linux-kernel - Re: [PATCH v3 1/6] hid: new driver for PicoLCD device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100326223932.01305c17@neptune.home>
Date:	Fri, 26 Mar 2010 22:39:32 +0100
From:	Bruno Prémont <bonbons@...ux-vserver.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Jiri Kosina <jkosina@...e.cz>, linux-input@...r.kernel.org,
	linux-usb@...r.kernel.org, linux-fbdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	"Rick L. Vinyard Jr." <rvinyard@...nmsu.edu>,
	Nicu Pavel <npavel@...ner.com>,
	Oliver Neukum <oliver@...kum.org>,
	Jaya Kumar <jayakumar.lkml@...il.com>
Subject: Re: [PATCH v3 1/6] hid: new driver for PicoLCD device

On Fri, 26 March 2010 Dmitry Torokhov <dmitry.torokhov@...il.com> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/