writel(0, USB_AHBBURST);
> > - /* Use the AHB transactor */
> > - writel(0, USB_AHBMODE);
> > + /* Use the AHB transactor, allow posted data writes */
> > + writel(0x8, USB_AHBMODE);
> > /* Disable streaming mode and select host mode */
> > writel(0
e_size(res);
> + hcd->regs = devm_ioremap(&pdev->dev, hcd->rsrc_start, hcd->rsrc_len);
> + if (!hcd->regs) {
> + dev_err(&pdev->dev, "ioremap failed\n");
> + ret = -ENOMEM;
> + goto put_hcd;
> + }
>
On Tue, 21 Apr 2015, Ivan T. Ivanov wrote:
>
> On Tue, 2015-04-21 at 11:04 -0400, Alan Stern wrote:
> > On Tue, 21 Apr 2015, Ivan T. Ivanov wrote:
> >
> > > This reverts commit 70843f623b58 ("usb: host: ehci-msm: Use
> > > devm_ioremap_resource i
this patch is in fact _not_ a reversion of 70843f623b58. That
commit removed 4 lines of code and added 3. If this were truly a
reversion, it would remove 3 lines and add 4. Instead it adds 10.
Please make this a true reversion.
Alan Stern
> Cc: Vivek Gautam
> Signed-off-by: Ivan T. Ivano
On Mon, 20 Apr 2015, Ivan T. Ivanov wrote:
>
> On Mon, 2015-04-20 at 10:14 -0400, Alan Stern wrote:
> > On Mon, 20 Apr 2015, Ivan T. Ivanov wrote:
> >
> > > Hi Alan,
> > >
> > > Perhaps I have to resend this patch with updated commit
> > > m
;d like to get an Acked-by from Vivek before accepting this.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This is almost exactly the same as reverting commit 70843f623b58 (usb:
host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap).
Vivek, what do you think?
Alan Stern
> Signed-off-by: Ivan T. Ivanov
> ---
> drivers/usb/host/ehci-msm.c | 10 +++---
> 1 file change
lan, this is ok to me:
>
> Acked-by: Felipe Balbi
Greg, it's okay with me too.
Acked-by: Alan Stern
> > ---
> > drivers/usb/host/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/host/Kconfig b/driver
tage of a control
transfer. Or to omit the Setup stage and go directly to the Data
stage. Then the SINGLE_STEP_GET_DEVICE_DESCRIPTOR test could be
implemented very simply by submitting two URBs with a delay between.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe l
it is done in the newly
merged code. The only difference is that it uses a special test_mode
callback instead of a special selector value.
Didn't you say you wanted a large part of the support moved into
usbcore? For example, the routines that create and enqueue this "URB
with a delay in t
I think it should be hidden by Kconfig, not arguing against that.
Therefore we both agree the $SUBJECT patch should not be accepted in
its current form. At the very least, the new code in ehci-hcd should
be conditional on a CONFIG_USB_HCD_TEST_MODE option. In addition, we
may want some of
ot of testing code
in distribution kernels where it will never be used seems like a big
waste.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
this one test but the entire USB-CV suite.
> > Besides, doesn't USB-CV install its own version of Windows' EHCI driver
> > while it runs its tests?
>
> IIRC only USB20CV, the new USB30CV (which also tests USB2) doesn't do
> that.
I don't have more than
On Thu, 25 Jul 2013, Felipe Balbi wrote:
> On Thu, Jul 25, 2013 at 03:44:20PM -0400, Alan Stern wrote:
> > On Thu, 25 Jul 2013, Greg KH wrote:
> >
> > > On Tue, Jul 02, 2013 at 08:13:52PM -0700, Jack Pham wrote:
> > > > From: Manu Gautam
> > >
is somewhat
fragile, in that it copies part of usbcore into ehci-hcd; updates to
the core will have to be mirrored in the driver.
On the other hand, there's no real reason to reject it, and it could
end up helping people who want to test new USB devices. So...
Acked-by: Alan Stern
--
On Fri, 7 Sep 2012, Alan Stern wrote:
> On Fri, 7 Sep 2012, Pavankumar Kondeti wrote:
>
> > There is a possibility of QH overlay region having reference to a stale
> > qTD pointer during unlink.
> >
> > Consider an endpoint having two pending qTD before unlink proc
region
> + * might have reference to the just unlinked qtd. The
> + * qtd is updated in qh_completions(). Update the QH
> + * overlay here.
> + */
> + if (cpu_to_hc32(ehci, qtd->qtd_dma) == qh->hw->hw_current) {
> +
E);
>
> Can you do this or may there be a CPU that speculatively writes before
> it reads next->link.control ?
CPUs never do speculative writes. And even if they did, the wmb()
would prevent the speculative write from preceding any statement that
comes before the memory barrier.
sary
only for URBs that use bulk streaming rather than for all SuperSpeed
URBs.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 16 Jun 2011, Alan Stern wrote:
> On Thu, 16 Jun 2011, Felipe Balbi wrote:
>
> > Hi,
> >
> > On Thu, Jun 16, 2011 at 11:06:47AM -0400, Alan Stern wrote:
> > > On Thu, 16 Jun 2011, Tatyana Brokhman wrote:
> > >
> > > > This impleme
On Thu, 16 Jun 2011, Felipe Balbi wrote:
> Hi,
>
> On Thu, Jun 16, 2011 at 11:06:47AM -0400, Alan Stern wrote:
> > On Thu, 16 Jun 2011, Tatyana Brokhman wrote:
> >
> > > This implementation adds a new proprietary device control requests (to be
> > > han
*/
> struct usbdevfs_iso_packet_desc iso_frame_desc[0];
> + compat_uint_t stream_id;
> };
It would be nice if we could do this, but we can't. We are not allowed
to change an established ABI. Every copy of libusb would have to be
rebuilt.
Alan Stern
--
To unsubscribe from this l
/* UT: Connect/disconnect the device */
> + schedule_work(&dum_hcd->conn_disc_work);
> + ret_val = 0;
> + break;
> }
> return ret_val;
> }
I forgot to mention... You need to test setup->bRequestType.
Alan Stern
--
To unsubscr
vice is configured).
> This patch is needed for several of UAS test to pass.
Then the tests are broken. NAK.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t_val=%d\n",
> + ret_val);
> +}
>
> /**
> * handle_control_request() - handles all control transfers
> @@ -1534,6 +1572,10 @@ static int handle_control_request(struct dummy_hcd
> *dum_hcd, struct urb *urb,
> *stat
here are arguments against this patch.
I don't care either way. It's up to you and Felipe.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
gle
min_t. All (or almost all) the places this patch touches currently
contain only one typecast, so the motivation for changing them is a lot
weaker.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 10 Jun 2011, Tatyana Brokhman wrote:
> This patch adds a new module parameter to dummy_hcd: is_high_speed
> When set to false the connected device will be forced to operate in FS
> mode. The default of this parameter is true.
>
> Signed-off-by: Tatyana Brokhman
Acked
ind. But "invalid parameter" is probably good
enough, since these are the _only_ parameters. :-) So this part is
okay as it stands.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
tatic int __init init (void)
> if (usb_disabled ())
> return -ENODEV;
>
> + if (!mod_data.is_high_speed && mod_data.is_super_speed)
> + return -EINVAL;
Print an error message in the log so that the user will know why the
failure occurred.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ror is for the user to issue the modprobe command again,
with the correct parameters this time. Therefore the driver should
fail to load, so that the modprobe can be reissued with no need to do
rmmod first.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
est
> to keep the printks to a minimum. Isn't that the general approach? IMO, in
> this particular case informing the user isn't a "must". If you feel strongly
> about it I can add the message.
IMO the driver should print an error message and fail to load if there
are c
ge if the user
specifies is_super_speed = True and is_high_speed = False.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
rticular speed from the
> controller.
Unfortunately this would mean changing a bunch of UDC drivers. But I
agree, it makes sense for the gadget driver to specifically ask for the
pullups to be enabled when it is ready.
Don't some of the existing UDC drivers fail to implement the pullup
method
parameter is
set to False then we know that the emulated connection will never run
at SS. Therefore there's no point in registering a SS root hub.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t/Kconfig
> @@ -626,6 +626,7 @@ config USB_DUMMY_HCD
> depends on USB_GADGET_DUMMY_HCD
> default USB_GADGET
> select USB_GADGET_SELECTED
> + select USB_GADGET_SUPERSPEED
This belongs under USB_GADGET_DUMMY_HCD, next to the "select
USB_GADGET_DUALSPEED" l
ED is selected under USB_GADGET_DUMMY_HCD,
which is the right place for it, I think. Same as all the other UDC
drivers.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ove will be true for HS as well. I mean the
> current speed of composite_driver is set always to HS but if there is a
> function driver that supports only FS then the above will update
> composite_driver.speed to FS.
That's right. The same solution will work for both cases.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
descriptors
are available.
Since these structures are passed to usb_composite_probe() before the
gadget driver is registered, the necessary calculations can be done
there.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ers with the UDC driver ...
and surely that can't happen until all the function drivers have
registered with the composite driver? After all, the gadget can't be
enumerated until all the function drivers are registered.
Maybe this logic can be put in usb_add_function()? That routine
al
On Wed, 25 May 2011, Alan Stern wrote:
> I have looked this over more carefully. It turns out that both of you
> have misunderstood the purpose of CONFIG_USB_GADGET_DUALSPEED (and by
> extension, CONFIG_USB_GADGET_SUPERSPEED). In fact, the existing
> Kconfig file is also wrong.
>
composite_driver.speed to USB_SPEED_SUPER. Otherwise, if all of them
support high speed and CONFIG_USB_GADGET_DUALSPEED is enabled then set
composite_driver.speed to USB_SPEED_HIGH. Otherwise set it to
USB_SPEED_FULL.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe l
missing something?
dummy_hcd should work when CONFIG_USB_GADGET_SUPERSPEED is enabled,
even if the usb_gadget_driver structure is initialized with the speed
field set to USB_SPEED_HIGH. This will be true for all the standalone
gadget drivers until they are updated.
Which leaves a question about the
t's a property of the gadget driver, not the UDC driver. dummy-hcd
> > is a UDC driver (and an HCD too).
>
> USB3.0 dummy_hcd should still enumerate USB2.0 gadget drivers.
Yes, certainly it should. If it doesn't, that's a bug, not a design
error.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
there some other gadget driver that has a fall back to
> full or low speed when high speed enumeration fails?
That's a property of the gadget driver, not the UDC driver. dummy-hcd
is a UDC driver (and an HCD too).
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
quot;which type of cable the
> connection was made over - SS or HS". The "cable type" is exactly what the
> module parameter is.
>
> My familiarity with the Linux host isn't as good as I would like it to be
> (still working on that) so I might be wrong with my con
27;t just fails, it gives the device over to the shared_hcd :-)
It does not. xhci-hcd does not keep track of whether or not
enumeration succeeds, and it doesn't do anything special when
enumeration fails.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
nsigned long _dum_hcd)
> > case USB_SPEED_HIGH:
> > total = 512/*bytes*/ * 13/*packets*/ * 8/*uframes*/;
> > break;
> > + case USB_SPEED_SUPER:
> > + /* Bus speed is 500000 bytes/ms, so use a little less */
>
> isn't it
gt; }
In several places you open-coded dummy_hcd_to_hcd(). Please change
them to use the inline routine instead.
> -static inline struct device *dummy_dev (struct dummy *dum)
> +static inline struct device *dummy_dev(struct dummy_hcd *dum)
> {
> - return dummy_to_hcd(dum)->self.
because dummy-hcd does not handle any
hardware interrupts.
> Also, Sergei pointed out that IRQF_DISABLED is deprecated so it seems to me
> that xhci needs an update as well
Plus every other source file that uses IRQF_DISABLED...
Alan Stern
--
To unsubscribe from this list: send
> over to studying that and applying it to the UAS gadget driver.
I'm not familiar with that framework either, so if you find any good
introductory documentation (other than the files in
Documentation/target) please post a link to it. Nicholas Bellinger is
very willing to answer qu
sn't what we wanted then, but it is what we're
interested in now.
Getting things to switch back might be harder -- re-enabling the
SuperSpeed terminations won't force the device to stop using the USB-2
bus. It might be necessary to reset the USB-2 port.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
LUN,
> or up to .can_queue commands for all LUNs.
For all LUNs.
Since Tanya is writing the gadget driver, she gets to decide how many
streams it will support (limited by the device controller hardware).
In this setting I would use one thread per stream, since a thread can't
elds.
> unsignedmult:2;
> unsignedpad:1;
> unsignedmaxburst:4;
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
. They implement Bulk-Only Transport on altsetting 0 and
UAS on altsetting 1.
On the other hand, I don't think there's anything that says you _have_
to do it that way...
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a mess
and secondary HCDs, representing the USB-2 and USB-3 root hubs
of an xHCI controller. dummy-hcd should use the same mechanism.
This will means creating only one host-side platform device, and then
creating two usb_hcd structures below it. Tanya's design should be
based on Sarah'
HIFT (General setup
/ Kernel log buffer size, if you use "make menuconfig").
> There will be a lot of messages, but you can capture them by running
> this command line:
>
> tail -f /var/log/kern.log | tee logfile.txt
This is not as reliable as using dmesg. When a lot of mes
ing something?
No, you are right. However, it is still true even with SS that the
value is contained in bits 0..10, since the value can never be larger
than 2047.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Also, you might try running this patch through checkpatch.pl and fixing
> > any complaints it makes.
> >
>
> Actually I always do that. It came out clean. If you see something wrong
> with the coding style please let me know.
There are a few places where a terminating ';&#x
at 500 million bytes/s, not 400
million. For another, 400 << 20 isn't equal to 400 million.
Don't try to be too clever. Realizing that this is only an
approximation anyway, just say:
/* Bus speed is 50 bytes/ms, so use a little less */
to
less, the title and the first sentence in the patch description
contain two errors. First, there is no such thing as UASP. What
you're talking about is UAS -- USB-Attached SCSI. Second, the patch
set implements a gadget (or function) driver, not a device driver.
Alan Stern
--
To unsubscribe
ise it is an empty inline routine.
But taking the address of an inline routine forces the compiler to
produce an out-of-line version. Therefore you might as well explicitly
define usb_hnp_polling_work() as an empty function when CONFIG_USB_OTG
isn't set.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
S, USB_DIR_IN | USB_RECIP_DEVICE,
> >+0, OTG_STATUS_SELECTOR, status, sizeof(*status),
>
> 0, OTG_STATUS_SELECTOR, &status, sizeof(status);
> ??
You mustn't do DMA to addresses on the stack.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe
s should allow
you to eliminate many of them.
Also, in the 5/5 patch in hub_activate(), all those
if (hdev->bus->is_b_host && type == HUB_INIT)
tests are distracting. You can make the test once, at the start of the
function, and store the result in a local variable.
Alan Ste
PEND);
> + if (ret)
> + dev_info(&udev->dev, "suspend failed\n");
> + } else {
> + schedule_delayed_work(&bus->hnp_polling,
> + msecs_to_jiffies(THOST_REQ_POLL));
> + }
> +out:
> + kfree(status);
> +}
> +#endif
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
bus transfer rate of 500 million bytes/s it
seems clear that you can't transfer more than 50 bytes per frame.
The actual limit must be lower than that, maybe something like 1024
bytes/packet * 60 packets/uframe * 8 uframes/frame = 491520
bytes/frame.
Alan Stern
--
To unsubscribe from
int handle_control_request(struct dummy *dum, struct urb *urb,
> + struct usb_ctrlrequest setup,
Don't pass "setup" by value! Pass it by reference, i.e., pass a
pointer to the "setup" variable in dummy_timer().
> +
k it up if you could refer me to it.
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-07-usb/usb-core-use-kernel-assigned-address-for-devices-under-xhci.patch
> > Also, the address_device routine should not change udev->devnum. The
> > code that does this i
picious. Why have this function if it's only going
to do the same thing that usbcore would do if it weren't present?
Also, the address_device routine should not change udev->devnum. The
code that does this in the xhci driver is being removed, because it
causes bugs.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
case USB_DEVICE_LTM_ENABLE:
> + if (dum->gadget.speed == USB_SPEED_SUPER)
> + w_value = USB_DEV_STAT_LTM_ENABLED;
> + else
> + ret_val = -EOPNOTSUPP;
> +
+ .queue = msm72k_queue,
> + .dequeue= msm72k_dequeue,
> +
> + .set_halt = msm72k_set_halt,
> + .fifo_flush = msm72k_fifo_flush,
> +};
The .set_wedge method is missing.
Alan Stern
--
To unsubscribe from this list: send the line "unsubs
71 matches
Mail list logo
