Hi Greg,
On Thu, May 15, 2014 at 12:47:34AM +0800, Greg KH wrote:
> On Wed, May 14, 2014 at 12:41:44PM -0400, Alan Stern wrote:
> > On Wed, 14 May 2014, Greg KH wrote:
> >
> > > > > Or just make the lvstest driver have to be "manually" bound to the
> > > > > device through the bind file in sysfs,
On Thu, May 15, 2014 at 12:07:19AM +0800, Greg KH wrote:
> On Mon, May 12, 2014 at 11:45:23AM +0530, Pratyush Anand wrote:
> > +static DEVICE_ATTR(u3_entry, S_IWUSR, NULL, issue_u3_entry);
>
> For this, and the other DEVICE_ATTR() entries, please use
> DEVICE_ATTR_RO() or _RW(), or _WO(), dependin
On Wed, May 14, 2014 at 12:41:44PM -0400, Alan Stern wrote:
> On Wed, 14 May 2014, Greg KH wrote:
>
> > > > Or just make the lvstest driver have to be "manually" bound to the
> > > > device through the bind file in sysfs, don't let the driver
> > > > automatically bind to anything.
> > >
> > > Ho
On Wed, 14 May 2014, Greg KH wrote:
> > > Or just make the lvstest driver have to be "manually" bound to the
> > > device through the bind file in sysfs, don't let the driver
> > > automatically bind to anything.
> >
> > How can we do that? The probe routine doesn't know whether it was
> > calle
On Wed, May 14, 2014 at 12:06:40PM -0400, Alan Stern wrote:
> On Wed, 14 May 2014, Greg KH wrote:
>
> > > Is it really safe to rely on the device core always probing drivers in
> > > order of driver registration?
> >
> > Yes it is.
>
> Okay, good. Do you know if this is documented anywhere?
No
On Mon, May 12, 2014 at 11:45:23AM +0530, Pratyush Anand wrote:
> +static DEVICE_ATTR(u3_entry, S_IWUSR, NULL, issue_u3_entry);
For this, and the other DEVICE_ATTR() entries, please use
DEVICE_ATTR_RO() or _RW(), or _WO(), depending on what you are wanting
the permissions to be. I'm trying to get
On Wed, 14 May 2014, Greg KH wrote:
> > Is it really safe to rely on the device core always probing drivers in
> > order of driver registration?
>
> Yes it is.
Okay, good. Do you know if this is documented anywhere?
> > If it is then we are okay (at least in this particular case), because
> >
On Wed, May 14, 2014 at 11:05:44AM -0400, Alan Stern wrote:
> On Wed, 14 May 2014, Pratyush Anand wrote:
> > If that is not true, may be I can do what Bj?rn Mork is suggesting.
> > But that would require change in drivers/base/bus.c:driver_(un)bind.
> >
> > -- Add a new field manual_binding in str
On Wed, 14 May 2014, Pratyush Anand wrote:
> I see some references on different mailing lists that "probe will be
> executed according to object link order which is decided by Makefile".
>
> http://comments.gmane.org/gmane.linux.usb.general/98616
I believe that refers to probing during driver re
On Wed, May 14, 2014 at 09:56:02AM +0530, Pratyush Anand wrote:
> Hi Alan,
>
> PS: For all other comments, will do as you suggested.
> On Tue, May 13, 2014 at 10:28:11PM +0800, Alan Stern wrote:
> > On Tue, 13 May 2014, Pratyush Anand wrote:
> >
> > > > The biggest bug may not be an obvious one.
Pratyush Anand writes:
> If that is not true, may be I can do what Bjørn Mork is suggesting.
> But that would require change in drivers/base/bus.c:driver_(un)bind.
>
> -- Add a new field manual_binding in struct device_driver.
> -- set this flag in drivers_bind before calling driver_probe_device.
Hi Alan,
PS: For all other comments, will do as you suggested.
On Tue, May 13, 2014 at 10:28:11PM +0800, Alan Stern wrote:
> On Tue, 13 May 2014, Pratyush Anand wrote:
>
> > > The biggest bug may not be an obvious one. Suppose the lvstest driver
> > > has been built into the kernel. When the ke
On Tue, 13 May 2014, Pratyush Anand wrote:
> > The biggest bug may not be an obvious one. Suppose the lvstest driver
> > has been built into the kernel. When the kernel boots and the root
> > hubs are registered, what will prevent them all from binding to lvstest
> > instead of the normal hub dr
Hi Alan,
On Mon, May 12, 2014 at 11:19:33PM +0800, Alan Stern wrote:
> On Mon, 12 May 2014, Pratyush Anand wrote:
>
> > OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
> > system (SS-OVS) which consists of an excersizer and analyzer.
> >
> > USB Compliance Suite from Lecr
Alan Stern writes:
> The biggest bug may not be an obvious one. Suppose the lvstest driver
> has been built into the kernel. When the kernel boots and the root
> hubs are registered, what will prevent them all from binding to lvstest
> instead of the normal hub driver?
I don't know if this
On Mon, 12 May 2014, Pratyush Anand wrote:
> OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
> system (SS-OVS) which consists of an excersizer and analyzer.
>
> USB Compliance Suite from Lecroy can act as such SS-OVS for Link Layer
> Validation (LVS).
>
> Some modificati
OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
system (SS-OVS) which consists of an excersizer and analyzer.
USB Compliance Suite from Lecroy can act as such SS-OVS for Link Layer
Validation (LVS).
Some modifications are needed for an embedded Linux USB host to pass all
17 matches
Mail list logo
