All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.