Refactor I2C driver implementation into separate modules in order to add
support for SPI MCP48FxBy1/2/4/8 DAC family on top of the I2C
implementation. The I2C and SPI devices have the same memory map and
supported functionalities.

Signed-off-by: Ariana Lazar <ariana.lazar@microchip.com>
---
Changes in v7:
- replace custom mask define with standard field_prep()
- use "Suggested-by" instead of "Reported-by" where it was more suitable
- use "Fixes:" with "Closes:" instead of "Link:" for fixes tags in commit
   messages 
- modified module description for core when adding support for SPI parts
   in order to specify SPI families too 
- remove unused macro MCP47FEB02_GAIN_BIT_MASK from the second commit
- Link to v6: https://lore.kernel.org/r/20260916-mcp47feb02_refactor-v6-0-285464651f89@microchip.com

Changes in v6:
- use field_get() in Gain, Vref and Power-Down registers channel formulas
- rebase from 7.2 to 7.3-rc1
- add fixes tags and Cc stable in the commit messages
- add numeric constants in front of time defines for better readability
- replaced dev_err() with dev_warn_probe() for missing label
- if match data is not found at probe, return -ENODATA and a suitable
    error message
- Link to v5: https://lore.kernel.org/r/20260909-mcp47feb02_refactor-v5-0-8b67bcab93d1@microchip.com

Changes in v5:
- improve commit messages by justifying the changes made
- increase polling time for EEPROM writes
- delete unnecessary comments and extra blank line from header file
- Link to v4: https://lore.kernel.org/r/20260819-mcp47feb02_refactor-v4-0-beb2aa3bfd09@microchip.com

Changes in v4:
- remove unused headers
- add missing header types.h in protocol files
- create 6 precursor commits before the refactor patch for handling:
    - comment typo
    - renaming command mask define
    - for an invalid label use a debug message instead of probe error
    - correct return value in store_eeprom_store() for false state case
    - correct channel gain formula
    - read DAC value register to initialize channel data struct field at
      probe 
- Link to v3: https://lore.kernel.org/r/20260804-mcp47feb02_refactor-v3-0-97f8b81f3628@microchip.com

Changes in v3:
- renumbering the patch version to include the first patch submision
- fix review comments device tree binding:
   - change 'additionalProperties' to unevaluatedProperties
   - add else branch with spi-max-frequency in the condition which checks
     if a device has SPI interface
   - correct SPI address example
   - add clock polarity and clock phase properties for SPI devices
   - enumerate I2C devices in lexicographic order from the description section
   - specify supported SPI modes using dependencies
- fix review comments driver:
   - remove unneccesarry libraries and add the missing ones
   - correct comment typo
   - return -ENODEV using dev_err_probe() in protocol probe functions
   - use named initializers
   - move defines for registers and enums from the header to the core file
   - add dev_set_drvdata() in probe()
   - move mutex aquiring from mcp47feb02_write_to_eeprom() to
     store_eeprom_store()
   - write correct value into Vref register in resume()
- Link to v2: https://lore.kernel.org/r/20260723-mcp47feb02_refactor-v1-0-ee59e63672bc@microchip.com

v2:
- include in the same patch series the refactoring of the driver and the
  support for SPI devices, but in different patches
- remove changes regarding review comments received not related to the
  code refactoring
- first version of the combined refactoring I2C and adding support for SPI
  driver
- Link to v1: https://lore.kernel.org/all/20260403-mcp47feb02-fix2-v1-1-da60c773550e@microchip.com

v1:
- first version which did not separate the refactoring and adding support for
  SPI devices (into different patches from the same series)

---
Ariana Lazar (11):
      iio: dac: mcp47feb02: initialize dac_data field in channel data struct at probe
      iio: dac: mcp47feb02: Fix gain field initialization for active channels
      iio: dac: mcp47feb02: use field_get() instead of custom dynamic macros
      iio: dac: mcp47feb02: Return len when disabling EEPROM store
      iio: dac: mcp47feb02: Increase EEPROM Programming Write Cycle Time
      iio: dac: mcp47feb02: Avoid unjustified probe error on missing label
      iio: dac: mcp47feb02: correct typo from a comment
      iio: dac: mcp47feb02: use field_prep() instead of custom dynamic macros
      iio: dac: mcp47feb02: refactor MCP47FEB02 I2C driver into two modules
      dt-bindings: iio: dac: add support for MCP48FEB02 SPI
      iio: dac: add support for Microchip MCP48FEB02

 .../bindings/iio/dac/microchip,mcp47feb02.yaml     | 221 +++++++++---
 MAINTAINERS                                        |   2 +-
 drivers/iio/dac/Kconfig                            |  32 +-
 drivers/iio/dac/Makefile                           |   4 +-
 .../iio/dac/{mcp47feb02.c => mcp47feb02-core.c}    | 388 ++++-----------------
 drivers/iio/dac/mcp47feb02-i2c.c                   | 145 ++++++++
 drivers/iio/dac/mcp47feb02-spi.c                   | 145 ++++++++
 drivers/iio/dac/mcp47feb02.h                       |  43 +++
 8 files changed, 600 insertions(+), 380 deletions(-)
