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=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,SPF_PASS,T_DKIMWL_WL_HIGH,URIBL_BLOCKED autolearn=ham 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 0849DC004C9 for ; Wed, 8 May 2019 01:37:31 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 CB560204EC for ; Wed, 8 May 2019 01:37:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="F8400WcD"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="YoIj9jBz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CB560204EC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=W9ClutGSI3yuIg1gGFhxGh7fuEckdVeIffVsxEMtZFc=; b=F8400WcDVF4wtR XLFvsFGHgK/vQ14cNzg7XhHbgI0aQRfltSS4I7vCjYcH+/NgQnyYjPK5XVbGykEnEopMHyfgH3y3+ h4W3aP8qMOXBbPm0FZXngFYQOX2NpmppO1B+S96S8l/QobhMJFsZtYwcFqD4PbZnfetdyEcDXkTIY /G76wAV4PFmdCqmKHUB9hpkPkPGXhhyeXwbq6nYJGjw+dwh1G6x3oELu9wNX7OVS6ApOW5MOMOSYs yluL6waDhT7tORTIR6ZcUtdRY53FH6XiTnYnePgeazcIZ7KMiINAOn8s2CzYciSCnffkMrlIz3Nza Dpcwa16187p5A/7dYeLg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hOBWQ-0000Ls-Nz; Wed, 08 May 2019 01:37:26 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hOBWL-0000FY-Tf for linux-arm-kernel@lists.infradead.org; Wed, 08 May 2019 01:37:24 +0000 Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 758A2204EC for ; Wed, 8 May 2019 01:37:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557279441; bh=OIKNrpQ//1+gNyFNJNx5GTrLEgWv7I8DuK91PHiBHGU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=YoIj9jBz0ncG68/oormp3IZkK+oscTLcGb8PSX4KzJuQ7lM2ZwkFTsUrfsUc6uwn+ P1o3R/VHf4Bnai4Bd9WniWYjnFgSSr/bBxalHv9qCm3WjRFIkMY/SFRPnRd4druLg3 7veiohg9gGuwgwZ0TJS6u5KodZgBdccsb1Yofsv8= Received: by mail-qk1-f175.google.com with SMTP id w20so799754qka.7 for ; Tue, 07 May 2019 18:37:21 -0700 (PDT) X-Gm-Message-State: APjAAAVsDG9nvl6PSzU0IPJW+B6rViw+2pf24cAeOdST62AyxFG9hgP5 pqg+FTJXQVZrBNSMauIoMzoe9Hnl2Q6q2aXrvg== X-Google-Smtp-Source: APXvYqyeiy1xlQlbcMBCEKm6e0Cu0M1tx5QYpc220iWQ2Ezm2T8NmPq4Igp3eHP72JG5/Njg7ZMROOL/ApIYZNB2fdY= X-Received: by 2002:a37:351:: with SMTP id 78mr1234316qkd.147.1557279440735; Tue, 07 May 2019 18:37:20 -0700 (PDT) MIME-Version: 1.0 References: <20190507151353.ns2i72ii5cw6z7lz@flea> In-Reply-To: <20190507151353.ns2i72ii5cw6z7lz@flea> From: Rob Herring Date: Tue, 7 May 2019 20:37:09 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/4] dt-bindings: spi: Add YAML schemas for the generic SPI options To: Maxime Ripard X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190507_183722_216394_368DD01E X-CRM114-Status: GOOD ( 29.13 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , devicetree@vger.kernel.org, linux-spi , Chen-Yu Tsai , Mark Brown , Frank Rowand , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, May 7, 2019 at 1:07 PM Maxime Ripard wrote: > > Hi, > > On Tue, May 07, 2019 at 09:35:28AM -0500, Rob Herring wrote: > > On Tue, May 7, 2019 at 8:48 AM Maxime Ripard wrote: > > > > > > The SPI controllers have a bunch of generic options that are needed in a > > > device tree. Add a YAML schemas for those. > > > > I'd started on this one, but was planning to move it to the schema > > repository. The issue there is re-licensing (adding BSD 2 clause). > > Maybe better to just move it later. > > I just found out that dt-doc-validate also chokes on the reference > URI. Maybe I should just submit it to the repo then once that is > settled? I'm not really too excited about chasing down licensing on every file we want to move and I'd like to avoid per file licenses, so I'd like local $refs to work. I think I've got something figured out that will work. It will need a small kernel side change though. > > > +properties: > > > + $nodename: > > > + pattern: "^spi(@[a-zA-Z0-9]+)?$" > > > > I think we want just "(@.*)". At a minimum, you need to allow for ','. > > It would be the a bus schema for the parent which should validate unit > > addresses, so we should pretty much just allow anything here. > > The issue with this is that it will also match any node starting with > spi. In the Allwinner case, that also means the pinctrl nodes with spi > pins in them, but I'm sure we can find more corner cases. Maybe I wasn't clear, but I meant changing just the unit-address part. So: "^spi(@.*)$" > > > > + > > > + "#address-cells": > > > + const: 1 > > > + > > > + "#size-cells": > > > + const: 0 > > > + > > > + cs-gpios: > > > + description: | > > > + GPIOs used as chip selects. > > > + If that property is used, the number of chip selects will be > > > + increased automatically with max(cs-gpios, hardware chip selects). > > > + > > > + So if, for example, the controller has 2 CS lines, and the > > > + cs-gpios looks like this > > > + cs-gpios = <&gpio1 0 0>, <0>, <&gpio1 1 0>, <&gpio1 2 0>; > > > + > > > + Then it should be configured so that num_chipselect = 4, with > > > + the following mapping > > > + cs0 : &gpio1 0 0 > > > + cs1 : native > > > + cs2 : &gpio1 1 0 > > > + cs3 : &gpio1 2 0 > > > + > > > + num-cs: > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + description: > > > + Total number of chip selects. > > > + > > > + spi-slave: > > > + $ref: /schemas/types.yaml#/definitions/flag > > > > "type: boolean" is sufficient here. Maybe we should just remove > > 'flag'. OTOH, maybe consistency with other types and the abstraction > > is better as we could add to the flag schema. > > I was trying to be consistent. Do you want me to remove it? No, it's fine. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel