John Stultz wrote:
> On Fri, Feb 1, 2019 at 4:46 PM Thinh Nguyen wrote:
>> John Stultz wrote:
>>> On Fri, Feb 1, 2019 at 4:18 PM John Stultz wrote:
>>> Bisecting the changes down, it seems like its due to commit
>>> fec9095bdef4e ("usb: dwc3: gadget: remove wait_end_transfer").
>>>
>>> It doesn't
From: Ajay Gupta
Here we read the currently flashed firmware version of both
primary and secondary firmware and then compare it with
version of firmware file to determine if flashing is required.
Signed-off-by: Ajay Gupta
---
Changes from v2 to v3
- Moved enum_fw_mode enum to patch [1/6
From: Ajay Gupta
Adding support for below commands which will be used
during firmware flashing.
- ENTER_FLASHING
- RESET
- PDPORT_ENABLE
- JUMP_TO_BOOT
- FLASH_ROW_RW
- VALIDATE_FW
I command specific mutex lock is also added to sync
between driver a
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 Heikki
These changes adds support for updating firmware on Cypress CCGx
controller. New version (v3) fixes comments form you and Greg.
I have tested them on NVIDIA GPU card.
I will be posting firmware binary patch to linux-firmware.git repo soon.
Please help review this set.
Thanks
Ajay
Aj
From: Ajay Gupta
Used to send various commands to ccg controller. They are
mainly used during firmware update process.
We wait for response after sending the command and then
read the response from RAB_RESPONSE register.
Signed-off-by: Ajay Gupta
---
Changes from v2 to v3
- Removed unu
From: Ajay Gupta
Read PD port number information and save. It will be
required while sending PD_PORT_ENABLE command.
Signed-off-by: Ajay Gupta
---
Changes from v2 to v3
- Fixed comments from Heikki on removing SHIFT
drivers/usb/typec/ucsi/ucsi_ccg.c | 6 ++
1 file changed, 6 inser
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
---
Changes from v2 to v3
- Fixed comments from Greg on using __le16 and __packed
- Added enum_fw_mode an
On Fri, Feb 1, 2019 at 4:46 PM Thinh Nguyen wrote:
> John Stultz wrote:
> > On Fri, Feb 1, 2019 at 4:18 PM John Stultz wrote:
> > Bisecting the changes down, it seems like its due to commit
> > fec9095bdef4e ("usb: dwc3: gadget: remove wait_end_transfer").
> >
> > It doesn't happen all the time,
Hi John,
John Stultz wrote:
> On Fri, Feb 1, 2019 at 4:18 PM John Stultz wrote:
>> Hey all,
>> Since the 5.0 merge window opened, I've been tripping on frequent
>> dwc3 crashes on reboot and suspend, which I've added an example to the
>> bottom of this mail.
>>
>> I've dug in a little bit and s
On Fri, Feb 1, 2019 at 4:18 PM John Stultz wrote:
>
> Hey all,
> Since the 5.0 merge window opened, I've been tripping on frequent
> dwc3 crashes on reboot and suspend, which I've added an example to the
> bottom of this mail.
>
> I've dug in a little bit and sort of have a sense of whats going
On Fri, Feb 1, 2019 at 4:31 PM Thinh Nguyen wrote:
>
> Hi John,
>
> John Stultz wrote:
> > Hey all,
> > Since the 5.0 merge window opened, I've been tripping on frequent
> > dwc3 crashes on reboot and suspend, which I've added an example to the
> > bottom of this mail.
> >
> > I've dug in a litt
Hi John,
John Stultz wrote:
> Hey all,
> Since the 5.0 merge window opened, I've been tripping on frequent
> dwc3 crashes on reboot and suspend, which I've added an example to the
> bottom of this mail.
>
> I've dug in a little bit and sort of have a sense of whats going on.
>
> In ffs_epfile_io
Hey all,
Since the 5.0 merge window opened, I've been tripping on frequent
dwc3 crashes on reboot and suspend, which I've added an example to the
bottom of this mail.
I've dug in a little bit and sort of have a sense of whats going on.
In ffs_epfile_io():
https://git.kernel.org/pub/scm/linux/ke
tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
testing/next
head: 72bc0e861a6678b4a36653cd94147a5043959ed2
commit: 5f404e8452cb9ff560e8f2a254e29d1449632a0d [19/21] usb: dwc3: gadget:
don't use resource_index as a flag
config: x86_64-randconfig-x017-201904 (attached as .co
Hi Heikki, the use of "con->port_altmode[cur]->mode" (which is a 1-based index,
not a 32-bit mode VDO) can cause incorrect matches if the GET_ALTERNATE_MODES
returns different ordering for recipient=connector and recipient=sop for a
particular svid.
For example, UCSI command GET_ALTERNATE_MODES
From: Jon Flatley
The sysfs documentation for /sys/bus/usb/.../portX/connect_type has one
of the possible values listed as "wired" when the actual value should be
"hardwired".
Changes the ABI documentation for connect_type to match the strings in
port.c.
Signed-off-by: Jon Flatley
---
Documen
On Fri, 01 Feb 2019 17:09:57 +0100,
Christoph Hellwig wrote:
>
> On Fri, Feb 01, 2019 at 02:16:08PM +0100, Takashi Iwai wrote:
> > Actually there are a bunch of ISA sound drivers that still call
> > allocators with NULL device.
> >
> > The patch below should address it, although it's only compile
On Fri, 01 Feb 2019 17:09:06 +0100,
Christoph Hellwig wrote:
>
> On Fri, Feb 01, 2019 at 02:12:45PM +0100, Takashi Iwai wrote:
> > Shall I take this one through sound git tree or all through yours?
>
> Feel free to merge the sound bits through your tree!
Alright, merged both patches 17 and 18 no
On Fri, Feb 01, 2019 at 02:14:34PM +, Robin Murphy wrote:
> And equivalently for rxdma here. However, given that this all seems only
> relevant to antique ARCH_PXA platforms which are presumably managing to
> work as-is, it's probably not worth tinkering too much. I'd just stick a
> note in
On Fri, Feb 01, 2019 at 01:53:09PM +, Robin Murphy wrote:
>> #define LOW_WATER_MARK 100
>> #define HIGH_WATER_MARK (LOW_WATER_MARK*5)
>> -#ifdef CONFIG_UML
>> +#ifdef CONFIG_HAS_DMA
>
> #ifndef, surely?
Indeed.
On Fri, Feb 01, 2019 at 02:16:08PM +0100, Takashi Iwai wrote:
> Actually there are a bunch of ISA sound drivers that still call
> allocators with NULL device.
>
> The patch below should address it, although it's only compile-tested.
Oh, I missed these "indirect" calls. This looks good to me:
Re
On Fri, Feb 01, 2019 at 03:19:41PM +0200, Felipe Balbi wrote:
> Christoph Hellwig writes:
>
> > dma_map_single already transfers ownership to the device.
> >
> > Signed-off-by: Christoph Hellwig
>
> Do you want me to take the USB bits or will you take the entire series?
> In case you're taking
On Fri, Feb 01, 2019 at 02:12:45PM +0100, Takashi Iwai wrote:
> Shall I take this one through sound git tree or all through yours?
Feel free to merge the sound bits through your tree!
On Fri, 1 Feb 2019, Jan-Marek Glogowski wrote:
> On plug-in of my USB-C device, its USB_SS_PORT_LS_SS_INACTIVE
> link state bit is set. Greping all the kernel for this bit shows
> that the port status requests a warm-reset this way.
>
> This just happens, if its the only device on the root hub, t
Hi Felipe, thanks for the review :)
On Fri, 2019-02-01 at 15:31 +0200, Felipe Balbi wrote:
> Hi,
>
> Nicolas Saenz Julienne writes:
> > Immediate data transfers (IDT) allow the HCD to copy small chunks of
> > data (up to 8bits) directly into its output transfer TRBs. This avoids
>
On 01/02/2019 08:47, Christoph Hellwig wrote:
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Hmm, as far as I'm aware these are PIO chips wi
On 01/02/2019 08:47, Christoph Hellwig wrote:
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use the proper Kconfig symbol to check for
Hi Felipe,
We use the Netchip 228x and PLX 2380/338x family in our devices and I have some
small patches that I can share with the community.
Some patches are common and should be ok for all environments. However I also
have 1-2 patches that are mandatory in our environment, but I cannot estimat
Hi,
Guido Kiener writes:
> We use the Netchip 228x and PLX 2380/338x family in our devices and I
> have some small patches that I can share with the community.
>
> Some patches are common and should be ok for all environments. However
> I also have 1-2 patches that are mandatory in our environme
On 01/02/2019 at 09:47, Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Signed-off-by: Christoph Hellwig
Ac
Hi,
Nicolas Saenz Julienne writes:
> Immediate data transfers (IDT) allow the HCD to copy small chunks of
> data (up to 8bits) directly into its output transfer TRBs. This avoids
^
8 bytes
> the somewhat expensive DMA mappings that are performed by default on
> m
Christoph Hellwig writes:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Signed-off-by: Christoph Hellwig
In case you're taking th
Christoph Hellwig writes:
> dma_map_single already transfers ownership to the device.
>
> Signed-off-by: Christoph Hellwig
Do you want me to take the USB bits or will you take the entire series?
In case you're taking the entire series:
Acked-by: Felipe Balbi
> ---
> drivers/usb/gadget/udc/f
On Fri, 01 Feb 2019 09:47:43 +0100,
Christoph Hellwig wrote:
>
> We still have a few drivers which pass a NULL struct device pointer
> to DMA API functions, which generally is a bad idea as the API
> implementations rely on the device not only for ops selection, but
> also the dma mask and various
On Fri, 01 Feb 2019 09:48:00 +0100,
Christoph Hellwig wrote:
>
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Signed-off-by: Christo
On Fri, 01 Feb 2019 09:48:01 +0100,
Christoph Hellwig wrote:
>
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Also use GFP_KERNEL in
Immediate data transfers (IDT) allow the HCD to copy small chunks of
data (up to 8bits) directly into its output transfer TRBs. This avoids
the somewhat expensive DMA mappings that are performed by default on
most URBs submissions.
In the case an URB was suitable for IDT. The data is directly copi
This is actually v4.
With this patch applied, dmesg on device plug looks like this and has no more
suspend-resume-cycle:
[ 454.845205] xhci_hcd:handle_port_status: xhci_hcd :00:14.0: Port Status
Change Event for port 19
[ 454.845215] xhci_hcd:handle_port_status: xhci_hcd :00:14.0: res
On plug-in of my USB-C device, its USB_SS_PORT_LS_SS_INACTIVE
link state bit is set. Greping all the kernel for this bit shows
that the port status requests a warm-reset this way.
This just happens, if its the only device on the root hub, the hub
therefore resumes and the HCDs status_urb isn't yet
On 31.01.2019 23:11, Alan Stern wrote:
On Thu, 31 Jan 2019, Jan-Marek Glogowski wrote:
Perhaps you didn't notice that at the end, hub_activate() calls
kick_hub_wq(). That routine calls
usb_autopm_get_interface_no_resume(), which will prevent the hub trim
suspending until hub_event() calls usb_
This is the output of udevadm monitor -k
KERNEL[41346.476368] add /devices/pci:00/:00:12.2/usb1/1-3 (usb)
KERNEL[41346.517737] add
/devices/pci:00/:00:12.2/usb1/1-3/1-3:1.0 (usb)
KERNEL[41346.558013] add
/devices/pci:00/:00:12.2/usb1/1-3/1-3:1.1 (usb)
KERNEL[41346.5979
This makes it possible to bind a driver to a DisplayPort
alt mode adapter devices.
The driver attempts to cope with the limitations of UCSI by
"emulating" behaviour and attempting to guess things when
ever possible in order to satisfy the requirements the
standard DisplayPort alt mode driver has.
Hi,
I was reluctant to add the support for alternate modes to the UCSI
driver because of problems that I'll explain below, and also because
of the fact that there is no guarantee that the firmware even allows
the operating system to know about the alternate modes (the feature is
optional in UCSI s
With UCSI the alternate modes, just like everything else
related to USB Type-C connectors, are handled in firmware.
The operating system can see the status and is allowed to
request certain things, for example entering and exiting the
modes, but the support for alternate modes is very limited
in UC
The helpers used for reading and writing the pin assignment
from and to the Configuration VDO will be useful in GPU
drivers, and also UCSI driver after DisplayPort alt mode
support is added to it.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/altmodes/displayport.c | 4
include/linux
It's not needed. Moving everything from it to trace.c.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/ucsi/debug.h | 65 --
drivers/usb/typec/ucsi/trace.c | 59 ++
drivers/usb/typec/ucsi/trace.h | 7 ++--
3 files changed, 64 inse
Because of UCSI, we have to support alt mode enter/exit
reporting even when there is no alt mode driver bind to the
alt mode device. With UCSI a firmware handles the alternate
modes, and the modes are entered automatically from OS PoW.
Changing typec_altmode_update_active() so that the driver
modu
On 2019/2/1 13:55, Hanjun Guo wrote:
> Hi John,
>
> On 2019/1/31 17:54, John Garry wrote:
>> On 30/01/2019 07:01, Hanjun Guo wrote:
>>> From: Hanjun Guo
> [...]
>>>
>>> drivers/usb/core/hcd-pci.c | 4
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/usb/core/hcd-pci.c b/driv
Adding Oliver and Macpaul Lin.
On Thu, Jan 31, 2019 at 06:54:24PM -0600, Carlos Salvador Pérez Salgado wrote:
> -- Forwarded message -
> >From: Johan Hovold
> >Date: Thu, Jan 31, 2019 at 9:27 AM
> >Subject: Re: MT65xx Preloader 0e8d:2000, Kernel 4.20.5.1
> >To: Carlos Salvador Pér
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/cadence/macb_main.c | 8
1
gbefb uses managed resources, so it should do the same for DMA
allocations.
Signed-off-by: Christoph Hellwig
---
drivers/video/fbdev/gbefb.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
ind
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use GFP_KERNEL instead of GFP_ATOMIC as the gfp_t for the memory
allocation, as we aren't i
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/amd/au1000_eth.c | 6 +++---
1 file
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use GFP_KERNEL instead of GFP_USER as the gfp_t for the memory
allocation, as we should tre
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/moxa/moxart_ether.c | 11 +++
Just like we do for all other DMA operations.
Signed-off-by: Christoph Hellwig
---
drivers/video/fbdev/pxa3xx-gcu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/pxa3xx-gcu.c b/drivers/video/fbdev/pxa3xx-gcu.c
index 69cfb337c857..047a2fa4b87e 100644
-
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/video/fbdev/da8xx-fb.c | 13 +++--
1 file
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/dma/imx-sdma.c | 10 +-
1 file changed, 5
We still have a few drivers which pass a NULL struct device pointer
to DMA API functions, which generally is a bad idea as the API
implementations rely on the device not only for ops selection, but
also the dma mask and various other attributes.
This series contains all easy conversions to pass a
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use the proper Kconfig symbol to check for DMA API availability.
Signed-off-by: Christoph
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/smsc/smc911x.c | 4 ++--
1 file chan
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Note that this driver seems to entirely lack dma_map_single error
handling, but that is left for
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Note this driver seems to lack dma_unmap_* calls entirely, but fixing
that is left for another t
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/parport/parport_ip32.c | 18 ++
1
dma_map_single already transfers ownership to the device.
Signed-off-by: Christoph Hellwig
---
drivers/usb/gadget/udc/fotg210-udc.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/usb/gadget/udc/fotg210-udc.c
b/drivers/usb/gadget/udc/fotg210-udc.c
index bc6abaea907d..fe9cf415f2f1
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/usb/gadget/udc/fotg210-udc.c | 7 ---
1 file
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
sound/mips/hal2.c | 31 +--
1
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use GFP_KERNEL instead of GFP_ATOMIC as the gfp_t for the memory
allocation, as we aren't i
69 matches
Mail list logo
