On Thu, 08 Feb 2024 10:52:31 +0100, Luca Weiss wrote:
> This series adds all the necessary bits to enable USB-C role switching,
> charger and fuel gauge (all via pmic-glink) on Fairphone 5.
>
>
Applied, thanks!
[1/2] dt-bindings: soc: qcom: qcom,pmic-glink: document QCM6490 compatible
commit: a5b150af2c6ad2749aee51edc36f9f9883869f5b
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
On Mon, 04 Mar 2024 11:26:09 +0200, Dmitry Baryshkov wrote:
> Reuse Type-C support implemented for the PMI632 PMIC (found on Qualcomm
> Robotics RB2 platform) and implement Type-C handling for the Qualcomm
> Robotics RB1 platform.
>
>
Applied, thanks!
[2/2] arm64: dts: qcom: qrb2210-rb1: enable USB-C port handling
commit: c39c5aed65d428f2a1c2364851c8b44702e9d7db
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
On Tue, 20 Feb 2024 23:21:45 +0300, Danila Tikhonov wrote:
> This series adds typec support for PM6150. Was tested on SM7150
> (xiaomi-surya).
>
> Changes in v2:
> - Drop the patch 1 (from v1), since it has already been applied:
> [1/3] dt-bindings: regulator: qcom,usb-vbus-regulator: Add PM6150
> compatible (commit <ec29a4d9b7c7>)
> - Add Reviewed-by: Krzysztof for patch 1
> - Add Reviewed-by: Dmitry for patch 2
> - Fix typo in commit msg for patch 2 (Quacomm/Qualcomm)
> - Fix IRQ flags in patch 2 according PM8150B (Bryan && Dmitry)
> - Link to v1:
> https://lore.kernel.org/all/20240217163201.32989-1-danila@jiaxyga.com/
>
> [...]
Applied, thanks!
[2/2] arm64: dts: qcom: pm6150: define USB-C related blocks
commit: 601feafa7dad3a1de094ea524b6c2e1315a738d2
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
> We can discuss that offline and come up with an approach that is > reviewable by maintainers and the community. Sure, looking forward to working together with you! Thanks, Albert Wang On Fri, Mar 15, 2024 at 4:57 AM Wesley Cheng <quic_wcheng@quicinc.com> wrote: > > Hi Albert > > On 3/14/2024 3:29 AM, Albert Wang wrote: > > On Thu, Mar 14, 2024 at 3:18 AM Wesley Cheng <quic_wcheng@quicinc.com> wrote: > >> > >> Hi Albert, > >> > >> On 3/13/2024 1:03 AM, Albert Wang wrote: > >>> Hi Wesley, > >>> > >>> The suspend function `qc_usb_audio_offload_suspend()` looks to stop > >>> the traffic on the bus, so that the bus can be suspended. That allows > >>> the application processor(AP) to enter suspend. There is a subtle > >>> difference with our feature, which is to allow AP suspend with the > >>> Host and USB controller active to continue the audio offloading. We > >>> call this feature `allow AP suspend in playback`. So, I have some > >>> points to clarify with you: > >> > >> Yes, I'm aware of that feature also. > >> > >>> 1. Will the suspend flow `usb_audio_suspend() --> > >>> platform_ops->suspend_cb() --> qc_usb_audio_offload_suspend()` be > >>> called when offloading is active? > >> > >> It can be. This is why in our case, we are going to issue the > >> disconnect event to the audio DSP to stop the session if it is currently > >> in one. > >> > >>> 2. As my understanding, the suspend function is to allow AP suspend > >>> when the offloading is IDLE, but it won't allow AP suspend when in > >>> playback or capture. Please correct me if anything is wrong. > >> > >> As mentioned above, it will let apps go into PM suspend after forcing > >> the audio stream to be idle. We won't block PM suspend entry. > >> > > Right. Your design is to force the audio stream idle, or say, inform > > the audio DSP > > to stop the current offloading session first, then AP can go into PM > > suspend as usual. > > Then I can say the current design did not support the `allow AP > > suspend in playback` > > feature, right? > > > > Correct, this series does not cover this mechanism. > > >> Yes, I saw that patch as well. I'll take a look once this series lands > >> upstream. > > > > That patch is rejected and archived now. So we need to find another > > approach to do > > that, even based on your framework. > > > > We can discuss that offline and come up with an approach that is > reviewable by maintainers and the community. > > Thanks > Wesley Cheng > > > Thanks, > > Albert > > > > > >>> 3. We would like to integrate the `allow AP suspend in playback` > >>> feature with your framework to become one upstream offload solution. > >>> Here is the patch: > >>> https://patchwork.kernel.org/project/linux-pm/patch/20240223143833.1509961-1-guanyulin@google.com/ > >>> . > >> > >> Yes, I saw that patch as well. I'll take a look once this series lands > >> upstream. > >> > >> Thanks > >> Wesley Cheng
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. Let's opt for the new 2-argument version of strscpy() which guarantees NUL-termination on the destination buffer and simplifies snytax. The NUL-padding behavior that strncpy() provides is not required as u3d->eps is already zero-allocated: | u3d->eps = kzalloc(size, GFP_KERNEL); Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> --- Note: build-tested only. Found with: $ rg "strncpy\(" --- drivers/usb/gadget/udc/mv_u3d_core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/udc/mv_u3d_core.c b/drivers/usb/gadget/udc/mv_u3d_core.c index 2a421f0ff931..e1dd5cf25d08 100644 --- a/drivers/usb/gadget/udc/mv_u3d_core.c +++ b/drivers/usb/gadget/udc/mv_u3d_core.c @@ -1307,7 +1307,7 @@ static int mv_u3d_eps_init(struct mv_u3d *u3d) /* initialize ep0, ep0 in/out use eps[1] */ ep = &u3d->eps[1]; ep->u3d = u3d; - strncpy(ep->name, "ep0", sizeof(ep->name)); + strscpy(ep->name, "ep0"); ep->ep.name = ep->name; ep->ep.ops = &mv_u3d_ep_ops; ep->wedge = 0; @@ -1337,7 +1337,7 @@ static int mv_u3d_eps_init(struct mv_u3d *u3d) ep->ep.caps.dir_out = true; } ep->u3d = u3d; - strncpy(ep->name, name, sizeof(ep->name)); + strscpy(ep->name, name); ep->ep.name = ep->name; ep->ep.caps.type_iso = true; --- base-commit: bf3a69c6861ff4dc7892d895c87074af7bc1c400 change-id: 20240318-strncpy-drivers-usb-gadget-udc-mv_u3d_core-c-50ea7422311c Best regards, -- Justin Stitt <justinstitt@google.com>
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. Let's use the new 2-argument strscpy() as this guarantees NUL-termination on the destination buffer and also uses the destination buffer's size to bound the operation. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> --- Note: build-tested only. Found with: $ rg "strncpy\(" --- drivers/usb/gadget/function/u_ether.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/u_ether.c b/drivers/usb/gadget/function/u_ether.c index 3c5a6f6ac341..6e4ff64532c2 100644 --- a/drivers/usb/gadget/function/u_ether.c +++ b/drivers/usb/gadget/function/u_ether.c @@ -1032,7 +1032,7 @@ int gether_set_ifname(struct net_device *net, const char *name, int len) if (!p || p[1] != 'd' || strchr(p + 2, '%')) return -EINVAL; - strncpy(net->name, tmp, sizeof(net->name)); + strscpy(net->name, tmp); dev->ifname_set = true; return 0; --- base-commit: bf3a69c6861ff4dc7892d895c87074af7bc1c400 change-id: 20240318-strncpy-drivers-usb-gadget-function-u_ether-c-125ed8336ca5 Best regards, -- Justin Stitt <justinstitt@google.com>
On Mon, Mar 18, 2024, at 3:22 PM, Yaroslav Isakov wrote: > Hello, Mark! > > пн, 18 мар. 2024 г. в 19:48, Mark Pearson <mpearson@squebb.ca>: >> >> On Thu, Feb 22, 2024, at 9:30 AM, Mark Pearson wrote: >> > Hi, >> > >> Just to confirm that I've tested a trial BIOS from the FW team and it fixes the issue (shows up under /sys/class/typec > Great to hear, thank you! > >> If there's anything in particular you'd like me to confirm let me know. > > If /sys/class/typec is populated, I think it should be enough... Just > to double check, is /sys/class/usb_power_delivery populated, too, now? Yes. From my system: # ls /sys/class/typec port0 port0-partner port1 # ls /sys/class/usb_power_delivery pd0 pd1 pd2 > > I also did not manage to see anything in /sys/class/usb_role or > /sys/class/typec_mux, even with my hack - is it expected on AMD, > because of lack of appropriate mux/role switch drivers? I'm not seeing anything under those with this BIOS either I checked on an Intel platform on my desk (P14s G3) and those aren't populated there either...so not sure this is AMD specific. I'm being lazy and not looking at the kernel code - what would we expect to see in those entries? Mark
> -----Original Message----- > From: Thinh Nguyen <Thinh.Nguyen@synopsys.com> > Sent: Friday, March 15, 2024 6:32 AM > To: Simek, Michal <michal.simek@amd.com> > Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>; Pandey, Radhey Shyam > <radhey.shyam.pandey@amd.com>; gregkh@linuxfoundation.org; linux- > usb@vger.kernel.org; linux-kernel@vger.kernel.org; git (AMD-Xilinx) > <git@amd.com> > Subject: Re: [PATCH v2] usb: dwc3: core: enable CCI support for AMD-xilinx > DWC3 controller > > On Thu, Mar 07, 2024, Michal Simek wrote: > > > > > > On 3/7/24 02:44, Thinh Nguyen wrote: > > > Hi, > > > > > > On Tue, Feb 27, 2024, Pandey, Radhey Shyam wrote: > > > > > -----Original Message----- > > > > > From: Thinh Nguyen <Thinh.Nguyen@synopsys.com> > > > > > Sent: Saturday, February 24, 2024 4:38 AM > > > > > To: Pandey, Radhey Shyam <radhey.shyam.pandey@amd.com> > > > > > Cc: gregkh@linuxfoundation.org; linux-usb@vger.kernel.org; linux- > > > > > kernel@vger.kernel.org; git (AMD-Xilinx) <git@amd.com> > > > > > Subject: Re: [PATCH v2] usb: dwc3: core: enable CCI support for AMD- > xilinx > > > > > DWC3 controller > > > > > > > > > > On Fri, Feb 23, 2024, Thinh Nguyen wrote: > > > > > > On Sat, Feb 24, 2024, Radhey Shyam Pandey wrote: > > > > > > > From: Piyush Mehta <piyush.mehta@amd.com> > > > > > > > > > > > > > > The GSBUSCFG0 register bits [31:16] are used to configure the > cache type > > > > > > > settings of the descriptor and data write/read transfers > (Cacheable, > > > > > > > Bufferable/ Posted). When CCI is enabled in the design, DWC3 > core > > > > > GSBUSCFG0 > > > > > > > cache bits must be updated to support CCI enabled transfers in > USB. > > > > > > > > > > > > > > Signed-off-by: Piyush Mehta <piyush.mehta@amd.com> > > > > > > > Signed-off-by: Radhey Shyam Pandey > > > > > <radhey.shyam.pandey@amd.com> > > > > > > > ---- > > > > > > > changes for v2: > > > > > > > Make GSBUSCFG0 configuration specific to AMD-xilinx platform. > > > > > > > Taken reference from existing commit ec5eb43813a4 ("usb: dwc3: > core: > > > > > > > add support for realtek SoCs custom's global register start > address") > > > > > > > > > > Regarding that change from Realtek, it's a special case. I want to avoid > > > > > doing platform specific checks in the core.c if possible. Eventually, I > > > > > want to move that logic from Realtek to its glue driver. > > > > > > > > > > BR, > > > > > Thinh > > > > Thanks. As you suggested I tried "temporarily memory map and update > this > > > > register in your Xilinx glue driver. Its value should retain after soft > reset". > > > > > > > > Did ioremap for core register space once again in glue driver but it > resulted > > > > in below error: > > > > dwc3 fe200000.usb: can't request region for resource [mem > 0xfe200000-0xfe23ffff] > > > > dwc3-xilinx ff9d0000.usb: error -EBUSY: failed to map DWC3 registers > > > > > > > > So to avoid remapping, now get the struct dwc3 platform data handle in > glue > > > > driver and pass it to dwc3_readl/writel() like the below sequence. Is > that fine? > > > > If yes I will respin v3 with these changes and also do some more > > > > sanity tests. > > > > > > > > drivers/usb/dwc3/dwc3-xilinx.c > > > > #include "io.h" > > > > > > > > <snip> > > > > ret = of_platform_populate(np, NULL, NULL, dev); > > > > if (ret) { > > > > dev_err(dev, "failed to register dwc3 core - %d\n", ret); > > > > goto err_clk_put; > > > > } > > > > > > > > dwc3_np = of_get_compatible_child(np, "snps,dwc3"); > > > > priv_data->dwc3 = of_find_device_by_node(dwc3_np); > > > > dwc = platform_get_drvdata(priv_data->dwc3); > > > > if (of_dma_is_coherent(dev->of_node)) { > > > > reg = dwc3_readl(dwc->regs , DWC3_GSBUSCFG0); > > > > reg |= DWC3_GSBUSCFG0_DATRDREQINFO_MASK | > > > > DWC3_GSBUSCFG0_DESRDREQINFO_MASK | > > > > DWC3_GSBUSCFG0_DATWRREQINFO_MASK | > > > > DWC3_GSBUSCFG0_DESWRREQINFO_MASK; > > > > > > It's a bit odd to use "mask" as value instead of some defined > > > macros/values. > > > > > > > dwc3_writel(dwc->regs , DWC3_GSBUSCFG0, reg); > > > > } > > > > > > > > > > Perhaps it may be better to add a new interface for the core to interact > > > with the glue drivers. The core can use these callbacks to properly set > > > platform specific configuration at specified sequence of the controller > > > initialization. It will be better defined and more predictable than what > > > we have here. What do you think? > > > > Not sure I fully understand what you mean by more predictable. > > Are you asking for simple read/write interface to dwc3 core IP? > > Do you want there any limitation for accesses to be able to control it? > > > > I don't think we have any issue with your suggestion but it is unclear how > > exactly it should look like. > > Can you please sketch it? > > > > Hi, > > Sorry, my suggestion would require a handler for the glue driver and the > core. But the various implementations in different glue drivers are > handled in such a way that won't be simple to pass this handle around. > This can get hairy quickly... > > Let's scratch what I suggested. > > Instead, perhaps we can do it as following: > * Keep the setting of the controller registers in the core > * Create a software_node to pass a software property to the core Thanks. By software property you mean flags or caps that can be passed glue drivers to dwc3 core driver ? dwc3_set_quirks(struct dwc3 *dwc, u64 flags); Defines quirks in core.h DWC3_FLAGS_COMMON DWC3_XLNX_CCI DWC3_XLNX_IPD DWC3_REALTEK_RES_FIX Then based on these quirks/flags program it in core.c. Is this approach fine and aligned with your thoughts? Thanks, Radhey > > These software properties will not be documented in the devicetree > binding. Just document them in the driver core header. They are simply > driver properties that get passed through software node. > > You can add the software node using device_add_software_node(). This can > be done before calling of_platform_populate() in dwc3-xilinx (can be > done in pltfm_init()) > > Let me know if this works for you. > > Thanks, > Thinh
Hello, Mark! пн, 18 мар. 2024 г. в 19:48, Mark Pearson <mpearson@squebb.ca>: > > On Thu, Feb 22, 2024, at 9:30 AM, Mark Pearson wrote: > > Hi, > > > > On Tue, Dec 19, 2023, at 5:02 AM, Heikki Krogerus wrote: > >> On Mon, Dec 18, 2023 at 06:45:05PM +0100, Yaroslav Isakov wrote: > >>> пн, 18 дек. 2023 г. в 04:46, Douglas Gilbert <dgilbert@interlog.com>: > >>> > > >>> > On 12/17/23 16:25, Yaroslav Isakov wrote: > >>> > > вс, 17 дек. 2023 г. в 21:48, Yaroslav Isakov <yaroslav.isakov@gmail.com>: > >>> > >> > >>> > >> вс, 17 дек. 2023 г. в 20:15, Douglas Gilbert <dgilbert@interlog.com>: > >>> > >>> > >>> > >>> On 12/17/23 12:24, Yaroslav Isakov wrote: > >>> > >>>> вс, 17 дек. 2023 г. в 18:08, Douglas Gilbert <dgilbert@interlog.com>: > >>> > >>>>> > >>> > >>>>> On 12/17/23 11:21, Yaroslav Isakov wrote: > >>> > >>>>>> Hello! I recently bought Thinkpad T14 Gen 4 AMD laptop, and I > >>> > >>>>>> installed Gentoo on it, with kernel 6.6.4. > >>> > >>>>>> > >>> > >>>>>> Even though type-c ports seems to be working (I checked usb3 flash > >>> > >>>>>> stick, lenovo charger, Jabra headset, Yubikey), I cannot see any > >>> > >>>>>> devices in /sys/class/(typec,typec_mux,usb_power_delivery). > >>> > >>>>>> > >>> > >>>>>> There are no messages in dmesg at all, mentioning typec. I can see > >>> > >>>>>> that modules typec_ucsi, ucsi_acpi, thunderbolt are loaded. I can see > >>> > >>>>>> that device TYPEC000 is present on acpi bus, there are files in > >>> > >>>>>> /sys/bus/acpi/devices/USBC000:00, but, there is no driver linked in > >>> > >>>>>> it. > >>> > >>>>>> > >>> > >>>>>> I tried to recompile module ucsi_acpi, with adding { "USBC000", 0 } > >>> > >>>>>> to ucsi_acpi_match, but it did not change anything (except that in > >>> > >>>>>> modinfo of this module, USBC000 is now seen. > >>> > >>>>>> > >>> > >>>>>> I tried to decompile SSDT1 table, which has definition of USBC, but > >>> > >>>>>> there is nothing in it, which is supicious. > >>> > >>>>>> > >>> > >>>>>> What else can I check, to understand, why can't I see anything in > >>> > >>>>>> typec/PD subsystems? > >>> > >>>>>> > >>> > >>>>> > >>> > >>>>> I have a X13 Gen 3 [i5-1240P] which is about 18 months old. Everything you > >>> > >>>>> mention is present plus the typec ports and the associated pd objects: > >>> > >>>>> > >>> > >>>>> $ lsucpd > >>> > >>>>> port0 [pd0] <<==== partner [pd2] > >>> > >>>>> port1 [pd1] < > >>> > >>>> > >>> > >>>> I guess, it makes no sense to install lsucpd, if it checks /sys/class/typec etc? > >>> > >>>> > >>> > >>>>> > >>> > >>>>> A power adapter is connected to port0. Here are the modules loaded: > >>> > >>>>> > >>> > >>>>> $ lsmod | grep typec > >>> > >>>>> typec_ucsi 57344 1 ucsi_acpi > >>> > >>>>> roles 16384 1 typec_ucsi > >>> > >>>>> typec 114688 1 typec_ucsi > >>> > >>>>> usb_common 20480 4 xhci_hcd,usbcore,uvcvideo,typec_ucsi > >>> > >>>>> $ lsmod | grep ucsi > >>> > >>>>> ucsi_acpi 12288 0 > >>> > >>>>> typec_ucsi 57344 1 ucsi_acpi > >>> > >>>>> roles 16384 1 typec_ucsi > >>> > >>>>> typec 114688 1 typec_ucsi > >>> > >>>>> usb_common 20480 4 xhci_hcd,usbcore,uvcvideo,typec_ucsi > >>> > >>>>> > >>> > >>>> I have exact same modules. > >>> > >>>> > >>> > >>>>> $ ls /sys/bus/acpi/devices/USBC000:00 > >>> > >>>>> device:ac device:ad hid modalias path physical_node power status > >>> > >>>>> subsystem uevent uid wakeup > >>> > >>>> Under /sys/bus/acpi/devices/USBC000:00 I have the similar files: > >>> > >>>> adr device:48 device:49 hid modalias path physical_node power > >>> > >>>> status subsystem uevent uid > >>> > >>>> As you don't have driver symlink there, too, then it's a red herring, > >>> > >>>> that lack of driver file is symptom of this issue. > >>> > >>>> > >>> > >>>>> > >>> > >>>>> Strange that the Thunderbolt module is loaded since I thought only the Intel > >>> > >>>>> variants supported Thunderbolt. > >>> > >>>> thundebolt module is now shared with USB4 subsystem, and T14 started > >>> > >>>> to have USB4 from Gen 3, for AMD variant. > >>> > >>>>> > >>> > >>>>> The only thing that I can think of is some BIOS setting. When I poked around > >>> > >>>>> in the X13 BIOS I don't remember any setting that would cause what you are > >>> > >>>>> seeing.] > >>> > >>>> I checked BIOS settings, but I cannot find anything related > >>> > >>>> > >>> > >>>> Could you please show, what drivers are used for device:ac and > >>> > >>>> device:ad, under /sys/bus/acpi/devices/USBC000:00? It seems that if I > >>> > >>>> have such entries in my /sys/bus/acpi/devices/USBC000:00, at least > >>> > >>>> ucsi_acpi works properly. > >>> > >>> > >>> > >>> dougg@treten:/sys/bus/acpi/devices/USBC000:00/device:ac$ ls -l > >>> > >>> total 0 > >>> > >>> -r--r--r-- 1 root root 4096 Dec 16 19:11 adr > >>> > >>> -r--r--r-- 1 root root 4096 Dec 16 19:11 path > >>> > >>> lrwxrwxrwx 1 root root 0 Dec 16 19:11 physical_node -> > >>> > >>> ../../../../platform/USBC000:00/typec/port0 > >>> > >>> drwxr-xr-x 2 root root 0 Dec 16 19:11 power > >>> > >>> lrwxrwxrwx 1 root root 0 Dec 16 16:45 subsystem -> ../../../../../bus/acpi > >>> > >>> -rw-r--r-- 1 root root 4096 Dec 16 16:45 uevent > >>> > >>> > >>> > >>> dougg@treten:/sys/bus/acpi/devices/USBC000:00/device:ac$ cd ../device\:ad > >>> > >>> dougg@treten:/sys/bus/acpi/devices/USBC000:00/device:ad$ ls -l > >>> > >>> total 0 > >>> > >>> -r--r--r-- 1 root root 4096 Dec 16 19:11 adr > >>> > >>> -r--r--r-- 1 root root 4096 Dec 16 19:11 path > >>> > >>> lrwxrwxrwx 1 root root 0 Dec 16 19:11 physical_node -> > >>> > >>> ../../../../platform/USBC000:00/typec/port1 > >>> > >>> drwxr-xr-x 2 root root 0 Dec 16 19:11 power > >>> > >>> lrwxrwxrwx 1 root root 0 Dec 16 16:45 subsystem -> ../../../../../bus/acpi > >>> > >>> -rw-r--r-- 1 root root 4096 Dec 16 16:45 uevent > >>> > >>> > >>> > >>> > >>> > >>>> > >>> > >>>> In my /sys/bus/acpi/devices/USBC000:00/device:(48,49), there are only > >>> > >>>> adr, path and uevent files, and power and subsytem folders. Subsystem > >>> > >>>> links to bus/acpi, and path has \_SB_.UBTC.CR01, \_SB_.UBTC.CR02 > >>> > >>> > >>> > >>> Mine has the extra physical_node symlinks to typec/port0 and typec/port1 > >>> > >> Yes, I have the same as on T14 Gen 3 (Intel). Looks like they have no > >>> > >> driver symlinks, too, but they're working on Intel. > >>> > >>> > >>> > >>>> P.S. I tried latest live Fedora, just to see if I forgot to compile > >>> > >>>> some drivers for custom-built Gentoo kernel, but same issue on Fedora > >>> > >>> > >>> > >>> Below is a fragment of a post from Heikki Krogerus about turning on ucsi debug: > >>> > >>> > >>> > >>> If you want to see the actual UCSI notification in user space, then > >>> > >>> that is not possible, but the driver does produce trace output, and I > >>> > >>> would actually like to see what we got there. You need debugfs to be > >>> > >>> mounted. Then try the following: > >>> > >>> > >>> > >>> # Unload all UCSI modules > >>> > >>> modprobe -r ucsi_acpi > >>> > >>> > >>> > >>> # At this point you should plug-in the problematic device > >>> > >>> > >>> > >>> # Reload the UCSI core module > >>> > >>> modprobe typec_ucsi > >>> > >>> > >>> > >>> # Enable UCSI tracing > >>> > >>> echo 1 > /sys/kernel/debug/tracing/events/ucsi/enable > >>> > >>> > >>> > >>> # Now reload the ACPI glue driver > >>> > >>> modprobe ucsi_acpi > >>> > >>> > >>> > >>> # Unplug the problematic device so that you see the error > >>> > >>> > >>> > >>> # Finally dump the trace output > >>> > >>> cat /sys/kernel/debug/tracing/trace > >>> > >>> > >>> > >>> So if that works, please send the trace output to me. > >>> > >>> [Heikki] > >>> > >> I tried provided commands, both in Gentoo and Fedora - nothing in > >>> > >> trace at all. I guess, it's because ucsi on AMD can see two devices, > >>> > >> but cannot work with them, for some reason. I also checked same > >>> > >> commands on T14 Gen 3 (Intel), and I can see many ucsi_register_port > >>> > >> and ucsi_register_altmode events. > >>> > >>> > >>> > >>> > >>> > > > >>> > > I think I managed to find the issue - looks like on my laptop, > >>> > > ucsi_register fails in version check, !ucsi->version returns False. > >>> > > Commenting out this check populates /sys/class/typec and > >>> > > /sys/class/usb_power_delivery. I did not check yet, if populated data > >>> > > is correct, but, it's definite progress. > >>> > > >>> > Well spotted. > >>> > > >>> > That is probably the first UCSI read operation that failed. At the very least > >>> > ucsi_register() could send a message to the log that it was exiting rather > >>> > than leave users guessing. > >>> It returns -ENODEV, which, I guess, is a signal for code, which > >>> detects devices, that this module doesn't support this device. > >>> > >>> P.S. Looks like power_delivery code works properly, even with > >>> version==0 - lsucpd shows proper directions, even with my Pixel 7, > >>> which can charge laptop. Also it shows correct data for > >>> voltage/current, for "partner" device. It also shows proper data in > >>> power_supply subsystem. The only thing which is not working, > >>> currently, is displayport altmode not showing, for dockstation I > >>> have... But this might be missing module, or something else... I'll > >>> try this on Intel laptop, and will debug it further. > >>> > >>> > > >>> > My guess is that Lenovo/AMD have a configuration or timing issue. > >>> > >>> I tried to add loop, re-reading version in case if it's zero, but, > >>> even after 10 tries, it's returning zero, so, it's some weird behavior > >>> of UCSI on this AMD laptop. I wonder, what should be the proper fix, > >>> then. > >> > >> You need to report this to Lenovo. This is an issue in their firmware. > >> > >> We can work around this by adding DMI quirk where we hardcode the UCSI > >> version for your system, but before we do that, you should try to get > >> Lenovo to fix their firmware. > >> > > I got forwarded this report from the support team. Was able to > > reproduce this on my system. > > I have internal ticket LO-2879 open and we'll look into it. > > > Just to confirm that I've tested a trial BIOS from the FW team and it fixes the issue (shows up under /sys/class/typec Great to hear, thank you! > If there's anything in particular you'd like me to confirm let me know. If /sys/class/typec is populated, I think it should be enough... Just to double check, is /sys/class/usb_power_delivery populated, too, now? I also did not manage to see anything in /sys/class/usb_role or /sys/class/typec_mux, even with my hack - is it expected on AMD, because of lack of appropriate mux/role switch drivers? > > I've asked the FW team for confirmation when the fix will be released. Expect it to take a while as the test/release process can take some time > > Mark
On Thu, Feb 22, 2024, at 9:30 AM, Mark Pearson wrote:
> Hi,
>
> On Tue, Dec 19, 2023, at 5:02 AM, Heikki Krogerus wrote:
>> On Mon, Dec 18, 2023 at 06:45:05PM +0100, Yaroslav Isakov wrote:
>>> пн, 18 дек. 2023 г. в 04:46, Douglas Gilbert <dgilbert@interlog.com>:
>>> >
>>> > On 12/17/23 16:25, Yaroslav Isakov wrote:
>>> > > вс, 17 дек. 2023 г. в 21:48, Yaroslav Isakov <yaroslav.isakov@gmail.com>:
>>> > >>
>>> > >> вс, 17 дек. 2023 г. в 20:15, Douglas Gilbert <dgilbert@interlog.com>:
>>> > >>>
>>> > >>> On 12/17/23 12:24, Yaroslav Isakov wrote:
>>> > >>>> вс, 17 дек. 2023 г. в 18:08, Douglas Gilbert <dgilbert@interlog.com>:
>>> > >>>>>
>>> > >>>>> On 12/17/23 11:21, Yaroslav Isakov wrote:
>>> > >>>>>> Hello! I recently bought Thinkpad T14 Gen 4 AMD laptop, and I
>>> > >>>>>> installed Gentoo on it, with kernel 6.6.4.
>>> > >>>>>>
>>> > >>>>>> Even though type-c ports seems to be working (I checked usb3 flash
>>> > >>>>>> stick, lenovo charger, Jabra headset, Yubikey), I cannot see any
>>> > >>>>>> devices in /sys/class/(typec,typec_mux,usb_power_delivery).
>>> > >>>>>>
>>> > >>>>>> There are no messages in dmesg at all, mentioning typec. I can see
>>> > >>>>>> that modules typec_ucsi, ucsi_acpi, thunderbolt are loaded. I can see
>>> > >>>>>> that device TYPEC000 is present on acpi bus, there are files in
>>> > >>>>>> /sys/bus/acpi/devices/USBC000:00, but, there is no driver linked in
>>> > >>>>>> it.
>>> > >>>>>>
>>> > >>>>>> I tried to recompile module ucsi_acpi, with adding { "USBC000", 0 }
>>> > >>>>>> to ucsi_acpi_match, but it did not change anything (except that in
>>> > >>>>>> modinfo of this module, USBC000 is now seen.
>>> > >>>>>>
>>> > >>>>>> I tried to decompile SSDT1 table, which has definition of USBC, but
>>> > >>>>>> there is nothing in it, which is supicious.
>>> > >>>>>>
>>> > >>>>>> What else can I check, to understand, why can't I see anything in
>>> > >>>>>> typec/PD subsystems?
>>> > >>>>>>
>>> > >>>>>
>>> > >>>>> I have a X13 Gen 3 [i5-1240P] which is about 18 months old. Everything you
>>> > >>>>> mention is present plus the typec ports and the associated pd objects:
>>> > >>>>>
>>> > >>>>> $ lsucpd
>>> > >>>>> port0 [pd0] <<==== partner [pd2]
>>> > >>>>> port1 [pd1] <
>>> > >>>>
>>> > >>>> I guess, it makes no sense to install lsucpd, if it checks /sys/class/typec etc?
>>> > >>>>
>>> > >>>>>
>>> > >>>>> A power adapter is connected to port0. Here are the modules loaded:
>>> > >>>>>
>>> > >>>>> $ lsmod | grep typec
>>> > >>>>> typec_ucsi 57344 1 ucsi_acpi
>>> > >>>>> roles 16384 1 typec_ucsi
>>> > >>>>> typec 114688 1 typec_ucsi
>>> > >>>>> usb_common 20480 4 xhci_hcd,usbcore,uvcvideo,typec_ucsi
>>> > >>>>> $ lsmod | grep ucsi
>>> > >>>>> ucsi_acpi 12288 0
>>> > >>>>> typec_ucsi 57344 1 ucsi_acpi
>>> > >>>>> roles 16384 1 typec_ucsi
>>> > >>>>> typec 114688 1 typec_ucsi
>>> > >>>>> usb_common 20480 4 xhci_hcd,usbcore,uvcvideo,typec_ucsi
>>> > >>>>>
>>> > >>>> I have exact same modules.
>>> > >>>>
>>> > >>>>> $ ls /sys/bus/acpi/devices/USBC000:00
>>> > >>>>> device:ac device:ad hid modalias path physical_node power status
>>> > >>>>> subsystem uevent uid wakeup
>>> > >>>> Under /sys/bus/acpi/devices/USBC000:00 I have the similar files:
>>> > >>>> adr device:48 device:49 hid modalias path physical_node power
>>> > >>>> status subsystem uevent uid
>>> > >>>> As you don't have driver symlink there, too, then it's a red herring,
>>> > >>>> that lack of driver file is symptom of this issue.
>>> > >>>>
>>> > >>>>>
>>> > >>>>> Strange that the Thunderbolt module is loaded since I thought only the Intel
>>> > >>>>> variants supported Thunderbolt.
>>> > >>>> thundebolt module is now shared with USB4 subsystem, and T14 started
>>> > >>>> to have USB4 from Gen 3, for AMD variant.
>>> > >>>>>
>>> > >>>>> The only thing that I can think of is some BIOS setting. When I poked around
>>> > >>>>> in the X13 BIOS I don't remember any setting that would cause what you are
>>> > >>>>> seeing.]
>>> > >>>> I checked BIOS settings, but I cannot find anything related
>>> > >>>>
>>> > >>>> Could you please show, what drivers are used for device:ac and
>>> > >>>> device:ad, under /sys/bus/acpi/devices/USBC000:00? It seems that if I
>>> > >>>> have such entries in my /sys/bus/acpi/devices/USBC000:00, at least
>>> > >>>> ucsi_acpi works properly.
>>> > >>>
>>> > >>> dougg@treten:/sys/bus/acpi/devices/USBC000:00/device:ac$ ls -l
>>> > >>> total 0
>>> > >>> -r--r--r-- 1 root root 4096 Dec 16 19:11 adr
>>> > >>> -r--r--r-- 1 root root 4096 Dec 16 19:11 path
>>> > >>> lrwxrwxrwx 1 root root 0 Dec 16 19:11 physical_node ->
>>> > >>> ../../../../platform/USBC000:00/typec/port0
>>> > >>> drwxr-xr-x 2 root root 0 Dec 16 19:11 power
>>> > >>> lrwxrwxrwx 1 root root 0 Dec 16 16:45 subsystem -> ../../../../../bus/acpi
>>> > >>> -rw-r--r-- 1 root root 4096 Dec 16 16:45 uevent
>>> > >>>
>>> > >>> dougg@treten:/sys/bus/acpi/devices/USBC000:00/device:ac$ cd ../device\:ad
>>> > >>> dougg@treten:/sys/bus/acpi/devices/USBC000:00/device:ad$ ls -l
>>> > >>> total 0
>>> > >>> -r--r--r-- 1 root root 4096 Dec 16 19:11 adr
>>> > >>> -r--r--r-- 1 root root 4096 Dec 16 19:11 path
>>> > >>> lrwxrwxrwx 1 root root 0 Dec 16 19:11 physical_node ->
>>> > >>> ../../../../platform/USBC000:00/typec/port1
>>> > >>> drwxr-xr-x 2 root root 0 Dec 16 19:11 power
>>> > >>> lrwxrwxrwx 1 root root 0 Dec 16 16:45 subsystem -> ../../../../../bus/acpi
>>> > >>> -rw-r--r-- 1 root root 4096 Dec 16 16:45 uevent
>>> > >>>
>>> > >>>
>>> > >>>>
>>> > >>>> In my /sys/bus/acpi/devices/USBC000:00/device:(48,49), there are only
>>> > >>>> adr, path and uevent files, and power and subsytem folders. Subsystem
>>> > >>>> links to bus/acpi, and path has \_SB_.UBTC.CR01, \_SB_.UBTC.CR02
>>> > >>>
>>> > >>> Mine has the extra physical_node symlinks to typec/port0 and typec/port1
>>> > >> Yes, I have the same as on T14 Gen 3 (Intel). Looks like they have no
>>> > >> driver symlinks, too, but they're working on Intel.
>>> > >>>
>>> > >>>> P.S. I tried latest live Fedora, just to see if I forgot to compile
>>> > >>>> some drivers for custom-built Gentoo kernel, but same issue on Fedora
>>> > >>>
>>> > >>> Below is a fragment of a post from Heikki Krogerus about turning on ucsi debug:
>>> > >>>
>>> > >>> If you want to see the actual UCSI notification in user space, then
>>> > >>> that is not possible, but the driver does produce trace output, and I
>>> > >>> would actually like to see what we got there. You need debugfs to be
>>> > >>> mounted. Then try the following:
>>> > >>>
>>> > >>> # Unload all UCSI modules
>>> > >>> modprobe -r ucsi_acpi
>>> > >>>
>>> > >>> # At this point you should plug-in the problematic device
>>> > >>>
>>> > >>> # Reload the UCSI core module
>>> > >>> modprobe typec_ucsi
>>> > >>>
>>> > >>> # Enable UCSI tracing
>>> > >>> echo 1 > /sys/kernel/debug/tracing/events/ucsi/enable
>>> > >>>
>>> > >>> # Now reload the ACPI glue driver
>>> > >>> modprobe ucsi_acpi
>>> > >>>
>>> > >>> # Unplug the problematic device so that you see the error
>>> > >>>
>>> > >>> # Finally dump the trace output
>>> > >>> cat /sys/kernel/debug/tracing/trace
>>> > >>>
>>> > >>> So if that works, please send the trace output to me.
>>> > >>> [Heikki]
>>> > >> I tried provided commands, both in Gentoo and Fedora - nothing in
>>> > >> trace at all. I guess, it's because ucsi on AMD can see two devices,
>>> > >> but cannot work with them, for some reason. I also checked same
>>> > >> commands on T14 Gen 3 (Intel), and I can see many ucsi_register_port
>>> > >> and ucsi_register_altmode events.
>>> > >>>
>>> > >>>
>>> > >
>>> > > I think I managed to find the issue - looks like on my laptop,
>>> > > ucsi_register fails in version check, !ucsi->version returns False.
>>> > > Commenting out this check populates /sys/class/typec and
>>> > > /sys/class/usb_power_delivery. I did not check yet, if populated data
>>> > > is correct, but, it's definite progress.
>>> >
>>> > Well spotted.
>>> >
>>> > That is probably the first UCSI read operation that failed. At the very least
>>> > ucsi_register() could send a message to the log that it was exiting rather
>>> > than leave users guessing.
>>> It returns -ENODEV, which, I guess, is a signal for code, which
>>> detects devices, that this module doesn't support this device.
>>>
>>> P.S. Looks like power_delivery code works properly, even with
>>> version==0 - lsucpd shows proper directions, even with my Pixel 7,
>>> which can charge laptop. Also it shows correct data for
>>> voltage/current, for "partner" device. It also shows proper data in
>>> power_supply subsystem. The only thing which is not working,
>>> currently, is displayport altmode not showing, for dockstation I
>>> have... But this might be missing module, or something else... I'll
>>> try this on Intel laptop, and will debug it further.
>>>
>>> >
>>> > My guess is that Lenovo/AMD have a configuration or timing issue.
>>>
>>> I tried to add loop, re-reading version in case if it's zero, but,
>>> even after 10 tries, it's returning zero, so, it's some weird behavior
>>> of UCSI on this AMD laptop. I wonder, what should be the proper fix,
>>> then.
>>
>> You need to report this to Lenovo. This is an issue in their firmware.
>>
>> We can work around this by adding DMI quirk where we hardcode the UCSI
>> version for your system, but before we do that, you should try to get
>> Lenovo to fix their firmware.
>>
> I got forwarded this report from the support team. Was able to
> reproduce this on my system.
> I have internal ticket LO-2879 open and we'll look into it.
>
Just to confirm that I've tested a trial BIOS from the FW team and it fixes the issue (shows up under /sys/class/typec
If there's anything in particular you'd like me to confirm let me know.
I've asked the FW team for confirmation when the fix will be released. Expect it to take a while as the test/release process can take some time
Mark
Remove the trailing comma in the terminator entry for the OF table making code robust against (theoretical) misrebases or other similar things where the new entry goes _after_ the termination without the compiler noticing. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> --- v3->v4: * No change. v2->v3: * No change. v1->v2: * Added Rb tag from Geert. --- drivers/usb/renesas_usbhs/common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/renesas_usbhs/common.c b/drivers/usb/renesas_usbhs/common.c index df94375f6c23..7ec1ab90fef3 100644 --- a/drivers/usb/renesas_usbhs/common.c +++ b/drivers/usb/renesas_usbhs/common.c @@ -597,7 +597,7 @@ static const struct of_device_id usbhs_of_match[] = { .compatible = "renesas,rzg2l-usbhs", .data = &usbhs_rzg2l_plat_info, }, - { }, + { } }; MODULE_DEVICE_TABLE(of, usbhs_of_match); -- 2.25.1
As per the hardware manual, double buffer setting results in fewer interrupts for high-speed data transfers. Improve usbhsc_default_pipe[] for isochronous transfers by updating the table from single->double buffering and update the pipe number accordingly. Suggested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> --- v3->v4: * Added Rbtag from Geert. v3: * New patch --- drivers/usb/renesas_usbhs/common.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/usb/renesas_usbhs/common.c b/drivers/usb/renesas_usbhs/common.c index 0c62e4c6c88d..177fa3144a47 100644 --- a/drivers/usb/renesas_usbhs/common.c +++ b/drivers/usb/renesas_usbhs/common.c @@ -366,11 +366,11 @@ static void usbhsc_clk_disable_unprepare(struct usbhs_priv *priv) /* commonly used on old SH-Mobile SoCs */ static struct renesas_usbhs_driver_pipe_config usbhsc_default_pipe[] = { RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_CONTROL, 64, 0x00, false), - RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_ISOC, 1024, 0x08, false), - RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_ISOC, 1024, 0x18, false), - RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_BULK, 512, 0x28, true), - RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_BULK, 512, 0x38, true), + RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_ISOC, 1024, 0x08, true), + RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_ISOC, 1024, 0x28, true), RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_BULK, 512, 0x48, true), + RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_BULK, 512, 0x58, true), + RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_BULK, 512, 0x68, true), RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_INT, 64, 0x04, false), RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_INT, 64, 0x05, false), RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_INT, 64, 0x06, false), -- 2.25.1
The RZ/G2L family SoCs has 10 pipe buffers compared to 16 pipe buffers on RZ/A2M. Update the pipe configuration for RZ/G2L family SoCs and use family SoC specific compatible to handle this difference. The pipe configuration of RZ/G2L is same as usbhsc_rzg2l_default_pipe[], so select the default pipe configuration for RZ/G2L SoCs by setting .has_new_pipe_configs to zero. Add SoC specific compatible to OF table to avoid ABI breakage with old DTB. To optimize memory usage the SoC specific compatible will be removed later. Based on the patch in BSP by Huy Nguyen <huy.nguyen.wh@renesas.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> --- v3->v4: * Credit Huy Nguyen's work in the commit message and dropped his name from Signed-off-by tag. * Selection of usbhsc_rzg2l_default_pipe[] by setting the variable has_new_pipe_configs to zero. * Updated commit description. * Dropped the check 'priv->dparam.pipe_configs' as it is same as checking !has_new_pipe_configs. v2->v3: * Updated commit description * Dropped usbhsc_rzg2l_pipe[] and reusing the default_pipe[]. v1->v2: * Dropped using of_device_is_compatible() in probe. * Added usbhs_rzg2l_plat_info and replaced the device data for RZ/G2L from usbhs_rza2_plat_info->usbhs_rzg2l_plat_info. * Moved usbhsc_rzg2l_pipe table near to the user. * Updated commit description. --- drivers/usb/renesas_usbhs/common.c | 20 ++++++++++++++++++-- drivers/usb/renesas_usbhs/rza.h | 1 + drivers/usb/renesas_usbhs/rza2.c | 13 +++++++++++++ 3 files changed, 32 insertions(+), 2 deletions(-) diff --git a/drivers/usb/renesas_usbhs/common.c b/drivers/usb/renesas_usbhs/common.c index 177fa3144a47..df94375f6c23 100644 --- a/drivers/usb/renesas_usbhs/common.c +++ b/drivers/usb/renesas_usbhs/common.c @@ -363,7 +363,7 @@ static void usbhsc_clk_disable_unprepare(struct usbhs_priv *priv) * platform default param */ -/* commonly used on old SH-Mobile SoCs */ +/* commonly used on old SH-Mobile and RZ/G2L family SoCs */ static struct renesas_usbhs_driver_pipe_config usbhsc_default_pipe[] = { RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_CONTROL, 64, 0x00, false), RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_ISOC, 1024, 0x08, true), @@ -565,6 +565,18 @@ static const struct of_device_id usbhs_of_match[] = { .compatible = "renesas,usbhs-r8a77995", .data = &usbhs_rcar_gen3_with_pll_plat_info, }, + { + .compatible = "renesas,usbhs-r9a07g043", + .data = &usbhs_rzg2l_plat_info, + }, + { + .compatible = "renesas,usbhs-r9a07g044", + .data = &usbhs_rzg2l_plat_info, + }, + { + .compatible = "renesas,usbhs-r9a07g054", + .data = &usbhs_rzg2l_plat_info, + }, { .compatible = "renesas,rcar-gen2-usbhs", .data = &usbhs_rcar_gen2_plat_info, @@ -581,6 +593,10 @@ static const struct of_device_id usbhs_of_match[] = { .compatible = "renesas,rza2-usbhs", .data = &usbhs_rza2_plat_info, }, + { + .compatible = "renesas,rzg2l-usbhs", + .data = &usbhs_rzg2l_plat_info, + }, { }, }; MODULE_DEVICE_TABLE(of, usbhs_of_match); @@ -642,7 +658,7 @@ static int usbhs_probe(struct platform_device *pdev) if (usbhs_get_dparam(priv, has_new_pipe_configs)) { priv->dparam.pipe_configs = usbhsc_new_pipe; priv->dparam.pipe_size = ARRAY_SIZE(usbhsc_new_pipe); - } else if (!priv->dparam.pipe_configs) { + } else { priv->dparam.pipe_configs = usbhsc_default_pipe; priv->dparam.pipe_size = ARRAY_SIZE(usbhsc_default_pipe); } diff --git a/drivers/usb/renesas_usbhs/rza.h b/drivers/usb/renesas_usbhs/rza.h index a29b75fef057..8b879aa34a20 100644 --- a/drivers/usb/renesas_usbhs/rza.h +++ b/drivers/usb/renesas_usbhs/rza.h @@ -3,3 +3,4 @@ extern const struct renesas_usbhs_platform_info usbhs_rza1_plat_info; extern const struct renesas_usbhs_platform_info usbhs_rza2_plat_info; +extern const struct renesas_usbhs_platform_info usbhs_rzg2l_plat_info; diff --git a/drivers/usb/renesas_usbhs/rza2.c b/drivers/usb/renesas_usbhs/rza2.c index f079817250bb..b83699eab373 100644 --- a/drivers/usb/renesas_usbhs/rza2.c +++ b/drivers/usb/renesas_usbhs/rza2.c @@ -71,3 +71,16 @@ const struct renesas_usbhs_platform_info usbhs_rza2_plat_info = { .has_new_pipe_configs = 1, }, }; + +const struct renesas_usbhs_platform_info usbhs_rzg2l_plat_info = { + .platform_callback = { + .hardware_init = usbhs_rza2_hardware_init, + .hardware_exit = usbhs_rza2_hardware_exit, + .power_ctrl = usbhs_rza2_power_ctrl, + .get_id = usbhs_get_id_as_gadget, + }, + .driver_param = { + .has_cnen = 1, + .cfifo_byte_addr = 1, + }, +}; -- 2.25.1
Simplify probe() by removing redundant dev->of_node check. While at it, replace dev_err->dev_err_probe for error path. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> --- v3->v4: * No change. v2->v3: * Added Rb tag from Geert. v2: * New patch. --- drivers/usb/renesas_usbhs/common.c | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/drivers/usb/renesas_usbhs/common.c b/drivers/usb/renesas_usbhs/common.c index dd1c17542439..0c62e4c6c88d 100644 --- a/drivers/usb/renesas_usbhs/common.c +++ b/drivers/usb/renesas_usbhs/common.c @@ -595,16 +595,11 @@ static int usbhs_probe(struct platform_device *pdev) u32 tmp; int irq; - /* check device node */ - if (dev_of_node(dev)) - info = of_device_get_match_data(dev); - else - info = renesas_usbhs_get_info(pdev); - - /* check platform information */ + info = of_device_get_match_data(dev); if (!info) { - dev_err(dev, "no platform information\n"); - return -EINVAL; + info = renesas_usbhs_get_info(pdev); + if (!info) + return dev_err_probe(dev, -EINVAL, "no platform info\n"); } /* platform data */ -- 2.25.1
The USBHS IP found on RZ/G2L SoCs only has 10 pipe buffers compared to 16 pipe buffers on RZ/A2M. Document renesas,rzg2l-usbhs family compatible to handle this difference for RZ/G2L family SoCs. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> --- v3->v4: * No change. v2->v3: * Added Rb tag from Geert. v1->v2: * Added Ack from Krzysztof Kozlowski. --- Documentation/devicetree/bindings/usb/renesas,usbhs.yaml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml index 40ada78f2328..c63db3ebd07b 100644 --- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml +++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml @@ -19,10 +19,14 @@ properties: - items: - enum: - renesas,usbhs-r7s9210 # RZ/A2 + - const: renesas,rza2-usbhs + + - items: + - enum: - renesas,usbhs-r9a07g043 # RZ/G2UL and RZ/Five - renesas,usbhs-r9a07g044 # RZ/G2{L,LC} - renesas,usbhs-r9a07g054 # RZ/V2L - - const: renesas,rza2-usbhs + - const: renesas,rzg2l-usbhs - items: - enum: -- 2.25.1
The USBHS IP found on RZ/G2L SoCs only has 10 pipe buffers compared to 16 pipe buffers on RZ/A2M. Document renesas,rzg2l-usbhs family compatible to handle this difference for RZ/G2L family SoCs. This patch series aims to fix the USB pipe configuration for RZ/G2L family SoCs. For the backward compatibility SoC specific compatible is used and will be removed the same after few kernel releases. As the DTS update has a hard dependency on the driver fix, Got ack from Geert for patch#6 to apply the DTS update together with the driver fix. v3->v4: * Added Rbtag from Geert for patch#3. * Dropped patch#4 * Credit Huy Nguyen's work in the commit message for patch#4 and dropped his name from Signed-off-by tag. * Selection of usbhsc_rzg2l_default_pipe[] by setting the variable has_new_pipe_configs to zero. * Updated commit description for patch#4. * Dropped the check 'priv->dparam.pipe_configs' as it is same as checking !has_new_pipe_configs. v2->v3: * Added Rb tag from Geert for patch#1,#2 and #7 * Added Ack tag from Geert for patch#7. * Added patch#3 for improving usbhsc_default_pipe[] for isochronous transfers * Added patch#4 for dropping has_new_pipe_configs from struct renesas_usbhs_driver_param * Updated commit description for patch#5 * Dropped usbhsc_rzg2l_pipe[] and reusing the default_pipe[]. v1->v2: * Added Ack from Krzysztof Kozlowski for patch#1. * Added patch#2 for simplify obtaining device data. * Dropped using of_device_is_compatible() in probe. * Added usbhs_rzg2l_plat_info and replaced the device data for RZ/G2L from usbhs_rza2_plat_info->usbhs_rzg2l_plat_info. * Moved usbhsc_rzg2l_pipe table near to the user. * Updated commit description in patch#3 * Added Rb tag from Geert for patch#4. * Updated commit description about ABI breakage in patch#5. * Updated commit header in patch#5 as it is RZ/G2L specific. Biju Das (6): dt-bindings: usb: renesas,usbhs: Document RZ/G2L family compatible usb: renesas_usbhs: Simplify obtaining device data usb: renesas_usbhs: Improve usbhsc_default_pipe[] for isochronous transfers usb: renesas_usbhs: Update usbhs pipe configuration for RZ/G2L family usb: renesas_usbhs: Remove trailing comma in the terminator entry for OF table arm64: dts: renesas: r9a07g0{43,44,54}: Update RZ/G2L family compatible .../bindings/usb/renesas,usbhs.yaml | 6 ++- arch/arm64/boot/dts/renesas/r9a07g043.dtsi | 2 +- arch/arm64/boot/dts/renesas/r9a07g044.dtsi | 2 +- arch/arm64/boot/dts/renesas/r9a07g054.dtsi | 2 +- drivers/usb/renesas_usbhs/common.c | 43 ++++++++++++------- drivers/usb/renesas_usbhs/rza.h | 1 + drivers/usb/renesas_usbhs/rza2.c | 13 ++++++ 7 files changed, 49 insertions(+), 20 deletions(-) -- 2.25.1
[-- Attachment #1: Type: text/plain, Size: 852 bytes --] On Mon, Mar 18, 2024 at 10:55:54AM -0400, Alan Stern wrote: > On Mon, Mar 18, 2024 at 02:40:31PM +0000, Mark Brown wrote: > > On Mon, Mar 18, 2024 at 04:36:24PM +0200, Mathias Nyman wrote: > > > We are already mid merge window. > > > Not sure if there's some way Greg can still get this in, otherwise I'm > > > afraid we need wait for rc1, and try to get this into rc2. > > Given that it's a bug fix for a fairly serious issue (it's causing boot > > failures) it should be perfectly fine to apply during the merge window? > Greg is away on vacation until this weekend. If the bug is all that > serious, you could consider sending the fix directly to Linus. I can do that, or Mathias do you want to resend it? Boot breaks in -rc1 tend to be pretty miserable for testing since a lot of people use it as a base for their branches. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 484 bytes --]
On Mon, Mar 18, 2024 at 02:40:31PM +0000, Mark Brown wrote:
> On Mon, Mar 18, 2024 at 04:36:24PM +0200, Mathias Nyman wrote:
> > On 18.3.2024 15.30, Aishwarya TCV wrote:
> > > On 08/03/2024 11:34, Mathias Nyman wrote:
>
> > > When booting the kernel against next-master(next-20240318) with Arm64 on
> > > JUNO using ACPI, the kernel is resulting in boot failures for our CI.
>
> > > A bisect identified f3ac348e6e04 ("usb: usb-acpi: Set port connect type
> > > of not connectable ports correctly") as introducing the failure.
> > > Bisected it on the tag "next-20240308" at repo
> > > "https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git".
>
> > > I believe this is the patch to fix the issue. Kindly note that the
> > > failure is seen on next-master runs from the past week. Any chance that
> > > you could get this merged into next-master sooner?
>
> > We are already mid merge window.
> > Not sure if there's some way Greg can still get this in, otherwise I'm
> > afraid we need wait for rc1, and try to get this into rc2.
>
> Given that it's a bug fix for a fairly serious issue (it's causing boot
> failures) it should be perfectly fine to apply during the merge window?
Greg is away on vacation until this weekend. If the bug is all that
serious, you could consider sending the fix directly to Linus.
Alan Stern
[-- Attachment #1: Type: text/plain, Size: 1094 bytes --] On Mon, Mar 18, 2024 at 04:36:24PM +0200, Mathias Nyman wrote: > On 18.3.2024 15.30, Aishwarya TCV wrote: > > On 08/03/2024 11:34, Mathias Nyman wrote: > > When booting the kernel against next-master(next-20240318) with Arm64 on > > JUNO using ACPI, the kernel is resulting in boot failures for our CI. > > A bisect identified f3ac348e6e04 ("usb: usb-acpi: Set port connect type > > of not connectable ports correctly") as introducing the failure. > > Bisected it on the tag "next-20240308" at repo > > "https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git". > > I believe this is the patch to fix the issue. Kindly note that the > > failure is seen on next-master runs from the past week. Any chance that > > you could get this merged into next-master sooner? > We are already mid merge window. > Not sure if there's some way Greg can still get this in, otherwise I'm > afraid we need wait for rc1, and try to get this into rc2. Given that it's a bug fix for a fairly serious issue (it's causing boot failures) it should be perfectly fine to apply during the merge window? [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On 18.3.2024 15.30, Aishwarya TCV wrote:
>
>
> On 08/03/2024 11:34, Mathias Nyman wrote:
>> If reading the ACPI _PLD port location object fails, or the port
>> doesn't have a _PLD ACPI object then the *pld pointer will remain
>> uninitialized and oops when freed.
>>
>> The patch that caused this is currently in next, on its way to v6.9.
>> So no need to add this to stable or current 6.8 kernel.
>>
>> Reported-by: Klara Modin <klarasmodin@gmail.com>
>> Closes: https://lore.kernel.org/linux-usb/7e92369a-3197-4883-9988-3c93452704f5@gmail.com/
>> Tested-by: Klara Modin <klarasmodin@gmail.com>
>> Fixes: f3ac348e6e04 ("usb: usb-acpi: Set port connect type of not connectable ports correctly")
>> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>> ---
>
> Hi Mathias,
>
> When booting the kernel against next-master(next-20240318) with Arm64 on
> JUNO using ACPI, the kernel is resulting in boot failures for our CI.
>
> A bisect identified f3ac348e6e04 ("usb: usb-acpi: Set port connect type
> of not connectable ports correctly") as introducing the failure.
> Bisected it on the tag "next-20240308" at repo
> "https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git".
>
> I believe this is the patch to fix the issue. Kindly note that the
> failure is seen on next-master runs from the past week. Any chance that
> you could get this merged into next-master sooner?
Hi
We are already mid merge window.
Not sure if there's some way Greg can still get this in, otherwise I'm
afraid we need wait for rc1, and try to get this into rc2.
Thanks
Mathias
On 08/03/2024 11:34, Mathias Nyman wrote: > If reading the ACPI _PLD port location object fails, or the port > doesn't have a _PLD ACPI object then the *pld pointer will remain > uninitialized and oops when freed. > > The patch that caused this is currently in next, on its way to v6.9. > So no need to add this to stable or current 6.8 kernel. > > Reported-by: Klara Modin <klarasmodin@gmail.com> > Closes: https://lore.kernel.org/linux-usb/7e92369a-3197-4883-9988-3c93452704f5@gmail.com/ > Tested-by: Klara Modin <klarasmodin@gmail.com> > Fixes: f3ac348e6e04 ("usb: usb-acpi: Set port connect type of not connectable ports correctly") > Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> > --- Hi Mathias, When booting the kernel against next-master(next-20240318) with Arm64 on JUNO using ACPI, the kernel is resulting in boot failures for our CI. A bisect identified f3ac348e6e04 ("usb: usb-acpi: Set port connect type of not connectable ports correctly") as introducing the failure. Bisected it on the tag "next-20240308" at repo "https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git". I believe this is the patch to fix the issue. Kindly note that the failure is seen on next-master runs from the past week. Any chance that you could get this merged into next-master sooner? Sample log from failure against run on JUNO: -------------------------------------------- <0>[ 2.594950] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP <4>[ 2.594960] Modules linked in: <6>[ 2.601938] usbhid: USB HID core driver <4>[ 2.608722] smsc <4>[ 2.608733] CPU: 1 PID: 46 Comm: kworker/u26:0 Not tainted 6.8.0-next-20240318 #1 <4>[ 2.649317] Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Jan 30 2024 <4>[ 2.660381] Workqueue: async async_run_entry_fn <4>[ 2.665192] pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 2.672431] pc : kfree+0x44/0x1a8 <4>[ 2.676019] lr : usb_acpi_find_companion+0x138/0x1c0 <4>[ 2.681257] sp : ffff800082c9b260 <4>[ 2.684835] x29: ffff800082c9b260 x28: ffff000822dddc00 x27: 0000000000000000 <4>[ 2.692259] x26: 0000000000000000 x25: ffff80008156bd30 x24: ffff000822dde008 <4>[ 2.699680] x23: ffff800082aadf90 x22: ffff8000826fec98 x21: ffff000800055690 <4>[ 2.707100] x20: ffff800082c9b2f0 x19: ffffffffc20b26c0 x18: 00000000fffffffe <4>[ 2.714521] x17: 00000000c94f8e36 x16: ffff800082906558 x15: 0000000000000002 <4>[ 2.721941] x14: 0000000000000001 x13: 000000000014f15e x12: ffff000800f50089 <4>[ 2.729362] x11: 000000000000002e x10: 00000000ffffffff x9 : ffff800082c9b1e0 <4>[ 2.736782] x8 : ffff000800f6b050 x7 : ffff000800f5b518 x6 : 0000000000000018 <4>[ 2.744203] x5 : ffff0008002c9100 x4 : ffff0008002c9100 x3 : 0000000000000c02 <4>[ 2.751623] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffc1ffc0000000 <4>[ 2.759043] Call trace: <4>[ 2.761751] kfree+0x44/0x1a8 <4>[ 2.764989] usb_acpi_find_companion+0x138/0x1c0 <4>[ 2.769877] acpi_device_notify+0x98/0x140 <4>[ 2.774245] device_add+0x108/0x77c <4>[ 2.778007] device_register+0x20/0x30 <4>[ 2.782028] usb_hub_create_port_device+0x128/0x3c4 <4>[ 2.787176] hub_probe+0x6b0/0x978 <4>[ 2.790849] usb_probe_interface+0xd4/0x2b4 <4>[ 2.795302] really_probe+0xbc/0x2a0 <4>[ 2.799146] __driver_probe_device+0x78/0x12c <4>[ 2.803772] driver_probe_device+0xdc/0x160 <4>[ 2.808224] __device_attach_driver+0xb8/0x134 <4>[ 2.812938] bus_for_each_drv+0x84/0xe0 <4>[ 2.817042] __device_attach+0xa8/0x1b0 <4>[ 2.821146] device_initial_probe+0x14/0x20 <4>[ 2.825599] bus_probe_device+0xa8/0xac <4>[ 2.829703] device_add+0x5c4/0x77c <4>[ 2.833462] usb_set_configuration+0x524/0x958 <4>[ 2.838175] usb_generic_driver_probe+0x60/0x88 <4>[ 2.842974] usb_probe_device+0x3c/0x11c <4>[ 2.847165] really_probe+0xbc/0x2a0 <4>[ 2.851007] __driver_probe_device+0x78/0x12c <4>[ 2.855634] driver_probe_device+0xdc/0x160 <4>[ 2.860086] __device_attach_driver+0xb8/0x134 <4>[ 2.864799] bus_for_each_drv+0x84/0xe0 <4>[ 2.868902] __device_attach+0xa8/0x1b0 <4>[ 2.873006] device_initial_probe+0x14/0x20 <4>[ 2.877458] bus_probe_device+0xa8/0xac <4>[ 2.881561] device_add+0x5c4/0x77c <4>[ 2.885321] usb_new_device+0x1d0/0x5a0 <4>[ 2.889427] register_root_hub+0xd8/0x1d0 <4>[ 2.893708] usb_add_hcd+0x3f8/0x618 <4>[ 2.897554] ehci_platform_probe+0x228/0x4dc <4>[ 2.902096] platform_probe+0x68/0xd8 <4>[ 2.906029] really_probe+0xbc/0x2a0 <4>[ 2.909872] __driver_probe_device+0x78/0x12c <4>[ 2.914499] driver_probe_device+0xdc/0x160 <4>[ 2.918957] __driver_attach_async_helper+0x4c/0xb4 <4>[ 2.924108] async_run_entry_fn+0x34/0xe0 <4>[ 2.928388] process_one_work+0x150/0x294 <4>[ 2.932672] worker_thread+0x304/0x408 <4>[ 2.936693] kthread+0x118/0x11c <4>[ 2.940190] ret_from_fork+0x10/0x20 <0>[ 2.944039] Code: b26287e0 d34cfe73 f2d83fe0 8b131813 (f9400660) <4>[ 2.950403] ---[ end trace 0000000000000000 ]--- <3>[ 23.568762] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: <3>[ 23.575137] rcu: (detected by 1, t=5252 jiffies, g=-579, q=11 ncpus=6) <3>[ 23.582026] rcu: All QSes seen, last rcu_preempt kthread activity 5151 (4294898132-4294892981), jiffies_till_next_fqs=1, root ->qsmask 0x0 <3>[ 23.594746] rcu: rcu_preempt kthread timer wakeup didn't happen for 5156 jiffies! g-579 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 <3>[ 23.606335] rcu: Possible timer handling issue on cpu=0 timer-softirq=73 <3>[ 23.613394] rcu: rcu_preempt kthread starved for 5162 jiffies! g-579 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=0 <3>[ 23.624025] rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. <3>[ 23.633432] rcu: RCU grace-period kthread stack dump: <6>[ 23.638750] task:rcu_preempt state:R stack:0 pid:15 tgid:15 ppid:2 flags:0x00000008 <6>[ 23.648345] Call trace: <6>[ 23.651053] __switch_to+0xe0/0x124 <6>[ 23.654814] __schedule+0x2bc/0x848 <6>[ 23.658570] schedule+0x34/0x104 <6>[ 23.662063] schedule_timeout+0x80/0xf4 <6>[ 23.666170] rcu_gp_fqs_loop+0x124/0x460 <6>[ 23.670365] rcu_gp_kthread+0x130/0x168 <6>[ 23.674472] kthread+0x118/0x11c <6>[ 23.677970] ret_from_fork+0x10/0x20 <3>[ 23.681817] rcu: Stack dump where RCU GP kthread last ran: <6>[ 23.687571] Sending NMI from CPU 1 to CPUs 0: Thanks, Aishwarya
On Fri, Mar 15, 2024 at 05:04:22PM +0100, Luca Weiss wrote: > Switch to using the new DRM_AUX_BRIDGE helper to create the transparent > DRM bridge device instead of handcoding corresponding functionality. > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> > --- > Very similar to this patch: > c5d296bad640 ("usb: typec: nb7vpq904m: switch to DRM_AUX_BRIDGE") > --- > drivers/usb/typec/mux/Kconfig | 2 +- > drivers/usb/typec/mux/ptn36502.c | 44 ++-------------------------------------- > 2 files changed, 3 insertions(+), 43 deletions(-) > > diff --git a/drivers/usb/typec/mux/Kconfig b/drivers/usb/typec/mux/Kconfig > index 399c7b0983df..4827e86fed6d 100644 > --- a/drivers/usb/typec/mux/Kconfig > +++ b/drivers/usb/typec/mux/Kconfig > @@ -60,7 +60,7 @@ config TYPEC_MUX_PTN36502 > tristate "NXP PTN36502 Type-C redriver driver" > depends on I2C > depends on DRM || DRM=n > - select DRM_PANEL_BRIDGE if DRM > + select DRM_AUX_BRIDGE if DRM_BRIDGE > select REGMAP_I2C > help > Say Y or M if your system has a NXP PTN36502 Type-C redriver chip > diff --git a/drivers/usb/typec/mux/ptn36502.c b/drivers/usb/typec/mux/ptn36502.c > index 72ae38a1b2be..0ec86ef32a87 100644 > --- a/drivers/usb/typec/mux/ptn36502.c > +++ b/drivers/usb/typec/mux/ptn36502.c > @@ -8,7 +8,7 @@ > * Copyright (C) 2023 Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > */ > > -#include <drm/drm_bridge.h> > +#include <drm/bridge/aux-bridge.h> > #include <linux/bitfield.h> > #include <linux/i2c.h> > #include <linux/kernel.h> > @@ -68,8 +68,6 @@ struct ptn36502 { > > struct typec_switch *typec_switch; > > - struct drm_bridge bridge; > - > struct mutex lock; /* protect non-concurrent retimer & switch */ > > enum typec_orientation orientation; > @@ -283,44 +281,6 @@ static int ptn36502_detect(struct ptn36502 *ptn) > return 0; > } > > -#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_DRM_PANEL_BRIDGE) > -static int ptn36502_bridge_attach(struct drm_bridge *bridge, > - enum drm_bridge_attach_flags flags) > -{ > - struct ptn36502 *ptn = container_of(bridge, struct ptn36502, bridge); > - struct drm_bridge *next_bridge; > - > - if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) > - return -EINVAL; > - > - next_bridge = devm_drm_of_get_bridge(&ptn->client->dev, ptn->client->dev.of_node, 0, 0); > - if (IS_ERR(next_bridge)) { > - dev_err(&ptn->client->dev, "failed to acquire drm_bridge: %pe\n", next_bridge); > - return PTR_ERR(next_bridge); > - } > - > - return drm_bridge_attach(bridge->encoder, next_bridge, bridge, > - DRM_BRIDGE_ATTACH_NO_CONNECTOR); > -} > - > -static const struct drm_bridge_funcs ptn36502_bridge_funcs = { > - .attach = ptn36502_bridge_attach, > -}; > - > -static int ptn36502_register_bridge(struct ptn36502 *ptn) > -{ > - ptn->bridge.funcs = &ptn36502_bridge_funcs; > - ptn->bridge.of_node = ptn->client->dev.of_node; > - > - return devm_drm_bridge_add(&ptn->client->dev, &ptn->bridge); > -} > -#else > -static int ptn36502_register_bridge(struct ptn36502 *ptn) > -{ > - return 0; > -} > -#endif > - > static const struct regmap_config ptn36502_regmap = { > .max_register = 0x0d, > .reg_bits = 8, > @@ -369,7 +329,7 @@ static int ptn36502_probe(struct i2c_client *client) > if (ret) > goto err_disable_regulator; > > - ret = ptn36502_register_bridge(ptn); > + ret = drm_aux_bridge_register(dev); > if (ret) > goto err_disable_regulator; > > > --- > base-commit: 9bb9b28d0568991b1d63e66fe75afa5f97ad1156 > change-id: 20240315-ptn36502-aux-15dd6f289aff > > Best regards, > -- > Luca Weiss <luca.weiss@fairphone.com> -- heikki
On Fri, Mar 15, 2024 at 05:18:35PM +0000, Jameson Thies wrote: > Check the UCSI_CAP_GET_PD_MESSAGE bit before sending GET_PD_MESSAGE to > discover partner and cable identity, check UCSI_CAP_CABLE_DETAILS before > sending GET_CABLE_PROPERTY to discover the cable and check > UCSI_CAP_ALT_MODE_DETAILS before registering the a cable plug. Additionally, > move 8 bits from reserved_1 to features in the ucsi_capability struct. This > makes the field 16 bits, still 8 short of the 24 bits allocated for it in > UCSI v3.0, but it will not overflow because UCSI only defines 14 bits in > bmOptionalFeatures. > > Fixes: 38ca416597b0 ("usb: typec: ucsi: Register cables based on GET_CABLE_PROPERTY") > Link: https://lore.kernel.org/linux-usb/44e8142f-d9b3-487b-83fe-39deadddb492@linaro.org > Suggested-by: Neil Armstrong <neil.armstrong@linaro.org> > Signed-off-by: Jameson Thies <jthies@google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> > --- > Confirmed a device which supports GET_PD_MESSAGE, GET_CABLE_PROPERTY and > GET_ALTERNATE_MODES still requested identity and cable information. > > drivers/usb/typec/ucsi/ucsi.c | 34 +++++++++++++++++++++------------- > drivers/usb/typec/ucsi/ucsi.h | 5 +++-- > 2 files changed, 24 insertions(+), 15 deletions(-) > > diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c > index cf52cb34d2859..958dc82989b60 100644 > --- a/drivers/usb/typec/ucsi/ucsi.c > +++ b/drivers/usb/typec/ucsi/ucsi.c > @@ -1133,17 +1133,21 @@ static int ucsi_check_cable(struct ucsi_connector *con) > if (ret < 0) > return ret; > > - ret = ucsi_get_cable_identity(con); > - if (ret < 0) > - return ret; > + if (con->ucsi->cap.features & UCSI_CAP_GET_PD_MESSAGE) { > + ret = ucsi_get_cable_identity(con); > + if (ret < 0) > + return ret; > + } > > - ret = ucsi_register_plug(con); > - if (ret < 0) > - return ret; > + if (con->ucsi->cap.features & UCSI_CAP_ALT_MODE_DETAILS) { > + ret = ucsi_register_plug(con); > + if (ret < 0) > + return ret; > > - ret = ucsi_register_altmodes(con, UCSI_RECIPIENT_SOP_P); > - if (ret < 0) > - return ret; > + ret = ucsi_register_altmodes(con, UCSI_RECIPIENT_SOP_P); > + if (ret < 0) > + return ret; > + } > > return 0; > } > @@ -1189,8 +1193,10 @@ static void ucsi_handle_connector_change(struct work_struct *work) > ucsi_register_partner(con); > ucsi_partner_task(con, ucsi_check_connection, 1, HZ); > ucsi_partner_task(con, ucsi_check_connector_capability, 1, HZ); > - ucsi_partner_task(con, ucsi_get_partner_identity, 1, HZ); > - ucsi_partner_task(con, ucsi_check_cable, 1, HZ); > + if (con->ucsi->cap.features & UCSI_CAP_GET_PD_MESSAGE) > + ucsi_partner_task(con, ucsi_get_partner_identity, 1, HZ); > + if (con->ucsi->cap.features & UCSI_CAP_CABLE_DETAILS) > + ucsi_partner_task(con, ucsi_check_cable, 1, HZ); > > if (UCSI_CONSTAT_PWR_OPMODE(con->status.flags) == > UCSI_CONSTAT_PWR_OPMODE_PD) > @@ -1589,8 +1595,10 @@ static int ucsi_register_port(struct ucsi *ucsi, struct ucsi_connector *con) > ucsi_register_partner(con); > ucsi_pwr_opmode_change(con); > ucsi_port_psy_changed(con); > - ucsi_get_partner_identity(con); > - ucsi_check_cable(con); > + if (con->ucsi->cap.features & UCSI_CAP_GET_PD_MESSAGE) > + ucsi_get_partner_identity(con); > + if (con->ucsi->cap.features & UCSI_CAP_CABLE_DETAILS) > + ucsi_check_cable(con); > } > > /* Only notify USB controller if partner supports USB data */ > diff --git a/drivers/usb/typec/ucsi/ucsi.h b/drivers/usb/typec/ucsi/ucsi.h > index 32daf5f586505..0e7c92eb1b227 100644 > --- a/drivers/usb/typec/ucsi/ucsi.h > +++ b/drivers/usb/typec/ucsi/ucsi.h > @@ -206,7 +206,7 @@ struct ucsi_capability { > #define UCSI_CAP_ATTR_POWER_OTHER BIT(10) > #define UCSI_CAP_ATTR_POWER_VBUS BIT(14) > u8 num_connectors; > - u8 features; > + u16 features; > #define UCSI_CAP_SET_UOM BIT(0) > #define UCSI_CAP_SET_PDM BIT(1) > #define UCSI_CAP_ALT_MODE_DETAILS BIT(2) > @@ -215,7 +215,8 @@ struct ucsi_capability { > #define UCSI_CAP_CABLE_DETAILS BIT(5) > #define UCSI_CAP_EXT_SUPPLY_NOTIFICATIONS BIT(6) > #define UCSI_CAP_PD_RESET BIT(7) > - u16 reserved_1; > +#define UCSI_CAP_GET_PD_MESSAGE BIT(8) > + u8 reserved_1; > u8 num_alt_modes; > u8 reserved_2; > u16 bc_version; > -- > 2.44.0.291.gc1ea87d7ee-goog -- heikki
On Wed, Mar 13, 2024 at 05:54:17AM +0200, Dmitry Baryshkov wrote: > Now as all UCSI issues have been fixed, reenable UCSI subdevice on the > Qualcomm SC8280XP platform. > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> > --- > drivers/soc/qcom/pmic_glink.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/soc/qcom/pmic_glink.c b/drivers/soc/qcom/pmic_glink.c > index f913e9bd57ed..e5a591733a0f 100644 > --- a/drivers/soc/qcom/pmic_glink.c > +++ b/drivers/soc/qcom/pmic_glink.c > @@ -343,7 +343,6 @@ static const unsigned long pmic_glink_sm8450_client_mask = BIT(PMIC_GLINK_CLIENT > > static const struct of_device_id pmic_glink_of_match[] = { > { .compatible = "qcom,sc8180x-pmic-glink", .data = &pmic_glink_sc8180x_client_mask }, > - { .compatible = "qcom,sc8280xp-pmic-glink", .data = &pmic_glink_sc8180x_client_mask }, > { .compatible = "qcom,pmic-glink", .data = &pmic_glink_sm8450_client_mask }, > {} > }; > > -- > 2.39.2 -- heikki
On Wed, Mar 13, 2024 at 05:54:16AM +0200, Dmitry Baryshkov wrote: > Use typec_partner_usb_power_delivery_register() to register PD device > for Type-C partner so that the PD device is nested under the partner's > device in sysfs. > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> > --- > drivers/usb/typec/ucsi/ucsi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c > index 72d368433b1f..78e04b7701c8 100644 > --- a/drivers/usb/typec/ucsi/ucsi.c > +++ b/drivers/usb/typec/ucsi/ucsi.c > @@ -833,7 +833,7 @@ static int ucsi_register_partner_pdos(struct ucsi_connector *con) > if (con->partner_pd) > return 0; > > - con->partner_pd = usb_power_delivery_register(NULL, &desc); > + con->partner_pd = typec_partner_usb_power_delivery_register(con->partner, &desc); > if (IS_ERR(con->partner_pd)) > return PTR_ERR(con->partner_pd); > > > -- > 2.39.2 -- heikki