Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp6836248imm; Wed, 27 Jun 2018 14:25:12 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcFycMLA0zUl4/ykcMX+zF4X3Jl1cerICMxvyfC3dZxeXuO0TliBCicOssktYMyf8RuHFnP X-Received: by 2002:a62:fe19:: with SMTP id z25-v6mr7292585pfh.167.1530134712151; Wed, 27 Jun 2018 14:25:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530134712; cv=none; d=google.com; s=arc-20160816; b=XHQbY7zSOYchg/nMi3DWIOvcO175hNXOzamHmK6j6vNiOX4o//Dyy0Y5swoH6mOmvJ orR+Pj11dGfzxOWrHyySfthh+JEE26fWKjx9CdCm/HUGFPJlbtmsMhuZl/8v5dvnUfbP yNzYlMbNwzYjaK0yjKDd6aRKQ1s/3hdItF6kTQ141kjWmiTxnt1OA7dEarDuCzjzbAmh g103q2mipwCyzwTwPPn4mG4ZmvqIQcl3GYXGFOv6l8tSCJLUsXzplFmOJjNkmHE0eksC MHXh/mQpa0hCoIaz8OqpZNtQdC2/GrXAYOoUFVj5AqbvvJzEThBCMAKs0lOpngJCGZEJ BjYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=tG6EN1+SbuNj1/BEU/nNUXcPCQNSDPd6LpdNz9Tjl1A=; b=zCle/kWT3cswMgV78SbufweLEnhR3ooQWy1CkyNTOzeeAT/88aFJJM92YPTFPgBd87 LdpxHGHtf4z4uEbjbIWzPhe4NiiTPRflFCouS+xvrh4G4VI1zK4ewqLsA7i+Fug6tB5h QeaYqb3djA5cbCnqUCxpg2piJZyysLJ0tHdZybUMy9T1kK9CggVRnICzfrvLYZztPwhn KyrEKZj5dcKIgsCW4NgMPZ6nUgbEGVsLWK7Ac1v8H0q6zPKTIY4C+8K/U1wm6qC8FE+g eDSZps0i8R/y8DyjVrwRka3+rQwV+eOhCrtbzNwizojduhB4U/P5ryfr9flqsV/umalY mvlA== 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 i62-v6si4235385pge.93.2018.06.27.14.24.28; Wed, 27 Jun 2018 14:25:12 -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 S966382AbeF0TMs (ORCPT + 99 others); Wed, 27 Jun 2018 15:12:48 -0400 Received: from mail.bugwerft.de ([46.23.86.59]:51044 "EHLO mail.bugwerft.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966127AbeF0TMq (ORCPT ); Wed, 27 Jun 2018 15:12:46 -0400 Received: from [192.168.178.170] (pD95EF523.dip0.t-ipconnect.de [217.94.245.35]) by mail.bugwerft.de (Postfix) with ESMTPSA id 7B5AA28BD95; Wed, 27 Jun 2018 19:09:32 +0000 (UTC) Subject: Re: [PATCH RFC 0/4] Adding DT functionality to w1 busses To: Rob Herring Cc: zbr@ioremap.net, Mark Rutland , szabolcs.gyurko@tlt.hu, devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" References: <20180619212744.794-1-daniel@zonque.org> From: Daniel Mack Message-ID: <31d55df2-b5ba-f37e-7566-c73f58ba9b43@zonque.org> Date: Wed, 27 Jun 2018 21:12:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, June 26, 2018 11:39 PM, Rob Herring wrote: > On Tue, Jun 19, 2018 at 3:27 PM, Daniel Mack wrote: >> 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. > > Looks to me like you are letting the driver structure define the DT > structure. This detail is all irrelevant to DT. > >> >> 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>; >> }; > > This should just be one node and a child of the 1-wire master. Yeah, you're right. This also makes the patch set much simpler. Thanks for the feedback - I'll send another round of patches. Daniel