From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
To: Peter Chen <peter.chen@nxp.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: [resend] usb: chipidea: Don't select EXTCON
Date: Mon, 23 Apr 2018 15:33:10 +0800 [thread overview]
Message-ID: <20180423153310.47a20e6d@xhacker.debian> (raw)
On Fri, 20 Apr 2018 09:35:54 +0000 Peter Chen wrote:
>
> > >
> > > Sorry to reply late, are you really care 2KB code side? Since many
> > > users use EXTCON to handle vbus and id, it is hard just delete it. I
> > > could accept patch for your specific platforms, like:
> > >
> > > + select EXTCON if !ARCH_XXXX
> >
> > The patch doesn't remove extcon support from chipidea driver.
> > I just want to not select EXTCON unconditionally, but let the users choose. If the
> > users need extcon, they could enable EXTCON themselves
> >
> > I just searched all the dts in arch/arm/boot/dts and arch/arm64/boot/dts only the four
> > dts give extcon phandle to chipidea host, other users don't make use of it:
> >
> > arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> >
> > arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
> >
> > arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
> >
> > arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts
> >
>
> I see, but I do not want to break msm platforms. You may try to create Glue driver Kconfig
> entry for chipidea like dwc3, and let msm depends on EXTCON.
Got your points. Since multi_v7_defconfig has selected EXTCON, and
EXTCON_USB_GPIO(which depends on EXTCON) is enabled in arm64 defconfig, so
what about:
enable EXTCON explicitly in arm64 defconfig?
then add this patch?
Is it acceptable?
Thanks,
Jisheng
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Jisheng.Zhang@synaptics.com (Jisheng Zhang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH resend] usb: chipidea: Don't select EXTCON
Date: Mon, 23 Apr 2018 15:33:10 +0800 [thread overview]
Message-ID: <20180423153310.47a20e6d@xhacker.debian> (raw)
In-Reply-To: <VI1PR04MB14558BCFB82A06C92F7AA0CA8BB40@VI1PR04MB1455.eurprd04.prod.outlook.com>
On Fri, 20 Apr 2018 09:35:54 +0000 Peter Chen wrote:
>
> > >
> > > Sorry to reply late, are you really care 2KB code side? Since many
> > > users use EXTCON to handle vbus and id, it is hard just delete it. I
> > > could accept patch for your specific platforms, like:
> > >
> > > + select EXTCON if !ARCH_XXXX
> >
> > The patch doesn't remove extcon support from chipidea driver.
> > I just want to not select EXTCON unconditionally, but let the users choose. If the
> > users need extcon, they could enable EXTCON themselves
> >
> > I just searched all the dts in arch/arm/boot/dts and arch/arm64/boot/dts only the four
> > dts give extcon phandle to chipidea host, other users don't make use of it:
> >
> > arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> >
> > arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
> >
> > arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
> >
> > arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts
> >
>
> I see, but I do not want to break msm platforms. You may try to create Glue driver Kconfig
> entry for chipidea like dwc3, and let msm depends on EXTCON.
Got your points. Since multi_v7_defconfig has selected EXTCON, and
EXTCON_USB_GPIO(which depends on EXTCON) is enabled in arm64 defconfig, so
what about:
enable EXTCON explicitly in arm64 defconfig?
then add this patch?
Is it acceptable?
Thanks,
Jisheng
WARNING: multiple messages have this Message-ID (diff)
From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
To: Peter Chen <peter.chen@nxp.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH resend] usb: chipidea: Don't select EXTCON
Date: Mon, 23 Apr 2018 15:33:10 +0800 [thread overview]
Message-ID: <20180423153310.47a20e6d@xhacker.debian> (raw)
In-Reply-To: <VI1PR04MB14558BCFB82A06C92F7AA0CA8BB40@VI1PR04MB1455.eurprd04.prod.outlook.com>
On Fri, 20 Apr 2018 09:35:54 +0000 Peter Chen wrote:
>
> > >
> > > Sorry to reply late, are you really care 2KB code side? Since many
> > > users use EXTCON to handle vbus and id, it is hard just delete it. I
> > > could accept patch for your specific platforms, like:
> > >
> > > + select EXTCON if !ARCH_XXXX
> >
> > The patch doesn't remove extcon support from chipidea driver.
> > I just want to not select EXTCON unconditionally, but let the users choose. If the
> > users need extcon, they could enable EXTCON themselves
> >
> > I just searched all the dts in arch/arm/boot/dts and arch/arm64/boot/dts only the four
> > dts give extcon phandle to chipidea host, other users don't make use of it:
> >
> > arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> >
> > arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
> >
> > arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
> >
> > arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts
> >
>
> I see, but I do not want to break msm platforms. You may try to create Glue driver Kconfig
> entry for chipidea like dwc3, and let msm depends on EXTCON.
Got your points. Since multi_v7_defconfig has selected EXTCON, and
EXTCON_USB_GPIO(which depends on EXTCON) is enabled in arm64 defconfig, so
what about:
enable EXTCON explicitly in arm64 defconfig?
then add this patch?
Is it acceptable?
Thanks,
Jisheng
next reply other threads:[~2018-04-23 7:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-23 7:33 Jisheng Zhang [this message]
2018-04-23 7:33 ` [PATCH resend] usb: chipidea: Don't select EXTCON Jisheng Zhang
2018-04-23 7:33 ` Jisheng Zhang
-- strict thread matches above, loose matches on Subject: below --
2018-04-25 1:47 [resend] " Peter Chen
2018-04-25 1:47 ` [PATCH resend] " Peter Chen
2018-04-25 1:47 ` Peter Chen
2018-04-20 9:35 [resend] " Peter Chen
2018-04-20 9:35 ` [PATCH resend] " Peter Chen
2018-04-20 9:35 ` Peter Chen
2018-04-20 9:01 [resend] " Jisheng Zhang
2018-04-20 9:01 ` [PATCH resend] " Jisheng Zhang
2018-04-20 9:01 ` Jisheng Zhang
2018-04-20 1:38 [resend] " Peter Chen
2018-04-20 1:38 ` [PATCH resend] " Peter Chen
2018-04-20 1:38 ` Peter Chen
2018-04-19 8:01 [resend] " Jisheng Zhang
2018-04-19 8:01 ` [PATCH resend] " Jisheng Zhang
2018-04-19 8:01 ` Jisheng Zhang
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=20180423153310.47a20e6d@xhacker.debian \
--to=jisheng.zhang@synaptics.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=peter.chen@nxp.com \
/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.