* Re: [RFC PATCH 0/2] Add gpio-usb-c-connector compatible
From: Krishna Kurapati PSSNV @ 2024-03-30 13:45 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Rob Herring, Krzysztof Kozlowski, Greg Kroah-Hartman,
Conor Dooley, Miquel Raynal, Guenter Roeck, Bjorn Helgaas,
Kyle Tso, Fabrice Gasnier, Heikki Krogerus, u.kleine-koenig,
AngeloGioacchino Del Regno, devicetree, linux-usb, linux-kernel,
quic_ppratap, quic_jackp
In-Reply-To: <CAA8EJppa4hVBSenLgxc5MYxTfzPPf4exHvh8RWTP=p8mgB_RCw@mail.gmail.com>
On 3/30/2024 7:09 PM, Dmitry Baryshkov wrote:
> On Sat, 30 Mar 2024 at 11:13, Krishna Kurapati PSSNV
> <quic_kriskura@quicinc.com> wrote:
>> On 3/29/2024 6:23 PM, Dmitry Baryshkov wrote:
>>> On Fri, 29 Mar 2024 at 09:20, Krishna Kurapati
>>> <quic_kriskura@quicinc.com> wrote:
>>>>
>>>> QDU1000 IDP [1] has a Type-c connector and supports USB 3.0.
>>>> However it relies on usb-conn-gpio driver to read the vbus and id
>>>> gpio's and provide role switch. However the driver currently has
>>>> only gpio-b-connector compatible present in ID table. Adding that
>>>> in DT would mean that the device supports Type-B connector and not
>>>> Type-c connector. Thanks to Dmitry Baryshkov for pointing it out [2].
>>>
>>> USB-B connector is pretty simple, it really has just an ID pin and
>>> VBUS input, which translates to two GPIOs being routed from the
>>> _connector_ itself.
>>>
>>> USB-C is much more complicated, it has two CC pins and a VBus power
>>> pin. It is not enough just to measure CC pin levels. Moreover,
>>> properly handling USB 3.0 inside a USB-C connector requires a separate
>>> 'orientation' signal to tell the host which two lanes must be used for
>>> the USB SS signals. Thus it is no longer possible to route just two
>>> pins from the connector to the SoC.
>>>
>>> Having all that in mind, I suspect that you are not describing your
>>> hardware properly. I suppose that you have a Type-C port controller /
>>> redriver / switch, which handles CC lines communication and then
>>> provides ID / VBUS signals to the host. In such a case, please
>>> describe this TCPC in the DT file and use its compatible string
>>> instead of "gpio-c-connector".
>>>
>>
>> Hi Dmitry,
>>
>> My bad. I must have provided more details of the HW.
>>
>> I presume you are referring to addition of a connector node, type-c
>> switch, pmic-glink and other remote endpoints like in other SoC's like
>> SM8450/ SM8550/ SM8650.
>>
>> This HW is slightly different. It has a Uni Phy for Super speed and
>> hence no DP.
>
> This is fine and it's irrelevant for the USB-C.
>
>> For orientation switching, on mobile SoC's, there is a provision for
>> orientation gpio given in pmic-glink node and is handled in ucsi_glink
>> driver. But on this version of HW, there is a USB-C Switch with its own
>> firmware taking care of orientation switching. It takes 8 SS Lines and 2
>> CC lines coming from connector as input and gives out 4 SS Lines (SS
>> TX1/TX2 RX1/RX2) as output which go to the SoC. So orientation switch is
>> done by the USB-C-switch in between and it automatically routes
>> appropriate active SS Lane from connector to the SoC.
>
> This is also fine. As I wrote, you _have_ the Type-C port controller.
> So your DT file should be describing your hardware.
>
>> As usual like in other targets, the DP and DM lines from type-c
>> connector go to the SoC directly.
>>
>> To handle role switch, the VBUS and ID Pin connections are given to
>> SoC as well. There is a vbus controller regulator present to provide
>> vbus to connected peripherals in host mode.
>>
>> There is no PPM entity (ADSP in mobile SoC's) and no UCSI involved
>> here. Hence we rely on usb-conn-gpio to read the vbus/id and switch
>> roles accordingly.
>
> This is also fine.
>
> You confirmed my suspicions. You have an external Type-C switch which
> handles orientation (and most likely PD or non-PD power negotiation)
> for you. It has GPIO outputs, etc.
>
> But it is not a part of the connector. Instead of adding the
> "gpio-usb-c-connector", add proper compatible string (see, how this is
> handled e.g. by the spidev - it is a generic driver, but it requires
> hardware-specific compatibles).
> Your hardware description should look like:
>
> typec {
> compatible = "your,switch";
> id-gpios = <&gpio 1>;
> vbus-gpios = <&gpio 2>;
> vbus-supplies = <®-vbus>;
>
> ports {
> #address-cells = <1>;
> #size-cells = <1>;
> port@0 {
> endpoint {
> remote-endpoint = <&usb_dwc3_hs_out>;
> };
> };
> port@1 {
> endpoint {
> remote-endpoint = <&usb_uni_phy_out>;
> };
> };
> /* No SBU port */
> };
> };
> > Note, I haven't said anything regarding the driver. You can continue
> using the usb-conn-gpio driver. Just add a compatible string for you
> switch.
>
Got it. So the "usb_conn_gpio: usb-conn-gpio" in [1] to be replaced
with something like a "typec- " naming convention and add a new
compatible to gpio-conn (something specific to qcom-qdu) and use it in
the new DT node.
Thanks for the suggestion. Is it fine if it put the whole of the above
text in v2 and push it for getting a new compatible added to connector
binding and usb-conn driver and then send v3 of DT changes or mix this
series with the DT series ?
[1]:
https://lore.kernel.org/all/20240319091020.15137-3-quic_kbajaj@quicinc.com/
Thanks,
Krishna,
>>
>> Hope this answers the query as to why we wanted to use usb-conn-gpio
>> and why we were trying to add a new compatible.
>>
>> Regards,
>> Krishna,
>>
>>>>
>>>> This series intends to add that compatible in driver and bindings
>>>> so that it can be used in QDU1000 IDP DT.
>>>>
>>>> [1]: https://lore.kernel.org/all/20240319091020.15137-3-quic_kbajaj@quicinc.com/
>>>> [2]: https://lore.kernel.org/all/CAA8EJprXPvji8TgZu1idH7y4GtHtD4VmQABFBcRt-9BQaCberg@mail.gmail.com/
>>>>
>>>> Krishna Kurapati (2):
>>>> dt-bindings: connector: Add gpio-usb-c-connector compatible
>>>> usb: common: usb-conn-gpio: Update ID table to add usb-c connector
>>>>
>>>> Documentation/devicetree/bindings/connector/usb-connector.yaml | 3 +++
>>>> drivers/usb/common/usb-conn-gpio.c | 1 +
>>>> 2 files changed, 4 insertions(+)
>>>>
>>>> --
>>>> 2.34.1
>>>>
>>>
>>>
>>> --
>>> With best wishes
>>> Dmitry
>
>
>
X-sender: <linux-usb+bounces-8669-peter.schumann=secunet.com@vger.kernel.org>
X-Receiver: <peter.schumann@secunet.com> ORCPT=rfc822;peter.schumann@secunet.com
X-CreatedBy: MSExchange15
X-HeloDomain: mbx-dresden-01.secunet.de
X-ExtendedProps: BQBjAAoAtI6mlidQ3AgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwA/AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5EaXJlY3RvcnlEYXRhLk1haWxEZWxpdmVyeVByaW9yaXR5DwADAAAATG93
X-Source: SMTP:Default MBX-ESSEN-02
X-SourceIPAddress: 10.53.40.199
X-EndOfInjectedXHeaders: 15862
Received: from mbx-dresden-01.secunet.de (10.53.40.199) by
mbx-essen-02.secunet.de (10.53.40.198) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2507.37; Sat, 30 Mar 2024 14:47:01 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-02.secunet.de
(10.53.40.202) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
Transport; Sat, 30 Mar 2024 14:47:01 +0100
Received: from localhost (localhost [127.0.0.1])
by b.mx.secunet.com (Postfix) with ESMTP id 2FFD720322
for <peter.schumann@secunet.com>; Sat, 30 Mar 2024 14:47:01 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=2.1
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: a.mx.secunet.com (amavisd-new);
dkim=pass (2048-bit key) header.d=quicinc.com
Received: from b.mx.secunet.com ([127.0.0.1])
by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id YL3VWx9f9dzH for <peter.schumann@secunet.com>;
Sat, 30 Mar 2024 14:46:56 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=147.75.80.249; helo=am.mirrors.kernel.org; envelope-from=linux-usb+bounces-8669-peter.schumann=secunet.com@vger.kernel.org; receiver=peter.schumann@secunet.com
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com A5E902025D
Authentication-Results: b.mx.secunet.com;
dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b="GV1ze4/b"
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by b.mx.secunet.com (Postfix) with ESMTPS id A5E902025D
for <peter.schumann@secunet.com>; Sat, 30 Mar 2024 14:46:56 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id 899CB1F21F40
for <peter.schumann@secunet.com>; Sat, 30 Mar 2024 13:46:55 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id D4F102E3E4;
Sat, 30 Mar 2024 13:46:44 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b="GV1ze4/b"
X-Original-To: linux-usb@vger.kernel.org
Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by smtp.subspace.kernel.org (Postfix) with ESMTPS id 67F3F2F2F;
Sat, 30 Mar 2024 13:46:42 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1711806404; cv=none; b=PRurmsWyDKad109HsbgKEUxlNZ5muTPP2EUI6gbKerhmX8xRq+vhVJj645342XrQ79TcR62BMaPRCNobetjitOXD/HaefdR1brXHz1c1gQ0eAzEFMdDGylsRE8MbdjyfNWIRqMxCI6pLHQX1ZGzzz5ccxBuuLGM7nIGSe3mffwY=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1711806404; c=relaxed/simple;
bh=Ns/3qZvk6Me7y5ToeEB/QaAzO9OBzvqWe05LErgFeME=;
h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From:
In-Reply-To:Content-Type; b=IevWMIu+6JH6YGWVlA+zAzvV6ltO79Jyuh7WxBaNMxDaVmtNA8Zxx5Pb2vdrgRHhPOuXtdbSl3HEk5pM3i6C5gV2xwDM3kROsApDDia5YO7iY5LAGLnl8TOQSaGaw8vXOLxDRsAjHCbmH31TuD1SM5X/h+XzUjyUCn33b+V7Rg4=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com; spf=pass smtp.mailfrom=quicinc.com; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b=GV1ze4/b; arc=none smtp.client-ip=205.220.180.131
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=quicinc.com
Received: from pps.filterd (m0279870.ppops.net [127.0.0.1])
by mx0a-0031df01.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 42UDgTsr003435;
Sat, 30 Mar 2024 13:46:10 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=
message-id:date:mime-version:subject:to:cc:references:from
:in-reply-to:content-type:content-transfer-encoding; s=
qcppdkim1; bh=SVWFHV4sqPFX76VmpS4jxlnWZQYsLMqwWZI1Sedjiao=; b=GV
1ze4/bvO54xknN6187ZJoKwvSkJrP1fqKpvr4ADOWvevrSjhHPar1y8mcA8Twwhc
xD4abPcm2FjyqM32o6qCDmE9lqU0v7vUJEQnlmf1XJzGBFnD6imcS6k5S4hnNtvs
S4I1p8+TaIEAlIvEojW6pwPMzKmaG1V8mIQiUMPcJsenDIgeCzvy3foYXkpMUHng
07Ym5vkEdaBnThnaQMY+RnJhiM8uDCoOiPlWb4y+cniaP4cNaWZHEBuOvByzDSik
eDcgPwrVKailgG8FheazZUQMh0ZVHtaV1v4fGkvhrN7NE40uDPiP2vYHWPdl3RJ6
JLulBlELV8AFumUTY+4g==
Received: from nalasppmta02.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20])
by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3x6atwgwsk-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Sat, 30 Mar 2024 13:46:09 +0000 (GMT)
Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196])
by NALASPPMTA02.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 42UDk8Rv024225
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Sat, 30 Mar 2024 13:46:08 GMT
Received: from [10.216.59.24] (10.80.80.8) by nalasex01a.na.qualcomm.com
(10.47.209.196) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.40; Sat, 30 Mar
2024 06:46:02 -0700
Message-ID: <44bc6ea4-eba9-4b80-bb07-3b744eb7cce6@quicinc.com>
Date: Sat, 30 Mar 2024 19:15:57 +0530
Precedence: bulk
X-Mailing-List: linux-usb@vger.kernel.org
List-Id: <linux-usb.vger.kernel.org>
List-Subscribe: <mailto:linux-usb+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-usb+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH 0/2] Add gpio-usb-c-connector compatible
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
CC: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski
<krzysztof.kozlowski+dt@linaro.org>,
Greg Kroah-Hartman
<gregkh@linuxfoundation.org>,
Conor Dooley <conor+dt@kernel.org>,
"Miquel
Raynal" <miquel.raynal@bootlin.com>,
Guenter Roeck <linux@roeck-us.net>,
"Bjorn Helgaas" <bhelgaas@google.com>, Kyle Tso <kyletso@google.com>,
Fabrice
Gasnier <fabrice.gasnier@foss.st.com>,
Heikki Krogerus
<heikki.krogerus@linux.intel.com>,
<u.kleine-koenig@pengutronix.de>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>,
<devicetree@vger.kernel.org>, <linux-usb@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <quic_ppratap@quicinc.com>,
<quic_jackp@quicinc.com>
References: <20240329071948.3101882-1-quic_kriskura@quicinc.com>
<CAA8EJpqx+VFW8z6oG=+pnhPN97Q3R6z+ygf85Uspve-9syQsUw@mail.gmail.com>
<6f2df222-36d4-468e-99a7-9c48fae85aa9@quicinc.com>
<CAA8EJppa4hVBSenLgxc5MYxTfzPPf4exHvh8RWTP=p8mgB_RCw@mail.gmail.com>
Content-Language: en-US
From: Krishna Kurapati PSSNV <quic_kriskura@quicinc.com>
In-Reply-To: <CAA8EJppa4hVBSenLgxc5MYxTfzPPf4exHvh8RWTP=p8mgB_RCw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To
nalasex01a.na.qualcomm.com (10.47.209.196)
X-QCInternal: smtphost
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085
X-Proofpoint-GUID: i-7mgUWTKegtutg-30OaQLWt41ipl3Tl
X-Proofpoint-ORIG-GUID: i-7mgUWTKegtutg-30OaQLWt41ipl3Tl
X-Proofpoint-Virus-Version: vendor=baseguard
engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
definitions=2024-03-30_08,2024-03-28_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 clxscore=1015
adultscore=0 priorityscore=1501 bulkscore=0 mlxscore=0 mlxlogscore=999
impostorscore=0 spamscore=0 malwarescore=0 phishscore=0 lowpriorityscore=0
classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2403210001
definitions=main-2403300112
Return-Path: linux-usb+bounces-8669-peter.schumann=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 30 Mar 2024 13:47:01.2412
(UTC)
X-MS-Exchange-Organization-Network-Message-Id: efeb8251-5d13-4486-56c4-08dc50bfe055
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.202
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-02.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=cas-essen-02.secunet.de:TOTAL-FE=0.025|SMR=0.024(SMRPI=0.022(SMRPI-FrontendProxyAgent=0.022));2024-03-30T13:47:01.266Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-essen-02.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-02.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-OriginalSize: 15313
X-MS-Exchange-Organization-Transport-Properties: DeliveryPriority=Low
X-MS-Exchange-Organization-Prioritization: 2:ShadowRedundancy
X-MS-Exchange-Organization-IncludeInSla: False:ShadowRedundancy
On 3/30/2024 7:09 PM, Dmitry Baryshkov wrote:
> On Sat, 30 Mar 2024 at 11:13, Krishna Kurapati PSSNV
> <quic_kriskura@quicinc.com> wrote:
>> On 3/29/2024 6:23 PM, Dmitry Baryshkov wrote:
>>> On Fri, 29 Mar 2024 at 09:20, Krishna Kurapati
>>> <quic_kriskura@quicinc.com> wrote:
>>>>
>>>> QDU1000 IDP [1] has a Type-c connector and supports USB 3.0.
>>>> However it relies on usb-conn-gpio driver to read the vbus and id
>>>> gpio's and provide role switch. However the driver currently has
>>>> only gpio-b-connector compatible present in ID table. Adding that
>>>> in DT would mean that the device supports Type-B connector and not
>>>> Type-c connector. Thanks to Dmitry Baryshkov for pointing it out [2].
>>>
>>> USB-B connector is pretty simple, it really has just an ID pin and
>>> VBUS input, which translates to two GPIOs being routed from the
>>> _connector_ itself.
>>>
>>> USB-C is much more complicated, it has two CC pins and a VBus power
>>> pin. It is not enough just to measure CC pin levels. Moreover,
>>> properly handling USB 3.0 inside a USB-C connector requires a separate
>>> 'orientation' signal to tell the host which two lanes must be used for
>>> the USB SS signals. Thus it is no longer possible to route just two
>>> pins from the connector to the SoC.
>>>
>>> Having all that in mind, I suspect that you are not describing your
>>> hardware properly. I suppose that you have a Type-C port controller /
>>> redriver / switch, which handles CC lines communication and then
>>> provides ID / VBUS signals to the host. In such a case, please
>>> describe this TCPC in the DT file and use its compatible string
>>> instead of "gpio-c-connector".
>>>
>>
>> Hi Dmitry,
>>
>> My bad. I must have provided more details of the HW.
>>
>> I presume you are referring to addition of a connector node, type-c
>> switch, pmic-glink and other remote endpoints like in other SoC's like
>> SM8450/ SM8550/ SM8650.
>>
>> This HW is slightly different. It has a Uni Phy for Super speed and
>> hence no DP.
>
> This is fine and it's irrelevant for the USB-C.
>
>> For orientation switching, on mobile SoC's, there is a provision for
>> orientation gpio given in pmic-glink node and is handled in ucsi_glink
>> driver. But on this version of HW, there is a USB-C Switch with its own
>> firmware taking care of orientation switching. It takes 8 SS Lines and 2
>> CC lines coming from connector as input and gives out 4 SS Lines (SS
>> TX1/TX2 RX1/RX2) as output which go to the SoC. So orientation switch is
>> done by the USB-C-switch in between and it automatically routes
>> appropriate active SS Lane from connector to the SoC.
>
> This is also fine. As I wrote, you _have_ the Type-C port controller.
> So your DT file should be describing your hardware.
>
>> As usual like in other targets, the DP and DM lines from type-c
>> connector go to the SoC directly.
>>
>> To handle role switch, the VBUS and ID Pin connections are given to
>> SoC as well. There is a vbus controller regulator present to provide
>> vbus to connected peripherals in host mode.
>>
>> There is no PPM entity (ADSP in mobile SoC's) and no UCSI involved
>> here. Hence we rely on usb-conn-gpio to read the vbus/id and switch
>> roles accordingly.
>
> This is also fine.
>
> You confirmed my suspicions. You have an external Type-C switch which
> handles orientation (and most likely PD or non-PD power negotiation)
> for you. It has GPIO outputs, etc.
>
> But it is not a part of the connector. Instead of adding the
> "gpio-usb-c-connector", add proper compatible string (see, how this is
> handled e.g. by the spidev - it is a generic driver, but it requires
> hardware-specific compatibles).
> Your hardware description should look like:
>
> typec {
> compatible = "your,switch";
> id-gpios = <&gpio 1>;
> vbus-gpios = <&gpio 2>;
> vbus-supplies = <®-vbus>;
>
> ports {
> #address-cells = <1>;
> #size-cells = <1>;
> port@0 {
> endpoint {
> remote-endpoint = <&usb_dwc3_hs_out>;
> };
> };
> port@1 {
> endpoint {
> remote-endpoint = <&usb_uni_phy_out>;
> };
> };
> /* No SBU port */
> };
> };
> > Note, I haven't said anything regarding the driver. You can continue
> using the usb-conn-gpio driver. Just add a compatible string for you
> switch.
>
Got it. So the "usb_conn_gpio: usb-conn-gpio" in [1] to be replaced
with something like a "typec- " naming convention and add a new
compatible to gpio-conn (something specific to qcom-qdu) and use it in
the new DT node.
Thanks for the suggestion. Is it fine if it put the whole of the above
text in v2 and push it for getting a new compatible added to connector
binding and usb-conn driver and then send v3 of DT changes or mix this
series with the DT series ?
[1]:
https://lore.kernel.org/all/20240319091020.15137-3-quic_kbajaj@quicinc.com/
Thanks,
Krishna,
>>
>> Hope this answers the query as to why we wanted to use usb-conn-gpio
>> and why we were trying to add a new compatible.
>>
>> Regards,
>> Krishna,
>>
>>>>
>>>> This series intends to add that compatible in driver and bindings
>>>> so that it can be used in QDU1000 IDP DT.
>>>>
>>>> [1]: https://lore.kernel.org/all/20240319091020.15137-3-quic_kbajaj@quicinc.com/
>>>> [2]: https://lore.kernel.org/all/CAA8EJprXPvji8TgZu1idH7y4GtHtD4VmQABFBcRt-9BQaCberg@mail.gmail.com/
>>>>
>>>> Krishna Kurapati (2):
>>>> dt-bindings: connector: Add gpio-usb-c-connector compatible
>>>> usb: common: usb-conn-gpio: Update ID table to add usb-c connector
>>>>
>>>> Documentation/devicetree/bindings/connector/usb-connector.yaml | 3 +++
>>>> drivers/usb/common/usb-conn-gpio.c | 1 +
>>>> 2 files changed, 4 insertions(+)
>>>>
>>>> --
>>>> 2.34.1
>>>>
>>>
>>>
>>> --
>>> With best wishes
>>> Dmitry
>
>
>
^ permalink raw reply
* [PATCH v2] dt-bindings: usb: qcom,pmic-typec: update example to follow connector schema
From: Dmitry Baryshkov @ 2024-03-30 22:21 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Bryan O'Donoghue,
Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-usb, devicetree, linux-kernel, Luca Weiss,
Dmitry Baryshkov
Update Qualcomm PMIC Type-C examples to follow the USB-C connector
schema. The USB-C connector should have three ports (USB HS @0,
SSTX/RX @1 and SBU @2 lanes). Reorder ports accordingly and add SBU port
connected to the SBU mux (e.g. FSA4480).
Fixes: 00bb478b829e ("dt-bindings: usb: Add Qualcomm PMIC Type-C")
Reported-by: Luca Weiss <luca.weiss@fairphone.com>
Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
Update examples to follow usb-c-connector schema wrt. ports definitions.
---
Changes in v2:
- Dropped patch removing the role-switching port. We do not use it, but
it can become useful by other designs.
- Link to v1: https://lore.kernel.org/r/20240322-typec-fix-example-v1-0-6b01c347419e@linaro.org
---
.../devicetree/bindings/usb/qcom,pmic-typec.yaml | 34 +++++++++++++++++-----
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
index d9694570c419..fe757619e535 100644
--- a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
@@ -192,15 +192,22 @@ examples:
port@0 {
reg = <0>;
- pmic_typec_mux_out: endpoint {
- remote-endpoint = <&usb_phy_typec_mux_in>;
+ pmic_typec_hs_in: endpoint {
+ remote-endpoint = <&usb_hs_out>;
};
};
port@1 {
reg = <1>;
- pmic_typec_role_switch_out: endpoint {
- remote-endpoint = <&usb_role_switch_in>;
+ pmic_typec_ss_in: endpoint {
+ remote-endpoint = <&usb_phy_typec_ss_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ pmic_typec_sbu: endpoint {
+ remote-endpoint = <&usb_mux_sbu>;
};
};
};
@@ -212,8 +219,8 @@ examples:
dr_mode = "otg";
usb-role-switch;
port {
- usb_role_switch_in: endpoint {
- remote-endpoint = <&pmic_typec_role_switch_out>;
+ usb_hs_out: endpoint {
+ remote-endpoint = <&pmic_typec_hs_in>;
};
};
};
@@ -221,8 +228,19 @@ examples:
usb-phy {
orientation-switch;
port {
- usb_phy_typec_mux_in: endpoint {
- remote-endpoint = <&pmic_typec_mux_out>;
+ usb_phy_typec_ss_out: endpoint {
+ remote-endpoint = <&pmic_typec_ss_in>;
+ };
+ };
+ };
+
+ usb-mux {
+ orientation-switch;
+ mode-switch;
+
+ port {
+ usb_mux_sbu: endpoint {
+ remote-endpoint = <&pmic_typec_sbu>;
};
};
};
---
base-commit: 13ee4a7161b6fd938aef6688ff43b163f6d83e37
change-id: 20240322-typec-fix-example-3d9b1eca853d
Best regards,
--
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
X-sender: <linux-kernel+bounces-125900-steffen.klassert=secunet.com@vger.kernel.org>
X-Receiver: <steffen.klassert@secunet.com> ORCPT=rfc822;steffen.klassert@secunet.com
X-CreatedBy: MSExchange15
X-HeloDomain: mbx-dresden-01.secunet.de
X-ExtendedProps: BQBjAAoAlmUFfe5Q3AgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwA/AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5EaXJlY3RvcnlEYXRhLk1haWxEZWxpdmVyeVByaW9yaXR5DwADAAAATG93
X-Source: SMTP:Default MBX-ESSEN-02
X-SourceIPAddress: 10.53.40.199
X-EndOfInjectedXHeaders: 13579
Received: from mbx-dresden-01.secunet.de (10.53.40.199) by
mbx-essen-02.secunet.de (10.53.40.198) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2507.37; Sat, 30 Mar 2024 23:21:44 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-02.secunet.de
(10.53.40.202) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.37 via Frontend
Transport; Sat, 30 Mar 2024 23:21:43 +0100
Received: from localhost (localhost [127.0.0.1])
by b.mx.secunet.com (Postfix) with ESMTP id ACA1220322
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 23:21:43 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -5.051
X-Spam-Level:
X-Spam-Status: No, score=-5.051 tagged_above=-999 required=2.1
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: a.mx.secunet.com (amavisd-new);
dkim=pass (2048-bit key) header.d=linaro.org
Received: from b.mx.secunet.com ([127.0.0.1])
by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id llastv2nJa3W for <steffen.klassert@secunet.com>;
Sat, 30 Mar 2024 23:21:39 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=139.178.88.99; helo=sv.mirrors.kernel.org; envelope-from=linux-kernel+bounces-125900-steffen.klassert=secunet.com@vger.kernel.org; receiver=steffen.klassert@secunet.com
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com F20042025D
Authentication-Results: b.mx.secunet.com;
dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="S7jYKe8m"
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by b.mx.secunet.com (Postfix) with ESMTPS id F20042025D
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 23:21:38 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id AB99C282E05
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 22:21:36 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 44F5851C2B;
Sat, 30 Mar 2024 22:21:23 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="S7jYKe8m"
Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by smtp.subspace.kernel.org (Postfix) with ESMTPS id B9CB14AEFE
for <linux-kernel@vger.kernel.org>; Sat, 30 Mar 2024 22:21:18 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.53
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1711837280; cv=none; b=XKrIEzcBkBL/hOcL+PegxyE/vNWdtHdDuwO1xpeEiAC6t4vXH2B0UDw/C3b8f0+NEAgaJlQK5NXB6ryHa+1pQbPePD7rFvyDPFh5CQ1Ppc7cZKOYcoOucML5+ZWoBRZOs4yWFiVG+wg2IF6INfMBNjCHeRkOCCMyDi6yvQOp+h0=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1711837280; c=relaxed/simple;
bh=Oc9kcICFBM05I/E/I4AVoBzP2f/9gloPVHobW/2H4Sc=;
h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=YQTKIydBv76w12PvQhQQjI3DwHzqSpM+qMI2Z3QxqmwQdMF3YTDwNH67P4SjyWtoplJqTmpRLxFipCb1aKTSu2Tit/R+ldwYxjHREmtGRyPG1Bu7js/BfhkXMeNEZU+WP2gHR/1YxGBxjv+lG978wlt8TkLWc7IxAoDpLRU/dko=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=S7jYKe8m; arc=none smtp.client-ip=209.85.167.53
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org
Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-515b43b39fdso2560628e87.1
for <linux-kernel@vger.kernel.org>; Sat, 30 Mar 2024 15:21:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=linaro.org; s=google; t=1711837277; x=1712442077; darn=vger.kernel.org;
h=cc:to:message-id:content-transfer-encoding:mime-version:subject
:date:from:from:to:cc:subject:date:message-id:reply-to;
bh=0XPGOUCDwaV1EzZ064paZOD8RnQFs1ddJgtwbPEEUz4=;
b=S7jYKe8msBG0Hsn9CYMRKdMJJSwT1C1KDhNhWuJJHVT+tL8mNXWKFyF+N0xZnPGV7w
Bk395XN7yob2caKMRGEHJe6VxJAokee7Kuj72ZuuItUajPwWtTCX/PtXOjRFqsIhxjts
WKUR6aB21G3DVDKrpcp8XrK9Cxw26zWJvuIGkjkr16KV03F3awH9lwtKlw4fenCUcdO3
LU3p253gOI4kwjlGq6OetGqNdKqLFLukYdPM/lNlK7YfHvzfBF8Z5O570IQA8o7szYfn
WLR+DJOlOy6aCjAf/IRfozcLCEQurAHZMiYsp9nOqaxvRboDSJywiCRgfsnf4iyxjfLJ
UmHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1711837277; x=1712442077;
h=cc:to:message-id:content-transfer-encoding:mime-version:subject
:date:from:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=0XPGOUCDwaV1EzZ064paZOD8RnQFs1ddJgtwbPEEUz4=;
b=xOoYGllKePqUWaEBrRT6/3vclrcBPNz0xLPua3A1z/NguIMM49lSPS3HJ027Quy0MM
+r3UsVk94vQ3FBH2XPHpauwRvZwq0wQ6u8uItwHEgu9kclNYDkraRHhzxKWjW/qTTS+Y
o634mb1Aig8HS7fy67clvSnFxw8BAz7iNimpw6Ag2FxWTWgAiM+hzApRtRrMWdRpkeIV
bWRRRyuiITxiHBVKsF5Aruhuz1YXQIDzNbtEK3Dc8Pesz8Nya5ZTT6TxwMjfeEH7Y1ga
UXzqFlwq5OMDBhDT20B/wCmbsj2P8K9e+5uqcuTsaYtxNRGwsqwyc74z51AszgXjh/Vj
N3IA==
X-Forwarded-Encrypted: i=1; AJvYcCX7ya2Zl7cM1YAYRL/4YZRdDSjjSlP4fA8VoE4naRClKtBdM80VOqG8H8JY5gs0uIefefYiFTD3rPwNsGyOgAkHYrdabBIERoDtpR8b
X-Gm-Message-State: AOJu0YwjeEq9ll8717JTBIAGV56NKsvyka31BH5MCNmxe+l2M/d490bL
4O/2boJ7myuJCoVeC293QfGBuDPNY2VtkTZuqtProgqc9L+/Y/G+7eQUnpJV1c0=
X-Google-Smtp-Source: AGHT+IF+x3Qdox2g6SjvSt6ZfLOJ3gFe7c5YL+555P/qahnN8Eg7hcDHoGbL+RaMts29GpUddkiBTg==
X-Received: by 2002:a05:6512:3d1b:b0:516:9f65:fcf with SMTP id d27-20020a0565123d1b00b005169f650fcfmr965650lfv.26.1711837276931;
Sat, 30 Mar 2024 15:21:16 -0700 (PDT)
Received: from umbar.lan ([192.130.178.91])
by smtp.gmail.com with ESMTPSA id j18-20020a056512399200b00514b6e2fd49sm993992lfu.169.2024.03.30.15.21.16
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 30 Mar 2024 15:21:16 -0700 (PDT)
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date: Sun, 31 Mar 2024 00:21:15 +0200
Subject: [PATCH v2] dt-bindings: usb: qcom,pmic-typec: update example to
follow connector schema
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20240331-typec-fix-example-v2-1-f56fffe4f37c@linaro.org>
X-B4-Tracking: v=1; b=H4sIAFqQCGYC/32NSQ6DMBAEv4LmnIm8kIWc8o+Ig7EnMBKxLRshE
OLvcXhAjtWtrt4gU2LK8Kg2SDRz5uALqFMFdjC+J2RXGJRQtdBK4bRGsvjmBWkxnzgSatd0kqy
5X7SDsouJSn04X23hgfMU0npczPKX/rPNEgVeOyGtrm+1bOg5sjcpnEPqod33/QuTXSVvswAAA
A==
To: Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>,
Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>
Cc: linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Luca Weiss <luca.weiss@fairphone.com>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
X-Mailer: b4 0.13.0
X-Developer-Signature: v=1; a=openpgp-sha256; l=3401;
i=dmitry.baryshkov@linaro.org; h=from:subject:message-id;
bh=Oc9kcICFBM05I/E/I4AVoBzP2f/9gloPVHobW/2H4Sc=;
b=owEBbQGS/pANAwAKAYs8ij4CKSjVAcsmYgBmCJBcricaIiHddrBejVu6XApq90lPrz+UyzOaL
MmslELd922JATMEAAEKAB0WIQRMcISVXLJjVvC4lX+LPIo+Aiko1QUCZgiQXAAKCRCLPIo+Aiko
1SnyCACjI3jZcyF8lv/PfbC7h7LpkxjJVFoEqIGjQQ0uJNVnplc27e2UQGG1fpyLbbDQgQEUwP3
rmurUTUJveKBLHSQJ1fs80Qe9/ZNBZ2YLRBE/vEA5u/RXkKoGSiSgOlSbLk4i2IfXTXWPKHsAyz
84sJQUpm5yIxaBu8NrAeYw0NnaoMBJEVcJsgrDuGpKUUUhB7FW8fApu+0yroEiMyrtN63xcUV2v
O2bGuho1A5A6REMw/Xtdr15nkzJC6mbjYg6PxDPL+qy61fuiLlzvN0XxZ/N60JZf39D5ne95O7k
euRzdwIcCJFYFyYsOMyDhOhTuzIBm0hasGa5sU32VgH8Umna
X-Developer-Key: i=dmitry.baryshkov@linaro.org; a=openpgp;
fpr=8F88381DD5C873E4AE487DA5199BF1243632046A
Return-Path: linux-kernel+bounces-125900-steffen.klassert=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 30 Mar 2024 22:21:43.8207
(UTC)
X-MS-Exchange-Organization-Network-Message-Id: 201822ae-4eca-4fcf-da6e-08dc5107c7c8
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.202
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-02.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=cas-essen-02.secunet.de:TOTAL-FE=0.023|SMR=0.023(SMRPI=0.021(SMRPI-FrontendProxyAgent=0.021));2024-03-30T22:21:43.843Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-essen-02.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-02.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-OriginalSize: 13032
X-MS-Exchange-Organization-Transport-Properties: DeliveryPriority=Low
X-MS-Exchange-Organization-Prioritization: 2:ShadowRedundancy
X-MS-Exchange-Organization-IncludeInSla: False:ShadowRedundancy
Update Qualcomm PMIC Type-C examples to follow the USB-C connector
schema. The USB-C connector should have three ports (USB HS @0,
SSTX/RX @1 and SBU @2 lanes). Reorder ports accordingly and add SBU port
connected to the SBU mux (e.g. FSA4480).
Fixes: 00bb478b829e ("dt-bindings: usb: Add Qualcomm PMIC Type-C")
Reported-by: Luca Weiss <luca.weiss@fairphone.com>
Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
Update examples to follow usb-c-connector schema wrt. ports definitions.
---
Changes in v2:
- Dropped patch removing the role-switching port. We do not use it, but
it can become useful by other designs.
- Link to v1: https://lore.kernel.org/r/20240322-typec-fix-example-v1-0-6b01c347419e@linaro.org
---
.../devicetree/bindings/usb/qcom,pmic-typec.yaml | 34 +++++++++++++++++-----
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
index d9694570c419..fe757619e535 100644
--- a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
@@ -192,15 +192,22 @@ examples:
port@0 {
reg = <0>;
- pmic_typec_mux_out: endpoint {
- remote-endpoint = <&usb_phy_typec_mux_in>;
+ pmic_typec_hs_in: endpoint {
+ remote-endpoint = <&usb_hs_out>;
};
};
port@1 {
reg = <1>;
- pmic_typec_role_switch_out: endpoint {
- remote-endpoint = <&usb_role_switch_in>;
+ pmic_typec_ss_in: endpoint {
+ remote-endpoint = <&usb_phy_typec_ss_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ pmic_typec_sbu: endpoint {
+ remote-endpoint = <&usb_mux_sbu>;
};
};
};
@@ -212,8 +219,8 @@ examples:
dr_mode = "otg";
usb-role-switch;
port {
- usb_role_switch_in: endpoint {
- remote-endpoint = <&pmic_typec_role_switch_out>;
+ usb_hs_out: endpoint {
+ remote-endpoint = <&pmic_typec_hs_in>;
};
};
};
@@ -221,8 +228,19 @@ examples:
usb-phy {
orientation-switch;
port {
- usb_phy_typec_mux_in: endpoint {
- remote-endpoint = <&pmic_typec_mux_out>;
+ usb_phy_typec_ss_out: endpoint {
+ remote-endpoint = <&pmic_typec_ss_in>;
+ };
+ };
+ };
+
+ usb-mux {
+ orientation-switch;
+ mode-switch;
+
+ port {
+ usb_mux_sbu: endpoint {
+ remote-endpoint = <&pmic_typec_sbu>;
};
};
};
---
base-commit: 13ee4a7161b6fd938aef6688ff43b163f6d83e37
change-id: 20240322-typec-fix-example-3d9b1eca853d
Best regards,
--
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
^ permalink raw reply related
* [net-next,v2] dt-bindings: net: renesas,ethertsn: Create child-node for MDIO bus
From: Niklas Söderlund @ 2024-03-30 13:12 UTC (permalink / raw)
To: Sergey Shtylyov, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, netdev, devicetree
Cc: linux-renesas-soc, Niklas Söderlund, Rob Herring
The bindings for Renesas Ethernet TSN was just merged in v6.9 and the
design for the bindings followed that of other Renesas Ethernet drivers
and thus did not force a child-node for the MDIO bus. As there
are no upstream drivers or users of this binding yet take the
opportunity to correct this and force the usage of a child-node for the
MDIO bus.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Rob Herring <robh@kernel.org>
---
* Changes since v1
- Expand on history in commit message.
Hello,
The Ethernet TSN driver is still in review and have not been merged and
no usage of the bindings are merged either. So while this breaks the
binding it effects no one. So we can correct this mistake without
breaking any use-cases before we need to support any backward
compatibility.
---
.../bindings/net/renesas,ethertsn.yaml | 33 ++++++++-----------
1 file changed, 14 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml b/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml
index ea35d19be829..b4680a1d0a06 100644
--- a/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml
+++ b/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml
@@ -71,16 +71,8 @@ properties:
enum: [0, 2000]
default: 0
- '#address-cells':
- const: 1
-
- '#size-cells':
- const: 0
-
-patternProperties:
- "^ethernet-phy@[0-9a-f]$":
- type: object
- $ref: ethernet-phy.yaml#
+ mdio:
+ $ref: /schemas/net/mdio.yaml#
unevaluatedProperties: false
required:
@@ -94,8 +86,7 @@ required:
- resets
- phy-mode
- phy-handle
- - '#address-cells'
- - '#size-cells'
+ - mdio
additionalProperties: false
@@ -122,14 +113,18 @@ examples:
tx-internal-delay-ps = <2000>;
phy-handle = <&phy3>;
- #address-cells = <1>;
- #size-cells = <0>;
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
- phy3: ethernet-phy@3 {
- compatible = "ethernet-phy-ieee802.3-c45";
- reg = <0>;
- interrupt-parent = <&gpio4>;
- interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
reset-gpios = <&gpio1 23 GPIO_ACTIVE_LOW>;
+ reset-post-delay-us = <4000>;
+
+ phy3: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+ };
};
};
--
2.44.0
X-sender: <netdev+bounces-83505-steffen.klassert=secunet.com@vger.kernel.org>
X-Receiver: <steffen.klassert@secunet.com> ORCPT=rfc822;steffen.klassert@secunet.com NOTIFY=NEVER; X-ExtendedProps=BQAVABYAAgAAAAUAFAARAPDFCS25BAlDktII2g02frgPADUAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0LkRpcmVjdG9yeURhdGEuSXNSZXNvdXJjZQIAAAUAagAJAAEAAAAAAAAABQAWAAIAAAUAQwACAAAFAEYABwADAAAABQBHAAIAAAUAEgAPAGIAAAAvbz1zZWN1bmV0L291PUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpL2NuPVJlY2lwaWVudHMvY249U3RlZmZlbiBLbGFzc2VydDY4YwUACwAXAL4AAACheZxkHSGBRqAcAp3ukbifQ049REI2LENOPURhdGFiYXNlcyxDTj1FeGNoYW5nZSBBZG1pbmlzdHJhdGl2ZSBHcm91cCAoRllESUJPSEYyM1NQRExUKSxDTj1BZG1pbmlzdHJhdGl2ZSBHcm91cHMsQ049c2VjdW5ldCxDTj1NaWNyb3NvZnQgRXhjaGFuZ2UsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1zZWN1bmV0LERDPWRlBQAOABEABiAS9uuMOkqzwmEZDvWNNQUAHQAPAAwAAABtYngtZXNzZW4tMDIFADwAAgAADwA2AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50LkRpc3BsYXlOYW1lDwARAAAAS2xhc3NlcnQsIFN0ZWZmZW4FAAwAAgAABQBsAAIAAAUAWAAXAEoAAADwxQktuQQJQ5LSCNoNNn64Q049S2xhc3NlcnQgU3RlZmZlbixPVT1Vc2VycyxPVT1NaWdyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUAJgACAAEFACIADwAxAAAAQXV0b1Jlc3BvbnNlU3VwcHJlc3M6IDANClRyYW5zbWl0SGlzdG9yeTogRmFsc2UNCg8ALwAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuRXhwYW5zaW9uR3JvdXBUeXBlDwAVAAAATWVtYmVyc0dyb3VwRXhwYW5zaW9uBQAjAAIAAQ==
X-CreatedBy: MSExchange15
X-HeloDomain: a.mx.secunet.com
X-ExtendedProps: BQBjAAoAxI2mlidQ3AgFAGEACAABAAAABQA3AAIAAA8APAAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5Pcmdhbml6YXRpb25TY29wZREAAAAAAAAAAAAAAAAAAAAAAAUASQACAAEFAAQAFCABAAAAHAAAAHN0ZWZmZW4ua2xhc3NlcnRAc2VjdW5ldC5jb20FAAYAAgABBQApAAIAAQ8ACQAAAENJQXVkaXRlZAIAAQUAAgAHAAEAAAAFAAMABwAAAAAABQAFAAIAAQUAYgAKACIAAADcigAABQBkAA8AAwAAAEh1Yg==
X-Source: SMTP:Default MBX-ESSEN-02
X-SourceIPAddress: 62.96.220.36
X-EndOfInjectedXHeaders: 19690
Received: from cas-essen-01.secunet.de (10.53.40.201) by
mbx-essen-02.secunet.de (10.53.40.198) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2507.37; Sat, 30 Mar 2024 14:13:41 +0100
Received: from a.mx.secunet.com (62.96.220.36) by cas-essen-01.secunet.de
(10.53.40.201) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
Transport; Sat, 30 Mar 2024 14:13:41 +0100
Received: from localhost (localhost [127.0.0.1])
by a.mx.secunet.com (Postfix) with ESMTP id AD12520882
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 14:13:41 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -5.051
X-Spam-Level:
X-Spam-Status: No, score=-5.051 tagged_above=-999 required=2.1
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: a.mx.secunet.com (amavisd-new);
dkim=pass (2048-bit key) header.d=ragnatech.se header.b=s4j9+5zN;
dkim=pass (2048-bit key) header.d=messagingengine.com
header.b=T332CDzy
Received: from a.mx.secunet.com ([127.0.0.1])
by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id C1xSVlry9SmB for <steffen.klassert@secunet.com>;
Sat, 30 Mar 2024 14:13:38 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=139.178.88.99; helo=sv.mirrors.kernel.org; envelope-from=netdev+bounces-83505-steffen.klassert=secunet.com@vger.kernel.org; receiver=steffen.klassert@secunet.com
DKIM-Filter: OpenDKIM Filter v2.11.0 a.mx.secunet.com 6205620892
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by a.mx.secunet.com (Postfix) with ESMTPS id 6205620892
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 14:13:37 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 71FC028254E
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 13:13:35 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 4BAC721364;
Sat, 30 Mar 2024 13:13:30 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=ragnatech.se header.i=@ragnatech.se header.b="s4j9+5zN";
dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="T332CDzy"
X-Original-To: netdev@vger.kernel.org
Received: from flow7-smtp.messagingengine.com (flow7-smtp.messagingengine.com [103.168.172.142])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB0281FB5;
Sat, 30 Mar 2024 13:13:23 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.142
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1711804409; cv=none; b=X9Ltip7zthj9aqpST+wx2sE85OL4e1dv4iGo1bJYPymg4sFydx0aNaC8r9mlYq4oZ+aK1nNb60wrIfNHCYsMaHn2QMscWel8wPjEHYYTXdhB3Mim+UEjha/3Rmg1dZ4rwwroEppBzZ34ApMgzrX0xmAbn1zUmhCYqeNSSpo6xeY=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1711804409; c=relaxed/simple;
bh=oYWNSLB7Z3OmKkRKaMdt+xkwR1s947tnLcLU8T4RTrU=;
h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=A+MGrDpKH4eFNwmmnDrY1yESgFCJgICElw2WPUziiTdXmwB2ISQwVb7hH/l97xvffCiwww6oKpOwdB0NPFJy1pvwE9w2Mq2bxWN+/akEqJ3Iakn+HiBh2npfl0BkNlD56HZXD0Sl6Xn3vM7WN/hltLcAfIJifTTr7j3U+wOk7Bo=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ragnatech.se; spf=pass smtp.mailfrom=ragnatech.se; dkim=pass (2048-bit key) header.d=ragnatech.se header.i=@ragnatech.se header.b=s4j9+5zN; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=T332CDzy; arc=none smtp.client-ip=103.168.172.142
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ragnatech.se
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ragnatech.se
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
by mailflow.nyi.internal (Postfix) with ESMTP id 6C2B7200215;
Sat, 30 Mar 2024 09:13:22 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
by compute1.internal (MEProxy); Sat, 30 Mar 2024 09:13:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ragnatech.se; h=
cc:cc:content-transfer-encoding:content-type:content-type:date
:date:from:from:in-reply-to:message-id:mime-version:reply-to
:subject:subject:to:to; s=fm1; t=1711804402; x=1711808002; bh=DH
XZ2gkIcVCkQdzHyEOYWm/LRH13Sc+9ts+wLRwRTE4=; b=s4j9+5zN9N2Oy5Wqb8
16YQluyk3DEE+/Kc7VcyV7GgnsAFssOD6UUAWA+Duh9DzU8us0RWQXOyRlG0t3zu
RamIKWUeCeWsJDx576RlAlyJTizC+LcyOYC6ryhQInQs1Z5Jm5pizoOgA7S/2Kxt
oadd4N/6PqvO3k8TGhQPYND7U+QfJXoLSzMpMta2JxCjNqgZCVAW3XKB+GM3Kq2T
jMx5loESWFPVvAMnHRiWucQi4K9j2Ko1dW4SPvAUhAD38E9B6P3n8bvB7qI+lFhh
pkelvNpM+WDFc1PDK8cE675fUyfOefWpXED4t4j3p4b6EVRppehy09ZbQnhZR5C2
Ve6Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-transfer-encoding
:content-type:content-type:date:date:feedback-id:feedback-id
:from:from:in-reply-to:message-id:mime-version:reply-to:subject
:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
:x-sasl-enc; s=fm2; t=1711804402; x=1711808002; bh=DHXZ2gkIcVCkQ
dzHyEOYWm/LRH13Sc+9ts+wLRwRTE4=; b=T332CDzybdOPUGRlmaDKfrA1hAED8
gR/BWTgcmwkOe/U0VpYLzk9xYuAk6VTGkLsnEWGLhjRoC/XMUUniTgb3kqiruvuq
F4rbd5JEv0vF51iojqiXKcFZfk/+Mr/L55QxXJnQmLNBe8UvujFiVh3dT11+6JQz
4GCaFVLN2cfw2e+v4F/dY8uEHpwrzPBv1+qXaOW3VGRtDNAHf6Ut4yAkv0DpAspD
BGGHcitbs8HEgclm6wuf6oRUI+C4HzAR/Dj378Mdndd8jO8aQuyJpAZoNE4Xqw6z
ck2XDUP3emSCQRgNYP+aRF0jd7mPROuQfmrH9X3GydKvdKGtY/6QWp+7w==
X-ME-Sender: <xms:8Q8IZjvHBFzNn1XsPUf7WqtF07UZZ_NmTS5jiJ4juis3mqC1wrLB0Q>
<xme:8Q8IZkfyYZU63a5yS8cMODWdwY15vU400YDoTIjgrmlOvhynUcqRc0vcLufL1-NMi
9Byb-TOs-a_ztAhT9U>
X-ME-Received: <xmr:8Q8IZmxKNH0ANM3d0qv2nny-gXcdIMyFHRFheqQm3sbeFDgsiviqJSKv04R_IjXV1oNkiXw2WFzqYWtbKqIyd6pbY1e5-srewbSz>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddvhedgvdeiucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhephffvvefufffkofggtgfgsehtkeertdertdejnecuhfhrohhmpefpihhklhgr
shcuufpnuggvrhhluhhnugcuoehnihhklhgrshdrshhouggvrhhluhhnugdorhgvnhgvsh
grshesrhgrghhnrghtvggthhdrshgvqeenucggtffrrghtthgvrhhnpeehudelteetkefg
ffefudefuedvjeeivdekhfevieefgeffheeltddvvefhfeetgeenucevlhhushhtvghruf
hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnihhklhgrshdrshhouggvrhhl
uhhnugdorhgvnhgvshgrshesrhgrghhnrghtvggthhdrshgv
X-ME-Proxy: <xmx:8Q8IZiMklNKIFXsjhLoJVAWfsTb-331eBq9-kEyoKFUFmOWtPYZKiA>
<xmx:8Q8IZj-ZEqgeVBJ8_Q-WmARCvPkwyh0vg4Q4nNjuT21_PZh6wfDNEw>
<xmx:8Q8IZiV2lK7WlSjHPGsDZO-P0WfYli8i_iLmKSFo0HwI8uvZ7vpSgg>
<xmx:8Q8IZkcdFSrK11KRr6YFQM4t7f4h29wE6RPWj5-LGUXcCGWwBl0yhw>
<xmx:8g8IZnXEr36MyWR291UoN0yIS9SwkuBUHS348t3HJ8JIsheerXEJlpD3pRI>
Feedback-ID: i80c9496c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat,
30 Mar 2024 09:13:19 -0400 (EDT)
From: =?UTF-8?q?Niklas=20S=C3=B6derlund?= <niklas.soderlund+renesas@ragnatech.se>
To: Sergey Shtylyov <s.shtylyov@omp.ru>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
netdev@vger.kernel.org,
devicetree@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org,
=?UTF-8?q?Niklas=20S=C3=B6derlund?= <niklas.soderlund+renesas@ragnatech.se>,
Rob Herring <robh@kernel.org>
Subject: [net-next,v2] dt-bindings: net: renesas,ethertsn: Create child-node for MDIO bus
Date: Sat, 30 Mar 2024 14:12:28 +0100
Message-ID: <20240330131228.1541227-1-niklas.soderlund+renesas@ragnatech.se>
X-Mailer: git-send-email 2.44.0
Precedence: bulk
X-Mailing-List: netdev@vger.kernel.org
List-Id: <netdev.vger.kernel.org>
List-Subscribe: <mailto:netdev+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:netdev+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Return-Path: netdev+bounces-83505-steffen.klassert=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 30 Mar 2024 13:13:41.7275
(UTC)
X-MS-Exchange-Organization-Network-Message-Id: 6193e8d8-8759-4738-9ae1-08dc50bb3887
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.36
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.201
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-01.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=mbx-essen-02.secunet.de:TOTAL-HUB=0.214|SMR=0.139(SMRDE=0.005|SMRC=0.133(SMRCL=0.102|X-SMRCR=0.132))|CAT=0.075(CATOS=0.001
|CATRESL=0.024(CATRESLP2R=0.018)|CATORES=0.047(CATRS=0.047(CATRS-Transport
Rule Agent=0.001 (X-ETREX=0.001)|CATRS-Index Routing
Agent=0.044)));2024-03-30T13:13:41.957Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-essen-02.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-01.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-FromEntityHeader: Internet
X-MS-Exchange-Organization-OriginalSize: 12178
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageLatency: SRV=cas-essen-01.secunet.de:TOTAL-FE=0.015|SMR=0.009(SMRPI=0.007(SMRPI-FrontendProxyAgent=0.007))|SMS=0.006
X-MS-Exchange-Organization-Recipient-Limit-Verified: True
X-MS-Exchange-Organization-TotalRecipientCount: 1
X-MS-Exchange-Organization-Rules-Execution-History: 0b0cf904-14ac-4724-8bdf-482ee6223cf2%%%fd34672d-751c-45ae-a963-ed177fcabe23%%%d8080257-b0c3-47b4-b0db-23bc0c8ddb3c%%%95e591a2-5d7d-4afa-b1d0-7573d6c0a5d9%%%f7d0f6bc-4dcc-4876-8c5d-b3d6ddbb3d55%%%16355082-c50b-4214-9c7d-d39575f9f79b
X-MS-Exchange-Forest-RulesExecuted: mbx-essen-02
X-MS-Exchange-Organization-RulesExecuted: mbx-essen-02
X-MS-Exchange-Forest-IndexAgent-0: AQ0CZW4AAZAGAAAPAAADH4sIAAAAAAAEAKVVf3PTRhA9OZbjKJbDjz
QF/toJtJQ6cuzYhMRQJgxkCjMUaJKh02Fo5mydbRFZcnVSEvfH1+oX
6Ifo1+nuneTIJGHawZMRp723796+3RP/LB8MBXS9wPWCgYR+GMGeCI
TkEnbjoYgCEcPB/is4wcCHRMYwEtFAuOAFcLxZ3wYeuIA423KF9AaB
IohnGX0/PBGE4jGEfQiJ9vwhbuQdi0jalmZMJLieC0EYE2VPAIfe0P
NdJwhdMT3lh2cvXkM3kXV4IikQoRAeCUyDZCzjSPBRRgyYkki16CPU
k5lEmODpMT8Suo5wPA6jOAm8eAJxCL0wikQv1hkkTauhwxPJB4LYLp
JmW1NttmVb++iNcJ2w33e6kw688o58LH7/779cEfkJ0j4KVKguwzRS
i7RDOxEfBDwWvWFdise2tSeOPYF+Kp69sAvPRRRRGY+isDvcOSI3/X
oYDRDrOI5tfQtPhzwYCAnSC1D6cRM3YPd0TNWEAWBhcRhNqKO9cDTy
qMWSSlPCnwts3xqtaE5mRkIbC+iLjD3fJ4JIiVM+DfmxUO3rChFkU4
MbtkXNyaybGRXqXAoUHp1Uh/0QTtBbkXYMG3oktb1Z91Cv6PexRZK6
HgZCJwno8WC2eyMslNp8gtxhEiMF0REHDyY0G06PS7SpK7CHgigCQX
MbgkzUUChcl/eOTniEdaBbYx57Xc/HWamnbkO9Xl/PKlpHq9bTPq4J
qiiWQX3CRz6kvz+g1YJa+nPOfkjUhD4V3lPNc9eg2UaHcYBjLwzkN7
V7GNkGV/hCB5x71CTX6/fBcQboCl9/FvaSkQhiToh1F3vTE3gnxH/R
1/2cbNtCiDgFwVv33eZ2V2xtbNfr3fbmVoM33QZvbEKz0dhst5Vpn6
fUttC5z5W7swPOg+ZacxNq+M8W4Ps4CsdktpAdbAb9RJCMOvCusQYb
jUbjfRp1RZ8nftyBBvnvANy9zV03wivk9PDuyLsdFQWcxUAijG5fip
Peb+JiUEODcLxivG9v8lIQtvqLSO+hMx5Odt41nG3u9N/fWc1Y4slY
dCDsfsDZT0N3ItHvQD5PlX4b7QMYuV7YUasMuC57QzHi2jTaztCq5i
QQx9xP8Kvk5rRBn/tSkAv4Hfg18SLhdrS12230tLa1ufaAnM1tIpeD
71LEMn1BYc4Iv4G5V7wAri9UHc45d6fhnJmqEkdVpdRghkdTwf0L1Z
LC5sbGGl6wWrPZWmuq/otTPhr7Z91Xvp46XkAd4b6DN49PnLGE7+AR
zcPjhzngmWza/hpfW7Sf9oJ+s2UQqkmIs/2zemhT0deyTaoMfs8FPs
E4i7mANXco6Zwdkp0WnePkObLPnqptNQ92PCHEVmOj3nJ67furDz9K
jMRgeujMhvI0SsZIgv8FBLHybDD2wvblUKW/BS/2fjw8+PnN7uHL3b
e7Lw9fvv5ppg/6WBwvh+jklLgJGy34/s2L14dPnh68eLubJdbOJ45D
GafNThRBO2127SP4BeY1zjXp/xp4Ljlv4rnNTxt5OfyTZs6k/Zl3d/
pCC/o/a6PebtfVd9C2GJtjxTJbwOc8K+sF/hWZWWLzBTZXMOYMxgxW
UHEKagAi8Q9hiDFZSefOq3QMagzGMdE0mMVK06Ba6CyiwoVKLGsefC
IAX6fIRVbBIEY0A2L0E4PnyE21KOOpdkpeRMELbBEjX9HCQh58FphZ
NtgiWygoSSi7aLCltDobMYq/pB3Q2nA9zyoms6Z26V2tRNuiZRRTHn
O6m08pZZVOYZpfP3WWTtEl43NeWU0FGmxB1a6P1uZrr8rMstmtfB+L
RrXAWMG4qdtHVMYCRdicZSzpxQK7UlTKEWCzqsUWZxiYeUm8hBoqrF
ox7BJjJVa5BGZdHDdwjc0rKnlzeq1Emha7VjTmaW1gdazIKqhZbVnz
1FPsS9XUALZYpNabucj8VXYT21rBswxTkaC2gp4TxBbJt+qcan0lHV
QM2gheYcZ05PDQL9iX2OiyUT3TZhTyOsvsSokSWZlSFudICTZ3KRO5
lGmzi2xhma2YRoXKMUxd8tmalcpsGcUtq1tA02KUVOFXM87FIltOaV
MrMvL0tVpkK7OA67MAbHEps0Xrv2axapkOVU0xytork+748lxq5jVM
vsIsFGCyFcuoph8B3FAuqWu4bNIlwmGwTKOkJyp3j2j3uprzXF03zo
lZuVzMjUzMSk7MrYvFGBu6TdphWv8LSqHCvDMPAAABAp8IPD94bWwg
dmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTE2Ij8+DQo8VGFza1
NldD4NCiAgPFZlcnNpb24+MTUuMC4wLjA8L1ZlcnNpb24+DQogIDxU
YXNrcz4NCiAgICA8VGFzayBTdGFydEluZGV4PSI3NjEiPg0KICAgIC
AgPFRhc2tTdHJpbmc+YnJlYWtpbmcgYW55IHVzZS1jYXNlcyBiZWZv
cmUgd2UgbmVlZCB0byBzdXBwb3J0IGFueSBiYWNrd2FyZDwvVGFza1
N0cmluZz4NCiAgICAgIDxBc3NpZ25lZXM+DQogICAgICAgIDxFbWFp
bFVzZXIgSWQ9InMuc2h0eWx5b3ZAb21wLnJ1Ij5TZXJnZXkgU2h0eW
x5b3Y8L0VtYWlsVXNlcj4NCiAgICAgICAgPEVtYWlsVXNlciBJZD0i
ZGF2ZW1AZGF2ZW1sb2Z0Lm5ldCI+RGF2aWQgUy4gTWlsbGVyPC9FbW
FpbFVzZXI+DQogICAgICAgIDxFbWFpbFVzZXIgSWQ9ImVkdW1hemV0
QGdvb2dsZS5jb20iPkVyaWMgRHVtYXpldDwvRW1haWxVc2VyPg0KIC
AgICAgICA8RW1haWxVc2VyIElkPSJrdWJhQGtlcm5lbC5vcmciPkph
a3ViIEtpY2luc2tpPC9FbWFpbFVzZXI+DQogICAgICAgIDxFbWFpbF
VzZXIgSWQ9InBhYmVuaUByZWRoYXQuY29tIj5QYW9sbyBBYmVuaTwv
RW1haWxVc2VyPg0KICAgICAgICA8RW1haWxVc2VyIElkPSJyb2JoK2
R0QGtlcm5lbC5vcmciPlJvYiBIZXJyaW5nPC9FbWFpbFVzZXI+DQog
ICAgICAgIDxFbWFpbFVzZXIgSWQ9ImtyenlzenRvZi5rb3psb3dza2
krZHRAbGluYXJvLm9yZyI+S3J6eXN6dG9mIEtvemxvd3NraTwvRW1h
aWxVc2VyPg0KICAgICAgICA8RW1haWxVc2VyIElkPSJjb25vcitkdE
BrZXJuZWwub3JnIj5Db25vciBEb29sZXk8L0VtYWlsVXNlcj4NCiAg
ICAgICAgPEVtYWlsVXNlciBJZD0iZ2VlcnQrcmVuZXNhc0BnbGlkZX
IuYmUiPkdlZXJ0IFV5dHRlcmhvZXZlbjwvRW1haWxVc2VyPg0KICAg
ICAgICA8RW1haWxVc2VyIElkPSJuZXRkZXZAdmdlci5rZXJuZWwub3
JnIiAvPg0KICAgICAgICA8RW1haWxVc2VyIElkPSJkZXZpY2V0cmVl
QHZnZXIua2VybmVsLm9yZyIgLz4NCiAgICAgIDwvQXNzaWduZWVzPg
0KICAgIDwvVGFzaz4NCiAgPC9UYXNrcz4NCjwvVGFza1NldD4BCt8C
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTE2Ij8+DQ
o8RW1haWxTZXQ+DQogIDxWZXJzaW9uPjE1LjAuMC4wPC9WZXJzaW9u
Pg0KICA8RW1haWxzPg0KICAgIDxFbWFpbCBTdGFydEluZGV4PSIzOT
AiIFBvc2l0aW9uPSJTaWduYXR1cmUiPg0KICAgICAgPEVtYWlsU3Ry
aW5nPm5pa2xhcy5zb2Rlcmx1bmQrcmVuZXNhc0ByYWduYXRlY2guc2
U8L0VtYWlsU3RyaW5nPg0KICAgIDwvRW1haWw+DQogICAgPEVtYWls
IFN0YXJ0SW5kZXg9IjQ1NiI+DQogICAgICA8RW1haWxTdHJpbmc+cm
9iaEBrZXJuZWwub3JnPC9FbWFpbFN0cmluZz4NCiAgICA8L0VtYWls
Pg0KICA8L0VtYWlscz4NCjwvRW1haWxTZXQ+AQyuBzw/eG1sIHZlcn
Npb249IjEuMCIgZW5jb2Rpbmc9InV0Zi0xNiI/Pg0KPENvbnRhY3RT
ZXQ+DQogIDxWZXJzaW9uPjE1LjAuMC4wPC9WZXJzaW9uPg0KICA8Q2
9udGFjdHM+DQogICAgPENvbnRhY3QgU3RhcnRJbmRleD0iMzcyIiBQ
b3NpdGlvbj0iU2lnbmF0dXJlIj4NCiAgICAgIDxQZXJzb24gU3Rhcn
RJbmRleD0iMzcyIiBQb3NpdGlvbj0iU2lnbmF0dXJlIj4NCiAgICAg
ICAgPFBlcnNvblN0cmluZz5OaWtsYXM8L1BlcnNvblN0cmluZz4NCi
AgICAgIDwvUGVyc29uPg0KICAgICAgPEVtYWlscz4NCiAgICAgICAg
PEVtYWlsIFN0YXJ0SW5kZXg9IjM5MCIgUG9zaXRpb249IlNpZ25hdH
VyZSI+DQogICAgICAgICAgPEVtYWlsU3RyaW5nPm5pa2xhcy5zb2Rl
cmx1bmQrcmVuZXNhc0ByYWduYXRlY2guc2U8L0VtYWlsU3RyaW5nPg
0KICAgICAgICA8L0VtYWlsPg0KICAgICAgPC9FbWFpbHM+DQogICAg
ICA8Q29udGFjdFN0cmluZz5OaWtsYXMgU8O2ZGVybHVuZCAmbHQ7bm
lrbGFzLnNvZGVybHVuZCtyZW5lc2FzQHJhZ25hdGVjaC5zZTwvQ29u
dGFjdFN0cmluZz4NCiAgICA8L0NvbnRhY3Q+DQogICAgPENvbnRhY3
QgU3RhcnRJbmRleD0iNDQzIj4NCiAgICAgIDxQZXJzb24gU3RhcnRJ
bmRleD0iNDQzIj4NCiAgICAgICAgPFBlcnNvblN0cmluZz5Sb2I8L1
BlcnNvblN0cmluZz4NCiAgICAgIDwvUGVyc29uPg0KICAgICAgPEVt
YWlscz4NCiAgICAgICAgPEVtYWlsIFN0YXJ0SW5kZXg9IjQ1NiI+DQ
ogICAgICAgICAgPEVtYWlsU3RyaW5nPnJvYmhAa2VybmVsLm9yZzwv
RW1haWxTdHJpbmc+DQogICAgICAgIDwvRW1haWw+DQogICAgICA8L0
VtYWlscz4NCiAgICAgIDxDb250YWN0U3RyaW5nPlJvYiBIZXJyaW5n
ICZsdDtyb2JoQGtlcm5lbC5vcmc8L0NvbnRhY3RTdHJpbmc+DQogIC
AgPC9Db250YWN0Pg0KICA8L0NvbnRhY3RzPg0KPC9Db250YWN0U2V0
PgEOzwFSZXRyaWV2ZXJPcGVyYXRvciwxMCwxO1JldHJpZXZlck9wZX
JhdG9yLDExLDM7UG9zdERvY1BhcnNlck9wZXJhdG9yLDEwLDE7UG9z
dERvY1BhcnNlck9wZXJhdG9yLDExLDA7UG9zdFdvcmRCcmVha2VyRG
lhZ25vc3RpY09wZXJhdG9yLDEwLDI7UG9zdFdvcmRCcmVha2VyRGlh
Z25vc3RpY09wZXJhdG9yLDExLDA7VHJhbnNwb3J0V3JpdGVyUHJvZH VjZXIsMjAsMjA=
X-MS-Exchange-Forest-IndexAgent: 1 4262
X-MS-Exchange-Forest-EmailMessageHash: 28218C02
X-MS-Exchange-Forest-Language: en
X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent
The bindings for Renesas Ethernet TSN was just merged in v6.9 and the
design for the bindings followed that of other Renesas Ethernet drivers
and thus did not force a child-node for the MDIO bus. As there
are no upstream drivers or users of this binding yet take the
opportunity to correct this and force the usage of a child-node for the
MDIO bus.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Rob Herring <robh@kernel.org>
---
* Changes since v1
- Expand on history in commit message.
Hello,
The Ethernet TSN driver is still in review and have not been merged and
no usage of the bindings are merged either. So while this breaks the
binding it effects no one. So we can correct this mistake without
breaking any use-cases before we need to support any backward
compatibility.
---
.../bindings/net/renesas,ethertsn.yaml | 33 ++++++++-----------
1 file changed, 14 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml b/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml
index ea35d19be829..b4680a1d0a06 100644
--- a/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml
+++ b/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml
@@ -71,16 +71,8 @@ properties:
enum: [0, 2000]
default: 0
- '#address-cells':
- const: 1
-
- '#size-cells':
- const: 0
-
-patternProperties:
- "^ethernet-phy@[0-9a-f]$":
- type: object
- $ref: ethernet-phy.yaml#
+ mdio:
+ $ref: /schemas/net/mdio.yaml#
unevaluatedProperties: false
required:
@@ -94,8 +86,7 @@ required:
- resets
- phy-mode
- phy-handle
- - '#address-cells'
- - '#size-cells'
+ - mdio
additionalProperties: false
@@ -122,14 +113,18 @@ examples:
tx-internal-delay-ps = <2000>;
phy-handle = <&phy3>;
- #address-cells = <1>;
- #size-cells = <0>;
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
- phy3: ethernet-phy@3 {
- compatible = "ethernet-phy-ieee802.3-c45";
- reg = <0>;
- interrupt-parent = <&gpio4>;
- interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
reset-gpios = <&gpio1 23 GPIO_ACTIVE_LOW>;
+ reset-post-delay-us = <4000>;
+
+ phy3: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+ };
};
};
--
2.44.0
^ permalink raw reply related
* Re: [PATCH v6 0/1] Add property in dwmac-stm32 documentation
From: patchwork-bot+netdevbpf @ 2024-03-29 22:50 UTC (permalink / raw)
To: Christophe Roullier
Cc: davem, edumazet, kuba, pabeni, robh+dt, krzysztof.kozlowski+dt,
conor+dt, mcoquelin.stm32, alexandre.torgue, richardcochran,
joabreu, lgirdwood, broonie, marex, netdev, devicetree,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20240328185337.332703-1-christophe.roullier@foss.st.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 28 Mar 2024 19:53:36 +0100 you wrote:
> Introduce property in dwmac-stm32 documentation
>
> - st,ext-phyclk: is present since 2020 in driver so need to explain
> it and avoid dtbs check issue : views/kernel/upstream/net-next/arch/arm/boot/dts/st/stm32mp157c-dk2.dtb:
> ethernet@5800a000: Unevaluated properties are not allowed
> ('st,ext-phyclk' was unexpected)
> Furthermore this property will be use in upstream of MP13 dwmac glue. (next step)
>
> [...]
Here is the summary with links:
- [v6,1/1] dt-bindings: net: dwmac: Document STM32 property st,ext-phyclk
https://git.kernel.org/netdev/net-next/c/929107d3d2a3
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
X-sender: <linux-kernel+bounces-125481-steffen.klassert=secunet.com@vger.kernel.org>
X-Receiver: <steffen.klassert@secunet.com> ORCPT=rfc822;steffen.klassert@secunet.com NOTIFY=NEVER; X-ExtendedProps=BQAVABYAAgAAAAUAFAARAPDFCS25BAlDktII2g02frgPADUAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0LkRpcmVjdG9yeURhdGEuSXNSZXNvdXJjZQIAAAUAagAJAAEAAAAAAAAABQAWAAIAAAUAQwACAAAFAEYABwADAAAABQBHAAIAAAUAEgAPAGIAAAAvbz1zZWN1bmV0L291PUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpL2NuPVJlY2lwaWVudHMvY249U3RlZmZlbiBLbGFzc2VydDY4YwUACwAXAL4AAACheZxkHSGBRqAcAp3ukbifQ049REI2LENOPURhdGFiYXNlcyxDTj1FeGNoYW5nZSBBZG1pbmlzdHJhdGl2ZSBHcm91cCAoRllESUJPSEYyM1NQRExUKSxDTj1BZG1pbmlzdHJhdGl2ZSBHcm91cHMsQ049c2VjdW5ldCxDTj1NaWNyb3NvZnQgRXhjaGFuZ2UsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1zZWN1bmV0LERDPWRlBQAOABEABiAS9uuMOkqzwmEZDvWNNQUAHQAPAAwAAABtYngtZXNzZW4tMDIFADwAAgAADwA2AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50LkRpc3BsYXlOYW1lDwARAAAAS2xhc3NlcnQsIFN0ZWZmZW4FAAwAAgAABQBsAAIAAAUAWAAXAEoAAADwxQktuQQJQ5LSCNoNNn64Q049S2xhc3NlcnQgU3RlZmZlbixPVT1Vc2VycyxPVT1NaWdyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUAJgACAAEFACIADwAxAAAAQXV0b1Jlc3BvbnNlU3VwcHJlc3M6IDANClRyYW5zbWl0SGlzdG9yeTogRmFsc2UNCg8ALwAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuRXhwYW5zaW9uR3JvdXBUeXBlDwAVAAAATWVtYmVyc0dyb3VwRXhwYW5zaW9uBQAjAAIAAQ==
X-CreatedBy: MSExchange15
X-HeloDomain: b.mx.secunet.com
X-ExtendedProps: BQBjAAoAWUmmlidQ3AgFAGEACAABAAAABQA3AAIAAA8APAAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5Pcmdhbml6YXRpb25TY29wZREAAAAAAAAAAAAAAAAAAAAAAAUASQACAAEFAAQAFCABAAAAHAAAAHN0ZWZmZW4ua2xhc3NlcnRAc2VjdW5ldC5jb20FAAYAAgABBQApAAIAAQ8ACQAAAENJQXVkaXRlZAIAAQUAAgAHAAEAAAAFAAMABwAAAAAABQAFAAIAAQUAYgAKAGUAAADNigAABQBkAA8AAwAAAEh1Yg==
X-Source: SMTP:Default MBX-ESSEN-02
X-SourceIPAddress: 62.96.220.37
X-EndOfInjectedXHeaders: 12168
Received: from cas-essen-01.secunet.de (10.53.40.201) by
mbx-essen-02.secunet.de (10.53.40.198) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2507.37; Fri, 29 Mar 2024 23:50:58 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-01.secunet.de
(10.53.40.201) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
Transport; Fri, 29 Mar 2024 23:50:58 +0100
Received: from localhost (localhost [127.0.0.1])
by b.mx.secunet.com (Postfix) with ESMTP id 51EB6202E4
for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 23:50:58 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=2.1
tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.099, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MAILING_LIST_MULTI=-1,
RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=unavailable autolearn_force=no
Authentication-Results: a.mx.secunet.com (amavisd-new);
dkim=pass (2048-bit key) header.d=kernel.org
Received: from b.mx.secunet.com ([127.0.0.1])
by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id QAo-ZgBbYr2Z for <steffen.klassert@secunet.com>;
Fri, 29 Mar 2024 23:50:57 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=147.75.199.223; helo=ny.mirrors.kernel.org; envelope-from=linux-kernel+bounces-125481-steffen.klassert=secunet.com@vger.kernel.org; receiver=steffen.klassert@secunet.com
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com 5F257200BB
Authentication-Results: b.mx.secunet.com;
dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QriMG5bP"
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by b.mx.secunet.com (Postfix) with ESMTPS id 5F257200BB
for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 23:50:57 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id 27A8F1C21134
for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 22:50:56 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id AD84C13E6BB;
Fri, 29 Mar 2024 22:50:33 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QriMG5bP"
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by smtp.subspace.kernel.org (Postfix) with ESMTPS id 61D1613D62A;
Fri, 29 Mar 2024 22:50:30 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1711752631; cv=none; b=eLispVzL4Rucdj5yrzfRgnSRePLp+Y1FD2BRZyUX76ykzaZw7VHi9YXASU31baAxoYFmxYlpOQR4UYS8gEjEpjt1zGwq62prz06qhAHc+483Hh1xmTXYFXP7I4YViQd6l9vns1N932S+E0brudJT0ir0I9KRIrHiq60XZoaVoX0=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1711752631; c=relaxed/simple;
bh=1rWdaEawfYR3LfAF31PiRtpuMF8rLJZ44iKkxh0MscI=;
h=Content-Type:MIME-Version:Subject:From:Message-Id:Date:References:
In-Reply-To:To:Cc; b=Xg3OsV9Hn217vm8daSQu1usYD3ksPWTEpVZ2YL8e46SgPg+BrESFujNuqbVuhFeJowZ00pl26chFLpmFOjszBnk+xcfKA2Lv8VGoUK8QewV5y96v44UHH8h1j3HJYz3vCS+bWN/aej6pX4824HBLNpa31QWPvcxKcQWmCuSFNkM=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QriMG5bP; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPS id 8AA7FC43609;
Fri, 29 Mar 2024 22:50:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
s=k20201202; t=1711752630;
bh=1rWdaEawfYR3LfAF31PiRtpuMF8rLJZ44iKkxh0MscI=;
h=Subject:From:Date:References:In-Reply-To:To:Cc:From;
b=QriMG5bPxFDJal3+iK1Pb0iH9WyOvvWgwweQ2/D86v3oy/13nMNRcnZgIMYLJopSY
7KLJczmMCVMHyE0HUKo16Zlrh+oM1jIPi5sy2qLvR1xNCT85FR5iD28bsq3bhCic2E
9agT52MvYHoRihMvi5B1sSF3/Py9XPrQj9IBRigclTJz6rtPhf6vSl/5FSEsRqKbd5
AG+Y/Btm/xHAuRSBzBp5kwOLojbL6e2YNlyWE+0YcxgNg53lc484ELHLR7HwPJHh3Q
zxW5r1DkUTeEdz0tQrKVSD3O2p8NxXZGc3WAWBi8z8L8dwVHWkG0HVZicER5qqp8k6
laI6AElXluGGw==
Received: from aws-us-west-2-korg-oddjob-1.ci.codeaurora.org (localhost.localdomain [127.0.0.1])
by aws-us-west-2-korg-oddjob-1.ci.codeaurora.org (Postfix) with ESMTP id 816E5D2D0EB;
Fri, 29 Mar 2024 22:50:30 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PATCH v6 0/1] Add property in dwmac-stm32 documentation
From: patchwork-bot+netdevbpf@kernel.org
Message-ID: <171175263052.1693.263504657362042828.git-patchwork-notify@kernel.org>
Date: Fri, 29 Mar 2024 22:50:30 +0000
References: <20240328185337.332703-1-christophe.roullier@foss.st.com>
In-Reply-To: <20240328185337.332703-1-christophe.roullier@foss.st.com>
To: Christophe Roullier <christophe.roullier@foss.st.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com,
richardcochran@gmail.com, joabreu@synopsys.com, lgirdwood@gmail.com,
broonie@kernel.org, marex@denx.de, netdev@vger.kernel.org,
devicetree@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Return-Path: linux-kernel+bounces-125481-steffen.klassert=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 29 Mar 2024 22:50:58.3672
(UTC)
X-MS-Exchange-Organization-Network-Message-Id: d4d0ffc8-2bb7-4705-a7dd-08dc5042b329
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.201
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-01.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=mbx-essen-02.secunet.de:TOTAL-HUB=0.387|SMR=0.325(SMRDE=0.004|SMRC=0.320(SMRCL=0.101|X-SMRCR=0.320))|CAT=0.060(CATOS=0.001
|CATRESL=0.028(CATRESLP2R=0.002)|CATORES=0.029(CATRS=0.028(CATRS-Index
Routing Agent=0.027 )));2024-03-29T22:50:58.771Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-essen-02.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-01.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-FromEntityHeader: Internet
X-MS-Exchange-Organization-OriginalSize: 7690
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageLatency: SRV=cas-essen-01.secunet.de:TOTAL-FE=0.017|SMR=0.008(SMRPI=0.006(SMRPI-FrontendProxyAgent=0.006))|SMS=0.009
X-MS-Exchange-Organization-Recipient-Limit-Verified: True
X-MS-Exchange-Organization-TotalRecipientCount: 1
X-MS-Exchange-Organization-Rules-Execution-History: 0b0cf904-14ac-4724-8bdf-482ee6223cf2%%%fd34672d-751c-45ae-a963-ed177fcabe23%%%d8080257-b0c3-47b4-b0db-23bc0c8ddb3c%%%95e591a2-5d7d-4afa-b1d0-7573d6c0a5d9%%%f7d0f6bc-4dcc-4876-8c5d-b3d6ddbb3d55%%%16355082-c50b-4214-9c7d-d39575f9f79b
X-MS-Exchange-Forest-RulesExecuted: mbx-essen-02
X-MS-Exchange-Organization-RulesExecuted: mbx-essen-02
X-MS-Exchange-Forest-IndexAgent-0: AQ0CZW4AAUADAAAPAAADH4sIAAAAAAAEAF1TX2/bNhA/2ZJsK9E6bB
j2entqgtmSbC9tIwxFH4qt3RBswLKHoegDLXERIYkURMpqvvM+xI6U
k6WDBVom737/jv4nfMebRuVxFEe3ldDYMVNUODKNrOsawUs0CiU3JT
+m9LWR/JNJ7oTBi5YJeRlHh3v8hdXDAX8VhZC6Fvgj/WJvat5L3iSq
v3vt0H+TeFsNa9y9whvW4y7b/YDb6/xqn+9f4PfZNsvwXg049spwan
iN76XpVTkUHLtedbw39ygklmPLio027X6HpSqGlkvDjFCSWmwXblCb
NYncdNV90dQ5WlM911SHWkiCI+rMQfXiyHvU1t/kk3/qGnLlcBDJJJ
MlsqMSJZbmoLGoeFEToB445ngUfNTp5DMdOm16ztrHkFLWFxUtbXpQ
yqSl0ak2qRPedturl8WmrHcJwTqz3FQWx7y5epVlLMuyHP+U/MiagR
nSdkpAcBpLz1EqkkZjG3lpmy+ef2b5uRvfQCI6XlD35cnPT0NvWVpF
CMbN+iHXUTQNHjgOmttgHryg+htvft/up9Dxrhl4ghfWHGXMu8tT5B
+SJPloR/yOEzLhEgvqoW1Zb6FNhY2QtSafdjofji/W23T7kRLdHIQs
hbzTub1h+UST49vTWPGP2xua8qPKz0xaMMTKmE7naUoXMvnvwqX/u6
9pkV7vrrfZy3Jf7tjeSv2LrppNko1cq5avSTOTtb2B38XRZhNHbzk1
lzQ5Wswa3yPFwfCgTBJHD6w1cSV0CfVTbvcHGlVfp91oyyvTNpbRfg
ACiHwIAgjn4C9gOYN56MHXsFjCag6BDwvaodMllXnwDIIQFnNY0Sad
zjw4o8e++74XLAGW3iqwmBaNkFcQLV1xYMtC2o/hW9vrQQR+6OiINP
BCH4BkWHbHOL0v4AtHRFDhJDKwxfAzhKFTSA/tW3a3UvEz+HIOS3cU
ncF5BGe076zFT3lpJ4KvqIAaJ5CJiNZJ8ERH9n0bwjePBaTWHcUzj8
DA82Z2hfnM5UCkc3tqtbnQVk9Iz0n5laN2GZ5WQvNgdm5lTzpXLj2b
dmypyZctIBxa55SAB1unwT/NwqeQrdR/AY8Sojk5BQAAAQrVATw/eG
1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9InV0Zi0xNiI/Pg0KPEVt
YWlsU2V0Pg0KICA8VmVyc2lvbj4xNS4wLjAuMDwvVmVyc2lvbj4NCi
AgPEVtYWlscz4NCiAgICA8RW1haWwgU3RhcnRJbmRleD0iODMiPg0K
ICAgICAgPEVtYWlsU3RyaW5nPmt1YmFAa2VybmVsLm9yZzwvRW1haW
xTdHJpbmc+DQogICAgPC9FbWFpbD4NCiAgPC9FbWFpbHM+DQo8L0Vt
YWlsU2V0PgEL+gI8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPS
J1dGYtMTYiPz4NCjxVcmxTZXQ+DQogIDxWZXJzaW9uPjE1LjAuMC4w
PC9WZXJzaW9uPg0KICA8VXJscz4NCiAgICA8VXJsIFN0YXJ0SW5kZX
g9IjcwMSIgVHlwZT0iVXJsIj4NCiAgICAgIDxVcmxTdHJpbmc+aHR0
cHM6Ly9naXQua2VybmVsLm9yZy9uZXRkZXYvbmV0LW5leHQvYy85Mj
kxMDdkM2QyYTM8L1VybFN0cmluZz4NCiAgICA8L1VybD4NCiAgICA8
VXJsIFN0YXJ0SW5kZXg9IjgxOSIgVHlwZT0iVXJsIj4NCiAgICAgID
xVcmxTdHJpbmc+aHR0cHM6Ly9rb3JnLmRvY3Mua2VybmVsLm9yZy9w
YXRjaHdvcmsvcHdib3QuaHRtbDwvVXJsU3RyaW5nPg0KICAgIDwvVX
JsPg0KICA8L1VybHM+DQo8L1VybFNldD4BDOgDPD94bWwgdmVyc2lv
bj0iMS4wIiBlbmNvZGluZz0idXRmLTE2Ij8+DQo8Q29udGFjdFNldD
4NCiAgPFZlcnNpb24+MTUuMC4wLjA8L1ZlcnNpb24+DQogIDxDb250
YWN0cz4NCiAgICA8Q29udGFjdCBTdGFydEluZGV4PSI2NyI+DQogIC
AgICA8UGVyc29uIFN0YXJ0SW5kZXg9IjY3Ij4NCiAgICAgICAgPFBl
cnNvblN0cmluZz5KYWt1YiBLaWNpbnNraTwvUGVyc29uU3RyaW5nPg
0KICAgICAgPC9QZXJzb24+DQogICAgICA8RW1haWxzPg0KICAgICAg
ICA8RW1haWwgU3RhcnRJbmRleD0iODMiPg0KICAgICAgICAgIDxFbW
FpbFN0cmluZz5rdWJhQGtlcm5lbC5vcmc8L0VtYWlsU3RyaW5nPg0K
ICAgICAgICA8L0VtYWlsPg0KICAgICAgPC9FbWFpbHM+DQogICAgIC
A8Q29udGFjdFN0cmluZz5KYWt1YiBLaWNpbnNraSAmbHQ7a3ViYUBr
ZXJuZWwub3JnPC9Db250YWN0U3RyaW5nPg0KICAgIDwvQ29udGFjdD
4NCiAgPC9Db250YWN0cz4NCjwvQ29udGFjdFNldD4BDs8BUmV0cmll
dmVyT3BlcmF0b3IsMTAsMDtSZXRyaWV2ZXJPcGVyYXRvciwxMSwxO1
Bvc3REb2NQYXJzZXJPcGVyYXRvciwxMCwwO1Bvc3REb2NQYXJzZXJP
cGVyYXRvciwxMSwwO1Bvc3RXb3JkQnJlYWtlckRpYWdub3N0aWNPcG
VyYXRvciwxMCwwO1Bvc3RXb3JkQnJlYWtlckRpYWdub3N0aWNPcGVy
YXRvciwxMSwwO1RyYW5zcG9ydFdyaXRlclByb2R1Y2VyLDIwLDEz
X-MS-Exchange-Forest-IndexAgent: 1 2145
X-MS-Exchange-Forest-EmailMessageHash: B35CD68A
X-MS-Exchange-Forest-Language: en
X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 28 Mar 2024 19:53:36 +0100 you wrote:
> Introduce property in dwmac-stm32 documentation
>
> - st,ext-phyclk: is present since 2020 in driver so need to explain
> it and avoid dtbs check issue : views/kernel/upstream/net-next/arch/arm/boot/dts/st/stm32mp157c-dk2.dtb:
> ethernet@5800a000: Unevaluated properties are not allowed
> ('st,ext-phyclk' was unexpected)
> Furthermore this property will be use in upstream of MP13 dwmac glue. (next step)
>
> [...]
Here is the summary with links:
- [v6,1/1] dt-bindings: net: dwmac: Document STM32 property st,ext-phyclk
https://git.kernel.org/netdev/net-next/c/929107d3d2a3
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v6 17/17] net: pse-pd: Add TI TPS23881 PSE controller driver
From: Andrew Lunn @ 2024-03-30 14:52 UTC (permalink / raw)
To: Kory Maincent
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jonathan Corbet, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Oleksij Rempel, Mark Brown,
Frank Rowand, Heiner Kallweit, Russell King, Thomas Petazzoni,
netdev, linux-kernel, linux-doc, devicetree, Dent Project
In-Reply-To: <20240329155657.7939ac4b@kmaincent-XPS-13-7390>
On Fri, Mar 29, 2024 at 03:56:57PM +0100, Kory Maincent wrote:
> On Thu, 28 Mar 2024 17:24:17 +0100
> Andrew Lunn <andrew@lunn.ch> wrote:
>
> > > +static int tps23881_flash_fw_part(struct i2c_client *client,
> > > + const char *fw_name,
> > > + const struct tps23881_fw_conf *fw_conf)
> >
> > Does the device actually have flash? Or is this just downloading to
> > SRAM?
>
> It is downloading to SRAM.
So maybe rename these functions.
Andrew
X-sender: <netdev+bounces-83507-steffen.klassert=secunet.com@vger.kernel.org>
X-Receiver: <steffen.klassert@secunet.com> ORCPT=rfc822;steffen.klassert@secunet.com NOTIFY=NEVER; X-ExtendedProps=BQAVABYAAgAAAAUAFAARAPDFCS25BAlDktII2g02frgPADUAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0LkRpcmVjdG9yeURhdGEuSXNSZXNvdXJjZQIAAAUAagAJAAEAAAAAAAAABQAWAAIAAAUAQwACAAAFAEYABwADAAAABQBHAAIAAAUAEgAPAGIAAAAvbz1zZWN1bmV0L291PUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpL2NuPVJlY2lwaWVudHMvY249U3RlZmZlbiBLbGFzc2VydDY4YwUACwAXAL4AAACheZxkHSGBRqAcAp3ukbifQ049REI2LENOPURhdGFiYXNlcyxDTj1FeGNoYW5nZSBBZG1pbmlzdHJhdGl2ZSBHcm91cCAoRllESUJPSEYyM1NQRExUKSxDTj1BZG1pbmlzdHJhdGl2ZSBHcm91cHMsQ049c2VjdW5ldCxDTj1NaWNyb3NvZnQgRXhjaGFuZ2UsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1zZWN1bmV0LERDPWRlBQAOABEABiAS9uuMOkqzwmEZDvWNNQUAHQAPAAwAAABtYngtZXNzZW4tMDIFADwAAgAADwA2AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50LkRpc3BsYXlOYW1lDwARAAAAS2xhc3NlcnQsIFN0ZWZmZW4FAAwAAgAABQBsAAIAAAUAWAAXAEoAAADwxQktuQQJQ5LSCNoNNn64Q049S2xhc3NlcnQgU3RlZmZlbixPVT1Vc2VycyxPVT1NaWdyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUAJgACAAEFACIADwAxAAAAQXV0b1Jlc3BvbnNlU3VwcHJlc3M6IDANClRyYW5zbWl0SGlzdG9yeTogRmFsc2UNCg8ALwAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuRXhwYW5zaW9uR3JvdXBUeXBlDwAVAAAATWVtYmVyc0dyb3VwRXhwYW5zaW9uBQAjAAIAAQ==
X-CreatedBy: MSExchange15
X-HeloDomain: b.mx.secunet.com
X-ExtendedProps: BQBjAAoAwNjp8x1Q3AgFAGEACAABAAAABQA3AAIAAA8APAAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5Pcmdhbml6YXRpb25TY29wZREAAAAAAAAAAAAAAAAAAAAAAAUASQACAAEFAGIACgBtAAAAnIoAAAUABAAUIAEAAAAcAAAAc3RlZmZlbi5rbGFzc2VydEBzZWN1bmV0LmNvbQUABgACAAEFACkAAgABDwAJAAAAQ0lBdWRpdGVkAgABBQACAAcAAQAAAAUAAwAHAAAAAAAFAAUAAgABBQBkAA8AAwAAAEh1Yg==
X-Source: SMTP:Default MBX-DRESDEN-01
X-SourceIPAddress: 62.96.220.37
X-EndOfInjectedXHeaders: 11630
Received: from cas-essen-02.secunet.de (10.53.40.202) by
mbx-dresden-01.secunet.de (10.53.40.199) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2507.37; Sat, 30 Mar 2024 15:53:36 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-02.secunet.de
(10.53.40.202) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
Transport; Sat, 30 Mar 2024 15:53:36 +0100
Received: from localhost (localhost [127.0.0.1])
by b.mx.secunet.com (Postfix) with ESMTP id AFDEC20322
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 15:53:36 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=2.1
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: a.mx.secunet.com (amavisd-new);
dkim=pass (1024-bit key) header.d=lunn.ch
Received: from b.mx.secunet.com ([127.0.0.1])
by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 1bKMfFGP__Qt for <steffen.klassert@secunet.com>;
Sat, 30 Mar 2024 15:53:35 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=147.75.80.249; helo=am.mirrors.kernel.org; envelope-from=netdev+bounces-83507-steffen.klassert=secunet.com@vger.kernel.org; receiver=steffen.klassert@secunet.com
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com C1C5D2025D
Authentication-Results: b.mx.secunet.com;
dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="AgKIFxWL"
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by b.mx.secunet.com (Postfix) with ESMTPS id C1C5D2025D
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 15:53:34 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id 6B0831F21EBE
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 14:53:34 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id B5BFD383B5;
Sat, 30 Mar 2024 14:53:23 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="AgKIFxWL"
X-Original-To: netdev@vger.kernel.org
Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by smtp.subspace.kernel.org (Postfix) with ESMTPS id AD8311C0DEF;
Sat, 30 Mar 2024 14:53:20 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=156.67.10.101
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1711810403; cv=none; b=VrO6J8Hi+SBymX6+G5k3Ud8x7blzHf4q7Un8U6HDTfCcAzT4feZ1IAepX0YzqrNRbWaj6sVRlwcJW0hQh2XaqpefkR4Sl2gkocyv4v1p3KRon1liM9mPgLHk8XrtVDkI9/lTyxhV5mKiovFXgO/D2P2uamXtEBKUKCzDezwG5NM=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1711810403; c=relaxed/simple;
bh=gJx0oB7ZzuoCNKkwsr1UzGLJ3CRfFELmHureG9uOYGw=;
h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
Content-Type:Content-Disposition:In-Reply-To; b=oDelDfSdHTx21mIJ0hem715uqMg/JEbBvu+QI/n4j2Dk5mc8GbK+VtSdOJISO50a39BBZcXcTZecoAszKR55fvrHsgPXRjIkkmjNpNVTs/51Np0JtRcq77T52D8q+mY13M2OFNo9qBat6UJf/PFGufjBrguPYjOpPuK3LA1Ni/8=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lunn.ch; spf=pass smtp.mailfrom=lunn.ch; dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b=AgKIFxWL; arc=none smtp.client-ip=156.67.10.101
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lunn.ch
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lunn.ch
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch;
s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject:
Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:
Content-ID:Content-Description:Content-Disposition:In-Reply-To:References;
bh=caGVOX2RZ69c4hjscPFCuCKDrFK7z35V6qvgjgO6mvs=; b=AgKIFxWLgU4PMlGPkeuWts4Sdx
C1uk2GClcr5WI35QPJ/c+zppgblTWKdov5NwQ4Y/rlf4kRO+pXEefeYiuH/9vvqcMMhtsW5bKoOSc
ptiP23T99yvkYQ4yFYT1LkW6GjFn1aaNnXMQ/2LbdTSWKkldN1777vtFbSTbTQ5A4V60=;
Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2)
(envelope-from <andrew@lunn.ch>)
id 1rqa4f-00Bj1W-9i; Sat, 30 Mar 2024 15:52:49 +0100
Date: Sat, 30 Mar 2024 15:52:49 +0100
From: Andrew Lunn <andrew@lunn.ch>
To: Kory Maincent <kory.maincent@bootlin.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Jonathan Corbet <corbet@lwn.net>,
Luis Chamberlain <mcgrof@kernel.org>,
Russ Weight <russ.weight@linux.dev>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Oleksij Rempel <o.rempel@pengutronix.de>,
Mark Brown <broonie@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, devicetree@vger.kernel.org,
Dent Project <dentproject@linuxfoundation.org>
Subject: Re: [PATCH net-next v6 17/17] net: pse-pd: Add TI TPS23881 PSE
controller driver
Message-ID: <8186fea6-c1f4-403b-b717-83c1dd3ad826@lunn.ch>
References: <20240326-feature_poe-v6-0-c1011b6ea1cb@bootlin.com>
<20240326-feature_poe-v6-17-c1011b6ea1cb@bootlin.com>
<6bbc6b86-3947-4679-ac0b-fde50129d0f6@lunn.ch>
<20240329155657.7939ac4b@kmaincent-XPS-13-7390>
Precedence: bulk
X-Mailing-List: netdev@vger.kernel.org
List-Id: <netdev.vger.kernel.org>
List-Subscribe: <mailto:netdev+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:netdev+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240329155657.7939ac4b@kmaincent-XPS-13-7390>
Return-Path: netdev+bounces-83507-steffen.klassert=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 30 Mar 2024 14:53:36.7613
(UTC)
X-MS-Exchange-Organization-Network-Message-Id: bcacc45f-6eaf-4034-2c6e-08dc50c92dd9
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.202
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-02.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=mbx-dresden-01.secunet.de:TOTAL-HUB=0.415|SMR=0.342(SMRDE=0.035|SMRC=0.306(SMRCL=0.101|X-SMRCR=0.306))|CAT=0.073(CATOS=0.014
(CATSM=0.014(CATSM-Malware
Agent=0.013))|CATRESL=0.041(CATRESLP2R=0.018)|CATORES=0.014
(CATRS=0.014(CATRS-Index Routing
Agent=0.013))|CATORT=0.001(CATRT=0.001(CATRT-Journal Agent=0.001
)));2024-03-30T14:53:37.211Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-dresden-01.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-02.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-FromEntityHeader: Internet
X-MS-Exchange-Organization-OriginalSize: 7920
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageLatency: SRV=cas-essen-02.secunet.de:TOTAL-FE=0.034|SMR=0.007(SMRPI=0.004(SMRPI-FrontendProxyAgent=0.004))|SMS=0.027
X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
X-MS-Exchange-Organization-Recipient-Limit-Verified: True
X-MS-Exchange-Organization-TotalRecipientCount: 1
X-MS-Exchange-Organization-Rules-Execution-History: 0b0cf904-14ac-4724-8bdf-482ee6223cf2%%%fd34672d-751c-45ae-a963-ed177fcabe23%%%d8080257-b0c3-47b4-b0db-23bc0c8ddb3c%%%95e591a2-5d7d-4afa-b1d0-7573d6c0a5d9%%%f7d0f6bc-4dcc-4876-8c5d-b3d6ddbb3d55%%%16355082-c50b-4214-9c7d-d39575f9f79b
X-MS-Exchange-Forest-RulesExecuted: mbx-dresden-01
X-MS-Exchange-Organization-RulesExecuted: mbx-dresden-01
X-MS-Exchange-Forest-IndexAgent-0: AQ0CZW4AAdkBAAAPAAADH4sIAAAAAAAEAJWRTU/bQBCGx5+xDalQD5
znWEiEHANNalVQpKpS1UZUpXdru9nUrswa2Wus/AV+NTNrCuqhh9qr
zc7M+z4z6zz41xo/tdUc16LF7N0cszQ7Q2EwPc3P3+bny29rnKWLNJ
3jl6bdkazSUmmDQ9sYlU+TCyTCj7In52qEMGCxzLOzfLEcvay60ptW
Dfi11xrfCxt8qCk4keXFC4yV/M46I0wlsaJO5q7LTlerRbGtRVcW26
G4E61505m2lwarTBayrnik4/F3/gzBfz+y0Z1BWdLAx0TU4lb9h++p
98tkQ0GFrUXx4ciiRt7HRnVoSoUbdV9JhUKaXtT1Dktxr9De6RKvW6
xYRdvvnhpsmkHXjdhU+heaZgTdfL9aXz59o8+G9X+rrOBkmkyTmwZv
xe6nwlbxxbh7R616LU1F81vNnwuN/wtnAFzwPAg8B/Zpge+C70PgOl
7kQAS0IjoHAAFMKB9BHEAyWlwH9mjx2fedgMVObJVxyOIwdOCVdREz
gNeUJCVhDxkSEoRKnHQgAT+EKIQZ5clI5AlXjygkAVkOILb659IBeT
12TWgkOtN4JBiZtPZg34XI552TNqQSQ0Ym7TEcho/Hww3DCwMAAAEK
6gE8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJ1dGYtMTYiPz
4NCjxFbWFpbFNldD4NCiAgPFZlcnNpb24+MTUuMC4wLjA8L1ZlcnNp
b24+DQogIDxFbWFpbHM+DQogICAgPEVtYWlsIFN0YXJ0SW5kZXg9Ij
ExNyIgUG9zaXRpb249IlNpZ25hdHVyZSI+DQogICAgICA8RW1haWxT
dHJpbmc+YW5kcmV3QGx1bm4uY2g8L0VtYWlsU3RyaW5nPg0KICAgID
wvRW1haWw+DQogIDwvRW1haWxzPg0KPC9FbWFpbFNldD4BDKIEPD94
bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTE2Ij8+DQo8Q2
9udGFjdFNldD4NCiAgPFZlcnNpb24+MTUuMC4wLjA8L1ZlcnNpb24+
DQogIDxDb250YWN0cz4NCiAgICA8Q29udGFjdCBTdGFydEluZGV4PS
IxMDQiIFBvc2l0aW9uPSJTaWduYXR1cmUiPg0KICAgICAgPFBlcnNv
biBTdGFydEluZGV4PSIxMDQiIFBvc2l0aW9uPSJTaWduYXR1cmUiPg
0KICAgICAgICA8UGVyc29uU3RyaW5nPkFuZHJldyBMdW5uPC9QZXJz
b25TdHJpbmc+DQogICAgICA8L1BlcnNvbj4NCiAgICAgIDxFbWFpbH
M+DQogICAgICAgIDxFbWFpbCBTdGFydEluZGV4PSIxMTciIFBvc2l0
aW9uPSJTaWduYXR1cmUiPg0KICAgICAgICAgIDxFbWFpbFN0cmluZz
5hbmRyZXdAbHVubi5jaDwvRW1haWxTdHJpbmc+DQogICAgICAgIDwv
RW1haWw+DQogICAgICA8L0VtYWlscz4NCiAgICAgIDxDb250YWN0U3
RyaW5nPkFuZHJldyBMdW5uICZsdDthbmRyZXdAbHVubi5jaDwvQ29u
dGFjdFN0cmluZz4NCiAgICA8L0NvbnRhY3Q+DQogIDwvQ29udGFjdH
M+DQo8L0NvbnRhY3RTZXQ+AQ7OAVJldHJpZXZlck9wZXJhdG9yLDEw
LDE7UmV0cmlldmVyT3BlcmF0b3IsMTEsMDtQb3N0RG9jUGFyc2VyT3
BlcmF0b3IsMTAsMDtQb3N0RG9jUGFyc2VyT3BlcmF0b3IsMTEsMDtQ
b3N0V29yZEJyZWFrZXJEaWFnbm9zdGljT3BlcmF0b3IsMTAsMDtQb3
N0V29yZEJyZWFrZXJEaWFnbm9zdGljT3BlcmF0b3IsMTEsMDtUcmFu
c3BvcnRXcml0ZXJQcm9kdWNlciwyMCw2
X-MS-Exchange-Forest-IndexAgent: 1 1482
X-MS-Exchange-Forest-EmailMessageHash: BAB86D88
X-MS-Exchange-Forest-Language: en
X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent
On Fri, Mar 29, 2024 at 03:56:57PM +0100, Kory Maincent wrote:
> On Thu, 28 Mar 2024 17:24:17 +0100
> Andrew Lunn <andrew@lunn.ch> wrote:
>
> > > +static int tps23881_flash_fw_part(struct i2c_client *client,
> > > + const char *fw_name,
> > > + const struct tps23881_fw_conf *fw_conf)
> >
> > Does the device actually have flash? Or is this just downloading to
> > SRAM?
>
> It is downloading to SRAM.
So maybe rename these functions.
Andrew
X-sender: <linux-kernel+bounces-125749-steffen.klassert=secunet.com@vger.kernel.org>
X-Receiver: <steffen.klassert@secunet.com> ORCPT=rfc822;steffen.klassert@secunet.com NOTIFY=NEVER; X-ExtendedProps=BQAVABYAAgAAAAUAFAARAPDFCS25BAlDktII2g02frgPADUAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0LkRpcmVjdG9yeURhdGEuSXNSZXNvdXJjZQIAAAUAagAJAAEAAAAAAAAABQAWAAIAAAUAQwACAAAFAEYABwADAAAABQBHAAIAAAUAEgAPAGIAAAAvbz1zZWN1bmV0L291PUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpL2NuPVJlY2lwaWVudHMvY249U3RlZmZlbiBLbGFzc2VydDY4YwUACwAXAL4AAACheZxkHSGBRqAcAp3ukbifQ049REI2LENOPURhdGFiYXNlcyxDTj1FeGNoYW5nZSBBZG1pbmlzdHJhdGl2ZSBHcm91cCAoRllESUJPSEYyM1NQRExUKSxDTj1BZG1pbmlzdHJhdGl2ZSBHcm91cHMsQ049c2VjdW5ldCxDTj1NaWNyb3NvZnQgRXhjaGFuZ2UsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1zZWN1bmV0LERDPWRlBQAOABEABiAS9uuMOkqzwmEZDvWNNQUAHQAPAAwAAABtYngtZXNzZW4tMDIFADwAAgAADwA2AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50LkRpc3BsYXlOYW1lDwARAAAAS2xhc3NlcnQsIFN0ZWZmZW4FAAwAAgAABQBsAAIAAAUAWAAXAEoAAADwxQktuQQJQ5LSCNoNNn64Q049S2xhc3NlcnQgU3RlZmZlbixPVT1Vc2VycyxPVT1NaWdyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUAJgACAAEFACIADwAxAAAAQXV0b1Jlc3BvbnNlU3VwcHJlc3M6IDANClRyYW5zbWl0SGlzdG9yeTogRmFsc2UNCg8ALwAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuRXhwYW5zaW9uR3JvdXBUeXBlDwAVAAAATWVtYmVyc0dyb3VwRXhwYW5zaW9uBQAjAAIAAQ==
X-CreatedBy: MSExchange15
X-HeloDomain: a.mx.secunet.com
X-ExtendedProps: BQBjAAoAwNjp8x1Q3AgFAGEACAABAAAABQA3AAIAAA8APAAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5Pcmdhbml6YXRpb25TY29wZREAAAAAAAAAAAAAAAAAAAAAAAUASQACAAEFAGIACgBuAAAAnIoAAAUABAAUIAEAAAAcAAAAc3RlZmZlbi5rbGFzc2VydEBzZWN1bmV0LmNvbQUABgACAAEFACkAAgABDwAJAAAAQ0lBdWRpdGVkAgABBQACAAcAAQAAAAUAAwAHAAAAAAAFAAUAAgABBQBkAA8AAwAAAEh1Yg==
X-Source: SMTP:Default MBX-DRESDEN-01
X-SourceIPAddress: 62.96.220.36
X-EndOfInjectedXHeaders: 11449
Received: from cas-essen-02.secunet.de (10.53.40.202) by
mbx-dresden-01.secunet.de (10.53.40.199) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2507.37; Sat, 30 Mar 2024 15:53:46 +0100
Received: from a.mx.secunet.com (62.96.220.36) by cas-essen-02.secunet.de
(10.53.40.202) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
Transport; Sat, 30 Mar 2024 15:53:46 +0100
Received: from localhost (localhost [127.0.0.1])
by a.mx.secunet.com (Postfix) with ESMTP id 0092E2087C
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 15:53:46 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -5.051
X-Spam-Level:
X-Spam-Status: No, score=-5.051 tagged_above=-999 required=2.1
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: a.mx.secunet.com (amavisd-new);
dkim=pass (1024-bit key) header.d=lunn.ch
Received: from a.mx.secunet.com ([127.0.0.1])
by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id q78oTPU6yoBB for <steffen.klassert@secunet.com>;
Sat, 30 Mar 2024 15:53:45 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=139.178.88.99; helo=sv.mirrors.kernel.org; envelope-from=linux-kernel+bounces-125749-steffen.klassert=secunet.com@vger.kernel.org; receiver=steffen.klassert@secunet.com
DKIM-Filter: OpenDKIM Filter v2.11.0 a.mx.secunet.com 3C0B120847
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by a.mx.secunet.com (Postfix) with ESMTPS id 3C0B120847
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 15:53:45 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 423C9282229
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 14:53:43 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 9648539FD4;
Sat, 30 Mar 2024 14:53:25 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="AgKIFxWL"
Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by smtp.subspace.kernel.org (Postfix) with ESMTPS id AD8311C0DEF;
Sat, 30 Mar 2024 14:53:20 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=156.67.10.101
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1711810403; cv=none; b=VrO6J8Hi+SBymX6+G5k3Ud8x7blzHf4q7Un8U6HDTfCcAzT4feZ1IAepX0YzqrNRbWaj6sVRlwcJW0hQh2XaqpefkR4Sl2gkocyv4v1p3KRon1liM9mPgLHk8XrtVDkI9/lTyxhV5mKiovFXgO/D2P2uamXtEBKUKCzDezwG5NM=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1711810403; c=relaxed/simple;
bh=gJx0oB7ZzuoCNKkwsr1UzGLJ3CRfFELmHureG9uOYGw=;
h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
Content-Type:Content-Disposition:In-Reply-To; b=oDelDfSdHTx21mIJ0hem715uqMg/JEbBvu+QI/n4j2Dk5mc8GbK+VtSdOJISO50a39BBZcXcTZecoAszKR55fvrHsgPXRjIkkmjNpNVTs/51Np0JtRcq77T52D8q+mY13M2OFNo9qBat6UJf/PFGufjBrguPYjOpPuK3LA1Ni/8=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lunn.ch; spf=pass smtp.mailfrom=lunn.ch; dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b=AgKIFxWL; arc=none smtp.client-ip=156.67.10.101
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lunn.ch
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lunn.ch
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch;
s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version:
References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject:
Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:
Content-ID:Content-Description:Content-Disposition:In-Reply-To:References;
bh=caGVOX2RZ69c4hjscPFCuCKDrFK7z35V6qvgjgO6mvs=; b=AgKIFxWLgU4PMlGPkeuWts4Sdx
C1uk2GClcr5WI35QPJ/c+zppgblTWKdov5NwQ4Y/rlf4kRO+pXEefeYiuH/9vvqcMMhtsW5bKoOSc
ptiP23T99yvkYQ4yFYT1LkW6GjFn1aaNnXMQ/2LbdTSWKkldN1777vtFbSTbTQ5A4V60=;
Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2)
(envelope-from <andrew@lunn.ch>)
id 1rqa4f-00Bj1W-9i; Sat, 30 Mar 2024 15:52:49 +0100
Date: Sat, 30 Mar 2024 15:52:49 +0100
From: Andrew Lunn <andrew@lunn.ch>
To: Kory Maincent <kory.maincent@bootlin.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Jonathan Corbet <corbet@lwn.net>,
Luis Chamberlain <mcgrof@kernel.org>,
Russ Weight <russ.weight@linux.dev>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Oleksij Rempel <o.rempel@pengutronix.de>,
Mark Brown <broonie@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, devicetree@vger.kernel.org,
Dent Project <dentproject@linuxfoundation.org>
Subject: Re: [PATCH net-next v6 17/17] net: pse-pd: Add TI TPS23881 PSE
controller driver
Message-ID: <8186fea6-c1f4-403b-b717-83c1dd3ad826@lunn.ch>
References: <20240326-feature_poe-v6-0-c1011b6ea1cb@bootlin.com>
<20240326-feature_poe-v6-17-c1011b6ea1cb@bootlin.com>
<6bbc6b86-3947-4679-ac0b-fde50129d0f6@lunn.ch>
<20240329155657.7939ac4b@kmaincent-XPS-13-7390>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240329155657.7939ac4b@kmaincent-XPS-13-7390>
Return-Path: linux-kernel+bounces-125749-steffen.klassert=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 30 Mar 2024 14:53:46.0227
(UTC)
X-MS-Exchange-Organization-Network-Message-Id: 4173286b-f2f8-48eb-586a-08dc50c9335e
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.36
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.202
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-02.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=mbx-dresden-01.secunet.de:TOTAL-HUB=0.409|SMR=0.340(SMRDE=0.035|SMRC=0.305(SMRCL=0.100|X-SMRCR=0.305))|CAT=0.068(CATOS=0.011
(CATSM=0.011(CATSM-Malware
Agent=0.010))|CATRESL=0.040(CATRESLP2R=0.018)|CATORES=0.014
(CATRS=0.014(CATRS-Index Routing Agent=0.013)));2024-03-30T14:53:46.467Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-dresden-01.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-02.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-FromEntityHeader: Internet
X-MS-Exchange-Organization-OriginalSize: 7799
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageLatency: SRV=cas-essen-02.secunet.de:TOTAL-FE=0.034|SMR=0.007(SMRPI=0.005(SMRPI-FrontendProxyAgent=0.005))|SMS=0.028
X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
X-MS-Exchange-Organization-Recipient-Limit-Verified: True
X-MS-Exchange-Organization-TotalRecipientCount: 1
X-MS-Exchange-Organization-Rules-Execution-History: 0b0cf904-14ac-4724-8bdf-482ee6223cf2%%%fd34672d-751c-45ae-a963-ed177fcabe23%%%d8080257-b0c3-47b4-b0db-23bc0c8ddb3c%%%95e591a2-5d7d-4afa-b1d0-7573d6c0a5d9%%%f7d0f6bc-4dcc-4876-8c5d-b3d6ddbb3d55%%%16355082-c50b-4214-9c7d-d39575f9f79b
X-MS-Exchange-Forest-RulesExecuted: mbx-dresden-01
X-MS-Exchange-Organization-RulesExecuted: mbx-dresden-01
X-MS-Exchange-Forest-IndexAgent-0: AQ0CZW4AAdkBAAAPAAADH4sIAAAAAAAEAJWRTU/bQBCGx5+xDalQD5
znWEiEHANNalVQpKpS1UZUpXdru9nUrswa2Wus/AV+NTNrCuqhh9qr
zc7M+z4z6zz41xo/tdUc16LF7N0cszQ7Q2EwPc3P3+bny29rnKWLNJ
3jl6bdkazSUmmDQ9sYlU+TCyTCj7In52qEMGCxzLOzfLEcvay60ptW
Dfi11xrfCxt8qCk4keXFC4yV/M46I0wlsaJO5q7LTlerRbGtRVcW26
G4E61505m2lwarTBayrnik4/F3/gzBfz+y0Z1BWdLAx0TU4lb9h++p
98tkQ0GFrUXx4ciiRt7HRnVoSoUbdV9JhUKaXtT1Dktxr9De6RKvW6
xYRdvvnhpsmkHXjdhU+heaZgTdfL9aXz59o8+G9X+rrOBkmkyTmwZv
xe6nwlbxxbh7R616LU1F81vNnwuN/wtnAFzwPAg8B/Zpge+C70PgOl
7kQAS0IjoHAAFMKB9BHEAyWlwH9mjx2fedgMVObJVxyOIwdOCVdREz
gNeUJCVhDxkSEoRKnHQgAT+EKIQZ5clI5AlXjygkAVkOILb659IBeT
12TWgkOtN4JBiZtPZg34XI552TNqQSQ0Ym7TEcho/Hww3DCwMAAAEK
6gE8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJ1dGYtMTYiPz
4NCjxFbWFpbFNldD4NCiAgPFZlcnNpb24+MTUuMC4wLjA8L1ZlcnNp
b24+DQogIDxFbWFpbHM+DQogICAgPEVtYWlsIFN0YXJ0SW5kZXg9Ij
ExNyIgUG9zaXRpb249IlNpZ25hdHVyZSI+DQogICAgICA8RW1haWxT
dHJpbmc+YW5kcmV3QGx1bm4uY2g8L0VtYWlsU3RyaW5nPg0KICAgID
wvRW1haWw+DQogIDwvRW1haWxzPg0KPC9FbWFpbFNldD4BDKIEPD94
bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTE2Ij8+DQo8Q2
9udGFjdFNldD4NCiAgPFZlcnNpb24+MTUuMC4wLjA8L1ZlcnNpb24+
DQogIDxDb250YWN0cz4NCiAgICA8Q29udGFjdCBTdGFydEluZGV4PS
IxMDQiIFBvc2l0aW9uPSJTaWduYXR1cmUiPg0KICAgICAgPFBlcnNv
biBTdGFydEluZGV4PSIxMDQiIFBvc2l0aW9uPSJTaWduYXR1cmUiPg
0KICAgICAgICA8UGVyc29uU3RyaW5nPkFuZHJldyBMdW5uPC9QZXJz
b25TdHJpbmc+DQogICAgICA8L1BlcnNvbj4NCiAgICAgIDxFbWFpbH
M+DQogICAgICAgIDxFbWFpbCBTdGFydEluZGV4PSIxMTciIFBvc2l0
aW9uPSJTaWduYXR1cmUiPg0KICAgICAgICAgIDxFbWFpbFN0cmluZz
5hbmRyZXdAbHVubi5jaDwvRW1haWxTdHJpbmc+DQogICAgICAgIDwv
RW1haWw+DQogICAgICA8L0VtYWlscz4NCiAgICAgIDxDb250YWN0U3
RyaW5nPkFuZHJldyBMdW5uICZsdDthbmRyZXdAbHVubi5jaDwvQ29u
dGFjdFN0cmluZz4NCiAgICA8L0NvbnRhY3Q+DQogIDwvQ29udGFjdH
M+DQo8L0NvbnRhY3RTZXQ+AQ7OAVJldHJpZXZlck9wZXJhdG9yLDEw
LDE7UmV0cmlldmVyT3BlcmF0b3IsMTEsMTtQb3N0RG9jUGFyc2VyT3
BlcmF0b3IsMTAsMDtQb3N0RG9jUGFyc2VyT3BlcmF0b3IsMTEsMDtQ
b3N0V29yZEJyZWFrZXJEaWFnbm9zdGljT3BlcmF0b3IsMTAsMDtQb3
N0V29yZEJyZWFrZXJEaWFnbm9zdGljT3BlcmF0b3IsMTEsMDtUcmFu
c3BvcnRXcml0ZXJQcm9kdWNlciwyMCw2
X-MS-Exchange-Forest-IndexAgent: 1 1482
X-MS-Exchange-Forest-EmailMessageHash: BAB86D88
X-MS-Exchange-Forest-Language: en
X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent
On Fri, Mar 29, 2024 at 03:56:57PM +0100, Kory Maincent wrote:
> On Thu, 28 Mar 2024 17:24:17 +0100
> Andrew Lunn <andrew@lunn.ch> wrote:
>
> > > +static int tps23881_flash_fw_part(struct i2c_client *client,
> > > + const char *fw_name,
> > > + const struct tps23881_fw_conf *fw_conf)
> >
> > Does the device actually have flash? Or is this just downloading to
> > SRAM?
>
> It is downloading to SRAM.
So maybe rename these functions.
Andrew
^ permalink raw reply
* Re: [PATCH 3/3] drm: panel: Add LG sw43408 panel driver
From: Marijn Suijten @ 2024-03-30 10:27 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Sumit Semwal, Caleb Connolly, Neil Armstrong, Jessica Zhang,
Sam Ravnborg, David Airlie, Daniel Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, dri-devel, devicetree,
linux-kernel, linux-arm-msm, Vinod Koul, Caleb Connolly
In-Reply-To: <20240330-lg-sw43408-panel-v1-3-f5580fc9f2da@linaro.org>
On 2024-03-30 05:59:30, Dmitry Baryshkov wrote:
> From: Sumit Semwal <sumit.semwal@linaro.org>
>
> LG SW43408 is 1080x2160, 4-lane MIPI-DSI panel, used in some Pixel3
> phones.
>
> Whatever init sequence we have for this panel isn't capable of
> initialising it completely, toggling the reset gpio ever causes the
> panel to die. Until this is resolved we avoid resetting the panel. The
Are you sure it is avoided? This patch seems to be toggling reset_gpio in
sw43408_prepare()?
> disable/unprepare functions only put the panel to sleep mode and
> disable the backlight.
>
> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
> [vinod: Add DSC support]
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
> [caleb: cleanup and support turning off the panel]
> Signed-off-by: Caleb Connolly <caleb@connolly.tech>
> [DB: partially rewrote the driver and fixed DSC programming]
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> MAINTAINERS | 8 +
> drivers/gpu/drm/panel/Kconfig | 11 ++
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-lg-sw43408.c | 322 +++++++++++++++++++++++++++++++
> 4 files changed, 342 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4b511a55101c..f4cf7ee97376 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6755,6 +6755,14 @@ S: Maintained
> F: Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
> F: drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
>
> +DRM DRIVER FOR LG SW43408 PANELS
> +M: Sumit Semwal <sumit.semwal@linaro.org>
> +M: Caleb Connolly <caleb.connolly@linaro.org>
> +S: Maintained
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +F: Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml
> +F: drivers/gpu/drm/panel/panel-lg-sw43408.c
> +
> DRM DRIVER FOR LOGICVC DISPLAY CONTROLLER
> M: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> S: Supported
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index d037b3b8b999..f94c702735cb 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -335,6 +335,17 @@ config DRM_PANEL_LG_LG4573
> Say Y here if you want to enable support for LG4573 RGB panel.
> To compile this driver as a module, choose M here.
>
> +config DRM_PANEL_LG_SW43408
> + tristate "LG SW43408 panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> + Say Y here if you want to enable support for LG sw43408 panel.
> + The panel has a 1080x2160 resolution and uses
> + 24 bit RGB per pixel. It provides a MIPI DSI interface to
> + the host and has a built-in LED backlight.
> +
> config DRM_PANEL_MAGNACHIP_D53E6EA8966
> tristate "Magnachip D53E6EA8966 DSI panel"
> depends on OF && SPI
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index f156d7fa0bcc..a75687d13caf 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -34,6 +34,7 @@ obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) += panel-leadtek-ltk050h3146w.o
> obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
> obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
> obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
> +obj-$(CONFIG_DRM_PANEL_LG_SW43408) += panel-lg-sw43408.o
> obj-$(CONFIG_DRM_PANEL_MAGNACHIP_D53E6EA8966) += panel-magnachip-d53e6ea8966.o
> obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
> obj-$(CONFIG_DRM_PANEL_NEWVISION_NV3051D) += panel-newvision-nv3051d.o
> diff --git a/drivers/gpu/drm/panel/panel-lg-sw43408.c b/drivers/gpu/drm/panel/panel-lg-sw43408.c
> new file mode 100644
> index 000000000000..365d25e14d54
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-lg-sw43408.c
> @@ -0,0 +1,322 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019-2024 Linaro Ltd
> + * Author: Sumit Semwal <sumit.semwal@linaro.org>
> + * Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> + */
> +
> +#include <linux/backlight.h>
> +#include <linux/delay.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <video/mipi_display.h>
> +
> +#include <drm/drm_mipi_dsi.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_probe_helper.h>
> +#include <drm/display/drm_dsc.h>
> +#include <drm/display/drm_dsc_helper.h>
> +
> +#define NUM_SUPPLIES 2
> +
> +struct sw43408_panel {
> + struct drm_panel base;
> + struct mipi_dsi_device *link;
> +
> + const struct drm_display_mode *mode;
> +
> + struct regulator_bulk_data supplies[NUM_SUPPLIES];
> +
> + struct gpio_desc *reset_gpio;
> +};
> +
> +static inline struct sw43408_panel *to_panel_info(struct drm_panel *panel)
> +{
> + return container_of(panel, struct sw43408_panel, base);
> +}
> +
> +static int sw43408_unprepare(struct drm_panel *panel)
> +{
> + struct sw43408_panel *ctx = to_panel_info(panel);
> + int ret;
> +
> + ret = mipi_dsi_dcs_set_display_off(ctx->link);
> + if (ret < 0)
> + dev_err(panel->dev, "set_display_off cmd failed ret = %d\n", ret);
> +
> + ret = mipi_dsi_dcs_enter_sleep_mode(ctx->link);
> + if (ret < 0)
> + dev_err(panel->dev, "enter_sleep cmd failed ret = %d\n", ret);
> +
> + msleep(100);
> +
> + gpiod_set_value(ctx->reset_gpio, 1);
> +
> + return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> +}
> +
> +static int sw43408_program(struct drm_panel *panel)
> +{
> + struct sw43408_panel *ctx = to_panel_info(panel);
> + struct drm_dsc_picture_parameter_set pps;
> + u8 dsc_en = 0x11;
Yeah, this is completely strange. Bit 0, 0x1, is to enable DSC which is
normal. 0x10 however, which is bit 4, selects PPS table 2. Do you ever set
pps_identifier in struct drm_dsc_picture_parameter_set to 2? Or is the table
that you send below bogus and/or not used? Maybe the Driver IC on the other
end of the DSI link has a default PPS table with identifier 2 that works out of
the box?
> + mipi_dsi_dcs_write_seq(ctx->link, MIPI_DCS_SET_GAMMA_CURVE, 0x02);
> +
> + mipi_dsi_dcs_set_tear_on(ctx->link, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
> +
> + mipi_dsi_dcs_write_seq(ctx->link, 0x53, 0x0c, 0x30);
> + mipi_dsi_dcs_write_seq(ctx->link, 0x55, 0x00, 0x70, 0xdf, 0x00, 0x70, 0xdf);
> + mipi_dsi_dcs_write_seq(ctx->link, 0xf7, 0x01, 0x49, 0x0c);
> +
> + mipi_dsi_dcs_exit_sleep_mode(ctx->link);
> +
> + msleep(135);
> +
> + mipi_dsi_compression_mode_raw(ctx->link, &dsc_en, 1);
Even though I think we should change this function to describe the known
bit layout of command 0x7 per the VESA DSI spec, for now replace 1 with
sizeof(dsc_en)?
> +
> + mipi_dsi_dcs_write_seq(ctx->link, 0xb0, 0xac);
> + mipi_dsi_dcs_write_seq(ctx->link, 0xe5,
> + 0x00, 0x3a, 0x00, 0x3a, 0x00, 0x0e, 0x10);
> + mipi_dsi_dcs_write_seq(ctx->link, 0xb5,
> + 0x75, 0x60, 0x2d, 0x5d, 0x80, 0x00, 0x0a, 0x0b,
> + 0x00, 0x05, 0x0b, 0x00, 0x80, 0x0d, 0x0e, 0x40,
> + 0x00, 0x0c, 0x00, 0x16, 0x00, 0xb8, 0x00, 0x80,
> + 0x0d, 0x0e, 0x40, 0x00, 0x0c, 0x00, 0x16, 0x00,
> + 0xb8, 0x00, 0x81, 0x00, 0x03, 0x03, 0x03, 0x01,
> + 0x01);
> + msleep(85);
> + mipi_dsi_dcs_write_seq(ctx->link, 0xcd,
> + 0x00, 0x00, 0x00, 0x19, 0x19, 0x19, 0x19, 0x19,
> + 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19,
> + 0x16, 0x16);
> + mipi_dsi_dcs_write_seq(ctx->link, 0xcb, 0x80, 0x5c, 0x07, 0x03, 0x28);
> + mipi_dsi_dcs_write_seq(ctx->link, 0xc0, 0x02, 0x02, 0x0f);
> + mipi_dsi_dcs_write_seq(ctx->link, 0x55, 0x04, 0x61, 0xdb, 0x04, 0x70, 0xdb);
> + mipi_dsi_dcs_write_seq(ctx->link, 0xb0, 0xca);
> +
> + mipi_dsi_dcs_set_display_on(ctx->link);
Any specific reason to not have the (un)blanking sequence in the enable/disable
callbacks and leaving display configuration in (un)prepare?
> + msleep(50);
> +
> + ctx->link->mode_flags &= ~MIPI_DSI_MODE_LPM;
> +
> + drm_dsc_pps_payload_pack(&pps, ctx->link->dsc);
> + mipi_dsi_picture_parameter_set(ctx->link, &pps);
I'm always surprised why this is sent _after_ turning the display on (unblanking
it). Wouldn't that cause unnecessary corruption?
> +
> + ctx->link->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> + return 0;
> +}
> +
> +static int sw43408_prepare(struct drm_panel *panel)
> +{
> + struct sw43408_panel *ctx = to_panel_info(panel);
> + int ret;
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> + if (ret < 0)
> + return ret;
> +
> + usleep_range(5000, 6000);
> +
> + gpiod_set_value(ctx->reset_gpio, 0);
> + usleep_range(9000, 10000);
> + gpiod_set_value(ctx->reset_gpio, 1);
> + usleep_range(1000, 2000);
> + gpiod_set_value(ctx->reset_gpio, 0);
> + usleep_range(9000, 10000);
> +
> + ret = sw43408_program(panel);
> + if (ret)
> + goto poweroff;
> +
> + return 0;
> +
> +poweroff:
> + gpiod_set_value(ctx->reset_gpio, 1);
> + regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> + return ret;
> +}
> +
> +static int sw43408_get_modes(struct drm_panel *panel,
> + struct drm_connector *connector)
> +{
> + struct sw43408_panel *ctx = to_panel_info(panel);
> +
> + return drm_connector_helper_get_modes_fixed(connector, ctx->mode);
> +}
> +
> +static int sw43408_backlight_update_status(struct backlight_device *bl)
> +{
> + struct mipi_dsi_device *dsi = bl_get_data(bl);
> + uint16_t brightness = backlight_get_brightness(bl);
> +
> + return mipi_dsi_dcs_set_display_brightness_large(dsi, brightness);
> +}
> +
> +const struct backlight_ops sw43408_backlight_ops = {
> + .update_status = sw43408_backlight_update_status,
> +};
> +
> +static int sw43408_backlight_init(struct sw43408_panel *ctx)
> +{
> + struct device *dev = &ctx->link->dev;
> + const struct backlight_properties props = {
> + .type = BACKLIGHT_PLATFORM,
> + .brightness = 255,
> + .max_brightness = 255,
> + };
> +
> + ctx->base.backlight = devm_backlight_device_register(dev, dev_name(dev), dev,
> + ctx->link,
> + &sw43408_backlight_ops,
> + &props);
> +
> + if (IS_ERR(ctx->base.backlight))
> + return dev_err_probe(dev, PTR_ERR(ctx->base.backlight),
> + "Failed to create backlight\n");
> +
> + return 0;
> +}
> +
> +static const struct drm_panel_funcs sw43408_funcs = {
> + .unprepare = sw43408_unprepare,
> + .prepare = sw43408_prepare,
> + .get_modes = sw43408_get_modes,
> +};
> +
> +static const struct drm_display_mode sw43408_default_mode = {
> + .clock = 152340,
> +
> + .hdisplay = 1080,
> + .hsync_start = 1080 + 20,
> + .hsync_end = 1080 + 20 + 32,
> + .htotal = 1080 + 20 + 32 + 20,
> +
> + .vdisplay = 2160,
> + .vsync_start = 2160 + 20,
> + .vsync_end = 2160 + 20 + 4,
> + .vtotal = 2160 + 20 + 4 + 20,
> +
> + .width_mm = 62,
> + .height_mm = 124,
> +
> + .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> +};
> +
> +static const struct of_device_id sw43408_of_match[] = {
> + { .compatible = "lg,sw43408", .data = &sw43408_default_mode },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, sw43408_of_match);
> +
> +static int sw43408_add(struct sw43408_panel *ctx)
> +{
> + struct device *dev = &ctx->link->dev;
> + int ret;
> +
> + ctx->supplies[0].supply = "vddi"; /* 1.88 V */
> + ctx->supplies[0].init_load_uA = 62000;
> + ctx->supplies[1].supply = "vpnl"; /* 3.0 V */
> + ctx->supplies[1].init_load_uA = 857000;
> +
> + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies),
> + ctx->supplies);
> + if (ret < 0)
> + return ret;
> +
> + ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(ctx->reset_gpio)) {
> + dev_err(dev, "cannot get reset gpio %ld\n",
> + PTR_ERR(ctx->reset_gpio));
> + return PTR_ERR(ctx->reset_gpio);
> + }
> +
> + ret = sw43408_backlight_init(ctx);
> + if (ret < 0)
> + return ret;
> +
> + ctx->base.prepare_prev_first = true;
> +
> + drm_panel_init(&ctx->base, dev, &sw43408_funcs, DRM_MODE_CONNECTOR_DSI);
> +
> + drm_panel_add(&ctx->base);
> + return ret;
> +}
> +
> +static int sw43408_probe(struct mipi_dsi_device *dsi)
> +{
> + struct sw43408_panel *ctx;
> + struct drm_dsc_config *dsc;
> + int ret;
> +
> + ctx = devm_kzalloc(&dsi->dev, sizeof(*ctx), GFP_KERNEL);
> + if (!ctx)
> + return -ENOMEM;
> +
> + ctx->mode = of_device_get_match_data(&dsi->dev);
> + dsi->mode_flags = MIPI_DSI_MODE_LPM;
> + dsi->format = MIPI_DSI_FMT_RGB888;
> + dsi->lanes = 4;
> +
> + ctx->link = dsi;
> + mipi_dsi_set_drvdata(dsi, ctx);
> +
> + ret = sw43408_add(ctx);
> + if (ret < 0)
> + return ret;
> +
> + /* The panel is DSC panel only, set the dsc params */
> + dsc = devm_kzalloc(&dsi->dev, sizeof(*dsc), GFP_KERNEL);
We've recently decided to store struct drm_dsc_config in struct sw43408_panel
and save on an extra allocation.
> + if (!dsc)
> + return -ENOMEM;
> +
> + dsc->dsc_version_major = 0x1;
> + dsc->dsc_version_minor = 0x1;
> +
> + dsc->slice_height = 16;
> + dsc->slice_width = 540;
> + dsc->slice_count = 2;
Maybe incorporate with a comment that slice_count * slice_width == the width of
the mode?
- Marijn
> + dsc->bits_per_component = 8;
> + dsc->bits_per_pixel = 8 << 4;
> + dsc->block_pred_enable = true;
> +
> + dsi->dsc = dsc;
> +
> + return mipi_dsi_attach(dsi);
> +}
> +
> +static void sw43408_remove(struct mipi_dsi_device *dsi)
> +{
> + struct sw43408_panel *ctx = mipi_dsi_get_drvdata(dsi);
> + int ret;
> +
> + ret = sw43408_unprepare(&ctx->base);
> + if (ret < 0)
> + dev_err(&dsi->dev, "failed to unprepare panel: %d\n",
> + ret);
> +
> + ret = mipi_dsi_detach(dsi);
> + if (ret < 0)
> + dev_err(&dsi->dev, "failed to detach from DSI host: %d\n", ret);
> +
> + drm_panel_remove(&ctx->base);
> +}
> +
> +static struct mipi_dsi_driver sw43408_driver = {
> + .driver = {
> + .name = "panel-lg-sw43408",
> + .of_match_table = sw43408_of_match,
> + },
> + .probe = sw43408_probe,
> + .remove = sw43408_remove,
> +};
> +module_mipi_dsi_driver(sw43408_driver);
> +
> +MODULE_AUTHOR("Sumit Semwal <sumit.semwal@linaro.org>");
> +MODULE_DESCRIPTION("LG SW436408 MIPI-DSI LED panel");
> +MODULE_LICENSE("GPL");
>
> --
> 2.39.2
>
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: mfd: x-powers,axp152: add boost regulator
From: Andre Przywara @ 2024-03-30 21:40 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Chen-Yu Tsai, Lee Jones, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree, linux-kernel,
linux-sunxi, Jernej Skrabec, Samuel Holland, Ryan Walklin,
Chris Morgan
In-Reply-To: <0b53cf44-b5ca-4ccc-9912-777b85f1bcbd@linaro.org>
On Sat, 30 Mar 2024 10:30:05 +0100
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
Hi,
> On 30/03/2024 00:50, Andre Przywara wrote:
> > The X-Powers AXP717 contains a boost regulator, that it meant to provide
> > the 5V USB VBUS voltage when the devices operates on battery.
> >
> > Add the name "boost" to the regexp describing the allowed node names,
> > to allow the regulator to be described in the devicetree.
> >
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> > Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
> > index b8e8db0d58e9c..14ab367fc8871 100644
> > --- a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
> > +++ b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
> > @@ -274,7 +274,7 @@ properties:
> > Defines the work frequency of DC-DC in kHz.
> >
> > patternProperties:
> > - "^(([a-f])?ldo[0-9]|dcdc[0-7a-e]|ldo(_|-)io(0|1)|(dc1)?sw|rtc(_|-)ldo|cpusldo|drivevbus|dc5ldo)$":
> > + "^(([a-f])?ldo[0-9]|dcdc[0-7a-e]|ldo(_|-)io(0|1)|(dc1)?sw|rtc(_|-)ldo|cpusldo|drivevbus|dc5ldo|boost)$":
>
> That's not an easy to read regex...
TBH regexps are the least of my problems when reading bindings ;-)
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Thanks!
> If driver does not depend on _, please consider dropping (_|-).
The drivers (checked both Linux and FreeBSD) do look for a specific
string, but it's the real old regulators that used ldo_io[01] and
rtc_ldo, all the "newer" ones use a dash. Since this binding covers all
of them, we can't drop this from this regexp, but rest assured we only
go with dashes for new and upcoming devices.
Thanks,
Andre
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: power: Add mediatek larb definition
From: kernel test robot @ 2024-03-31 15:02 UTC (permalink / raw)
To: yu-chang.lee, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ulf Hansson, Matthias Brugger, AngeloGioacchino Del Regno,
MandyJH Liu
Cc: oe-kbuild-all, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, fan.chen, xiufeng.li,
yu-chang.lee
In-Reply-To: <20240327055732.28198-3-yu-chang.lee@mediatek.com>
Hi yu-chang.lee,
kernel test robot noticed the following build warnings:
[auto build test WARNING on robh/for-next]
[also build test WARNING on krzk-dt/for-next linus/master v6.9-rc1 next-20240328]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/yu-chang-lee/pmdomain-mediatek-add-smi_larb_reset-function-when-power-on/20240327-140007
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link: https://lore.kernel.org/r/20240327055732.28198-3-yu-chang.lee%40mediatek.com
patch subject: [PATCH v2 2/3] dt-bindings: power: Add mediatek larb definition
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20240331/202403312222.fjYPC06h-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202403312222.fjYPC06h-lkp@intel.com/
dtcheck warnings: (new ones prefixed by >>)
>> Documentation/devicetree/bindings/power/mediatek,power-controller.yaml:128:6: [error] syntax error: expected <block end>, but found '<block mapping start>' (syntax)
>> Documentation/devicetree/bindings/power/mediatek,power-controller.yaml:129:9: [warning] wrong indentation: expected 7 but found 8 (indentation)
--
>> Documentation/devicetree/bindings/power/mediatek,power-controller.yaml:128:6: did not find expected key
>> Documentation/devicetree/bindings/mfd/mediatek,mt8195-scpsys.yaml:
while parsing a block mapping
in "<unicode string>", line 64, column 5
did not find expected key
in "<unicode string>", line 128, column 6
--
>> Documentation/devicetree/bindings/power/mediatek,power-controller.yaml: ignoring, error parsing file
vim +128 Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
8
9 maintainers:
10 - MandyJH Liu <mandyjh.liu@mediatek.com>
11 - Matthias Brugger <mbrugger@suse.com>
12
13 description: |
14 Mediatek processors include support for multiple power domains which can be
15 powered up/down by software based on different application scenes to save power.
16
17 IP cores belonging to a power domain should contain a 'power-domains'
18 property that is a phandle for SCPSYS node representing the domain.
19
20 properties:
21 $nodename:
22 pattern: '^power-controller(@[0-9a-f]+)?$'
23
24 compatible:
25 enum:
26 - mediatek,mt6795-power-controller
27 - mediatek,mt8167-power-controller
28 - mediatek,mt8173-power-controller
29 - mediatek,mt8183-power-controller
30 - mediatek,mt8186-power-controller
31 - mediatek,mt8188-power-controller
32 - mediatek,mt8192-power-controller
33 - mediatek,mt8195-power-controller
34 - mediatek,mt8365-power-controller
35
36 '#power-domain-cells':
37 const: 1
38
39 '#address-cells':
40 const: 1
41
42 '#size-cells':
43 const: 0
44
45 patternProperties:
46 "^power-domain@[0-9a-f]+$":
47 $ref: "#/$defs/power-domain-node"
48 patternProperties:
49 "^power-domain@[0-9a-f]+$":
50 $ref: "#/$defs/power-domain-node"
51 patternProperties:
52 "^power-domain@[0-9a-f]+$":
53 $ref: "#/$defs/power-domain-node"
54 patternProperties:
55 "^power-domain@[0-9a-f]+$":
56 $ref: "#/$defs/power-domain-node"
57 unevaluatedProperties: false
58 unevaluatedProperties: false
59 unevaluatedProperties: false
60 unevaluatedProperties: false
61
62 $defs:
63 power-domain-node:
64 type: object
65 description: |
66 Represents the power domains within the power controller node as documented
67 in Documentation/devicetree/bindings/power/power-domain.yaml.
68
69 properties:
70
71 '#power-domain-cells':
72 description:
73 Must be 0 for nodes representing a single PM domain and 1 for nodes
74 providing multiple PM domains.
75
76 '#address-cells':
77 const: 1
78
79 '#size-cells':
80 const: 0
81
82 reg:
83 description: |
84 Power domain index. Valid values are defined in:
85 "include/dt-bindings/power/mt6795-power.h" - for MT8167 type power domain.
86 "include/dt-bindings/power/mt8167-power.h" - for MT8167 type power domain.
87 "include/dt-bindings/power/mt8173-power.h" - for MT8173 type power domain.
88 "include/dt-bindings/power/mt8183-power.h" - for MT8183 type power domain.
89 "include/dt-bindings/power/mediatek,mt8188-power.h" - for MT8188 type power domain.
90 "include/dt-bindings/power/mt8192-power.h" - for MT8192 type power domain.
91 "include/dt-bindings/power/mt8195-power.h" - for MT8195 type power domain.
92 "include/dt-bindings/power/mediatek,mt8365-power.h" - for MT8365 type power domain.
93 maxItems: 1
94
95 clocks:
96 description: |
97 A number of phandles to clocks that need to be enabled during domain
98 power-up sequencing.
99
100 clock-names:
101 description: |
102 List of names of clocks, in order to match the power-up sequencing
103 for each power domain we need to group the clocks by name. BASIC
104 clocks need to be enabled before enabling the corresponding power
105 domain, and should not have a '-' in their name (i.e mm, mfg, venc).
106 SUSBYS clocks need to be enabled before releasing the bus protection,
107 and should contain a '-' in their name (i.e mm-0, isp-0, cam-0).
108
109 In order to follow properly the power-up sequencing, the clocks must
110 be specified by order, adding first the BASIC clocks followed by the
111 SUSBSYS clocks.
112
113 domain-supply:
114 description: domain regulator supply.
115
116 mediatek,infracfg:
117 $ref: /schemas/types.yaml#/definitions/phandle
118 description: phandle to the device containing the INFRACFG register range.
119
120 mediatek,infracfg-nao:
121 $ref: /schemas/types.yaml#/definitions/phandle
122 description: phandle to the device containing the INFRACFG-NAO register range.
123
124 mediatek,smi:
125 $ref: /schemas/types.yaml#/definitions/phandle
126 description: phandle to the device containing the SMI register range.
127
> 128 mediatek,larb:
> 129 $ref: /schemas/types.yaml#/definitions/phandle
130 description: phandle to the device containing the LARB register range.
131
132 required:
133 - reg
134
135 required:
136 - compatible
137
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v6 0/4] fpga: xilinx-selectmap: add new driver
From: Xu Yilun @ 2024-03-31 14:50 UTC (permalink / raw)
To: Charles Perry
Cc: mdf, avandiver, bcody, Wu Hao, Xu Yilun, Tom Rix, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Michal Simek, linux-fpga,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20240321220447.3260065-1-charles.perry@savoirfairelinux.com>
On Thu, Mar 21, 2024 at 06:04:32PM -0400, Charles Perry wrote:
> Hello,
>
> This patchset adds a new driver for the 7 series FPGA's SelectMAP
> interface.
>
> The SelectMAP interface shares a common GPIO protocol with the SPI
> interface which is already in the kernel (drivers/fpga/xilinx-spi.c).
> The approach proposed in this patchset is to refactor xilinx-spi.c into
> xilinx-core.c which would handle the common GPIO protocol. This is then
> used to build two drivers, the already existing xilinx-spi.c driver and
> a newly added xilinx-selectmap.c driver.
>
> The SelectMAP driver proposed only supports 8 bit mode. This is because
> the 16 and 32 bits mode have limitations with regards to compressed
> bitstream support as well as introducing endianness considerations.
>
> I'm testing xilinx-selectmap.c on a custom i.MX6 board connected to an
> Artix 7 FPGA. Flashing a 913K bitstream takes 0.44 seconds.
>
> Changes since v5: (from Yilun review)
> * xilinx-core.h: remove private fields kernel-doc
> * xilinx-spi.c: rename conf into core in xilinx_spi_probe
> * xilinx-core.c: introduce the new gpio names in patch 4/4
> * xilinx-core.c: remove kernel-doc on xilinx_core_devm_gpiod_get()
> * xilinx-selectmap.c:
> * reorder includes in alphabetical order
> * xilinx_selectmap_probe(): remove unused resource *r variable
> * xilinx_selectmap_probe(): use a single gpio_desc* temporary
> * xilinx_selectmap_probe(): declare variables in reverse xmas tree
>
> Changes since v4: (from Yilun and Krzysztof review)
> * xilinx-core: use sizeof() instead of hardcoded immediate
> * xilinx-core: fix module compilation (EXPORT_SYMBOL_GPL, MODULE_LICENSE,
> MODULE_AUTHOR, MODULE_DESCRIPTION)
> * xilinx-core: add private/public qualifiers for struct xilinx_fpga_core
> * xilinx-spi: remove struct xilinx_spi_conf. This struct isn't needed as
> the struct spi_device* can be retrieved from the struct device*.
> * dt-bindings: remove usage of "_b" and "-b" for the new driver. We
> agreed that the spi and selectmap driver will use different bindings
> which will be handled by the driver core and that the legacy names will
> be used only for the spi compatible.
> * xilinx-core: select between prog/init and prog_b/init-b
>
> Changes since v3: (from Rob Herring review)
> * Fix an error in the DT binding example compatible.
> * Drop the renaming of "prog_b" to "prog" and "init-b" to "init".
> Patches 2 and 3 are removed.
>
> Changes since v2:
> * Inserted patch 2 and 3 which rename "prog_b" and "init-b" into "prog"
> and "init" for the SPI driver.
> * From Krzysztof Kozlowski review's:
> * Use more specific compatible names
> * Remove other missing occurences of the slave word missed in v2.
> * From Xu Yilun review's:
> * Fix vertical whitespace in get_done_gpio().
> * Combine write() and write_one_dummy_byte() together.
> * Eliminate most of the xilinx_core_probe() arguments, the driver
> needs to populate those directly into the xilinx_fpga_core struct.
> Added some documentation to struct xilinx_fpga_core to clarify
> this.
> * Removed typedefs from xilinx-core.h.
> * Moved null checks in xilinx_core_probe() to first patch.
> * Move csi_b and rdwr_b out of xilinx_selectmap_conf as they are not
> used out of the probe function.
>
> Changes since v1: (from Krzysztof Kozlowski review's)
> * Use more conventional names for gpio DT bindings
> * fix example in DT bindings
> * add mc-peripheral-props.yaml to DT bindings
> * fix various formatting mistakes
> * Remove all occurences of the "slave" word.
>
> Charles Perry (4):
> fpga: xilinx-spi: extract a common driver core
> dt-bindings: fpga: xlnx,fpga-selectmap: add DT schema
> fpga: xilinx-selectmap: add new driver
> xilinx-core: add new gpio names for prog and init
>
> .../bindings/fpga/xlnx,fpga-selectmap.yaml | 86 +++++++
> drivers/fpga/Kconfig | 12 +
> drivers/fpga/Makefile | 2 +
> drivers/fpga/xilinx-core.c | 229 ++++++++++++++++++
> drivers/fpga/xilinx-core.h | 27 +++
> drivers/fpga/xilinx-selectmap.c | 95 ++++++++
> drivers/fpga/xilinx-spi.c | 224 ++---------------
> 7 files changed, 466 insertions(+), 209 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/fpga/xlnx,fpga-selectmap.yaml
> create mode 100644 drivers/fpga/xilinx-core.c
> create mode 100644 drivers/fpga/xilinx-core.h
> create mode 100644 drivers/fpga/xilinx-selectmap.c
Applied this series to for-next with a nit.
Thanks,
Yilun
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v6 3/4] fpga: xilinx-selectmap: add new driver
From: Xu Yilun @ 2024-03-31 14:34 UTC (permalink / raw)
To: Charles Perry
Cc: mdf, avandiver, bcody, Wu Hao, Xu Yilun, Tom Rix, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Michal Simek, linux-fpga,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20240321220447.3260065-4-charles.perry@savoirfairelinux.com>
> +static int xilinx_selectmap_write(struct xilinx_fpga_core *core,
> + const char *buf, size_t count)
> +{
> + struct xilinx_selectmap_conf *conf = to_xilinx_selectmap_conf(core);
> + u32 i;
comparing u32 with size_t is problematic.
size_t i;
I can fix it in place.
Thanks,
Yilun
> +
> + for (i = 0; i < count; ++i)
> + writeb(buf[i], conf->base);
> +
> + return 0;
> +}
^ permalink raw reply
* Re: [PATCH] iio: industrialio-core: look for aliases to request device index
From: Jonathan Cameron @ 2024-03-31 14:20 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Dominique Martinet, David Lechner, Krzysztof Kozlowski,
Syunya Ohshio, Guido Günther, Lars-Peter Clausen,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20240318122953.000013f3@Huawei.com>
On Mon, 18 Mar 2024 12:29:53 +0000
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:
> On Mon, 18 Mar 2024 11:15:36 +0900
> Dominique Martinet <dominique.martinet@atmark-techno.com> wrote:
>
> > David Lechner wrote on Fri, Mar 15, 2024 at 10:53:36AM -0500:
> > > How about using udev rules to create symlinks for each device based on
> > > the label attribute? No changes to the kernel are needed.
> >
> > Right, it's definitely possible to make symlinks for each "device" -- my
> > patch comment links to such an udev script "solution":
> > https://git.toradex.com/cgit/meta-toradex-bsp-common.git/tree/recipes-core/udev/files/verdin-imx8mm/toradex-adc.sh?h=kirkstone-6.x.y
> > (the script is launched by udev here:
> > https://git.toradex.com/cgit/meta-toradex-bsp-common.git/tree/recipes-core/udev/files/verdin-imx8mm/99-toradex.rules
> > )
> >
> > My conceptual problem with this is that this makes symlinks in /dev to
> > files in /sys and it feels like we're crossing boundaries.
> > As far as I can tell there is no way for userspace to create arbitrary
> > symlinks in /sys, so I think we could have an interface more
> > user-friendly by allowing paths to be static for users with multiple
> > devices.
> > (I guess that's a weak argument given e.g. disks etc will also have an
> > unreliable name in /sys in the general case, but simple programs don't
> > interact with them in /sys and can use stable links in /dev so my
> > expectations here aren't quite the same)
> >
> >
> > Ultimately, the problem might run deeper in that we're having userspace
> > interact with the device through /sys and not the /dev char dev... As
> > far as I could see /dev/iio:deviceX only allows reading buffered values
> > and doesn't have any ioctl or other way of reading immediate values as
> > is possible in /sys though, so that'd require quite a bit of work to
> > duplicate the interface there...
>
> Don't. The sysfs interface as only control is entirely intentional and
> we do not want IOCTL based duplication.
>
> Just addressing this bit as I'm still a bit snowed under to think about this
> more generally.
>
Hi, got back to this finally...
So the problems compared to other 'alias' users is that IIO is a bit more
complex than for example LEDs. A single DT node/compatible (or equivalent) can
result in a 1+ IIO devices and 1+ triggers. Triggers can also be instantiated
via configfs (technically devices can as well but we can ignore that).
Any alias scheme needs to work for all these options. To my mind that makes
it a userspace problem, not something the kernel can deal with in generic
enough way. I think that all IIO devices have ways to stability identify them
(label, or parent devices)
There is an approximate equivalent of DT alias entries in SMBIOS but
I suspect not all ACPI platforms will provide that (it's typically used for
stable disk / network device naming on complex servers).
So I've messed around a bit and can think of various possible options to make
this simpler.
1) Use a tmpfs mount and link from that.
Now we 'could' put an alias directory somewhere under /sys/bus/iio/ that
is a mount point created via sysfs_create_mount_point() - I abused the
/sys/kernel/debug directory to test this (unmounted debugfs and mounted
a tmpfs). That would provide somewhere in sysfs that allows suitable
links. However, this is unusual so likely to be controversial.
2) Alternatively the relevant platform could create one of these somewhere
outside of sysfs and use udev rules to create the links.
3) Stick to the oddity of doing it under /dev/
4) Access the things in the first place via more stable paths?
/sys/bus/i2c/devices/i2c-0/0-0008/iio\:device?/ etc
Relying on the alias support for i2c bus numbering to make that stable should work
and if you are sure there will only be one entry (most devices) that matches
the wild card, should be easy enough to use in scripts.
My personal preference is this last option. Basically if you want stable paths
don't use /sys/bus/iio/devices/ to get them.
Jonathan
^ permalink raw reply
* RE: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support
From: Peng Fan @ 2024-03-31 13:44 UTC (permalink / raw)
To: Andy Shevchenko, Peng Fan (OSS)
Cc: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Linus Walleij, Dan Carpenter,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, Oleksii Moisieiev
In-Reply-To: <ZgcP4IkTQGks9ehH@surfacebook.localdomain>
Hi Andy,
> Subject: Re: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol
> protocol basic support
>
> Sat, Mar 23, 2024 at 08:15:16PM +0800, Peng Fan (OSS) kirjoitti:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > Add basic implementation of the SCMI v3.2 pincontrol protocol.
>
> ...
>
> > scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_VIRTIO) += virtio.o
> > scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_OPTEE) += optee.o
> > scmi-protocols-y = base.o clock.o perf.o power.o reset.o sensors.o
> > system.o voltage.o powercap.o
>
> Actually you want to have := here.
>
> > +scmi-protocols-y += pinctrl.o
>
>
>
> > scmi-module-objs := $(scmi-driver-y) $(scmi-protocols-y)
> > $(scmi-transport-y)
>
> Side note: The -objs has to be -y
>
> ...
>
> > +#include <linux/module.h>
> > +#include <linux/scmi_protocol.h>
> > +#include <linux/slab.h>
>
> This is semi-random list of headers. Please, follow IWYU principle (include
> what you use). There are a lot of inclusions I see missing (just in the context of
> this page I see bits.h, types.h, and asm/byteorder.h).
Is there any documentation about this requirement?
Some headers are already included by others.
>
> ...
>
> > +enum scmi_pinctrl_protocol_cmd {
> > + PINCTRL_ATTRIBUTES = 0x3,
> > + PINCTRL_LIST_ASSOCIATIONS = 0x4,
> > + PINCTRL_SETTINGS_GET = 0x5,
> > + PINCTRL_SETTINGS_CONFIGURE = 0x6,
> > + PINCTRL_REQUEST = 0x7,
> > + PINCTRL_RELEASE = 0x8,
> > + PINCTRL_NAME_GET = 0x9,
> > + PINCTRL_SET_PERMISSIONS = 0xa
>
> Leave trailing comma as it's not a termination.
>
> > +};
>
> ...
>
> > +static int scmi_pinctrl_attributes_get(const struct scmi_protocol_handle
> *ph,
> > + struct scmi_pinctrl_info *pi) {
> > + int ret;
> > + struct scmi_xfer *t;
> > + struct scmi_msg_pinctrl_protocol_attributes *attr;
> > +
> > + ret = ph->xops->xfer_get_init(ph, PROTOCOL_ATTRIBUTES, 0,
> sizeof(*attr),
> > + &t);
>
> This looks much better on a single line.
Per Cristian, scmi drivers keep 80 max chars.
>
> > + if (ret)
> > + return ret;
> > +
> > + attr = t->rx.buf;
> > +
> > + ret = ph->xops->do_xfer(ph, t);
> > + if (!ret) {
> > + pi->nr_functions = GET_FUNCTIONS_NR(attr-
> >attributes_high);
> > + pi->nr_groups = GET_GROUPS_NR(attr->attributes_low);
> > + pi->nr_pins = GET_PINS_NR(attr->attributes_low);
> > + }
> > +
> > + ph->xops->xfer_put(ph, t);
> > + return ret;
> > +}
>
> ...
>
> > + ret = ph->xops->xfer_get_init(ph, PINCTRL_ATTRIBUTES, sizeof(*tx),
> > + sizeof(*rx), &t);
>
> Possible to have on a single line (if you use relaxed 100 limit).
> Or (re)split it more logically:
>
> ret = ph->xops->xfer_get_init(ph, PINCTRL_ATTRIBUTES,
> sizeof(*tx), sizeof(*rx), &t);
>
> > + if (ret)
> > + return ret;
>
> ...
>
> > + /*
> > + * If supported overwrite short name with the extended one;
> > + * on error just carry on and use already provided short name.
> > + */
> > + if (!ret && ext_name_flag)
>
> Please, use standard pattern, i.e.
>
> if (ret)
> return ret;
>
> > + ph->hops->extended_name_get(ph, PINCTRL_NAME_GET,
> selector,
> > + (u32 *)&type, name,
>
> Why is an explicit casting needed?
The type is enum, not u32.
>
> > + SCMI_MAX_STR_SIZE);
> > + return ret;
>
> ...
>
> > + iter = ph->hops->iter_response_init(ph, &ops, size,
> > + PINCTRL_LIST_ASSOCIATIONS,
> > + sizeof(struct
> scmi_msg_pinctrl_list_assoc),
> > + &ipriv);
>
> > +
>
> Redundant blank line.
>
> > + if (IS_ERR(iter))
> > + return PTR_ERR(iter);
>
> ...
>
> > + if (p->flag == 1)
> > + attributes |= FIELD_PREP(SKIP_CONFIGS_MASK, desc_index);
> > + else if (!p->flag)
>
> Be consistent, i.e. if (p->flag == 0)
>
> > + attributes |= FIELD_PREP(CONFIG_TYPE_MASK, p-
> >config_types[0]);
>
> ...
>
> > + st->num_remaining = le32_get_bits(r->num_configs,
> > + GENMASK(31, 24));
>
> One line?
Scmi drivers use 80 max drivers.
>
> ...
>
> > + if (!p->flag) {
> > + if (p->config_types[0] !=
> > + le32_get_bits(r->configs[st->loop_idx * 2], GENMASK(7, 0)))
> > + return -EINVAL;
> > + } else if (p->flag == 1) {
> > + p->config_types[st->desc_index + st->loop_idx] =
> > + le32_get_bits(r->configs[st->loop_idx * 2],
> > + GENMASK(7, 0));
>
> With a temporary variable for r->configs[st->loop_idx * 2] the above can be
> written in much better way.
ok. Fix in v7.
>
> > + } else if (p->flag == 2) {
> > + return 0;
> > + }
>
> > + p->config_values[st->desc_index + st->loop_idx] =
> > + le32_to_cpu(r->configs[st->loop_idx * 2 + 1]);
>
> For the sake of consistency with the above suggestion also temporary for next
> config value.
>
> ...
>
> > + iter = ph->hops->iter_response_init(ph, &ops, 1,
> PINCTRL_SETTINGS_GET,
> > + sizeof(struct
> scmi_msg_settings_get),
> > + &ipriv);
>
> > +
>
> Redundant blank line.
>
> > + if (IS_ERR(iter))
> > + return PTR_ERR(iter);
>
> ...
>
> > +static int scmi_pinctrl_get_group_info(const struct scmi_protocol_handle
> *ph,
> > + u32 selector,
> > + struct scmi_group_info *group) {
> > + int ret;
>
> > + if (!group)
> > + return -EINVAL;
>
> When the above is not a dead code?
It could be removed.
>
> > + ret = scmi_pinctrl_attributes(ph, GROUP_TYPE, selector,
> > + group->name,
> > + &group->nr_pins);
> > + if (ret)
> > + return ret;
> > +
> > + if (!group->nr_pins) {
> > + dev_err(ph->dev, "Group %d has 0 elements", selector);
> > + return -ENODATA;
> > + }
> > +
> > + group->group_pins = kmalloc_array(group->nr_pins,
> > + sizeof(*group->group_pins),
> > + GFP_KERNEL);
> > + if (!group->group_pins)
> > + return -ENOMEM;
> > +
> > + ret = scmi_pinctrl_list_associations(ph, selector, GROUP_TYPE,
> > + group->nr_pins, group-
> >group_pins);
> > + if (ret) {
> > + kfree(group->group_pins);
> > + return ret;
> > + }
> > +
> > + group->present = true;
> > + return 0;
> > +}
>
> ...
>
> > + ret = scmi_pinctrl_get_group_info(ph, selector,
> > + &pi->groups[selector]);
>
> One line?
>
> > + if (ret)
> > + return ret;
>
> ...
>
> > + ret = scmi_pinctrl_attributes(ph, FUNCTION_TYPE, selector,
> > + func->name,
> > + &func->nr_groups);
>
> At least last two lines can be joined.
>
> > + if (ret)
> > + return ret;
>
> ...
>
> > + ret = scmi_pinctrl_attributes(ph, PIN_TYPE, selector,
> > + pin->name, NULL);
>
> It's pleany of room on the previous line.
>
> > + if (ret)
> > + return ret;
>
> ...
>
> > + ret = scmi_pinctrl_get_pin_info(ph, selector,
> > + &pi->pins[selector]);
>
> Ditto.
>
> > + if (ret)
> > + return ret;
>
> ...
>
> > +static int scmi_pinctrl_protocol_init(const struct
> > +scmi_protocol_handle *ph) {
> > + int ret;
> > + u32 version;
> > + struct scmi_pinctrl_info *pinfo;
> > +
> > + ret = ph->xops->version_get(ph, &version);
> > + if (ret)
> > + return ret;
> > +
> > + dev_dbg(ph->dev, "Pinctrl Version %d.%d\n",
> > + PROTOCOL_REV_MAJOR(version),
> PROTOCOL_REV_MINOR(version));
> > +
> > + pinfo = devm_kzalloc(ph->dev, sizeof(*pinfo), GFP_KERNEL);
>
> Huh?!
>
> Please, get yourself familiar with the scope of devm APIs.
Please teach me if this is wrong.
>
> > + if (!pinfo)
> > + return -ENOMEM;
> > +
> > + ret = scmi_pinctrl_attributes_get(ph, pinfo);
> > + if (ret)
> > + return ret;
> > +
> > + pinfo->pins = devm_kcalloc(ph->dev, pinfo->nr_pins,
> > + sizeof(*pinfo->pins),
> > + GFP_KERNEL);
> > + if (!pinfo->pins)
> > + return -ENOMEM;
> > +
> > + pinfo->groups = devm_kcalloc(ph->dev, pinfo->nr_groups,
> > + sizeof(*pinfo->groups),
> > + GFP_KERNEL);
> > + if (!pinfo->groups)
> > + return -ENOMEM;
> > +
> > + pinfo->functions = devm_kcalloc(ph->dev, pinfo->nr_functions,
> > + sizeof(*pinfo->functions),
> > + GFP_KERNEL);
> > + if (!pinfo->functions)
> > + return -ENOMEM;
> > +
> > + pinfo->version = version;
> > +
> > + return ph->set_priv(ph, pinfo, version); }
> > +
> > +static int scmi_pinctrl_protocol_deinit(const struct
> > +scmi_protocol_handle *ph) {
> > + int i;
> > + struct scmi_pinctrl_info *pi = ph->get_priv(ph);
> > +
> > + for (i = 0; i < pi->nr_groups; i++) {
> > + if (pi->groups[i].present) {
> > + kfree(pi->groups[i].group_pins);
> > + pi->groups[i].present = false;
> > + }
> > + }
> > +
> > + for (i = 0; i < pi->nr_functions; i++) {
> > + if (pi->functions[i].present) {
> > + kfree(pi->functions[i].groups);
>
> This is wrong in conjunction with the above.
Yeah.
>
> > + pi->functions[i].present = false;
> > + }
> > + }
> > +
> > + return 0;
> > +}
>
> ...
>
> > +static const struct scmi_protocol scmi_pinctrl = {
> > + .id = SCMI_PROTOCOL_PINCTRL,
> > + .owner = THIS_MODULE,
> > + .instance_init = &scmi_pinctrl_protocol_init,
> > + .instance_deinit = &scmi_pinctrl_protocol_deinit,
> > + .ops = &pinctrl_proto_ops,
> > + .supported_version = SCMI_PROTOCOL_SUPPORTED_VERSION, };
>
> > +
>
> Redundant blank line.
Fix in v7
Thanks,
Peng.
>
> > +DEFINE_SCMI_PROTOCOL_REGISTER_UNREGISTER(pinctrl, scmi_pinctrl)
>
>
> --
> With Best Regards,
> Andy Shevchenko
>
^ permalink raw reply
* RE: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support
From: Peng Fan @ 2024-03-31 13:28 UTC (permalink / raw)
To: Cristian Marussi, Peng Fan (OSS)
Cc: Sudeep Holla, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, Dan Carpenter,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, Oleksii Moisieiev
In-Reply-To: <ZgWRA2V3PF_q9yRM@pluto>
Hi Cristian,
> Subject: Re: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol
> protocol basic support
>
> On Sat, Mar 23, 2024 at 08:15:16PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > Add basic implementation of the SCMI v3.2 pincontrol protocol.
> >
>
> Hi,
>
> a few more comments down below...
>
> > Co-developed-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
> > Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > drivers/firmware/arm_scmi/Makefile | 1 +
> > drivers/firmware/arm_scmi/driver.c | 2 +
> > drivers/firmware/arm_scmi/pinctrl.c | 921
> ++++++++++++++++++++++++++++++++++
> > drivers/firmware/arm_scmi/protocols.h | 1 +
> > include/linux/scmi_protocol.h | 75 +++
> > 5 files changed, 1000 insertions(+)
> >
> > diff --git a/drivers/firmware/arm_scmi/Makefile
> > b/drivers/firmware/arm_scmi/Makefile
> > index a7bc4796519c..8e3874ff1544 100644
> > --- a/drivers/firmware/arm_scmi/Makefile
> > +++ b/drivers/firmware/arm_scmi/Makefile
> > @@ -11,6 +11,7 @@ scmi-transport-$(CONFIG_ARM_SCMI_HAVE_MSG) +=
> msg.o
> > scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_VIRTIO) += virtio.o
> > scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_OPTEE) += optee.o
> > scmi-protocols-y = base.o clock.o perf.o power.o reset.o sensors.o
> > system.o voltage.o powercap.o
> > +scmi-protocols-y += pinctrl.o
> > scmi-module-objs := $(scmi-driver-y) $(scmi-protocols-y)
> > $(scmi-transport-y)
> >
> > obj-$(CONFIG_ARM_SCMI_PROTOCOL) += scmi-core.o diff --git
> > a/drivers/firmware/arm_scmi/driver.c
> > b/drivers/firmware/arm_scmi/driver.c
> > index 415e6f510057..ac2d4b19727c 100644
> > --- a/drivers/firmware/arm_scmi/driver.c
> > +++ b/drivers/firmware/arm_scmi/driver.c
> > @@ -3142,6 +3142,7 @@ static int __init scmi_driver_init(void)
> > scmi_voltage_register();
> > scmi_system_register();
> > scmi_powercap_register();
> > + scmi_pinctrl_register();
> >
> > return platform_driver_register(&scmi_driver);
> > }
> > @@ -3159,6 +3160,7 @@ static void __exit scmi_driver_exit(void)
> > scmi_voltage_unregister();
> > scmi_system_unregister();
> > scmi_powercap_unregister();
> > + scmi_pinctrl_unregister();
> >
> > scmi_transports_exit();
> >
> > diff --git a/drivers/firmware/arm_scmi/pinctrl.c
> > b/drivers/firmware/arm_scmi/pinctrl.c
> > new file mode 100644
> > index 000000000000..87d9b89cab13
> > --- /dev/null
> > +++ b/drivers/firmware/arm_scmi/pinctrl.c
> > @@ -0,0 +1,921 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * System Control and Management Interface (SCMI) Pinctrl Protocol
> > + *
> > + * Copyright (C) 2024 EPAM
> > + * Copyright 2024 NXP
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/scmi_protocol.h>
> > +#include <linux/slab.h>
> > +
> > +#include "common.h"
> > +#include "protocols.h"
> > +
> > +/* Updated only after ALL the mandatory features for that version are
> merged */
> > +#define SCMI_PROTOCOL_SUPPORTED_VERSION 0x0
> > +
>
> AFAICS, the only missing things are PINCTRL_SET_PERMISSIONS (optional
> command)
I not see users as of now, could we add it until we need it?
and the multiple-configs on SETTINGS_GET, but this latter is
> something really that we have to ask for in the request AND we did not as of
> now since we dont need it...so I would say to bump the version to 0x10000
ok.
> just to avoid needless warning as soon as a server supporting Pinctrl is met.
>
> > +#define GET_GROUPS_NR(x) le32_get_bits((x), GENMASK(31, 16))
> > +#define GET_PINS_NR(x) le32_get_bits((x), GENMASK(15, 0))
> > +#define GET_FUNCTIONS_NR(x) le32_get_bits((x), GENMASK(15, 0))
> > +
> > +#define EXT_NAME_FLAG(x) le32_get_bits((x), BIT(31))
> > +#define NUM_ELEMS(x) le32_get_bits((x), GENMASK(15, 0))
> > +
> > +#define REMAINING(x) le32_get_bits((x), GENMASK(31,
> 16))
> > +#define RETURNED(x) le32_get_bits((x), GENMASK(11, 0))
> > +
> > +#define CONFIG_FLAG_MASK GENMASK(19, 18)
> > +#define SELECTOR_MASK GENMASK(17, 16)
> > +#define SKIP_CONFIGS_MASK GENMASK(15, 8)
> > +#define CONFIG_TYPE_MASK GENMASK(7, 0)
> > +
> > +enum scmi_pinctrl_protocol_cmd {
> > + PINCTRL_ATTRIBUTES = 0x3,
> > + PINCTRL_LIST_ASSOCIATIONS = 0x4,
> > + PINCTRL_SETTINGS_GET = 0x5,
> > + PINCTRL_SETTINGS_CONFIGURE = 0x6,
> > + PINCTRL_REQUEST = 0x7,
> > + PINCTRL_RELEASE = 0x8,
> > + PINCTRL_NAME_GET = 0x9,
> > + PINCTRL_SET_PERMISSIONS = 0xa
> > +};
> > +
> > +struct scmi_msg_settings_conf {
> > + __le32 identifier;
> > + __le32 function_id;
> > + __le32 attributes;
> > + __le32 configs[];
> > +};
> > +
> > +struct scmi_msg_settings_get {
> > + __le32 identifier;
> > + __le32 attributes;
> > +};
> > +
> > +struct scmi_resp_settings_get {
> > + __le32 function_selected;
> > + __le32 num_configs;
> > + __le32 configs[];
> > +};
> > +
> > +struct scmi_msg_pinctrl_protocol_attributes {
> > + __le32 attributes_low;
> > + __le32 attributes_high;
> > +};
> > +
> > +struct scmi_msg_pinctrl_attributes {
> > + __le32 identifier;
> > + __le32 flags;
> > +};
> > +
> > +struct scmi_resp_pinctrl_attributes {
> > + __le32 attributes;
> > + u8 name[SCMI_SHORT_NAME_MAX_SIZE];
> > +};
> > +
> > +struct scmi_msg_pinctrl_list_assoc {
> > + __le32 identifier;
> > + __le32 flags;
> > + __le32 index;
> > +};
> > +
> > +struct scmi_resp_pinctrl_list_assoc {
> > + __le32 flags;
> > + __le16 array[];
> > +};
> > +
> > +struct scmi_msg_func_set {
> > + __le32 identifier;
> > + __le32 function_id;
> > + __le32 flags;
> > +};
> > +
>
> As said by Dan...drop this.
>
> > +struct scmi_msg_request {
> > + __le32 identifier;
> > + __le32 flags;
> > +};
> > +
> > +struct scmi_group_info {
> > + char name[SCMI_MAX_STR_SIZE];
> > + bool present;
> > + u32 *group_pins;
> > + u32 nr_pins;
> > +};
> > +
> > +struct scmi_function_info {
> > + char name[SCMI_MAX_STR_SIZE];
> > + bool present;
> > + u32 *groups;
> > + u32 nr_groups;
> > +};
> > +
> > +struct scmi_pin_info {
> > + char name[SCMI_MAX_STR_SIZE];
> > + bool present;
> > +};
> > +
> > +struct scmi_pinctrl_info {
> > + u32 version;
> > + int nr_groups;
> > + int nr_functions;
> > + int nr_pins;
> > + struct scmi_group_info *groups;
> > + struct scmi_function_info *functions;
> > + struct scmi_pin_info *pins;
> > +};
> > +
> > +static int scmi_pinctrl_attributes_get(const struct scmi_protocol_handle
> *ph,
> > + struct scmi_pinctrl_info *pi) {
> > + int ret;
> > + struct scmi_xfer *t;
> > + struct scmi_msg_pinctrl_protocol_attributes *attr;
> > +
> > + ret = ph->xops->xfer_get_init(ph, PROTOCOL_ATTRIBUTES, 0,
> sizeof(*attr),
> > + &t);
> > + if (ret)
> > + return ret;
> > +
> > + attr = t->rx.buf;
> > +
> > + ret = ph->xops->do_xfer(ph, t);
> > + if (!ret) {
> > + pi->nr_functions = GET_FUNCTIONS_NR(attr-
> >attributes_high);
> > + pi->nr_groups = GET_GROUPS_NR(attr->attributes_low);
> > + pi->nr_pins = GET_PINS_NR(attr->attributes_low);
>
> I was thinking, does make sense to allow a nr_pins == 0 setup to probe
> successfully ? Becasuse is legit for the platform to return zero groups or zero
> functions BUT zero pins is just useless (spec does not say
> anything)
>
> Maybe you could just put a dev_warn() here on if (nr_pins == 0) and bail out
> with -EINVAL...
ok, fix in v7.
>
> On the other side looking at the zero groups/function case, that is plausible
> and handled properly by the driver since a 0-bytes devm_kcalloc will return
> ZERO_SIZE_PTR (not NULL) and all the remaining references to pinfo->groups
> and pinfo->functions are guarded by a check on selector >= nr_groups (or >=
> nr_functions), and by scmi_pinctrl_validate_id() so the zero grouyps/fuctions
> scenarios should be safely handled.
>
> > + }
> > +
> > + ph->xops->xfer_put(ph, t);
> > + return ret;
> > +}
> > +
> > +static int scmi_pinctrl_count_get(const struct scmi_protocol_handle *ph,
> > + enum scmi_pinctrl_selector_type type) {
> > + struct scmi_pinctrl_info *pi = ph->get_priv(ph);
> > +
> > + switch (type) {
> > + case PIN_TYPE:
> > + return pi->nr_pins;
> > + case GROUP_TYPE:
> > + return pi->nr_groups;
> > + case FUNCTION_TYPE:
> > + return pi->nr_functions;
> > + default:
> > + return -EINVAL;
> > + }
> > +}
> > +
> > +static int scmi_pinctrl_validate_id(const struct scmi_protocol_handle *ph,
> > + u32 identifier,
> > + enum scmi_pinctrl_selector_type type) {
> > + int value;
> > +
> > + value = scmi_pinctrl_count_get(ph, type);
> > + if (value < 0)
> > + return value;
> > +
> > + if (identifier >= value)
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +
> > +static int scmi_pinctrl_attributes(const struct scmi_protocol_handle *ph,
> > + enum scmi_pinctrl_selector_type type,
> > + u32 selector, char *name,
> > + u32 *n_elems)
> > +{
> > + int ret;
> > + struct scmi_xfer *t;
> > + struct scmi_msg_pinctrl_attributes *tx;
> > + struct scmi_resp_pinctrl_attributes *rx;
> > + u32 ext_name_flag;
>
> what about a bool
>
> > +
> > + if (!name)
> > + return -EINVAL;
> > +
> > + ret = scmi_pinctrl_validate_id(ph, selector, type);
> > + if (ret)
> > + return ret;
> > +
> > + ret = ph->xops->xfer_get_init(ph, PINCTRL_ATTRIBUTES, sizeof(*tx),
> > + sizeof(*rx), &t);
> > + if (ret)
> > + return ret;
> > +
> > + tx = t->tx.buf;
> > + rx = t->rx.buf;
> > + tx->identifier = cpu_to_le32(selector);
> > + tx->flags = cpu_to_le32(type);
> > +
> > + ret = ph->xops->do_xfer(ph, t);
> > + if (!ret) {
> > + if (n_elems)
> > + *n_elems = NUM_ELEMS(rx->attributes);
> > +
> > + strscpy(name, rx->name, SCMI_SHORT_NAME_MAX_SIZE);
> > +
> > + ext_name_flag = EXT_NAME_FLAG(rx->attributes);
> > + } else
> > + ext_name_flag = 0;
>
> and you dont need this else branch to set ext_name_flag to false, since down
> below you will check ext_flag ONLY if !ret, so it will have surely been set if the
> do_xfer did not fail.
>
> > +
> > + ph->xops->xfer_put(ph, t);
> > +
> > + /*
> > + * If supported overwrite short name with the extended one;
> > + * on error just carry on and use already provided short name.
> > + */
> > + if (!ret && ext_name_flag)
> > + ph->hops->extended_name_get(ph, PINCTRL_NAME_GET,
> selector,
> > + (u32 *)&type, name,
> > + SCMI_MAX_STR_SIZE);
> > + return ret;
> > +}
> > +
> > +struct scmi_pinctrl_ipriv {
> > + u32 selector;
> > + enum scmi_pinctrl_selector_type type;
> > + u32 *array;
> > +};
> > +
> > +static void iter_pinctrl_assoc_prepare_message(void *message,
> > + u32 desc_index,
> > + const void *priv)
> > +{
> > + struct scmi_msg_pinctrl_list_assoc *msg = message;
> > + const struct scmi_pinctrl_ipriv *p = priv;
> > +
> > + msg->identifier = cpu_to_le32(p->selector);
> > + msg->flags = cpu_to_le32(p->type);
> > + /* Set the number of OPPs to be skipped/already read */
>
> OPP ? .. maybe drop this comment that was cut/pasted from somewhere
> else :D
>
> > + msg->index = cpu_to_le32(desc_index); }
> > +
> > +static int iter_pinctrl_assoc_update_state(struct scmi_iterator_state *st,
> > + const void *response, void *priv)
> {
> > + const struct scmi_resp_pinctrl_list_assoc *r = response;
> > +
> > + st->num_returned = RETURNED(r->flags);
> > + st->num_remaining = REMAINING(r->flags);
> > +
> > + return 0;
> > +}
> > +
> > +static int
> > +iter_pinctrl_assoc_process_response(const struct scmi_protocol_handle
> *ph,
> > + const void *response,
> > + struct scmi_iterator_state *st, void *priv)
> {
> > + const struct scmi_resp_pinctrl_list_assoc *r = response;
> > + struct scmi_pinctrl_ipriv *p = priv;
> > +
> > + p->array[st->desc_index + st->loop_idx] =
> > + le16_to_cpu(r->array[st->loop_idx]);
> > +
> > + return 0;
> > +}
> > +
> > +static int scmi_pinctrl_list_associations(const struct scmi_protocol_handle
> *ph,
> > + u32 selector,
> > + enum scmi_pinctrl_selector_type
> type,
> > + u16 size, u32 *array)
> > +{
> > + int ret;
> > + void *iter;
> > + struct scmi_iterator_ops ops = {
> > + .prepare_message = iter_pinctrl_assoc_prepare_message,
> > + .update_state = iter_pinctrl_assoc_update_state,
> > + .process_response = iter_pinctrl_assoc_process_response,
> > + };
> > + struct scmi_pinctrl_ipriv ipriv = {
> > + .selector = selector,
> > + .type = type,
> > + .array = array,
> > + };
> > +
> > + if (!array || !size || type == PIN_TYPE)
> > + return -EINVAL;
> > +
> > + ret = scmi_pinctrl_validate_id(ph, selector, type);
> > + if (ret)
> > + return ret;
> > +
> > + iter = ph->hops->iter_response_init(ph, &ops, size,
> > + PINCTRL_LIST_ASSOCIATIONS,
> > + sizeof(struct
> scmi_msg_pinctrl_list_assoc),
> > + &ipriv);
> > +
> > + if (IS_ERR(iter))
> > + return PTR_ERR(iter);
> > +
> > + return ph->hops->iter_response_run(iter);
> > +}
> > +
> > +struct scmi_settings_get_ipriv {
> > + u32 selector;
> > + enum scmi_pinctrl_selector_type type;
> > + u32 flag;
> > + enum scmi_pinctrl_conf_type *config_types;
> > + u32 *config_values;
> > +};
> > +
> > +static void
> > +iter_pinctrl_settings_get_prepare_message(void *message, u32 desc_index,
> > + const void *priv)
> > +{
> > + struct scmi_msg_settings_get *msg = message;
> > + const struct scmi_settings_get_ipriv *p = priv;
> > + u32 attributes;
> > +
> > + attributes = FIELD_PREP(CONFIG_FLAG_MASK, p->flag) |
> > + FIELD_PREP(SELECTOR_MASK, p->type);
> > +
> > + if (p->flag == 1)
>
> A boolean like .get_all would be more clear..see down below why you dont
> need a flag 0|1|2
>
> > + attributes |= FIELD_PREP(SKIP_CONFIGS_MASK, desc_index);
> > + else if (!p->flag)
> > + attributes |= FIELD_PREP(CONFIG_TYPE_MASK, p-
> >config_types[0]);
> > +
> > + msg->attributes = cpu_to_le32(attributes);
> > + msg->identifier = cpu_to_le32(p->selector); }
> > +
> > +static int
> > +iter_pinctrl_settings_get_update_state(struct scmi_iterator_state *st,
> > + const void *response, void *priv) {
> > + const struct scmi_resp_settings_get *r = response;
> > + struct scmi_settings_get_ipriv *p = priv;
> > +
> > + if (p->flag == 1) {
>
> Ditto... see below the explanation
>
> > + st->num_returned = le32_get_bits(r->num_configs,
> GENMASK(7, 0));
> > + st->num_remaining = le32_get_bits(r->num_configs,
> > + GENMASK(31, 24));
> > + } else {
> > + st->num_returned = 1;
> > + st->num_remaining = 0;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int
> > +iter_pinctrl_settings_get_process_response(const struct
> scmi_protocol_handle *ph,
> > + const void *response,
> > + struct scmi_iterator_state *st,
> > + void *priv)
> > +{
> > + const struct scmi_resp_settings_get *r = response;
> > + struct scmi_settings_get_ipriv *p = priv;
> > +
> > + if (!p->flag) {
> > + if (p->config_types[0] !=
> > + le32_get_bits(r->configs[st->loop_idx * 2], GENMASK(7, 0)))
> > + return -EINVAL;
> > + } else if (p->flag == 1) {
> > + p->config_types[st->desc_index + st->loop_idx] =
> > + le32_get_bits(r->configs[st->loop_idx * 2],
> > + GENMASK(7, 0));
> > + } else if (p->flag == 2) {
> > + return 0;
> > + }
>
> Unneeded...see down below for explanation
>
> > +
> > + p->config_values[st->desc_index + st->loop_idx] =
> > + le32_to_cpu(r->configs[st->loop_idx * 2 + 1]);
> > +
> > + return 0;
> > +}
> > +
> > +static int
> > +scmi_pinctrl_settings_get(const struct scmi_protocol_handle *ph, u32
> selector,
> > + enum scmi_pinctrl_selector_type type,
> > + enum scmi_pinctrl_conf_type config_type,
> > + u32 *config_value)
> > +{
> > + int ret;
> > + void *iter;
> > + struct scmi_iterator_ops ops = {
> > + .prepare_message =
> iter_pinctrl_settings_get_prepare_message,
> > + .update_state = iter_pinctrl_settings_get_update_state,
> > + .process_response =
> iter_pinctrl_settings_get_process_response,
> > + };
> > + struct scmi_settings_get_ipriv ipriv = {
> > + .selector = selector,
> > + .type = type,
> > + .flag = 0,
> > + .config_types = &config_type,
> > + .config_values = config_value,
> > + };
> > +
>
> So this function is used to retrieve configs; as of now, just one, then it could
> be extended to fetch all the configs, and for this it uses the iterators helpers,
> BUT it is not and will not be used to just fetch the selected_function with
> flag_2 (even though is always provided), since in that case you wont get back
> a multi-part SCMI response and so there is no need to use iterators...
>
> IOW... no need here to handle flag_2 scenario and as a consequence I would
> change the ipriv flag to be be a boolean .get_all, like it was, since it is more
> readable (and so you wont need to add any comment..)
ok, so your suggestion is drop the iterators, and only support one config,
right?
Or keep iterators with get_all be passed as a function parameter?
>
> In the future could make sense to add here also a *selected_function output
> param to this function since you will always get it back for free when
> retrieving configs ... BUT for now is just not needed really...no users for this
> case till now...
>
> ...when the time will come that we will need a function_selected_get to be
> issued without retrieveing also the configs I would add a distinct routine that
> crafts properly a SETTINGS_GET with flag_2 without worrying about multi-
> part responses (and with no need for iterators support)
>
> Trying to handle all in here just complicates stuff...
>
> > + if (!config_value || type == FUNCTION_TYPE)
> > + return -EINVAL;
> > +
> > + ret = scmi_pinctrl_validate_id(ph, selector, type);
> > + if (ret)
> > + return ret;
> > +
> > + iter = ph->hops->iter_response_init(ph, &ops, 1,
> PINCTRL_SETTINGS_GET,
> > + sizeof(struct
> scmi_msg_settings_get),
> > + &ipriv);
> > +
> > + if (IS_ERR(iter))
> > + return PTR_ERR(iter);
> > +
> > + return ph->hops->iter_response_run(iter);
> > +}
> > +
> > +static int
> > +scmi_pinctrl_settings_conf(const struct scmi_protocol_handle *ph,
> > + u32 selector,
> > + enum scmi_pinctrl_selector_type type,
> > + u32 nr_configs,
> > + enum scmi_pinctrl_conf_type *config_type,
> > + u32 *config_value)
> > +{
> > + struct scmi_xfer *t;
> > + struct scmi_msg_settings_conf *tx;
> > + u32 attributes;
> > + int ret, i;
> > + u32 configs_in_chunk, conf_num = 0;
> > + u32 chunk;
> > + int max_msg_size = ph->hops->get_max_msg_size(ph);
> > +
> > + if (!config_type || !config_value || type == FUNCTION_TYPE)
> > + return -EINVAL;
> > +
> > + ret = scmi_pinctrl_validate_id(ph, selector, type);
> > + if (ret)
> > + return ret;
> > +
> > + configs_in_chunk = (max_msg_size - sizeof(*tx)) / (sizeof(__le32) * 2);
> > + while (conf_num < nr_configs) {
> > + chunk = (nr_configs - conf_num > configs_in_chunk) ?
> > + configs_in_chunk : nr_configs - conf_num;
> > +
> > + ret = ph->xops->xfer_get_init(ph,
> PINCTRL_SETTINGS_CONFIGURE,
> > + sizeof(*tx) +
> > + chunk * 2 * sizeof(__le32),
> > + 0, &t);
> > + if (ret)
> > + return ret;
> for consistency I would
> break;
>
> like below and you will exit always from the last return ret;
>
> > +
> > + tx = t->tx.buf;
> > + tx->identifier = cpu_to_le32(selector);
> > + attributes = FIELD_PREP(GENMASK(1, 0), type) |
> > + FIELD_PREP(GENMASK(9, 2), chunk);
> > + tx->attributes = cpu_to_le32(attributes);
> > +
> > + for (i = 0; i < chunk; i++) {
> > + tx->configs[i * 2] =
> > + cpu_to_le32(config_type[conf_num + i]);
> > + tx->configs[i * 2 + 1] =
> > + cpu_to_le32(config_value[conf_num + i]);
> > + }
> > +
> > + ret = ph->xops->do_xfer(ph, t);
> > +
> > + ph->xops->xfer_put(ph, t);
> > +
> > + if (ret)
> > + break;
> > +
> > + conf_num += chunk;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static int scmi_pinctrl_function_select(const struct scmi_protocol_handle
> *ph,
> > + u32 group,
> > + enum scmi_pinctrl_selector_type
> type,
> > + u32 function_id)
> > +{
> > + int ret;
> > + struct scmi_xfer *t;
> > + struct scmi_msg_settings_conf *tx;
> > + u32 attributes;
> > +
> > + ret = scmi_pinctrl_validate_id(ph, group, type);
> > + if (ret)
> > + return ret;
> > +
> > + ret = ph->xops->xfer_get_init(ph, PINCTRL_SETTINGS_CONFIGURE,
> > + sizeof(*tx), 0, &t);
> > + if (ret)
> > + return ret;
> > +
> > + tx = t->tx.buf;
> > + tx->identifier = cpu_to_le32(group);
> > + tx->function_id = cpu_to_le32(function_id);
> > + attributes = FIELD_PREP(GENMASK(1, 0), type) | BIT(10);
> > + tx->attributes = cpu_to_le32(attributes);
> > +
> > + ret = ph->xops->do_xfer(ph, t);
> > + ph->xops->xfer_put(ph, t);
> > +
> > + return ret;
> > +}
> > +
> > +static int scmi_pinctrl_request(const struct scmi_protocol_handle *ph,
> > + u32 identifier,
> > + enum scmi_pinctrl_selector_type type) {
> > + int ret;
> > + struct scmi_xfer *t;
> > + struct scmi_msg_request *tx;
> > +
> > + if (type == FUNCTION_TYPE)
> > + return -EINVAL;
> > +
> > + ret = scmi_pinctrl_validate_id(ph, identifier, type);
> > + if (ret)
> > + return ret;
> > +
> > + ret = ph->xops->xfer_get_init(ph, PINCTRL_REQUEST, sizeof(*tx), 0,
> &t);
> > + if (ret)
> > + return ret;
> > +
> > + tx = t->tx.buf;
> > + tx->identifier = cpu_to_le32(identifier);
> > + tx->flags = cpu_to_le32(type);
> > +
> > + ret = ph->xops->do_xfer(ph, t);
> > + ph->xops->xfer_put(ph, t);
> > +
> > + return ret;
> > +}
> > +
>
> ..this function ...
>
> > +static int scmi_pinctrl_pin_request(const struct scmi_protocol_handle *ph,
> > + u32 pin)
> > +{
> > + return scmi_pinctrl_request(ph, pin, PIN_TYPE); }
> > +
> > +static int scmi_pinctrl_free(const struct scmi_protocol_handle *ph,
> > + u32 identifier,
> > + enum scmi_pinctrl_selector_type type) {
> > + int ret;
> > + struct scmi_xfer *t;
> > + struct scmi_msg_request *tx;
> > +
> > + if (type == FUNCTION_TYPE)
> > + return -EINVAL;
> > +
> > + ret = scmi_pinctrl_validate_id(ph, identifier, type);
> > + if (ret)
> > + return ret;
> > +
> > + ret = ph->xops->xfer_get_init(ph, PINCTRL_RELEASE, sizeof(*tx), 0, &t);
> > + if (ret)
> > + return ret;
> > +
> > + tx = t->tx.buf;
> > + tx->identifier = cpu_to_le32(identifier);
> > + tx->flags = cpu_to_le32(type);
> > +
> > + ret = ph->xops->do_xfer(ph, t);
> > + ph->xops->xfer_put(ph, t);
> > +
> > + return ret;
> > +}
> > +
>
> ...and this are completely identical, beside the used command msg_id...please
> make it a common workhorse function by adding a param for the command...
>
> > +static int scmi_pinctrl_pin_free(const struct scmi_protocol_handle
> > +*ph, u32 pin) {
> > + return scmi_pinctrl_free(ph, pin, PIN_TYPE); }
> > +
>
> ...and convert these _request/_free functions into a pair odf simple wrapper
> invoking the common workhorse...
>
> > +static int scmi_pinctrl_get_group_info(const struct scmi_protocol_handle
> *ph,
> > + u32 selector,
> > + struct scmi_group_info *group) {
> > + int ret;
> > +
> > + if (!group)
> > + return -EINVAL;
> > +
> > + ret = scmi_pinctrl_attributes(ph, GROUP_TYPE, selector,
> > + group->name,
> > + &group->nr_pins);
> > + if (ret)
> > + return ret;
> > +
> > + if (!group->nr_pins) {
> > + dev_err(ph->dev, "Group %d has 0 elements", selector);
> > + return -ENODATA;
> > + }
> > +
> > + group->group_pins = kmalloc_array(group->nr_pins,
> > + sizeof(*group->group_pins),
> > + GFP_KERNEL);
> > + if (!group->group_pins)
> > + return -ENOMEM;
> > +
> > + ret = scmi_pinctrl_list_associations(ph, selector, GROUP_TYPE,
> > + group->nr_pins, group-
> >group_pins);
> > + if (ret) {
> > + kfree(group->group_pins);
> > + return ret;
> > + }
> > +
> > + group->present = true;
> > + return 0;
> > +}
> > +
> > +static int scmi_pinctrl_get_group_name(const struct scmi_protocol_handle
> *ph,
> > + u32 selector, const char **name) {
> > + struct scmi_pinctrl_info *pi = ph->get_priv(ph);
> > +
> > + if (!name)
> > + return -EINVAL;
> > +
> > + if (selector >= pi->nr_groups)
> > + return -EINVAL;
> > +
> > + if (!pi->groups[selector].present) {
> > + int ret;
> > +
> > + ret = scmi_pinctrl_get_group_info(ph, selector,
> > + &pi->groups[selector]);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + *name = pi->groups[selector].name;
> > +
> > + return 0;
> > +}
> > +
> > +static int scmi_pinctrl_group_pins_get(const struct scmi_protocol_handle
> *ph,
> > + u32 selector, const u32 **pins,
> > + u32 *nr_pins)
> > +{
> > + struct scmi_pinctrl_info *pi = ph->get_priv(ph);
> > +
> > + if (!pins || !nr_pins)
> > + return -EINVAL;
> > +
> > + if (selector >= pi->nr_groups)
> > + return -EINVAL;
> > +
> > + if (!pi->groups[selector].present) {
> > + int ret;
> > +
> > + ret = scmi_pinctrl_get_group_info(ph, selector,
> > + &pi->groups[selector]);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + *pins = pi->groups[selector].group_pins;
> > + *nr_pins = pi->groups[selector].nr_pins;
> > +
> > + return 0;
> > +}
> > +
> > +static int scmi_pinctrl_get_function_info(const struct
> scmi_protocol_handle *ph,
> > + u32 selector,
> > + struct scmi_function_info *func) {
> > + int ret;
> > +
> > + if (!func)
> > + return -EINVAL;
> > +
> > + ret = scmi_pinctrl_attributes(ph, FUNCTION_TYPE, selector,
> > + func->name,
> > + &func->nr_groups);
> > + if (ret)
> > + return ret;
> > +
> > + if (!func->nr_groups) {
> > + dev_err(ph->dev, "Function %d has 0 elements", selector);
> > + return -ENODATA;
> > + }
> > +
> > + func->groups = kmalloc_array(func->nr_groups, sizeof(*func->groups),
> > + GFP_KERNEL);
> > + if (!func->groups)
> > + return -ENOMEM;
> > +
> > + ret = scmi_pinctrl_list_associations(ph, selector, FUNCTION_TYPE,
> > + func->nr_groups, func->groups);
> > + if (ret) {
> > + kfree(func->groups);
> > + return ret;
> > + }
> > +
> > + func->present = true;
> > + return 0;
> > +}
> > +
> > +static int scmi_pinctrl_get_function_name(const struct
> scmi_protocol_handle *ph,
> > + u32 selector, const char **name) {
> > + struct scmi_pinctrl_info *pi = ph->get_priv(ph);
> > +
> > + if (!name)
> > + return -EINVAL;
> > +
> > + if (selector >= pi->nr_functions)
> > + return -EINVAL;
> > +
> > + if (!pi->functions[selector].present) {
> > + int ret;
> > +
> > + ret = scmi_pinctrl_get_function_info(ph, selector,
> > + &pi-
> >functions[selector]);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + *name = pi->functions[selector].name;
> > + return 0;
> > +}
> > +
> > +static int
> > +scmi_pinctrl_function_groups_get(const struct scmi_protocol_handle *ph,
> > + u32 selector, u32 *nr_groups,
> > + const u32 **groups)
> > +{
> > + struct scmi_pinctrl_info *pi = ph->get_priv(ph);
> > +
> > + if (!groups || !nr_groups)
> > + return -EINVAL;
> > +
> > + if (selector >= pi->nr_functions)
> > + return -EINVAL;
> > +
> > + if (!pi->functions[selector].present) {
> > + int ret;
> > +
> > + ret = scmi_pinctrl_get_function_info(ph, selector,
> > + &pi-
> >functions[selector]);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + *groups = pi->functions[selector].groups;
> > + *nr_groups = pi->functions[selector].nr_groups;
> > +
> > + return 0;
> > +}
> > +
> > +static int scmi_pinctrl_mux_set(const struct scmi_protocol_handle *ph,
> > + u32 selector, u32 group)
> > +{
> > + return scmi_pinctrl_function_select(ph, group, GROUP_TYPE,
> > +selector); }
> > +
> > +static int scmi_pinctrl_get_pin_info(const struct scmi_protocol_handle *ph,
> > + u32 selector, struct scmi_pin_info *pin) {
> > + int ret;
> > +
> > + if (!pin)
> > + return -EINVAL;
> > +
> > + ret = scmi_pinctrl_attributes(ph, PIN_TYPE, selector,
> > + pin->name, NULL);
> > + if (ret)
> > + return ret;
> > +
> > + pin->present = true;
> > + return 0;
> > +}
> > +
> > +static int scmi_pinctrl_get_pin_name(const struct scmi_protocol_handle
> *ph,
> > + u32 selector, const char **name) {
> > + struct scmi_pinctrl_info *pi = ph->get_priv(ph);
> > +
> > + if (!name)
> > + return -EINVAL;
> > +
> > + if (selector >= pi->nr_pins)
> > + return -EINVAL;
> > +
> > + if (!pi->pins[selector].present) {
> > + int ret;
> > +
> > + ret = scmi_pinctrl_get_pin_info(ph, selector,
> > + &pi->pins[selector]);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + *name = pi->pins[selector].name;
> > +
> > + return 0;
> > +}
> > +
> > +static int scmi_pinctrl_name_get(const struct scmi_protocol_handle *ph,
> > + u32 selector,
> > + enum scmi_pinctrl_selector_type type,
> > + const char **name)
> > +{
> > + switch (type) {
> > + case PIN_TYPE:
> > + return scmi_pinctrl_get_pin_name(ph, selector, name);
> > + case GROUP_TYPE:
> > + return scmi_pinctrl_get_group_name(ph, selector, name);
> > + case FUNCTION_TYPE:
> > + return scmi_pinctrl_get_function_name(ph, selector, name);
> > + default:
> > + return -EINVAL;
> > + }
> > +}
> > +
> > +static const struct scmi_pinctrl_proto_ops pinctrl_proto_ops = {
> > + .count_get = scmi_pinctrl_count_get,
> > + .name_get = scmi_pinctrl_name_get,
> > + .group_pins_get = scmi_pinctrl_group_pins_get,
> > + .function_groups_get = scmi_pinctrl_function_groups_get,
> > + .mux_set = scmi_pinctrl_mux_set,
> > + .settings_get = scmi_pinctrl_settings_get,
> > + .settings_conf = scmi_pinctrl_settings_conf,
> > + .pin_request = scmi_pinctrl_pin_request,
> > + .pin_free = scmi_pinctrl_pin_free,
> > +};
> > +
> > +static int scmi_pinctrl_protocol_init(const struct
> > +scmi_protocol_handle *ph) {
> > + int ret;
> > + u32 version;
> > + struct scmi_pinctrl_info *pinfo;
> > +
> > + ret = ph->xops->version_get(ph, &version);
> > + if (ret)
> > + return ret;
> > +
> > + dev_dbg(ph->dev, "Pinctrl Version %d.%d\n",
> > + PROTOCOL_REV_MAJOR(version),
> PROTOCOL_REV_MINOR(version));
> > +
> > + pinfo = devm_kzalloc(ph->dev, sizeof(*pinfo), GFP_KERNEL);
> > + if (!pinfo)
> > + return -ENOMEM;
> > +
> > + ret = scmi_pinctrl_attributes_get(ph, pinfo);
> > + if (ret)
> > + return ret;
>
> ..as a I was saying is nr_pins == 0 the scmi_pinctrl_attributes_get could return
> -EINVAL here and bail out....not sure that a running setup with zero pins has
> any values (even for testing...) BUT, as said above, I wuld certainly add a
> dev_warn in scmi_pinctrl_attributes_get() when nr_pins == 0
Fix it in v7.
Thanks,
Peng.
>
> Thanks,
> Cristian
^ permalink raw reply
* [PATCH v4] dt-bindings: serial: actions,owl-uart: convert to dtschema
From: Kanak Shilledar @ 2024-03-31 13:28 UTC (permalink / raw)
Cc: krzysztof.kozlowski+dt, robh+dt, devicetree, daniel.baluta,
Kanak Shilledar, Krzysztof Kozlowski
From: Kanak Shilledar <kanakshilledar111@protonmail.com>
Convert the Actions Semi Owl UART to newer DT schema.
Created DT schema based on the .txt file which had
`compatible`, `reg` and `interrupts` as the
required properties. This binding is used by Actions S500, S700
and S900 SoC. S700 and S900 use the same UART compatible string.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Kanak Shilledar <kanakshilledar111@protonmail.com>
---
Changes in v4
- added `clocks` property to fix warning of 'clocks' was unexpected
while running `make dtbs_check`. `clocks` property was not defined
in the original .txt file. `clocks` property is removed from the
required section.
- added `clocks` property in example
- extended the devicetree with clocks node
---
.../bindings/serial/actions,owl-uart.txt | 16 -------
.../bindings/serial/actions,owl-uart.yaml | 48 +++++++++++++++++++
2 files changed, 48 insertions(+), 16 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/serial/actions,owl-uart.txt
create mode 100644 Documentation/devicetree/bindings/serial/actions,owl-uart.yaml
diff --git a/Documentation/devicetree/bindings/serial/actions,owl-uart.txt b/Documentation/devicetree/bindings/serial/actions,owl-uart.txt
deleted file mode 100644
index aa873eada02d..000000000000
--- a/Documentation/devicetree/bindings/serial/actions,owl-uart.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Actions Semi Owl UART
-
-Required properties:
-- compatible : "actions,s500-uart", "actions,owl-uart" for S500
- "actions,s900-uart", "actions,owl-uart" for S900
-- reg : Offset and length of the register set for the device.
-- interrupts : Should contain UART interrupt.
-
-
-Example:
-
- uart3: serial@b0126000 {
- compatible = "actions,s500-uart", "actions,owl-uart";
- reg = <0xb0126000 0x1000>;
- interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
- };
diff --git a/Documentation/devicetree/bindings/serial/actions,owl-uart.yaml b/Documentation/devicetree/bindings/serial/actions,owl-uart.yaml
new file mode 100644
index 000000000000..ab1c4514ae93
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/actions,owl-uart.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/actions,owl-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Actions Semi Owl UART
+
+maintainers:
+ - Kanak Shilledar <kanakshilledar111@protonmail.com>
+
+allOf:
+ - $ref: serial.yaml
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - actions,s500-uart
+ - actions,s900-uart
+ - const: actions,owl-uart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/actions,s500-cmu.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ uart0: serial@b0126000 {
+ compatible = "actions,s500-uart", "actions,owl-uart";
+ reg = <0xb0126000 0x1000>;
+ clocks = <&cmu CLK_UART0>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ };
--
2.34.1
^ permalink raw reply related
* RE: [EXTERNAL] Re: [PATCH v7 4/4] ASoc: dt-bindings: PCM6240: Add initial DT binding
From: Ding, Shenghao @ 2024-03-31 13:20 UTC (permalink / raw)
To: Krzysztof Kozlowski, linux-kernel@vger.kernel.org
Cc: lgirdwood@gmail.com, broonie@kernel.org, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
linux-sound@vger.kernel.org, devicetree@vger.kernel.org,
perex@perex.cz, tiwai@suse.com, 13916275206@139.com,
Chawla, Mohit, soyer@irl.hu, Huang, Jonathan, tiwai@suse.de,
Djuandi, Peter, Agrawal, Manisha, Hari, Raj, Yashar, Avi,
Nagalla, Hari, Bajjuri, Praneeth, Baojun.Xu@fpt.com, Rob Herring
In-Reply-To: <cc7a60c3-4a1e-4f32-b6ef-4a41d5c48eaf@linaro.org>
Hi Krzysztof
Answer inline
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Sunday, March 31, 2024 4:15 PM
> To: Ding, Shenghao <shenghao-ding@ti.com>; linux-kernel@vger.kernel.org
> Cc: lgirdwood@gmail.com; broonie@kernel.org; robh+dt@kernel.org;
> krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org; linux-
> sound@vger.kernel.org; devicetree@vger.kernel.org; perex@perex.cz;
> tiwai@suse.com; 13916275206@139.com; Chawla, Mohit
> <mohit.chawla@ti.com>; soyer@irl.hu; Huang, Jonathan
> <jkhuang3@ti.com>; tiwai@suse.de; Djuandi, Peter <pdjuandi@ti.com>;
> Agrawal, Manisha <manisha.agrawal@ti.com>; Hari, Raj <s-hari@ti.com>;
> Yashar, Avi <aviel@ti.com>; Nagalla, Hari <hnagalla@ti.com>; Bajjuri,
> Praneeth <praneeth@ti.com>; Baojun.Xu@fpt.com; Rob Herring
> <robh@kernel.org>
> Subject: [EXTERNAL] Re: [PATCH v7 4/4] ASoc: dt-bindings: PCM6240: Add
> initial DT binding
>
.............................
> > - remove unneeded items and if branches.
> > - Add missing compatible devices, such as adc6120, etc.
> > - Add necessary people into the list for DTS review
> > - correct misaligned.
> > - simplify the compatibility
> > - remove sound-name-prefix and revert back
> > - Add review information
>
> All these changes in v7 and you still kept Rob's review? I think either review
> was not given or your changelog is just incorrect.
Since Rob's review, nothing changed in yaml. Even in this patch, only removed kcontrol interfaces
in the code and added the mixer-test report in cover-letter as Mark suggested, which is no effect
on yaml file.
>
>
>
> Best regards,
> Krzysztof
^ permalink raw reply
* RE: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support
From: Peng Fan @ 2024-03-31 12:47 UTC (permalink / raw)
To: Dan Carpenter, Peng Fan (OSS)
Cc: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Linus Walleij, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, Oleksii Moisieiev
In-Reply-To: <4879ad5d-165c-4118-81f7-8f6348a5a5d4@moroto.mountain>
Hi Dan,
> Subject: Re: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol
> protocol basic support
>
> Looks really nice. Just a few small comments below.
>
> On Sat, Mar 23, 2024 at 08:15:16PM +0800, Peng Fan (OSS) wrote:
> > +
> > +struct scmi_msg_func_set {
> > + __le32 identifier;
> > + __le32 function_id;
> > + __le32 flags;
> > +};
>
> This scmi_msg_func_set struct is unused. Delete.
>
> > +static void
> > +iter_pinctrl_settings_get_prepare_message(void *message, u32 desc_index,
> > + const void *priv)
> > +{
> > + struct scmi_msg_settings_get *msg = message;
> > + const struct scmi_settings_get_ipriv *p = priv;
> > + u32 attributes;
> > +
> > + attributes = FIELD_PREP(CONFIG_FLAG_MASK, p->flag) |
> > + FIELD_PREP(SELECTOR_MASK, p->type);
> > +
> > + if (p->flag == 1)
> > + attributes |= FIELD_PREP(SKIP_CONFIGS_MASK, desc_index);
> > + else if (!p->flag)
>
> This is a nit-pick but could you change these !p->flag conditions to
> p->flag == 0? It's a number zero, not a bool.
>
> > + attributes |= FIELD_PREP(CONFIG_TYPE_MASK, p-
> >config_types[0]);
> > +
> > + msg->attributes = cpu_to_le32(attributes);
> > + msg->identifier = cpu_to_le32(p->selector); }
> > +
> > +static int
> > +iter_pinctrl_settings_get_update_state(struct scmi_iterator_state *st,
> > + const void *response, void *priv) {
> > + const struct scmi_resp_settings_get *r = response;
> > + struct scmi_settings_get_ipriv *p = priv;
> > +
> > + if (p->flag == 1) {
> > + st->num_returned = le32_get_bits(r->num_configs,
> GENMASK(7, 0));
> > + st->num_remaining = le32_get_bits(r->num_configs,
> > + GENMASK(31, 24));
> > + } else {
> > + st->num_returned = 1;
> > + st->num_remaining = 0;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int
> > +iter_pinctrl_settings_get_process_response(const struct
> scmi_protocol_handle *ph,
> > + const void *response,
> > + struct scmi_iterator_state *st,
> > + void *priv)
> > +{
> > + const struct scmi_resp_settings_get *r = response;
> > + struct scmi_settings_get_ipriv *p = priv;
> > +
> > + if (!p->flag) {
>
>
> if (p->flag == 0) {
>
> > + if (p->config_types[0] !=
> > + le32_get_bits(r->configs[st->loop_idx * 2], GENMASK(7, 0)))
> > + return -EINVAL;
> > + } else if (p->flag == 1) {
> > + p->config_types[st->desc_index + st->loop_idx] =
> > + le32_get_bits(r->configs[st->loop_idx * 2],
> > + GENMASK(7, 0));
> > + } else if (p->flag == 2) {
> > + return 0;
> > + }
> > +
> > + p->config_values[st->desc_index + st->loop_idx] =
> > + le32_to_cpu(r->configs[st->loop_idx * 2 + 1]);
> > +
> > + return 0;
> > +}
> > +
> > +static int
> > +scmi_pinctrl_settings_get(const struct scmi_protocol_handle *ph, u32
> selector,
> > + enum scmi_pinctrl_selector_type type,
> > + enum scmi_pinctrl_conf_type config_type,
> > + u32 *config_value)
> > +{
> > + int ret;
> > + void *iter;
> > + struct scmi_iterator_ops ops = {
> > + .prepare_message =
> iter_pinctrl_settings_get_prepare_message,
> > + .update_state = iter_pinctrl_settings_get_update_state,
> > + .process_response =
> iter_pinctrl_settings_get_process_response,
> > + };
> > + struct scmi_settings_get_ipriv ipriv = {
> > + .selector = selector,
> > + .type = type,
> > + .flag = 0,
>
> ->flag should be 0-2.
>
> > + .config_types = &config_type,
> > + .config_values = config_value,
> > + };
> > +
> > + if (!config_value || type == FUNCTION_TYPE)
> ^^^^^^^^^^^^
> config_value should be optional for flag == 2.
As Cristian replied, I would keep it as is until we have a case in
linux that need flag == 2.
Thanks,
Peng
>
> regards,
> dan carpenter
>
> > + return -EINVAL;
> > +
> > + ret = scmi_pinctrl_validate_id(ph, selector, type);
> > + if (ret)
> > + return ret;
> > +
> > + iter = ph->hops->iter_response_init(ph, &ops, 1,
> PINCTRL_SETTINGS_GET,
> > + sizeof(struct
> scmi_msg_settings_get),
> > + &ipriv);
> > +
> > + if (IS_ERR(iter))
> > + return PTR_ERR(iter);
> > +
> > + return ph->hops->iter_response_run(iter);
> > +}
> > +
^ permalink raw reply
* RE: [PATCH v5 4/4] clk: imx: add i.MX95 BLK CTL clk driver
From: Peng Fan @ 2024-03-31 12:01 UTC (permalink / raw)
To: Krzysztof Kozlowski, Peng Fan (OSS), Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Abel Vesa
Cc: linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <d3770f5e-f3cc-40fd-a211-b229be46d974@linaro.org>
> Subject: Re: [PATCH v5 4/4] clk: imx: add i.MX95 BLK CTL clk driver
>
> On 24/03/2024 08:52, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
>
> ...
>
> > +
> > +static const struct of_device_id imx95_bc_of_match[] = {
> > + { .compatible = "nxp,imx95-camera-csr", .data = &camblk_dev_data },
> > + { .compatible = "nxp,imx95-display-master-csr", },
> > + { .compatible = "nxp,imx95-lvds-csr", .data = &lvds_csr_dev_data },
> > + { .compatible = "nxp,imx95-display-csr", .data =
> &dispmix_csr_dev_data },
> > + { .compatible = "nxp,imx95-vpu-csr", .data = &vpublk_dev_data },
> > + { /* Sentinel */ },
> > +};
> > +MODULE_DEVICE_TABLE(of, imx95_bc_of_match);
> > +
> > +static struct platform_driver imx95_bc_driver = {
> > + .probe = imx95_bc_probe,
> > + .driver = {
> > + .name = "imx95-blk-ctl",
> > + .of_match_table = of_match_ptr(imx95_bc_of_match),
>
> Drop of_match_ptr(), causes warnings. From where did you copy such code?
> Which mainline driver has such pattern?
I recall that when COMPILE_TEST is selected, OF is not selected, kernel
robot reports warning. This may not be true now.
I could drop it in v6.
Thanks,
Peng.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* RE: [PATCH v5 0/4] Add support i.MX95 BLK CTL module clock features
From: Peng Fan @ 2024-03-31 12:00 UTC (permalink / raw)
To: Krzysztof Kozlowski, Peng Fan (OSS), Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Abel Vesa
Cc: linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <ce1b814a-6b1b-4773-ad29-b572d00f56c9@linaro.org>
> Subject: Re: [PATCH v5 0/4] Add support i.MX95 BLK CTL module clock
> features
>
> On 24/03/2024 08:51, Peng Fan (OSS) wrote:
> > i.MX95's several MIXes has BLK CTL module which could be used for clk
> > settings, QoS settings, Misc settings for a MIX. This patchset is to
> > add the clk feature support, including dt-bindings
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > Changes in v5:
> > - Merge bindings except the one has mux-controller
> > - Separate clock ID headers in a separate patch per Rob's comments
>
> Where did he suggest it?
See https://lore.kernel.org/all/20240315165422.GA1472059-robh@kernel.org/
Thanks,
Peng.
>
>
>
> Best regards,
> Krzysztof
^ permalink raw reply
* RE: [PATCH v5 1/4] dt-bindings: clock: support i.MX95 BLK CTL module
From: Peng Fan @ 2024-03-31 11:58 UTC (permalink / raw)
To: Krzysztof Kozlowski, Peng Fan (OSS), Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Abel Vesa
Cc: linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1709e7df-268b-4da6-a75d-9d7ce80d9a41@linaro.org>
> Subject: Re: [PATCH v5 1/4] dt-bindings: clock: support i.MX95 BLK CTL
> module
>
> On 24/03/2024 08:52, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > i.MX95 includes BLK CTL module in several MIXes, such as VPU_CSR in
> > VPUMIX, CAMERA_CSR in CAMERAMIX and etc.
> >
> > The BLK CTL module is used for various settings of a specific MIX,
> > such as clock, QoS and etc.
> >
> > This patch is to add some BLK CTL modules that has clock features.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > .../bindings/clock/nxp,imx95-blk-ctl.yaml | 56
> ++++++++++++++++++++++
> > 1 file changed, 56 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml
> > b/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml
> > new file mode 100644
> > index 000000000000..2dffc02dcd8b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml
> > @@ -0,0 +1,56 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> > +cetree.org%2Fschemas%2Fclock%2Fnxp%2Cimx95-blk-
> ctl.yaml%23&data=05%7C
> >
> +02%7Cpeng.fan%40nxp.com%7Cd713a861f155495c922a08dc4d01346d%7
> C686ea1d3
> >
> +bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638469914764776121%7CUnk
> nown%7CTWF
> >
> +pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VCI6
> >
> +Mn0%3D%7C0%7C%7C%7C&sdata=rW7%2BGedk3bloLsAqBIkMlXQNjDmRd
> Z0cHacQtKxjc
> > +mQ%3D&reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> > +cetree.org%2Fmeta-
> schemas%2Fcore.yaml%23&data=05%7C02%7Cpeng.fan%40nx
> >
> +p.com%7Cd713a861f155495c922a08dc4d01346d%7C686ea1d3bc2b4c6fa9
> 2cd99c5c
> >
> +301635%7C0%7C0%7C638469914764787067%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiM
> >
> +C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7
> >
> +C&sdata=tFzM3%2BxuQVsit9lCEnNz8kYnZjT%2FXj%2Fdqzk9DB9oy1c%3D&r
> eserved
> > +=0
> > +
> > +title: NXP i.MX95 Block Control
> > +
> > +maintainers:
> > + - Peng Fan <peng.fan@nxp.com>
> > +
> > +properties:
> > + compatible:
> > + items:
> > + - enum:
> > + - nxp,imx95-lvds-csr
> > + - nxp,imx95-display-csr
> > + - nxp,imx95-camera-csr
> > + - nxp,imx95-vpu-csr
> > + - const: syscon
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + power-domains:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + '#clock-cells':
> > + const: 1
> > + description:
> > + The clock consumer should specify the desired clock by having the
> clock
> > + ID in its "clocks" phandle cell. See
> > + include/dt-bindings/clock/nxp,imx95-clock.h
>
> In such case, put header as your first patch in the patchset. I don't understand
> why it was split in the first place...
Rob gave a comment in v4, so I split the headers.
"
If this number can change, then it is not ABI and doesn't go in this
header. With that dropped,
"
https://lore.kernel.org/all/20240315165422.GA1472059-robh@kernel.org/
Thanks,
Peng.
>
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH 2/5] mfd: add driver for Marvell 88PM886 PMIC
From: Karel Balej @ 2024-03-31 10:46 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Liam Girdwood, Mark Brown, devicetree,
linux-kernel, linux-input
Cc: Duje Mihanović, ~postmarketos/upstreaming, phone-devel
In-Reply-To: <20240331105608.7338-2-balejk@matfyz.cz>
Marvell 88PM886 is a PMIC which provides various functions such as
onkey, battery, charger and regulators. It is found for instance in the
samsung,coreprimevelte smartphone with which this was tested. Implement
basic support to allow for the use of regulators and onkey.
Signed-off-by: Karel Balej <balejk@matfyz.cz>
---
Notes:
v1:
- Address Mark's feedback:
- Move regmap config back out of the header and rename it. Also lower
its maximum register based on what's actually used in the downstream
code.
RFC v4:
- Use MFD_CELL_* macros.
- Address Lee's feedback:
- Do not define regmap_config.val_bits and .reg_bits.
- Drop everything regulator related except mfd_cell (regmap
initialization, IDs enum etc.). Drop pm886_initialize_subregmaps.
- Do not store regmap pointers as an array as there is now only one
regmap. Also drop the corresponding enum.
- Move regmap_config to the header as it is needed in the regulators
driver.
- pm886_chip.whoami -> chip_id
- Reword chip ID mismatch error message and print the ID as
hexadecimal.
- Fix includes in include/linux/88pm886.h.
- Drop the pm886_irq_number enum and define the (for the moment) only
IRQ explicitly.
- Have only one MFD cell for all regulators as they are now registered
all at once in the regulators driver.
- Reword commit message.
- Make device table static and remove comma after the sentinel to signal
that nothing should come after it.
RFC v3:
- Drop onkey cell .of_compatible.
- Rename LDO page offset and regmap to REGULATORS.
RFC v2:
- Remove some abstraction.
- Sort includes alphabetically and add linux/of.h.
- Depend on OF, remove of_match_ptr and add MODULE_DEVICE_TABLE.
- Use more temporaries and break long lines.
- Do not initialize ret in probe.
- Use the wakeup-source DT property.
- Rename ret to err.
- Address Lee's comments:
- Drop patched in presets for base regmap and related defines.
- Use full sentences in comments.
- Remove IRQ comment.
- Define regmap_config member values.
- Rename data to sys_off_data.
- Add _PMIC suffix to Kconfig.
- Use dev_err_probe.
- Do not store irq_data.
- s/WHOAMI/CHIP_ID
- Drop LINUX part of include guard name.
- Merge in the regulator series modifications in order to have more
devices and modify the commit message accordingly. Changes with
respect to the original regulator series patches:
- ret -> err
- Add temporary for dev in pm88x_initialize_subregmaps.
- Drop of_compatible for the regulators.
- Do not duplicate LDO regmap for bucks.
- Rewrite commit message.
drivers/mfd/88pm886.c | 157 ++++++++++++++++++++++++++++++++++++
drivers/mfd/Kconfig | 12 +++
drivers/mfd/Makefile | 1 +
include/linux/mfd/88pm886.h | 30 +++++++
4 files changed, 200 insertions(+)
create mode 100644 drivers/mfd/88pm886.c
create mode 100644 include/linux/mfd/88pm886.h
diff --git a/drivers/mfd/88pm886.c b/drivers/mfd/88pm886.c
new file mode 100644
index 000000000000..e06d418a5da9
--- /dev/null
+++ b/drivers/mfd/88pm886.c
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include <linux/i2c.h>
+#include <linux/mfd/core.h>
+#include <linux/module.h>
+#include <linux/notifier.h>
+#include <linux/of.h>
+#include <linux/reboot.h>
+#include <linux/regmap.h>
+
+#include <linux/mfd/88pm886.h>
+
+#define PM886_REG_INT_STATUS1 0x05
+
+#define PM886_REG_INT_ENA_1 0x0a
+#define PM886_INT_ENA1_ONKEY BIT(0)
+
+#define PM886_IRQ_ONKEY 0
+
+#define PM886_REGMAP_CONF_MAX_REG 0xef
+
+static const struct regmap_config pm886_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = PM886_REGMAP_CONF_MAX_REG,
+};
+
+static struct regmap_irq pm886_regmap_irqs[] = {
+ REGMAP_IRQ_REG(PM886_IRQ_ONKEY, 0, PM886_INT_ENA1_ONKEY),
+};
+
+static struct regmap_irq_chip pm886_regmap_irq_chip = {
+ .name = "88pm886",
+ .irqs = pm886_regmap_irqs,
+ .num_irqs = ARRAY_SIZE(pm886_regmap_irqs),
+ .num_regs = 4,
+ .status_base = PM886_REG_INT_STATUS1,
+ .ack_base = PM886_REG_INT_STATUS1,
+ .unmask_base = PM886_REG_INT_ENA_1,
+};
+
+static struct resource pm886_onkey_resources[] = {
+ DEFINE_RES_IRQ_NAMED(PM886_IRQ_ONKEY, "88pm886-onkey"),
+};
+
+static struct mfd_cell pm886_devs[] = {
+ MFD_CELL_RES("88pm886-onkey", pm886_onkey_resources),
+ MFD_CELL_NAME("88pm886-regulator"),
+};
+
+static int pm886_power_off_handler(struct sys_off_data *sys_off_data)
+{
+ struct pm886_chip *chip = sys_off_data->cb_data;
+ struct regmap *regmap = chip->regmap;
+ struct device *dev = &chip->client->dev;
+ int err;
+
+ err = regmap_update_bits(regmap, PM886_REG_MISC_CONFIG1, PM886_SW_PDOWN,
+ PM886_SW_PDOWN);
+ if (err) {
+ dev_err(dev, "Failed to power off the device: %d\n", err);
+ return NOTIFY_BAD;
+ }
+ return NOTIFY_DONE;
+}
+
+static int pm886_setup_irq(struct pm886_chip *chip,
+ struct regmap_irq_chip_data **irq_data)
+{
+ struct regmap *regmap = chip->regmap;
+ struct device *dev = &chip->client->dev;
+ int err;
+
+ /* Set interrupt clearing mode to clear on write. */
+ err = regmap_update_bits(regmap, PM886_REG_MISC_CONFIG2,
+ PM886_INT_INV | PM886_INT_CLEAR | PM886_INT_MASK_MODE,
+ PM886_INT_WC);
+ if (err) {
+ dev_err(dev, "Failed to set interrupt clearing mode: %d\n", err);
+ return err;
+ }
+
+ err = devm_regmap_add_irq_chip(dev, regmap, chip->client->irq,
+ IRQF_ONESHOT, -1, &pm886_regmap_irq_chip,
+ irq_data);
+ if (err) {
+ dev_err(dev, "Failed to request IRQ: %d\n", err);
+ return err;
+ }
+
+ return 0;
+}
+
+static int pm886_probe(struct i2c_client *client)
+{
+ struct regmap_irq_chip_data *irq_data;
+ struct device *dev = &client->dev;
+ struct pm886_chip *chip;
+ struct regmap *regmap;
+ unsigned int chip_id;
+ int err;
+
+ chip = devm_kzalloc(dev, sizeof(*chip), GFP_KERNEL);
+ if (!chip)
+ return -ENOMEM;
+
+ chip->client = client;
+ chip->chip_id = (uintptr_t)device_get_match_data(dev);
+ i2c_set_clientdata(client, chip);
+
+ regmap = devm_regmap_init_i2c(client, &pm886_regmap_config);
+ if (IS_ERR(regmap))
+ return dev_err_probe(dev, PTR_ERR(regmap), "Failed to initialize regmap\n");
+ chip->regmap = regmap;
+
+ err = regmap_read(regmap, PM886_REG_ID, &chip_id);
+ if (err)
+ return dev_err_probe(dev, err, "Failed to read chip ID\n");
+
+ if (chip->chip_id != chip_id)
+ return dev_err_probe(dev, -EINVAL, "Unsupported chip: 0x%x\n", chip_id);
+
+ err = pm886_setup_irq(chip, &irq_data);
+ if (err)
+ return err;
+
+ err = devm_mfd_add_devices(dev, 0, pm886_devs, ARRAY_SIZE(pm886_devs),
+ NULL, 0, regmap_irq_get_domain(irq_data));
+ if (err)
+ return dev_err_probe(dev, err, "Failed to add devices\n");
+
+ err = devm_register_power_off_handler(dev, pm886_power_off_handler, chip);
+ if (err)
+ return dev_err_probe(dev, err, "Failed to register power off handler\n");
+
+ device_init_wakeup(dev, device_property_read_bool(dev, "wakeup-source"));
+
+ return 0;
+}
+
+static const struct of_device_id pm886_of_match[] = {
+ { .compatible = "marvell,88pm886-a1", .data = (void *)PM886_A1_CHIP_ID },
+ { }
+};
+MODULE_DEVICE_TABLE(of, pm886_of_match);
+
+static struct i2c_driver pm886_i2c_driver = {
+ .driver = {
+ .name = "88pm886",
+ .of_match_table = pm886_of_match,
+ },
+ .probe = pm886_probe,
+};
+module_i2c_driver(pm886_i2c_driver);
+
+MODULE_DESCRIPTION("Marvell 88PM886 PMIC driver");
+MODULE_AUTHOR("Karel Balej <balejk@matfyz.cz>");
+MODULE_LICENSE("GPL");
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 4b023ee229cf..d6a762b2bd47 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -794,6 +794,18 @@ config MFD_88PM860X
select individual components like voltage regulators, RTC and
battery-charger under the corresponding menus.
+config MFD_88PM886_PMIC
+ bool "Marvell 88PM886 PMIC"
+ depends on I2C=y
+ depends on OF
+ select REGMAP_I2C
+ select REGMAP_IRQ
+ select MFD_CORE
+ help
+ This enables support for Marvell 88PM886 Power Management IC.
+ This includes the I2C driver and the core APIs _only_, you have to
+ select individual components like onkey under the corresponding menus.
+
config MFD_MAX14577
tristate "Maxim Semiconductor MAX14577/77836 MUIC + Charger Support"
depends on I2C
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index c66f07edcd0e..d016b7fed354 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -7,6 +7,7 @@
obj-$(CONFIG_MFD_88PM860X) += 88pm860x.o
obj-$(CONFIG_MFD_88PM800) += 88pm800.o 88pm80x.o
obj-$(CONFIG_MFD_88PM805) += 88pm805.o 88pm80x.o
+obj-$(CONFIG_MFD_88PM886_PMIC) += 88pm886.o
obj-$(CONFIG_MFD_ACT8945A) += act8945a.o
obj-$(CONFIG_MFD_SM501) += sm501.o
obj-$(CONFIG_ARCH_BCM2835) += bcm2835-pm.o
diff --git a/include/linux/mfd/88pm886.h b/include/linux/mfd/88pm886.h
new file mode 100644
index 000000000000..5ce30a3b85aa
--- /dev/null
+++ b/include/linux/mfd/88pm886.h
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __MFD_88PM886_H
+#define __MFD_88PM886_H
+
+#include <linux/i2c.h>
+#include <linux/regmap.h>
+
+#define PM886_A1_CHIP_ID 0xa1
+
+#define PM886_REG_ID 0x00
+
+#define PM886_REG_STATUS1 0x01
+#define PM886_ONKEY_STS1 BIT(0)
+
+#define PM886_REG_MISC_CONFIG1 0x14
+#define PM886_SW_PDOWN BIT(5)
+
+#define PM886_REG_MISC_CONFIG2 0x15
+#define PM886_INT_INV BIT(0)
+#define PM886_INT_CLEAR BIT(1)
+#define PM886_INT_RC 0x00
+#define PM886_INT_WC BIT(1)
+#define PM886_INT_MASK_MODE BIT(2)
+
+struct pm886_chip {
+ struct i2c_client *client;
+ unsigned int chip_id;
+ struct regmap *regmap;
+};
+#endif /* __MFD_88PM886_H */
--
2.44.0
^ permalink raw reply related
* [PATCH 5/5] MAINTAINERS: add myself for Marvell 88PM886 PMIC
From: Karel Balej @ 2024-03-31 10:46 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Liam Girdwood, Mark Brown, devicetree,
linux-kernel, linux-input
Cc: Duje Mihanović, ~postmarketos/upstreaming, phone-devel
In-Reply-To: <20240331105608.7338-2-balejk@matfyz.cz>
Add an entry to MAINTAINERS for the Marvell 88PM886 PMIC MFD, onkey and
regulator drivers.
Signed-off-by: Karel Balej <balejk@matfyz.cz>
---
Notes:
RFC v3:
- Remove onkey bindings file.
RFC v2:
- Only mention 88PM886 in the commit message.
- Add regulator driver.
- Rename the entry.
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index aa3b947fb080..c6bdf93ea3a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13048,6 +13048,15 @@ F: drivers/net/dsa/mv88e6xxx/
F: include/linux/dsa/mv88e6xxx.h
F: include/linux/platform_data/mv88e6xxx.h
+MARVELL 88PM886 PMIC DRIVER
+M: Karel Balej <balejk@matfyz.cz>
+S: Maintained
+F: Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml
+F: drivers/input/misc/88pm886-onkey.c
+F: drivers/mfd/88pm886.c
+F: drivers/regulators/88pm886-regulator.c
+F: include/linux/mfd/88pm886.h
+
MARVELL ARMADA 3700 PHY DRIVERS
M: Miquel Raynal <miquel.raynal@bootlin.com>
S: Maintained
--
2.44.0
^ permalink raw reply related
* [PATCH 3/5] regulator: add regulators driver for Marvell 88PM886 PMIC
From: Karel Balej @ 2024-03-31 10:46 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Liam Girdwood, Mark Brown, devicetree,
linux-kernel, linux-input
Cc: Duje Mihanović, ~postmarketos/upstreaming, phone-devel
In-Reply-To: <20240331105608.7338-2-balejk@matfyz.cz>
Support the LDO and buck regulators of the Marvell 88PM886 PMIC.
Signed-off-by: Karel Balej <balejk@matfyz.cz>
---
Notes:
v1:
- Add remaining regulators.
- Clean up includes.
- Address Mark's feedback:
- Use dedicated regmap config.
RFC v4:
- Initialize regulators regmap in the regulators driver.
- Register all regulators at once.
- Drop regulator IDs.
- Add missing '\n' to dev_err_probe message.
- Fix includes.
- Add ID table.
RFC v3:
- Do not have a variable for each regulator -- define them all in the
pm886_regulators array.
- Use new regulators regmap index name.
- Use dev_err_probe.
RFC v2:
- Drop of_compatible and related code.
- Drop unused include.
- Remove some abstraction: use only one regmap for all regulators and
only mention 88PM886 in Kconfig description.
- Reword commit message.
drivers/regulator/88pm886-regulator.c | 509 ++++++++++++++++++++++++++
drivers/regulator/Kconfig | 6 +
drivers/regulator/Makefile | 1 +
3 files changed, 516 insertions(+)
create mode 100644 drivers/regulator/88pm886-regulator.c
diff --git a/drivers/regulator/88pm886-regulator.c b/drivers/regulator/88pm886-regulator.c
new file mode 100644
index 000000000000..05d24bf444cb
--- /dev/null
+++ b/drivers/regulator/88pm886-regulator.c
@@ -0,0 +1,509 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/regulator/driver.h>
+
+#include <linux/mfd/88pm886.h>
+
+#define PM886_PAGE_OFFSET_REGULATORS 1
+
+#define PM886_REG_LDO_EN1 0x09
+#define PM886_REG_LDO_EN2 0x0a
+
+#define PM886_REG_BUCK_EN 0x08
+
+#define PM886_REG_LDO1_VOUT 0x20
+#define PM886_REG_LDO2_VOUT 0x26
+#define PM886_REG_LDO3_VOUT 0x2c
+#define PM886_REG_LDO4_VOUT 0x32
+#define PM886_REG_LDO5_VOUT 0x38
+#define PM886_REG_LDO6_VOUT 0x3e
+#define PM886_REG_LDO7_VOUT 0x44
+#define PM886_REG_LDO8_VOUT 0x4a
+#define PM886_REG_LDO9_VOUT 0x50
+#define PM886_REG_LDO10_VOUT 0x56
+#define PM886_REG_LDO11_VOUT 0x5c
+#define PM886_REG_LDO12_VOUT 0x62
+#define PM886_REG_LDO13_VOUT 0x68
+#define PM886_REG_LDO14_VOUT 0x6e
+#define PM886_REG_LDO15_VOUT 0x74
+#define PM886_REG_LDO16_VOUT 0x7a
+
+#define PM886_REG_BUCK1_VOUT 0xa5
+#define PM886_REG_BUCK2_VOUT 0xb3
+#define PM886_REG_BUCK3_VOUT 0xc1
+#define PM886_REG_BUCK4_VOUT 0xcf
+#define PM886_REG_BUCK5_VOUT 0xdd
+
+#define PM886_LDO_VSEL_MASK 0x0f
+#define PM886_BUCK_VSEL_MASK 0x7f
+
+static const struct regmap_config pm886_regulator_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = PM886_REG_BUCK5_VOUT,
+};
+
+struct pm886_regulator {
+ struct regulator_desc desc;
+ int max_uA;
+};
+
+static int pm886_regulator_get_ilim(struct regulator_dev *rdev)
+{
+ struct pm886_regulator *data = rdev_get_drvdata(rdev);
+
+ if (!data) {
+ dev_err(&rdev->dev, "Failed to get regulator data\n");
+ return -EINVAL;
+ }
+ return data->max_uA;
+}
+
+static const struct regulator_ops pm886_ldo_ops = {
+ .list_voltage = regulator_list_voltage_table,
+ .map_voltage = regulator_map_voltage_iterate,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .get_current_limit = pm886_regulator_get_ilim,
+};
+
+static const struct regulator_ops pm886_buck_ops = {
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage = regulator_map_voltage_linear_range,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .get_current_limit = pm886_regulator_get_ilim,
+};
+
+static const unsigned int pm886_ldo_volt_table1[] = {
+ 1700000, 1800000, 1900000, 2500000, 2800000, 2900000, 3100000, 3300000,
+};
+
+static const unsigned int pm886_ldo_volt_table2[] = {
+ 1200000, 1250000, 1700000, 1800000, 1850000, 1900000, 2500000, 2600000,
+ 2700000, 2750000, 2800000, 2850000, 2900000, 3000000, 3100000, 3300000,
+};
+
+static const unsigned int pm886_ldo_volt_table3[] = {
+ 1700000, 1800000, 1900000, 2000000, 2100000, 2500000, 2700000, 2800000,
+};
+
+static const struct linear_range pm886_buck_volt_ranges1[] = {
+ REGULATOR_LINEAR_RANGE(600000, 0, 79, 12500),
+ REGULATOR_LINEAR_RANGE(1600000, 80, 84, 50000),
+};
+
+static const struct linear_range pm886_buck_volt_ranges2[] = {
+ REGULATOR_LINEAR_RANGE(600000, 0, 79, 12500),
+ REGULATOR_LINEAR_RANGE(1600000, 80, 114, 50000),
+};
+
+static struct pm886_regulator pm886_regulators[] = {
+ {
+ .desc = {
+ .name = "LDO1",
+ .regulators_node = "regulators",
+ .of_match = "ldo1",
+ .ops = &pm886_ldo_ops,
+ .type = REGULATOR_VOLTAGE,
+ .enable_reg = PM886_REG_LDO_EN1,
+ .enable_mask = BIT(0),
+ .volt_table = pm886_ldo_volt_table1,
+ .n_voltages = ARRAY_SIZE(pm886_ldo_volt_table1),
+ .vsel_reg = PM886_REG_LDO1_VOUT,
+ .vsel_mask = PM886_LDO_VSEL_MASK,
+ },
+ .max_uA = 100000,
+ },
+ {
+ .desc = {
+ .name = "LDO2",
+ .regulators_node = "regulators",
+ .of_match = "ldo2",
+ .ops = &pm886_ldo_ops,
+ .type = REGULATOR_VOLTAGE,
+ .enable_reg = PM886_REG_LDO_EN1,
+ .enable_mask = BIT(1),
+ .volt_table = pm886_ldo_volt_table1,
+ .n_voltages = ARRAY_SIZE(pm886_ldo_volt_table1),
+ .vsel_reg = PM886_REG_LDO2_VOUT,
+ .vsel_mask = PM886_LDO_VSEL_MASK,
+ },
+ .max_uA = 100000,
+ },
+ {
+ .desc = {
+ .name = "LDO3",
+ .regulators_node = "regulators",
+ .of_match = "ldo3",
+ .ops = &pm886_ldo_ops,
+ .type = REGULATOR_VOLTAGE,
+ .enable_reg = PM886_REG_LDO_EN1,
+ .enable_mask = BIT(2),
+ .volt_table = pm886_ldo_volt_table1,
+ .n_voltages = ARRAY_SIZE(pm886_ldo_volt_table1),
+ .vsel_reg = PM886_REG_LDO3_VOUT,
+ .vsel_mask = PM886_LDO_VSEL_MASK,
+ },
+ .max_uA = 100000,
+ },
+ {
+ .desc = {
+ .name = "LDO4",
+ .regulators_node = "regulators",
+ .of_match = "ldo4",
+ .ops = &pm886_ldo_ops,
+ .type = REGULATOR_VOLTAGE,
+ .enable_reg = PM886_REG_LDO_EN1,
+ .enable_mask = BIT(3),
+ .volt_table = pm886_ldo_volt_table2,
+ .n_voltages = ARRAY_SIZE(pm886_ldo_volt_table2),
+ .vsel_reg = PM886_REG_LDO4_VOUT,
+ .vsel_mask = PM886_LDO_VSEL_MASK,
+ },
+ .max_uA = 400000,
+ },
+ {
+ .desc = {
+ .name = "LDO5",
+ .regulators_node = "regulators",
+ .of_match = "ldo5",
+ .ops = &pm886_ldo_ops,
+ .type = REGULATOR_VOLTAGE,
+ .enable_reg = PM886_REG_LDO_EN1,
+ .enable_mask = BIT(4),
+ .volt_table = pm886_ldo_volt_table2,
+ .n_voltages = ARRAY_SIZE(pm886_ldo_volt_table2),
+ .vsel_reg = PM886_REG_LDO5_VOUT,
+ .vsel_mask = PM886_LDO_VSEL_MASK,
+ },
+ .max_uA = 400000,
+ },
+ {
+ .desc = {
+ .name = "LDO6",
+ .regulators_node = "regulators",
+ .of_match = "ldo6",
+ .ops = &pm886_ldo_ops,
+ .type = REGULATOR_VOLTAGE,
+ .enable_reg = PM886_REG_LDO_EN1,
+ .enable_mask = BIT(5),
+ .volt_table = pm886_ldo_volt_table2,
+ .n_voltages = ARRAY_SIZE(pm886_ldo_volt_table2),
+ .vsel_reg = PM886_REG_LDO6_VOUT,
+ .vsel_mask = PM886_LDO_VSEL_MASK,
+ },
+ .max_uA = 400000,
+ },
+ {
+ .desc = {
+ .name = "LDO7",
+ .regulators_node = "regulators",
+ .of_match = "ldo7",
+ .ops = &pm886_ldo_ops,
+ .type = REGULATOR_VOLTAGE,
+ .enable_reg = PM886_REG_LDO_EN1,
+ .enable_mask = BIT(6),
+ .volt_table = pm886_ldo_volt_table2,
+ .n_voltages = ARRAY_SIZE(pm886_ldo_volt_table2),
+ .vsel_reg = PM886_REG_LDO7_VOUT,
+ .vsel_mask = PM886_LDO_VSEL_MASK,
+ },
+ .max_uA = 400000,
+ },
+ {
+ .desc = {
+ .name = "LDO8",
+ .regulators_node = "regulators",
+ .of_match = "ldo8",
+ .ops = &pm886_ldo_ops,
+ .type = REGULATOR_VOLTAGE,
+ .enable_reg = PM886_REG_LDO_EN1,
+ .enable_mask = BIT(7),
+ .volt_table = pm886_ldo_volt_table2,
+ .n_voltages = ARRAY_SIZE(pm886_ldo_volt_table2),
+ .vsel_reg = PM886_REG_LDO8_VOUT,
+ .vsel_mask = PM886_LDO_VSEL_MASK,
+ },
+ .max_uA = 400000,
+ },
+ {
+ .desc = {
+ .name = "LDO9",
+ .regulators_node = "regulators",
+ .of_match = "ldo9",
+ .ops = &pm886_ldo_ops,
+ .type = REGULATOR_VOLTAGE,
+ .enable_reg = PM886_REG_LDO_EN2,
+ .enable_mask = BIT(0),
+ .volt_table = pm886_ldo_volt_table2,
+ .n_voltages = ARRAY_SIZE(pm886_ldo_volt_table2),
+ .vsel_reg = PM886_REG_LDO9_VOUT,
+ .vsel_mask = PM886_LDO_VSEL_MASK,
+ },
+ .max_uA = 400000,
+ },
+ {
+ .desc = {
+ .name = "LDO10",
+ .regulators_node = "regulators",
+ .of_match = "ldo10",
+ .ops = &pm886_ldo_ops,
+ .type = REGULATOR_VOLTAGE,
+ .enable_reg = PM886_REG_LDO_EN2,
+ .enable_mask = BIT(1),
+ .volt_table = pm886_ldo_volt_table2,
+ .n_voltages = ARRAY_SIZE(pm886_ldo_volt_table2),
+ .vsel_reg = PM886_REG_LDO10_VOUT,
+ .vsel_mask = PM886_LDO_VSEL_MASK,
+ },
+ .max_uA = 200000,
+ },
+ {
+ .desc = {
+ .name = "LDO11",
+ .regulators_node = "regulators",
+ .of_match = "ldo11",
+ .ops = &pm886_ldo_ops,
+ .type = REGULATOR_VOLTAGE,
+ .enable_reg = PM886_REG_LDO_EN2,
+ .enable_mask = BIT(2),
+ .volt_table = pm886_ldo_volt_table2,
+ .n_voltages = ARRAY_SIZE(pm886_ldo_volt_table2),
+ .vsel_reg = PM886_REG_LDO11_VOUT,
+ .vsel_mask = PM886_LDO_VSEL_MASK,
+ },
+ .max_uA = 200000,
+ },
+ {
+ .desc = {
+ .name = "LDO12",
+ .regulators_node = "regulators",
+ .of_match = "ldo12",
+ .ops = &pm886_ldo_ops,
+ .type = REGULATOR_VOLTAGE,
+ .enable_reg = PM886_REG_LDO_EN2,
+ .enable_mask = BIT(3),
+ .volt_table = pm886_ldo_volt_table2,
+ .n_voltages = ARRAY_SIZE(pm886_ldo_volt_table2),
+ .vsel_reg = PM886_REG_LDO12_VOUT,
+ .vsel_mask = PM886_LDO_VSEL_MASK,
+ },
+ .max_uA = 200000,
+ },
+ {
+ .desc = {
+ .name = "LDO13",
+ .regulators_node = "regulators",
+ .of_match = "ldo13",
+ .ops = &pm886_ldo_ops,
+ .type = REGULATOR_VOLTAGE,
+ .enable_reg = PM886_REG_LDO_EN2,
+ .enable_mask = BIT(4),
+ .volt_table = pm886_ldo_volt_table2,
+ .n_voltages = ARRAY_SIZE(pm886_ldo_volt_table2),
+ .vsel_reg = PM886_REG_LDO13_VOUT,
+ .vsel_mask = PM886_LDO_VSEL_MASK,
+ },
+ .max_uA = 200000,
+ },
+ {
+ .desc = {
+ .name = "LDO14",
+ .regulators_node = "regulators",
+ .of_match = "ldo14",
+ .ops = &pm886_ldo_ops,
+ .type = REGULATOR_VOLTAGE,
+ .enable_reg = PM886_REG_LDO_EN2,
+ .enable_mask = BIT(5),
+ .volt_table = pm886_ldo_volt_table2,
+ .n_voltages = ARRAY_SIZE(pm886_ldo_volt_table2),
+ .vsel_reg = PM886_REG_LDO14_VOUT,
+ .vsel_mask = PM886_LDO_VSEL_MASK,
+ },
+ .max_uA = 200000,
+ },
+ {
+ .desc = {
+ .name = "LDO15",
+ .regulators_node = "regulators",
+ .of_match = "ldo15",
+ .ops = &pm886_ldo_ops,
+ .type = REGULATOR_VOLTAGE,
+ .enable_reg = PM886_REG_LDO_EN2,
+ .enable_mask = BIT(6),
+ .volt_table = pm886_ldo_volt_table2,
+ .n_voltages = ARRAY_SIZE(pm886_ldo_volt_table2),
+ .vsel_reg = PM886_REG_LDO15_VOUT,
+ .vsel_mask = PM886_LDO_VSEL_MASK,
+ },
+ .max_uA = 200000,
+ },
+ {
+ .desc = {
+ .name = "LDO16",
+ .regulators_node = "regulators",
+ .of_match = "ldo16",
+ .ops = &pm886_ldo_ops,
+ .type = REGULATOR_VOLTAGE,
+ .enable_reg = PM886_REG_LDO_EN2,
+ .enable_mask = BIT(7),
+ .volt_table = pm886_ldo_volt_table3,
+ .n_voltages = ARRAY_SIZE(pm886_ldo_volt_table3),
+ .vsel_reg = PM886_REG_LDO16_VOUT,
+ .vsel_mask = PM886_LDO_VSEL_MASK,
+ },
+ .max_uA = 200000,
+ },
+ {
+ .desc = {
+ .name = "buck1",
+ .regulators_node = "regulators",
+ .of_match = "buck1",
+ .ops = &pm886_buck_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = 85,
+ .linear_ranges = pm886_buck_volt_ranges1,
+ .n_linear_ranges = ARRAY_SIZE(pm886_buck_volt_ranges1),
+ .vsel_reg = PM886_REG_BUCK1_VOUT,
+ .vsel_mask = PM886_BUCK_VSEL_MASK,
+ .enable_reg = PM886_REG_BUCK_EN,
+ .enable_mask = BIT(0),
+ },
+ .max_uA = 3000000,
+ },
+ {
+ .desc = {
+ .name = "buck2",
+ .regulators_node = "regulators",
+ .of_match = "buck2",
+ .ops = &pm886_buck_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = 115,
+ .linear_ranges = pm886_buck_volt_ranges2,
+ .n_linear_ranges = ARRAY_SIZE(pm886_buck_volt_ranges2),
+ .vsel_reg = PM886_REG_BUCK2_VOUT,
+ .vsel_mask = PM886_BUCK_VSEL_MASK,
+ .enable_reg = PM886_REG_BUCK_EN,
+ .enable_mask = BIT(1),
+ },
+ .max_uA = 1200000,
+ },
+ {
+ .desc = {
+ .name = "buck3",
+ .regulators_node = "regulators",
+ .of_match = "buck3",
+ .ops = &pm886_buck_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = 115,
+ .linear_ranges = pm886_buck_volt_ranges2,
+ .n_linear_ranges = ARRAY_SIZE(pm886_buck_volt_ranges2),
+ .vsel_reg = PM886_REG_BUCK3_VOUT,
+ .vsel_mask = PM886_BUCK_VSEL_MASK,
+ .enable_reg = PM886_REG_BUCK_EN,
+ .enable_mask = BIT(2),
+ },
+ .max_uA = 1200000,
+ },
+ {
+ .desc = {
+ .name = "buck4",
+ .regulators_node = "regulators",
+ .of_match = "buck4",
+ .ops = &pm886_buck_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = 115,
+ .linear_ranges = pm886_buck_volt_ranges2,
+ .n_linear_ranges = ARRAY_SIZE(pm886_buck_volt_ranges2),
+ .vsel_reg = PM886_REG_BUCK4_VOUT,
+ .vsel_mask = PM886_BUCK_VSEL_MASK,
+ .enable_reg = PM886_REG_BUCK_EN,
+ .enable_mask = BIT(3),
+ },
+ .max_uA = 1200000,
+ },
+ {
+ .desc = {
+ .name = "buck5",
+ .regulators_node = "regulators",
+ .of_match = "buck5",
+ .ops = &pm886_buck_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = 115,
+ .linear_ranges = pm886_buck_volt_ranges2,
+ .n_linear_ranges = ARRAY_SIZE(pm886_buck_volt_ranges2),
+ .vsel_reg = PM886_REG_BUCK5_VOUT,
+ .vsel_mask = PM886_BUCK_VSEL_MASK,
+ .enable_reg = PM886_REG_BUCK_EN,
+ .enable_mask = BIT(4),
+ },
+ .max_uA = 1200000,
+ },
+};
+
+static int pm886_regulator_probe(struct platform_device *pdev)
+{
+ struct pm886_chip *chip = dev_get_drvdata(pdev->dev.parent);
+ struct regulator_config rcfg = { };
+ struct pm886_regulator *regulator;
+ struct device *dev = &pdev->dev;
+ struct regulator_desc *rdesc;
+ struct regulator_dev *rdev;
+ struct i2c_client *page;
+ struct regmap *regmap;
+
+ page = devm_i2c_new_dummy_device(dev, chip->client->adapter,
+ chip->client->addr + PM886_PAGE_OFFSET_REGULATORS);
+ if (IS_ERR(page))
+ return dev_err_probe(dev, PTR_ERR(page),
+ "Failed to initialize regulators client\n");
+
+ regmap = devm_regmap_init_i2c(page, &pm886_regulator_regmap_config);
+ if (IS_ERR(regmap))
+ return dev_err_probe(dev, PTR_ERR(regmap),
+ "Failed to initialize regulators regmap\n");
+ rcfg.regmap = regmap;
+
+ rcfg.dev = dev->parent;
+
+ for (int i = 0; i < ARRAY_SIZE(pm886_regulators); i++) {
+ regulator = &pm886_regulators[i];
+ rdesc = ®ulator->desc;
+ rcfg.driver_data = regulator;
+ rdev = devm_regulator_register(dev, rdesc, &rcfg);
+ if (IS_ERR(rdev))
+ return dev_err_probe(dev, PTR_ERR(rdev),
+ "Failed to register %s\n", rdesc->name);
+ }
+
+ return 0;
+}
+
+static const struct platform_device_id pm886_regulator_id_table[] = {
+ { "88pm886-regulator", },
+ { }
+};
+MODULE_DEVICE_TABLE(platform, pm886_regulator_id_table);
+
+static struct platform_driver pm886_regulator_driver = {
+ .driver = {
+ .name = "88pm886-regulator",
+ },
+ .probe = pm886_regulator_probe,
+ .id_table = pm886_regulator_id_table,
+};
+module_platform_driver(pm886_regulator_driver);
+
+MODULE_DESCRIPTION("Marvell 88PM886 PMIC regulator driver");
+MODULE_AUTHOR("Karel Balej <balejk@matfyz.cz>");
+MODULE_LICENSE("GPL");
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 7db0a29b5b8d..89845892c533 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -91,6 +91,12 @@ config REGULATOR_88PM8607
help
This driver supports 88PM8607 voltage regulator chips.
+config REGULATOR_88PM886
+ tristate "Marvell 88PM886 voltage regulators"
+ depends on MFD_88PM886_PMIC
+ help
+ This driver implements support for Marvell 88PM886 voltage regulators.
+
config REGULATOR_ACT8865
tristate "Active-semi act8865 voltage regulator"
depends on I2C
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 46fb569e6be8..f30089b74b2e 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_REGULATOR_USERSPACE_CONSUMER) += userspace-consumer.o
obj-$(CONFIG_REGULATOR_88PG86X) += 88pg86x.o
obj-$(CONFIG_REGULATOR_88PM800) += 88pm800-regulator.o
obj-$(CONFIG_REGULATOR_88PM8607) += 88pm8607.o
+obj-$(CONFIG_REGULATOR_88PM886) += 88pm886-regulator.o
obj-$(CONFIG_REGULATOR_CROS_EC) += cros-ec-regulator.o
obj-$(CONFIG_REGULATOR_CPCAP) += cpcap-regulator.o
obj-$(CONFIG_REGULATOR_AAT2870) += aat2870-regulator.o
--
2.44.0
^ permalink raw reply related
* [PATCH 0/5] initial support for Marvell 88PM886 PMIC
From: Karel Balej @ 2024-03-31 10:46 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Liam Girdwood, Mark Brown, devicetree,
linux-kernel, linux-input
Cc: Duje Mihanović, ~postmarketos/upstreaming, phone-devel
Hello,
the following implements basic support for Marvell's 88PM886 PMIC which
is found for instance as a component of the samsung,coreprimevelte
smartphone which inspired this and also serves as a testing platform.
The code for the MFD is based primarily on this old series [1] with the
addition of poweroff based on the smartphone's downstream kernel tree
[2]. The onkey and regulators drivers are based on the latter. I am not
in possesion of the datasheet.
[1] https://lore.kernel.org/all/1434098601-3498-1-git-send-email-yizhang@marvell.com/
[2] https://github.com/CoderCharmander/g361f-kernel
Thank you and kind regards,
K. B.
---
v1:
- RFC v4: https://lore.kernel.org/r/20240311160110.32185-1-karelb@gimli.ms.mff.cuni.cz/
- Rebase to v6.9-rc1.
- Thank you to everybody for their feedback on the RFC!
RFC v4:
- RFC v3: https://lore.kernel.org/all/20240303101506.4187-1-karelb@gimli.ms.mff.cuni.cz/
RFC v3:
- Address Rob's feedback:
- Drop onkey bindings patch.
- Rename PM88X -> PM886 everywhere.
- RFC v2: https://lore.kernel.org/all/20240211094609.2223-1-karelb@gimli.ms.mff.cuni.cz/
RFC v2:
- Merge with the regulators series to have multiple devices and thus
justify the use of the MFD framework.
- Rebase on v6.8-rc3.
- Reorder patches.
- MFD RFC v1: https://lore.kernel.org/all/20231217131838.7569-1-karelb@gimli.ms.mff.cuni.cz/
- regulators RFC v1: https://lore.kernel.org/all/20231228100208.2932-1-karelb@gimli.ms.mff.cuni.cz/
Karel Balej (5):
dt-bindings: mfd: add entry for Marvell 88PM886 PMIC
mfd: add driver for Marvell 88PM886 PMIC
regulator: add regulators driver for Marvell 88PM886 PMIC
input: add onkey driver for Marvell 88PM886 PMIC
MAINTAINERS: add myself for Marvell 88PM886 PMIC
.../bindings/mfd/marvell,88pm886-a1.yaml | 76 +++
MAINTAINERS | 9 +
drivers/input/misc/88pm886-onkey.c | 98 ++++
drivers/input/misc/Kconfig | 7 +
drivers/input/misc/Makefile | 1 +
drivers/mfd/88pm886.c | 157 ++++++
drivers/mfd/Kconfig | 12 +
drivers/mfd/Makefile | 1 +
drivers/regulator/88pm886-regulator.c | 509 ++++++++++++++++++
drivers/regulator/Kconfig | 6 +
drivers/regulator/Makefile | 1 +
include/linux/mfd/88pm886.h | 30 ++
12 files changed, 907 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml
create mode 100644 drivers/input/misc/88pm886-onkey.c
create mode 100644 drivers/mfd/88pm886.c
create mode 100644 drivers/regulator/88pm886-regulator.c
create mode 100644 include/linux/mfd/88pm886.h
--
2.44.0
^ permalink raw reply
* [PATCH 4/5] input: add onkey driver for Marvell 88PM886 PMIC
From: Karel Balej @ 2024-03-31 10:46 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Liam Girdwood, Mark Brown, devicetree,
linux-kernel, linux-input
Cc: Duje Mihanović, ~postmarketos/upstreaming, phone-devel
In-Reply-To: <20240331105608.7338-2-balejk@matfyz.cz>
Marvell 88PM886 PMIC provides onkey among other things. Add client
driver to handle it. The driver currently only provides a basic support
omitting additional functions found in the vendor version, such as long
onkey and GPIO integration.
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Karel Balej <balejk@matfyz.cz>
---
Notes:
v1:
- Remove kernel.h include.
RFC v4:
- Reflect MFD driver changes:
- chip->regmaps[...] -> chip->regmap
- Address Dmitry's feedback:
- Add ID table.
- Add Ack.
RFC v3:
- Drop wakeup-source.
RFC v2:
- Address Dmitry's feedback:
- Sort includes alphabetically.
- Drop onkey->irq.
- ret -> err in irq_handler and no initialization.
- Break long lines and other formatting.
- Do not clobber platform_get_irq error.
- Do not set device parent manually.
- Use input_set_capability.
- Use the wakeup-source DT property.
- Drop of_match_table.
- Use more temporaries.
- Use dev_err_probe.
- Modify Kconfig description.
drivers/input/misc/88pm886-onkey.c | 98 ++++++++++++++++++++++++++++++
drivers/input/misc/Kconfig | 7 +++
drivers/input/misc/Makefile | 1 +
3 files changed, 106 insertions(+)
create mode 100644 drivers/input/misc/88pm886-onkey.c
diff --git a/drivers/input/misc/88pm886-onkey.c b/drivers/input/misc/88pm886-onkey.c
new file mode 100644
index 000000000000..284ff5190b6e
--- /dev/null
+++ b/drivers/input/misc/88pm886-onkey.c
@@ -0,0 +1,98 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include <linux/input.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#include <linux/mfd/88pm886.h>
+
+struct pm886_onkey {
+ struct input_dev *idev;
+ struct pm886_chip *chip;
+};
+
+static irqreturn_t pm886_onkey_irq_handler(int irq, void *data)
+{
+ struct pm886_onkey *onkey = data;
+ struct regmap *regmap = onkey->chip->regmap;
+ struct input_dev *idev = onkey->idev;
+ struct device *parent = idev->dev.parent;
+ unsigned int val;
+ int err;
+
+ err = regmap_read(regmap, PM886_REG_STATUS1, &val);
+ if (err) {
+ dev_err(parent, "Failed to read status: %d\n", err);
+ return IRQ_NONE;
+ }
+ val &= PM886_ONKEY_STS1;
+
+ input_report_key(idev, KEY_POWER, val);
+ input_sync(idev);
+
+ return IRQ_HANDLED;
+}
+
+static int pm886_onkey_probe(struct platform_device *pdev)
+{
+ struct pm886_chip *chip = dev_get_drvdata(pdev->dev.parent);
+ struct device *dev = &pdev->dev;
+ struct pm886_onkey *onkey;
+ struct input_dev *idev;
+ int irq, err;
+
+ onkey = devm_kzalloc(dev, sizeof(*onkey), GFP_KERNEL);
+ if (!onkey)
+ return -ENOMEM;
+
+ onkey->chip = chip;
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ return dev_err_probe(dev, irq, "Failed to get IRQ\n");
+
+ idev = devm_input_allocate_device(dev);
+ if (!idev) {
+ dev_err(dev, "Failed to allocate input device\n");
+ return -ENOMEM;
+ }
+ onkey->idev = idev;
+
+ idev->name = "88pm886-onkey";
+ idev->phys = "88pm886-onkey/input0";
+ idev->id.bustype = BUS_I2C;
+
+ input_set_capability(idev, EV_KEY, KEY_POWER);
+
+ err = devm_request_threaded_irq(dev, irq, NULL, pm886_onkey_irq_handler,
+ IRQF_ONESHOT | IRQF_NO_SUSPEND, "onkey",
+ onkey);
+ if (err)
+ return dev_err_probe(dev, err, "Failed to request IRQ\n");
+
+ err = input_register_device(idev);
+ if (err)
+ return dev_err_probe(dev, err, "Failed to register input device\n");
+
+ return 0;
+}
+
+static const struct platform_device_id pm886_onkey_id_table[] = {
+ { "88pm886-onkey", },
+ { }
+};
+MODULE_DEVICE_TABLE(platform, pm886_onkey_id_table);
+
+static struct platform_driver pm886_onkey_driver = {
+ .driver = {
+ .name = "88pm886-onkey",
+ },
+ .probe = pm886_onkey_probe,
+ .id_table = pm886_onkey_id_table,
+};
+module_platform_driver(pm886_onkey_driver);
+
+MODULE_DESCRIPTION("Marvell 88PM886 onkey driver");
+MODULE_AUTHOR("Karel Balej <balejk@matfyz.cz>");
+MODULE_LICENSE("GPL");
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 6ba984d7f0b1..16a079d9f0f2 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -33,6 +33,13 @@ config INPUT_88PM80X_ONKEY
To compile this driver as a module, choose M here: the module
will be called 88pm80x_onkey.
+config INPUT_88PM886_ONKEY
+ tristate "Marvell 88PM886 onkey support"
+ depends on MFD_88PM886_PMIC
+ help
+ Support the onkey of Marvell 88PM886 PMIC as an input device
+ reporting power button status.
+
config INPUT_AB8500_PONKEY
tristate "AB8500 Pon (PowerOn) Key"
depends on AB8500_CORE
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 04296a4abe8e..054a6dc1ac27 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -7,6 +7,7 @@
obj-$(CONFIG_INPUT_88PM860X_ONKEY) += 88pm860x_onkey.o
obj-$(CONFIG_INPUT_88PM80X_ONKEY) += 88pm80x_onkey.o
+obj-$(CONFIG_INPUT_88PM886_ONKEY) += 88pm886-onkey.o
obj-$(CONFIG_INPUT_AB8500_PONKEY) += ab8500-ponkey.o
obj-$(CONFIG_INPUT_AD714X) += ad714x.o
obj-$(CONFIG_INPUT_AD714X_I2C) += ad714x-i2c.o
--
2.44.0
^ permalink raw reply related
* [PATCH 1/5] dt-bindings: mfd: add entry for Marvell 88PM886 PMIC
From: Karel Balej @ 2024-03-31 10:46 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Torokhov, Liam Girdwood, Mark Brown, devicetree,
linux-kernel, linux-input
Cc: Duje Mihanović, ~postmarketos/upstreaming, phone-devel
In-Reply-To: <20240331105608.7338-2-balejk@matfyz.cz>
Marvell 88PM886 is a PMIC with several subdevices such as onkey,
regulators or battery and charger. It comes in at least two revisions,
A0 and A1 -- only A1 is described here at the moment.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Karel Balej <balejk@matfyz.cz>
---
Notes:
RFC v4:
- Address Krzysztof's comments:
- Fix regulators indentation.
- Add Krzysztof's trailer.
RFC v3:
- Add wakeup-source property.
- Address Rob's feedback:
- Move regulators into the MFD file.
- Remove interrupt-controller and #interrupt-cells properties.
RFC v2:
- Address Rob's feedback:
- Drop mention of 88PM880.
- Make sure the file passes bindings check (add the necessary header
and fix `interrupt-cells`).
- Other small changes.
- Add regulators. Changes with respect to the regulator RFC series:
- Address Krzysztof's comments:
- Drop unused compatible.
- Fix sub-node pattern.
.../bindings/mfd/marvell,88pm886-a1.yaml | 76 +++++++++++++++++++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml
diff --git a/Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml b/Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml
new file mode 100644
index 000000000000..d6a71c912b76
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/marvell,88pm886-a1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell 88PM886 PMIC core
+
+maintainers:
+ - Karel Balej <balejk@matfyz.cz>
+
+description:
+ Marvell 88PM886 is a PMIC providing several functions such as onkey,
+ regulators or battery and charger.
+
+properties:
+ compatible:
+ const: marvell,88pm886-a1
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ wakeup-source: true
+
+ regulators:
+ type: object
+ additionalProperties: false
+ patternProperties:
+ "^(ldo(1[0-6]|[1-9])|buck[1-5])$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ description: LDO or buck regulator.
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pmic@30 {
+ compatible = "marvell,88pm886-a1";
+ reg = <0x30>;
+ interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&gic>;
+ wakeup-source;
+
+ regulators {
+ ldo2: ldo2 {
+ regulator-min-microvolt = <3100000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ldo15: ldo15 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ buck2: buck2 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ };
+ };
+ };
+...
--
2.44.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox