Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp4443016imm; Tue, 11 Sep 2018 11:59:03 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZQZbyDTiah6JNHw/bDhewAyzr7LOOABGapa+4xiqlXhbz/dVQCzs+PAbYf7OSUqWjmEX3B X-Received: by 2002:a62:7d8d:: with SMTP id y135-v6mr30655617pfc.259.1536692343351; Tue, 11 Sep 2018 11:59:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536692343; cv=none; d=google.com; s=arc-20160816; b=H8YOyvYSTeUliGxVGP6kG+Ug4bglIt4DGqPuIKA4X1z0xG0KV0W6GiL8ksXE0c0ZGK nWZnRqi40oaBYhUymkyRdlQc9T+n5BNmRWk+pd8G+fLrTRcRLimeeoAaUFQpLvhW3Qai rp9evYjvQxpwNfCaN3lgu1xgKVoTQd/gD5eIl4Qr47nTwze6+8Y/EDW189lockX5LjY4 TylES7eOrW5nZLvrak4lPYCpfZuqvaKwTOb1LTqliC5p0BMKjNRzT36XTWFZX6/Bbi39 u5VSEy6TXwBNbohINJyCTfTNc0g2oupl/hGR+VHVwZUxbgPmFvbVy/aMA71QkXX5DvcV 9uxw== 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; bh=/yoMpDOR0IZZBYvMCcbJJ4PoMfOtDxMYwHsDhYCHaI0=; b=NGlqeBWPBqdxsfu0oKs8mbyb+jHSo1flgpPz/UniTZoMpU1cBH6gFgg9ZS7nqA087I J7wLy72g7SdmEEAhb5T0ztE1DABTRWk3xyjgtM+dfaLl6jO8OKSu/lJiqJoAWUskaP+V efzqxIZfF8Hwlxc8AORb7IqTpYnl5M9zB67X8GGGsd4AQ3z8O+eLu880T95R2gnAjL5H MlNfzm+6fXojbhuU04wyZISg4xtyi7bNyK488z5yUHJN1oBKXcANVoBO8TnoTacxw26B vVddyJX02d9ri5z4Zanq0dKH+akEeoOaLFE+w7pTjRFcYBBt0zsa8ZLS8HOoI4vQyN2b qVqA== 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 i189-v6si21896070pgd.668.2018.09.11.11.58.46; Tue, 11 Sep 2018 11:59:03 -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 S1726899AbeIKX7U (ORCPT + 99 others); Tue, 11 Sep 2018 19:59:20 -0400 Received: from mail.bootlin.com ([62.4.15.54]:56739 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726725AbeIKX7U (ORCPT ); Tue, 11 Sep 2018 19:59:20 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id D66F820731; Tue, 11 Sep 2018 20:58:39 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.0 Received: from localhost (unknown [88.191.26.124]) by mail.bootlin.com (Postfix) with ESMTPSA id A828A20618; Tue, 11 Sep 2018 20:58:39 +0200 (CEST) Date: Tue, 11 Sep 2018 20:58:39 +0200 From: Alexandre Belloni To: Lee Jones Cc: Geert Uytterhoeven , radu_nicolae.pirea@upb.ro, Rob Herring , Mark Rutland , Nicolas Ferre , Greg KH , Mark Brown , Jiri Slaby , Richard Genoud , "David S. Miller" , Mauro Carvalho Chehab , Andrew Morton , Arnd Bergmann , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux ARM , Linux Kernel Mailing List , "open list:SERIAL DRIVERS" , linux-spi Subject: Re: [PATCH v12 0/6] Driver for at91 usart in spi mode Message-ID: <20180911185839.GA25212@piout.net> References: <20180904111310.4049-1-radu_nicolae.pirea@upb.ro> <20180911093356.GE4185@dell> <20180911093917.GL2494@piout.net> <20180911153621.GP2494@piout.net> <20180911181838.GI4185@dell> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180911181838.GI4185@dell> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/09/2018 19:39:30+0100, Lee Jones wrote: > On Tue, 11 Sep 2018, Geert Uytterhoeven wrote: > > > On Tue, Sep 11, 2018 at 5:36 PM Alexandre Belloni > > wrote: > > > On 11/09/2018 16:59:09+0200, Geert Uytterhoeven wrote: > > > > On Tue, Sep 11, 2018 at 11:40 AM Alexandre Belloni > > > > wrote: > > > > > On 11/09/2018 10:33:56+0100, Lee Jones wrote: > > > > > > On Tue, 04 Sep 2018, Radu Pirea wrote: > > > > > > > Radu Pirea (6): > > > > > > > MAINTAINERS: add at91 usart mfd driver > > > > > > > dt-bindings: add binding for atmel-usart in SPI mode > > > > > > > mfd: at91-usart: added mfd driver for usart > > > > > > > MAINTAINERS: add at91 usart spi driver > > > > > > > spi: at91-usart: add driver for at91-usart as spi > > > > > > > tty/serial: atmel: change the driver to work under at91-usart mfd > > > > > > > > > > > > > > .../bindings/{serial => mfd}/atmel-usart.txt | 25 +- > > > > > > > MAINTAINERS | 16 + > > > > > > > drivers/mfd/Kconfig | 9 + > > > > > > > drivers/mfd/Makefile | 1 + > > > > > > > drivers/mfd/at91-usart.c | 71 +++ > > > > > > > drivers/spi/Kconfig | 8 + > > > > > > > drivers/spi/Makefile | 1 + > > > > > > > drivers/spi/spi-at91-usart.c | 432 ++++++++++++++++++ > > > > > > > drivers/tty/serial/Kconfig | 1 + > > > > > > > drivers/tty/serial/atmel_serial.c | 42 +- > > > > > > > include/dt-bindings/mfd/at91-usart.h | 17 + > > > > > > > 11 files changed, 606 insertions(+), 17 deletions(-) > > > > > > > rename Documentation/devicetree/bindings/{serial => mfd}/atmel-usart.txt (76%) > > > > > > > create mode 100644 drivers/mfd/at91-usart.c > > > > > > > create mode 100644 drivers/spi/spi-at91-usart.c > > > > > > > create mode 100644 include/dt-bindings/mfd/at91-usart.h > > > > > > > > > > > > Seeing as this patch-set has caused some issues this morning, I took > > > > > > the liberty to peruse back into its history to figure out where things > > > > > > started to go wrong. I also re-reviewed the MFD driver - and I'm glad > > > > > > I did! > > > > > > > > > > > > My Acked-by has been attached to the MFD portion since v5, which is > > > > > > why the code hasn't caught my eye before today. I reviewed the > > > > > > relocation of the *binding document* (serial => mfd with no changes) > > > > > > in v4 and nothing else. It appears as though you mistakenly added it > > > > > > to the *MFD driver* instead. This explains my confusion in v10 when I > > > > > > told you I'd already reviewed the binding document. > > > > > > > > > > > > As I said, I have re-reviewed the MFD driver and I'm afraid to say > > > > > > that I do not like what I see. Besides the missing header file and > > > > > > the whitespace tabbing errors, I do not agree with the implementation. > > > > > > Using MFD as a shim to hack around driver selection is not a valid > > > > > > use-case. > > > > > > > > > > > > What's stopping you from just using the compatible string directly to > > > > > > select which driver you need to probe? > > > > > > > > > > > > > > > > Then you'd have multiple compatible strings for the same IP which is a > > > > > big no-no. > > > > > > > > It's still the same hardware device, isn't? > > > > What if the SPI or UART slave is not on-board, but on an expansion board? > > > > Then the SoC-specific .dtsi has no idea what mode should be used. > > > > > > > > Hence shouldn't the software derive the hardware mode from the full > > > > hardware description in DT? If that's impossible (I didn't look into detail > > > > whether an SPI bus can easily be distinguished from a UART bus), perhaps > > > > a mode property should be added? > > > > > > Yes, this is exactly what is done: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/tree/drivers/mfd/at91-usart.c?h=ib-mfd-spi-tty-4.20-1#n33 > > > > OK. > > > > I guess the main "hackish" part is that the mfd_cell uses of_compatible, > > which thus requires having additional compatible values? > > > > I think those can just be removed. AFAICS, the SPI and serial drivers already > > match against the "at91_usart_spi" resp. "atmel_usart_serial" platform device > > names? > > The hackish part of this driver is that it's using MFD for something > which is clearly not an MFD. It's a USART device. Nothing more, > nothing less. > > Does anyone have the datasheet to hand? > It is not a simple usart, it is either a usart or a full blown SPI controller with registers changing layout depending on the selected mode. Otherwise, I'm not sure how you would get a USART to do SPI. Datasheet here: http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6438-32-bit-ARM926-Embedded-Microprocessor-SAM9G45_Datasheet.pdf USART doc starting p572, registers p621. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com