From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752322AbeAOFWS (ORCPT + 1 other); Mon, 15 Jan 2018 00:22:18 -0500 Received: from mailout1.samsung.com ([203.254.224.24]:21433 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750842AbeAOFWQ (ORCPT ); Mon, 15 Jan 2018 00:22:16 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.samsung.com 20180115052214epoutp01d690b0e379ac038eebc352c27ab8c10f~J5ETqlno91476114761epoutp01j X-AuditID: b6c32a36-3d5ff7000000117d-65-5a5c3a85c50f MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset="UTF-8" Message-id: <5A5C3A85.9080109@samsung.com> Date: Mon, 15 Jan 2018 14:22:13 +0900 From: Chanwoo Choi Organization: Samsung Electronics User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Hans de Goede , MyungJoo Ham , Chen-Yu Tsai Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] extcon: axp288: Only reschedule charger-detection at boot when a SDP is detected In-reply-to: <20180114151021.11432-2-hdegoede@redhat.com> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBKsWRmVeSWpSXmKPExsWy7bCmgW6rVUyUwfQ5RhZvjk9nsri8aw6b xe3GFWwWPw+dZ3Jg8djwaDWrx/t9V9k8+rasYvT4vEkugCUq1SYjNTEltUghNS85PyUzL91W yTs43jne1MzAUNfQ0sJcSSEvMTfVVsnFJ0DXLTMHaKWSQlliTilQKCCxuFhJ386mKL+0JFUh I7+4xFYp2tDQSM/QwFzPyMhIz8Q41srIFKgkITXjxqR1TAWzRSpe3fvD0sDYIdDFyMkhIWAi seLWTNYuRi4OIYEdjBKTzl9ignC+M0p0bfzPAlP17/AKdojEBkaJJVNnMYMkeAUEJX5MvgdU xMHBLCAvceRSNkiYWUBTYuvu9VD19xglOl49ZYeo15L48/cNE4jNIqAqsWZ9D5jNBhTf/+IG G4jNL6AocfXHY0YQW1QgQmLn/G9gvSICBRKNP7axQSxQkPh1bxMriC0skC3x6usGsDmcApYS ny5sZANZLCGwhk2i9VA3K8QHLhL93fuhbGGJV8e3sIMcLSEgLXHpqC1EfTujRPveecwQzhRG iXPX7zFBNBhLPFvYxQSxmU/i3dceVohmXomONiGIEg+Jyf/3QZU7SnT9PsEC8f1uRokT246z TGCUm4UUYLMQATYLKcAWMDKvYhRLLSjOTU8tNiww0itOzC0uzUvXS87P3cQITmVaZjsYF53z OcQowMGoxMPLsCQ6Sog1say4MvcQowQHs5IIb9jpiCgh3pTEyqrUovz4otKc1OJDjKbA8J7I LCWanA9Ms3kl8YYmlgYmZkbA9GVpaKgkzhsQ4BIlJJCeWJKanZpakFoE08fEwSnVwJhanB/Y 56KeKlGzw1roNMdN4VXX8jQOq20/H/Az/KPDnqClmyL5FWw8/79eeyDyrUzQfq41q2qm7L2/ 9DNDfWFKTsC5gCD5NweC+R8fduTnuH5xQp3SwumreJN8P96s1Et+wLM+PaiIddVnzkOcu+7f 2cUmFv+rtFcw+MRbro/cPx/Gf8s9GaDEUpyRaKjFXFScCADpbZpOewMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsVy+t9jQd1Wq5gog8dfZS3eHJ/OZHF51xw2 i9uNK9gsfh46z+TA4rHh0WpWj/f7rrJ59G1ZxejxeZNcAEsUl01Kak5mWWqRvl0CV8aNSeuY CmaLVLy694elgbFDoIuRk0NCwETi3+EV7F2MXBxCAusYJTYfW8kIkuAVEJT4MfkeSxcjBwez gLzEkUvZIGFmAXWJSfMWMUPUP2CUOLf7LhNEvZbEn79vwGwWAVWJNet7wGw2oPj+FzfYQGx+ AUWJqz8eM4LMFBWIkOg+UQliiggUSPR9q4QYryDx694mVhBbWCBbon3hQxaIVbsZJdaeeQE2 klPAUuLThY1sExgFZiG5dBbCpbOQXLqAkXkVo2RqQXFuem6xUYFhXmq5XnFibnFpXrpecn7u JkZgAG87rNW3g/H+kvhDjAIcjEo8vBHLoqOEWBPLiitzDzFKcDArifCGnY6IEuJNSaysSi3K jy8qzUktPsQozcGiJM57O+9YpJBAemJJanZqakFqEUyWiYNTqoGRMdvppnqGinzcRW7GS/m6 h9WcNcOErWeJ/Xt4T2LWqhebfVpV1N0z3Pi/Jjh/XxErP13GrCQ86KRB+qpi00v1Ip2HZ4ZY rRf+xJhkHTlp3V/HBY5c/FzRrVxRyqeFf9zVteZZ7ibkXsLlcrXZRUKmgylj9sZNQX3FuXYH ub5Lfpj8OfDMGiWW4oxEQy3mouJEAG2o2INcAgAA X-CMS-MailID: 20180115052213epcas1p45141e853fe1008a0a2c3c14292083f28 X-Msg-Generator: CA CMS-TYPE: 101P DLP-Filter: Pass X-CFilter-Loop: Reflected X-CMS-RootMailID: 20180114151027epcas3p4d76fcdd44ec7d8adeaa187abd5e5a825 X-RootMTR: 20180114151027epcas3p4d76fcdd44ec7d8adeaa187abd5e5a825 References: <20180114151021.11432-1-hdegoede@redhat.com> <20180114151021.11432-2-hdegoede@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 2018년 01월 15일 00:10, Hans de Goede wrote: > The only misdetection which can happen at boot due to data-lines mux issues > is detecting a non SDP as SDP, so we only need to retry if we detect a SDP > on our first detection. > > Note Vbus misdetection is not a problem, as soon as the drivers controlling > the Vbus path set it correctly we will get an interrupt which reschedules > the charger-detection. > > Also update the comment about the re-detection to reflect this. > > Signed-off-by: Hans de Goede > --- > drivers/extcon/extcon-axp288.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c > index 63b99d5becd7..17e6808af0d1 100644 > --- a/drivers/extcon/extcon-axp288.c > +++ b/drivers/extcon/extcon-axp288.c > @@ -161,16 +161,16 @@ static void axp288_chrg_detect_complete(struct axp288_extcon_info *info, > /* > * We depend on other drivers to do things like mux the data lines, > * enable/disable vbus based on the id-pin, etc. Sometimes the BIOS has > - * not set these things up correctly resulting in the initial charger > - * cable type detection giving a wrong result and we end up not charging > - * or charging at only 0.5A. > + * not set these things up correctly resulting in a wrong result for the > + * initial charger type detection and we end up charging at only 0.5A. > * > - * So we schedule a second cable type detection after 2 seconds to > - * give the other drivers time to load and do their thing. > + * If our first detect detects an SDP charger-type, we try again after > + * 2 seconds to give the other drivers time to load and do their thing. > */ > if (!info->first_detect_done) { > - queue_delayed_work(system_wq, &info->det_work, > - msecs_to_jiffies(2000)); > + if (info->previous_cable == EXTCON_CHG_USB_SDP) > + queue_delayed_work(system_wq, &info->det_work, > + msecs_to_jiffies(2000)); > info->first_detect_done = true; > } > > I understand why you add the second delayed_work because of dependency of other consumer driver. But, this patch is not proper method. It looks like the workaround. We need to consider the fundamental solution such as using OF graph or sending the pending notification when consumer driver is probed. I don't know what is best solution right now. I'll consider the appropriate method for all extcon provider drivers. -- Best Regards, Chanwoo Choi Samsung Electronics