Re: [PATCH 1/2] dt-bindings: iio: dac: add support for Microchip MCP48FEB02

[David Lechner <dlechner@baylibre.com>]

On 2/16/26 7:31 AM, Ariana.Lazar@microchip.com wrote:
> Hi all,
> 
> Thank you for your reviews.
> 
> 
> On Thu, 2026-02-12 at 22:04 +0200, Andy Shevchenko wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you
>> know the content is safe
>>
>> On Thu, Feb 12, 2026 at 06:00:06PM +0000, Conor Dooley wrote:
>>> On Thu, Feb 12, 2026 at 02:48:34PM +0200, Ariana Lazar wrote:
>>>> This is the device tree schema for iio driver for Microchip
>>>> MCP48FxBy1/2/4/8 series of buffered voltage output Digital-to-
>>>> Analog
>>>> Converters with nonvolatile or volatile memory and an SPI
>>>> Interface.
>>>>
>>>> The families support up to 8 output channels.
>>>>
>>>> The devices can be 8-bit, 10-bit and 12-bit.
>>>>
>>>> Signed-off-by: Ariana Lazar <ariana.lazar@microchip.com>
>>>
>>> Other than the interface, what's actually different between this
>>> and the
>>> 47? Could they share the same binding?
>>
>> If that is the case, I don't think we even need a brand new driver,
>> the
>> existing one should be refactored to adapt SPI interface.
>>
>> --
>> With Best Regards,
>> Andy Shevchenko
>>
>>
> 
> 
> I have decided to submit two separate drivers, even though the chips
> share similar functionality, in order to make it easier for the client
> to identify the supported chips.
> 
> For example the I2C family of devices has: 3 different resolutions,
> with 4 different channel numbers available for a particular part and
> most important you can get the same part with or without EEPROM.
> That means the I2C driver will cover 24 different devices. The SPI
> family follows the same pattern, covering another 24 devices.
> 
> Microchip also has some devices (I2C and SPI) with Nonvolatile Memory
> (similar to EEPROM but limited to fewer than 32 writes) and I want to
> add these families to the existing drivers while maintaining the split
> by interface.
> 
> Please tell me if you have anything against this approach (having 2
> different drivers split based on interface and each of them to support
> at least 24 different part numbers).
> 
> Best regards,
> Ariana

The usual way we support parts with the same register map that can have
an I2C or a SPI bus it to make three modules: <name>_core.c, <name>_i2c.c
and <name>_spi.c. If you look through the iio folders, you will see many
drivers like this.

The _i2c.c and _spi.c files will just contain the chip info tables that
contain all of the differences between the chips and pass that to a
common probe function in the _core.c module.

It seems like this approach should work in your case as well.