linux-kernel - Re: [PATCH v3 1/6] dt-bindings: nvme: Document nvme-card compatible

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: <66b22260.050a0220.18f4fd.5a4d@mx.google.com>
Date: Tue, 6 Aug 2024 15:17:16 +0200
From: Christian Marangi <ansuelsmth@...il.com>
To: Christoph Hellwig <hch@....de>
Cc: Ulf Hansson <ulf.hansson@...aro.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Miquel Raynal <miquel.raynal@...tlin.com>,
	Richard Weinberger <richard@....at>,
	Vignesh Raghavendra <vigneshr@...com>,
	Joern Engel <joern@...ybastard.org>,
	Keith Busch <kbusch@...nel.org>, Jens Axboe <axboe@...nel.dk>,
	Sagi Grimberg <sagi@...mberg.me>,
	Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
	linux-mmc@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org,
	linux-nvme@...ts.infradead.org
Subject: Re: [PATCH v3 1/6] dt-bindings: nvme: Document nvme-card compatible

On Tue, Aug 06, 2024 at 03:00:03PM +0200, Christoph Hellwig wrote:
> I don't see how this works.  There is absolutely nothing nvme specific
> in there, and we really should not bring OF into NVMe.
>

Thing is that OF for PCIe devices is already a thing so NVMe already
have OF support. And that is totally OK if the PCIe is not removable.

So it's really a simple subnode to keep things organized in DT and
permit common code. Why this would be problematic, the implications of
adding support for this are really none, only additional support for the
new devices that are taking this path. (you would be surprised by the
amount of hacks they use downstream so about times to stabilize this the
correct way)

> > (alternative is to have in block2mtd all kind of extra logic with switch
> > case to check for major block ID that deviates from a common schema)
> 
> What common scheme?
> 

The emmc one and also nand attached to spi. They all follow this.

controller {
	card {
	};
};

-- 
	Ansuel