Re: at24 driver - a possible problem

[Aleksandar Ivanov <ivanov.aleks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

I also tested the patch and it looks like it fixes the problem.
Thank you for the efforts:)

2009/11/9 Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>:
>
>> > Still, the latter one beats me right now. The sysfs-bin-write gets a kobject
>> > and the O_SYNC is placed in the flags of a filp during open. Is there a some
>> > connection between those? I'm not even sure if O_SYNC should be handled at the
>> > sysfs-layer instead of inside the driver?
>>
>> I'm not sure how sysfs could handle it. What backs up the sysfs file is
>> driver-specific, so only the driver knows how to ensure that the data
>> has been written. In the at24 driver case, the only way AFAICS is to
>> try to read one byte back from the EEPROM and only return when the read
>> is successful.
>
> ACK. Sorry, I was not specific here. I also imagined that a solution must look
> like:
>
>        if (flag_however_I_get_it == O_SYNC)
>                at24_eeprom_read(...)
>
> most probably in at24_write().
>
> What I meant with "handled at sysfs-layer" was that it felt wrong to look for
> some complicated way from the kobject to the O_SYNC flag. It appeared to me
> that it might be more suitable to let the sysfs-layer recognize the flag during
> open and then, maybe, set another flag in a struct which is easier to reach for
> a bin-file. Then again, I wondered how many sysfs-bin files would really need
> that and that the "eeprom"-bin file might be a gray area (because of really
> acessing a media).
>
>> is entirely possible that sysfs simply has no support for O flags. This
>> would have to be discussed at a higher level.
>
> Most probably.
>
> Regards,
>
>   Wolfram
>
> --
> Pengutronix e.K.                           | Wolfram Sang                |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkr33JUACgkQD27XaX1/VRuNZACgtsi5ORcR4PrmxNWNXs8IU4z5
> 6f8AnA6i5IhWuwg5OaX/RafoTfm3xi+/
> =4vXM
> -----END PGP SIGNATURE-----
>
>