Hi
On 5/21/20 5:37 AM, Serge Semin wrote:
On Wed, May 20, 2020 at 03:46:11PM +0300, Jarkko Nikula wrote:
Hi
On 5/10/20 12:50 PM, Serge Semin wrote:
Seeing the DW I2C platform driver is getting overcomplicated with a lot of
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.
Comment to this patch and patches 9/12 and 12/12:
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?
I think sub directory decision under each subsystem is more subsystem
rather than vendor/driver specific. Good point anyway.
For this patchset I'd like more if changes are done to
i2c-designware-platdrv.c since it's not too complicated yet :-)
If it starts to look too messy in the future then it's time split I think.
Jarkko
