On Sun, 19 Aug 2012, Bruno Prémont wrote:
> > I don't know bout hid_hw_close(). Certainly no more reports should be
> > submitted following usbhid_stop().
>
> Ok, I did just that, prevent new calls to usbhid_submit_report(), after
> calling hid_hw_close(), fixed one bug in my code that triggers
On Sat, 18 August 2012 Alan Stern wrote:
> On Sat, 18 Aug 2012, Bruno Prémont wrote:
>
> > One thing I just though about, how does usbhid handle the calls to
> > usbhid_submit_report() when hid_hw_stop()/hid_hw_close() have already
> > been called?
>
> Looks like they aren't synchronized at all.
On Sat, 18 Aug 2012, Bruno Prémont wrote:
> One thing I just though about, how does usbhid handle the calls to
> usbhid_submit_report() when hid_hw_stop()/hid_hw_close() have already
> been called?
Looks like they aren't synchronized at all. That's a bug.
usbhid_submit_report() should check th
On Sat, 18 August 2012 Bruno Prémont wrote:
> One thing I just though about, how does usbhid handle the calls to
> usbhid_submit_report() when hid_hw_stop()/hid_hw_close() have already
> been called?
> I will attempt to see if it makes a difference to shortcut my
> usbhid_submit_report() calls fro
On Sat, 18 August 2012 Alan Stern wrote:
> On Sat, 18 Aug 2012, Bruno Prémont wrote:
> > On Thu, 16 August 2012 Jiri Kosina wrote:
> > > On Thu, 16 Aug 2012, Bruno Prémont wrote:
> > >
> > > > > I don't really understand this explanation. Once usb_kill_urb()
> > > > > returns,
> > > > > the UR
On Sat, 18 Aug 2012, Bruno Prémont wrote:
> Hi Jiri,
>
> [CCing Alan Stern]
>
> On Thu, 16 August 2012 Jiri Kosina wrote:
> > On Thu, 16 Aug 2012, Bruno Prémont wrote:
> >
> > > > I don't really understand this explanation. Once usb_kill_urb()
> > > > returns,
> > > > the URB should be avail
Hi Jiri,
[CCing Alan Stern]
On Thu, 16 August 2012 Jiri Kosina wrote:
> On Thu, 16 Aug 2012, Bruno Prémont wrote:
>
> > > I don't really understand this explanation. Once usb_kill_urb() returns,
> > > the URB should be available for future use (and therefore all queues
> > > completely draine
On Thu, 16 Aug 2012, Bruno Prémont wrote:
> > I don't really understand this explanation. Once usb_kill_urb() returns,
> > the URB should be available for future use (and therefore all queues
> > completely drained).
>
> I won't have time today to check, though my guess is that on each
> echo $
On Wed, 15 August 2012 Jiri Kosina wrote:
> On Wed, 15 Aug 2012, Bruno Prémont wrote:
> > > I see. Alan Stern has fixed a huge pile of things in this area in
> > > 3.6-rc1.
> > > I have expected all of those to actually be on theoretical problems not
> > > ever having happened in the wild, but
On Wed, 15 Aug 2012, Bruno Prémont wrote:
> > I see. Alan Stern has fixed a huge pile of things in this area in 3.6-rc1.
> > I have expected all of those to actually be on theoretical problems not
> > ever having happened in the wild, but it might be that you are actually
> > chasing on of thos
Hi Jiri,
On Wed, 15 August 2012 Jiri Kosina wrote:
> I see. Alan Stern has fixed a huge pile of things in this area in 3.6-rc1.
> I have expected all of those to actually be on theoretical problems not
> ever having happened in the wild, but it might be that you are actually
> chasing on of th
On Wed, 15 Aug 2012, Bruno Prémont wrote:
> > > [ 6383.521833]
> > > =
> > > [ 6383.530020] BUG kmalloc-64 (Not tainted): Object already free
> > > [ 6383.530020]
> > > ---
Hi Jiri,
On Wed, 15 August 2012 Jiri Kosina wrote:
> On Mon, 30 Jul 2012, Bruno Prémont wrote:
> > Hi,
> >
> > This series updates picoLCD driver:
> > - split the driver functions into separate files which get included
> > depending on Kconfig selection
> > (implementation for CIR using RC_C
On Mon, 30 Jul 2012, Bruno Prémont wrote:
> Hi,
>
> This series updates picoLCD driver:
> - split the driver functions into separate files which get included
> depending on Kconfig selection
> (implementation for CIR using RC_CORE will follow later)
> - drop private framebuffer refcounting in
Hello,
On Tue, Aug 14, 2012 at 08:30:44AM +0200, Bruno Prémont wrote:
> > I'm kinda shooting in the dark but who flushes / cancels
> > fb_info->deferred_work?
>
> fb_deferred_io_cleanup() does so and is called by destroy fbops
> (when last reference to fb_info is returned):
I see. Sorry but jus
Hello Tejun,
[Tejun: sorry for duplicate, did hit "reply" instead of "reply to all"]
On Mon, 13 Aug 2012 16:27:08 Tejun Heo wrote:
> On Thu, Aug 09, 2012 at 08:09:47PM +0200, Bruno Prémont wrote:
> > As you are working on workqueues and related code, could you have a look
> > at my usage of them
Hello,
On Thu, Aug 09, 2012 at 08:09:47PM +0200, Bruno Prémont wrote:
> As you are working on workqueues and related code, could you have a look
> at my usage of them in combination with db_defio?
>
> The delayed memory corruptions or system reboots after unbinding/unplugging
> the PicoLCD seem v
Hi Tejun,
As you are working on workqueues and related code, could you have a look
at my usage of them in combination with db_defio?
The delayed memory corruptions or system reboots after unbinding/unplugging
the PicoLCD seem very much related to workqueue used to handle the deferred
IO to frameb
Hi David,
On Tue, 31 Jul 2012 09:26:07 David Herrmann wrote:
> This is not directly related to this patchset, but did you fix the
> locking issue with hid-core? It is still on my todo-list but I haven't
> gotten around fixing it, yet. However, I plan on fixing it this
> summer, but if picolcd does
Hi Bruno
On Mon, Jul 30, 2012 at 9:36 PM, Bruno Prémont
wrote:
> Hi,
>
> This series updates picoLCD driver:
> - split the driver functions into separate files which get included
> depending on Kconfig selection
> (implementation for CIR using RC_CORE will follow later)
> - drop private frame
Hi,
This series updates picoLCD driver:
- split the driver functions into separate files which get included
depending on Kconfig selection
(implementation for CIR using RC_CORE will follow later)
- drop private framebuffer refcounting in favor of refcounting added
to fb_info some time ago
-
21 matches
Mail list logo
