On Thu, 8 Jan 2026 07:25:47 -0600 John Groves <[email protected]> wrote:
> On 26/01/08 10:43AM, Jonathan Cameron wrote: > > On Wed, 7 Jan 2026 09:33:10 -0600 > > John Groves <[email protected]> wrote: > > > > > This function will be used by both device.c and fsdev.c, but both are > > > loadable modules. Moving to bus.c puts it in core and makes it available > > > to both. > > > > > > No code changes - just relocated. > > > > > > Signed-off-by: John Groves <[email protected]> > > Hi John, > > > > I don't know the code well enough to offer an opinion on whether this > > move causes any issues or if this is the best location, so review is > > superficial > > stuff only. > > > > Jonathan > > > > > --- > > > drivers/dax/bus.c | 27 +++++++++++++++++++++++++++ > > > drivers/dax/device.c | 23 ----------------------- > > > 2 files changed, 27 insertions(+), 23 deletions(-) > > > > > > diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c > > > index fde29e0ad68b..a2f9a3cc30a5 100644 > > > --- a/drivers/dax/bus.c > > > +++ b/drivers/dax/bus.c > > > @@ -7,6 +7,9 @@ > > > #include <linux/slab.h> > > > #include <linux/dax.h> > > > #include <linux/io.h> > > > +#include <linux/backing-dev.h> > > > > I'm not immediately spotting why this one. Maybe should be in a different > > patch? > > > > > +#include <linux/range.h> > > > +#include <linux/uio.h> > > > > Why this one? > > Good eye, thanks. These must have leaked from some of the many dead ends > that I tried before coming up with this approach. > > I've dropped all new includes and it still builds :D Range one should be there... > > > > > Style wise, dax seems to use reverse xmas tree for includes, so > > this should keep to that. > > > > > #include "dax-private.h" > > > #include "bus.h" > > > > > > @@ -1417,6 +1420,30 @@ static const struct device_type dev_dax_type = { > > > .groups = dax_attribute_groups, > > > }; > > > > > > +/* see "strong" declaration in tools/testing/nvdimm/dax-dev.c */ > > Bonus space before that */ > > Curiously that wasn't there in the original. > > Removed. > > [ ... ] > > Thanks, > John
