Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3548365imu; Mon, 10 Dec 2018 04:09:32 -0800 (PST) X-Google-Smtp-Source: AFSGD/WJeZYKfXA14VGYYCpVYpT6buUjJLKYMCU5bdI70XORTXZoFiLhlfuseRwtX4CSBlNa+Jmb X-Received: by 2002:a17:902:8346:: with SMTP id z6mr11824834pln.340.1544443772666; Mon, 10 Dec 2018 04:09:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544443772; cv=none; d=google.com; s=arc-20160816; b=0yikPA9V2pdMWIXcBC6M9cwDWccaYZ6MUkSPRS7pRuChqO8dfvGG8aBfxf1kDaJkkZ fYDmLwgvX1zd8JGVDOkEJEwY2GOikBjUC7oTU+bdD8+oH3RGW0jQ2M66Bg+jrs9yIF0W OjNQnrCR3cyuStAcIDA/c4FqDU3wTQkHzPLiHZ6WEdcBYohQ0QRtCD6Ds8lRP4+rYag1 34b+TZqqlNTRYHePnEHKVLsvncMLbIQm2yZk2aMMjJV8Be3LivttP7jCeW2VWg2Fyaxd YIkcMWrS4vs1+uOdw3P+7PY2wn2kgPNjSoqgorBE4wrcu20bRjEGjgQw1FQ+Lvs1/zyM tFLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=SoIHMtUTNlfSVDIq9B3xkSQBtFVNdE1rVVqkyNUwkbY=; b=OGtPrp5g7u/cGGY8zPA0HH+QRuLoEGhjlCSKPG5eiDyGIvlExXlSjv0MfzF5W6d2nC ihBRgv2079DVVpj6dKunXgnyZwzazVYakdjJ09Agjd8/n6bBsGnatVdqpM++AWEBhf88 a0Qh/PNGSFmaZs46ROhpIN5KpYvjB7b+/rwA260s/ZbqFDnJYtzWMyE5rSzSmgmfzVwX DXC0VRRF8HXSOjjVC6gkEMqPd+D0EMTClEv3Ke9o5UCpYV5kDKP/MmWu3ogydWH/caDJ ZEauLVaOexaV/U2Vzk/MhXIIMDKNHMNCBhqvnNEm+6gbnol4WhkH/OJUtMH5tGs2KVi+ CWeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=Kj+il6zE; 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; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u22si8780436pgh.286.2018.12.10.04.09.14; Mon, 10 Dec 2018 04:09:32 -0800 (PST) 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; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=Kj+il6zE; 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; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727529AbeLJMHT (ORCPT + 99 others); Mon, 10 Dec 2018 07:07:19 -0500 Received: from fllv0015.ext.ti.com ([198.47.19.141]:39548 "EHLO fllv0015.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727172AbeLJMHS (ORCPT ); Mon, 10 Dec 2018 07:07:18 -0500 Received: from fllv0034.itg.ti.com ([10.64.40.246]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id wBAC6klv060754; Mon, 10 Dec 2018 06:06:47 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1544443607; bh=SoIHMtUTNlfSVDIq9B3xkSQBtFVNdE1rVVqkyNUwkbY=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Kj+il6zEk3LprbloS0GylZFl7IlYxPosj43YMYau3UDWeaJCa4d7/5sbzgBDXJ1SC A/tPzsk0cU6ab3ciGAA8U3vlHKfwFFoawA68DKvR3u9BS7xhKG0ZhZO6S8RmNHxYxa bUALwwsiz+51xzUt6+yuMqf4zwEDapQrMXBEy6ik= Received: from DFLE103.ent.ti.com (dfle103.ent.ti.com [10.64.6.24]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id wBAC6kgf081800 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 10 Dec 2018 06:06:46 -0600 Received: from DFLE100.ent.ti.com (10.64.6.21) by DFLE103.ent.ti.com (10.64.6.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Mon, 10 Dec 2018 06:06:46 -0600 Received: from dlep32.itg.ti.com (157.170.170.100) by DFLE100.ent.ti.com (10.64.6.21) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1591.10 via Frontend Transport; Mon, 10 Dec 2018 06:06:46 -0600 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep32.itg.ti.com (8.14.3/8.13.8) with ESMTP id wBAC6kT9008560; Mon, 10 Dec 2018 06:06:46 -0600 Date: Mon, 10 Dec 2018 06:06:48 -0600 From: Nishanth Menon To: Sekhar Nori CC: Faiz Abbas , , , , , , , , , , , Tony Lindgren , Arnd Bergmann Subject: Re: [PATCH 2/2] arm64: dts: ti: k3-am654-base-board: Add MMC/SD support Message-ID: <20181210120647.i3ply3p7umvedb3u@akan> References: <20181207084233.13700-1-faiz_abbas@ti.com> <20181207084233.13700-3-faiz_abbas@ti.com> <20181208155427.jmidz4vsw4k4qj36@akan> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13:33-20181210, Sekhar Nori wrote: > On 08/12/18 9:24 PM, Nishanth Menon wrote: > > On 14:12-20181207, Faiz Abbas wrote: > > > >> + > >> +&sdhci0 { > >> + status = "okay"; > >> + pinctrl-names = "default"; > >> + pinctrl-0 = <&main_mmc0_pins_default>; > >> + bus-width = <8>; > >> + non-removable; > >> + ti,driver-strength-ohm = <50>; > > > > ^^ > > > >> +}; > >> + > >> +&sdhci1 { > >> + status = "okay"; > >> + pinctrl-names = "default"; > >> + pinctrl-0 = <&main_mmc1_pins_default>; > >> + ti,driver-strength-ohm = <50>; > > > > NAK. > > > > $ git checkout next-20181207 > > $ git grep ti,driver-strength-ohm Documentation > > $ > > > > Nada.. And.. I think "new phy binding" probably introduces this. > > [1] https://patchwork.kernel.org/project/linux-mmc/list/?series=53185 > > > > If your patches are'nt really ready, please send them as RFC, I am not > > really in a mood to track the status of every single driver subsystem. > > > > If your binding is not in linux next at the baremin, as far as I am > > concerned, this is not ready, and should be RFC. > > No, RFC does not say "do not merge" or "this has dependencies". RFC is > used to invite a stronger review when introducing a new concept. Its > fair game to apply patches marked RFC if maintainer is okay with the > content. True, fair enough.. RFC is request for comments. Anyways, that is besides the point. > > Dependencies are either noted in cover-letter or below the patch > tear-line. With what you are asking, looks like patches need to be > resubmitted once dependencies are cleared, even if there is no change in > the content itself. This will be additional work. Yes please. There would be other dts changes that are probably ready and I really wont be tracking everything happening on other drivers. If the binding is present at least in next, it is a good indication of things clean and ready to go. > > That said, if it makes life convenient for you, you can impose such a > rule for patches you need to handle. But I think it will take some > getting used for developers who send patches to you as I don't think > this is a norm elsewhere. > > Adding Tony and Arnd as well, in case I have missed some recently > accepted convention. I have'nt looked at any conventions, The style I prefer to follow when I do submissions: It is my job to get the bindings in, until then my actual dts is just "request for comments". Only after the bindings are merged do I formally submit dts - simply because I dont expect dts maintainer to track what happened to my driver's binding and discussions there of. Seriously, is'nt it really reasonable for dts maintainer to check every single driver's development status in 15 different mailing lists? Because, it sounds like what you are asking. At least I wont have time for it.. I really am curious how Arnd / Tony actually pull this one off.. If they have continous cron job for checking if your patch is ready... I doubt it.. -- Regards, Nishanth Menon