giveback_urb_bh, bh);
> + struct giveback_urb_bh *bh = from_work(bh, t, bh);
> struct list_head local_list;
>
> spin_lock_irq(>lock);
Is there any reason for this apparently pointless change of a local
variable's name?
Alan Stern
> Tested on AmigaOne X5000/20 and X5000/40 Contains code by Rob Herring
> > (in fsl-mph-dr-of.c)
>
> Thanks for fixing.
>
> Acked-by: Rob Herring
Okay for me too.
Acked-by: Alan Stern
rrent state of affairs, I vote in favor of 1 (plus a WARN or
something similar to generate a stack dump in the callee, since double
registration really is a bug).
Alan Stern
urs when
a notifier callback is added twice, not when a caller fails to check the
return code. Double-registration is not the sort of thing that can be
detected at build time.
Alan Stern
> Due to the sheer volume of the patches, I have addressed the respective
> patch and the last one, whic
On Fri, Jul 17, 2020 at 12:22:49PM -0400, Mathieu Desnoyers wrote:
> - On Jul 17, 2020, at 12:11 PM, Alan Stern st...@rowland.harvard.edu
> wrote:
>
> >> > I agree with Nick: A memory barrier is needed somewhere between the
> >> > assignment at 6 and the ret
as to ensure that it executes
after the IPI-induced memory barrier on CPU1. If it happened before
then we could still end up with r1 = 0. That's why the pairing matters.
I hope this helps your head get properly wrapped. :-)
Alan Stern
On Fri, Jul 17, 2020 at 09:39:25AM -0400, Mathieu Desnoyers wrote:
> - On Jul 16, 2020, at 5:24 PM, Alan Stern st...@rowland.harvard.edu wrote:
>
> > On Thu, Jul 16, 2020 at 02:58:41PM -0400, Mathieu Desnoyers wrote:
> >> - On Jul 16, 2020, at 12:03
s say that a writes to X and 9
reads from X.
Then we have an instance of the Store Buffer pattern:
CPU0CPU1
a. Write X 6. Write rq->curr for user thread
c. smp_mb() 7. switch_to memory barrier
d. Read rq->curr9. Read X
In this pattern, the memory barriers make it impossible for both reads
to miss their corresponding writes. Since d does fail to read 6 (it
sees the earlier value stored by 4), 9 must read a.
The other guarantee you need is that g on CPU0 will observe anything
written by CPU1 in 1. This is easier to see, using the fact that 3 is a
memory barrier and d reads from 4.
Alan Stern
have a respun version ready, but I'd really like to hear some
> comments from usb developers about the approach before spamming
> everyone again..
I didn't see any problems with your approach at first glance; it looked
like a good idea.
Alan Stern
the declaration
so that it says:
status u64 dummy_mask = DMA_BIT_MASK(32);
and remove the line that does the assignment dynamically.
Alan Stern
On Thu, 19 Jul 2018, Geoff Levand wrote:
> Hi Alan,
>
> On 07/19/2018 07:33 AM, Alan Stern wrote:
> > On Wed, 18 Jul 2018, Geoff Levand wrote:
> >
> >> diff --git a/drivers/usb/host/ehci-ps3.c b/drivers/usb/host/ehci-ps3.c
> >> index 8c733492d8fe..454d8c62
}
>
> - dev->core.dma_mask = _mask; /* FIXME: for improper usb code */
> + dummy_mask = DMA_BIT_MASK(32);
> + dev->core.dma_mask = _mask;
> + dma_set_coherent_mask(>core, dummy_mask);
Same here.
Alan Stern
, it might turn out that the
hardware you are using contains a bug of a sort I have seen in the
past. In that case, programming a workaround wouldn't take more than a
few hours, once I knew what was going on.
Alan Stern
___
Linuxppc-dev mailing list
source
file Documentation/usb/usbmon.txt.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
driver; I tried manually but it turned into compiler errors...
It looks like the configurator is smart; it won't let you select the
wrong driver for your hardware.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
the driver software.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
with a USB-2 host controller, boot it from a Live-CD version of Linux,
plug in your hub with the codecs, and see what happens.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
not at the
right place to ask these questions. I can also provide some code if
someone need it to help.
Your first step should be to use an up-to-date kernel, as recommended
by other people.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev
, if you can't figure out
a reasonable way to encapsulate the differences.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
the check for platform data and instead
provide reasonable defaults if no platform data is present. This is
similar to what is currently done in ehci-platform.c.
Signed-off-by: Alistair Popple alist...@popple.id.au
Acked-by: Alan Stern st...@rowland.harvard.edu
As Arnd pointed out, this patch
of whether to merge ehci-ppc-of into
ehci-platform. This would be a rather invasive change, but I suppose
we could do it. With adjustments along the lines suggested by Mark
Rutland.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
the formatting fix)? No other drivers currently use usb-ochi so
it
shouldn't require any merging of drivers.
Yes, go ahead (as long as you use the right spelling, as Ben pointed
out).
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
than one EHCI controller using
ehci-platform. To accomodate such cases, it would be necessary to
allocate a separate copy of ehci_platform_defaults for each controller.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
and instead
provide reasonable defaults if no platform data is present. This is
similar to what is currently done in ehci-platform.c.
Signed-off-by: Alistair Popple alist...@popple.id.au
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-...@vger.kernel.org
---
drivers/usb/host/ohci-platform.c
On Tue, 5 Nov 2013, Alistair Popple wrote:
The IBM Akebono board has an EHCI compliant USB host interface. This
patch adds support for it to the EHCI platform driver.
Signed-off-by: Alistair Popple alist...@popple.id.au
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-...@vger.kernel.org
settings.
I don't know to what extent the same may be true for the other,
platform-specific, drivers changed by this patch. But it's something
to be aware of.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org
(struct usb_hcd *hcd)
if (retval)
return retval;
- if (ehci_is_TDI(ehci))
- tdi_reset(ehci);
-
ehci_reset(ehci);
return 0;
Acked-by: Alan Stern st...@rowland.harvard.edu
This should be applied to stable kernels going back to 3.6.
In case you
On Mon, 19 Nov 2012, Bill Pemberton wrote:
CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
For all the __devinit* annotations and all the EHCI, OHCI, and UHCI
drivers:
Acked-by: Alan Stern st
deletions(-)
I assume this should be considered a bug fix and be looked at for
inclusion in
v3.6?
- k
[Shengzhou] Yes.
Greg,
ping?
Greg is away on vacation for the rest of this week.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev
that.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
the motivation for changing them is a lot
weaker.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
to you and Felipe.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
an explicit default set
Kconfig will default to disabling it and if anything enabling it is the
option that requires special effort.
This may be a naive suggestion, but have you considered simply _asking_
the people who added those defconfigs?
Alan Stern
= dwc_otg_pcd_alloc_request,
+ .free_request = dwc_otg_pcd_free_request,
+ .queue = dwc_otg_pcd_ep_queue,
+ .dequeue = dwc_otg_pcd_ep_dequeue,
+ .set_halt = dwc_otg_pcd_ep_set_halt,
+ .fifo_status = NULL,
+ .fifo_flush = NULL,
+};
This is missing a .set_wedge method.
Alan Stern
and the corresponding
behavior. That can stand by itself, and once it is accepted the rest
of your series should go through with no difficulty (at least, no
difficulties involving the USB core!).
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev
PIO is always true, but in the
future it won't be.
So this assumes that transfer_dma should be set initially to 0 when
allocating USB buffers for HCD_NO_COHERENT_MEM.
No, it should be set to ~0, the same as when buffers are allocated for
a PIO-based controller.
Alan Stern
=126477569707174w=2
See especially this email:
http://marc.info/?l=linux-usbm=126630714002200w=2
Should I make provisions for this check now too?
Don't worry about it. If you structure the code as I described, it
will be easy to insert the check later on.
Alan Stern
be
removed.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
much effort.
That might make a good project.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
is recorded in the URB flags.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
of handling.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, 4 Feb 2010, Albert Herranz wrote:
Hi Alan,
Alan Stern wrote:
This description sounds hopelessly confused. Maybe you're just
misusing the term coherent. The patch itself doesn't affect the
coherent DMA mappings anyway; it affects the streaming mappings. Or to
put it another
address for port 2 (error -62)
Those are normal. They occur because your system loads ohci-hcd before
ehci-hcd. It should load ehci-hcd first.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo
but have not had time to fix
this bug. It is on my todo list. Please feel free to make an
attempt.
Where is the information about the hardware errata you mentioned?
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
, then I guess there's nothing more I can do regarding Bug #13304.
Can you take it over?
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
of the breakpoint addresses. That's more like what the
x86 code does.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
*/
+ if (!bp)
+ return rc;
Shouldn't this test be moved outside the if statement, as in the x86
code?
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
= ksym_name;
+ sample_hbp.info.type = DABR_DATA_WRITE;
This should be HW_BREAKPOINT_WRITE, not DABR_DATA_WRITE.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Wed, 24 Dec 2008, Anton Vorontsov wrote:
Follow these changes for the FHCI driver:
commit e9df41c5c5899259541dc928872cad4d07b82076
Author: Alan Stern st...@rowland.harvard.edu
Date: Wed Aug 8 11:48:02 2007 -0400
USB: make HCDs responsible for managing endpoint queues
On the whole
. The driver is missing some critical calls to functions like
usb_hcd_link_urb_to_ep().
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
at this
point. In fact the disconnect call is what quiesces the driver!
And wouldn't it be better to _skip_ doing this if the gadget wasn't
connected before?
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo
talking about the
gadget driver.
+skip_quiesce:
/* unbind gadget and unhook driver. */
driver-unbind(udc_controller-gadget);
udc_controller-gadget.dev.driver = NULL;
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
that it does not cause a build error on
non-PowerPC architectures.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
you have to apply them both.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
this on a non-PPC440EPx system? It looks like
this patch would cause a compile error.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
then. Nothing really
wrong
No. If the hubs run at high speed then they must have transaction
translators; it's required by the USB 2.0 specification.
Did you try using them with ohci-hcd not loaded?
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev
up so that
they don't affect people who aren't building kernels for 44x systems.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
it isn't necessary to set CONFIG_SLEEP,
CONFIG_HIBERNATION, or CONFIG_USB_SUSPEND.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
.
If the gadget hardware drivers were registering the device with a
gadget_bus_type, you could still enforce the only one protocol
rule by binding every protocol to every device in that bus type.
There is no such rule.
Alan Stern
___
Linuxppc-dev
On Fri, 29 Aug 2008, Arnd Bergmann wrote:
On Friday 29 August 2008, Alan Stern wrote:
I thought you _were_ arguing against that. Unless I misunderstood,
your original complaint was that since each peripheral controller
driver defines usb_gadget_{un}register_driver, there can be only one
.
A little more tweaking will be needed to handle system sleeps. But
this should be a good start.
What to do when CONFIG_PM is off is a separate matter. Let's not worry
about it for now -- especially since, as Matthias suggested, you can
use a USB 2.0 hub.
Alan Stern
it; it's not just a case of bad design.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
then your patch
shouldn't be needed, because then ohci-hcd will automatically suspend
the OHCI root hub 1 second after the last full/low-speed device is
unplugged. You could reduce that 1 second value if you wanted to
decrease the probability of conflicts.
Alan Stern
On Thu, 28 Aug 2008, Scott Wood wrote:
Alan Stern wrote:
This was done deliberately. The relevant standards state that a USB
device can have no more than one peripheral interface.
Does building a kernel image that can run on different hardware without
rebuilding also violate
On Thu, 28 Aug 2008, Steven A. Falco wrote:
Alan Stern wrote:
Your original post mentioned that the 440EPx has only one USB 2.0 host
port. Then how can you use a keyboard and memory stick at the same
time? You'd have to plug them into a hub -- in which case only one
controller would
:
irq_dispose_mapping(irq);
I doubt this will interact properly with usbcore and the rest of
ohci-hcd. They do not expect the root hub to be suspended unless they
know about it.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https
that
an unlink is valid. If you're about to giveback an URB then you
already know it's valid to do so.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
.
+ }
+ spin_unlock_irqrestore(c67x00-lock, flags);
+}
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
for that I can do the test he suggested to you or Paul a
while ago.
Isn't it true that the freezer _already_ isn't enabled on PPC? So
leaving it off wouldn't break anything more than it is broken now.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev
favorite char device driver: How will it behave if a user task submits
an I/O request after the device has been suspended?)
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
for system sleep. (I should test and
make sure that really works...)
But aren't there other kernel threads scattered around that still
want to be frozen? For instance, drivers/misc/tifm_core.c calls
create_freezeable_workqueue(). And set_freezable() gets called in lots
of places.
Alan
71 matches
Mail list logo
