Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp3283539ybi; Fri, 5 Jul 2019 04:58:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqxqIJoj1x+hJWuJclx7xQk0EM4CyKjfNynD1oGuPApUt91RMhomBR1spwUGuc7iObV9S0y9 X-Received: by 2002:a63:1f1f:: with SMTP id f31mr5060715pgf.353.1562327929002; Fri, 05 Jul 2019 04:58:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562327928; cv=none; d=google.com; s=arc-20160816; b=MRBZ5s3/UugRrxYSAgA3XyL872QuxU/z3GHpKelReFHXaxaus7bQbq2lGwAsTOUdZ0 UgrNnKHOU1cqE5sgMBOQp/R+c+OP8wNYn4BLF0zPeRfvShTLQ8WrtvvQ/vSomGW+rn0i /FlMtbKtZldV60e9oiEZxwsvNxqpvLXtFoShijvqkV3+JfhiCQmoLtkvcE3SDq/mooDg Owoo0K+QZv+JrNtukA34ImXusSYoAb7SwiKvTGQ9vvRy9S1OoMvx5gZqVmv5v9o8P64a mQG5mT6kxgQPyACJfVnF7E3Pmcl+pkj1wjQSd36WFiJIzFCroTM8U/Gj9ONEnmM3g25f b75w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version; bh=HRoTSVuyTswIVW15ikjXFdX2n8jCbUCIyQ6fYzzcux4=; b=CiUBU9Q5bWzSBgOsqrlSaLc1enTt0cKaPOpDnB/3XDiLd2s/nQjplon9wb3YUFlUTS zcZao+NaMroXMBq09npSqE9eChKCR1qTYNKUHXhWcRaOyBGyrh3iiiW/Ov9cl1UB/CzV E8XE9PbdwIEfGZiEmHE46DPAIQio0k01V/d6fBAxxoghHxMS501vwOiluCpnPSe5Ja5v 84fNRbSiClTXRWriNXhwW9ZOBA10/qmk7QZxoK+DkmQRjs/K6wwdJs1FB1dzRIf2X+h5 C6egjIGfyqaX/Oxpj4hKfm8EaQ9G1TjW6ONv3p/d2GZ4ZtcPAqMBHAg8QbFYhpkGgEan lemQ== 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 i5si8619348pgq.412.2019.07.05.04.58.33; Fri, 05 Jul 2019 04:58:48 -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 S1728516AbfGELgv (ORCPT + 99 others); Fri, 5 Jul 2019 07:36:51 -0400 Received: from host-88-217-225-28.customer.m-online.net ([88.217.225.28]:55434 "EHLO mail.dev.tdt.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726107AbfGELgu (ORCPT ); Fri, 5 Jul 2019 07:36:50 -0400 Received: from mail.dev.tdt.de (localhost [IPv6:::1]) by mail.dev.tdt.de (Postfix) with ESMTP id B24B42110C; Fri, 5 Jul 2019 11:36:47 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 05 Jul 2019 13:36:47 +0200 From: Florian Eckert To: Andy Shevchenko Cc: Eckert.Florian@googlemail.com, "Enrico Weigelt, metux IT consult" , Darren Hart , Andy Shevchenko , Platform Driver , Linux Kernel Mailing List Subject: Re: [PATCH 0/3] Update pcengines-apuv2 platform device In-Reply-To: References: <20190704090205.19400-1-fe@dev.tdt.de> Message-ID: <226c0a14b7a662be019d02eee4695d17@dev.tdt.de> X-Sender: fe@dev.tdt.de User-Agent: Roundcube Webmail/1.1.5 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.dev.tdt.de Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Andy >> >> This patchset adds the following changes to this pcengines-apuv2 >> >> platform device. >> >> >> > >> > Before doing anything to this driver, what is the plan for previously >> > upstreamed: >> > >> > drivers/leds/leds-apu.c >> >> I think we can remove the related APU2/APU3 code stuff from this >> driver. >> The recently added pcengines-apuv2 driver does *not* support the APU1. >> So I think we need the related APU1 stuff if we still want to support >> this board. > > So, I would like to see some unification (since it's material for v5.4 > cycle anyway, we have time). A few thoughts and information about your suggestion to unify this. APU1 (PC-Engines) CPU "AMD G series T40E APU": This is also an old design and is not recommend for new design (deprecated). Also not many were produced and are in the field. See https://pcengines.ch/apu.htm Platform-Device (LEDs, Button): I have no platform device description found in the linux sources. So the GPIO button should not work. LEDs-Driver: Only the LEDs should work with this device driver. This is shared additonal with new APU2/APU3. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/leds/leds-apu.c I think we should remove the APU2/APU3 stuff. This will now be handled by the new gpio-amd-fch.c / pcengines-apuv2.c kombination. APU2/APU3/APU4 (PC-Engines) CPU "AMD Embedded G series GX-412TC": This is the newest design and is recommend for new products. See https://pcengines.ch/apu2.htm GPIO-Driver: The following driver is responsible for the GPIO export and handling https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpio/gpio-amd-fch.c Platform-Device (LEDs, Button): This Platform description is only valid for APU2/APU3 and not for APU1. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/platform/x86/pcengines-apuv2.c LEDs-Driver: We have an additional device only for LEDs this works for APU1/APU2/APU3. I think we should remove the APU2/APU3 LEDs from the leds-apu device as mentioned above. So this device supports only the APU1 LEDs. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/leds/leds-apu.c We could extend and/or rename the pcengienes-apuv2 device to support also APU3 and the newest APU4. The APU2 does only have LEDs Button and the MPCIE2 reset lines see my patch. The APU3 does have an additional the simswap pin. So the current pcengines-apuv2 platform is from my point of view wrong. We should change this to the following layout and add the legacy GPIO numbering. This are the following GPIOs: APU2: LED1 LED2 LED3 BUTTON MPCIE2 MPCIE3 APU3: LED1 LED2 LED3 BUTTON MPCIE2 MPCIE3 SIMSWAP APU4: TODO >> > arch/x86/platform/geode/alix.c >> >> I think this is not related because this is a different platform >> driver. >> Maybe we should move them to drivers/platform/x86? > > You mentioned somewhere ALIx, can you elaborate if these are platforms > of the same family (PC engines)? > > Looking into the code, I think we may unify all three under umbrella > of one driver if the above is true. ALIX (PC-Engines) CPU "AMD Geode LX": This is an old design we have already in use and is not recommend for new design (deprecated) https://pcengines.ch/alix.htm GPIO-Driver: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpio/gpio-cs5535.c Platform-Device (LEDs, button): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/platform/geode/alix.c I think we should leave the driver as it is because this is a different design and has nothing to do with the PUs. The only thing I can imagine is to move the platform device to "drivers/platform/x86", but this is cosmetic. I have only mentioned the alix board to explain why I think that we should change the APU key code from the GPIO button to unify this. With Best Regards, Florian