On Tue, Apr 16, 2019 at 10:27:47AM -0700, Ajay Gupta wrote:
> From: Ajay Gupta
>
> CCGx has two copies of the firmware in addition to the bootloader.
> If the device is running FW1, FW2 can be updated with the new version.
> Dual firmware mode allows the CCG device to stay in a PD contract and
>
On Tue, Apr 16, 2019 at 10:07:54PM +0200, Hans de Goede wrote:
> Some tcpc device-drivers need to explicitly be told to watch for connection
> events, otherwise the tcpc will not generate any TCPM_CC_EVENTs and devices
> being plugged into the Type-C port will not be noticed.
>
> For dual-role por
On Tue, Apr 16, 2019 at 10:07:53PM +0200, Hans de Goede wrote:
> When in single-role port mode, we must start single-role toggling to
> get an interrupt when a device / cable gets plugged into the port.
>
> This commit modifies the fusb302 start_toggling implementation to
> start toggling for all
On Tue, Apr 16, 2019 at 10:07:52PM +0200, Hans de Goede wrote:
> Some tcpc device-drivers need to explicitly be told to watch for connection
> events, otherwise the tcpc will not generate any TCPM_CC_EVENTs and devices
> being plugged into the Type-C port will not be noticed.
>
> For dual-role por
On 4/16/19 1:07 PM, Hans de Goede wrote:
Some tcpc device-drivers need to explicitly be told to watch for connection
events, otherwise the tcpc will not generate any TCPM_CC_EVENTs and devices
being plugged into the Type-C port will not be noticed.
For dual-role ports tcpm_start_drp_toggling() i
On 4/16/19 1:07 PM, Hans de Goede wrote:
When in single-role port mode, we must start single-role toggling to
get an interrupt when a device / cable gets plugged into the port.
This commit modifies the fusb302 start_toggling implementation to
start toggling for all port-types, so that connection
On 4/16/19 1:07 PM, Hans de Goede wrote:
Some tcpc device-drivers need to explicitly be told to watch for connection
events, otherwise the tcpc will not generate any TCPM_CC_EVENTs and devices
being plugged into the Type-C port will not be noticed.
For dual-role ports tcpm_start_drp_toggling() i
Hello,
syzbot has tested the proposed patch but the reproducer still triggered
crash:
WARNING in usb_submit_urb
hub 3-0:1.0: 90da6a2e hub_activate type 4 discon 0
hub 3-0:1.0: 90da6a2e Submitting status URB
hub 3-0:1.0: 90da6a2e Submitting status URB
[ cut
On Tue, 16 Apr 2019, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch but the reproducer still triggered
> crash:
> WARNING in usb_submit_urb
>
> hub 3-0:1.0: 15733366 hub_activate type 4 discon 0
> hub 3-0:1.0: 15733366 Submitting status URB
> hub 3-0:1.0: 0
Some tcpc device-drivers need to explicitly be told to watch for connection
events, otherwise the tcpc will not generate any TCPM_CC_EVENTs and devices
being plugged into the Type-C port will not be noticed.
For dual-role ports tcpm_start_drp_toggling() is used to tell the tcpc to
watch for connec
Some tcpc device-drivers need to explicitly be told to watch for connection
events, otherwise the tcpc will not generate any TCPM_CC_EVENTs and devices
being plugged into the Type-C port will not be noticed.
For dual-role ports tcpm_start_drp_toggling() is used to tell the tcpc to
watch for connec
When in single-role port mode, we must start single-role toggling to
get an interrupt when a device / cable gets plugged into the port.
This commit modifies the fusb302 start_toggling implementation to
start toggling for all port-types, so that connection-detection works
on single-role ports too.
Hi,
On 15-04-19 20:38, Guenter Roeck wrote:
On Mon, Apr 15, 2019 at 07:53:58PM +0200, Hans de Goede wrote:
Hi Guenter,
On 15-04-19 17:51, Guenter Roeck wrote:
On Sat, Apr 13, 2019 at 10:39:53PM +0200, Hans de Goede wrote:
Some tcpc device-drivers need to explicitly be told to watch for conne
Hi,
Thank you for the review.
On 14-04-19 09:40, Sergei Shtylyov wrote:
Hello!
On 13.04.2019 23:39, Hans de Goede wrote:
When in single role port mode, we most start single-role toggling to
Must, perhaps?
Right, fixed for the upcoming v2 of the patch-set.
get an interrupt when a de
Hello,
syzbot has tested the proposed patch but the reproducer still triggered
crash:
WARNING in usb_submit_urb
hub 3-0:1.0: 15733366 hub_activate type 4 discon 0
hub 3-0:1.0: 15733366 Submitting status URB
hub 3-0:1.0: 15733366 Submitting status URB
[ cut
On Tue, 16 Apr 2019, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch but the reproducer still triggered
> crash:
> WARNING in usb_submit_urb
>
> hub 3-0:1.0: hub_activate type 4
> hub 3-0:1.0: Submitting status URB
> hub 3-0:1.0: Submitting status URB
> [ cut here ]
Hello,
syzbot has tested the proposed patch but the reproducer still triggered
crash:
WARNING in usb_submit_urb
hub 3-0:1.0: hub_activate type 4
hub 3-0:1.0: Submitting status URB
hub 3-0:1.0: Submitting status URB
[ cut here ]
URB a8d7a6c6 submitted while acti
On Mon, 15 Apr 2019, Andrey Konovalov wrote:
> On Mon, Apr 15, 2019 at 5:16 PM Andrey Konovalov
> wrote:
> >
> > On Mon, Apr 15, 2019 at 2:34 PM syzbot
> > wrote:
> > >
> > > Hello,
> > >
> > > syzbot has tested the proposed patch and the reproducer did not trigger
> > > crash:
> > >
> > > Repo
Hi Heikki
These changes add support for updating firmware on Cypress CCGx
controller. New version (v8) fixes comments from Greg at [1].
I have tested them on NVIDIA GPU card.
Firmware binary is already merged. Details are at [2].
Please help review this set.
Thanks
Ajay
[1] https://marc.info
From: Ajay Gupta
Function is to get the details of ccg firmware and device version.
It will be useful in debugging and also during firmware update.
Signed-off-by: Ajay Gupta
Signed-off-by: Heikki Krogerus
---
Changes from v7 -> v8
- None
drivers/usb/typec/ucsi/ucsi_ccg.c | 66 +++
From: Ajay Gupta
Adding device property "ccgx,firmware-build" for the CCGx
device, so the CCGx driver knows which firmware binary to
use for a specific vendor.
Suggested-by: Heikki Krogerus
Signed-off-by: Ajay Gupta
Signed-off-by: Heikki Krogerus
---
Changes from v7->v8
- None
drive
From: Ajay Gupta
CCGx has two copies of the firmware in addition to the bootloader.
If the device is running FW1, FW2 can be updated with the new version.
Dual firmware mode allows the CCG device to stay in a PD contract and
support USB PD and Type-C functionality while a firmware update is in
pr
Hi friend I am a banker in ADB BANK. I want to transfer an abandoned
$10.2Million to your Bank account. 40/percent will be your share.
For more details contanct me urgently. Yours Mr Ghazi Ahmed
The SCSI core does not like to have devices or hosts unregistered
while error recovery is in progress. Trying to do so can lead to
self-deadlock: Part of the removal code tries to obtain a lock already
held by the error handler.
This can cause problems for the usb-storage and uas drivers, because
On Tue, Apr 16, 2019 at 04:44:39PM +0300, Heikki Krogerus wrote:
> On Tue, Apr 16, 2019 at 12:19:53PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Feb 22, 2019 at 03:11:58PM +0100, Hans de Goede wrote:
> > > The 2 callers of fusb302_set_cc_polarity both call fusb302_set_cc_pull
> > > directly befor
On Tue, Apr 16, 2019 at 12:19:53PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Feb 22, 2019 at 03:11:58PM +0100, Hans de Goede wrote:
> > The 2 callers of fusb302_set_cc_polarity both call fusb302_set_cc_pull
> > directly before calling fusb302_set_cc_polarity, this is not ideal for
> > 2 reasons:
>
On Mon, Apr 15, 2019 at 03:09:27PM +0300, Heikki Krogerus wrote:
> +static ssize_t do_flash_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "[Usage]\n"
> + "1) copy ccg_boot.cyacd /lib/firmware/\n"
> +
On Fri, Feb 22, 2019 at 03:11:58PM +0100, Hans de Goede wrote:
> The 2 callers of fusb302_set_cc_polarity both call fusb302_set_cc_pull
> directly before calling fusb302_set_cc_polarity, this is not ideal for
> 2 reasons:
>
> 1) fusb302_set_cc_pull uses the cached polarity when applying pull-ups,
On Mon, Apr 15, 2019 at 03:09:31PM +0300, Heikki Krogerus wrote:
> From: Ajay Gupta
>
> Latest NVIDIA GPUs support VirtualLink device. Since USBIF
> has not assigned a Standard ID (SID) for VirtualLink
> so using NVIDA VID 0x955 as SVID.
>
> Signed-off-by: Ajay Gupta
> Signed-off-by: Heikki Kro
On Tue, Apr 16, 2019 at 10:46:07AM +0300, Heikki Krogerus wrote:
> On Tue, Apr 16, 2019 at 09:27:03AM +0300, Heikki Krogerus wrote:
> > On Tue, Apr 16, 2019 at 12:45:12AM +, Ajay Gupta wrote:
> > > Hi Heikki,
> > >
> > > > -Original Message-
> > > > From: linux-usb-ow...@vger.kernel.or
On Wed, Apr 10, 2019 at 02:47:24PM +0800, Chunfeng Yun wrote:
> Use devm_clk_get_optional() to get optional clock
>
> Signed-off-by: Chunfeng Yun
> ---
> v2: no changes
> ---
> drivers/usb/host/xhci-mtk.c | 19 +++
> 1 file changed, 3 insertions(+), 16 deletions(-)
>
> diff --gi
On Thu, Apr 11, 2019 at 10:51:47AM +0800, Yang Xiao wrote:
> Hi,
>
> There are NULL pointer deferences in the function stk_camera_probe in
> drivers/media/usb/stkwebcam/stk-webcam.c and function s2255_probe in
> drivers/media/usb/s2255/s2255drv.c, which allows proximate attackers
> to cause a deni
On Tue, Apr 16, 2019 at 4:28 PM Maxime Ripard wrote:
>
> Neither the OHCI or EHCI bindings are using the phy-names property, so we
> can just drop it.
>
> Signed-off-by: Maxime Ripard
Acked-by: Chen-Yu Tsai
for all the DT patches in this series.
The USB HCD generic binding is used by many USB host bindings.
In order to allow the DT validation to happen on those, let's create a YAML
description for that generic binding that can be referenced later on.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/usb/usb-hcd.txt |
Neither the OHCI or EHCI bindings are using the phy-names property, so we
can just drop it.
Signed-off-by: Maxime Ripard
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts | 2 --
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 2 --
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
Neither the OHCI or EHCI bindings are using the phy-names property, so we
can just drop it.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index
Neither the OHCI or EHCI bindings are using the phy-names property, so we
can just drop it.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun4i-a10.dtsi | 4
arch/arm/boot/dts/sun5i.dtsi | 2 --
arch/arm/boot/dts/sun6i-a31.dtsi | 4
arch/arm/boot/dts/sun7i-a20.dtsi
The generic EHCI binding is used by many controllers that are using the
EHCI spec.
Convert that binding to a YAML description to enable the validation on all
the nodes using that binding.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/usb/generic-ehci.yaml | 95 ++-
The generic OHCI binding is used by many controllers that are using the
OHCI spec.
Convert that binding to a YAML description to enable the validation on all
the nodes using that binding.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/usb/generic-ohci.yaml | 89 ++-
Hi Alan,
Alan Stern writes:
> I finally took the time to put more work into the explicit-status-stage
> project. Now I've got patches adding support to both dummy-hcd and
> net2280. (The two patches for net2280 I sent earlier today address
> unrelated issues that turned up while this work was
On Tue, Apr 16, 2019 at 09:27:03AM +0300, Heikki Krogerus wrote:
> On Tue, Apr 16, 2019 at 12:45:12AM +, Ajay Gupta wrote:
> > Hi Heikki,
> >
> > > -Original Message-
> > > From: linux-usb-ow...@vger.kernel.org On
> > > Behalf Of Heikki Krogerus
> > > Sent: Monday, April 15, 2019 5:10
41 matches
Mail list logo
