Hi,
Pratyush Anand writes:
> Hi Felipe,
>
> On Friday 09 June 2017 11:43 AM, Felipe Balbi wrote:
>> +static void notrace ftrace_write(struct trace_export *ftrace, const void
>> *buf,
>> + unsigned int len)
>> +{
>> +struct usb_ftrace *trace = ftrace
Hi,
Pratyush Anand writes:
> On Friday 09 June 2017 03:58 PM, Felipe Balbi wrote:
>> Felipe Balbi writes:
>>
>>> Allow for ftrace data to be exported over a USB Gadget
>>> Controller. With this, we have a potentially very fast pipe for
>>> transmitting ftrace data to a Host PC for further analy
On Fri, 14 Jul 2017, Gargi Sharma wrote:
> Earlier bitmap was traversed to find the pid greater or equal to nr
> (passed as a parameter). Now a call to idr_get_next fetches the id
> greater than or equal to nr.
>
> Signed-off-by: Gargi Sharma
> ---
> kernel/pid.c | 8 +---
> 1 file changed
On Fri, 14 Jul 2017, Gargi Sharma wrote:
> In pid_alloc function, idr_preload function is used along with
> idr_alloc_cyclic.
> idr_alloc_cyclic is used instead of idr_alloc because we might want to
> reuse the unassigned integers. The rest of the code is same as the previous
> alloc_pid, which
Hi Felipe,
On Friday 09 June 2017 03:58 PM, Felipe Balbi wrote:
Felipe Balbi writes:
Allow for ftrace data to be exported over a USB Gadget
Controller. With this, we have a potentially very fast pipe for
transmitting ftrace data to a Host PC for further analysis.
Note that in order to decode
Hi Felipe,
On Friday 09 June 2017 11:43 AM, Felipe Balbi wrote:
+static void notrace ftrace_write(struct trace_export *ftrace, const void *buf,
+unsigned int len)
+{
+ struct usb_ftrace *trace = ftrace_to_trace(ftrace);
+ struct usb_reque
This function is called by init/main.c and earlier used to allocate
space to pidmap. Now idr struct for init_pid_ns is initialised and ID 0
alocated using idr_alloc_cyclic. Also deleted NULL allocation for
pidmap.
Signed-off-by: Gargi Sharma
---
include/linux/pid_namespace.h | 2 +-
init/main.c
Add idr struct and the mutex lock corresponding to
this struct to pid_namespace struct. Use IDR API for implementing
create_pid_namespace. The only change in the function is that instead of
allocating a bitmap, now idr_init is used to initialise the radix tree
associated with this namespace. This t
Earlier bitmap was traversed to find the pid greater or equal to nr
(passed as a parameter). Now a call to idr_get_next fetches the id
greater than or equal to nr.
Signed-off-by: Gargi Sharma
---
kernel/pid.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/kernel/pid.c
These functions are no longer used anywhere in the kernel
and hance can be safely deleted. Earlier they were used for various
pidmap functions, for example, next_pidmap(nr) was used to find the
integer in the bitmap greater than or equal to the parameter nr.
Signed-off-by: Gargi Sharma
---
kerne
Delete mk_pid(), pid_before() and set_last_pid(). These functions were
earlier used by alloc_pidmap(), next_pidmap() and free_pidmap() and are
no longer required.
Signed-off-by: Gargi Sharma
---
kernel/pid.c | 45 -
1 file changed, 45 deletions(-)
dif
All allocated pids were searched for in the bitmap and removed to exit
from the processes. The lookup is now done using idr_get_next, which
will find out the next allocated id. nr, the parameter passed to
idr_get_next is set to 2 because idr_get_next() fetches the idr entry
equal to or greater than
In pid_alloc function, idr_preload function is used along with
idr_alloc_cyclic.
idr_alloc_cyclic is used instead of idr_alloc because we might want to
reuse the unassigned integers. The rest of the code is same as the previous
alloc_pid, which puts the pid allocated onto the task list. After the f
Instead of freeing individual pages of the bitmap for the namespace,
call idr_destroy() on the idr struct for the namespace.
Signed-off-by: Gargi Sharma
---
kernel/pid_namespace.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/pid_namespace.c b/kernel/pid_namesp
This patchset contains patches for PID allocation. Individual patches
in the series break the kernel. But once, the patchset is applied, the
kernel compiles. We have to figure out whether to send this as one whole patch
or if to send in a series, how to break the patches so that it does not break
t
Hi, Lu
At 07/13/2017 11:00 AM, Lu Baolu wrote:
Hi,
On 07/13/2017 09:39 AM, Dou Liyang wrote:
Hi, Lu
At 07/13/2017 09:17 AM, Lu Baolu wrote:
Hi,
On 07/12/2017 04:02 PM, Dou Liyang wrote:
Hi, Lu
At 05/05/2017 08:50 PM, Boris Ostrovsky wrote:
On 05/05/2017 01:41 AM, Lu Baolu wrote:
Hi,
On
Quoting Peter Rosin (2017-07-11 22:04:46)
> On 2017-07-12 03:02, Stephen Boyd wrote:
> > This patchset adds support for the TC7USB40MU usb mux found on
> > db410c 96boards platforms via the new multiplexer framework and
> > hooks that into the chipidea driver. This allows us to properly
> > contro
Quoting Peter Rosin (2017-07-11 23:45:24)
> On 2017-07-12 03:02, Stephen Boyd wrote:
> > @@ -102,4 +107,7 @@ Example:
> > rx-burst-size-dword = <0x10>;
> > extcon = <0>, <&usb_id>;
> > phy-clkgate-delay-us = <400>;
> > + mux-controls = <&usb_swi
Alan Stern wrote on 14/07/17 02:30:
All right. In the meantime, changing usb-storage won't hurt.
Arthur, can you test the patch below?
Alan Stern
Index: usb-4.x/drivers/usb/storage/usb.c
===
--- usb-4.x.orig/drivers/usb/stora
> -Original Message-
> From: Petr Kulhavy [mailto:br...@jikos.cz]
> Sent: Thursday, July 13, 2017 1:41 PM
> To: steve.glendinn...@shawell.net; UNGLinuxDriver
> Cc: net...@vger.kernel.org; linux-usb@vger.kernel.org; Petr Kulhavy
> Subject: [PATCH] smsc95xx: use ethtool_op_get_ts_info()
>
>
This change enables the use of SW timestamping on Raspberry PI.
smsc95xx uses the usbnet transmit function usbnet_start_xmit(), which
implements software timestamping. However the SOF_TIMESTAMPING_TX_SOFTWARE
capability was missing and only SOF_TIMESTAMPING_RX_SOFTWARE was announced.
By using etht
On Wed, 12 Jul 2017, Christoph Hellwig wrote:
> On Wed, Jul 12, 2017 at 12:10:02PM -0400, Alan Stern wrote:
> > This is pretty conclusive. The problem comes about because
> > usb_stor_control_thread() calls scsi_mq_done() while holding
> > shost->host_lock, and then scsi_eh_scmd_add() tries to ac
On Wed, 12 Jul 2017 10:50:03 +0200
Johan Hovold jo...@kernel.org wrote:
...
>IIRC we should be able read from the EEPROM, and I would at least expect
>there to be a way to retrieve the current mode as well.
I've just send a patch for ftdi_sio.
Thanks,
Anatolij
--
To unsubscribe from this list: s
On FT232H the interface mode can be configured in the EEPROM,
and the async UART mode is configured by default. The chip is
also in async UART mode if no EEPROM is connected.
Check the EEPROM configuration and do not bind as serial device
when different interface mode is programmed in the EEPROM.
On Thu, 13 Jul 2017, Bin Liu wrote:
> On Fri, Jul 07, 2017 at 11:56:53AM -0400, Alan Stern wrote:
> > On Fri, 7 Jul 2017, Bin Liu wrote:
> >
> > > While unlink an urb, if the urb has been programmed in the controller,
> > > the controller driver might do some hw related actions to tear down the
>
On Fri, Jul 07, 2017 at 11:56:53AM -0400, Alan Stern wrote:
> On Fri, 7 Jul 2017, Bin Liu wrote:
>
> > While unlink an urb, if the urb has been programmed in the controller,
> > the controller driver might do some hw related actions to tear down the
> > urb.
> >
> > Currently usb_hcd_flush_endpoi
On Thu, 13 Jul 2017, Felipe Balbi wrote:
> Hi,
>
> Alan Stern writes:
>
> > Felipe:
> >
> > On Thu, 29 Jun 2017, kernel test robot wrote:
> >
> >> FYI, we noticed the following commit:
> >>
> >> commit: f16443a034c7aa359ddf6f0f9bc40d01ca31faea ("USB: gadgetfs,
> >> dummy-hcd, net2280: fix loc
By submitting completed transfers to the system workqueue there is no
guarantee that completion events will be queued up in the correct order,
so if a large bulk transfer is being read with aio the data may arrive
in the wrong order.
Create a single-threaded workqueue for FunctionFS so that comple
On 13/07/17 12:36, Bjorn Helgaas wrote:
> On Thu, Jul 13, 2017 at 08:46:45AM +0100, Marc Zyngier wrote:
>> On 13/07/17 07:48, Ard Biesheuvel wrote:
>>> On 13 July 2017 at 04:12, Bjorn Helgaas wrote:
On Mon, Jul 10, 2017 at 04:52:28PM +0100, Marc Zyngier wrote:
> Ard and myself have just s
Hi,
Felipe Balbi writes:
> Allow for ftrace data to be exported over a USB Gadget
> Controller. With this, we have a potentially very fast pipe for
> transmitting ftrace data to a Host PC for further analysis.
>
> Note that in order to decode the data, one needs access to kernel
> symbols in ord
On Thu, Jul 13, 2017 at 10:26:40AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 12, 2017 at 10:12:34PM -0500, Bjorn Helgaas wrote:
> > On Mon, Jul 10, 2017 at 04:52:28PM +0100, Marc Zyngier wrote:
> > > Ard and myself have just spent quite some time lately trying to pin
> > > down an issue in the
On Thu, Jul 13, 2017 at 08:46:45AM +0100, Marc Zyngier wrote:
> On 13/07/17 07:48, Ard Biesheuvel wrote:
> > On 13 July 2017 at 04:12, Bjorn Helgaas wrote:
> >> On Mon, Jul 10, 2017 at 04:52:28PM +0100, Marc Zyngier wrote:
> >>> Ard and myself have just spent quite some time lately trying to pin
>
This enables the platform-roothub for the xhci-plat driver. This allows
specifying a PHY for each port via devicetree. All PHYs will then be
enabled/disabled by the platform-roothub driver.
One example where this is required is the Amlogic GXL and GXM SoCs:
They are using a dwc3 USB controller wit
Many SoC platforms have separate devices for the USB PHY which are
registered through the generic PHY framework. These PHYs have to be
enabled to make the USB controller actually work. They also have to be
disabled again on shutdown/suspend.
Currently (at least) the following HCI platform drivers
This series is the outcome of a discussion with Felipe Balbi,
see [0] and [1].
The quick-summary of this is:
- dwc3 already takes one USB2 and one USB3 PHY and initializes these
correct
- some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and
ohci-platform.c) do not have a limita
A USB root-hub may have several PHYs which need to be configured before
the root-hub starts working.
This adds the documentation for such a USB root-hub.
Signed-off-by: Martin Blumenstingl
---
.../devicetree/bindings/usb/usb-roothub.txt| 46 ++
1 file changed, 46 inse
On Wed, Jul 12, 2017 at 10:12:34PM -0500, Bjorn Helgaas wrote:
> On Mon, Jul 10, 2017 at 04:52:28PM +0100, Marc Zyngier wrote:
> > Ard and myself have just spent quite some time lately trying to pin
> > down an issue in the DMA code which was taking the form of a PCIe USB3
> > controller issuing a
On 13/07/17 07:48, Ard Biesheuvel wrote:
> On 13 July 2017 at 04:12, Bjorn Helgaas wrote:
>> On Mon, Jul 10, 2017 at 04:52:28PM +0100, Marc Zyngier wrote:
>>> Ard and myself have just spent quite some time lately trying to pin
>>> down an issue in the DMA code which was taking the form of a PCIe U
Hi,
On 13 July 2017 at 15:26, Manu Gautam wrote:
>
>
> On 7/13/2017 11:33 AM, Baolin Wang wrote:
>> On 12 July 2017 at 16:58, Manu Gautam wrote:
>>>
>>> On 7/12/2017 2:06 PM, Baolin Wang wrote:
Hi,
On 12 July 2017 at 15:25, Manu Gautam wrote:
>
> On 7/12/2017 12:19 PM, Ba
On 7/13/2017 11:33 AM, Baolin Wang wrote:
> On 12 July 2017 at 16:58, Manu Gautam wrote:
>>
>> On 7/12/2017 2:06 PM, Baolin Wang wrote:
>>> Hi,
>>>
>>> On 12 July 2017 at 15:25, Manu Gautam wrote:
On 7/12/2017 12:19 PM, Baolin Wang wrote:
> Hi,
>
> On 3 July 2017 at 19:25,
40 matches
Mail list logo
