Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [GIT PATCH] char/misc patches for 3.10-rc1 | Date | Mon, 29 Apr 2013 22:50:47 +0200 |
| |
On Monday 29 April 2013, Linus Torvalds wrote: > On Mon, Apr 29, 2013 at 12:54 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> There are other things wrong with that whole SSBI driver crap that you > seem to be ignoring: > > - it's not a bus, it's just a driver. Just because some people call > it "serial bus" doesn't make it magically about a "bus". I can call an > ethernet driver an "ethernet bus driver", and it may be technically > correct, but it is still bullshit. And ethernet is damn more a real > bus than that SSBI driver is. That's just a pure serial driver for a > very specific piece of embedded hardware. Stop calling it a bus.
Fair enough. Of course the distinction here is not based on what it does, but how it gets used. I've looked at the driver now and it seems to do exactly the same as i2c and spi, which we certainly need to treat as buses here. The only difference here is that this hardware only has a single use in linux-next, which in an MFD driver. If we had a lot of different ones, it could reasonably be called a bus and use the bus_type and device_driver infrastructure.
> - The whole Kconfig thing is complete and utter garbage. There is no > excuse what-so-ever for ever asking the user about it. Not on x86, not > on ARM. The drivers that actually use that magical serial line > driver should just have selected it.
Agreed.
> - I'm not seeing what commonalities this thing can have with anything > else. Did anybody look at the code? There's nothing generic there.
It's a simple bus that has addressable registers. We have a generic infrastructure for these things in drivers/base/regmap, currently handling I2C, SPI and MMIO based buses, which are often used as different methods to address the same device endpoints. I think it would be sensible to add another one-off type here and convert the user(s) to be based on the regmap interface rather than its own set of exported symbols. Alternatively, it could just be moved next to the pm8921 driver in drivers/mfd, which is currently its only user, but the Qualcomm people might have a better idea on whether other devices connected to ssbi follow the same pattern or whether they are going to live elsewhere outside of drivers/mfd.
Arnd
| |