diff mbox series

[v3,2/6] nvme: assign of_node to nvme device

Message ID 20240806114118.17198-3-ansuelsmth@gmail.com
State New
Headers show
Series mtd: improve block2mtd + airoha parser | expand

Commit Message

Christian Marangi Aug. 6, 2024, 11:41 a.m. UTC
Introduce support for a dedicated node for a nvme card. This will be a
subnode of the nvme controller node that will have the "nvme-card"
compatible.

This follow a similar implementation done for mmc where the specific mmc
card have a dedicated of_node.

This can be used for scenario where block2mtd module is used to declare
partition in DT and block2mtd is called on the root block of the nvme
card, permitting the usage of fixed-partition parser or alternative
ones.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
 drivers/nvme/host/core.c | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Christoph Hellwig Aug. 6, 2024, 12:43 p.m. UTC | #1
On Tue, Aug 06, 2024 at 01:41:12PM +0200, Christian Marangi wrote:
> Introduce support for a dedicated node for a nvme card. This will be a
> subnode of the nvme controller node that will have the "nvme-card"
> compatible.
> 
> This follow a similar implementation done for mmc where the specific mmc
> card have a dedicated of_node.
> 
> This can be used for scenario where block2mtd module is used to declare
> partition in DT and block2mtd is called on the root block of the nvme
> card, permitting the usage of fixed-partition parser or alternative
> ones.

Err, hell no.  Why would you wire up a purely PCIe device to OF?
PCIe is self-discovering.
Christian Marangi Aug. 6, 2024, 1:03 p.m. UTC | #2
On Tue, Aug 06, 2024 at 02:43:12PM +0200, Christoph Hellwig wrote:
> On Tue, Aug 06, 2024 at 01:41:12PM +0200, Christian Marangi wrote:
> > Introduce support for a dedicated node for a nvme card. This will be a
> > subnode of the nvme controller node that will have the "nvme-card"
> > compatible.
> > 
> > This follow a similar implementation done for mmc where the specific mmc
> > card have a dedicated of_node.
> > 
> > This can be used for scenario where block2mtd module is used to declare
> > partition in DT and block2mtd is called on the root block of the nvme
> > card, permitting the usage of fixed-partition parser or alternative
> > ones.
> 
> Err, hell no.  Why would you wire up a purely PCIe device to OF?
> PCIe is self-discovering.
>

Well on embedded pure PCIe card most of the time are not a thing...
Unless it's an enterprise product, everything is integrated in the pcb
and not detachable for cost saving measure or also if the thing use PCIe
protocol but it tighlty coupled with the SoC.

This implementation is already very common for all kind of pcie devices
like wireless card, gpio expander that are integrated in the PCB and
require property in DT like calibration data, quirks or GPIO pin
definitions, i2c...

In modern SoC we are seeing an influx of using cheap flash storage
option instead of NAND or NOR as modern hw require more space and price
increase is not that high... Almost any high tier device is switching to
using emmc and even attached NVME and simulating MTD with them for easy
usage.

Please consider this well used scenario in emebedded where PCIe is just
a comunication way and the concept of detachable doesn't exist at all
and things can be described in DT as static. Also these storage are used
for rootfs mount so userspace is not so viable.
Christoph Hellwig Aug. 6, 2024, 1:09 p.m. UTC | #3
On Tue, Aug 06, 2024 at 03:03:24PM +0200, Christian Marangi wrote:
> Well on embedded pure PCIe card most of the time are not a thing...
> Unless it's an enterprise product, everything is integrated in the pcb
> and not detachable for cost saving measure or also if the thing use PCIe
> protocol but it tighlty coupled with the SoC.

Yes, PCIe has a bunch of form factors, including just soldered on BGA
devices, but none of that matters at all for the logical protocol.

> This implementation is already very common for all kind of pcie devices
> like wireless card, gpio expander that are integrated in the PCB and
> require property in DT like calibration data, quirks or GPIO pin
> definitions, i2c...

Do you have a document on that/
Christian Marangi Aug. 6, 2024, 1:26 p.m. UTC | #4
On Tue, Aug 06, 2024 at 03:09:38PM +0200, Christoph Hellwig wrote:
> On Tue, Aug 06, 2024 at 03:03:24PM +0200, Christian Marangi wrote:
> > Well on embedded pure PCIe card most of the time are not a thing...
> > Unless it's an enterprise product, everything is integrated in the pcb
> > and not detachable for cost saving measure or also if the thing use PCIe
> > protocol but it tighlty coupled with the SoC.
> 
> Yes, PCIe has a bunch of form factors, including just soldered on BGA
> devices, but none of that matters at all for the logical protocol.
>

