On Fri, 26 March 2010 Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote:
> On Friday 26 March 2010 01:59:19 pm Jiri Kosina wrote:
> > On Fri, 26 Mar 2010, Bruno Prémont wrote:
> > > > > + for (i = 0; i < PICOLCD_KEYS; i++) {
> > > > > + int key = ((int *)idev->keycode)[i];
> > > >
> > > > Keycodes are now short, not int. Also, just do:
> > > > input_set_capability(idev, EV_KEY, data->keycode[i]);
> > > >
> > > > > + if (key < KEY_MAX && key >= 0)
> > > > > + input_set_capability(idev, EV_KEY, key);
> > >
> > > Oops, I was not careful enough when switching over...
> >
> > Dmitry, thanks a lot for rapid review the driver.
> >
> > Bruno, could you please fix this and submit a followup 1/6 patch, so that
> > I could queue the driver in my tree?
> >
> > I have almost finished going over the driver and haven't encountered any
> > other issues that would require immediate fixing.
> >
> > Still, it would be nice to have the framebuffer/LCD/backlight bits
> > reviewed by respective subsystem maintainers. But I'll probably queue the
> > driver nevertheless and add potential ACKs later.
>
> FWIW I am not entrely happy with the whole send-and_wait implementation -
> it looks like it is not being called concurrently so we don't need mutex
> there... I'd do something like:
It can be called concurrently, not within patch 1/6 but it definitely
can once patch 6/6 is applied (concurrent access to debugfs files for
EEPROM and/or FLASH).
Even later on when FLASH (and EEPROM) access get moved to a better home
concurrent access will still exist.
> send_nand_wait() {
>
> set_bit(WAITING_RESPONSE, data->state);
> prepare message
> send message
> wait_for_event_interruptible_timeout(&data->wait,
> !test_bit(WAITING_RESPONSE, data->state));
> if (!test_bit()) {
> process
> return 0;
> }
>
> return -ETIME;
> }
>
> irq(...) {
>
> else if (test_bit(WAITING_RESPONSE, data->state)) {
> copy response...
> clear_bit(WAITING_RESPONSE, data->state);
> wake_up(&data->wait);
> }
> }
>
> and not bother with kmallocing pending structure, but it should not
> stop from merging driver.
It might be an option to not allocate the pending structure but as
the whole "pending" access is definitely not a hot path (flashing
firmware or splash and changing EEPROM values will most probably
not be done very often). The only more common use is version check
on probe.
So what is more expensive, the used memory or the CPU usage to
allocate/release the struct? That probably depends on reader's taste.
Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
