From patchwork Mon Jun 18 07:45:51 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 138856 Delivered-To: patch@linaro.org Received: by 2002:a2e:970d:0:0:0:0:0 with SMTP id r13-v6csp3643826lji; Mon, 18 Jun 2018 00:46:12 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJ9MrmOaIX7Y5T/keozkSLxwFMM0JaGjiecHCp14CBrjlv7JWbal+ZLHVo0/yx36J0gFZd5 X-Received: by 2002:a17:902:a518:: with SMTP id s24-v6mr13024368plq.144.1529307972083; Mon, 18 Jun 2018 00:46:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529307972; cv=none; d=google.com; s=arc-20160816; b=jywSFJxt4r6+HiP4Hlrbk6WAJ+cu6eVUUnh9sWEBlIJp9nw9VRd56rumrHqt0/W4Ye CEySpDsCQH7YgbQeY6ZSdAD02eFVAlgWGcl/upjcu9yVi7iSQHA+9djRE1WQXmSNmsQv wimnVGTlH8RIK5xLLPaHD2QyWM8ZF4q71XREmchgJAaR9bdVTjQM/TDVYX7FzlQ4cEnH Q741r9kiLC3sbxMIcdVCQDMzif+x07IRRRYrbPxmDcHnt0lOA5LLG8WxrCKVYx2/QJEa U3nqwCxRzN5WlOoao0Q1Mwzd9XebNxi4KUfFXXcfHKaY0VjqSqkfrMXqQgQOw5dSuMne sqHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=rb2BH2pqa4dl+BflqUWvSoL8Uf39foVytvE0GwMyvCE=; b=dIZCXTB5mUpuv249LypwfIgnLPNhf4qL1l4MKlWet+uvl5lEVbzqjW/q9pjdl+XraU 97OnHXjJ97cXIlSNaPuY/r7Gg9GO3AtSwo4Tuhjg79IggyiK8qtPimZHSdkMf6ma5KrX bihPTDujLSE1zvEv10wFz/HV864e9laUMa4qVWsuXXs9t1WOF0ATJFaeFUSpXUqZqUHp 6D0lYQlZnf3bVcT4CTMf1FZSlGkDMpcoIBtQtopQF0rULwIworGtJ1vgsYvrRT6YYXzy VKGuT7Goi9AMvPq7SM8gQW3v5xb3XO71tlckTX1hiSsa6OvajJ26OfTm2zxTCzbSkT98 mKig== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.s=google header.b=Z3RflTuY; spf=pass (google.com: best guess record for domain of devicetree-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=devicetree-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w2-v6si11655956pgs.59.2018.06.18.00.46.11; Mon, 18 Jun 2018 00:46:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of devicetree-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.s=google header.b=Z3RflTuY; spf=pass (google.com: best guess record for domain of devicetree-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=devicetree-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754911AbeFRHqL (ORCPT + 5 others); Mon, 18 Jun 2018 03:46:11 -0400 Received: from mail-lf0-f66.google.com ([209.85.215.66]:38076 "EHLO mail-lf0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754636AbeFRHqK (ORCPT ); Mon, 18 Jun 2018 03:46:10 -0400 Received: by mail-lf0-f66.google.com with SMTP id i83-v6so23121529lfh.5 for ; Mon, 18 Jun 2018 00:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=lim5N03wQFi8hCqADBRcRKQRcfJqZscJ6+pQ0EhoV5g=; b=Z3RflTuY+VxqnJCFWpKOG8C7wqqVf+SKO/sJrpuie4AfgtoHaK3sZbbGI3uCEGMNO8 U0MjHGQEDHX9VVOpRDkeSuZEHVKoOpSOkjorETwNXg19NNXXewzwfqzi2GtWK416RnFK fv/ZQ0UlZ8FHTr95/65iYNDbDnPLbFdXSeFWU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=lim5N03wQFi8hCqADBRcRKQRcfJqZscJ6+pQ0EhoV5g=; b=pMhKzBGGRUsRQOforHls+3DPXVeFVksh+l0XHlLPNtMOzd3dKFIS+mUHPGDELwxF0J VfrZbfAtE2sZ/D39bafRF+VjoAYXkyOpmuf3NA1cCZKfFe6pOhwAFTXR8B3zf2WtlYJT lCxIyJeMWZOw2RoBCWzeWkZ8BH1uoZ2pfBt6Uf0kHJG2UHMXEEwy7ckD4GUlMIyCg8k6 4F2cssdLq1O0u9Oazfw4a1Mxd5+Oiea9gm4zZFu+dZbD0mNeJzogS6CZo5VyFGqG4Tfd L1e8TY8s6EL8+dhhxinrHRkmP9jpjleZ3rbEeOgKz/a2QV3O91fbqkg23hza23cxsanQ +aVA== X-Gm-Message-State: APt69E2pq9vA4YpogN5D4J7r15EdhLPy2UwMrh577HCC5RxJ0Qp6sHrx qJU4cxTQipZaiNowWttz9uctRw== X-Received: by 2002:a19:2bc8:: with SMTP id r191-v6mr6385130lfr.61.1529307968569; Mon, 18 Jun 2018 00:46:08 -0700 (PDT) Received: from genomnajs.ideon.se ([85.235.10.227]) by smtp.gmail.com with ESMTPSA id x18-v6sm2616390ljh.63.2018.06.18.00.46.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 18 Jun 2018 00:46:07 -0700 (PDT) From: Linus Walleij To: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, dev@lists.96boards.org Cc: John Stultz , Manivannan Sadhasivam , Rob Herring , Mark Rutland , Frank Rowand , Mark Brown , Michal Simek , Andy Shevchenko , Mika Westerberg , Arnd Bergmann , Linus Walleij Subject: [PATCH 0/5] RFC: Mezzanine handling for 96boards Date: Mon, 18 Jun 2018 09:45:51 +0200 Message-Id: <20180618074556.6944-1-linus.walleij@linaro.org> X-Mailer: git-send-email 2.17.0 Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org This is a proposal for how to handle the non-discoverable 96boards plug-in expansion boards called "mezzanines" in the Linux kernel. It is a working RFC series meant for discussion at the moment. The RFC was done on the brand new Ultra96 board from Xilinx with a Secure96 mezzanine expansion board. The main part is in patch 4, the rest is enabling and examples. The code can be obtained from here: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=ultra96 You can for example probably augment the DTS file for any upstream-supported 96board and get the Secure96 going with it with minor efforts. TODO: - Proper device tree bindings for the connector, for now look at the example. - Discuss whether to actually do this or just take it all and flush it down the drain because the community doesn't like it. I'm not one of those especially infatuated with my own code, I always stay by the old programming project management mantra to calculate to make one version and throw it away as stepping stone to a good final design. - Placement: putting this in drivers/bus is just an example. drivers/platform/96boards-mezzanines is fine too, maybe better? - I am especially curious about input from Andy and Mika from the Intel/ACPI camp on what they have seen for non-discoverable plug-in boards. Does this problem even exist in the Intel world, or not... Background: - These boards connect on a custom connector on this family of boards. The relationship is many-to-many with the connector as nexus. The electronic standard for the connector is specified: https://github.com/96boards/documentation/blob/master/Specifications/96Boards-CE-Specification.pdf Example mezzanines: https://www.96boards.org/documentation/mezzanine/ - These boards have siblings on other platforms, the problem scope is similar with BeagleBone "capes": https://beagleboard.org/capes Raspberry Pi expansion boards: https://www.abelectronics.co.uk/products/18/raspberry-pi-expansion-boards Intel Edison, Galileo, Joule also have expansion boards. Idea: add a driver for the connector itself and tie it in to the device tree with a compatible string. Since the boards are non-discoverable two mechanisms are provided to discover them: - Add a very simple device tree node with just a compatible string for the board in the node. This will be simple to add from e.g. a boot loader or as an overlay from userspace. board { compatible = "96boards,secure96"; }; - Echo 1 > boardname into a sysfs file to populate the board and echo 0 > boardname to depopulate it. This makes it easy to even switch out expansion boards at runtime, if allowed by the electronics. > cd /sys/devices/platform/connector > echo 1 > secure96 lscon connector: called mezzanine_store on secure96 lscon connector: populate secure96 at24 1-0050: 2048 byte 24c128 EEPROM, writable, 128 bytes/write atmel-ecc 1-0060: configuration zone is unlocked tpm_tis_spi spi0.0: 2.0 TPM (device-id 0x1B, rev-id 16) (...) What this patch set does not do: - It does not use device tree or ACPI DSDT or any other hardware decription language to model the contents of the board per se. Instead the boards buses are populated directly with platform devices. Predictable complaints about this design: Q: This is not device tree overlays. Why is it not device tree overlays? A1: Right tool for the job, overlays are complex and the plan to get it in place seems to be spanning years, this is a few devices on simple busses and it works today. Using this approach I can already work on shaping up drivers for the mezzanine board devices as proved by: https://marc.info/?l=linux-crypto-vger&m=152820660120590&w=2 https://marc.info/?l=linux-crypto-vger&m=152820662820595&w=2 (...) I can work on drivers for the chips on the Secure96 mezzanine board. It's just an example of what the mezzanine community can do. Now they are hacking around in userspace instead of doing/reusing kernel drivers for their stuff: https://github.com/jbech-linaro/secure96 This way we can bring developers for these components into the kernel community instead of telling them to wait for some big infrastructure that comes later before they can contribute their stuff. A2: Overlays does not solve the problem if the system runs ACPI, and what about if the same connector[s] appear on a server board, servers use ACPI. Also notice that Intel have development boards with non-discoverable expansion boards as well. They just will not use device tree. A3: Overlays is Big Upfront Design. https://en.wikipedia.org/wiki/Big_Design_Up_Front This way of designing things is associated with the (pejorative term) "waterfall model" which is out of fashion as a way of doing development. I think I am not the only one slightly annoyed by the fact that device tree overlays is now starting to look like a very big very upfront design. It's just not possible to get something up and running in small iterative steps with device tree overlays. Instead huge efforts are required and it involves major possible showstoppers and uncertain outcome as indicated by Frank's TODO: https://elinux.org/Frank's_Evolving_Overlay_Thoughts This appears also in our work process documents: Documentation/process/4.Coding.rst "experience has shown that excessive or premature abstraction can be just as harmful as premature optimization. Abstraction should be used to the level required and no further." So for that reason, or other predictable statements such as "you're reinventing board files", I'd like to have an open discussion on how to actually support these boards with the mainline kernel and work on device drivers common with other systems now, and not in 2020 when they are already obsolete. Yeah it is a bit controversial, but what we are doing right now for non-discoverable expansion boards isn't working in my opinion, so I have to throw something out there, and this is it. Linus Walleij (5): RFC: gpio: Add API to explicitly name a consumer RFC: eeprom: at24: Allow passing gpiodesc from pdata RFC: spi: Make of_find_spi_device_by_node() available RFC: bus: 96boards Low-Speed Connector RFC: ARM64: dts: Add Low-Speed Connector to ZCU100 .../boot/dts/xilinx/zynqmp-zcu100-revC.dts | 27 +- .../96boards-ls-connector.c | 307 ++++++++++++++++++ .../96boards-mezzanines/96boards-mezzanines.h | 46 +++ .../96boards-mezzanines/96boards-secure96.c | 249 ++++++++++++++ drivers/bus/96boards-mezzanines/Kconfig | 36 ++ drivers/bus/96boards-mezzanines/Makefile | 6 + drivers/bus/Kconfig | 2 + drivers/bus/Makefile | 4 +- drivers/gpio/gpiolib.c | 13 + drivers/misc/eeprom/at24.c | 6 +- drivers/spi/spi.c | 33 +- include/linux/gpio/consumer.h | 7 + include/linux/platform_data/at24.h | 2 + include/linux/spi/spi.h | 4 + 14 files changed, 723 insertions(+), 19 deletions(-) create mode 100644 drivers/bus/96boards-mezzanines/96boards-ls-connector.c create mode 100644 drivers/bus/96boards-mezzanines/96boards-mezzanines.h create mode 100644 drivers/bus/96boards-mezzanines/96boards-secure96.c create mode 100644 drivers/bus/96boards-mezzanines/Kconfig create mode 100644 drivers/bus/96boards-mezzanines/Makefile -- 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html