On Tue, 16 Sep 2014, Petr [iso-8859-1] Ml�dek wrote:
> Anyway, the solution for the race between kick_hub_wq() and
> hub_event() might be to get the reference already in kick_hub_wq().
Yes, this probably would work.
> I mean something like:
>
> static void kick_hub_wq(struct usb_hub *hub)
> {
>
On Tue 16-09-14 11:10:31, Petr Mládek wrote:
> Anyway, the solution for the race between kick_hub_wq() and
> hub_event() might be to get the reference already in kick_hub_wq().
> I mean something like:
>
> static void kick_hub_wq(struct usb_hub *hub)
> {
> if (hub->disconnected || work_pendi
On Fri 12-09-14 11:44:14, Alan Stern wrote:
> On Fri, 12 Sep 2014, Petr Mladek wrote:
>
> > > I don't think you can eliminate the lock quite so easily. This patch
> > > introduces some nasty races.
> > >
> > > > @@ -577,18 +571,20 @@ static int hub_port_status(struct usb_hub *hub,
> > > > int
On Fri, Sep 12, 2014 at 02:21:05PM +0200, Petr Mladek wrote:
> There is no need to have separate kthread for handling USB hub events.
> It is more elegant to use the workqueue framework.
>
> The workqueue is allocated as unbound, cpu intensive, and freezable.
I'd just go with WQ_FREEZABLE. As a
On Fri, 12 Sep 2014, Petr Mladek wrote:
> > I don't think you can eliminate the lock quite so easily. This patch
> > introduces some nasty races.
> >
> > > @@ -577,18 +571,20 @@ static int hub_port_status(struct usb_hub *hub, int
> > > port1,
> > >
> > > static void kick_khubd(struct usb_hu
On Fri 2014-09-12 10:16:21, Alan Stern wrote:
> On Fri, 12 Sep 2014, Petr Mladek wrote:
>
> > There is no need to have separate kthread for handling USB hub events.
> > It is more elegant to use the workqueue framework.
> >
> > The workqueue is allocated as unbound, cpu intensive, and freezable.
On Fri, 12 Sep 2014, Petr Mladek wrote:
> There is no need to have separate kthread for handling USB hub events.
> It is more elegant to use the workqueue framework.
>
> The workqueue is allocated as unbound, cpu intensive, and freezable.
> There does not seem to be any big advantage to run it on
There is no need to have separate kthread for handling USB hub events.
It is more elegant to use the workqueue framework.
The workqueue is allocated as unbound, cpu intensive, and freezable.
There does not seem to be any big advantage to run it on the same CPU.
The handler is taking a lock and thu
8 matches
Mail list logo
