linux-kernel - Re: [PATCH 2/4] i3c: master: add Microchip SAMA7D65 I3C HCI master driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aMEgeHLnrDyGjYM3@shikoro>
Date: Wed, 10 Sep 2025 08:53:44 +0200
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: Durai.ManickamKR@...rochip.com
Cc: Frank.li@....com, linux-i3c@...ts.infradead.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	alexandre.belloni@...tlin.com, robh@...nel.org, krzk+dt@...nel.org,
	conor+dt@...nel.org, Balamanikandan.Gunasundar@...rochip.com,
	Nicolas.Ferre@...rochip.com
Subject: Re: [PATCH 2/4] i3c: master: add Microchip SAMA7D65 I3C HCI master
 driver

Hi Durai,

> 1. To introduce a Microchip SoC specific macro to add Microchip specific 
> I3C changes to the existing driver. But in this approach, if suppose we 
> have a changes in the i3c-hci driver, we have to adapt the changes to 
> our IP also during every kernel updation and I donot know whether this 
> is accepted by the i3c-hci driver maintainer.
> 
> 2. Otherwise, creating a separate platform driver by reusing the 
> existing i3c-hci driver.

Usually, 2) is the way to go for the reason you gave above. If there are
fixes to the core part, you don't need to sync with your driver.
Maintenance burden is lower for most of the times.

If the hardware is so different that the modifications to the core
driver turn out to be more complex (and harder to maintain) than a
seperate driver, then 1) can be an option.

Without knowing your hardware, from the description above I'd think you
can reuse the existing HCI core driver. It is mainly about not using
stuff like DMA. Maybe that can be handled with newly introduced quirk
flags.

> I raised a query few weeks back to decide which approach to proceed 
> before sending this patch to upstream. But i have received comments like 
> "its upto us to decide which is best way". I dont have much idea on 
> which is best way to proceed and maintain.So, I have decided to go with 
> approach 2.

Your patch looks like approach 1), though? You don't hook into the HCI
driver or am I overlooking this?

> >> Features tested and supported :
> >>     Standard CCC commands.
> >>     I3C SDR mode private transfers in PIO mode.
> >>     I2C transfers in PIO mode.
> >>     Pure bus mode and mixed bus mode.
> >>
> >> Signed-off-by: Durai Manickam KR <durai.manickamkr@...rochip.com>

Please delete lines you don't quote anymore (here, the whole driver).

Happy hacking,

   Wolfram