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

[David Lechner]

On 2/16/26 11:34 AM, Conor Dooley wrote:
> On Mon, Feb 16, 2026 at 09:37:35AM -0600, David Lechner wrote:
>> On 2/16/26 7:31 AM, Ariana.Lazar@xxxxxxxxxxxxx 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@xxxxxxxxxxxxx>
>>>>>
>>>>> 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.
> 
> These usually have merged bindings too, right? Only real difference is
> going to be that the spi devices will need
> spi-peripheral-properties.yaml which obviously the i2c ones wont.

Correct.