From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932843AbeAOJIW (ORCPT + 1 other); Mon, 15 Jan 2018 04:08:22 -0500 Received: from mailout1.samsung.com ([203.254.224.24]:49652 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932385AbeAOJIP (ORCPT ); Mon, 15 Jan 2018 04:08:15 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.samsung.com 20180115090814epoutp01fbf41e6a8342ed32ecd067f4054da0c9~J8JoM_V632018820188epoutp01M X-AuditID: b6c32a45-e7bff700000010f7-66-5a5c6f7dd502 MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset="utf-8" Message-id: <5A5C6F7C.4090200@samsung.com> Date: Mon, 15 Jan 2018 18:08:12 +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: <996966c8-6a31-eb48-579e-f8ef119a15d5@redhat.com> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBKsWRmVeSWpSXmKPExsWy7bCmqW5tfkyUwZEuCYs3x6czWVzeNYfN 4nbjCjaLn4fOMzmweGx4tJrV4/2+q2wefVtWMXp83iQXwBKVapORmpiSWqSQmpecn5KZl26r 5B0c7xxvamZgqGtoaWGupJCXmJtqq+TiE6DrlpkDtFJJoSwxpxQoFJBYXKykb2dTlF9akqqQ kV9cYqsUbWhopGdoYK5nZGSkZ2Ica2VkClSSkJpx8NVm9oJPUhV7995mamB8LtLFyMkhIWAi 8XDnDpYuRi4OIYEdjBI9/14yQTjfGSWe3e9i62LkAKs612EPEd/NKHHzyxlmkG5eAUGJH5Pv sYDUMAvISxy5lA0SZhbQlHjxZRLU0HuMEme2HGOFqNeSmHj1CSOIzSKgKnHj2wY2EJsNKL7/ xQ0wm19AUeLqj8dgNaICERI7539jB7FFBAokGn9sY4NYoCDx694msJnCAtkSr75uYAKxOQXs JNbe7mMEWSwhsIZN4vWbHawQb7pIdP85zwRhC0u8Or6FHcKWlni2aiNUQzujRPveecwQzhRG iXPX70F1GEs8W9jFBLGaT6Lj8F92SLDwSnS0CUGUeEhM/r8PqtxRouv3Caj3+5gkXtzYwjSB UW4WUojNQoTYLKQQW8DIvIpRLLWgODc9tdiowFCvODG3uDQvXS85P3cTIziVabnuYJxxzucQ owAHoxIPL8OS6Cgh1sSy4srcQ4wSHMxKIryNwTFRQrwpiZVVqUX58UWlOanFhxhNgQE+kVlK NDkfmGbzSuINTSwNTMzMjMzNLIApTJy3LcAlSkggPbEkNTs1tSC1CKaPiYNTqoHR4dnB1Lzz 6a0bzOo+hz5Z9iZDUi7+B/ObCV97z8YUc+42PfaZtWdVzPllFpG7ciTOzNB6p7Jzr2JZzIqb M+I4Io8Xy8dJVXitTRRrnn5LPazxlLS3/4+3/OIhTfq/335xD3BuS/jP7qe55ElRQ99G47Sw lQH5OpbPbtrz1accXXB8SXdaspESS3FGoqEWc1FxIgDHzbsgewMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsVy+t9jAd3a/Jgog+YjnBZvjk9nsri8aw6b xe3GFWwWPw+dZ3Jg8djwaDWrx/t9V9k8+rasYvT4vEkugCWKyyYlNSezLLVI3y6BK+Pgq83s BZ+kKvbuvc3UwPhcpIuRg0NCwETiXId9FyMXh5DATkaJmU9fs3UxcnLwCghK/Jh8jwWkhllA XuLIpWwIU11iypRciPIHjBK7uvpZIMq1JCZefcIIYrMIqErc+LYBbAwbUHz/ixtgNr+AosTV H48ZQeaICkRIdJ+oBDFFBAok+r5VglQwCyhI/Lq3iRXEFhbIlmhf+JAFYlUfk8S1B3PAVnEK 2Emsvd3HOIFRYBaSQ2chHDoL4dAFjMyrGCVTC4pz03OLjQqM8lLL9YoTc4tL89L1kvNzNzEC Q3fbYa3+HYyPl8QfYhTgYFTi4WVYEh0lxJpYVlyZe4hRgoNZSYS3MTgmSog3JbGyKrUoP76o NCe1+BCjNAeLkjgvf/6xSCGB9MSS1OzU1ILUIpgsEwenVAOj43JNgUt6ByujthW0T00osJhy ZofAG50mPutF+Rzz6ywLJhaoqK+WXsvZ7VGQpi6Xlrmg8dGiI6nHrZz2P2rQF3aU+rw0Q1/P +r7QTwtnBg1PQ63pi+fMX+pl8aki84xRy0aTr02hjEfvvnotppqaIBJ2eHc1xyslo80KglU2 vktCCp4/WabEUpyRaKjFXFScCABdyh8QWQIAAA== X-CMS-MailID: 20180115090813epcas2p12a6cb0a3d313550ea40b01860cd8e212 X-Msg-Generator: CA CMS-TYPE: 102P 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> <5A5C3A85.9080109@samsung.com> <996966c8-6a31-eb48-579e-f8ef119a15d5@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일 17:36, Hans de Goede wrote: > Hi, > > On 15-01-18 06:22, Chanwoo Choi wrote: >> 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 agree that having some sort of proper probe ordering here would be > better. But on these ACPI systems that is going to be quite tricky todo, > since we've no control over the firmware there. > > Note that you've already merged the workaround, this patch merely changes > the workaround to avoid it in cases where it is not necessary, so I would > really like to see this get merged. I merged your patch because I knew this issue related to dependency. But, I don't want to merge this patch until developing the fundamental method. All extcon provider driver have the same issue. I'll try to resolve this issue thro extcon framework. -- Best Regards, Chanwoo Choi Samsung Electronics