Messages in this thread | | | Date | Mon, 26 Feb 2024 17:21:37 -0300 | From | "Ricardo B. Marliere" <> | Subject | Re: [PATCH] greybus: constify the struct device_type usage |
| |
On 26 Feb 13:50, Alex Elder wrote: > On 2/25/24 5:04 AM, Ricardo B. Marliere wrote: > >>>> On another subject: > >>>> > >>>> Johan might disagree, but I think it would be nice to make > >>>> the definitions of the Greybus device types as static (private) > >>>> and make the is_gb_host_device() etc. functions real functions > >>>> rather than static inlines in <linux/greybus.h>. > >>>> > >>>> It turns out that all of the is_gb_*() functions are called only > >>>> from drivers/greybus/core.c; they could all be moved there rather > >>>> than advertising them in <linux/greybus.h>. > >>> I guess it depends whether they would be used somewhere else in the > >>> future. Perhaps it was left there with that intention when it was first > >>> being developed? I agree, though. Will happily send a patch with this if > >>> desired. > >> Let's clean the code up for what we have today. If it's needed in the > >> future, we can move the structures then. > > Sounds good to me, will send a v2 then! > > I might be misinterpreting Greg's response; I *think* he > agrees with my suggestion.
That's what I thought too.
> > In any case, please do *not* send v2 with the purpose of > including my suggestion. > > If you send a v2, keep it focused on this original patch. > You can then implement the other suggestion as a follow-on > patch (or series).
Indeed, this one is good as is but I thought of converting it into a series so that they can be taken with no dependency on this one. So it would look like:
Patch 1: move "is_gb_*()" into drivers/greybus/core.c Patch 2: move "device_type greybus_*" into drivers/greybus/core.c Patch 3: make "device_type greybus_*" const
But you're right. I could simply send 1 and 2 after this one has been applied. If I were to send them separately, how would I communicate that there's a dependency? Something like:
--- This series depends on [1]. [1]: lore://link-to-this-patch
?
Thanks and sorry for the noobishness
> > -Alex
| |