| 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
| ||
|
Date: Fri, 25 Jul 2008 12:48:24 +0100 From: Jonathan Cameron <jic23@....ac.uk> To: David Brownell <david-b@...bell.net> CC: LKML <linux-kernel@...r.kernel.org>, Andrew Morton <akpm@...l.org> Subject: Re: [patch 2.6.26] gpio: pcf857x handle pca9500 and pca9501 Dear David, > On Thursday 24 July 2008, Jonathan Cameron wrote: > >> These two chips have two elements (on different i2c addresses), >> the first is a clone of the pcf8574 and the second 2kBit eeprom. >> > > That is, NXP documents say it's a pcf8582 eeprom, which > is software-compatible with what Linux calls a 24c02 chip. > > It'd be worth sending a patch so drivers/i2c/chips/at24.c > can handle those EEPROMs ... > Thanks, hadn't realized that it was compatible with that driver. Given the approach that seems to have been taken there, is it not the case that the changes should all be in the board config anyway to support a new chip? As the board config in question isn't going to be in mainline for a while anyway (awaiting da9030 driver) this means that no such patch would be needed. >> Seems easiest to support these separately so main query about >> this patch is should the device naming reflect this dual >> functionality. >> >> I've been using the pcf857x driver with a 9500 for several >> months without problems and just want this in to clean up >> a confusing element in a board config. >> > > Hmm, well I don't really see a way around having two entries > in the relevant boards' i2c board info ... so this patch just > ensures that *one* entry can list the actual part. > Indeed, I was merely advocating listing the actual part number so that the board config corresponds to the chips in front of the person using it. Not exactly important though as a comment explaining what is going on will do instead. > I'm curious why you added this chp to the pcf857x driver > rather than to the at24 driver ... since it's quite obvious > from docs that the chip is pcf8574-compatible, but only the > pca9500 lists the EEPROM compatibility. > Sorry, simply wasn't aware that the at24 driver would work with it and am currently running 2.6.26 meaning it wasn't actually there. I'm cynical and tend to wait for a release candidate or two before moving to a new kernel series! > I guess given my druthers I'd update Kconfig for both drivers > to mention these parts (and their need for two drivers), plus > add them to the at24 driver (rather than pcf857x) purely because > the docs are, overall, more clear about the GPIO compatibility > than about the EEPROM. > Makes a certain amount of sense but given that the at24 driver is quite specific about the use of generic chip names, whereas the pcf857x is listing devices would it not make more sense to add it there with help text explaining that eeprom is supported by the at24 driver? Pesky dual purpose chips get in the way of nice clean naming conventions! > >> As the Kconfig title for these is getting a bit long and the >> datasheet for these starts with stating they are pcf957x >> compatible so I haven't changed it. >> > > Right; helptext can have a sentence. > Indeed. Actually that's looking to be the only bit of the patch that will be needed. -- Jonathan -- 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/
Powered by blists - more mailing lists