All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pengyu Luo <mitltlatltl@gmail.com>
To: dmitry.baryshkov@oss.qualcomm.com
Cc: abel.vesa@linaro.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org, kishon@kernel.org,
	krzk+dt@kernel.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org,
	mitltlatltl@gmail.com, robh@kernel.org, sfr@canb.auug.org.au,
	vkoul@kernel.org
Subject: Re: [PATCH v2 2/2] phy: qualcomm: phy-qcom-eusb2-repeater: rework reg override handler
Date: Tue, 29 Apr 2025 17:23:29 +0800	[thread overview]
Message-ID: <20250429092331.53054-1-mitltlatltl@gmail.com> (raw)
In-Reply-To: <n5z5atbxkwqllni6cgygcw5nn7z4w3yjznhpkaajw6tggenxb3@kxpk2e6vmvlj>

On Tue, Apr 29, 2025 at 12:58 AM Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> On Sat, Apr 26, 2025 at 04:14:23PM +0800, Pengyu Luo wrote:
> > On Sat, Apr 26, 2025 at 3:41 AM Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> > > On Wed, Apr 16, 2025 at 08:02:01PM +0800, Pengyu Luo wrote:
> > > > In downstream tree, many registers need to be overridden, it varies
> > > > from devices and platforms, with these registers getting more, adding
> > > > a handler for this is helpful.
> > >
> > > It should be noted that previously all values were applied during _init
> > > phase, before checking the status etc. Now the overrides are programmed
> > > from the set_mode. Should you still program sane defaults at the init
> > > stage too?
> > >
> >
> > I think programming in set_mode is ok. When we init(dwc3_core_init), we
> > set_mode(dwc3_core_init_mode) later, please check
> > https://elixir.bootlin.com/linux/v6.14.3/source/drivers/usb/dwc3/core.c#L2287
>
> Yes, but that happens after reading status regs, etc.
>
> > Actually, in the downstream, all the things are done in init, it
> > overrides first, then masked write the deaults, finally it set_mode,
> > you can check here
> > https://github.com/OnePlusOSS/android_kernel_oneplus_sm8650/blob/oneplus/sm8650_v_15.0.0_pad_pro/drivers/usb/repeater/repeater-qti-pmic-eusb2.c#L356
>
> I'd stick to this approach too. Program everything in init, then
> program mode-dependent regs in set_mode.
>

If so, I don't mind programming the defaults in init, then programming
overrides in set_mode.

> >
> > > BTW, is there a real need to override those for the platform you are
> > > working on? Could you please provide some details, maybe in the cover
> > > letter.
> >
> > I am not quite sure, recently, I expirenced mode switching failure,
> > when I `echo device > /sys/kernel/debug/usb/a600000.usb/mode`, Ethernet
> > Gadget wouldn't work again, my desktop can't connect to it.
>
> Do you have at least a list of the properties / registers that
> downstream programs on your platform? I mean, it's not infrequent that
> vendor kernel is more versatile than necessary, as it is being used
> during bringup / etc. I'd suggest to limit supported overrides to those
> necessary for your platform (and add a comment that there were other
> available).
>

Yes, I only added the necessary overrides(0x54, and mode handling).
Please check

https://github.com/OnePlusOSS/android_kernel_modules_and_devicetree_oneplus_sm8650/blob/oneplus/sm8650_v_15.0.0_pad_pro/kernel_platform/qcom/proprietary/devicetree/oplus/oplus_misc/oplus-misc-23926.dtsi#L26

Best wishes,
Pengyu

WARNING: multiple messages have this Message-ID (diff)
From: Pengyu Luo <mitltlatltl@gmail.com>
To: dmitry.baryshkov@oss.qualcomm.com
Cc: abel.vesa@linaro.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org, kishon@kernel.org,
	krzk+dt@kernel.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org,
	mitltlatltl@gmail.com, robh@kernel.org, sfr@canb.auug.org.au,
	vkoul@kernel.org
Subject: Re: [PATCH v2 2/2] phy: qualcomm: phy-qcom-eusb2-repeater: rework reg override handler
Date: Tue, 29 Apr 2025 17:23:29 +0800	[thread overview]
Message-ID: <20250429092331.53054-1-mitltlatltl@gmail.com> (raw)
In-Reply-To: <n5z5atbxkwqllni6cgygcw5nn7z4w3yjznhpkaajw6tggenxb3@kxpk2e6vmvlj>

