On Tue, Jan 05, 2021 at 10:36:27AM -0400, Jason Gunthorpe wrote:
> On Tue, Jan 05, 2021 at 01:42:56PM +, Mark Brown wrote:
> > You're missing the point there. I2C is enumerated by firmware in
> > exactly the same way as the platform bus is, it's not discoverable from
> > the hardware (and
On Tue, Jan 05, 2021 at 01:42:56PM +, Mark Brown wrote:
> On Mon, Jan 04, 2021 at 08:13:41PM -0400, Jason Gunthorpe wrote:
> > On Mon, Jan 04, 2021 at 09:19:30PM +, Mark Brown wrote:
>
> > > Like I keep saying the same thing applies to all non-enumerable buses -
> > > exactly the same
On Mon, Jan 04, 2021 at 08:13:41PM -0400, Jason Gunthorpe wrote:
> On Mon, Jan 04, 2021 at 09:19:30PM +, Mark Brown wrote:
> > Like I keep saying the same thing applies to all non-enumerable buses -
> > exactly the same considerations exist for all the other buses like I2C
> > (including the
On Mon, Jan 04, 2021 at 07:12:47PM -0800, Dan Williams wrote:
> I get that, but I'm fearing a gigantic bus_ops structure that has
> narrow helpers like ->gpio_count() that mean nothing to the many other
> clients of the bus. Maybe I'm overestimating the pressure there will
> be to widen the ops
On Mon, Jan 4, 2021 at 5:53 PM Jason Gunthorpe wrote:
>
> On Mon, Jan 04, 2021 at 04:51:51PM -0800, Dan Williams wrote:
> > On Mon, Jan 4, 2021 at 4:14 PM Jason Gunthorpe wrote:
> > >
> > > On Mon, Jan 04, 2021 at 09:19:30PM +, Mark Brown wrote:
> > >
> > >
> > > > > Regardless of the
On Mon, Jan 04, 2021 at 04:51:51PM -0800, Dan Williams wrote:
> On Mon, Jan 4, 2021 at 4:14 PM Jason Gunthorpe wrote:
> >
> > On Mon, Jan 04, 2021 at 09:19:30PM +, Mark Brown wrote:
> >
> >
> > > > Regardless of the shortcut to make everything a struct
> > > > platform_device, I think it was
On Mon, Jan 4, 2021 at 4:14 PM Jason Gunthorpe wrote:
>
> On Mon, Jan 04, 2021 at 09:19:30PM +, Mark Brown wrote:
>
>
> > > Regardless of the shortcut to make everything a struct
> > > platform_device, I think it was a mistake to put OF devices on
> > > platform_bus. Those should have
On Mon, Jan 04, 2021 at 09:19:30PM +, Mark Brown wrote:
> > Regardless of the shortcut to make everything a struct
> > platform_device, I think it was a mistake to put OF devices on
> > platform_bus. Those should have remained on some of_bus even if they
>
> Like I keep saying the same
On Mon, Jan 04, 2021 at 02:08:31PM -0400, Jason Gunthorpe wrote:
> On Mon, Dec 21, 2020 at 06:51:40PM +, Mark Brown wrote:
> > BTW I did have a bit of a scan through some of the ACPI devices and
> > for a good proportion of them it seems fairly clear that they are
> > not platform devices at
On Mon, Dec 21, 2020 at 06:51:40PM +, Mark Brown wrote:
> > with some kind of inheritance scheme where platform device remained as
> > only instantiated directly in board files, while drivers could bind to
> > OF/DT/ACPI/FPGA/etc device instantiations with minimal duplication &
> >
On Fri, Dec 18, 2020 at 04:58:56PM -0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 08:32:11PM +, Mark Brown wrote:
>
> > Historically people did try to create custom bus types, as I have
> > pointed out before there was then pushback that these were duplicating
> > the platform bus so
On 18/12/2020 19:36:08-0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 10:16:58PM +0100, Alexandre Belloni wrote:
>
> > But then again, what about non-enumerable devices on the PCI device? I
> > feel this would exactly fit MFD. This is a collection of IPs that exist
> > as standalone but
On Fri, Dec 18, 2020 at 10:16:58PM +0100, Alexandre Belloni wrote:
> But then again, what about non-enumerable devices on the PCI device? I
> feel this would exactly fit MFD. This is a collection of IPs that exist
> as standalone but in this case are grouped in a single device.
So, if mfd had a
On Fri, Dec 18, 2020 at 1:17 PM Alexandre Belloni
wrote:
>
> On 18/12/2020 16:58:56-0400, Jason Gunthorpe wrote:
> > On Fri, Dec 18, 2020 at 08:32:11PM +, Mark Brown wrote:
> >
> > > > So, I strongly suspect, MFD should create mfd devices on a MFD bus
> > > > type.
> > >
> > > Historically
On 18/12/2020 16:58:56-0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 08:32:11PM +, Mark Brown wrote:
>
> > > So, I strongly suspect, MFD should create mfd devices on a MFD bus
> > > type.
> >
> > Historically people did try to create custom bus types, as I have
> > pointed out
On Fri, Dec 18, 2020 at 08:32:11PM +, Mark Brown wrote:
> > So, I strongly suspect, MFD should create mfd devices on a MFD bus
> > type.
>
> Historically people did try to create custom bus types, as I have
> pointed out before there was then pushback that these were duplicating
> the
On Fri, Dec 18, 2020 at 02:41:50PM -0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 06:03:10PM +, Mark Brown wrote:
> > If it's not supposed to use platform devices so I'm assuming that the
> > intention is that it should use aux devices, otherwise presumably it'd
> > be making some
On Fri, Dec 18, 2020 at 07:09:11PM +, Lee Jones wrote:
> ACPI, DT and MFD are not busses.
And yet ACPI and PNP have a bus:
extern struct bus_type acpi_bus_type;
extern struct bus_type pnp_bus_type;
Why? Because in the driver core if you subclass struct device and want
to bind drivers,
On Fri, 18 Dec 2020, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 06:03:10PM +, Mark Brown wrote:
> > On Fri, Dec 18, 2020 at 12:28:17PM -0400, Jason Gunthorpe wrote:
> > > On Fri, Dec 18, 2020 at 03:52:04PM +, Mark Brown wrote:
> > > > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason
On Fri, Dec 18, 2020 at 06:03:10PM +, Mark Brown wrote:
> On Fri, Dec 18, 2020 at 12:28:17PM -0400, Jason Gunthorpe wrote:
> > On Fri, Dec 18, 2020 at 03:52:04PM +, Mark Brown wrote:
> > > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote:
>
> > > > I thought the recent LWN
On Fri, Dec 18, 2020 at 12:28:17PM -0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 03:52:04PM +, Mark Brown wrote:
> > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote:
> > > I thought the recent LWN article summed it up nicely, auxillary bus is
> > > for gluing to
On 18/12/2020 12:28:17-0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 03:52:04PM +, Mark Brown wrote:
> > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote:
> > > On Fri, Dec 18, 2020 at 01:17:09PM +, Mark Brown wrote:
> >
> > > > As previously discussed this will
On Fri, Dec 18, 2020 at 03:52:04PM +, Mark Brown wrote:
> On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote:
> > On Fri, Dec 18, 2020 at 01:17:09PM +, Mark Brown wrote:
>
> > > As previously discussed this will need the auxilliary bus extending to
> > > support at least
On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 01:17:09PM +, Mark Brown wrote:
> > As previously discussed this will need the auxilliary bus extending to
> > support at least interrupts and possibly also general resources.
> I thought the recent
On Thu, Dec 17, 2020 at 06:39:55PM -0800, Dan Williams wrote:
> There is room for documentation improvement here. I realize reading it
> back now that much of the justification for "why not platform bus?"
> happened on the list, but only a small mention made it into the
It wasn't clear from the
On Fri, Dec 18, 2020 at 01:17:09PM +, Mark Brown wrote:
> As previously discussed this will need the auxilliary bus extending to
> support at least interrupts and possibly also general resources.
I thought the recent LWN article summed it up nicely, auxillary bus is
for gluing to subsystems
On Fri, 18 Dec 2020, Mark Brown wrote:
> On Fri, Dec 18, 2020 at 08:10:51AM +0100, Greg KH wrote:
> > On Thu, Dec 17, 2020 at 10:19:37PM +0100, Alexandre Belloni wrote:
>
> > > There is something I don't get from the documentation and it is what is
> > > this introducing that couldn't already be
On Fri, Dec 18, 2020 at 08:10:51AM +0100, Greg KH wrote:
> On Thu, Dec 17, 2020 at 10:19:37PM +0100, Alexandre Belloni wrote:
> > There is something I don't get from the documentation and it is what is
> > this introducing that couldn't already be done using platform drivers
> > and platform
On Thu, Dec 17, 2020 at 10:19:37PM +0100, Alexandre Belloni wrote:
> Hello,
>
> On 05/12/2020 16:51:36+0100, Greg KH wrote:
> > > To me, the documentation was written, and reviewed, more from the
> > > perspective of "why not open code a custom bus instead". So I can see
> > > after the fact how
On Thu, Dec 17, 2020 at 1:20 PM Alexandre Belloni
wrote:
>
> Hello,
>
> On 05/12/2020 16:51:36+0100, Greg KH wrote:
> > > To me, the documentation was written, and reviewed, more from the
> > > perspective of "why not open code a custom bus instead". So I can see
> > > after the fact how that is
Hello,
On 05/12/2020 16:51:36+0100, Greg KH wrote:
> > To me, the documentation was written, and reviewed, more from the
> > perspective of "why not open code a custom bus instead". So I can see
> > after the fact how that is a bit too much theory and justification and
> > not enough practical
On Sat, Dec 5, 2020 at 4:24 PM David Ahern wrote:
>
> On 12/2/20 5:54 PM, Dan Williams wrote:
> > diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> > index 8d7001712062..040be48ce046 100644
> > --- a/drivers/base/Kconfig
> > +++ b/drivers/base/Kconfig
> > @@ -1,6 +1,9 @@
> > #
On 12/2/20 5:54 PM, Dan Williams wrote:
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 8d7001712062..040be48ce046 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -1,6 +1,9 @@
> # SPDX-License-Identifier: GPL-2.0
> menu "Generic Driver Options"
>
>
On Fri, Dec 04, 2020 at 08:41:09AM -0800, Dan Williams wrote:
> On Fri, Dec 4, 2020 at 3:41 AM Greg KH wrote:
> >
> > On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote:
> > > From: Dave Ertman
> > >
> > > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver.
> > >
On Fri, Dec 04, 2020 at 09:10:34AM -0800, Ranjani Sridharan wrote:
> On Fri, 2020-12-04 at 13:59 +0100, Greg KH wrote:
> > On Fri, Dec 04, 2020 at 02:32:07PM +0200, Leon Romanovsky wrote:
> > > On Fri, Dec 04, 2020 at 12:42:46PM +0100, Greg KH wrote:
> > > > On Wed, Dec 02, 2020 at 04:54:24PM
On Fri, 2020-12-04 at 13:35 +0100, Greg KH wrote:
> On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote:
> > From: Dave Ertman
> >
> > Add support for the Auxiliary Bus, auxiliary_device and
> > auxiliary_driver.
> > It enables drivers to create an auxiliary_device and bind an
> >
On Fri, 2020-12-04 at 08:25 -0800, Jakub Kicinski wrote:
> On Fri, 4 Dec 2020 14:54:55 +0200 Leon Romanovsky wrote:
> > Thanks, pulled to mlx5-next
> >
> > Jason, Jakob,
> >
> > Can you please pull that mlx5-next branch to your trees?
> >
On Fri, 2020-12-04 at 13:59 +0100, Greg KH wrote:
> On Fri, Dec 04, 2020 at 02:32:07PM +0200, Leon Romanovsky wrote:
> > On Fri, Dec 04, 2020 at 12:42:46PM +0100, Greg KH wrote:
> > > On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote:
> > > > From: Dave Ertman
> > > >
> > > > Add
On Fri, Dec 4, 2020 at 3:41 AM Greg KH wrote:
>
> On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote:
> > From: Dave Ertman
> >
> > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver.
> > It enables drivers to create an auxiliary_device and bind an
> >
On Fri, 4 Dec 2020 14:54:55 +0200 Leon Romanovsky wrote:
> Thanks, pulled to mlx5-next
>
> Jason, Jakob,
>
> Can you please pull that mlx5-next branch to your trees?
> git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git
Could you post a PR with a proper description and so on?
On Fri, Dec 04, 2020 at 02:32:07PM +0200, Leon Romanovsky wrote:
> On Fri, Dec 04, 2020 at 12:42:46PM +0100, Greg KH wrote:
> > On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote:
> > > From: Dave Ertman
> > >
> > > Add support for the Auxiliary Bus, auxiliary_device and
On Fri, Dec 04, 2020 at 01:35:05PM +0100, Greg KH wrote:
> On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote:
> > From: Dave Ertman
> >
> > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver.
> > It enables drivers to create an auxiliary_device and bind an
> >
> From: Leon Romanovsky
> Sent: Friday, December 4, 2020 6:02 PM
>
> On Fri, Dec 04, 2020 at 12:42:46PM +0100, Greg KH wrote:
> > On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote:
> > > From: Dave Ertman
> > >
> > > Add support for the Auxiliary Bus, auxiliary_device and
On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote:
> From: Dave Ertman
>
> Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver.
> It enables drivers to create an auxiliary_device and bind an
> auxiliary_driver to it.
>
> The bus supports probe/remove shutdown and
On Fri, Dec 04, 2020 at 12:42:46PM +0100, Greg KH wrote:
> On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote:
> > From: Dave Ertman
> >
> > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver.
> > It enables drivers to create an auxiliary_device and bind an
> >
On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote:
> From: Dave Ertman
>
> Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver.
> It enables drivers to create an auxiliary_device and bind an
> auxiliary_driver to it.
>
> The bus supports probe/remove shutdown and
On Thu, Dec 3, 2020 at 6:34 PM Jason Gunthorpe wrote:
>
> On Thu, Dec 03, 2020 at 04:06:24PM +0100, Greg KH wrote:
>
> > > ...for all the independent drivers to have a common commit baseline. It
> > > is not there yet pending Greg's Ack.
> >
> > I have been trying to carve out some time to review
On Thu, Dec 03, 2020 at 04:06:24PM +0100, Greg KH wrote:
> > ...for all the independent drivers to have a common commit baseline. It
> > is not there yet pending Greg's Ack.
>
> I have been trying to carve out some time to review this. At my initial
> glance, I still have objections, so please,
On Thu, Dec 03, 2020 at 04:07:42PM +0100, Greg KH wrote:
> On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote:
> > PS: Greg I know I promised some review on newcomer patches to help with
> > your queue, unfortunately Intel-internal review is keeping my plate
> > full. Again, I do not
On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote:
> PS: Greg I know I promised some review on newcomer patches to help with
> your queue, unfortunately Intel-internal review is keeping my plate
> full. Again, I do not want other stakeholder to be waiting on me to
> resolve that
On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote:
> From: Dave Ertman
>
> Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver.
> It enables drivers to create an auxiliary_device and bind an
> auxiliary_driver to it.
>
> The bus supports probe/remove shutdown and
From: Dave Ertman
Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver.
It enables drivers to create an auxiliary_device and bind an
auxiliary_driver to it.
The bus supports probe/remove shutdown and suspend/resume callbacks.
Each auxiliary_device has a unique string based
52 matches
Mail list logo
