Messages in this thread | | | Subject | Re: [PATCH v2 3/4] Device bindings documentation updated ACPI-enabled platforms not currently supported | From | Luis Oliveira <> | Date | Tue, 8 Nov 2016 14:18:44 +0000 |
| |
Hi,
As you suggested I will split the drivers. I am thinking of doing 5 patches:
- factor out master() parts
- separate Master part to i2c-designware-master.c (changes in i2c-designware-core.c)
- enable Slave part to i2c-designware-slave (changes in i2c-designware-core.c)
- glue drivers and device bindings
- cleaning
Regards,
Luis
On 21-Oct-16 11:54, Andy Shevchenko wrote: > On Fri, 2016-10-21 at 10:56 +0100, Luis Oliveira wrote: >> Since practically 90% of the code is shared between master and slave, >> I was >> thinking if it will be acceptable to use the same driver for both but >> differentiate the master/slave mode by the compatible strings. > It might be possible to split like other drivers do: > > 1. Core part (i2c-designware-core.c) > 2. Master part (i2c-designware-master.c) > 3. Slave part (i2c-designware-slave.c) > 4. Glue drivers (like: i2c-designware-platdrv.c) > >> Thanks, >> Luis >> >> On 10/18/2016 16:17, Wolfram Sang wrote: >>>> This is needed because the configuration is different and the i2c- >>>> designware >>>> cannot be master/slave without a reset. To resolve that I added >>>> this property >>>> to bind it as a slave when needed. >>> Aww, pity that the HW can't do that. Do you have details why? >>> >>> If that is really a HW limitation, then I'd suggest having a >>> seperate >>> driver for slave-only mode so we can differentiate by compatible >>> strings. >>> >>
| |