From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A236DEE49A0 for ; Wed, 23 Aug 2023 12:29:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234835AbjHWM3n (ORCPT ); Wed, 23 Aug 2023 08:29:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52472 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234778AbjHWM3n (ORCPT ); Wed, 23 Aug 2023 08:29:43 -0400 Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 28923CFE for ; Wed, 23 Aug 2023 05:29:38 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-d71c3a32e1aso5179814276.3 for ; Wed, 23 Aug 2023 05:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1692793777; x=1693398577; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=vM2mBO0PFbPREfV6y5utVh2uALzEkEsaG8Xoi0Qft/g=; b=Cd9OYG6UG81jfau+T3IdehXTKw4ReKMw2IoJPnYZzAxGGzKNAFti+ubPYfRZQXe2lV 9cyH7NPPn5nY+3gJsPyUCPZwcnor6ws79981VjqYLlmK9E6BpewaCHc6rXMn7xxen4sS rR5Z9EikHYKIzTdu2Cq7KxgROwodbpvbtPWT8e9R+GgMcWIEdYdTyutJLzWJ9me4fEFh 8pP18HFTdKaMMbrbtVcw+WkbiBrRnXJSvmbz6gbM98Mn7QvEp8gyQyymj+2XI+Buyf0L Cj8xBkAUJXgCU1tN8JXdssrj48IPPEwDQAnm/x7n9jIwESLqINE8C2vQNBX3FSl5g4Kt Lcig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692793777; x=1693398577; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vM2mBO0PFbPREfV6y5utVh2uALzEkEsaG8Xoi0Qft/g=; b=GgxBEozlhoL2Nb0xX1gh/bB8WrCbGye6H07SdhgE+qLjvXILV7umX9QIlfSDf7LWTm ZI8zeoM40RRvhT8R+lpwtvEvHEbrSpo/+Q/P5aLmUrFt+ex1X1ESHDwJImFGDZKOwrU+ xSQlT82xF7sANkYywvrOsMNfSJAwBFx9ypzuAQQJsqQnnICW2aWirTVYsCj0L/ysdjvr vauqNfAxJMxQ0etlkw1xTriHpfUEafEakW32an8n0RzAFRFF6eKDPhG62nuT8Z99/hCP rRxEgi6tffGS9FFep/WCVqlofPks3HwHqtva2tnzZ3/fjVfUEvZs3ZN6ZGyQ7rZgg2hZ yxQg== X-Gm-Message-State: AOJu0YyJUjiE0QY9d78UyTB2euMyTDL3IRNiNo5QgpStAw86LXEPtiv8 c1B3+CCEbGLe5weJHpIT6+qpaiDp818kf5XyDB39NUVdpxmr945bAaw= X-Google-Smtp-Source: AGHT+IFFKP6YhXlKwTz5rGZpalkEJfHxEFdkjbdXxEPEMXoQfAsKDqn6fiAmTAPzSUrq8396Ku0mZMSONe0jbpZGYXQ= X-Received: by 2002:a25:3757:0:b0:d35:9a48:51b0 with SMTP id e84-20020a253757000000b00d359a4851b0mr11184274yba.7.1692793777291; Wed, 23 Aug 2023 05:29:37 -0700 (PDT) MIME-Version: 1.0 References: <20230823033427.23072-1-zhuyinbo@loongson.cn> <20230823033427.23072-3-zhuyinbo@loongson.cn> In-Reply-To: <20230823033427.23072-3-zhuyinbo@loongson.cn> From: Linus Walleij Date: Wed, 23 Aug 2023 14:29:25 +0200 Message-ID: Subject: Re: [PATCH v4 2/2] gpio: loongson: add more gpio chip support To: Yinbo Zhu Cc: Bartosz Golaszewski , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Jianmin Lv , wanghongliang@loongson.cn, loongson-kernel@lists.loongnix.cn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi Yinbo, thanks for the new patch, it's starting to look really good! The main point with offsets in the match data is very nice. On Wed, Aug 23, 2023 at 5:34=E2=80=AFAM Yinbo Zhu wr= ote: > This patch was to add loongson 2k0500, 2k2000 and 3a5000 gpio chip > driver support. > > Signed-off-by: Yinbo Zhu (...) > static int loongson_gpio_to_irq(struct gpio_chip *chip, unsigned int off= set) > { > + unsigned int u; > struct platform_device *pdev =3D to_platform_device(chip->parent)= ; > + struct loongson_gpio_chip *lgpio =3D to_loongson_gpio_chip(chip); > + > + if (lgpio->chip_data->mode =3D=3D BIT_CTRL_MODE) { > + u =3D readl(lgpio->reg_base + lgpio->chip_data->inten_off= set + offset / 32 * 4); > + u |=3D BIT(offset % 32); > + writel(u, lgpio->reg_base + lgpio->chip_data->inten_offse= t + offset / 32 * 4); This offset / 32 * 4 is really hard to read. What about /* Get the register index from offset then multiply by bytes per register *= / (offset / 32) * 4 > lgpio->reg_base =3D reg_base; > + if (device_property_read_u32(dev, "ngpios", &ngpios) || !ngpios) > + return -EINVAL; > + > + ret =3D DIV_ROUND_UP(ngpios, 8); > + switch (ret) { > + case 1 ... 2: > + io_width =3D ret; > + break; > + case 3 ... 4: > + io_width =3D 0x4; > + break; > + case 5 ... 8: > + io_width =3D 0x8; > + break; > + default: > + dev_err(dev, "unsupported io width\n"); > + return -EINVAL; > + } Is it really a good idea to infer the register width from ngpios? What about just putting this into the struct loongson_gpio_chip_data as well? Certainly it will be fixed for a certain device. Yours, Linus Walleij