Re: [PATCH net] net: usb: lan78xx: Connect PHY before registering MAC

thout having the PHY connected. > > Change the order to close this race condition. > > Fixes: 92571a1aae40 ("lan78xx: Connect phy early") > Reported-by: Daniel Wagner > Signed-off-by: Andrew Lunn Tested-by: Daniel Wagner Thanks for the fix! Daniel

Re: lan78xx and phy_state_machine

> >> Unfortunately, you didn't wrote which kernel version works for you > >> (except of this splat). Only 5.3 or 5.4-rc3 too? > > With v5.2.20 I was able to boot the system. But after this discussion > > I would say that was just luck. The race seems to exist for longer and > > only with my 'specia

Re: lan78xx and phy_state_machine

Hi Stefan, On Thu, Oct 17, 2019 at 07:05:32PM +0200, Stefan Wahren wrote: > Am 17.10.19 um 08:52 schrieb Daniel Wagner: > > On Wed, Oct 16, 2019 at 05:51:07PM +0200, Andrew Lunn wrote: > >> Please could you give this a go. It is totally untested, not even > >> comp

Re: lan78xx and phy_state_machine

On Wed, Oct 16, 2019 at 05:51:07PM +0200, Andrew Lunn wrote: > Hi Daniel > > Please could you give this a go. It is totally untested, not even > compile tested... Sure. The system boots but ther is one splat: [2.213987] usb 1-1: new high-speed USB device number 2 using dwc2 [2.426789] h

Re: lan78xx and phy_state_machine

On Tue, Oct 15, 2019 at 07:16:53PM +0200, Daniel Wagner wrote: > Could it be that the networking interface is still running (from > u-boot and PXE) when the drivers is setting it up and the workqueue is > premature kicked to work? I've dump the registers before the device is setu

Re: lan78xx and phy_state_machine

Hi Andrew, On Tue, Oct 15, 2019 at 02:53:27AM +0200, Andrew Lunn wrote: > On Mon, Oct 14, 2019 at 04:06:04PM +0200, Daniel Wagner wrote: > > Hi, > > > > I've trying to boot a RPi 3 Model B+ in 64 bit mode. While I can get > > my configuratin booting with v5.2.20,

Re: wl1251 & mac address & calibration data

" though -- but for that I can only refer you at this point to some of Daniel Wagner and Tom Gunderson's firmwared deamon prospect. It should help pave the way for a clean solution and help address other stupid issues. The firmwared project is hosted here https://github.com/teg/firmw

[PATCH] xprtrdma: use complete() instead complete_all()

From: Daniel Wagner There is only one waiter for the completion, therefore there is no need to use complete_all(). Let's make that clear by using complete() instead of complete_all(). The usage pattern of the completion is: waiter context waker co

[PATCH 0/2] wireless: Use complete() instead complete_all()

From: Daniel Wagner Hi, Using complete_all() is not wrong per se but it suggest that there might be more than one reader. For -rt I am reviewing all complete_all() users and would like to leave only the real ones in the tree. The main problem for -rt about complete_all() is that it can be uses

[PATCH 2/2] ath10k: use complete() instead complete_all()

From: Daniel Wagner There is only one waiter for the completion, therefore there is no need to use complete_all(). Let's make that clear by using complete() instead of complete_all(). The usage pattern of the completion is: waiter context waker context scan.st

[PATCH 1/2] carl9170: Fix wrong completion usage

From: Daniel Wagner carl9170_usb_stop() is used from several places to flush and cleanup any pending work. The normal pattern is to send a request and wait for the irq handler to call complete(). The completion is not reinitialized during normal operation and as the old comment indicates it is

Re: [PATCH net-next] nfnetlink_queue: enable PID info retrieval

