Received-SPF: pass (google.com: domain of linux-kernel+bounces-82314-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Mon, 26 Feb 2024 18:00:03 -0300
From: "Ricardo B. Marliere" <ricardo@marliere.net>
To: Alex Elder <elder@ieee.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, 
	Johan Hovold <johan@kernel.org>, Alex Elder <elder@kernel.org>, greybus-dev@lists.linaro.org, 
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] greybus: constify the struct device_type usage
Message-ID: <i2pptclnx3otryvzzndtfh5zqgmenbe2aa36xfrbpuripbfsym@5ophc6hj3u3g>
References: <20240219-device_cleanup-greybus-v1-1-babb3f65e8cc@marliere.net>
 <cf5b2696-d7ca-40fc-856a-52f352cd270c@ieee.org>
 <ids3525jm5zkwkgizt2xtg3do37kqqtfdy5gc2cptdduexoe7r@cr4yxh3tykkh>
 <2024022553-deepness-sublevel-73de@gregkh>
 <yru2ywkyqwhg3rpyuqkkx73fxkkgsfj3vcbttnzrjq662ctrov@boh65bhxjjgo>
 <17e89261-d46b-4845-9fca-05dac3006a39@ieee.org>
 <xsotlft7byeu4iyyzty74dgzxtszmvyj4nuhga7qwuqc2tnubc@lp4ut22lc622>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <xsotlft7byeu4iyyzty74dgzxtszmvyj4nuhga7qwuqc2tnubc@lp4ut22lc622>

On 26 Feb 17:21, Ricardo B. Marliere wrote:
> 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

Sorry, this made no sense!

> 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