Date:   Wed, 1 Mar 2023 19:18:45 +0200
From:   Vladimir Oltean <vladimir.oltean@nxp.com>
To:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc:     Daniel Scally <djrscally@gmail.com>,
        Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        Sakari Ailus <sakari.ailus@linux.intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Implementation of fwnode_operations :: device_get_match_data()
 for software nodes?
Message-ID: <20230301171845.oliqbso7v2vmyqr3@skbuf>
References: <20230223203713.hcse3mkbq3m6sogb@skbuf>
 <Y/0uC1LgeWR0V0ts@smile.fi.intel.com>
 <20230227234411.jqmwshzkeyx6iqyo@skbuf>
 <Y/9iLBWAO37y6lZZ@smile.fi.intel.com>
 <20230301143625.7kdnzujlv4psbhla@skbuf>
 <Y/9qtT0vckSikOKJ@smile.fi.intel.com>
 <20230301152527.khyzifds4w3rkebt@skbuf>
 <Y/9wlDkuh39auAgF@smile.fi.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y/9wlDkuh39auAgF@smile.fi.intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ca7VuG8t35lw+qQQBGIhY9dFwOrtiMhkZiz0ZuOKZowwIo+Ai9A+RpnjbMEw?=
 =?us-ascii?Q?HVs2uv+eat/RCY8y7zR5F19/CphTDf3yOT7IV3GEibJtklwEn2WMWvEDivoV?=
 =?us-ascii?Q?d3Ouk6R8v+tWM6RVPB04xElPrIHZNinr8rA9iOtUVpjd8xHVJ0KzDLvR9h+I?=
 =?us-ascii?Q?Kaj32u7MgGFa8yri16EvhMt6N760vWRCiweqHv3PmBPgBRDroUwcW/yWBQvG?=
 =?us-ascii?Q?b51x5MfcvANU9n5MaPeQoqO+HsXTWm2zML9I0d9jzrSzJ6GqyWu6R/dqXqLr?=
 =?us-ascii?Q?smubC+PR6L9xMZfGNwgdMngplv8XYouUHsmvTsf/iEce/9xJORVsY1NfNiZH?=
 =?us-ascii?Q?ti3bGKGEcO049/M7AjrGB/3xhWse8EsW6qjsX8/lpQ13YD5nWKPiUwWwOwGb?=
 =?us-ascii?Q?XPiUvTq10/BlknE+zwslqRmwHxeCtUNeu9cOYwgYkb/dRHhmQWvSyAQXJWAr?=
 =?us-ascii?Q?27NTFnM9IwZW3I1tNPbO8FGXjT3OssFICg95nG88iqQbsCbSRFvRkJcVOVOd?=
 =?us-ascii?Q?13a021OVC3w2VMI3ZKFwLhWnd+XI6G1aheV7Rjg6J6ex1WkHehkIToZmOuyx?=
 =?us-ascii?Q?NmWl0xm0+9oly31nLtMBe1Z7ju3oCyov2d/yjb6QOF+R01o4GgBLmHkZSDyD?=
 =?us-ascii?Q?ZHieQba+WSezNuBhWgONs5s40vcIgne3Gnqp8XpquiwlgPRUUcnnr8hZkZkB?=
 =?us-ascii?Q?dfq+Iq8ynGM7OKvTTWZYzWMs7xpk2qWGT3P/eyh2wGCq32pB7vlUzSCrC25a?=
 =?us-ascii?Q?Prk/KbEORCheeNOmLMNG7Voa+RIKsCoSBJK0JRDMIUC2I76eFbVoxOggngyj?=
 =?us-ascii?Q?ZPKllkpSc5xERGCB7mRiAK0DYyLVbUH4wzcwtzHLdt43vZDyb6iZ3EWKkL/3?=
 =?us-ascii?Q?U1Em8Xc2nPXbEghP0c6T9lRnsmH9ykgM24pOu65Y9+EQZgUoS2lys+dBicj4?=
 =?us-ascii?Q?zgrTLsw47lcZv0a8MoxJ0YZ72AFVNzGp8e1Ss51zbm5C1jA93iqyQaBzr5+J?=
 =?us-ascii?Q?iCv1Rb8OM/O43Ift/5uoCeOlbUMvES1q2Q39hOJ1NSlpbDofYru4FgkghoKm?=
 =?us-ascii?Q?sLTvVTb74ygqgBsh6Sz9M71mAQH8a3voSOV9q3j3+MDryzoqMaxqKuUcBgX+?=
 =?us-ascii?Q?Ez7gNBsstfCY4mRumFT+HzbIziwOLygSwmOorTMIjw4+04LzNvNCgVV+rFMR?=
 =?us-ascii?Q?kkG3V9A7EE+aYxeXx5EEtMukJ616749DP88IEfJUivz3kD6HhysYG4gL3ctL?=
 =?us-ascii?Q?qsWI1XVdizbygIPsV3rXYTU8sAsMprE5Jaq8HAwjzWlkFQ2+Fx0gV5rcGECL?=
 =?us-ascii?Q?Koby3jlCScOh4R4Cbty4xkNLEhAkUIarR7ZfS4Ive6lplS2T4emGc589BHX8?=
 =?us-ascii?Q?hSiTWBEh9TV8XrRtityoPzvZsLimvI4lxozE1JL+KX2KD/oKmjlis+SjpgJS?=
 =?us-ascii?Q?V4o1OlRc5ceXGKF0zffmOG5JKL+N84JAPsSNv4cwCLcKS1wtUcGGW2sO30h0?=
 =?us-ascii?Q?vp7THR0ZF4nMCimBGK6cH8X2zgLFgB5F5VuFvZLUoPoYym0byrNM1r09r/W8?=
 =?us-ascii?Q?ZyYEUG9mMnBCpULBXGywXLtt6ZRrLzFkot38A2TMMvIY7tqwOi5wJHkZ3DJS?=
 =?us-ascii?Q?vw=3D=3D?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6dcf69cc-d4f3-4831-11e1-08db1a790555
