Re: [PATCH v2 6/6] hid: add experimental access to PicoLCD device'sEEPROM and FLASH

[Bruno PrÃmont]

On Sat, 20 March 2010 Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote:
> On Sat, Mar 20, 2010 at 05:11:19PM +0100, Bruno PrÃmont wrote:
> > The PicoLCD device has a small amount of EEPROM and also provides
> > access to its FLASH where firmware and splash image are saved.
> > In flasher mode FLASH access is the only active feature.
> > 
> > Give read/write access to both via debugfs files.
> > 
> 
> It looks you are allowing multiple users access to these files. What
> will happen if 2 processes try to write EEPROM at the same time?

Writes will be serialized by the wait for response from device with
picolcd_send_and_wait() and it's up to userspace to repeat the
reads/writes in order to get all the data they need if they requested
more that the 20 bytes that can be transferred in a single HID report.

For flash access a concurrent write to same area can cause one of the
writers to conflict with the other one as a write there is a sequence
of operations which can interleave (e.g. A erases, A writes 1/2,
B erases, B writes 1/2, A writes 2nd 1/2, B writes 2nd 1/2 which would
fail).
A single-user open would be a nice work-around for this.
I would prefer to make erase operation explicitly visible to user so
I don't have to do the erase behind the scenes.
I've not yet looked in the area of mtd/nand support if I can use their
interface.

This is the big reason I did put both to debugfs, they (especially
flash access) need to be made visible in a better way.

> > +
> > +static inline int picolcd_init_devfs(struct picolcd_data *data,
> > +		struct hid_report *eeprom_r, struct hid_report *eeprom_w,
> > +		struct hid_report *flash_r, struct hid_report *flash_w,
> > +		struct hid_report *reset)
> > +{
> 
> I don't think this should be forced inline.

Ok, will drop most of the 'inline' keywords as you suggested already
on one of the other patches.

Thanks for the review,
Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/