Page MenuHomeFreeBSD

LinuxKPI: add of_node to struct device
AbandonedPublic

Authored by bz on Feb 19 2022, 1:10 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 1, 1:34 PM
Unknown Object (File)
Tue, Oct 15, 7:57 PM
Unknown Object (File)
Tue, Oct 15, 7:56 PM
Unknown Object (File)
Sep 28 2024, 6:34 AM
Unknown Object (File)
Sep 23 2024, 6:32 PM
Unknown Object (File)
Sep 23 2024, 1:48 AM
Unknown Object (File)
Sep 23 2024, 1:48 AM
Unknown Object (File)
Sep 23 2024, 1:48 AM

Details

Reviewers
imp
Group Reviewers
linuxkpi
Summary

Add the 'struct device_node *of_node' to struct device without
implementing it yet.

The main reason is to be merged to stable/13 before 13.1-R in order
for it to be used at a later time without changing struct device
right away again after the release (given it was already modified
on stable/13).

MFC after: 3 days

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 44510
Build 41398: arc lint + arc unit

Event Timeline

bz requested review of this revision.Feb 19 2022, 1:10 AM

Why ?
It really doesn't make sense to me to add every member to every struct that linux uses just to satisfy compilation.

For Linux webcamd I usually stub it. Will this be fully implemented for ARM64 I presume?

For Linux webcamd I usually stub it. Will this be fully implemented for ARM64 I presume?

That would be crazy.

Add stub implementations as well.

In D34318#777013, @manu wrote:

Why ?
It really doesn't make sense to me to add every member to every struct that linux uses just to satisfy compilation.

Because it's a lot easier to add the error returning stubs then to #ifdef out the drivers and maintain that over time.

In D34318#777059, @bz wrote:
In D34318#777013, @manu wrote:

Why ?
It really doesn't make sense to me to add every member to every struct that linux uses just to satisfy compilation.

Because it's a lot easier to add the error returning stubs then to #ifdef out the drivers and maintain that over time.

I've been maintaining drm-kmod from quite some time now and for me it's better to ifdef out in the code. It also shows that we have no intention of implementing this.

In D34318#777064, @manu wrote:
In D34318#777059, @bz wrote:
In D34318#777013, @manu wrote:

Why ?
It really doesn't make sense to me to add every member to every struct that linux uses just to satisfy compilation.

Because it's a lot easier to add the error returning stubs then to #ifdef out the drivers and maintain that over time.

I've been maintaining drm-kmod from quite some time now and for me it's better to ifdef out in the code. It also shows that we have no intention of implementing this.

Did you add the CONFIG_OF around the drm code or was it there?

I have more instances of this in a single file than I can find in the entire drm-kmod code and given the KConfig of my drivers doesn't even depend on CONFIG_OF I assume Linux must have dummy fallbacks as well as otherwise these drivers wouldn't compile in Linux for non OF kernels.

So your suggestion is to deal with these three drivers which need the pointer and completely #ifdef all the calls out and then if actually needed add native FreeBSD code and then maintain that rather that add a pointer and dummy calls? So double the work with each driver and the other ones to come? Right. Happy weekend.

IMO things we want to have in future should be #ifdef-ed in driver rather than dummy-implemented in LKPI
But in that case we can define opaque struct device_node; in linux/of.h to satisfy struct device_node *of_node; member of struct class and than add dummy implementation somewhere in wifi driver to get rid of extra #ifdef-s