---
base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
change-id: 20260625-mcp47feb02_refactor-fa8420ae3282

Best regards,
-- 
Ariana Lazar <ariana.lazar@microchip.com>

On Fri, Sep 18, 2026 at 12:06:26PM +0300, Ariana Lazar wrote:
> Refactor I2C driver implementation into separate modules in order to add
> support for SPI MCP48FxBy1/2/4/8 DAC family on top of the I2C
> implementation. The I2C and SPI devices have the same memory map and
> supported functionalities.

Jonathan, can you pick up the fixes from the series, please?
It will reduce a burden a lot (yeah, I know that it might mess with
Sashiko, but wouldn't simple delay fix this, I mean to give Sashiko
a time it needs and then update the branch?).

-- 
With Best Regards,
Andy Shevchenko

On Fri, 18 Sep 2026 12:52:53 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Fri, Sep 18, 2026 at 12:06:26PM +0300, Ariana Lazar wrote:
> > Refactor I2C driver implementation into separate modules in order to add
> > support for SPI MCP48FxBy1/2/4/8 DAC family on top of the I2C
> > implementation. The I2C and SPI devices have the same memory map and
> > supported functionalities.  
> 
> Jonathan, can you pick up the fixes from the series, please?
> It will reduce a burden a lot (yeah, I know that it might mess with
> Sashiko, but wouldn't simple delay fix this, I mean to give Sashiko
> a time it needs and then update the branch?).
> 
I'm not sure sashiko ever looks beyond mainline and given recent general
comments from Linus about only sending him late cycle fixes for stuff
that went wrong this cycle or is a major issue (which I've been interpreting
 as applying after rc4) I'm not thinking these fixes will go upstream before
 the merge window.  I don't mind applying them to the togreg branch now but
that isn't currently picked up by sashiko.

My biggest current issue with these bots is they make the workflow
of nibbling away at patch sets like I traditionally did not work
so well.  One option is to just send the whole series but edit
the titles to say they are already applied?  Hopefully that
lets reviewers jump over them or even maybe filter them out?

Anyhow, let me queue some of these.  I doubt we'll see anything new
from sashiko given the minor tweaks the rest of this series.

So with that in mind, applied patches in this order
1 2 4 5
held 6 back for the thing about checking if property present.
3 7 8 with link dropped.

So just 6 9 and 10 for next version please.

All the above on the testing branch of iio.git.

Thanks,

Jonathan

Hi Jonathan,

Thank you for the review.

> Anyhow, let me queue some of these.  I doubt we'll see anything new
> from sashiko given the minor tweaks the rest of this series.
> 
> So with that in mind, applied patches in this order
> 1 2 4 5
> held 6 back for the thing about checking if property present.
> 3 7 8 with link dropped.
> 
> So just 6 9 and 10 for next version please.
> 
> All the above on the testing branch of iio.git.

I was wondering if the correct approach for the v8 series is to create
a new branch based on iio/testing and add the remaining patches onto
it? 

These would include the needed changes: the property_present check for
the label (former patch 6), the new precursor patch for the EEPROM
mutex (former patch 9 split into 2 patches), along with the refactoring
and SPI support additions (former patches 10 and 11).

Please let me know if this is the preferred way to handle it.

Best regards,
Ariana

On Mon, 21 Sep 2026 14:16:34 +0000
<Ariana.Lazar@microchip.com> wrote:

> Hi Jonathan,
> 
> Thank you for the review.
> 
> > Anyhow, let me queue some of these.  I doubt we'll see anything new
> > from sashiko given the minor tweaks the rest of this series.
> > 
> > So with that in mind, applied patches in this order
> > 1 2 4 5
> > held 6 back for the thing about checking if property present.
> > 3 7 8 with link dropped.
> > 
> > So just 6 9 and 10 for next version please.
> > 
> > All the above on the testing branch of iio.git.  
> 
> I was wondering if the correct approach for the v8 series is to create
> a new branch based on iio/testing and add the remaining patches onto
> it? 
> 
> These would include the needed changes: the property_present check for
> the label (former patch 6), the new precursor patch for the EEPROM
> mutex (former patch 9 split into 2 patches), along with the refactoring
> and SPI support additions (former patches 10 and 11).
> 
> Please let me know if this is the preferred way to handle it.

Yes please do that. It will probably confuse sashiko but as discussed above
the chances of Sashiko spotting new stuff at this point should be low
anyway.  Prior to the LLMs becoming useful we used to do this sort
of partial series being merged a lot. It's less common now as we
loose bot coverage.

Thanks,

Jonathan

> 
> Best regards,
> Ariana
> 
>