On Tue, Apr 29, 2025 at 12:58 AM Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> On Sat, Apr 26, 2025 at 04:14:23PM +0800, Pengyu Luo wrote:
> > On Sat, Apr 26, 2025 at 3:41 AM Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> > > On Wed, Apr 16, 2025 at 08:02:01PM +0800, Pengyu Luo wrote:
> > > > In downstream tree, many registers need to be overridden, it varies
> > > > from devices and platforms, with these registers getting more, adding
> > > > a handler for this is helpful.
> > >
> > > It should be noted that previously all values were applied during _init
> > > phase, before checking the status etc. Now the overrides are programmed
> > > from the set_mode. Should you still program sane defaults at the init
> > > stage too?
> > >
> >
> > I think programming in set_mode is ok. When we init(dwc3_core_init), we
> > set_mode(dwc3_core_init_mode) later, please check
> > https://elixir.bootlin.com/linux/v6.14.3/source/drivers/usb/dwc3/core.c#L2287
>
> Yes, but that happens after reading status regs, etc.
>
> > Actually, in the downstream, all the things are done in init, it
> > overrides first, then masked write the deaults, finally it set_mode,
> > you can check here
> > https://github.com/OnePlusOSS/android_kernel_oneplus_sm8650/blob/oneplus/sm8650_v_15.0.0_pad_pro/drivers/usb/repeater/repeater-qti-pmic-eusb2.c#L356
>
> I'd stick to this approach too. Program everything in init, then
> program mode-dependent regs in set_mode.
>

If so, I don't mind programming the defaults in init, then programming
overrides in set_mode.

> >
> > > BTW, is there a real need to override those for the platform you are
> > > working on? Could you please provide some details, maybe in the cover
> > > letter.
> >
> > I am not quite sure, recently, I expirenced mode switching failure,
> > when I `echo device > /sys/kernel/debug/usb/a600000.usb/mode`, Ethernet
> > Gadget wouldn't work again, my desktop can't connect to it.
>
> Do you have at least a list of the properties / registers that
> downstream programs on your platform? I mean, it's not infrequent that
> vendor kernel is more versatile than necessary, as it is being used
> during bringup / etc. I'd suggest to limit supported overrides to those
> necessary for your platform (and add a comment that there were other
> available).
>

Yes, I only added the necessary overrides(0x54, and mode handling).
Please check

https://github.com/OnePlusOSS/android_kernel_modules_and_devicetree_oneplus_sm8650/blob/oneplus/sm8650_v_15.0.0_pad_pro/kernel_platform/qcom/proprietary/devicetree/oplus/oplus_misc/oplus-misc-23926.dtsi#L26

Best wishes,
Pengyu

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

  reply	other threads:[~2025-04-29  9:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-16 12:01 [PATCH v2 0/2] phy: qualcomm: phy-qcom-eusb2-repeater: rework reg override handler Pengyu Luo
2025-04-16 12:01 ` Pengyu Luo
2025-04-16 12:02 ` [PATCH v2 1/2] dt-bindings: phy: qcom,snps-eusb2-repeater: Add more tuning overrides Pengyu Luo
2025-04-16 12:02   ` Pengyu Luo
2025-04-21 21:32   ` Rob Herring
2025-04-21 21:32     ` Rob Herring
2025-04-16 12:02 ` [PATCH v2 2/2] phy: qualcomm: phy-qcom-eusb2-repeater: rework reg override handler Pengyu Luo
2025-04-16 12:02   ` Pengyu Luo
2025-04-25 19:41   ` Dmitry Baryshkov
2025-04-25 19:41     ` Dmitry Baryshkov
2025-04-26  8:14     ` Pengyu Luo
2025-04-26  8:14       ` Pengyu Luo
2025-04-28 16:58       ` Dmitry Baryshkov
2025-04-28 16:58         ` Dmitry Baryshkov
2025-04-29  9:23         ` Pengyu Luo [this message]
2025-04-29  9:23           ` Pengyu Luo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250429092331.53054-1-mitltlatltl@gmail.com \
    --to=mitltlatltl@gmail.com \
    --cc=abel.vesa@linaro.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=kishon@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=robh@kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.