On Tue, 2014-12-09 at 09:54 +0100, Wolfram Sang wrote: > > > Oh, I thought we agreed that you take it via powerpc. I still think this > > > is the best solution. > > > > I threatened to do that :-) I don't remember you replying, did I miss > > it ? > It is here: > http://thread.gmane.org/gmane.linux.drivers.i2c/20762/focus=21099 Weird, it never made it to my mbox... anyway: > I did not invent DT bindings. No I did :) Or rather Mitch did with OF and I contributed heavily at slapping it onto everbody's face :) Then I let Grant run with it and deal with the carnage... but as you can imagine, I feel like whatever rule I made for others don't apply to me :) > I did not invent that DT is/should be a >hardware description. This is the basic idea but it's flexible. It is in essence a description of the environment, which is essentially the HW but there is no taboo about adding various ancilliary pieces of informations that one deems useful, especially if they are prefixed by a vendor prefix to avoid collision with "well defined" properties. I think we ended up being fairly strict about the rules initially to try to rein in the crowd of ARM embedded folks who really went all over the place but like every rule, it's meant to be broken (hear the french guy talking ...). >For me, it is a burden that I (as a subsystem > maintainer for mainly drivers) have to prevent people from using DT ?> > for software configuration (some people use it as an 1:1 mapping for > platform data even.) Well, yes and no... for example, it's perfectly legit to have a node representing a UART, have the firmware slap into it the default expected baud rate as a property (or whatever it has configured it to be) which makes it then a reasonable default for the kernel to use. Generally speaking there is nothing fundamentally wrong about having configuration information in the device-tree, but it has to be clearly identifiable as such. The description of the HW in my world at least also implies how that HW is meant to be configured for a given platform. > Since there are no guidelines (probably there can't > be), I developed a set of rules out of experience and when those don't > match I ask for help. Having a different set of rules for > powerpc/arm/... (or server/embedded for that matter) will increase > this burden a lot. People will come and say "But they did it as > well..." The basic rule is "does it make sense ?". Really. Apply your jugement based on your experience as to whether something is a reasonable comprimise or not and whether it will turn into a big mess in the long run or, on the contrary, is a perfectly fine ad-hoc solution for a given setup. > It's getting quite tempting to just throw that driver into powerpc.git Maybe this is the easiest. Just make sure that MAINTAINERS also point this driver to you or PowerNV maintainers. And no Ack from me, please. Then, I can always say "I dunno" if people start asking questions. :) Technically I need your ack if we are to follow the process for Linux upstreaming. I doubt Linux will holler if I just put it in the tree but I'd rather follow the process if possible. >> And I don't give a flying crap about what random ARM SOC vendor >> thinks of my powerpc FW interface for a powerpc unique FW interface. > > But you are not alone here. If you open the box for giving busses a > configurable name, I can see other people (without FW) wanting this, > too. So, this discussion will come anyhow IMO. Right and I personally don't see a problem with that ... what's fundamentally wrong with letting the platform description (ie,. the DT) specify reasonable names for i2c busses ? It has pretty much no impact on drivers nowadays but means things are easier to figure out/locate for users/admin/developers and eases diagnostics. > > If you are ok with the driver and are happy for me to take it, > > please send an Ack. > > "Happy" is not the correct word, but let's just go over with it. Maybe > like this: > > Acked-by: Wolfram Sang <wsa@xxxxxxxxxxxxx> (I2C part, excluding the bindings) Forget about the binding mess, Olof reminded me that the result of one of the recent KS was that the bindings no longer needed "approval", and are to be sent to the list purely for informational purposes, otherwise the process is a mess. We have to provide at least some trust here, and we can reject the driver if we think the binding is really way too gross. > > From a binding perspective, it's just a piece of additional info that > > the firmware provides for convenience. > > I do understand the use case. I even agree it makes sense to have > something like this. It is just that I'd prefer a generic, widely > acknowledged solution, with consensus where it belongs and how it should > be named. Not a custom solution which, frankly, feels forced on me > by time pressure I have nothing to do with. So, not happy here, but also > not looking for drama. Let's move on... Adding a generic binding for i2c controllers to name their respective busses sounds like a laudable idea, and if that happens I'll be happy to update the driver to take that into account so that a future FW version can add it (in addition to the old property for backward compat). Ben. -- 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