X-MS-Exchange-CrossTenant-AuthSource: AM0PR04MB6452.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Mar 2023 17:18:48.7602
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: TUVQAtaw/pzcl07Wb5KWnpl/cCr4a3CulQ/okRk3PkXcRSenkHBHrCeUFcp+YbSNoxnh410LXTeDO8ylOFFLnA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR04MB8589
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Mar 01, 2023 at 05:34:44PM +0200, Andy Shevchenko wrote:
> On Wed, Mar 01, 2023 at 05:25:27PM +0200, Vladimir Oltean wrote:
> > On Wed, Mar 01, 2023 at 05:09:41PM +0200, Andy Shevchenko wrote:
> > > With overlays you can create the proper DT description stanza and end user's
> > > job is to just put it somewhere and upload via precoded script or so [1].
> > > 
> > > [1]:https://docs.kernel.org/devicetree/overlay-notes.html
> > 
> > Ah, okay, no, that's already a no-go, since existing device tree blobs
> > aren't compiled with the dtc "-@" flag which would generate the __symbols__
> > node necessary for DT overlays to be applied over them.
> > 
> > That, and it's clunky and uncalled for in general, both from my
> > perspective as a driver developer and that of a random user, if a driver
> > would just start requiring device tree overlays for more functionality.
> > Overlays address none of the complaints I had with large DT bindings
> > being large in general. They are still equally large, but now, they are
> > also spread into multiple files.
> 
> But isn't it what you would like to have working for your case?
> 
> Even taking into account the fixed HW layout, it would make sense to have more
> flexible approach to describe it, no?

Not really, no...
What I would like to have is a (partially) auto- (and dynamically-) generated
firmware description.

I'd need that in order to have a cleaner separation between the device
drivers for the various peripherals on that Ethernet switch SoC.
Currently, there's a lot of monolithic code to drive those peripherals
that lives in drivers/net/dsa/ but would belong to drivers/net/mdio,
drivers/irqchip/, drivers/gpio/, things like that.

What I want is the logic that gets me there, with none of the complications
for things I don't need.

> > > For the second one I'm not really the expert. But either FPGA framework (if
> > > they have anything working for this), or you also may look at Thunderbolt /
> > > USB4 which uses similar approach while being PCIe devices. Okay, the latter
> > > (USB4) is the PCIe topology, while FPGA is whatever behind the PCI switch.
> > > Meaning that FPGA case from HW p.o.v. is closer to your case.
> > 
> > A quick glance at Documentation/driver-api/fpga/ shows that it is a
> > framework for dealing with reprogrammable hardware, and has infra to
> > reprogram it. My hardware is fixed-function and doesn't need any of that.
> > 
> > Are you suggesting that I should look at reusing some common infra with
> > the fpga subsystem instead? A quick grep for device_add in drivers/fpga/
> > shows a bunch of open-coded device_add() and platform_device_add() calls.
> > Is this what you wanted me to see or is there something else?
> 
> Ah, so they don't have a mechanism on how to describe the hardware inside
> FPGA _after_ reconfiguration and apply it to the system? That's what I meant
> when referred to it.

Reading Documentation/devicetree/bindings/fpga/fpga-region.txt (with my
limited and ultra-superficial understanding), I guess that they still
use overlays to describe what should be probed on the reprogrammed regions.