Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp2616658ybh; Mon, 9 Mar 2020 09:27:11 -0700 (PDT) X-Google-Smtp-Source: ADFU+vt3HQmjGxJ2Zk7w50oaR9HsKU7WhbHLkUrmHScXZDF/QbyWNUudu9GptgTU5Ql32cWyP2Ul X-Received: by 2002:a05:6808:5d4:: with SMTP id d20mr94240oij.138.1583771230983; Mon, 09 Mar 2020 09:27:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583771230; cv=none; d=google.com; s=arc-20160816; b=mOVZBvN5PGwZpaIo6+MugKyZGqo4PjfvHQd3z86LwtcZLmXX3OZ+1d/TNXduiZmJ4P NuclXzstLzAvzwNBJlM2SPnE7INHMpChASRpVaoZJ/iO6GXgHhPBbiTzkKwQ1HOJ9zoR hagKDDb8K3kcyd8iQp5wqU1FxiTDfd4hBVlV2atG8MUg0iUkQsEzms4MxOutFzRZfh0E hQousaICSsu7c5Isi4PrX7JdOe5T4Cc1v78/qDGMhu4Vn+J6Hd1Ix2GBnKkuANINKlKB rFIqMeDI2wl78UM2rduiEk4hRZxhZ6wWEHCYoDtgpCp31RdbGiRHA1QUhn70sjiWBuB3 r52A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=2SxurIv9R9qp2Si0DTgSQoKCkSNaRgx6p4CO5nqcqJE=; b=IIBUoyvd+wNtKiAJym1IdtBrlDO6DA4tkadUSQTiC1j2FFxdcy0+quBYhkxdLCwnzh dLhM1OKiVXzIAMsQ9PBmpamQhAEfY4lH0vQ037ZrIj67TLVQAFZM2a4lTjF3sAgUdZwu YyR893s8srJBNpHow7o/PpDs4yhziGI45XArrgTtaR3RZbVOn9eQQVn1gi7ABQatgUwu e8h1a1c55lxYaNJ/fMcKJHXK05zSt/KJhg4Itc8m3OZ7tYd1MEFYMFkcYLrW0NRykuad msdDT4ogsSVHPziLMhxkfJcW2Coaf9Gt014KQ5+T+SD5OSfPjQSP982l2UGzwgUpORML Nsaw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=WSQZahax; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x9si1202166oia.194.2020.03.09.09.26.58; Mon, 09 Mar 2020 09:27:10 -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; dkim=pass header.i=@kernel.org header.s=default header.b=WSQZahax; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727220AbgCIQ0C (ORCPT + 99 others); Mon, 9 Mar 2020 12:26:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:53594 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727195AbgCIQ0C (ORCPT ); Mon, 9 Mar 2020 12:26:02 -0400 Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5B247227BF; Mon, 9 Mar 2020 16:26:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583771161; bh=Oufh7MrQPjXo9lbYsp3qWQvteiioqKO/EGPSF2qFeBo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=WSQZahaxTQSMDiV2kIuXICnK4TWpj3HS3+x9d6T8gFH3ZZoSfLvTEHw4Hi1O5q6RA R7VS//IYFN4OQ6jLw2so+oiCEKt0V+T00ucYfwrYhljZCKPqaR4cmoQF/Jx6ECNm0E uGMZjp3m5CnUbyvIoP4/4IgnEuyW3CK4STRDSB4w= Received: by mail-qk1-f176.google.com with SMTP id c145so4002783qke.12; Mon, 09 Mar 2020 09:26:01 -0700 (PDT) X-Gm-Message-State: ANhLgQ0TGRkztmj6+FE+3N9Bx/R+XiCHZMSViVOLnqI/1p3BSME05GHn MD2ZSNRlBL5Gim2Yu4FzdvTWbFUEXgH1DtLrPA== X-Received: by 2002:ae9:f205:: with SMTP id m5mr16056405qkg.152.1583771160417; Mon, 09 Mar 2020 09:26:00 -0700 (PDT) MIME-Version: 1.0 References: <20190822092643.593488-1-lkundrak@v3.sk> <20190822092643.593488-7-lkundrak@v3.sk> In-Reply-To: <20190822092643.593488-7-lkundrak@v3.sk> From: Rob Herring Date: Mon, 9 Mar 2020 11:25:49 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 06/20] irqchip/mmp: do not use of_address_to_resource() to get mux regs To: Lubomir Rintel Cc: Olof Johansson , Mark Rutland , Thomas Gleixner , Jason Cooper , Marc Zyngier , Kishon Vijay Abraham I , Russell King , Michael Turquette , Stephen Boyd , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , linux-clk , Pavel Machek Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 22, 2019 at 4:34 AM Lubomir Rintel wrote: > > The "regs" property of the "mrvl,mmp2-mux-intc" devices are silly. They > are offsets from intc's base, not addresses on the parent bus. At this > point it probably can't be fixed. Another option is for platform code to fixup the live DT and just add 'ranges' to make this work. > On an OLPC XO-1.75 machine, the muxes are children of the intc, not the > axi bus, and thus of_address_to_resource() won't work. We should treat > the values as mere integers as opposed to bus addresses. > > Signed-off-by: Lubomir Rintel > Acked-by: Pavel Machek > > --- > Changes since v4 of "MMP platform fixes" set: > - Add a comment, as suggested by Pavel > > Changes since v1: > - Fix up typoes in the comment > - Do not allow the regs property be larger than the bindings document. > > drivers/irqchip/irq-mmp.c | 22 +++++++++++++--------- > 1 file changed, 13 insertions(+), 9 deletions(-) > > diff --git a/drivers/irqchip/irq-mmp.c b/drivers/irqchip/irq-mmp.c > index 14618dc0bd396..e41e47ab71d3b 100644 > --- a/drivers/irqchip/irq-mmp.c > +++ b/drivers/irqchip/irq-mmp.c > @@ -424,9 +424,9 @@ IRQCHIP_DECLARE(mmp2_intc, "mrvl,mmp2-intc", mmp2_of_init); > static int __init mmp2_mux_of_init(struct device_node *node, > struct device_node *parent) > { > - struct resource res; > int i, ret, irq, j = 0; > u32 nr_irqs, mfp_irq; > + u32 reg[4]; > > if (!parent) > return -ENODEV; > @@ -438,18 +438,22 @@ static int __init mmp2_mux_of_init(struct device_node *node, > pr_err("Not found mrvl,intc-nr-irqs property\n"); > return -EINVAL; > } > - ret = of_address_to_resource(node, 0, &res); > + > + /* > + * For historical reasons, the "regs" property of the > + * mrvl,mmp2-mux-intc is not a regular "regs" property containing > + * addresses on the parent bus, but offsets from the intc's base. > + * That is why we can't use of_address_to_resource() here. > + */ > + ret = of_property_read_variable_u32_array(node, "reg", reg, > + ARRAY_SIZE(reg), > + ARRAY_SIZE(reg)); > if (ret < 0) { > pr_err("Not found reg property\n"); > return -EINVAL; > } > - icu_data[i].reg_status = mmp_icu_base + res.start; Seems like it was treated as an offset already? > - ret = of_address_to_resource(node, 1, &res); > - if (ret < 0) { > - pr_err("Not found reg property\n"); > - return -EINVAL; > - } > - icu_data[i].reg_mask = mmp_icu_base + res.start; > + icu_data[i].reg_status = mmp_icu_base + reg[0]; > + icu_data[i].reg_mask = mmp_icu_base + reg[2]; This is a bit fragile as it's hard coding the cell sizes. Are they the same for all the platforms? I'd be more comfortable doing that in platform specific fixup code than here. Rob