From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751706AbdFTIpb (ORCPT ); Tue, 20 Jun 2017 04:45:31 -0400 Received: from mail.free-electrons.com ([62.4.15.54]:42611 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751083AbdFTIp3 (ORCPT ); Tue, 20 Jun 2017 04:45:29 -0400 Date: Tue, 20 Jun 2017 10:45:17 +0200 From: Maxime Ripard To: Vinod Koul Cc: Icenowy Zheng , linux-arm-kernel@lists.infradead.org, Chen-Yu Tsai , linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com, Icenowy Zheng , dmaengine@vger.kernel.org Subject: Re: [linux-sunxi] Re: [PATCH 1/2] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk Message-ID: <20170620084517.giq3zhvbmhpx7pge@flea.lan> References: <20170605123348.26137-1-icenowy@aosc.io> <20170605123348.26137-2-icenowy@aosc.io> <20170614083252.GK13020@localhost> <20170614084529.GL13020@localhost> <20170614090439.rkdaoo3uqzjqwuxq@flea.lan> <20170615035407.GM13020@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="du6ragup5d35o6jj" Content-Disposition: inline In-Reply-To: <20170615035407.GM13020@localhost> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --du6ragup5d35o6jj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 15, 2017 at 09:24:08AM +0530, Vinod Koul wrote: > On Wed, Jun 14, 2017 at 11:04:39AM +0200, Maxime Ripard wrote: > > On Wed, Jun 14, 2017 at 02:15:29PM +0530, Vinod Koul wrote: > > > > SoC info is in compatible, so there's no reason to make it a proper= ty. > > >=20 > > > that's why it would need to be optional for the SoC's that needs thes= e.. > >=20 > > There's nothing optional about that behaviour, it's mandatory for the > > SoC that need it, and useless on the SoC that don't. >=20 > And why should kernel put strings for each hw behaviour. You will have strings in the kernel for each hw behaviour, disregarding on whether you base the behaviour on the compatible or a set of properties. In fact, you will have *much* more strings in the kernel in the latter case. > I am expecting DT to tell me if this SoC is a special case or not > and kernel shall handle accordingly How is this not the case here? The DT tells you that this SoC is a special case through a compatible already. > > Plus, that would require changing the DT binding, which isn't > > something we can do. >=20 > Any reason why bindings can't change..? I though this was support for new > SoC... No, this is a rework of an existing code to support a new SoC. The code is already there, and the binding too. It has been for 3 years. Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --du6ragup5d35o6jj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJZSOCdAAoJEBx+YmzsjxAg5EIP/32kvP/IOaTgEOyR+KaJQw4P 2u5KwHcfmgqlVBiypmhjlxFKOUtHrvgdSpLVWBdfZmaNrPP6GlxJKcUSF2kZ6BJv f3QsSfoxmunGibhoudtz0H8X/mMhIUr9fbZC35Dgk8RrF4voi+3gBT/sns8N/+HZ VHDjREdNcE6Cu/0V1g5CoT9f1L6m4ayi15dlGxCbMMGsp2fwmqIiX/BmWswo0zZT np5jAtVluEY8VYjT6UlVue2EM3IGbCBNc0nYz2l5eHS3suaF0ngDs+gdjCcUw2Sw w9ugQoWqHQCOBnLxY4o0u368CdJ+9jKbcb/GTeQZpo/7qrZe/y3xII+jvGUytKRG rqZWSB1yM+xN+GIVjiXZFAHB00XjJYouaCMgF8EG+iJAnsYG3Lz/+J/HhMHxki9S DX4AM+E7CTpPzH2PHeL9P64YOEKYNoGIRj8XdzD6rVoK7P0OtW8erzP7sSvC4GJG UNXEnfXuSsBj0IL6/irDZ/xJzHIlY/YHnRUvvtOH8aoiS70K6msr6xo4HahoRNIE Qu+tK9YvcFVh4BrWO3hpyzsQiwG/h5//wtg3xu/NaOJ2IYf86uhep6T4BQgXUda3 U2a1SnvFunXwXleZZzWP2lteWwjiI15Y8BCUqyJWdYowQobaUvo+rS4hozOFwhaF dhugYN0O+0zK0M7eUVfM =90Cz -----END PGP SIGNATURE----- --du6ragup5d35o6jj--