On Mon, Jun 27, 2016 at 06:27:21PM +0200, Peter Rosin wrote: > On 2016-06-27 15:17, Guenter Roeck wrote: > > On 06/27/2016 03:11 AM, Peter Rosin wrote: > >> Fill the gap for this pre-existing driver. > >> > >> Signed-off-by: Peter Rosin <peda@xxxxxxxxxx> > >> --- > >> .../devicetree/bindings/i2c/i2c-arb-pca9541.txt | 33 ++++++++++++++++++++++ > >> MAINTAINERS | 1 + > >> 2 files changed, 34 insertions(+) > >> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-arb-pca9541.txt > >> > >> Hi! > >> > >> I'm wondering about this driver. It is not a trivial device, and yet it > >> has historically relied on the i2c core matching the chip w/o vendor > >> prefix. This is not ideal. But what to do about the driver implementing > >> this in terms of an i2c-mux, somthing which the chip is not; It is an > >> i2c arbitrator. It just happens to rely on the i2c mux core also handling > >> i2c gates and i2c arbitrators. But that seems like a Linux detail. So I > >> don't know what to do here? > >> > > > > The concept of arbitrators didn't exist when I wrote the driver. I would not > > have a problem with renaming the file if that is what you are asking for. > > No, that was not my issue, I just wanted to document bindings for pca9541, > and I didn't like how it turned out. > > I don't really care if the bindings doc is named i2c-mux-pca9541.txt (that > would match the name of the driver, but it still wouldn't make the chip a mux). So name it i2c-pca9541.txt or the somewhat standard nxp,pca9541.txt following the compatible. > > >> That is, the patch - as is - describes something that would be trivial to > >> support today, but at the same time it seems to be too tied to Linux. > >> > >> The problem is that the i2c@0 intermediate node is not really needed, but > >> at the same time removing it would cause a disruption for the driver since > >> it can't really use the i2c mux core if that node isn't there. I don't > >> see a simple way to fix that in the i2c mux core either (but admittedly > >> haven't given it too much thought). > >> > > > > The gpio arbitrator uses the same principle as well. Why not just leave it > > alone ? Besides, I think it is a good idea to have it, since it groups > > the i2c devices behind the chip together. I would not consider that to be > > a Linuxism, but a design choice. > > The grouping argument would make sense if there was anything outside the > group. Also, the required reg property and the extra #address-cells and > #size-cells doesn't add anything and just gets in the way, and is indeed > the result of Linuxisms leaking back into device trees. > > If there were no muxes and this was a new driver, the example bindings > would almost certainly have been something like: > > i2c-arbitrator@74 { > compatible = "nxp,pca9541"; > reg = <0x74>; > > #address-cells = <1>; > #size-cells = <0>; > > eeprom@54 { > compatible = "at,24c08"; > reg = <0x54>; > }; > }; > > which I find much nicer. Yes. > But, I can't find a way to implement that and keep backwards compatibility > with old existing device trees. I don't see any in the kernel tree nor is it documented, so there is not compatibility to worry about. > > Which is why I submitted the patch I did. It documents the pca9541 bindings, > something which is lacking, in terms of i2c-mux as the driver is written. > At the same time, this feels ugly and exposes linuxism and I wanted to make > that clear up front. The above simply looks better than the example in the > patch. > > I intended to mark the submission [RFC PATCH], but I now realize that that > went missing along the way, sorry. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html