From: Andy Shevchenko <andy.shevchenko@gmail.com> To: Chanwoo Choi <cw00.choi@samsung.com> Cc: MyungJoo Ham <myungjoo.ham@samsung.com>, USB <linux-usb@vger.kernel.org>, Felipe Balbi <balbi@kernel.org>, Guenter Roeck <linux@roeck-us.net>, "Krogerus, Heikki" <heikki.krogerus@linux.intel.com>, rogerq@ti.com, Linux PM <linux-pm@vger.kernel.org>, "Rafael J. Wysocki" <rafael@kernel.org>, Sebastian Reichel <sre@kernel.org>, Linux OMAP Mailing List <linux-omap@vger.kernel.org>, Darren Hart <dvhart@infradead.org>, Platform Driver <platform-driver-x86@vger.kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Chen-Yu Tsai <wens@csie.org>, Hans de Goede <hdegoede@redhat.com> Subject: Re: [PATCH v1 2/5] extcon: Return -EPROBE_DEFER when extcon device is not found Date: Wed, 14 Nov 2018 13:17:23 +0200 [thread overview] Message-ID: <CAHp75Vc3NC95Wt9T2qx9SCGtwoR2hA7azGAHhqz7LO-yKz=mew@mail.gmail.com> (raw) In-Reply-To: <5BEC018E.8020102@samsung.com> On Wed, Nov 14, 2018 at 1:05 PM Chanwoo Choi <cw00.choi@samsung.com> wrote: > On 2018년 11월 14일 19:20, Andy Shevchenko wrote: > > On Wed, Nov 14, 2018 at 11:48 AM Chanwoo Choi <cw00.choi@samsung.com> wrote: > >> On 2018년 11월 14일 18:36, Andy Shevchenko wrote: > >>> On Wed, Nov 14, 2018 at 06:13:37PM +0900, Chanwoo Choi wrote: > >>>> On 2018년 11월 14일 17:35, Andy Shevchenko wrote: > >>>>> On Wed, Nov 14, 2018 at 1:53 AM Chanwoo Choi <cw00.choi@samsung.com> wrote: > >>>>> > >>>>>> I was thinking about again to change from NULL to EPROBE_DEFER. > >>>>>> > >>>>>> extcon_get_extcon_dev() function was almost called in the probe function. > >>>>>> But, this function might be called on other position instead of probe. > >>>>> > >>>>> *Might be* sounds like a theoretical thing, care to share what is in you mind? > >>>>> Current users and more important the new coming one are *all* doing the same. > >>>>> > >>>>>> ENODEV is more correct error instead of EPROBE_DEFER. > >>>>> > >>>>> So, you are proposing to continue duplicating conversion from ENODEV > >>>>> to EPROBE_DEFER in *each* caller? > >>>> > >>>> The extcon core don't know the caller situation is in either probe() or other position > >>>> in the caller driver. The caller driver should decide the kind of error value > >>>> by using the return value of extcon_get_extcon_dev(). > >>>> > >>>> extcon_get_extcon_dev() function cannot be modified for only one case. > >>>> If some device driver call extcon_get_extcon_dev() out of probe() fuction, > >>>> EPROBE_DEFER is not always correct. > >>> > >>> I agree with this, but look at the current state of affairs. All users do the same. > >>> If we need to have another case we may consider this later. > >> > >> Because we know the potential wrong case of this change, I can't agree this change. > >> If extcon_get_extcon_dev() returns ENODEV instead of EPROBE_DEFER, > >> it is clear and then there are no problem on both current and future. > > > > Changing NULL to -ENODEV is a trading bad to worse. > > I would not go that way, so, it's your call. > > If you think that this change is not necessary, just keep the current code > without the modification. Not only this, the useless churn for no benefit to anyone, except some *theoretical* cases no one saw. > Please drop this patch on next version. I will. > >>> API inside the kernel are not carved in the stone. > > > > Only can repeat myself (see above). While I see *theoretical* > > rationale on your side, mine has *practical* proofs. > > So, I'm giving up on this and will duplicate same what it's done in 4 > > current callers. > > > > I think that it is more important for removing the potential wrong case > instead of removing the duplicate code. The many device drivers already > decided the proper error value by using the return value of function of > kernel framework. The API has been introduced back in 2012. commit 74c5d09bd562edc220d6e076b8f1e118819c178f Author: Donggeun Kim <dg77.kim@samsung.com> Date: Fri Apr 20 14:16:24 2012 +0900 So, you are insisting that 6.5 years of use in a way people are using it is wrong? I don't know what might change your mind, but for me it's a clear win-win to switch to deferred probe error code based on the *practical* evidence. But as I said, I gave up now. P.S. I still disagree with your arguments in relation to de facto use of an API. -- With Best Regards, Andy Shevchenko
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andy.shevchenko@gmail.com> To: Chanwoo Choi <cw00.choi@samsung.com> Cc: MyungJoo Ham <myungjoo.ham@samsung.com>, USB <linux-usb@vger.kernel.org>, Felipe Balbi <balbi@kernel.org>, Guenter Roeck <linux@roeck-us.net>, "Krogerus, Heikki" <heikki.krogerus@linux.intel.com>, rogerq@ti.com, Linux PM <linux-pm@vger.kernel.org>, "Rafael J. Wysocki" <rafael@kernel.org>, Sebastian Reichel <sre@kernel.org>, Linux OMAP Mailing List <linux-omap@vger.kernel.org>, Darren Hart <dvhart@infradead.org>, Platform Driver <platform-driver-x86@vger.kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Chen-Yu Tsai <wens@csie.org>, Hans de Goede <hdegoede@redhat.com> Subject: [v1,2/5] extcon: Return -EPROBE_DEFER when extcon device is not found Date: Wed, 14 Nov 2018 13:17:23 +0200 [thread overview] Message-ID: <CAHp75Vc3NC95Wt9T2qx9SCGtwoR2hA7azGAHhqz7LO-yKz=mew@mail.gmail.com> (raw) On Wed, Nov 14, 2018 at 1:05 PM Chanwoo Choi <cw00.choi@samsung.com> wrote: > On 2018년 11월 14일 19:20, Andy Shevchenko wrote: > > On Wed, Nov 14, 2018 at 11:48 AM Chanwoo Choi <cw00.choi@samsung.com> wrote: > >> On 2018년 11월 14일 18:36, Andy Shevchenko wrote: > >>> On Wed, Nov 14, 2018 at 06:13:37PM +0900, Chanwoo Choi wrote: > >>>> On 2018년 11월 14일 17:35, Andy Shevchenko wrote: > >>>>> On Wed, Nov 14, 2018 at 1:53 AM Chanwoo Choi <cw00.choi@samsung.com> wrote: > >>>>> > >>>>>> I was thinking about again to change from NULL to EPROBE_DEFER. > >>>>>> > >>>>>> extcon_get_extcon_dev() function was almost called in the probe function. > >>>>>> But, this function might be called on other position instead of probe. > >>>>> > >>>>> *Might be* sounds like a theoretical thing, care to share what is in you mind? > >>>>> Current users and more important the new coming one are *all* doing the same. > >>>>> > >>>>>> ENODEV is more correct error instead of EPROBE_DEFER. > >>>>> > >>>>> So, you are proposing to continue duplicating conversion from ENODEV > >>>>> to EPROBE_DEFER in *each* caller? > >>>> > >>>> The extcon core don't know the caller situation is in either probe() or other position > >>>> in the caller driver. The caller driver should decide the kind of error value > >>>> by using the return value of extcon_get_extcon_dev(). > >>>> > >>>> extcon_get_extcon_dev() function cannot be modified for only one case. > >>>> If some device driver call extcon_get_extcon_dev() out of probe() fuction, > >>>> EPROBE_DEFER is not always correct. > >>> > >>> I agree with this, but look at the current state of affairs. All users do the same. > >>> If we need to have another case we may consider this later. > >> > >> Because we know the potential wrong case of this change, I can't agree this change. > >> If extcon_get_extcon_dev() returns ENODEV instead of EPROBE_DEFER, > >> it is clear and then there are no problem on both current and future. > > > > Changing NULL to -ENODEV is a trading bad to worse. > > I would not go that way, so, it's your call. > > If you think that this change is not necessary, just keep the current code > without the modification. Not only this, the useless churn for no benefit to anyone, except some *theoretical* cases no one saw. > Please drop this patch on next version. I will. > >>> API inside the kernel are not carved in the stone. > > > > Only can repeat myself (see above). While I see *theoretical* > > rationale on your side, mine has *practical* proofs. > > So, I'm giving up on this and will duplicate same what it's done in 4 > > current callers. > > > > I think that it is more important for removing the potential wrong case > instead of removing the duplicate code. The many device drivers already > decided the proper error value by using the return value of function of > kernel framework. The API has been introduced back in 2012. commit 74c5d09bd562edc220d6e076b8f1e118819c178f Author: Donggeun Kim <dg77.kim@samsung.com> Date: Fri Apr 20 14:16:24 2012 +0900 So, you are insisting that 6.5 years of use in a way people are using it is wrong? I don't know what might change your mind, but for me it's a clear win-win to switch to deferred probe error code based on the *practical* evidence. But as I said, I gave up now. P.S. I still disagree with your arguments in relation to de facto use of an API.
next prev parent reply other threads:[~2018-11-14 11:17 UTC|newest] Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-10 18:10 [PATCH v1 1/5] drivercore: Revert "deferral race condition fix" Andy Shevchenko 2018-11-10 18:10 ` [v1,1/5] " Andy Shevchenko 2018-11-10 18:10 ` [PATCH v1 2/5] extcon: Return -EPROBE_DEFER when extcon device is not found Andy Shevchenko 2018-11-10 18:10 ` [v1,2/5] " Andy Shevchenko 2018-11-10 18:39 ` [PATCH v1 2/5] " Guenter Roeck 2018-11-10 18:39 ` [v1,2/5] " Guenter Roeck 2018-11-11 0:06 ` [PATCH v1 2/5] " Sebastian Reichel 2018-11-11 0:06 ` [v1,2/5] " Sebastian Reichel 2018-11-12 0:24 ` [PATCH v1 2/5] " Chanwoo Choi 2018-11-12 0:24 ` [v1,2/5] " Chanwoo Choi 2018-11-13 23:52 ` [PATCH v1 2/5] " Chanwoo Choi 2018-11-13 23:52 ` [v1,2/5] " Chanwoo Choi 2018-11-14 8:35 ` [PATCH v1 2/5] " Andy Shevchenko 2018-11-14 8:35 ` [v1,2/5] " Andy Shevchenko 2018-11-14 9:13 ` [PATCH v1 2/5] " Chanwoo Choi 2018-11-14 9:13 ` [v1,2/5] " Chanwoo Choi 2018-11-14 9:36 ` [PATCH v1 2/5] " Andy Shevchenko 2018-11-14 9:36 ` [v1,2/5] " Andy Shevchenko 2018-11-14 9:48 ` [PATCH v1 2/5] " Chanwoo Choi 2018-11-14 9:48 ` [v1,2/5] " Chanwoo Choi 2018-11-14 10:20 ` [PATCH v1 2/5] " Andy Shevchenko 2018-11-14 10:20 ` [v1,2/5] " Andy Shevchenko 2018-11-14 11:05 ` [PATCH v1 2/5] " Chanwoo Choi 2018-11-14 11:05 ` [v1,2/5] " Chanwoo Choi 2018-11-14 11:17 ` Andy Shevchenko [this message] 2018-11-14 11:17 ` Andy Shevchenko 2018-11-14 14:04 ` [PATCH v1 2/5] " Andy Shevchenko 2018-11-14 14:04 ` [v1,2/5] " Andy Shevchenko 2018-11-15 1:16 ` [PATCH v1 2/5] " Chanwoo Choi 2018-11-15 1:16 ` [v1,2/5] " Chanwoo Choi 2018-11-12 11:47 ` [PATCH v1 2/5] " Heikki Krogerus 2018-11-12 11:47 ` [v1,2/5] " Heikki Krogerus 2018-11-10 18:10 ` [PATCH v1 3/5] staging: typec: fusb302: Rename fcs,extcon-name to linux,extcon-name Andy Shevchenko 2018-11-10 18:10 ` [v1,3/5] " Andy Shevchenko 2018-11-10 18:40 ` [PATCH v1 3/5] " Guenter Roeck 2018-11-10 18:40 ` [v1,3/5] " Guenter Roeck 2018-11-10 18:11 ` [PATCH v1 4/5] usb: dwc3: drd: Switch to device property for 'extcon' handling Andy Shevchenko 2018-11-10 18:11 ` [v1,4/5] " Andy Shevchenko 2018-11-12 11:47 ` [PATCH v1 4/5] " Felipe Balbi 2018-11-12 11:47 ` [v1,4/5] " Felipe Balbi 2018-11-12 11:47 ` [PATCH v1 4/5] " Felipe Balbi 2018-11-10 18:11 ` [PATCH v1 5/5] usb: dwc3: drd: Add support for DR detection through extcon Andy Shevchenko 2018-11-10 18:11 ` [v1,5/5] " Andy Shevchenko 2018-11-10 18:26 ` [PATCH v1 1/5] drivercore: Revert "deferral race condition fix" Greg Kroah-Hartman 2018-11-10 18:26 ` [v1,1/5] " Greg Kroah-Hartman 2018-11-10 18:36 ` [PATCH v1 1/5] " Andy Shevchenko 2018-11-10 18:36 ` [v1,1/5] " Andy Shevchenko 2018-11-11 11:45 ` [PATCH v1 1/5] " Hans de Goede 2018-11-11 11:45 ` [v1,1/5] " Hans de Goede 2018-11-11 13:04 ` [PATCH v1 1/5] " Andy Shevchenko 2018-11-11 19:26 ` Rob Herring 2018-11-11 23:53 ` Andy Shevchenko 2018-11-14 23:25 ` Grant Likely 2018-11-12 16:11 ` Peter Ujfalusi 2018-11-12 16:11 ` [v1,1/5] " Peter Ujfalusi 2018-11-12 16:11 ` [PATCH v1 1/5] " Peter Ujfalusi 2018-11-14 0:33 ` Mark Brown 2018-11-14 0:33 ` [v1,1/5] " Mark Brown 2018-11-14 8:45 ` [PATCH v1 1/5] " Andy Shevchenko 2018-11-14 8:45 ` [v1,1/5] " Andy Shevchenko 2018-11-14 8:45 ` [PATCH v1 1/5] " Andy Shevchenko 2018-11-14 10:19 ` Peter Ujfalusi 2018-11-14 10:19 ` [v1,1/5] " Peter Ujfalusi 2018-11-14 10:19 ` [PATCH v1 1/5] " Peter Ujfalusi
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='CAHp75Vc3NC95Wt9T2qx9SCGtwoR2hA7azGAHhqz7LO-yKz=mew@mail.gmail.com' \ --to=andy.shevchenko@gmail.com \ --cc=balbi@kernel.org \ --cc=cw00.choi@samsung.com \ --cc=dvhart@infradead.org \ --cc=gregkh@linuxfoundation.org \ --cc=hdegoede@redhat.com \ --cc=heikki.krogerus@linux.intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=linux@roeck-us.net \ --cc=myungjoo.ham@samsung.com \ --cc=platform-driver-x86@vger.kernel.org \ --cc=rafael@kernel.org \ --cc=rogerq@ti.com \ --cc=sre@kernel.org \ --cc=wens@csie.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: linkBe 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.