From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753193AbbJMPBv (ORCPT ); Tue, 13 Oct 2015 11:01:51 -0400 Received: from mout.kundenserver.de ([212.227.17.24]:54399 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752422AbbJMPBt (ORCPT ); Tue, 13 Oct 2015 11:01:49 -0400 From: Arnd Bergmann To: Gabriele Paoloni Cc: Bjorn Helgaas , "Wangzhou (B)" , Bjorn Helgaas , "jingoohan1@gmail.com" , "pratyush.anand@gmail.com" , "linux@arm.linux.org.uk" , "thomas.petazzoni@free-electrons.com" , "lorenzo.pieralisi@arm.com" , "james.morse@arm.com" , "Liviu.Dudau@arm.com" , "jason@lakedaemon.net" , "robh@kernel.org" , "gabriel.fernandez@linaro.org" , "Minghuan.Lian@freescale.com" , "linux-pci@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , zhangjukuo , qiuzhenfa , "liudongdong (C)" , qiujiang , "xuwei (O)" , "Liguozhu (Kenneth)" , "Wangkefeng (Kevin)" , Rob Herring Subject: Re: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05 Date: Tue, 13 Oct 2015 17:00:49 +0200 Message-ID: <11677087.JbqAo0FWJE@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <1444445957-239522-1-git-send-email-wangzhou1@hisilicon.com> <6336414.HvfCQcuT3Y@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:tzOJOqeqr8GG3XaIyrR9rIhqK8MJhvLvgVj05CN0ABgBfY1yISJ dIIntJ+fXCkuQCIz7AXW5Q3g8C6kkaU3SKJctHBvrZLgGDUrFcHxuotEwNalwVS/4LbeLRz FNVrvlOn06XTsxBnyCYaMxs0kF8mGPjaDg63IRQ5LmLY5LrRQJGcJQYPdK6ba3HvN+IBMDy aUvSSNjucaeBEUWNS49Ew== X-UI-Out-Filterresults: notjunk:1;V01:K0:n0o2SzjGXeI=:enUZbG89A8UpkE1/Q7esDM f+HM0foA0LPUEBILDa795SIJ336nUGNEIvSCm3qyT4a97vDdL5NgxKPU4tnmkMMwxeTbU6exn WR/jsN8BZeJBl8RKvgYcEtvo4cbC556/1+fHAhImu0vD34DNrJ5BRGyTGPpVO66gPKga8bP01 oiqIxwbUj0Lp0ysjl/g6m9b32+H+W8G9w4cdNmf+NBGQ5A+YbTeL2DwZa59lq/foJ+tAFWvul JnTI/hG+3BLQpC7UYoczn0nUx8kFbpU+dKMUYemMgoZB/KSzVDfZ+soqkOHWK/iSXOMbHciV7 WOLMro17u+1axpnlcTfErQ5xXO7TbZgn5h5/RhELvYA62DABqnf6lQ/cv2Dv+OjgNK4DpNw/0 FZ8kXhIE3gj1QwYqWxKTNT0Y5k1wflgHKRuQPUH34wDUEJzhlly1mn+yZrvT8dAJSumHyoKdB Jo/6eU1AILKj5lkO07vwp3UuKT3jbeLDpnE3H3rLVpj15RZcur1n/fnxzxKI7T0+duaIkdhsA dltc289fk1OJZtLu4g28Vg2KCD4plwpRUqEZKaBRH4Cp6qKGkofAY1lm/UIygPGq971ja/Yvk wQL9bMd2v76CHSqHoX4kf2u1/FKhlzI8zTKdjanu1Rt2cn/+xyyXNVoBns5fT/3UjTqd1iXqx IW7TE5sRaxey61b2+Hp3XoXydDAHviGtRvJNzVluOyTjZqgQfGR+8WdWfEJx1Ng6pqsVCnezb EOAFVZMM7IUdWDtf Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 13 October 2015 14:49:07 Gabriele Paoloni wrote: > > On Monday 12 October 2015 16:35:45 Bjorn Helgaas wrote: > > > > > > > +{ > > > > + u64 addr; > > > > + struct device_node *msi_node; > > > > + struct resource res; > > > > + struct device_node *np = pp->dev->of_node; > > > > + struct hisi_pcie *pcie = to_hisi_pcie(pp); > > > > + > > > > + msi_node = of_parse_phandle(np, "msi-parent", 0); > > > > + if (!msi_node) { > > > > + dev_err(pp->dev, "failed to find msi-parent\n"); > > > > + return -EINVAL; > > > > + } > > > > + of_address_to_resource(msi_node, 0, &res); > > > > > > Does this use the "msi-parent" node in the same way as other drivers > > > do? I'm sure there must be other places where we extract struct > > > resource information from an "msi-parent" node, but I don't see them. > > > > > > I'm trying to verify that this isn't some kind of incompatible > > > extension of the "msi-parent" property. I cc'd Arnd and Rob (DT > > > experts). > > > > This is not ok, what this does is that it relies on a particular > > implementation of the MSI controller and directly accesses its > > registers. > > Hi Arnd, thanks for reviewing. > > What we do is to retrieve the msi-parent physical address and we store it > in our internal PCIe register locations... Ah, thanks for the clarification, I missed that part. > So we do not operate directly on the msi controller registers... > > So I wonder if the current implementation is Ok to retrieve the > msi-parent address.... Not sure. Why do you do this? Normally the PCI host does not know or care about the address of the MSI controller, because the messages are just passed up to the parent bus as DMA transfers. I don't think what you do here is safe because the 'reg' property of the MSI controller might point to the address that is used for the message directly. Arnd