Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3780890pxf; Mon, 15 Mar 2021 19:31:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyyhBg3alhQouhoUEwshYr7zNqf4NVoolqcL4ng/HU9MrJS4xOpRJ8op7PI3RfzuLOdeURn X-Received: by 2002:a05:6402:35c9:: with SMTP id z9mr33116513edc.94.1615861878883; Mon, 15 Mar 2021 19:31:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1615861878; cv=none; d=google.com; s=arc-20160816; b=Hc1lsy3NXdFXg4vq71ykFFHapBvkk3oGXANtUW+KnYjiMmWUO4roFY+54QLLwcj509 uxVb188Y04/Jl6wGIvR14mwz5Kz25JFjlopgBl8q27L4UlJZ9kO4lb6ijEpvRt5QFYNJ 40uINL6dIf1sVnFIVJ0FwpTvDo60+zQn1I7pv+D2rtJ7sTkXa14IXJbzIOhKA78cfGnk LiEf5WTGZAvPodCa4nhq52YpIkHGHa53SkbexydY1QAmpTEs4La+in1yeaZqbhnbYJZC SLhoFSusxlHDGVNrZTWO8lGdl3XM+QGrGY/T1HiWVtIHS7q0VsX4mNdZdjWDDwSUGsEn gfNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=pskzclMkXR3IRzEZOEFMV+FedUz9vBjzoT3S2ZaEyiU=; b=BxV/tq/HEDdOJMl734lvHxDF97ksCMROcMFfSkBgO1k1meKK8zve8+sK+6CN8F/0oI CIgNLt8GvHVoLWSDw/YFhz0yf4Dlryx/3HXQWHR3a1tis1afw7tXVPKSW4SMU524zLLR d2+QnQ/L/7h63o5nVkzvNc6k6nEab1okyahGTS70XmMI62+gYZe//QTIU2KmAy0JAUVg m/ABi2YcaNmTSghK5leFyOrWTsBgBE0EKO4xOY4cHtcYcPAgghKBcsW7iPMtmIiLFCDh ZeOX1hvDytbm/jm1+UnlFweRgSwXNcAxa5OursSSG9zRJng6ESP50HcKP7nI2/5bpjvP pWxw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@svanheule.net header.s=mail1707 header.b=hoowfyuw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=svanheule.net Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s20si12163546edq.484.2021.03.15.19.30.38; Mon, 15 Mar 2021 19:31:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@svanheule.net header.s=mail1707 header.b=hoowfyuw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=svanheule.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233080AbhCOTJq (ORCPT + 99 others); Mon, 15 Mar 2021 15:09:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233233AbhCOTJT (ORCPT ); Mon, 15 Mar 2021 15:09:19 -0400 Received: from polaris.svanheule.net (polaris.svanheule.net [IPv6:2a00:c98:2060:a004:1::200]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2ABD6C06174A for ; Mon, 15 Mar 2021 12:09:18 -0700 (PDT) Received: from [IPv6:2a02:a03f:eaff:9701:b4db:50a7:6f83:328f] (unknown [IPv6:2a02:a03f:eaff:9701:b4db:50a7:6f83:328f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: sander@svanheule.net) by polaris.svanheule.net (Postfix) with ESMTPSA id F14B21DE339; Mon, 15 Mar 2021 20:09:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=svanheule.net; s=mail1707; t=1615835357; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pskzclMkXR3IRzEZOEFMV+FedUz9vBjzoT3S2ZaEyiU=; b=hoowfyuwXjQinpl+0faHCjkwmcG6kVRtut5FejL7IGhiY50Q0obkHABpSZKHILnnOjtQwr mlxKwCdD8CQmNZ3E8pBncoCGXxUteSJPVoqQVhiBePT2d6daZcVo0PC3g4BcTuuuFk1vJG X8YiGNMgfCX+E/bt20hRl1/bDtynMhCUebieJI5NeZ5Zre8gc/um6/goA0gXPgSjLfGk4g zwAqLSVSTM0L/KTvBW/cjYv40Sfs5JoLI7XVzBB/KEYaBGG2Ib9stGy4nvBw89TFlC27wP vlTlsQbzPtIKfvhYNqyn33sap6pv9hC9ps1VvqUhDu9d6Tao0rU0pqH3hAWAfg== Message-ID: Subject: Re: [PATCH 2/2] gpio: Add Realtek Otto GPIO support From: Sander Vanheule To: Linus Walleij Cc: "open list:GPIO SUBSYSTEM" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Bartosz Golaszewski , Rob Herring , Thomas Gleixner , Marc Zyngier , "linux-kernel@vger.kernel.org" , Bert Vermeulen Date: Mon, 15 Mar 2021 20:09:15 +0100 In-Reply-To: References: <20210315082339.9787-1-sander@svanheule.net> <20210315082339.9787-3-sander@svanheule.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2021-03-15 at 16:10 +0100, Linus Walleij wrote: > On Mon, Mar 15, 2021 at 9:26 AM Sander Vanheule > wrote: > > > Realtek MIPS SoCs (platform name Otto) have GPIO controllers with > > up to > > 64 GPIOs, divided over two banks. Each bank has a set of registers > > for > > 32 GPIOs, with support for edge-triggered interrupts. > > > > Each GPIO bank consists of four 8-bit GPIO ports (ABCD and EFGH). > > Most > > registers pack one bit per GPIO, except for the IMR register, which > > packs two bits per GPIO (AB-CD). > > > > Although the byte order is currently assumed to have port A..D at > > offset > > 0x0..0x3, this has been observed to be reversed on other, Lexra- > > based, > > SoCs (e.g. RTL8196E/97D/97F). > > > > Interrupt support is disabled for the fallback devicetree- > > compatible > > 'realtek,otto-gpio'. This allows for quick support of GPIO banks in > > which the byte order would be unknown. In this case, the port > > ordering > > in the IMR registers may not match the reversed order in the other > > registers (DCBA, and BA-DC or DC-BA). > > > > Signed-off-by: Sander Vanheule > > Overall this is a beautiful driver and it makes use of all the > generic > frameworks I can think of. I don't see any reason not to merge > it so: > Reviewed-by: Linus Walleij Thanks for the review and the kind comments! > > The following is some notes and nitpicks, nothing blocking any > merge, more like discussion. > > > +enum realtek_gpio_flags { > > +       GPIO_INTERRUPTS = BIT(0), > > +}; > > I suppose this looks like this because more flags will be introduced > when you add more functionality to the driver. Otherwise it seems > like overkill so a bool would suffice. > > I would add a comment /* TODO: this will be expanded */ > That's correct, I would like this to be extendable. Like the commit message noted, some other SoC appear to have port order D-C-B-A. The current driver only supports the A-B-C-D port order, so a flag could be added to differentiate between A-first and D-first. Another flag that will be added in the future, is one to indicate that the GPIO block has extra interrupt control registers, located after the second GPIO bank. For example, the rtl9300-series appears to have both the reversed port order, and an extra "interrupt enable" register. This is not yet implemented, since I don't currently have a device with this type of SoC. > > +static inline u32 realtek_gpio_imr_bits(unsigned int pin, u32 > > value) > > +{ > > +       return ((value & 0x3) << 2*(pin % 16)); > > +} > > I would explain a bit about this, obviouslt it is two bit per > line, but it took me some time to parse, so a comment > about the bit layout would be nice. > > > +       unsigned int offset = pin/16; > > Here that number appears again. > I've updated the patch (and added your Reviewed-by tags) for a v2. Hopefully this is now more obvious from the code and comments. Best, Sander > The use of GPIO_GENERIC and GPIO irqchip is flawless > and first class. > > Thanks! > Linus Walleij