On Wed, May 25, 2016 at 11:46:35AM -0700, Frank Rowand wrote: > On 5/25/2016 10:48 AM, Mark Brown wrote: > > Sometimes the best thing to do is remove the behaviour, some of these > Yes. And I have not formed an opinion on whether the existing > behavior should be kept, deprecated, or removed. I have avoided > commenting on that. That's not been clear... > > Adding documentation for every last implementation that happens to work > > in a given situation through layers of indirection isn't going to help > > with the usability issues DT has, one of the things that the > That is not a reasonable description of this case. > What the kernel does with the spi aliases is not a random unintended > side effect. It was a deliberate choice. Read the commit message for > bb29785e0d6d150181704be2efcc3141044625e2 I've read that (for the benefit of those playing at home that's "spi/of: Use DT aliases for assigning bus number"). What that reads like to me is that it's a quick hack which may or may not be intended to be used in the specific way it's being used now - it's still at a remove from the obviously not DT idiomatic spidev which isn't mentioned at all, it could be for that but it could also be for people trying to read log messages or distinguish between other devices. If it were for spidev I'd have expected labelling at the spidev level as it's both more direct and useful (we can easily get a string out rather than just a number). It does also mention a previous effort based on cell-index which is now being ignored as far as I can tell but presumably you feel must also be documented as a thing that might've done a thing in some older software release, I'm not sure that's useful though. Personally the way I parse this situation is that the kernel is taking a look at what's in the DT and making an effort to present it usefully in the running systems. Fixing our current interpretation in stone as a supported thing when we don't have to makes it more cumbersome to improve and discourages any efforts to do similar things in the future. It is reasonable to provide and document something here but when there's some fairly simple and obvious better things we could be doing it should be those rather than the legacy stuff.
Attachment:
signature.asc
Description: PGP signature
