From: Hans de Goede <hdegoede@redhat.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Yauhen Kharuzhy <jekhor@gmail.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
MyungJoo Ham <myungjoo.ham@samsung.com>
Subject: Re: [PATCH 0/2] extcon: Intel Cherry Trail Whiskey Cove PMIC and external charger tweaks
Date: Fri, 15 Feb 2019 10:33:41 +0100 [thread overview]
Message-ID: <4069f988-dda7-4e97-031d-ad494617ab4a@redhat.com> (raw)
In-Reply-To: <CAHp75VfB3PMBH8qAyHJPfptd0POGq4pey3TkjzU6dZqZ_Vqt+Q@mail.gmail.com>
Hi,
On 15-02-19 10:29, Andy Shevchenko wrote:
> On Fri, Feb 15, 2019 at 10:31 AM Hans de Goede <hdegoede@redhat.com> wrote:
>> On 14-02-19 15:15, Yauhen Kharuzhy wrote:
>
>> I would do something similar with the fuel-gauge in
>> drivers/platform/x86/intel_cht_int33fe.c, one option would
>> be to simply count the number of resources in the ACPI
>> resource table for the INT33FE device, versions with
>> the Type-C port have 7 resources, where as your INT33FE
>> device has only 3.
>>
>> I'm even thinking that it might be best to rename
>> intel_cht_int33fe.c to intel_cht_int33fe_typec.c and add
>> a check for the resource table having 7 entries there, then
>> you can make a intel_cht_int33fe_micro_usb.c copy and strip
>> that mostly empty. Both would bind to the same "INT33FE"
>> id and they would both silently bail with -ENODEV if the
>> resource-count (or the PTYP value) don't match.
>>
>> The reason I'm thinking of having 2 drivers is because
>> the current intel_cht_int33fe.c is quite special / ugly and
>> already has enough ifs.
>>
>> If you do a stand-alone intel_cht_int33fe_micro_usb.c that can
>> hopefully be much simpler.
>>
>> Andy what is your take on having separate intel_cht_int33fe_typec.c
>> and intel_cht_int33fe_micro_usb.c drivers, both binding to
>> the "INT33FE" ACPI-ID (with its totally !@#%$#-ed up "API") ?
>
> Depends on how code would look better,
Well the existing drivers/platform/x86/intel_cht_int33fe.c file,
which already is full of kludges would not get even more code-paths
added; and the new file which Yauhen will wrote should be nice and
clean with only 1 straight code-path pretty much.
> though I care about users that
> they will not get additional Kconfig option and broken their
> configurations when new piece of code landed up. So, from mine, as
> user, prospective, we may split driver as we wish, but we should get
> it working as previously for the existing cases.
That is a valid point, I'm not a fan of having even more Kconfig
options either, so we can simply enable/disable both modules through
the same Kconfig option.
Regards,
Hans
next prev parent reply other threads:[~2019-02-15 9:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20190210204024epcas3p36ea277b499e647b870d538c5680309bd@epcas3p3.samsung.com>
2019-02-10 20:36 ` [PATCH 0/2] extcon: Intel Cherry Trail Whiskey Cove PMIC and external charger tweaks Yauhen Kharuzhy
2019-02-10 20:36 ` [PATCH 1/2] extcon-intel-cht-wc: Make charger detection co-existed with OTG host mode Yauhen Kharuzhy
2019-02-13 23:15 ` Hans de Goede
2019-02-14 7:09 ` Yauhen Kharuzhy
2019-02-14 15:32 ` Hans de Goede
2019-02-14 14:22 ` Hans de Goede
2019-02-10 20:36 ` [PATCH 2/2] extcon intel-cht-wc: Enable external charger Yauhen Kharuzhy
2019-02-14 16:31 ` Hans de Goede
2019-02-15 6:32 ` Yauhen Kharuzhy
2019-02-17 21:52 ` Yauhen Kharuzhy
2019-02-18 9:24 ` Hans de Goede
2019-02-18 15:07 ` Yauhen Kharuzhy
2019-02-19 13:39 ` Hans de Goede
2019-02-19 20:20 ` Yauhen Kharuzhy
2019-02-20 16:42 ` Hans de Goede
2019-02-20 20:28 ` Yauhen Kharuzhy
2019-02-21 9:33 ` Hans de Goede
2019-02-13 23:00 ` [PATCH 0/2] extcon: Intel Cherry Trail Whiskey Cove PMIC and external charger tweaks Hans de Goede
2019-02-14 10:07 ` Hans de Goede
2019-02-14 12:47 ` Andy Shevchenko
[not found] ` <CAKWEGV7SGDMttB6uHwnkyjWk+bmSmZ-vTSOXHg1UAgLBeqnaXw@mail.gmail.com>
2019-02-14 15:05 ` Hans de Goede
2019-02-15 7:01 ` Yauhen Kharuzhy
2019-02-15 9:26 ` Hans de Goede
2019-02-15 9:29 ` Andy Shevchenko
2019-02-15 9:33 ` Hans de Goede [this message]
2019-02-15 7:08 ` Chanwoo Choi
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=4069f988-dda7-4e97-031d-ad494617ab4a@redhat.com \
--to=hdegoede@redhat.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=andy.shevchenko@gmail.com \
--cc=jekhor@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=myungjoo.ham@samsung.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).