lkml.org 
[lkml]   [2024]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Implementation of fwnode_operations :: device_get_match_data() for software nodes?
    Hi Vladimir,

    +Cc: Rob, Lizhi and Luca.

    On Mon, 25 Mar 2024 15:41:19 +0200
    Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

    > +Cc: people who might be also interested in this topic.
    >
    ..
    > >
    > > I agree we don't want to have multiple approaches of doing the same thing,
    > > but I debate whether I am really doing the same thing?
    > >
    > > If software nodes are not designed to be a good fit for my kind of use
    > > case, then what are they designed for?
    >
    > I think the hardware should be described in the respective format. Yet, you
    > have a point that it's too verbose to the cases when we know the layout of
    > the attached (not-hotpluggable) devices.
    >
    > There are discussions [1,2] on how to enable DT for the cases when
    > non-discoverable HW needs to be detected and enumerated.
    >
    > I don't know which solution will eventually be accepted, but my personal
    > opinion here that we would like to distantiate from board files as much
    > as possible.
    >
    > Btw, for the internal (board files) code we may also use property to
    > go with (see how spi-pxa2xx uses that) to distinguish configurations.
    > But it might be not that straight as with driver data.
    >
    > So far, I haven't seen the code (am I mistaken?) which makes use of driver data
    > for software nodes.
    >
    > [1]: https://lore.kernel.org/lkml/20231128084236.157152-1-wenst@chromium.org/
    > [2]: https://lore.kernel.org/lkml/1692120000-46900-1-git-send-email-lizhi.hou@amd.com/
    >
    > Aux topics which might not directly be related (in order of declining relevance
    > from my p.o.v.):
    > https://lore.kernel.org/lkml/20231130165700.685764-1-herve.codina@bootlin.com/
    > https://lore.kernel.org/lkml/DM6PR12MB3993D5ECA50B27682AEBE19FCD67A@DM6PR12MB3993.namprd12.prod.outlook.com/
    > https://lore.kernel.org/lkml/20240217010557.2381548-1-sboyd@kernel.org/
    >

    I work on PCI DT overlay support.
    The idea is to have a PCI driver that loads a DT overlay to describe the
    hardware embedded in the related PCI device. Some features related to this
    topic are already upstream.

    Rob did a presentation of this topic at the Linux Plumber conference last
    year (https://www.youtube.com/watch?v=MVGElnZW7BQ).

    IMHO, your use-case is pretty much the same. Of course it is not a PCI
    device but a SPI device. Even if the device beyond the SPI bus cannot be
    memory mapped, the idea seems pretty much the same: describe the hardware
    embedded in a specific device.

    You mentioned that you need the '-@' option when you compile your base dtb.
    In fact, it depends on the resources you need to reference from your overlay.
    On my case (DT overlay to describe a PCI device), I don't need any references
    to a base dtb from the overlay. I don't need to use the '-@' option.
    Even more, I started (not yet upstream) to use all of this feature on an ACPI
    base system and it works.

    My PCI device is a Microchip LAN9662 PCI device.
    The Microchip LAN9962 can be a "traditional" SoC with CPU cores and several
    IPs but also a PCI device.
    When provided as a PCI device, the internal CPU cores are no more available
    and replaced by a PCI endpoint IP.
    All the accesses done by the SoC CPU cores are replaced by accesses done by
    the host PCI system through the PCI endpoint.
    Drivers were already present upstream (traditional SoC platform driver such
    as i2c mdio, clock, switch, ...) and are used without any modifications for
    the PCI device.
    All the wiring (mapping) between the PCI world and the internal device
    hardware is done using a DT overlay.

    Best regards,
    Hervé

    --
    Hervé Codina, Bootlin
    Embedded Linux and Kernel engineering
    https://bootlin.com

    \
     
     \ /
      Last update: 2024-05-27 16:07    [W:7.760 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site