Hi Daniel, > [ Cc'ing John, Daniel, et al ] > > Btw, while I just looked at scm_detach_fds(), I think commits ... > > * 48a87cc26c13 ("net: netprio: fd passed in SCM_RIGHTS datagram not set > correctly") > * d84295067fc7 ("net: net_cls: fd passed in SCM_RIGHTS datagram not set > correctly") >

Re: [PATCH v2 net-next 0/12] bpf: map pre-alloc

> > this path set switches bpf hash map to use pre-allocation by default > and introduces BPF_F_NO_PREALLOC flag to keep old behavior for cases > where full map pre-allocation is too memory expensive. > > Some time back Daniel Wagner reported crashes when bpf hash map is >

Re: [PATCHSET v3] netfilter, cgroup: implement cgroup2 path match in xt_cgroup

On 11/23/2015 04:53 PM, Tejun Heo wrote: > On Mon, Nov 23, 2015 at 09:54:32AM +0100, Daniel Wagner wrote: > ... >>> [3.224665] BUG: spinlock bad magic on CPU#1, systemd/1 >>> [3.225653] lock: cgroup_sk_update_lock+0x0/0x60, .magic: , >>>

Re: [PATCH 7/9] sock, cgroup: add sock->sk_cgroup

On 11/23/2015 04:48 PM, Tejun Heo wrote: > On Mon, Nov 23, 2015 at 02:02:03PM +0100, Daniel Wagner wrote: >> On 11/21/2015 05:13 PM, Tejun Heo wrote: >>> Signed-off-by: Tejun Heo >>> Cc: Daniel Borkmann >>> Cc: Daniel Wagner >> >> I did a qui

Re: [PATCH 7/9] sock, cgroup: add sock->sk_cgroup

Hi Tejun, On 11/21/2015 05:13 PM, Tejun Heo wrote: > Signed-off-by: Tejun Heo > Cc: Daniel Borkmann > Cc: Daniel Wagner I did a quick test and for new connection the cgroup2 match worked as expected. For an existing connection I wasn't able to trigger the match. It is qui

Re: [PATCH 8/9] netfilter: prepare xt_cgroup for multi revisions

Hi Tejun, On 11/21/2015 05:14 PM, Tejun Heo wrote: > xt_cgroup will grow cgroup2 path based match. Postfix existing > symbols with _v0 and prepare for multi revision registration. > > Signed-off-by: Tejun Heo > Cc: Daniel Borkmann > Cc: Daniel Wagner Same as in my reply t

Re: [PATCH 9/9] netfilter: implement xt_cgroup cgroup2 path match

at least Acked-by should do the trick: Tested-by: Daniel Wagner Acked-by: Daniel Wagner cheers, daniel -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCHSET v3] netfilter, cgroup: implement cgroup2 path match in xt_cgroup

On 11/23/2015 08:11 AM, Daniel Wagner wrote: > [3.217648] systemd[1]: tmp.mount: Directory /tmp to mount over is not > empty, mounting anyway. > [3.224665] BUG: spinlock bad magic on CPU#1, systemd/1 > [3.225653] lock: cgroup_sk_update_lock+0x0/0x60, .magic: 000

Re: [PATCHSET v3] netfilter, cgroup: implement cgroup2 path match in xt_cgroup

Hi Tejun, On 11/21/2015 05:13 PM, Tejun Heo wrote: > This is v3 of the xt_cgroup2 patchset. Changes from the last take are > > * Folded cgroup2 path matching into xt_cgroup as a new revision rather > than a separate xt_cgroup2 match as suggested by Pablo. > > * Refreshed on top of Nina's net_

Re: [PATCH 6/7] sock, cgroup: add sock->sk_cgroup

Hi Tejun, On 11/19/2015 07:52 PM, Tejun Heo wrote: > +/* > + * There's a theoretical window where the following accessors race with > + * updaters and return part of the previous pointer as the prioidx or > + * classid. Such races are short-lived and the result isn't critical. > + */ > static in

Re: [PATCH 4/7] netprio_cgroup: limit the maximum css->id to USHRT_MAX

so that the > two cgroup related fields are adjacent. > > Signed-off-by: Tejun Heo > Cc: Daniel Borkmann > Cc: Daniel Wagner Acked-by: Daniel Wagner -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] bpf: BPF based latency tracing

On 06/20/2015 10:14 AM, Daniel Borkmann wrote: > I think it would be useful to perhaps have two options: > > 1) User specifies a specific CPU and gets one such an output above. Good point. Will do. > 2) Summary view, i.e. to have the samples of each CPU for comparison >next to each other in

[PATCH v2] bpf: BPF based latency tracing

0 || 32768 -> 65535: 72 || 65536 -> 131071 : 32 || 131072 -> 262143 : 26 || 262144 -> 524287

[PATCH v1] bpf: BPF based latency tracing

0 || 32768 -> 65535: 72 || 65536 -> 131071 : 32 || 131072 -> 262143 : 26 || 262144 -> 524287