linux-kernel - RE: [PATCH v3 11/12] PCI: exynos: Add support for Tesla FSD SoC

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: <00b401dc10fb$11bb1020$35313060$@samsung.com>
Date: Tue, 19 Aug 2025 16:48:59 +0530
From: "Shradha Todi" <shradha.t@...sung.com>
To: "'Krzysztof Kozlowski'" <krzk@...nel.org>, "'Bjorn Helgaas'"
	<helgaas@...nel.org>, "'Krzysztof Kozlowski'"
	<krzysztof.kozlowski@...aro.org>
Cc: <linux-pci@...r.kernel.org>, <devicetree@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-samsung-soc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-phy@...ts.infradead.org>,
	<mani@...nel.org>, <lpieralisi@...nel.org>, <kwilczynski@...nel.org>,
	<robh@...nel.org>, <bhelgaas@...gle.com>, <jingoohan1@...il.com>,
	<krzk+dt@...nel.org>, <conor+dt@...nel.org>, <alim.akhtar@...sung.com>,
	<vkoul@...nel.org>, <kishon@...nel.org>, <arnd@...db.de>,
	<m.szyprowski@...sung.com>, <jh80.chung@...sung.com>,
	<pankaj.dubey@...sung.com>
Subject: RE: [PATCH v3 11/12] PCI: exynos: Add support for Tesla FSD SoC



> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@...nel.org>
> Sent: 19 August 2025 12:04
> To: Bjorn Helgaas <helgaas@...nel.org>; Shradha Todi <shradha.t@...sung.com>; Krzysztof
> Kozlowski <krzysztof.kozlowski@...aro.org>
> Cc: linux-pci@...r.kernel.org; devicetree@...r.kernel.org; linux-arm-kernel@...ts.infradead.org;
> linux-samsung-soc@...r.kernel.org; linux-kernel@...r.kernel.org; linux-phy@...ts.infradead.org;
> mani@...nel.org; lpieralisi@...nel.org; kwilczynski@...nel.org; robh@...nel.org;
> bhelgaas@...gle.com; jingoohan1@...il.com; krzk+dt@...nel.org; conor+dt@...nel.org;
> alim.akhtar@...sung.com; vkoul@...nel.org; kishon@...nel.org; arnd@...db.de;
> m.szyprowski@...sung.com; jh80.chung@...sung.com; pankaj.dubey@...sung.com
> Subject: Re: [PATCH v3 11/12] PCI: exynos: Add support for Tesla FSD SoC
> 
> On 18/08/2025 20:25, Bjorn Helgaas wrote:
> > [+to Krzysztof]
> >
> > On Mon, Aug 18, 2025 at 03:00:00PM +0530, Shradha Todi wrote:
> >>> On Mon, Aug 11, 2025 at 09:16:37PM +0530, Shradha Todi wrote:
> >>>> Add host and endpoint controller driver support for FSD SoC.
> >
> >>> It's kind of unfortunate that the driver uses "ep" everywhere for
> >>> struct exynos_pcie pointers.  It's going to be confusing because "ep"
> >>> is also commonly used for endpoint-related things, e.g., struct
> >>> dw_pcie_ep pointers.  Maybe it's not worth changing; I dunno.
> >>
> >> I did try to rename the structure and the pointers
> >> (https://lore.kernel.org/all/20230214121333.1837-9-shradha.t@samsung.com/)
> >> But the intention was different back then and so the idea was rejected.
> >> I could add a patch to only rename the pointers to something less
> >> confusing like "exy_pci"
> >
> > The patch you mention did several renames:
> >
> >   s/to_exynos_pcie/to_samsung_pcie/
> >   s/struct exynos_pcie/struct samsung_pcie/
> >   s/struct exynos_pcie *ep/struct samsung_pcie *sp/
> >
> > I'm only concerned about the confusion of "ep" being used both for
> > "struct exynos_pcie *" and for "struct dw_pcie_ep *".
> >
> > It would still be sort of an annoying patch to do something like this:
> >
> >   s/struct exynos_pcie *ep/struct exynos_pcie *pcie/
> >
> > But 'git grep "struct .*_pcie \*.*=" drivers/pci/controller/' says
> > using "pcie" in this way is quite common, so maybe it would be worth
> > doing.
> >
> > What do you think, Krzysztof?
> 
> I think you want other Krzysztof, but nevertheless, the reasoning there
> "Changing it to samsung_pcie for making it
> generic."
> is wrong. The naming of these structures do not matter, they are not
> less generic. This is rather churn, which will affect backporting for
> ZERO readability increase. Why zero? Because calling all this "exynos"
> is the same as calling all this "samsung". It just does not matter.
> 
> However s/ep/pcie/ in variable name makes sense if that's more common.
> 

I will add a patch in the series to do that.

> 
> Best regards,
> Krzysztof