From: Hans de Goede <hdegoede@redhat.com>
To: Chanwoo Choi <cw00.choi@samsung.com>,
MyungJoo Ham <myungjoo.ham@samsung.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] extcon: int3496: process id-pin first so that we start with the right status
Date: Fri, 2 Feb 2018 09:10:01 +0100 [thread overview]
Message-ID: <9060e517-c67b-b04a-ba40-bc9e17bf2b4e@redhat.com> (raw)
In-Reply-To: <5A73B1A5.5000907@samsung.com>
Hi,
On 02-02-18 01:32, Chanwoo Choi wrote:
> On 2018년 01월 26일 04:39, Hans de Goede wrote:
>> Some other drivers may be waiting for our extcon to show-up (exiting their
>> probe methods with -EPROBE_DEFER until we show up).
>>
>> These drivers will typically get the cable state directly after getting
>> the extcon, this commit changes the int3496 code to process the id-pin
>> before registering the extcon, so that other drivers see the correct state
>> right away.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/extcon/extcon-intel-int3496.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/extcon/extcon-intel-int3496.c b/drivers/extcon/extcon-intel-int3496.c
>> index c8691b5a9cb0..b23ee9d993a3 100644
>> --- a/drivers/extcon/extcon-intel-int3496.c
>> +++ b/drivers/extcon/extcon-intel-int3496.c
>> @@ -131,6 +131,10 @@ static int int3496_probe(struct platform_device *pdev)
>> if (IS_ERR(data->gpio_usb_mux))
>> dev_info(dev, "can't request USB MUX GPIO\n");
>>
>> + /* process id-pin first so that we start with the right status */
>> + queue_delayed_work(system_wq, &data->work, 0);
>> + flush_delayed_work(&data->work);
>> +
>> /* register extcon device */
>> data->edev = devm_extcon_dev_allocate(dev, int3496_cable);
>> if (IS_ERR(data->edev))
>> @@ -153,9 +157,6 @@ static int int3496_probe(struct platform_device *pdev)
>> return ret;
>> }
>>
>> - /* queue initial processing of id-pin */
>> - queue_delayed_work(system_wq, &data->work, 0);
>> -
>> platform_set_drvdata(pdev, data);
>>
>> return 0;
>>
>
> Looks good to me.
> How about adding the 'Fixes' commit id on patch description?
Right, this could use a:
Fixes: 2f556bdb9f2e ("extcon: int3496: Add Intel INT3496 ACPI device extcon driver")
tag.
> I think that your revert patch of axp288 and this patch
> should be included in extcon-fixes branch.
Ack.
Regards,
Hans
next prev parent reply other threads:[~2018-02-02 8:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20180125193930epcas1p15288db5193038561d6061fcaa2a802bb@epcas1p1.samsung.com>
2018-01-25 19:39 ` Hans de Goede
2018-02-01 21:46 ` Chanwoo Choi
2018-02-02 0:32 ` Chanwoo Choi
2018-02-02 8:10 ` Hans de Goede [this message]
2018-02-04 23:28 ` Chanwoo Choi
2018-02-06 8:11 ` Hans de Goede
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=9060e517-c67b-b04a-ba40-bc9e17bf2b4e@redhat.com \
--to=hdegoede@redhat.com \
--cc=cw00.choi@samsung.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
Powered by JetHome