Correct, for the context of soldered stuff tho things can be
malfunctioning (problem in the PCIe driver) or working so it's possibile
to make assumption and attach OF node in DT. Consider that the thing is
probed only if the card is correctly detected. Card not present ->
nothing is done.

> > This implementation is already very common for all kind of pcie devices
> > like wireless card, gpio expander that are integrated in the PCB and
> > require property in DT like calibration data, quirks or GPIO pin
> > definitions, i2c...
> 
> Do you have a document on that/
> 

You mean example of PCIe that makes use of OF? Pretty much ath10k-11k
mediatek and in general all wireless card. Example ath11k-pci.yaml [1]

Compatible is set to the ID. PCIe will attach an OF node if found in the
pcie child nodes (already supported)

On NVMe driver side, the NVMe controller will already have an OF node
present.

We are now just adding an additional subnode "nvme-card" and attach it
on the root disk when it's created.

[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/wireless/qcom%2Cath11k-pci.yaml
Dragan Simic Aug. 6, 2024, 3:39 p.m. UTC | #5
Hello all,

On 2024-08-06 15:03, Christian Marangi wrote:
> On Tue, Aug 06, 2024 at 02:43:12PM +0200, Christoph Hellwig wrote:
>> On Tue, Aug 06, 2024 at 01:41:12PM +0200, Christian Marangi wrote:
>> > Introduce support for a dedicated node for a nvme card. This will be a
>> > subnode of the nvme controller node that will have the "nvme-card"
>> > compatible.
>> >
>> > This follow a similar implementation done for mmc where the specific mmc
>> > card have a dedicated of_node.
>> >
>> > This can be used for scenario where block2mtd module is used to declare
>> > partition in DT and block2mtd is called on the root block of the nvme
>> > card, permitting the usage of fixed-partition parser or alternative
>> > ones.
>> 
>> Err, hell no.  Why would you wire up a purely PCIe device to OF?
>> PCIe is self-discovering.
>> 
> 
> Well on embedded pure PCIe card most of the time are not a thing...
> Unless it's an enterprise product, everything is integrated in the pcb
> and not detachable for cost saving measure or also if the thing use 
> PCIe
> protocol but it tighlty coupled with the SoC.
> 
> This implementation is already very common for all kind of pcie devices
> like wireless card, gpio expander that are integrated in the PCB and
> require property in DT like calibration data, quirks or GPIO pin
> definitions, i2c...
> 
> In modern SoC we are seeing an influx of using cheap flash storage
> option instead of NAND or NOR as modern hw require more space and price
> increase is not that high... Almost any high tier device is switching 
> to
> using emmc and even attached NVME and simulating MTD with them for easy
> usage.
> 
> Please consider this well used scenario in emebedded where PCIe is just
> a comunication way and the concept of detachable doesn't exist at all
> and things can be described in DT as static. Also these storage are 
> used
> for rootfs mount so userspace is not so viable.

As a note, perhaps this is another good example of a "fixed layout"
PCIe device found on an SBC:

https://lore.kernel.org/linux-rockchip/20240805073425.3492078-1-jacobe.zang@wesion.com/T/#u
diff mbox series

Patch

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 053d5b4909cd..344523274d1b 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -14,6 +14,7 @@ 
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/backing-dev.h>
+#include <linux/of.h>
 #include <linux/slab.h>
 #include <linux/types.h>
 #include <linux/pr.h>
@@ -4651,6 +4652,7 @@  void nvme_uninit_ctrl(struct nvme_ctrl *ctrl)
 	nvme_hwmon_exit(ctrl);
 	nvme_fault_inject_fini(&ctrl->fault_inject);
 	dev_pm_qos_hide_latency_tolerance(ctrl->device);
+	of_node_put(ctrl->device->of_node);
 	cdev_device_del(&ctrl->cdev, ctrl->device);
 	nvme_put_ctrl(ctrl);
 }
@@ -4771,6 +4773,8 @@  int nvme_init_ctrl(struct nvme_ctrl *ctrl, struct device *dev,
 	else
 		ctrl->device->groups = nvme_dev_attr_groups;
 	ctrl->device->release = nvme_free_ctrl;
+	ctrl->device->of_node = of_get_compatible_child(ctrl->dev->of_node,
+							"nvme-card");
 	dev_set_drvdata(ctrl->device, ctrl);
 
 	return ret;