Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753174AbaBXIJU (ORCPT ); Mon, 24 Feb 2014 03:09:20 -0500 Received: from mail-la0-f52.google.com ([209.85.215.52]:38366 "EHLO mail-la0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751402AbaBXIJR (ORCPT ); Mon, 24 Feb 2014 03:09:17 -0500 MIME-Version: 1.0 In-Reply-To: References: <1392907389-21798-1-git-send-email-geert@linux-m68k.org> <1392907389-21798-8-git-send-email-geert@linux-m68k.org> Date: Mon, 24 Feb 2014 17:09:15 +0900 Message-ID: Subject: Re: [PATCH 07/10] spi: sh-msiof: Add support for R-Car H2 and M2 From: Magnus Damm To: Geert Uytterhoeven Cc: Mark Brown , Takashi Yoshii , linux-spi , SH-Linux , linux-kernel , Geert Uytterhoeven , "devicetree@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Geert, On Mon, Feb 24, 2014 at 4:39 PM, Geert Uytterhoeven wrote: > Hi Magnus, > > On Mon, Feb 24, 2014 at 3:45 AM, Magnus Damm wrote: >> On Fri, Feb 21, 2014 at 1:13 AM, Geert Uytterhoeven >> wrote: >>> On Thu, Feb 20, 2014 at 4:41 PM, Magnus Damm wrote: >>>> On thing stuck out a bit with the bindings. I can see that you specify >>>> both fifo size and use the SoC suffix for the r8a7790 and r8a7791 >>>> bindings. Isn't that a bit of redundant information there, if we know >>>> that the SoC is r8a7790 or r8a7791 then can't we simply put that >>>> information in r8a779x_data above and perhaps keep the binding >>>> simpler? Perhaps same thing applies to other properties as well? >>> >>> "renesas,tx-fifo-size" and "renesas,rx-fifo-size" are part of the existing >>> bindings, so I'm a bit reluctant to change these. >>> Hmm, since the original bindings didn't specify the default values, >>> I could make them chip-specific, though. >> >> Thanks, yes I think treating the "renesas,tx-fifo-size" and >> "renesas,rx-fifo-size" bindings as optional and allow us to rely on >> chip-specific default values makes sense. >> >>> The only other property is "num-cs", which can have any value if you >>> start using the generic "cs-gpios". >> >> I see. It looks to me that such a setting is board-specific, so what >> is a sane default in the SoC DTSI? You seem to have it set to "1" >> today, but if the board is supposed to override it anyway then do we >> need to set it? >> >> Anyway, "num-cs" is a minor detail so no need to bother about that too much! > > In v2, I'll drop the "num-cs" from the dtsi, so it will default to the driver's > default (which is 1, for the simple case of using hardware controlled CS). Sounds good, thanks for your help! / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/