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@xxxxxxxxxxxxxx>: > >> > 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----- > > -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
