lkml.org 
[lkml]   [2022]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [RFC PATCH v2 2/6] bus/cdx: add the cdx bus driver
    From
    On 2022-08-25 19:38, Saravana Kannan wrote:
    > On Wed, Aug 24, 2022 at 4:31 PM Jason Gunthorpe <jgg@nvidia.com> wrote:
    >>
    >> On Wed, Aug 24, 2022 at 02:11:48PM +0200, Greg KH wrote:
    >>>> We can share the RFC in case you are interested in looking at code flow
    >>>> using the of_dynamic approach.
    >>>
    >>> Please no more abuse of the platform device.
    >>
    >> Last time this came up there was some disagreement from the ARM folks,
    >> they were not keen on having xx_drivers added all over the place to
    >> support the same OF/DT devices just discovered in a different way. It is
    >> why ACPI is mapped to platform_device even in some cases.
    >>
    >> I think if you push them down this path they will get resistance to
    >> get the needed additional xx_drivers into the needed places.
    >>
    >>> If your device can be discovered by scanning a bus, it is not a platform
    >>> device.
    >>
    >> A DT fragment loaded during boot binds a driver using a
    >> platform_driver, why should a DT fragment loaded post-boot bind using
    >> an XX_driver and further why should the CDX way of getting the DT
    >> raise to such importantance that it gets its own cdx_driver ?
    >>
    >> In the end the driver does not care about how the DT was loaded.
    >> None of these things are on a discoverable bus in any sense like PCI
    >> or otherwise. They are devices described by a DT fragement and they
    >> take all their parameters from that chunk of DT.
    >>
    >> How the DT was loaded into the system is not a useful distinction that
    >> raises the level of needing an entire new set of xx_driver structs all
    >> over the tree, IMHO.
    >
    > Jason, I see your point or rather the point the ARM folks might have
    > made. But in this case, why not use DT overlays to add these devices?
    > IIRC there's an in kernel API to add DT overlays. If so, should this
    > be more of a FPGA driver that reads FPGA stuff and adds DT overlays?
    > That'd at least make a stronger case for why this isn't a separate
    > bus.

    Right, that's exactly where this discussion started.

    To my mind, it would definitely help to understand if this is a *real*
    discoverable bus in hardware, i.e. does one have to configure one's
    device with some sort of CDX wrapper at FPGA synthesis time, that then
    physically communicates with some sort of CDX controller to identify
    itself once loaded; or is it "discoverable" in the sense that there's
    some firmware on an MCU controlling what gets loaded into the FPGA, and
    software can query that and get back whatever precompiled DTB fragment
    came bundled with the bitstream, i.e. it's really more like fpga-mgr in
    a fancy hat?

    It's pretty much impossible to judge from all the empty placeholder code
    here how much is real and constrained by hardware and how much is
    firmware abstraction, which makes it particularly hard to review whether
    any proposal heading in the right direction.

    Even if it *is* entirely firmware smoke-and-mirrors, if that firmware
    can provide a standardised discovery and configuration interface for
    common resources, it can be a bus. But then it should *be* a bus, with
    its own bus_type and its own device type to model those standard
    interfaces and IDs and resources. Or if it is really just a very clever
    dynamic DT overlay manager for platform devices, then it can be that
    instead. But what it should clearly not be is some in-between mess
    making the worst of both worlds, which is what the code here inescapably
    smells of.

    Thanks,
    Robin.

    \
     
     \ /
      Last update: 2022-08-25 21:59    [W:4.216 / U:0.168 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site