Re: [PATCH] spi: reorganize drivers

[Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>]

On Monday 06 June 2011, Jean Delvare wrote:
> On Mon, 6 Jun 2011 13:21:07 +0200, Arnd Bergmann wrote:
> > A top-level /bus would work for me, and I guess would also address Russell's
> > concern. Regarding bus-specific drivers, we're gradually moving those out
> > of the bus specific directories anyway, basically the only bus directory
> > that really has device driver in it is USB at this point. It makes some
> > sense to have a bus-specific low-level user space interface driver like
> > sg or uio in the bus directory, but everything else should really belong
> > into some other subsystem.
> 
> Err, what about I2C and SPI? Aren't drivers/i2c/busses and drivers/spi
> full of "device drivers"? Or are these what you call "bus-specific
> drivers"? Maybe we need to define all the terms before the discussion
> continues further.

drivers/i2c/busses and drivers/spi are full of what I would call "bus
drivers" or "host drivers". They bind to a device from another bus
(platform, pci, ...) and export devices of their own type (i2c, spi, ...).
This is what all bus drivers do.

An i2c or spi device driver would in turn bind to that device and
provide a functionality not specific to that bus (e.g. hwmon, input,
leds, rtc or media).

> > (...)
> > This is about to get worse as we introduce new subsystems (e.g. iommu,
> > irq, clocksource, eeprom, nvram, ...) into which we are moving
> > code from arch/arm, drivers/char and drivers/misc. Having buses and
> > drivers in a separate hierarchy would make the drivers directory and
> > the respective menuconfig list more clearly structured IMHO.
> 
> This gets interesting. Would you suggest for example that i2c-core.c
> goes to bus/i2c, and drivers/i2c/busses becomes drivers/i2c? And that
> CONFIG_I2C is somewhere in menuconfig, and the hardware driver
> selection for drivers/i2c is in a totally different place?

No, all of drivers/i2c would go into bus/i2c or drivers/bus/i2c, there
is no point splitting that. The part that would no go there is the various
drivers that are already not under drivers/i2c but are for devices
connected to an i2c bus.

The confusion is probably that in case of drivers/scsi and drivers/usb,
both bus and device drivers are in the same subdirectories. If we move
drivers/usb to bus/usb, I would probably recommend to split
drivers/usb/{serial,storage,atm,misc} out of it and move it to
drivers/{tty/usb-serial,block/usb,net/usb/atm,misc/usb} though, to
make it look more like PCI or i2c that already have a clean split.

> While I am surprised, I am not necessarily objecting. But it seems that
> you should better define what your actual plan is, before asking us if
> we agree with it.

My original plan was to think this through a bit more, but Grant posted
the big spi reorganization, so I jumped in on that because it wouldn't
be nice to have to move all those drivers again.

	Arnd

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2