Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp69784imm; Tue, 19 Jun 2018 14:28:52 -0700 (PDT) X-Google-Smtp-Source: ADUXVKL1yK3ZWe/UCKtx3dPMm6l49XtHyL397t7iXk6e4gGiKJu+zHFLiqH8HqdD0sKVtcVhKwKh X-Received: by 2002:aa7:8254:: with SMTP id e20-v6mr19955813pfn.140.1529443732612; Tue, 19 Jun 2018 14:28:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529443732; cv=none; d=google.com; s=arc-20160816; b=AegNThbHRe8/i5dI67pfiNgcQqfmkP/Hoch023bq/c3dEOf/1V5M1b0FueYdhwsxSX wklNVzh9w/lrW5IHYSLxJ1h6jScSC3qF5FzHPTd3SWF9yMd+WvksEIj5MvunkUFWFn4P vQQLAvBe7i1hODG0MZ9WYi5u54SjuGqWR8VRUrGT2hmcvKZ5bXoEQmIWROiW+7FiY+dJ i2VVGVcJZhgNMAqCmlglpGqi1aTD1FoHzeE43rWIdv4/g/amQ1vb9oUYXkxV/x9aK+bm k63Ms7CyKdHWIY041Rzng5WCkPbFUPljR4cj2r7ncFfHlh0yBVOOZGxsQdflzE8ebr5o bMDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=d7pYz4jGz1zA/Ep/4OCKAqggd+GcJ+8P/6QBSTYbnHc=; b=Gyys1SHWw0b4LhV5pF/gcQL4TdvhWdy5Nyesy4bkxhxXJobbjJv7AJqJ2WlthN+bg1 7LcZNz0+U1Ct9xZ3/fX/F8Z+1OkqB3bvaBi1XCrMr5ZgZH3Fz5MB9KcUpER80zXi2iLU ZuIlEscY8oPxdwy/tmnBarQtn80+sbKwHCetPAkfnmkiMW5eZs9Dy1Q7e8y5bvG5LORe hKevVRFMLRPuZT88oTUzjpiW8vR7WJeceYk1FBSJDn05hjoV5RucLpd2z8xlwq+f73zp hEzymMy0Bm8VsNMf716POyvt3L5+3auv5KVgQeFJ92GrrNWqWRBvKWrxqhYUm8Kmt1Qj exYA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g63-v6si656160pfk.74.2018.06.19.14.28.31; Tue, 19 Jun 2018 14:28:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757365AbeFSV14 (ORCPT + 99 others); Tue, 19 Jun 2018 17:27:56 -0400 Received: from mail.bugwerft.de ([46.23.86.59]:50624 "EHLO mail.bugwerft.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755540AbeFSV1x (ORCPT ); Tue, 19 Jun 2018 17:27:53 -0400 Received: from localhost.localdomain (pD95EF733.dip0.t-ipconnect.de [217.94.247.51]) by mail.bugwerft.de (Postfix) with ESMTPSA id 8C7A4289CB9; Tue, 19 Jun 2018 21:24:47 +0000 (UTC) From: Daniel Mack To: zbr@ioremap.net, robh+dt@kernel.org, mark.rutland@arm.com, szabolcs.gyurko@tlt.hu Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Daniel Mack Subject: [PATCH RFC 0/4] Adding DT functionality to w1 busses Date: Tue, 19 Jun 2018 23:27:40 +0200 Message-Id: <20180619212744.794-1-daniel@zonque.org> X-Mailer: git-send-email 2.17.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In order to fully move battery-supplied devices over to devicetree, the onewire subsystem must get some updates. Currently, the w1 bus system works like this. Device families, such as battery controllers etc, are registered to the w1 core. Once a master device is probed, it starts scanning the bus. Slave devices that are revealed through this scan and that match previously registered families are then registered, and their .add_slave() callback is invoked. Some devices, such as the ds2760, use that callback to call platform_device_alloc() at runtime with a fixed device name to instanciate their only user. That user does the actual work, while the slave device merely functions as an I/O proxy. In the user implementation, the w1 slave device is accessible through dev->parent. Now, for devicetree environments, this has to change a bit. First, slave devices need to have a matching table so they can be listed as sub-nodes of their master bus controller. Second, the core needs to match the entries in these tables against the sub-nodes of the master node. These two are trivial to do. The next question is how the w1 slave device and its user(s) are linked together. I'm proposing a DT layout with the following example: onewire { compatible = "w1-gpio"; w1_slave: slave@0 { compatible = "maxim,w1-ds2760"; }; }; battery-supply { compatible = "maxim,ds2760-supply"; w1-slave = <&w1_slave>; }; Another option would be to place the supply user as another nested node under the slave device, but I'm not sure if that's beneficial. I'm open to discussions though. This patch set implements the changes for the above in the w1 core. Changing the supply users is left for later when the basics have settlerd, but a helper to reference slave devices through phandles is already provided. Thanks, Daniel Daniel Mack (4): dt-bindings: w1: document sub-node bindings for DS2760 w1: core: match sub-nodes of bus masters in devicetree w1: core: provide helper to look up w1 slaves through devicetree nodes w1: ds2760: add devicetree matching glue .../devicetree/bindings/w1/w1-ds2760.txt | 9 +++++ .../devicetree/bindings/w1/w1-gpio.txt | 6 +++ Documentation/devicetree/bindings/w1/w1.txt | 17 ++++++++ drivers/w1/slaves/w1_ds2760.c | 15 ++++++- drivers/w1/w1.c | 40 +++++++++++++++++++ include/linux/w1.h | 13 ++++++ 6 files changed, 99 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/w1/w1-ds2760.txt create mode 100644 Documentation/devicetree/bindings/w1/w1.txt -- 2.17.1