Hi, On Thu, Jan 20, 2022 at 7:36 AM Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, Jan 20, 2022 at 07:25:04AM -0800, Matthias Kaehlcke wrote: > > On Thu, Jan 20, 2022 at 08:45:24AM +0100, Greg Kroah-Hartman wrote: > > > On Wed, Jan 19, 2022 at 11:29:18PM -0800, Christoph Hellwig wrote: > > > > On Wed, Jan 19, 2022 at 12:43:42PM -0800, Matthias Kaehlcke wrote: > > > > > Export device_is_bound() to enable its use by drivers that are > > > > > built as modules. > > > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@xxxxxxxxxxxx> > > > > > Reviewed-by: Douglas Anderson <dianders@xxxxxxxxxxxx> > > > > > Reviewed-by: Stephen Boyd <swboyd@xxxxxxxxxxxx> > > > > > > > > Didn't Greg clearly NAK this the last few times it came up? > > > > > > Yes, which is why this series is _WAY_ on the bottom of my list for > > > reviews... > > > > I wasn't aware of that prior discussion, it would have helped to know > > that this is a major concern for you ... > > Sorry, that was on a different thread for a different feature, I thought > it was this one. Too many reviews at times. > > > > > If using device_is_bound() is a no-go then _find_onboard_hub() of > > the onboard_hub driver could make it's decision based on the > > presence (or absence) of drvdata, which is what the function ultimately > > returns. > > That suffers from the same problem. I'll take a look at this later > after -rc1 is out and see what can be done here... Did you have any suggestions or pointers to places to further research what you're looking for? I think at this point both Stephen Boyd and I have given the patch series a fairly thorough review. If the only problem left is the export of device_is_bound() then we should find a better solution to the problem so the series can move forward. Thanks! -Doug
