On Wed, May 20, 2020 at 03:46:11PM +0300, Jarkko Nikula wrote:I think sub directory decision under each subsystem is more subsystem rather than vendor/driver specific. Good point anyway.
On 5/10/20 12:50 PM, Serge Semin wrote:
Seeing the DW I2C platform driver is getting overcomplicated with a lot ofComment to this patch and patches 9/12 and 12/12:
vendor-specific configs let's introduce a glue-layer interface so new
platforms which equipped with Synopsys Designware APB I2C IP-core would
be able to handle their peculiarities in the dedicated objects.
Currently i2c-designware-platdrv.c is about 500 lines of code so I don't
think it's too overcomplicated. But I feel we have already too many Kconfig
options and source modules for i2c-designware and obviously would like to
push back a little from adding more.
I don't think i2c-designware-platdrv.c becomes yet too complicated if Baikal
related code is added there, perhaps under #ifdef CONFIG_OF like MSCC Ocelot
code is currently.
Well, it's up to you to decide, what solution is more suitable for you to
maintain. My idea of detaching the MSCC and Baikal-T1 code to the dedicated
source files was to eventually move the whole i2c-designware-* set of files
into a dedicated directory drivers/i2c/buses/dw as it's done for some others
Synopsys DesignWare controllers: drivers/pci/controller/dwc/, drivers/usb/dwc2,
drivers/usb/dwc3, drivers/net/ethernet/synopsys/ . If you think, that it's too
early for Dw I2C code to live in a dedicated directory, fine with me. I can
merge the MSCC and Baikal-T1 code back into the i2c-designware-platdrv.c .
So what's your final word in this matter?