Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp637107pxb; Tue, 9 Feb 2021 08:49:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJwgvjLBhLtuFJlEwqUXUvUY+vtN8HieFo6iAF+zudRWIJzV/EpjnbEBPKCB6kv0eoDc6yhS X-Received: by 2002:a05:6402:558:: with SMTP id i24mr21802471edx.190.1612889388906; Tue, 09 Feb 2021 08:49:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612889388; cv=none; d=google.com; s=arc-20160816; b=HJE9rCsl3fvJMuKqJpk4j2SGnOtMW4QTRsv6ta4Fvo9MnPKDMBxrb5EWYT4Ae2N/3l P8oxrMzZKJHbIzB72p8qFkXxWvaYCO2i5TDkTr649UI2QPgyjn6BkQcBKyJH2ibizS1C bZLgMD7lPprC3RwKBf1mm9v/57mOsrCVcuQjRyiEPuKNYa1DUgse8JLokcXZRn0wfggc H7BsBce5zC8ga3LMCm0QCheKthJpjQmn31YYhB64ggnMYiYLjDuwMZcwLGsxF+zCcqmw kA6dlFkMBbDHGMhHqW0Le8wZqxOxqDpKoPRineO+/EHzgCDxet13kEHVyW7l7hEaoxR5 H31g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=9taZttSD3TU/NKq023+Uxxq9BinerU1RlKUsH/RzkKw=; b=TbxeS48C0OMJrGOrXBgWcJPDQmfJ1oDsTcaIjjgMCqm0T471v90/J8Zs463G7UkM3G io5CeBCl8mKIvOWobdg0eSrKZu1bKA782TCa6UvnS527k6fAXSrjAYeP7pxgFodhOT8o MkODju4jGrYkPGhW7SQ7EegEteqkKoKU6nbwiQgDu5nWMIrZj4Jtkk0OUqfhgtzCbJJu Cw5WEUMldrJJqohBemmRyiJ+TGXLo4ZANlg35sr+PJEYQWtL3243hsfhkHyraN8FFOo9 TzphfZrDFbDREsCHJhg+tUnxrvsRBawZLLHSzYkxxrp7C9UxQ01Eh76dyF4Bx2OdnN7Z 6JzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="LsP/64hh"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p24si15274878edw.475.2021.02.09.08.49.25; Tue, 09 Feb 2021 08:49:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="LsP/64hh"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233037AbhBIQrm (ORCPT + 99 others); Tue, 9 Feb 2021 11:47:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233011AbhBIQpo (ORCPT ); Tue, 9 Feb 2021 11:45:44 -0500 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6C38EC061756 for ; Tue, 9 Feb 2021 08:45:02 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id i9so4128775wmq.1 for ; Tue, 09 Feb 2021 08:45:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=9taZttSD3TU/NKq023+Uxxq9BinerU1RlKUsH/RzkKw=; b=LsP/64hhwzFsXvgFZGb2VTs1HjU9kXxEeTBsrb/fWSKVnPyD+XFrnJb4Tcm7C8we5E Lnlk4p7cD20siuZnHIN7vts+RY0c4Ue6QCGsWPDiojz5pK43Z75I8M/CcuFbV3zKos3d +Eqxzectjd/mxA7YP9L+s4fukBC+h+7F7pvlKr+RK6V9nc7kvRWh2rs7BMIeNURBpuCB oUkUM1iXtMUYh2vQMowPoZomR1EX7H6v1RFaDG6flOayfAQFN1SUTALC+N8ri7RgNIaF o1Eez5DEDTvILnn52R8nDjttzPgEPkRiASADvTYT80UoAT7XysRu8CtLtaFXR7w4FDHz prBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=9taZttSD3TU/NKq023+Uxxq9BinerU1RlKUsH/RzkKw=; b=d909Ue0w5S15hIlA9V4zrcBIJDOS+TFoV8WxRuVAbt0Xz4oE8vo/2R/MB1GCnUFp3g c4mFAwQf3/TBT2epCl1kMHiQI9JNM9vjmuYaF2I9SQ62KQ3B+IjWz+0pXLo7mN5vGPJJ hurVPHEJb8+9zmTBguoOWOv0psTwl9qUadLzvE+Z4ETibfhQUxOnpbXUF3OG9VBK4f89 pRo970u9kso2hl4O2UUWDXxid6NWE8jf5XaiZ0ElDXB/tTf6lUsRpwrD583mlgdW2ttd RHSRkITmw3lcJ/rgvWgpyPq2zkI3f/QvDD+tsnHW+8cL494WsUYbGlHvQZ03mny8Nbr4 EhuQ== X-Gm-Message-State: AOAM532VPeQHfAJAJzUBUtcGKl2DkGi0ZtQTP80/Vl/cAGthQfNPFz6m rZlv173PhkJC72rMTl4OZQ9UTw== X-Received: by 2002:a1c:9c01:: with SMTP id f1mr4153206wme.159.1612889101120; Tue, 09 Feb 2021 08:45:01 -0800 (PST) Received: from dell ([91.110.221.187]) by smtp.gmail.com with ESMTPSA id z15sm4958853wmi.38.2021.02.09.08.44.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Feb 2021 08:45:00 -0800 (PST) Date: Tue, 9 Feb 2021 16:44:58 +0000 From: Lee Jones To: Hans de Goede Cc: MyungJoo Ham , Chanwoo Choi , Cezary Rojewski , Pierre-Louis Bossart , Liam Girdwood , Jie Yang , Mark Brown , patches@opensource.cirrus.com, linux-kernel@vger.kernel.org, Andy Shevchenko , Charles Keepax , alsa-devel@alsa-project.org Subject: Re: [PATCH v4 resend 00/13] MFD/extcon/ASoC: Rework arizona codec jack-detect support Message-ID: <20210209164458.GE220368@dell> References: <20210204112502.88362-1-hdegoede@redhat.com> <20210209141420.GE4766@dell> <20210209154511.GC220368@dell> <80068116-eb04-fd75-f656-804ab9f5d414@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <80068116-eb04-fd75-f656-804ab9f5d414@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 09 Feb 2021, Hans de Goede wrote: > Hi, > > On 2/9/21 4:45 PM, Lee Jones wrote: > > On Tue, 09 Feb 2021, Hans de Goede wrote: > > > >> Hi, > >> > >> On 2/9/21 3:14 PM, Lee Jones wrote: > >>> On Mon, 08 Feb 2021, Hans de Goede wrote: > >>> > >>>> Hi Mark, Lee, > >>>> > >>>> On 2/4/21 12:24 PM, Hans de Goede wrote: > >>>>> Hi all, > >>>>> > >>>>> Here is v4 of my series to rework the arizona codec jack-detect support > >>>>> to use the snd_soc_jack helpers instead of direct extcon reporting. > >>>>> > >>>>> This is a resend with some extra *-by tags collected and with the extcon > >>>>> folks added to the "To:" list, which I somehow missed with the original > >>>>> v4 posting, sorry. > >>>>> > >>>>> This is done by reworking the extcon driver into an arizona-jackdet > >>>>> library and then modifying the codec drivers to use that directly, > >>>>> replacing the old separate extcon child-devices and extcon-driver. > >>>>> > >>>>> This brings the arizona-codec jack-detect handling inline with how > >>>>> all other ASoC codec driver do this. This was developed and tested on > >>>>> a Lenovo Yoga Tablet 1051L with a WM5102 codec. > >>>>> > >>>>> This was also tested by Charles Keepax, one of the Cirrus Codec folks. > >>>>> > >>>>> This depends on the previously posted "[PATCH v4 0/5] MFD/ASoC: Add > >>>>> support for Intel Bay Trail boards with WM5102 codec" series and there > >>>>> are various interdependencies between the patches in this series. > >>>>> > >>>>> Lee Jones, the MFD maintainer has agreed to take this series upstream > >>>>> through the MFD tree and to provide an immutable branch for the ASoC > >>>>> and extcon subsystems to merge. > >>>>> > >>>>> Mark and extcon-maintainers may we have your ack for merging these > >>>>> through the MFD tree ? > >>>> > >>>> Now that the pre-cursor (1) series to this has been merged, I guess it > >>>> is time to decide how to merge this series. > >>>> > >>>> Chanwoo Choi has given his ack to merge the extcon bits through the MFD > >>>> tree and since Mark has expressed a preference for merging ASOC patches > >>>> directly I guess that it would be best to merge 1-6 through the MFD > >>>> tree and then Lee can send Mark a pull-req and Mark can apply the others? : > >>>> > >>>> 1/13 mfd: arizona: Drop arizona-extcon cells > >>>> 2/13 extcon: arizona: Fix some issues when HPDET IRQ fires after the jack has been unplugged > >>>> 3/13 extcon: arizona: Fix various races on driver unbind > >>>> 4/13 extcon: arizona: Fix flags parameter to the gpiod_get("wlf,micd-pol") call > >>>> 5/13 extcon: arizona: Always use pm_runtime_get_sync() when we need the device to be awake > >>>> 6/14 ASoC/extcon: arizona: Move arizona jack code to sound/soc/codecs/arizona-jack.c > >>>> > >>>> 1 is: Acked-for-MFD-by: Lee Jones > >>>> 2-6 are: Acked-by: Chanwoo Choi > >>>> > >>>> Note patch 6 renames drivers/extcon/extcon-arizona.c to sound/soc/codecs/arizona-jack.c > >>>> but it does not touch any other files under sound/soc (including NOT touching > >>>> sound/soc/codecs/Makefile that is done in a later patch). So it cannot cause any > >>>> conflicts. > >>>> > >>>> Mark, would merging 1-6 through the MFD tree, and you applying the rest > >>>> (which are all ASoC patches) work for you ? > >>> > >>> What a faff. > >>> > >>> I still don't see why they can't all go in and a PR provided. > >> > >> Well patch 13/13 of this set relies on 5/5 from the previous set which is > >> only in Mark's ASoC tree and not in the MFD tree, so splitting things over MFD + ASoC > >> again makes the most sense here too. > > > > Right, this is what can happen when patch-sets are split up. > > > >> The alternative is Mark doing a PR from ASoC to MFD to get 5/5 from the previous set > >> in MFD first, which seems less then ideal. > > > > Well this set isn't likely to go in this cycle anyway, so actually the > > problem should just go away. > > That is true. > > > Best to let the first set get sucked > > into v5.12, then send this one up subsequently for v5.13. > > Ack. So should I resend this once 5.12-rc1 is out ? If you haven't heard from anything by then, [RESEND] by all means. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog