On Thu, Jan 24, 2019 at 07:55:51AM +1300, Kees Cook wrote:
> On Thu, Jan 24, 2019 at 4:44 AM Jani Nikula
> wrote:
> >
> > On Wed, 23 Jan 2019, Edwin Zimmerman wrote:
> > > On Wed, 23 Jan 2019, Jani Nikula wrote:
> > >> On Wed, 23 Jan 2019, Greg KH wrote:
> > >> > On Wed, Jan 23, 2019 at 03:03:
On Wed, Jan 23, 2019 at 02:12:38PM -0600, Bin Liu wrote:
> > > > > Thanks for the info.
> > > > > I will handle this case in musb driver.
> > > >
> > > > Why doesn't the same problem occur with other types of host controller?
> > >
> > > Not sure, I am on musb for most of the times. Maybe other H
On Wed, Jan 23, 2019 at 11:05:40AM -0500, Alan Stern wrote:
> On Wed, 23 Jan 2019, Bin Liu wrote:
>
> > On Wed, Jan 23, 2019 at 03:55:47PM +0100, Johan Hovold wrote:
> > > On Wed, Jan 23, 2019 at 08:09:47AM -0600, Bin Liu wrote:
> > > > On Wed, Jan 23, 2019 at 09:55:49AM +0100, Johan Hovold wrote:
On Wed, Jan 23, 2019 at 08:50:38PM +, Måns Rullgård wrote:
> Bin Liu writes:
>
> >> > > Why doesn't the same problem occur with other types of host controller?
> >> >
> >> > Not sure, I am on musb for most of the times. Maybe other HCD doesn't
> >> > giveback URBs with -EPROTO in such error
Hi Rajat,
> Add a hook to allow the BT driver to do device or command specific
> handling in case of timeouts. This is to be used by Intel driver to
> reset the device after certain number of timeouts.
>
> Signed-off-by: Rajat Jain
> ---
> v5: Drop the quirk, and rename the hook function to cmd_
Hi Rajat,
> If the platform provides it, use the reset gpio to reset the Intel BT
> chip, as part of cmd_timeout handling. This has been found helpful on
> Intel bluetooth controllers where the firmware gets stuck and the only
> way out is a hard reset pin provided by the platform.
>
> Signed-off
Hi,
On Wed, Jan 16, 2019 at 10:57:42AM +0100, Nicolas Ferre wrote:
> Add support for additional reset causes and the proper compatibility
> string for sam9x60 SoC. The restart function is the same as the samx7.
>
> Signed-off-by: Nicolas Ferre
> ---
> drivers/power/reset/at91-reset.c | 13 +
Hi Sebastian,
On 23/01/2019 at 19:34, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Jan 16, 2019 at 10:57:42AM +0100, Nicolas Ferre wrote:
>> Add support for additional reset causes and the proper compatibility
>> string for sam9x60 SoC. The restart function is the same as the samx7.
>>
>> Signed-of
Johan Hovold writes:
> On Wed, Jan 23, 2019 at 08:50:38PM +, Måns Rullgård wrote:
>> Bin Liu writes:
>>
>> >> > > Why doesn't the same problem occur with other types of host
>> >> > > controller?
>> >> >
>> >> > Not sure, I am on musb for most of the times. Maybe other HCD doesn't
>> >> >
On Wednesday, January 23, 2019 6:04 AM, Kees Cook wrote
>
> Variables declared in a switch statement before any case statements
> cannot be initialized, so move all instances out of the switches.
> After this, future always-initialized stack variables will work
> and not throw warnings like this:
On Thu, 2019-01-24 at 13:48 +0800, Zhang Run wrote:
> The ax88772_bind() should return error code immediately when the PHY
> was not reset properly through ax88772a_hw_reset().
> Otherwise, The asix_get_phyid() will block when get the PHY
> Identifier from the PHYSID1 MII registers through asix_md
The QFN28 package version of the CP2102N has three additional gpio pins.
Add support for these.
Signed-off-by: Mans Rullgard
---
drivers/usb/serial/cp210x.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/c
On Thu, 24 Jan 2019, Johan Hovold wrote:
> > At least when -EPROTO errors are caused by device disconnect, we know
> > that they will eventually go away when the upstream hub reports the
> > port disconnect event. But until then, an interrupt storm is certainly
> > possible.
>
> Indeed, and t
On Thu, Jan 24, 2019 at 12:56:33PM +, Måns Rullgård wrote:
> Johan Hovold writes:
>
> > On Wed, Jan 23, 2019 at 08:50:38PM +, Måns Rullgård wrote:
> >> Bin Liu writes:
> >>
> >> >> > > Why doesn't the same problem occur with other types of host
> >> >> > > controller?
> >> >> >
> >> >
On Thu, Jan 24, 2019 at 10:22:26AM -0500, Alan Stern wrote:
> On Thu, 24 Jan 2019, Johan Hovold wrote:
>
> > > At least when -EPROTO errors are caused by device disconnect, we know
> > > that they will eventually go away when the upstream hub reports the
> > > port disconnect event. But until t
On Thu, 24 Jan 2019, Bin Liu wrote:
> > Perhaps it has something to do with the timing of the completion
> > interrupts. I don't know anything about how musb works, though. Some
> > low-level timing information would be good to see.
>
> The musb controller driver itself doesn't have a isr BH,
On 10.01.2019 00:11, Nathan Royce wrote:
Wow, my system got wrecked (exaggeration) during this latest stretch...
Pulseaudio was stretched to the limit and beyond and was forced to
restart. Anything that was producing audio had to be restarted to get
it back.
This time was much like the first time
On Thu, Jan 24, 2019 at 10:49:30AM -0500, Alan Stern wrote:
> On Thu, 24 Jan 2019, Bin Liu wrote:
>
> > > Perhaps it has something to do with the timing of the completion
> > > interrupts. I don't know anything about how musb works, though. Some
> > > low-level timing information would be good
Bin Liu writes:
> On Thu, Jan 24, 2019 at 12:56:33PM +, Måns Rullgård wrote:
>> Johan Hovold writes:
>>
>> > On Wed, Jan 23, 2019 at 08:50:38PM +, Måns Rullgård wrote:
>> >> Bin Liu writes:
>> >>
>> >> >> > > Why doesn't the same problem occur with other types of host
>> >> >> > > co
Hi,
On Thu, Jan 24, 2019 at 10:34:50AM +, nicolas.fe...@microchip.com wrote:
> Hi Sebastian,
>
> On 23/01/2019 at 19:34, Sebastian Reichel wrote:
> > Hi,
> >
> > On Wed, Jan 16, 2019 at 10:57:42AM +0100, Nicolas Ferre wrote:
> >> Add support for additional reset causes and the proper compati
Hi Greg
> -Original Message-
> From: Greg KH
> Sent: Thursday, January 17, 2019 11:06 PM
> To: Ajay Gupta
> Cc: heikki.kroge...@linux.intel.com; linux-usb@vger.kernel.org
> Subject: Re: [PATCH 1/7] usb: typec: ucsi: add get_fw_info function
>
> On Thu, Jan 17, 2019 at 05:09:03PM -0800,
Hi Heikki,
> > Function is to get the details of ccg firmware and device version.
> >
> > Signed-off-by: Ajay Gupta
> > ---
> > drivers/usb/typec/ucsi/ucsi_ccg.c | 76
> > ++-
> > 1 file changed, 74 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/typec/
Hi Greg
-off-by: Ajay Gupta
> > ---
> > drivers/usb/typec/ucsi/ucsi_ccg.c | 139
> > ++
> > 1 file changed, 139 insertions(+)
> >
> > diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c
> > b/drivers/usb/typec/ucsi/ucsi_ccg.c
> > index 5f341934a5af..6069a9f60d1e 100644
> >
Hi Greg,
> On Thu, Jan 17, 2019 at 05:12:38PM -0800, Ajay Gupta wrote:
> > This will be needed to check if latest fw is already flashed.
>
> Very odd changelog text, please make this more detailed.
Sure.
> And your email threading broke here, did your email client change?
There was some error fr
Hi Heikki,
> > Signed-off-by: Ajay Gupta
> > ---
> > drivers/usb/typec/ucsi/ucsi_ccg.c | 139
> > ++
> > 1 file changed, 139 insertions(+)
> >
> > diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c
> > b/drivers/usb/typec/ucsi/ucsi_ccg.c
> > index 5f341934a5af..6069a9f60d
Hi Greg,
> On Thu, Jan 17, 2019 at 05:09:04PM -0800, Ajay Gupta wrote:
> > Used to send command to ccg controller
>
> Writing changelog comments is hard, but please do more than just tiny snippets
> like this. Explain _why_ this change is needed in detail please.
>
> Same for all of these patch
Hi Heikki,
> From: Heikki Krogerus
> Sent: Friday, January 18, 2019 7:30 AM
> To: Ajay Gupta
> Cc: linux-usb@vger.kernel.org
> Subject: Re: [PATCH 6/7] usb: typec: ucsi: add check for supported vendor
>
> On Thu, Jan 17, 2019 at 05:13:02PM -0800, Ajay Gupta wrote:
> > Added check to see the curr
By the way, why do we need to store the qh in urb->hcpriv?
qh can always be accessible through urb->ep->hcpriv
Wouldn't it be better to drop entire urb->hcpriv usage?
ср, 23 янв. 2019 г. в 20:52, Matwey V. Kornilov :
>
> We assign "urb->hcpriv = qh;" a few lines down. The valid qh for the urb is
>
Hi Heikki
> > Used to send command to ccg controller
> >
> > Signed-off-by: Ajay Gupta
> > ---
> > drivers/usb/typec/ucsi/ucsi_ccg.c | 252
> > --
> > 1 file changed, 243 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c
> > b/driver
On Thu, Jan 24, 2019 at 1:46 AM Marcel Holtmann wrote:
>
> Hi Rajat,
>
> > If the platform provides it, use the reset gpio to reset the Intel BT
> > chip, as part of cmd_timeout handling. This has been found helpful on
> > Intel bluetooth controllers where the firmware gets stuck and the only
> >
Hi Marcel,
On Thu, Jan 24, 2019 at 1:36 AM Marcel Holtmann wrote:
>
> Hi Rajat,
>
> > Add a hook to allow the BT driver to do device or command specific
> > handling in case of timeouts. This is to be used by Intel driver to
> > reset the device after certain number of timeouts.
> >
> > Signed-of
Fix vhci_urb_enqueue() to print debug msg and return error instead of
failing with BUG_ON.
Signed-off-by: Shuah Khan
---
drivers/usb/usbip/vhci_hcd.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 1e592e
From: Dmitry Torokhov
In preparation for handling embedded USB devices let's split
usb_acpi_find_companion() into usb_acpi_find_companion_for_device() and
usb_acpi_find_companion_for_port().
Signed-off-by: Dmitry Torokhov
Signed-off-by: Rajat Jain
Acked-by: Greg Kroah-Hartman
Tested-by: Sukum
If the platform provides it, use the reset gpio to reset the Intel BT
chip, as part of cmd_timeout handling. This has been found helpful on
Intel bluetooth controllers where the firmware gets stuck and the only
way out is a hard reset pin provided by the platform.
Signed-off-by: Rajat Jain
---
v6
Add a hook to allow the BT driver to do device or command specific
handling in case of timeouts. This is to be used by Intel driver to
reset the device after certain number of timeouts.
Signed-off-by: Rajat Jain
---
v6: Dropped the "sent command" parameter from cmd_timeout()
v5: Drop the quirk, a
From: Dmitry Torokhov
USB devices permanently connected to USB ports may be described in ACPI
tables and share ACPI devices with ports they are connected to. See [1]
for details.
This will allow us to describe sideband resources for devices, such as,
for example, hard reset line for BT USB contr
Hi Bin,
Thanks for your help.
Hi Rob,
I find that Samsung describes the usb-connector attribute in DTS, and
uses a private driver.
And try to write DTS as following:
usb-connector node:
musb_con: musb_connector{
compatible = "linux,extcon-usb-gpio","usb-b-connector";
lable = "micro-USB"
From: Nikhil Badola
Remove USB errata checking code from driver. Applicability of erratum
is retrieved by reading corresponding property in device tree.
This property is written during device tree fixup.
Signed-off-by: Ramneek Mehresh
Signed-off-by: Nikhil Badola
Signed-off-by: Yinbo Zhu
---
From: Yinbo Zhu
This patch is to add member has_fsl_erratum_a006918 in platform data
Signed-off-by: Yinbo Zhu
---
include/linux/fsl_devices.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index 5da56a6..4c613d
From: Suresh Gupta
PHY_CLK_VALID bit for UTMI PHY in USBDR does not set even
if PHY is providing valid clock. Workaround for this
involves resetting of PHY and check PHY_CLK_VALID bit
multiple times. If PHY_CLK_VALID bit is still not set even
after 5 retries, it would be safe to deaclare that PHY
From: Nikhil Badola
Set USB_EN bit to select ULPI phy for USB controller version 2.5
Signed-off-by: Nikhil Badola
Signed-off-by: Yinbo Zhu
---
Change in v4:
Incorrect indentation of the continuation line
drivers/usb/host/ehci-fsl.c |6 ++
1 files changed, 6 insertions
From: Ramneek Mehresh
USB erratum-A006918 workaround tries to start internal PHY inside
uboot (when PLL fails to lock). However, if the workaround also
fails, then USB initialization is also stopped inside Linux.
Erratum-A006918 workaround failure creates "fsl,erratum_a006918"
node in device-tree
Remove unused #include in drivers/usb/chipidea/ci_hdrc_imx.c
Signed-off-by: Alexander Shiyan
---
drivers/usb/chipidea/ci_hdrc_imx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 09b37c0d075d..a1c0e9cc73a6 100644
> Cc: Peter Chen ; Greg Kroah-Hartman
> ; Alexander Shiyan
> Subject: [PATCH] usb: chipidea: imx: Remove unused include
>
> Remove unused #include in drivers/usb/chipidea/ci_hdrc_imx.c
>
> Signed-off-by: Alexander Shiyan
> ---
> drivers/usb/chipidea/ci_hdrc_imx.c | 1 -
> 1 file changed,
From: Zhang Run
Date: Thu, 24 Jan 2019 13:48:49 +0800
> The ax88772_bind() should return error code immediately when the PHY
> was not reset properly through ax88772a_hw_reset().
> Otherwise, The asix_get_phyid() will block when get the PHY
> Identifier from the PHYSID1 MII registers through asi
Hi Rajat,
> If the platform provides it, use the reset gpio to reset the Intel BT
> chip, as part of cmd_timeout handling. This has been found helpful on
> Intel bluetooth controllers where the firmware gets stuck and the only
> way out is a hard reset pin provided by the platform.
>
> Signed-off
Hi Rajat,
> USB devices permanently connected to USB ports may be described in ACPI
> tables and share ACPI devices with ports they are connected to. See [1]
> for details.
>
> This will allow us to describe sideband resources for devices, such as,
> for example, hard reset line for BT USB contro
Hi Rajat,
> In preparation for handling embedded USB devices let's split
> usb_acpi_find_companion() into usb_acpi_find_companion_for_device() and
> usb_acpi_find_companion_for_port().
>
> Signed-off-by: Dmitry Torokhov
> Signed-off-by: Rajat Jain
> Acked-by: Greg Kroah-Hartman
> Tested-by: Su
Hi Rajat,
> Add a hook to allow the BT driver to do device or command specific
> handling in case of timeouts. This is to be used by Intel driver to
> reset the device after certain number of timeouts.
>
> Signed-off-by: Rajat Jain
> ---
> v6: Dropped the "sent command" parameter from cmd_timeou
Hi Maynard,
On 1/24/2019 12:13 AM, Maynard Cabiente wrote:
> Hi Minas,
>
> On Wednesday, January 23, 2019 3:58 AM Minas Harutyunyan
> wrote:
>> But before it, could you please add some debug print in
>> dwc2_hsotg_suspend() function. I suspect that host side autosuspend mass
>> storage device(s)
50 matches
Mail list logo
