On Thu, May 28, 2015 at 11:09:38AM +0530, Sudip Mukherjee wrote:
> On Wed, May 27, 2015 at 08:21:16AM -0700, Greg KH wrote:
> > On Wed, May 27, 2015 at 11:16:34AM -0400, Alan Stern wrote:
> > > On Wed, 27 May 2015, Heikki Krogerus wrote:
> >
> > Maybe we need to test for this in the driver core, n
On Thu, 28 May 2015, Felipe Balbi wrote:
> On Thu, May 28, 2015 at 11:09:38AM +0530, Sudip Mukherjee wrote:
> > On Wed, May 27, 2015 at 08:21:16AM -0700, Greg KH wrote:
> > > On Wed, May 27, 2015 at 11:16:34AM -0400, Alan Stern wrote:
> > > > On Wed, 27 May 2015, Heikki Krogerus wrote:
> > >
> >
On Thu, May 28, 2015 at 08:36:46AM -0400, Sasha Levin wrote:
> On 05/28/2015 01:39 AM, Sudip Mukherjee wrote:
> > diff --git a/drivers/base/driver.c b/drivers/base/driver.c
> > index 4eabfe2..1acae5b 100644
> > --- a/drivers/base/driver.c
> > +++ b/drivers/base/driver.c
> > @@ -150,6 +150,11 @@ int
On 05/28/2015 01:39 AM, Sudip Mukherjee wrote:
> diff --git a/drivers/base/driver.c b/drivers/base/driver.c
> index 4eabfe2..1acae5b 100644
> --- a/drivers/base/driver.c
> +++ b/drivers/base/driver.c
> @@ -150,6 +150,11 @@ int driver_register(struct device_driver *drv)
> int ret;
> stru
On Thu, May 28, 2015 at 12:12:56PM +0530, Sudip Mukherjee wrote:
> On Thu, May 28, 2015 at 12:54:59AM -0500, Felipe Balbi wrote:
> > On Thu, May 28, 2015 at 11:09:38AM +0530, Sudip Mukherjee wrote:
> > > On Wed, May 27, 2015 at 08:21:16AM -0700, Greg KH wrote:
> > > > On Wed, May 27, 2015 at 11:16:
On Thu, May 28, 2015 at 12:54:59AM -0500, Felipe Balbi wrote:
> On Thu, May 28, 2015 at 11:09:38AM +0530, Sudip Mukherjee wrote:
> > On Wed, May 27, 2015 at 08:21:16AM -0700, Greg KH wrote:
> > > On Wed, May 27, 2015 at 11:16:34AM -0400, Alan Stern wrote:
> > > > On Wed, 27 May 2015, Heikki Krogeru
On Thu, May 28, 2015 at 11:09:38AM +0530, Sudip Mukherjee wrote:
> On Wed, May 27, 2015 at 08:21:16AM -0700, Greg KH wrote:
> > On Wed, May 27, 2015 at 11:16:34AM -0400, Alan Stern wrote:
> > > On Wed, 27 May 2015, Heikki Krogerus wrote:
> >
> > Maybe we need to test for this in the driver core, n
On Wed, May 27, 2015 at 08:21:16AM -0700, Greg KH wrote:
> On Wed, May 27, 2015 at 11:16:34AM -0400, Alan Stern wrote:
> > On Wed, 27 May 2015, Heikki Krogerus wrote:
>
> Maybe we need to test for this in the driver core, not allowing drivers
> for busses that are not registered, that might solve
Hi Greg,
On Tue, May 26, 2015 at 07:41:18PM -0700, Greg KH wrote:
> On Tue, May 26, 2015 at 10:54:01AM -0700, David Cohen wrote:
> > Hi,
> >
> > On Mon, May 25, 2015 at 07:00:13PM +0200, Bjørn Mork wrote:
> > > Greg KH writes:
> > >
> > > > If there are other bus drivers that do this, I'll go f
On Wed, May 27, 2015 at 11:16:34AM -0400, Alan Stern wrote:
> On Wed, 27 May 2015, Heikki Krogerus wrote:
>
> > This problem is not ulpi specific. We have the same issue with every
> > single bus. With a bus like PCI it's just really unlikely to hit it
> > because PCI bus driver uses postcore_init
On Wed, 27 May 2015, Heikki Krogerus wrote:
> This problem is not ulpi specific. We have the same issue with every
> single bus. With a bus like PCI it's just really unlikely to hit it
> because PCI bus driver uses postcore_initcall. But if there was
> a PCI driver that used postcore_initcall itse
On Wed, May 27, 2015 at 11:39:33AM +0300, Heikki Krogerus wrote:
> Hi Greg,
>
> I can appreciate now that fixing the core problem like I2C did is
> wrong, but I still feel that the driver core should provide something
> like the helper for checking if the bus was registered already or not.
> Other
Hi Greg,
> > But couldn't we add a helper function to drivers/base/bus.c that the
> > bus drivers can use to at least check was the bus already loaded or
> > not? It looks like there are a couple of bus drivers that use the
> > struct bus member "p" to check that.
> >
> > Greg, what do you think?
On Tue, May 26, 2015 at 07:41:18PM -0700, Greg KH wrote:
> On Tue, May 26, 2015 at 10:54:01AM -0700, David Cohen wrote:
> > Hi,
> >
> > On Mon, May 25, 2015 at 07:00:13PM +0200, Bjørn Mork wrote:
> > > Greg KH writes:
> > >
> Don't mess with bus->p. I can rename it to
> "do_not_touch_this_isnt_
On Tue, May 26, 2015 at 10:54:01AM -0700, David Cohen wrote:
> Hi,
>
> On Mon, May 25, 2015 at 07:00:13PM +0200, Bjørn Mork wrote:
> > Greg KH writes:
> >
> > > If there are other bus drivers that do this, I'll go fix them up,
> > > pointers to those files would be appreciated.
> >
> > git grep
On Mon, May 25, 2015 at 07:00:13PM +0200, Bjørn Mork wrote:
> Greg KH writes:
>
> > If there are other bus drivers that do this, I'll go fix them up,
> > pointers to those files would be appreciated.
>
> git grep -E 'if .*\.p\W' found a couple of interesting candidates you
> might want to check
Hi,
On Mon, May 25, 2015 at 07:00:13PM +0200, Bjørn Mork wrote:
> Greg KH writes:
>
> > If there are other bus drivers that do this, I'll go fix them up,
> > pointers to those files would be appreciated.
>
> git grep -E 'if .*\.p\W' found a couple of interesting candidates you
> might want to c
Greg KH writes:
> If there are other bus drivers that do this, I'll go fix them up,
> pointers to those files would be appreciated.
git grep -E 'if .*\.p\W' found a couple of interesting candidates you
might want to check out:
drivers/i2c/i2c-core.c: if (unlikely(WARN_ON(!i2c_bus_type.p))) {
On Mon, May 25, 2015 at 02:40:10PM +0300, Heikki Krogerus wrote:
> Hi,
>
> > Why do we even need that? If you take patch that makes ulpi_init a
> > subsys_initcall you won't have this problem, and no additional weird
> > hacks and errors will be needed
>
> Using subsys_initcall will work around t
Hi,
> Why do we even need that? If you take patch that makes ulpi_init a
> subsys_initcall you won't have this problem, and no additional weird
> hacks and errors will be needed
Using subsys_initcall will work around the problem for now, but I
would not make the assumption that there will never b
Why do we even need that? If you take patch that makes ulpi_init a
subsys_initcall you won't have this problem, and no additional weird
hacks and errors will be needed
On Sun, May 24, 2015 at 11:09 AM, Sudip Mukherjee
wrote:
> On Sun, May 24, 2015 at 12:19:48AM -0700, Greg KH wrote:
>> On Wed, Ma
On Sun, May 24, 2015 at 12:19:48AM -0700, Greg KH wrote:
> On Wed, May 20, 2015 at 03:33:26PM -0400, Sasha Levin wrote:
> > ULPI registers it's bus at module_init so if the bus fails to register, the
> > module will fail to load and all will be well in the world.
> >
> > However, if the ULPI code
On Wed, May 20, 2015 at 03:33:26PM -0400, Sasha Levin wrote:
> ULPI registers it's bus at module_init so if the bus fails to register, the
> module will fail to load and all will be well in the world.
>
> However, if the ULPI code is built-in rather than a module, the bus
> initialization may fail
On 05/22/2015 06:16 AM, Heikki Krogerus wrote:
> diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
> > > >>index 0e6f968..0b0a5e7 100644
> > > >>--- a/drivers/usb/common/ulpi.c
> > > >>+++ b/drivers/usb/common/ulpi.c
> > > >>@@ -132,6 +132,10 @@ int ulpi_registe
On Fri, May 22, 2015 at 01:16:38PM +0300, Heikki Krogerus wrote:
> > > >>diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
> > > >>index 0e6f968..0b0a5e7 100644
> > > >>--- a/drivers/usb/common/ulpi.c
> > > >>+++ b/drivers/usb/common/ulpi.c
> > > >>@@ -132,6 +132,10 @@ int ulpi_reg
> > >>diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
> > >>index 0e6f968..0b0a5e7 100644
> > >>--- a/drivers/usb/common/ulpi.c
> > >>+++ b/drivers/usb/common/ulpi.c
> > >>@@ -132,6 +132,10 @@ int ulpi_register_driver(struct ulpi_driver *drv)
> > >> if (!drv->probe)
> >
> >>ULPI registers it's bus at module_init so if the bus fails to register, the
> >A minor comment: s/it's/its/
> >
> >>module will fail to load and all will be well in the world.
> >>
> >>However, if the ULPI code is built-in rather than a module, the bus
> >>initialization may fail but we'd still
On 05/21/2015 05:22 AM, David Cohen wrote:
Hi,
On Wed, May 20, 2015 at 03:33:26PM -0400, Sasha Levin wrote:
ULPI registers it's bus at module_init so if the bus fails to register, the
A minor comment: s/it's/its/
module will fail to load and all will be well in the world.
However, if the
Hi,
On Wed, May 20, 2015 at 03:33:26PM -0400, Sasha Levin wrote:
> ULPI registers it's bus at module_init so if the bus fails to register, the
A minor comment: s/it's/its/
> module will fail to load and all will be well in the world.
>
> However, if the ULPI code is built-in rather than a modul
ULPI registers it's bus at module_init so if the bus fails to register, the
module will fail to load and all will be well in the world.
However, if the ULPI code is built-in rather than a module, the bus
initialization may fail but we'd still try to register drivers later onto
a non-existant bus,
30 matches
Mail list logo
