Hi,
Felipe Balbi writes:
[...]
>>> Any ideas on how to debug this would be apreciated.
>>
>> You can start by enabling verbose debugging in f_mass_storage.c.
>> Uncomment the two lines that say:
>>
>> /* #define VERBOSE_DEBUG */
>> /* #define DUMP_MSGS */
>>
>> You'll probably also have to en
> -Original Message-
> From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> Sent: Friday, September 02, 2016 12:09 PM
> To: Nava kishore Manne
> Cc: Soren Brinkmann ; robh...@kernel.org;
> pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@
Hi,
Felipe Balbi writes:
Any ideas on how to debug this would be apreciated.
>>>
>>> You can start by enabling verbose debugging in f_mass_storage.c.
>>> Uncomment the two lines that say:
>>>
>>> /* #define VERBOSE_DEBUG */
>>> /* #define DUMP_MSGS */
>>>
>>> You'll probably also have to e
This patch adds support for Infineon flashloader 0x8087/0x0801.
The flashloader is used in Telit LE940B modem family with Telit
flashing application.
Following lsusb output for the composition:
Bus 004 Device 020: ID 8087:0801 Intel Corp.
Device Descriptor:
bLength18
bDescri
This patch adds support for Infineon flashloader 0x8087/0x0801.
The flashloader is used in Telit LE940B modem family with Telit
flashing application.
Signed-off-by: Daniele Palmas
---
drivers/usb/serial/usb-serial-simple.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dr
On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>
> Hi Felipe and Arnd,
>
> It has been a while since the last response to this discussion, but we
> haven't reached an agreement yet! Can we get to a conclusion on if it
> is valid to create child platform device for abstraction purpo
On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
> >
> > Hi Felipe and Arnd,
> >
> > It has been a while since the last response to this discussion, but we
> > haven't reached an agreement yet! Can we get to a conclusio
Hi,
Arnd Bergmann writes:
> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>>
>> Hi Felipe and Arnd,
>>
>> It has been a while since the last response to this discussion, but we
>> haven't reached an agreement yet! Can we get to a conclusion on if it
>> is valid to create child
Hi,
Russell King - ARM Linux writes:
> On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>> >
>> > Hi Felipe and Arnd,
>> >
>> > It has been a while since the last response to this discussion, but we
>> > haven't reac
On 2016-09-02 03:30, Stephen Boyd wrote:
(Please trim replies)
sorry, will take care from next time.
Quoting Vivek Gautam (2016-08-31 23:17:55)
On Thu, Sep 1, 2016 at 6:10 AM, Stephen Boyd
wrote:
> +
> + uphy->cal_sleep_clk = clk = devm_clk_get(&ulpi->dev, "cal_sleep");
> + if
On Tue, Aug 16, 2016 at 04:42:23PM +0300, Binyamin Sharet wrote:
> Kernel version: raspberrypi 4.4.6-v7+ #871
> Kernel version: 4.4.0-24-generic #43-Ubuntu SMP
> Driver source file: drivers/staging/media/lirc/lirc_imon.c
> Umap2 command line: umap2vsscan -P -s 0aa8:8001
>
> After connecting such
On 02/09/16 11:53, Felipe Balbi wrote:
>
> Hi,
>
> Arnd Bergmann writes:
>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>>>
>>> Hi Felipe and Arnd,
>>>
>>> It has been a while since the last response to this discussion, but we
>>> haven't reached an agreement yet! Can we get to
Hi,
After confusing Greg, here’s the current status of all 11 issues initially
reported by us.
Since the initial tests were done on a rather old kernel (4.4) we retested on
4.7 and 4.8-rc2,
so, not reproduced means - not reproduced on 4.7 and 4.8-rc2.
The issues appear with the same numbering
Hi,
Felipe Balbi writes:
> [ Unknown signature status ]
>
> Hi,
>
> Felipe Balbi writes:
> Any ideas on how to debug this would be apreciated.
You can start by enabling verbose debugging in f_mass_storage.c.
Uncomment the two lines that say:
/* #define VERBOSE_DEBU
On Fri, Sep 02, 2016 at 12:02:12PM +, Hoefle Marco wrote:
> Hello Jaewon Kim,
> Please find the extended driver which allows configuring the gpout feature of
> the MAX3421 via DeviceTree.
> Please check and if ok I'll send a patch.
A patch is the only way we can review a driver.
Please subm
On Fri, Sep 02, 2016 at 12:09:40PM +, Binyamin Sharet (bsharet) wrote:
> Hi,
>
> After confusing Greg, here’s the current status of all 11 issues initially
> reported by us.
>
> Since the initial tests were done on a rather old kernel (4.4) we retested on
> 4.7 and 4.8-rc2,
> so, not reprod
> On 2 Sep 2016, at 15:31, Greg KH wrote:
>
> On Fri, Sep 02, 2016 at 12:09:40PM +, Binyamin Sharet (bsharet) wrote:
>> Hi,
>>
>> After confusing Greg, here’s the current status of all 11 issues initially
>> reported by us.
>>
>> Since the initial tests were done on a rather old kernel (4
Hi,
Robin Murphy writes:
It has been a while since the last response to this discussion, but we
haven't reached an agreement yet! Can we get to a conclusion on if it
is valid to create child platform device for abstraction purpose? If
yes, can this child device do DMA by it
On Friday, September 2, 2016 12:55:33 PM CEST Robin Murphy wrote:
>
> Huh? There's only no DMA description in DT if the device can be assumed
> to be happy with the defaults. Anything else should be using
> "dma-ranges", "dma-coherent", etc. to describe non-default integration
> aspects. For devic
On Thu, Aug 18, 2016 at 03:46:46PM -0700, Tony Lindgren wrote:
> Hi all,
>
> Here's a series of patches to simplify musb PM runtime support further.
>
> I finally figured out that we can get rid of most of the glue layer
> specific workarounds by following the devctl session bit in musb core.
>
On Thu, Aug 18, 2016 at 03:46:47PM -0700, Tony Lindgren wrote:
> We want to keep musb enabled always when the session bit is
> set. This simplifies the PM runtime and allows making it more
> generic across the various glue layers.
>
> So far the only exception to just following the session bit is
On Thu, Aug 18, 2016 at 03:46:48PM -0700, Tony Lindgren wrote:
> We want to be polling the state when nothing is connected.
> Let's change the polling logic in preparation for PM runtime
> support.
>
> Signed-off-by: Tony Lindgren
> ---
> drivers/usb/musb/musb_dsps.c | 24 +++
Hi,
Felipe Balbi writes:
> Hi,
>
> Russell King - ARM Linux writes:
>> On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
>>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>>> >
>>> > Hi Felipe and Arnd,
>>> >
>>> > It has been a while since the last response to thi
Hi,
On Wed, Aug 31, 2016 at 05:40:17PM -0700, Stephen Boyd wrote:
> @@ -174,14 +219,37 @@ static int ulpi_register(struct device *dev, struct
> ulpi *ulpi)
> ulpi->id.product = ulpi_read(ulpi, ULPI_PRODUCT_ID_LOW);
> ulpi->id.product |= ulpi_read(ulpi, ULPI_PRODUCT_ID_HIGH) << 8;
>
On Fri, 2 Sep 2016, Felipe Balbi wrote:
> Hi,
>
> Russell King - ARM Linux writes:
> > On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
> >> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
> >> >
> >> > Hi Felipe and Arnd,
> >> >
> >> > It has been a while since the
On Fri, 2 Sep 2016, Jacek Anaszewski wrote:
> >>> I'm pretty sure noone ever planned to have more than 1 trigger
> >>> assigned to a single LED. I just realized there will be a problem with
> >>> proposed solution: sysfs files conflict.
...
> >> Currently we support only triggers dedicated to sp
On Mon, Aug 29, 2016 at 01:39:03PM -0700, John Youn wrote:
> This property is not needed because the periodic fifos are not
> configurable. So it was incorrect to add this property in the first
> place.
>
> Signed-off-by: John Youn
> ---
> Documentation/devicetree/bindings/usb/dwc2.txt | 5 -
* Bin Liu [160902 07:03]:
> On Thu, Aug 18, 2016 at 03:46:47PM -0700, Tony Lindgren wrote:
> > + } else {
> > + dev_dbg(musb->controller, "Allow PM with no session: %02x\n",
> > + devctl);
>
> I changed dev_dbg() to musb_dbg(). musb core already moves to
> tracepoint
* Bin Liu [160902 07:05]:
> On Thu, Aug 18, 2016 at 03:46:48PM -0700, Tony Lindgren wrote:
> > + case OTG_STATE_A_WAIT_BCON:
> > mod_timer(&glue->timer, jiffies +
> > - msecs_to_jiffies(wrp->poll_timeout));
> > + msecs_to_jiffies(wrp->pol
Adding device tree support for gpout feature of the max3421 SPI-USB controller.
Intention is to supply vbus-gpout and vbus-active-level via device tree, e.g:
&peripherals_axi_quad_spi_2 {
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
usb@0 {
On Friday, September 2, 2016 10:21:23 AM CEST Alan Stern wrote:
> On Fri, 2 Sep 2016, Felipe Balbi wrote:
>
> > Hi,
> >
> > Russell King - ARM Linux writes:
> > > On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
> > >> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>
On Fri, 2 Sep 2016, Felipe Balbi wrote:
> I'm thinking we might have a race WRT our use of memory barriers; could
> it be?
>
> /me goes try
>
> Yeah, I've converted all smp_[wr]mb() to smp_mb() and the problem went
> away (apparently). It was failing on first iteration of my test but it
> has no
On Fri, 2 Sep 2016, Binyamin Sharet (bsharet) wrote:
>
> > On 2 Sep 2016, at 15:31, Greg KH wrote:
> >
> > On Fri, Sep 02, 2016 at 12:09:40PM +, Binyamin Sharet (bsharet) wrote:
> >> Hi,
> >>
> >> After confusing Greg, here’s the current status of all 11 issues initially
> >> reported by
On 09/02/2016 02:08 PM, Felipe Balbi wrote:
>
> Hi,
>
> Russell King - ARM Linux writes:
>> On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
>>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
Hi Felipe and Arnd,
It has been a while since the last r
On Fri, Sep 02, 2016 at 09:55:52AM +0800, Peter Chen wrote:
> Do you have other 5V to USB_H1_VBUS? USB PHY needs 5V input voltage
> as the source for USB LDO (3.0v), either from OTG or Host 1. I suspect
> the lower vbus voltage causes the USB LDO voltage less than 3.0v, then
> cause the unstable fo
On Thu, 1 Sep 2016, Vaibhav Hiremath wrote:
> >> I can put prints to trace the execution flow, lets see what comes out
> >> from it.
> > How easily can you reproduce the problem?
>
> Very easily. I would say 7-8 times out of 10.
Then you can add a printk in hub_activate() just before the call to
Hi,
Alan Stern writes:
> On Fri, 2 Sep 2016, Felipe Balbi wrote:
>
>> I'm thinking we might have a race WRT our use of memory barriers; could
>> it be?
>>
>> /me goes try
>>
>> Yeah, I've converted all smp_[wr]mb() to smp_mb() and the problem went
>> away (apparently). It was failing on first
Hi,
Felipe Balbi writes:
> Hi,
>
> Alan Stern writes:
>> On Fri, 2 Sep 2016, Felipe Balbi wrote:
>>
>>> I'm thinking we might have a race WRT our use of memory barriers; could
>>> it be?
>>>
>>> /me goes try
>>>
>>> Yeah, I've converted all smp_[wr]mb() to smp_mb() and the problem went
>>> aw
On Fri, 2 Sep 2016, Felipe Balbi wrote:
> >> I just noticed that the kerneldoc for wake_up_process() says that the
> >> caller should assume a write memory barrier if and only if any tasks
> >> are woken up. So if the task is already running, there is no barrier.
> >>
> >> This means that in f_
Hi,
Alan Stern writes:
> On Fri, 2 Sep 2016, Felipe Balbi wrote:
>
>> >> I just noticed that the kerneldoc for wake_up_process() says that the
>> >> caller should assume a write memory barrier if and only if any tasks
>> >> are woken up. So if the task is already running, there is no barrier.
Paul, Peter, and Ingo:
This must have come up before, but I don't know what was decided.
Isn't it often true that a memory barrier is needed before a call to
wake_up_process()? A typical scenario might look like this:
CPU 0
-
for (;;) {
set_current_s
Hi Peter,
> Stefan Wahren hat am 25. August 2016 um 19:17
> geschrieben:
>
>
> Hi,
>
> > Peter Chen hat am 25. August 2016 um 11:16
> > geschrieben:
> >
> >
> > On Thu, Aug 25, 2016 at 08:27:03AM +0200, Stefan Wahren wrote:
> > > Am 25.08.2016 um 08:44 schrieb Peter Chen:
> > > > On Thu, Au
On Fri, Sep 02, 2016 at 02:10:13PM -0400, Alan Stern wrote:
> Paul, Peter, and Ingo:
>
> This must have come up before, but I don't know what was decided.
>
> Isn't it often true that a memory barrier is needed before a call to
> wake_up_process()? A typical scenario might look like this:
>
>
On Fri, Sep 02, 2016 at 02:10:13PM -0400, Alan Stern wrote:
> Paul, Peter, and Ingo:
>
> This must have come up before, but I don't know what was decided.
>
> Isn't it often true that a memory barrier is needed before a call to
> wake_up_process()? A typical scenario might look like this:
>
>
Hi,
Alan Stern writes:
[...]
> No, that would be too late. The barrier needs to go between the write
> to common->thead_wakeup_needed and the call to wake_up_process().
alright, I tested this but it doesn't work. It still hangs :-(
--
balbi
--
To unsubscribe from this list: send the lin
On Fri, 2 Sep 2016, Peter Zijlstra wrote:
> On Fri, Sep 02, 2016 at 02:10:13PM -0400, Alan Stern wrote:
> > Paul, Peter, and Ingo:
> >
> > This must have come up before, but I don't know what was decided.
> >
> > Isn't it often true that a memory barrier is needed before a call to
> > wake_up_p
On Fri, 2 Sep 2016, Paul E. McKenney wrote:
> On Fri, Sep 02, 2016 at 02:10:13PM -0400, Alan Stern wrote:
> > Paul, Peter, and Ingo:
> >
> > This must have come up before, but I don't know what was decided.
> >
> > Isn't it often true that a memory barrier is needed before a call to
> > wake_up
On Fri, 2 Sep 2016, Felipe Balbi wrote:
>
> Hi,
>
> Alan Stern writes:
>
> [...]
>
> > No, that would be too late. The barrier needs to go between the write
> > to common->thead_wakeup_needed and the call to wake_up_process().
>
> alright, I tested this but it doesn't work. It still hang
On Fri, Sep 02, 2016 at 04:16:54PM -0400, Alan Stern wrote:
>
> Actually, that's not entirely true (although presumably it works okay
> for most architectures).
Yeah, all load-store archs (with exception of PowerPC and ARM64 and
possibly MIPS) implement ACQUIRE with a general fence (after the ll/
On Fri, Sep 2, 2016 at 5:43 AM, Arnd Bergmann wrote:
> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>>
>> Hi Felipe and Arnd,
>>
>> It has been a while since the last response to this discussion, but we
>> haven't reached an agreement yet! Can we get to a conclusion on if it
>> is
On Sat, Sep 03, 2016 at 12:14:13AM +0200, Peter Zijlstra wrote:
> On Fri, Sep 02, 2016 at 04:16:54PM -0400, Alan Stern wrote:
> >
> > Actually, that's not entirely true (although presumably it works okay
> > for most architectures).
>
> Yeah, all load-store archs (with exception of PowerPC and AR
On Fri, Sep 02, 2016 at 04:16:54PM -0400, Alan Stern wrote:
> Felipe, your tests will show whether my guess was totally off-base.
> For the new people, Felipe is tracking down a problem that involves
> exactly the code sequence listed at the top of the email, where we know
> that the wakeup routi
Hi,
Alan Stern writes:
> On Fri, 2 Sep 2016, Felipe Balbi wrote:
>
>>
>> Hi,
>>
>> Alan Stern writes:
>>
>> [...]
>>
>> > No, that would be too late. The barrier needs to go between the write
>> > to common->thead_wakeup_needed and the call to wake_up_process().
>>
>> alright, I tested
This seems to be the only code in the kernel that uses
macro defines with a trailing underscore. Fix that.
Joe Perches (2):
hso: Use a more common logging style
hso: Convert printk to pr_
drivers/net/usb/hso.c | 118 +++---
1 file changed, 55 inse
Macros that end in an underscore are just odd.
Add hso_dbg(level, fmt, ...) and use it everwhere instead.
Several uses had additional unnecessary newlines as the
macro added a newline. Remove the newline from the macro
and add newlines to each use as appropriate.
Remove now unused D macros.
Sig
Use a more common logging style
Miscellanea:
o Add pr_fmt to prefix each output message
o Realign arguments
Signed-off-by: Joe Perches
---
drivers/net/usb/hso.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/h
On Thu, Sep 1, 2016 at 8:17 PM, Peter Chen wrote:
> On Wed, Aug 31, 2016 at 05:40:24PM -0700, Stephen Boyd wrote:
>>
>>
>> if (cable->state)
>> - val |= OTGSC_ID;
>> + val &= ~OTGSC_ID; /* A device */
>> else
>> -
On Fri, Sep 2, 2016 at 7:09 AM, Heikki Krogerus
wrote:
> Hi,
>
> On Wed, Aug 31, 2016 at 05:40:17PM -0700, Stephen Boyd wrote:
>> @@ -174,14 +219,37 @@ static int ulpi_register(struct device *dev, struct
>> ulpi *ulpi)
>> ulpi->id.product = ulpi_read(ulpi, ULPI_PRODUCT_ID_LOW);
>> ulp
hi,
Peter Zijlstra writes:
> On Fri, Sep 02, 2016 at 04:16:54PM -0400, Alan Stern wrote:
>> Felipe, your tests will show whether my guess was totally off-base.
>> For the new people, Felipe is tracking down a problem that involves
>> exactly the code sequence listed at the top of the email, wh
59 matches
Mail list logo
