From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A4A9C433E0 for ; Thu, 11 Mar 2021 14:16:20 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7F91464FA9 for ; Thu, 11 Mar 2021 14:16:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7F91464FA9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=siemens.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=9IqEeDNuphX7W22yI4d502zbCCdW5t/hXkNFx6D4wJE=; b=ecU0BqDMPQIZG+vH+5+SLvQWz Vfchgmryx+unr/Oec2ZCaM7qfz8avwr2sh926RrP/0pzwK69guLZhDJlZ16bKVEOjlbfa8FXWngxb XAtrHraiHjftgLAyk0jhwqOc8bbf0KIks+0DCiGJQPeFuoBUaDEWWtWkDNMF7C4d9s2BnThRpjQh3 cD8FJZkecIroECNvHuiIh1ErlRUg+TJ49IMO3e72m1mIMnyGHWhcH4Rj23QeRSwpRUBlVdG9rcrrJ VSOkHElnMaxuIw1NWcKgkM1Hu2Lpaby+CfrNOVt3J8mF0pWqWdzxOgKP4oWfH+vddNEii6qO7E1+c 1qrP/XN5g==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lKM5R-009Ido-4g; Thu, 11 Mar 2021 14:14:49 +0000 Received: from gecko.sbs.de ([194.138.37.40]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lKM5N-009IdR-Dl for linux-arm-kernel@lists.infradead.org; Thu, 11 Mar 2021 14:14:47 +0000 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 12BEEf0x007069 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Mar 2021 15:14:41 +0100 Received: from [167.87.35.81] ([167.87.35.81]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 12BEEeDD022550; Thu, 11 Mar 2021 15:14:40 +0100 Subject: Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards To: Nishanth Menon Cc: Tero Kristo , Rob Herring , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Le Jin , Bao Cheng Su , Vignesh Raghavendra References: <9bff40f434e5298890e5d139cc36cc46a0ca2d76.1615369068.git.jan.kiszka@siemens.com> <20210311131754.i5ewls6hgeitcgre@astonish> <8d076ff1-cdac-941f-e796-a2e6dba792ab@siemens.com> <20210311140056.fzvke3rrg6c2uuoa@uncouth> From: Jan Kiszka Message-ID: <519ae6b7-35db-1fdd-de1e-e0155e0ca82a@siemens.com> Date: Thu, 11 Mar 2021 15:14:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <20210311140056.fzvke3rrg6c2uuoa@uncouth> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210311_141445_615963_98860ED8 X-CRM114-Status: GOOD ( 41.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 11.03.21 15:00, Nishanth Menon wrote: > On 14:44-20210311, Jan Kiszka wrote: >> On 11.03.21 14:17, Nishanth Menon wrote: >>> On 10:37-20210310, Jan Kiszka wrote: >>>> From: Jan Kiszka >>>> + spidev@0 { >>>> + compatible = "rohm,dh2228fv"; >>>> + spi-max-frequency = <20000000>; >>>> + reg = <0>; >>> >>> Jan, >>> >>> As part of my final sanity checks, I noticed that we missed this: is a checkpatch warning >>> >>> WARNING: DT compatible string "rohm,dh2228fv" appears un-documented -- check ./Documentation/devicetree/bindings/ >>> #629: FILE: arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi:581: >>> compatible = "rohm,dh2228fv"; >>> >>> I cannot pick up nodes that are'nt documented as yaml in >>> Documentation/devicetree >>> >>> I know this is irritating to find such nodes that already have previous >>> users and the person coming last gets to deal with "new rules".. but >>> sorry for catching this so late. >>> >>> Here are the options that come to mind: >>> >>> option 1) - drop the node and resubmit. >>> >>> option 2) - get the documentation into linux master tree and then submit >>> the patches. >>> >> >> As you said, I'm not setting a precedence here: >> >> arch/arm/boot/dts/imx28-cfa10049.dts: compatible = "rohm,dh2228fv"; >> arch/arm/boot/dts/rv1108-elgin-r1.dts: compatible = "rohm,dh2228fv"; >> arch/arm/boot/dts/socfpga_cyclone5_socdk.dts: compatible = "rohm,dh2228fv"; >> drivers/spi/spidev.c: { .compatible = "rohm,dh2228fv" }, >> >> Was just just never documented as binding? Or why is no one allowed to >> use this anymore? What is to be used instead for spidev? > > See [1] compare the compatibles against > Documentation/devicetree/bindings -> I think you should describe what > your hardware really is though. This SPI bus is routed to an Arduino connector. By default, userspace (e.g. mraa) takes ownership and adds the desired logic for what is being connected. We have no idea what shield or other extension the user adds, though. > > Unfortunately devicetree migration has been far from being smooth.. it > was like chewing an elephant - linux community had to attack it in > pieces.. > > Yes - it was unfortunately one of those cases where the driver support > was introduced long back and no binding was introduced at that time (it > was'nt mandatory then).. then we added a mandatory requirement that it > be documented in txt.. over years realized things are'nt great with > unstructured txt description of binding, now moving on converting > existing txt files to yaml and schemas to static check the dts... > evolution over the years, I guess. > > I am on a fight internally as well to have all our legacy txt files > converted over to yaml.. and am having to put up a stance - see [2] > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spidev.c#n678 > [2] https://lore.kernel.org/linux-arm-kernel/20210311134908.jsh2lywtwzvlyvbc@finally/T/#u > The problem here is not simple txt->yml conversion: There is no official binding for spidev yet, just existing users and the driver waiting for them. >> >>> >>> I think we should just drop the node and resubmit - since this is a more >>> intrusive change and I don't have your platform handy, I am going to >>> suggest you make a call :( >> >> This breaks userspace here, and we would need to carry that node on top. >> > > Uggh... that sucks.. but I think that would be lower tradeoff to make > than me (as it stands now) having to drop the patch series. > >> BTW, I already brought up the topic internally to get you some boards >> for testing. > > Thanks.. While it might help me personally to get some on my internal > farm, it might be good to get them on kernelci as well on the longer > run. > Will keep that on the radar. I definitely want to get it into the CIP LAVA lab which is testing LTS as well. >> >> I've done that and addressed all that I could (former patch 4). We >> import those from k3, and I don't feel confident how to resolve them. >> See also v1 of this patch. > > Yeah - i noticed that upstream dt-schema has gotten even more stricter > even though the dts has remained the same.. I need to spend time in > digging at it. > > At this point the only big kicker is the checkpatch stuff which I cant > let through - if i do that arnd will probably kick everything from my > PR out :( - which I cant do. > Are we talking about spidev here? Then let's drop that node, but I do need to know how to describe spidev properly Or is it about those other warnings coming from your dtsi files, now being surfaced? If you can tell me how to resolve them, I can write patches. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel