From: Nicolas Ferre <nicolas.ferre@microchip.com> To: Conor Dooley <conor@kernel.org>, Arnd Bergmann <arnd@arndb.de> Cc: Varshini Rajendran <varshini.rajendran@microchip.com>, Thomas Gleixner <tglx@linutronix.de>, Marc Zyngier <maz@kernel.org>, Rob Herring <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Alexandre Belloni <alexandre.belloni@bootlin.com>, Claudiu Beznea <claudiu.beznea@microchip.com>, "David S . Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Russell King <linux@armlinux.org.uk>, "Michael Turquette" <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Sebastian Reichel <sre@kernel.org>, Mark Brown <broonie@kernel.org>, "Gregory Clement" <gregory.clement@bootlin.com>, Sudeep Holla <sudeep.holla@arm.com>, Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>, <mihai.sain@microchip.com>, <linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, Netdev <netdev@vger.kernel.org>, <linux-usb@vger.kernel.org>, <linux-clk@vger.kernel.org>, <linux-pm@vger.kernel.org>, <Hari.PrasathGE@microchip.com>, <cristian.birsan@microchip.com>, <durai.manickamkr@microchip.com>, <manikandan.m@microchip.com>, <dharma.b@microchip.com>, <nayabbasha.sayed@microchip.com>, <balakrishnan.s@microchip.com> Subject: Re: [PATCH 15/21] dt-bindings: irqchip/atmel-aic5: Add support for sam9x7 aic Date: Mon, 5 Jun 2023 14:37:16 +0200 [thread overview] Message-ID: <add5e49e-8416-ba9f-819a-da944938c05f@microchip.com> (raw) In-Reply-To: <20230604-cohesive-unmoving-032da3272620@spud> Arnd, Conor, On 04/06/2023 at 23:08, Conor Dooley wrote: > On Sun, Jun 04, 2023 at 11:49:48AM +0200, Arnd Bergmann wrote: >> On Sat, Jun 3, 2023, at 23:23, Conor Dooley wrote: >>> On Sat, Jun 03, 2023 at 10:19:50PM +0100, Conor Dooley wrote: >>>> Hey Varshini, >>>> >>>> On Sun, Jun 04, 2023 at 01:32:37AM +0530, Varshini Rajendran wrote: >>>>> Document the support added for the Advanced interrupt controller(AIC) >>>>> chip in the sam9x7 soc family >>>> Please do not add new family based compatibles, but rather use per-soc >>>> compatibles instead. >>> These things leave me penally confused. Afaiu, sam9x60 is a particular > s/penally/perennially/ > >>> SoC. sam9x7 is actually a family, containing sam9x70, sam9x72 and >>> sam9x75. It would appear to me that each should have its own compatible, >>> no? >> I think the usual way this works is that the sam9x7 refers to the >> SoC design as in what is actually part of the chip, whereas the 70, >> 72 and 75 models are variants that have a certain subset of the >> features enabled. Yes, That's the case. >> If that is the case here, then referring to the on-chip parts by >> the sam9x7 name makes sense, and this is similar to what we do >> on TI AM-series chips. This is what we did for most of our SoCs families, indeed. > If it is the case that what differentiates them is having bits chopped > off, and there's no implementation differences that seems fair. Ok, thanks. >> There is a remaining risk that a there would be a future >> sam9x71/73/74/76/... product based on a new chip that uses >> incompatible devices, but at that point we can still use the >> more specific model number to identify those without being >> ambiguous. This is exactly what we did for sama5d29 which is not the same silicon vs. the other members of the sama5d2 family. We used the more specify sama5d29 sub-string for describing the changing parts (CAN-FD and Ethernet). >> The same thing can of course happen when a SoC >> vendor reuses a specific name of a prior product with an update >> chip that has software visible changes. >> >> I'd just leave this up to Varshini and the other at91 maintainers >> here, provided they understand the exact risks. Yep, I understand the risk and will try to review the compatibility strings that would need more precise description (maybe PMC or AIC). > Ye, seems fair to me. Nicolas/Claudiu etc, is there a convention to use > the "0" model as the compatible (like the 9x60 did) or have "random" > things been done so far? sam9x60 was a single SoC, not a member of a "family", so there was no meaning of the "0" here. Moreover, the "0" ones are usually not the subset, if it even exists. So far, we used the silicon string to define the compatibility string, adding a more precise string for hardware of family members that needed it (as mentioned above for sama5d29). >> It's different for the parts that are listed as just sam9x60 >> compatible in the DT, I think those clearly need to have sam9x7 >> in the compatible list, but could have the sam9x60 identifier >> as a fallback if the hardware is compatible. > Aye. Yep, agreed. Thanks for your help. Best regards, Nicolas -- Nicolas Ferre
WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Ferre <nicolas.ferre@microchip.com> To: Conor Dooley <conor@kernel.org>, Arnd Bergmann <arnd@arndb.de> Cc: Varshini Rajendran <varshini.rajendran@microchip.com>, Thomas Gleixner <tglx@linutronix.de>, Marc Zyngier <maz@kernel.org>, Rob Herring <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Alexandre Belloni <alexandre.belloni@bootlin.com>, Claudiu Beznea <claudiu.beznea@microchip.com>, "David S . Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Russell King <linux@armlinux.org.uk>, "Michael Turquette" <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Sebastian Reichel <sre@kernel.org>, Mark Brown <broonie@kernel.org>, "Gregory Clement" <gregory.clement@bootlin.com>, Sudeep Holla <sudeep.holla@arm.com>, Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>, <mihai.sain@microchip.com>, <linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, Netdev <netdev@vger.kernel.org>, <linux-usb@vger.kernel.org>, <linux-clk@vger.kernel.org>, <linux-pm@vger.kernel.org>, <Hari.PrasathGE@microchip.com>, <cristian.birsan@microchip.com>, <durai.manickamkr@microchip.com>, <manikandan.m@microchip.com>, <dharma.b@microchip.com>, <nayabbasha.sayed@microchip.com>, <balakrishnan.s@microchip.com> Subject: Re: [PATCH 15/21] dt-bindings: irqchip/atmel-aic5: Add support for sam9x7 aic Date: Mon, 5 Jun 2023 14:37:16 +0200 [thread overview] Message-ID: <add5e49e-8416-ba9f-819a-da944938c05f@microchip.com> (raw) In-Reply-To: <20230604-cohesive-unmoving-032da3272620@spud> Arnd, Conor, On 04/06/2023 at 23:08, Conor Dooley wrote: > On Sun, Jun 04, 2023 at 11:49:48AM +0200, Arnd Bergmann wrote: >> On Sat, Jun 3, 2023, at 23:23, Conor Dooley wrote: >>> On Sat, Jun 03, 2023 at 10:19:50PM +0100, Conor Dooley wrote: >>>> Hey Varshini, >>>> >>>> On Sun, Jun 04, 2023 at 01:32:37AM +0530, Varshini Rajendran wrote: >>>>> Document the support added for the Advanced interrupt controller(AIC) >>>>> chip in the sam9x7 soc family >>>> Please do not add new family based compatibles, but rather use per-soc >>>> compatibles instead. >>> These things leave me penally confused. Afaiu, sam9x60 is a particular > s/penally/perennially/ > >>> SoC. sam9x7 is actually a family, containing sam9x70, sam9x72 and >>> sam9x75. It would appear to me that each should have its own compatible, >>> no? >> I think the usual way this works is that the sam9x7 refers to the >> SoC design as in what is actually part of the chip, whereas the 70, >> 72 and 75 models are variants that have a certain subset of the >> features enabled. Yes, That's the case. >> If that is the case here, then referring to the on-chip parts by >> the sam9x7 name makes sense, and this is similar to what we do >> on TI AM-series chips. This is what we did for most of our SoCs families, indeed. > If it is the case that what differentiates them is having bits chopped > off, and there's no implementation differences that seems fair. Ok, thanks. >> There is a remaining risk that a there would be a future >> sam9x71/73/74/76/... product based on a new chip that uses >> incompatible devices, but at that point we can still use the >> more specific model number to identify those without being >> ambiguous. This is exactly what we did for sama5d29 which is not the same silicon vs. the other members of the sama5d2 family. We used the more specify sama5d29 sub-string for describing the changing parts (CAN-FD and Ethernet). >> The same thing can of course happen when a SoC >> vendor reuses a specific name of a prior product with an update >> chip that has software visible changes. >> >> I'd just leave this up to Varshini and the other at91 maintainers >> here, provided they understand the exact risks. Yep, I understand the risk and will try to review the compatibility strings that would need more precise description (maybe PMC or AIC). > Ye, seems fair to me. Nicolas/Claudiu etc, is there a convention to use > the "0" model as the compatible (like the 9x60 did) or have "random" > things been done so far? sam9x60 was a single SoC, not a member of a "family", so there was no meaning of the "0" here. Moreover, the "0" ones are usually not the subset, if it even exists. So far, we used the silicon string to define the compatibility string, adding a more precise string for hardware of family members that needed it (as mentioned above for sama5d29). >> It's different for the parts that are listed as just sam9x60 >> compatible in the DT, I think those clearly need to have sam9x7 >> in the compatible list, but could have the sam9x60 identifier >> as a fallback if the hardware is compatible. > Aye. Yep, agreed. Thanks for your help. Best regards, Nicolas -- Nicolas Ferre _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-06-05 12:38 UTC|newest] Thread overview: 122+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-06-03 20:02 [PATCH 00/21] Add support for sam9x7 SoC family Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-03 20:02 ` [PATCH 01/21] dt-bindings: microchip: atmel,at91rm9200-tcb: add sam9x60 compatible Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-05 6:35 ` Krzysztof Kozlowski 2023-06-05 6:35 ` Krzysztof Kozlowski 2023-06-05 7:04 ` Arnd Bergmann 2023-06-05 7:04 ` Arnd Bergmann 2023-06-05 7:34 ` Krzysztof Kozlowski 2023-06-05 7:34 ` Krzysztof Kozlowski 2023-06-05 12:03 ` Nicolas Ferre 2023-06-05 12:03 ` Nicolas Ferre 2023-06-14 19:37 ` Rob Herring 2023-06-14 19:37 ` Rob Herring 2023-06-03 20:02 ` [PATCH 02/21] dt-bindings: usb: ehci: Add atmel at91sam9g45-ehci compatible Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-14 19:38 ` Rob Herring 2023-06-14 19:38 ` Rob Herring 2023-06-03 20:02 ` [PATCH 03/21] dt-bindings: usb: generic-ehci: Document clock-names property Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-03 21:15 ` Conor Dooley 2023-06-03 21:15 ` Conor Dooley 2023-06-05 12:54 ` Nicolas Ferre 2023-06-05 12:54 ` Nicolas Ferre 2023-06-05 6:36 ` Krzysztof Kozlowski 2023-06-05 6:36 ` Krzysztof Kozlowski 2023-06-03 20:02 ` [PATCH 04/21] ARM: dts: at91: sam9x7: add device tree for soc Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-03 21:35 ` Conor Dooley 2023-06-03 21:35 ` Conor Dooley 2023-06-05 6:39 ` Krzysztof Kozlowski 2023-06-05 6:39 ` Krzysztof Kozlowski 2023-06-05 6:41 ` Krzysztof Kozlowski 2023-06-05 6:41 ` Krzysztof Kozlowski 2023-06-09 5:35 ` Dharma.B 2023-06-09 5:35 ` Dharma.B 2023-06-15 7:36 ` Claudiu.Beznea 2023-06-15 7:36 ` Claudiu.Beznea 2023-06-03 20:02 ` [PATCH 05/21] ARM: configs: at91: enable config flags for sam9x7 SoC Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-03 20:02 ` [PATCH 06/21] ARM: configs: at91: add mcan support Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-05 6:40 ` Krzysztof Kozlowski 2023-06-05 6:40 ` Krzysztof Kozlowski 2023-06-03 20:02 ` [PATCH 07/21] ARM: configs: at91: Enable csi and isc support Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-03 20:02 ` [PATCH 08/21] ARM: at91: pm: add support for sam9x7 soc family Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-15 7:42 ` Claudiu.Beznea 2023-06-15 7:42 ` Claudiu.Beznea 2023-06-03 20:02 ` [PATCH 09/21] ARM: at91: pm: add sam9x7 soc init config Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-15 7:43 ` Claudiu.Beznea 2023-06-15 7:43 ` Claudiu.Beznea 2023-06-03 20:02 ` [PATCH 10/21] ARM: at91: Kconfig: add config flag for SAM9X7 SoC Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-15 7:46 ` Claudiu.Beznea 2023-06-15 7:46 ` Claudiu.Beznea 2023-06-03 20:02 ` [PATCH 11/21] ARM: at91: add support in soc driver for new sam9x7 Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-15 7:48 ` Claudiu.Beznea 2023-06-15 7:48 ` Claudiu.Beznea 2023-06-03 20:02 ` [PATCH 12/21] clk: at91: clk-sam9x60-pll: re-factor to support individual core freq outputs Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-15 7:54 ` Claudiu.Beznea 2023-06-15 7:54 ` Claudiu.Beznea 2023-06-03 20:02 ` [PATCH 13/21] clk: at91: sam9x7: add support for HW PLL freq dividers Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-15 8:00 ` Claudiu.Beznea 2023-06-15 8:00 ` Claudiu.Beznea 2023-06-03 20:02 ` [PATCH 14/21] clk: at91: sam9x7: add sam9x7 pmc driver Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-04 18:00 ` Simon Horman 2023-06-04 18:00 ` Simon Horman 2023-06-15 8:39 ` Claudiu.Beznea 2023-06-15 8:39 ` Claudiu.Beznea 2023-06-03 20:02 ` [PATCH 15/21] dt-bindings: irqchip/atmel-aic5: Add support for sam9x7 aic Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-03 21:19 ` Conor Dooley 2023-06-03 21:19 ` Conor Dooley 2023-06-03 21:23 ` Conor Dooley 2023-06-03 21:23 ` Conor Dooley 2023-06-04 9:49 ` Arnd Bergmann 2023-06-04 21:08 ` Conor Dooley 2023-06-05 12:37 ` Nicolas Ferre [this message] 2023-06-05 12:37 ` Nicolas Ferre 2023-06-14 19:41 ` Rob Herring 2023-06-14 19:41 ` Rob Herring 2023-06-03 20:02 ` [PATCH 16/21] " Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-03 20:02 ` [PATCH 17/21] power: reset: at91-poweroff: lookup for proper pmc dt node for sam9x7 Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-05 6:43 ` Krzysztof Kozlowski 2023-06-05 6:43 ` Krzysztof Kozlowski 2023-06-05 13:04 ` Nicolas Ferre 2023-06-05 13:04 ` Nicolas Ferre 2023-06-05 13:26 ` Conor Dooley 2023-06-05 13:26 ` Conor Dooley 2023-06-16 17:32 ` Varshini.Rajendran 2023-06-16 17:32 ` Varshini.Rajendran 2023-06-05 13:33 ` Krzysztof Kozlowski 2023-06-05 13:33 ` Krzysztof Kozlowski 2023-06-03 20:02 ` [PATCH 18/21] power: reset: at91-reset: add reset support for sam9x7 soc Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-03 20:02 ` [PATCH 19/21] power: reset: at91-reset: add sdhwc " Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-03 20:02 ` [PATCH 20/21] dt-bindings: net: cdns,macb: add documentation for sam9x7 ethernet interface Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-05 6:42 ` Krzysztof Kozlowski 2023-06-05 6:42 ` Krzysztof Kozlowski 2023-06-14 19:42 ` Rob Herring 2023-06-14 19:42 ` Rob Herring 2023-06-03 20:02 ` [PATCH 21/21] net: macb: add support for gmac to sam9x7 Varshini Rajendran 2023-06-03 20:02 ` Varshini Rajendran 2023-06-05 6:42 ` Krzysztof Kozlowski 2023-06-05 6:42 ` Krzysztof Kozlowski 2023-06-05 12:07 ` Nicolas Ferre 2023-06-05 12:07 ` Nicolas Ferre 2023-06-05 12:21 ` Arnd Bergmann 2023-06-05 12:21 ` Arnd Bergmann 2023-06-05 13:34 ` Krzysztof Kozlowski 2023-06-05 13:34 ` Krzysztof Kozlowski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=add5e49e-8416-ba9f-819a-da944938c05f@microchip.com \ --to=nicolas.ferre@microchip.com \ --cc=Hari.PrasathGE@microchip.com \ --cc=alexandre.belloni@bootlin.com \ --cc=arnd@arndb.de \ --cc=balakrishnan.s@microchip.com \ --cc=balamanikandan.gunasundar@microchip.com \ --cc=broonie@kernel.org \ --cc=claudiu.beznea@microchip.com \ --cc=conor+dt@kernel.org \ --cc=conor@kernel.org \ --cc=cristian.birsan@microchip.com \ --cc=davem@davemloft.net \ --cc=devicetree@vger.kernel.org \ --cc=dharma.b@microchip.com \ --cc=durai.manickamkr@microchip.com \ --cc=edumazet@google.com \ --cc=gregkh@linuxfoundation.org \ --cc=gregory.clement@bootlin.com \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=kuba@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-clk@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=manikandan.m@microchip.com \ --cc=maz@kernel.org \ --cc=mihai.sain@microchip.com \ --cc=mturquette@baylibre.com \ --cc=nayabbasha.sayed@microchip.com \ --cc=netdev@vger.kernel.org \ --cc=pabeni@redhat.com \ --cc=robh+dt@kernel.org \ --cc=sboyd@kernel.org \ --cc=sre@kernel.org \ --cc=sudeep.holla@arm.com \ --cc=tglx@linutronix.de \ --cc=varshini.rajendran@microchip.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.