* Re: [GIT PULL v2] DT/core: cpu_ofnode updates for v3.12
From: Rafael J. Wysocki @ 2013-08-22 23:12 UTC (permalink / raw)
To: Sudeep KarkadaNagesha
Cc: Jonas Bonn, devicetree@vger.kernel.org, monstr@monstr.eu,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
rob.herring@calxeda.com, arm@kernel.org, Viresh Kumar,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <521618E4.4020007@arm.com>
On Thursday, August 22, 2013 02:57:56 PM Sudeep KarkadaNagesha wrote:
> Hi Rafael,
>
> Here is the v2 of the pull request for cpu of_node updates for v3.12
> It includes ACK for all the new changes since v1(mainly from Ben for
> PPC). Currently there's trivial conflict with today's linux-next in 3
> files. Let me know if you need me to rebase this on any particular
> branch if needed.
>
> Regards,
> Sudeep
>
> The following changes since commit b36f4be3de1b123d8601de062e7dbfc904f305fb:
>
> Linux 3.11-rc6 (2013-08-18 14:36:53 -0700)
>
> are available in the git repository at:
>
> git://linux-arm.org/linux-skn.git cpu_of_node
>
> for you to fetch changes up to 1037b2752345cc5666e90b711a913ab2ae6c5920:
>
> cpufreq: pmac32-cpufreq: remove device tree parsing for cpu nodes
> (2013-08-21 10:29:56 +0100)
>
> ----------------------------------------------------------------
> Sudeep KarkadaNagesha (19):
> microblaze: remove undefined of_get_cpu_node declaration
> openrisc: remove undefined of_get_cpu_node declaration
> powerpc: refactor of_get_cpu_node to support other architectures
> of: move of_get_cpu_node implementation to DT core library
> ARM: DT/kernel: define ARM specific arch_match_cpu_phys_id
> driver/core: cpu: initialize of_node in cpu's device struture
> of/device: add helper to get cpu device node from logical cpu index
> ARM: topology: remove hwid/MPIDR dependency from cpu_capacity
> ARM: mvebu: remove device tree parsing for cpu nodes
> drivers/bus: arm-cci: avoid parsing DT for cpu device nodes
> cpufreq: imx6q-cpufreq: remove device tree parsing for cpu nodes
> cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes
> cpufreq: highbank-cpufreq: remove device tree parsing for cpu nodes
> cpufreq: spear-cpufreq: remove device tree parsing for cpu nodes
> cpufreq: kirkwood-cpufreq: remove device tree parsing for cpu nodes
> cpufreq: arm_big_little: remove device tree parsing for cpu nodes
> cpufreq: maple-cpufreq: remove device tree parsing for cpu nodes
> cpufreq: pmac64-cpufreq: remove device tree parsing for cpu nodes
> cpufreq: pmac32-cpufreq: remove device tree parsing for cpu nodes
>
> arch/arm/kernel/devtree.c | 5 ++
> arch/arm/kernel/topology.c | 61 +++++-----------
> arch/arm/mach-imx/mach-imx6q.c | 3 +-
> arch/arm/mach-mvebu/platsmp.c | 51 ++++++-------
> arch/microblaze/include/asm/prom.h | 3 -
> arch/openrisc/include/asm/prom.h | 3 -
> arch/powerpc/include/asm/prom.h | 3 -
> arch/powerpc/kernel/prom.c | 43 +-----------
> drivers/base/cpu.c | 2 +
> drivers/bus/arm-cci.c | 28 ++------
> drivers/cpufreq/arm_big_little_dt.c | 40 ++++-------
> drivers/cpufreq/cpufreq-cpu0.c | 23 +-----
> drivers/cpufreq/highbank-cpufreq.c | 18 ++---
> drivers/cpufreq/imx6q-cpufreq.c | 4 +-
> drivers/cpufreq/kirkwood-cpufreq.c | 8 ++-
> drivers/cpufreq/maple-cpufreq.c | 23 +-----
> drivers/cpufreq/pmac32-cpufreq.c | 5 +-
> drivers/cpufreq/pmac64-cpufreq.c | 47 +++---------
> drivers/cpufreq/spear-cpufreq.c | 4 +-
> drivers/of/base.c | 95 ++++++++++++++++++++++++
> include/linux/cpu.h | 1 +
> include/linux/of.h | 7 ++
> include/linux/of_device.h | 15 ++++
> 23 files changed, 226 insertions(+), 266 deletions(-)
Pulled, thanks!
^ permalink raw reply
* Detecting LD/ST instruction
From: Sukadev Bhattiprolu @ 2013-08-22 22:55 UTC (permalink / raw)
To: linuxppc-dev
I am working on implementing the 'perf mem' command for Power
systems. This would for instance, let us know where in the memory
hierarchy (L1, L2, Local RAM etc) the data for a load/store
instruction was found (hit).
On Power7, if the mcmcra[DCACHE_MISS] is clear _and_ the
instruction is a load/store, then it implies a L1-hit.
Unlike on Power8, the Power7 event vector has no indication
if the instruction was load/store.
In the context of a PMU interrupt, is there any way to determine
if an instruction is a load/store ?
Sukadev
^ permalink raw reply
* Re: [PATCH v5 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
From: Tomasz Figa @ 2013-08-22 22:49 UTC (permalink / raw)
To: Mike Turquette
Cc: Mark Rutland, devicetree@vger.kernel.org,
alsa-devel@alsa-project.org, lars@metafoo.de,
ian.campbell@citrix.com, Pawel Moll, swarren@wwwdotorg.org,
festevam@gmail.com, Sascha Hauer, Nicolin Chen, timur@tabi.org,
rob.herring@calxeda.com, broonie@kernel.org,
p.zabel@pengutronix.de, galak@codeaurora.org,
shawn.guo@linaro.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130822224331.8231.75743@quantum>
On Thursday 22 of August 2013 15:43:31 Mike Turquette wrote:
> Quoting Sascha Hauer (2013-08-22 14:00:35)
>
> > On Thu, Aug 22, 2013 at 01:09:31PM +0100, Mark Rutland wrote:
> > > On Thu, Aug 22, 2013 at 08:19:10AM +0100, Mike Turquette wrote:
> > > > Quoting Tomasz Figa (2013-08-21 14:34:55)
> > > >
> > > > > On Wednesday 21 of August 2013 09:50:15 Mark Rutland wrote:
> > > > > > On Tue, Aug 20, 2013 at 01:06:25AM +0100, Mike Turquette
wrote:
> > > > > > > Quoting Mark Rutland (2013-08-19 02:35:43)
> > > > > > >
> > > > > > > > On Sat, Aug 17, 2013 at 04:17:18PM +0100, Tomasz Figa
wrote:
> > > > > > > > > On Saturday 17 of August 2013 16:53:16 Sascha Hauer
wrote:
> > > > > > > > > > On Sat, Aug 17, 2013 at 02:28:04PM +0200, Tomasz Figa
wrote:
> > > > > > > > > > > > > > Also I would make this option required. Use a
> > > > > > > > > > > > > > dummy
> > > > > > > > > > > > > > clock for
> > > > > > > > > > > > > > mux
> > > > > > > > > > > > > > inputs that are grounded for a specific SoC.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Some clocks are not from CCM and we haven't
> > > > > > > > > > > > > defined in
> > > > > > > > > > > > > imx6q-clk.txt,
> > > > > > > > > > > > > so in most cases we can't provide a phandle for
> > > > > > > > > > > > > them, eg:
> > > > > > > > > > > > > spdif_ext.
> > > > > > > > > > > > > I think it's a bit hard to force it to be
> > > > > > > > > > > > > 'required'. An
> > > > > > > > > > > > > 'optional'
> > > > > > > > > > > > > looks more flexible to me and a default one is
> > > > > > > > > > > > > ensured
> > > > > > > > > > > > > even if
> > > > > > > > > > > > > it's
> > > > > > > > > > > > > missing.
> > > > > > > > > > > >
> > > > > > > > > > > > <&clks 0> is the dummy clock. This can be used for
> > > > > > > > > > > > all input
> > > > > > > > > > > > clocks
> > > > > > > > > > > > not
> > > > > > > > > > > > defined by the SoC.
> > > > > > > > > > >
> > > > > > > > > > > Where does this assumption come from? Is it
> > > > > > > > > > > documented
> > > > > > > > > > > anywhere?
> > > > > > > > > >
> > > > > > > > > > This is how all i.MX clock bindings currently are. See
> > > > > > > > > > Documentation/devicetree/bindings/clock/imx*-clock.txt
> > > > > > > > >
> > > > > > > > > OK, thanks.
> > > > > > > > >
> > > > > > > > > I guess we need some discussion on dummy clocks vs
> > > > > > > > > skipped clocks.
> > > > > > > > > I think we want some consistency on this, don't we?
> > > > > > > > >
> > > > > > > > > If we really need a dummy clock, then we might also want
> > > > > > > > > a generic
> > > > > > > > > way to specify it.
> > > > > > > >
> > > > > > > > What do we actually mean by a "dummy clock"? We already
> > > > > > > > have
> > > > > > > > bindings
> > > > > > > > for "fixed-clock" and co friends describe relatively
> > > > > > > > simple
> > > > > > > > preconfigured clocks.
> > > > > > >
> > > > > > > Some platforms have a fake clock which defines noops
> > > > > > > callbacks and
> > > > > > > basically doesn't do anything. This is analogous to the
> > > > > > > dummy
> > > > > > > regulator
> > > > > > > implementation. A central one could be registered by the
> > > > > > > clock core,
> > > > > > > as
> > > > > > > is done by the regulator core.
> > > > > >
> > > > > > When you say some platforms, you presumably mean the platform
> > > > > > code in
> > > > > > Linux? A dummy clock sounds like a completely Linux-specific
> > > > > > abstraction rather than a description of the hardware, and I
> > > > > > don't see why we need that in the DT:
> > > > > >
> > > > > > * If a clock is wired up and running (as presumably the dummy
> > > > > > clock is), then surely it's a fixed-clock (it's running, we
> > > > > > and we have no control over it, but we presumably know its
> > > > > > rate) and can be described as such?
> > > > > >
> > > > > > * If no clock is wired up, then we should be able to describe
> > > > > > that. If a driver believes that a clock is required when it
> > > > > > isn't (for some level of functionality), then that driver
> > > > > > should be fixed up to support the clock as being optional.
> > > > > >
> > > > > > Am I missing something?
> > > > >
> > > > > I second that.
> > > > >
> > > > > Moreover, I don't think that device tree should deal with dummy
> > > > > anything. It should be able to describe hardware that is
> > > > > available on given system, not list what hardware is not
> > > > > available.
> > > >
> > > > I wasn't clear. The dummy clock IS a completely Linux-specific
> > > > abstraction.
> > > >
> > > > I'm not advocating a dummy clock in DT. I am advocating
> > > > consolidation of the implementation of a clock that does nothing
> > > > into the clock core. This code could easily live in
> > > > drivers/clk/clk.c instead of having everyone open-code it.
> > > >
> > > > As far as specifying a dummy clock in DT? I dunno. DT should
> > > > describe
> > > > real hardware so there isn't much use for a dummy clock.
> > >
> > > Sorry, I misunderstood. Good to hear we're on the same page :)
> > >
> > > > I'm guessing one of the reasons for such a clock are drivers do
> > > > not
> > > > honor the clk.h api and they freak out when clk_get gives them a
> > > > NULL
> > > > pointer?
> > >
> > > I'm not sure. Sascha, could you shed some light on the matter?
> >
> > The original reason introducing the dummy clocks in the i.MX dtbs
> > was to provide devices a clock which the driver requests but is
> > not software controllable. We often have the case where the same
> > devices are on several SoCs, but not on all of them all clocks have
> > a bit to en/disable them.
> >
> > Anyway, to accomplish this we don't need dummy clocks. We can just
> > describe the real clocks.
>
> You could use a dummy clk for the Linux implementation, but the downside
> is that a dummy clock has a rate of 0 always and a your clocks likely
> have non-zero rates.
>
> It is probably better for you define a clock which only implements the
> .recalc_rate callback. If the rate of this clock changes without Linux
> having knowledge of it you can use the CLK_GET_RATE_NOCACHE flag.
I doubt that rate of a dummy clock could ever change... unless it is a
rather smart dummy.
> > BTW with the S/PDIF core on which not all mux inputs are connected
> > to actual clocks we could also describe the unconnected inputs as
> > ground clocks with rate 0. This way we describe something which
> > is really there instead of dummy clocks ;)
>
> Again you could use a dummy clock for this OR a fixed-rate clock with a
> rate of zero from the perspective of the Linux implementation.
>
> Do you think it worthwhile to have a DT binding for a grounded clock?
> That is not an entirely uncommon case.
Well, how would that differ from skipping a clock from clocks list, i.e.
not specifying it in clock-names and clocks properties?
> > Background to why it might be a good idea to connect a ground clock
> > to the unconnected input pins is that a driver has a chance to
> > successfully grab all clocks. Otherwise how does the driver
> > distinguish
> > between an unconnected and an erroneous clock?
>
> Sorry, I don't follow this last question. Do you mean how to distinguish
> based on the value returned from clk_get?
Hmm, in theory, a driver could want to distinguish an error case (e.g.
clock specified, but there is a problem with it) from no clock (e.g. clock
not specified in DT, because it is not available on particular board).
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH v5 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
From: Mike Turquette @ 2013-08-22 22:43 UTC (permalink / raw)
To: Sascha Hauer, Mark Rutland
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
lars@metafoo.de, ian.campbell@citrix.com, Pawel Moll,
swarren@wwwdotorg.org, festevam@gmail.com, Nicolin Chen,
Tomasz Figa, rob.herring@calxeda.com, timur@tabi.org,
broonie@kernel.org, p.zabel@pengutronix.de, galak@codeaurora.org,
shawn.guo@linaro.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130822210035.GB31036@pengutronix.de>
Quoting Sascha Hauer (2013-08-22 14:00:35)
> On Thu, Aug 22, 2013 at 01:09:31PM +0100, Mark Rutland wrote:
> > On Thu, Aug 22, 2013 at 08:19:10AM +0100, Mike Turquette wrote:
> > > Quoting Tomasz Figa (2013-08-21 14:34:55)
> > > > On Wednesday 21 of August 2013 09:50:15 Mark Rutland wrote:
> > > > > On Tue, Aug 20, 2013 at 01:06:25AM +0100, Mike Turquette wrote:
> > > > > > Quoting Mark Rutland (2013-08-19 02:35:43)
> > > > > > =
> > > > > > > On Sat, Aug 17, 2013 at 04:17:18PM +0100, Tomasz Figa wrote:
> > > > > > > > On Saturday 17 of August 2013 16:53:16 Sascha Hauer wrote:
> > > > > > > > > On Sat, Aug 17, 2013 at 02:28:04PM +0200, Tomasz Figa wro=
te:
> > > > > > > > > > > > > Also I would make this option required. Use a dum=
my
> > > > > > > > > > > > > clock for
> > > > > > > > > > > > > mux
> > > > > > > > > > > > > inputs that are grounded for a specific SoC.
> > > > > > > > > > > > =
> > > > > > > > > > > > Some clocks are not from CCM and we haven't defined=
in
> > > > > > > > > > > > imx6q-clk.txt,
> > > > > > > > > > > > so in most cases we can't provide a phandle for the=
m, eg:
> > > > > > > > > > > > spdif_ext.
> > > > > > > > > > > > I think it's a bit hard to force it to be 'required=
'. An
> > > > > > > > > > > > 'optional'
> > > > > > > > > > > > looks more flexible to me and a default one is ensu=
red
> > > > > > > > > > > > even if
> > > > > > > > > > > > it's
> > > > > > > > > > > > missing.
> > > > > > > > > > > =
> > > > > > > > > > > <&clks 0> is the dummy clock. This can be used for al=
l input
> > > > > > > > > > > clocks
> > > > > > > > > > > not
> > > > > > > > > > > defined by the SoC.
> > > > > > > > > > =
> > > > > > > > > > Where does this assumption come from? Is it documented
> > > > > > > > > > anywhere?
> > > > > > > > > =
> > > > > > > > > This is how all i.MX clock bindings currently are. See
> > > > > > > > > Documentation/devicetree/bindings/clock/imx*-clock.txt
> > > > > > > > =
> > > > > > > > OK, thanks.
> > > > > > > > =
> > > > > > > > I guess we need some discussion on dummy clocks vs skipped =
clocks.
> > > > > > > > I think we want some consistency on this, don't we?
> > > > > > > > =
> > > > > > > > If we really need a dummy clock, then we might also want a =
generic
> > > > > > > > way to specify it.
> > > > > > > =
> > > > > > > What do we actually mean by a "dummy clock"? We already have
> > > > > > > bindings
> > > > > > > for "fixed-clock" and co friends describe relatively simple
> > > > > > > preconfigured clocks.
> > > > > > =
> > > > > > Some platforms have a fake clock which defines noops callbacks =
and
> > > > > > basically doesn't do anything. This is analogous to the dummy
> > > > > > regulator
> > > > > > implementation. A central one could be registered by the clock =
core,
> > > > > > as
> > > > > > is done by the regulator core.
> > > > > =
> > > > > When you say some platforms, you presumably mean the platform cod=
e in
> > > > > Linux? A dummy clock sounds like a completely Linux-specific abst=
raction
> > > > > rather than a description of the hardware, and I don't see why we=
need
> > > > > that in the DT:
> > > > > =
> > > > > * If a clock is wired up and running (as presumably the dummy clo=
ck is),
> > > > > then surely it's a fixed-clock (it's running, we and we have no c=
ontrol
> > > > > over it, but we presumably know its rate) and can be described as=
such?
> > > > > =
> > > > > * If no clock is wired up, then we should be able to describe tha=
t. If a
> > > > > driver believes that a clock is required when it isn't (for some =
level
> > > > > of functionality), then that driver should be fixed up to support=
the
> > > > > clock as being optional.
> > > > > =
> > > > > Am I missing something?
> > > > =
> > > > I second that.
> > > > =
> > > > Moreover, I don't think that device tree should deal with dummy any=
thing. =
> > > > It should be able to describe hardware that is available on given s=
ystem, =
> > > > not list what hardware is not available.
> > > =
> > > I wasn't clear. The dummy clock IS a completely Linux-specific
> > > abstraction.
> > > =
> > > I'm not advocating a dummy clock in DT. I am advocating consolidation=
of
> > > the implementation of a clock that does nothing into the clock core.
> > > This code could easily live in drivers/clk/clk.c instead of having
> > > everyone open-code it.
> > > =
> > > As far as specifying a dummy clock in DT? I dunno. DT should describe
> > > real hardware so there isn't much use for a dummy clock.
> > =
> > =
> > Sorry, I misunderstood. Good to hear we're on the same page :)
> > =
> > > =
> > > I'm guessing one of the reasons for such a clock are drivers do not
> > > honor the clk.h api and they freak out when clk_get gives them a NULL
> > > pointer?
> > =
> > I'm not sure. Sascha, could you shed some light on the matter?
> =
> The original reason introducing the dummy clocks in the i.MX dtbs
> was to provide devices a clock which the driver requests but is
> not software controllable. We often have the case where the same
> devices are on several SoCs, but not on all of them all clocks have
> a bit to en/disable them.
> =
> Anyway, to accomplish this we don't need dummy clocks. We can just
> describe the real clocks.
You could use a dummy clk for the Linux implementation, but the downside
is that a dummy clock has a rate of 0 always and a your clocks likely
have non-zero rates.
It is probably better for you define a clock which only implements the
.recalc_rate callback. If the rate of this clock changes without Linux
having knowledge of it you can use the CLK_GET_RATE_NOCACHE flag.
> =
> BTW with the S/PDIF core on which not all mux inputs are connected
> to actual clocks we could also describe the unconnected inputs as
> ground clocks with rate 0. This way we describe something which
> is really there instead of dummy clocks ;)
Again you could use a dummy clock for this OR a fixed-rate clock with a
rate of zero from the perspective of the Linux implementation.
Do you think it worthwhile to have a DT binding for a grounded clock?
That is not an entirely uncommon case.
> =
> Background to why it might be a good idea to connect a ground clock
> to the unconnected input pins is that a driver has a chance to
> successfully grab all clocks. Otherwise how does the driver distinguish
> between an unconnected and an erroneous clock?
Sorry, I don't follow this last question. Do you mean how to distinguish
based on the value returned from clk_get?
Regards,
Mike
> =
> Sascha
> =
> -- =
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: Ethernet over PCIe driver for Inter-Processor Communication
From: Ira W. Snyder @ 2013-08-22 22:29 UTC (permalink / raw)
To: David Hawkins; +Cc: Saravanan S, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <5216860A.6060409@ovro.caltech.edu>
On Thu, Aug 22, 2013 at 02:43:38PM -0700, David Hawkins wrote:
> Hi S.Saravanan,
>
> > I have a custom board with four MPC8640 nodes connected over
> > a transparent PCI express switch . In this configuration one node is
> > configured as host(Root Complex) and others as agents(End Point). Thus
> > the legacy PCI software works fine . However the mainline kernel lacks
> > any standard support for Inter-processor communication over PCI. I am
> > in the process of developing an Ethernet over PCI driver for the same
> > on the lines of rionet . However I am facing the following problems.
> >
> > a) I can generate MSI interrupts from End Point to Root Complex over
> > PCI . But the vice-versa is not possible . However i need a method to
> > interrupt the End Point from the Root Complex to complete my driver.
>
> Root complex's would normally interrupt a device via a PCIe write
> to a register in a BAR on the end-point (or in extended configuration
> space registers depending on the hardware implementation).
>
> > Only previous references I can find are this post
> > http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg25765.html
> > However this uses doorbells and I think may not be possible in MPC8640.
>
> PCIe drivers need some way to interrupt the processor, so there must
> be an option somewhere ... for example, what are the message register
> interrupts intended for? See p479
>
> http://cache.freescale.com/files/32bit/doc/ref_manual/MPC8641DRM.pdf
>
> (Ira and myself have not used the MPC8640 so are not familiar with
> its user manual).
>
> > Any pointers on this issue and guidance on this driver development would
> > be helpful .
>
> We use the Ethernet-over-PCI driver that Ira developed. Our next boards
> will use an MPC8308, but we don't currently have any in a PCIe device
> form-factor (just the MPC8038RDB), so he has not ported it to PCIe.
>
> Feel free to discuss your ideas for your PCIe driver (eg., why start
> with rionet rather than Ira's driver), either on-list, or email Ira
> and myself directly.
>
One further note. You might want to look at rproc/rpmsg and their virtio
driver support. That seems to be where the Linux world is moving for
inter-processor communications. See for example the ARM CPUs interfacing
with DSPs.
Ira
^ permalink raw reply
* Re: [PATCH] powerpc/p1010rdb: update phy node in dts
From: Scott Wood @ 2013-08-22 21:53 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linuxppc-dev
In-Reply-To: <1377144372-9003-1-git-send-email-Shengzhou.Liu@freescale.com>
On Thu, 2013-08-22 at 12:06 +0800, Shengzhou Liu wrote:
> Update phy node according to new P1010RDB-PB board.
>
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> ---
> arch/powerpc/boot/dts/p1010rdb.dtsi | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/p1010rdb.dtsi b/arch/powerpc/boot/dts/p1010rdb.dtsi
> index ec7c27a..da24b2d 100644
> --- a/arch/powerpc/boot/dts/p1010rdb.dtsi
> +++ b/arch/powerpc/boot/dts/p1010rdb.dtsi
> @@ -193,17 +193,17 @@
>
> mdio@24000 {
> phy0: ethernet-phy@0 {
> - interrupts = <3 1 0 0>;
> + interrupts = <0 1>;
> reg = <0x1>;
> };
>
> phy1: ethernet-phy@1 {
> - interrupts = <2 1 0 0>;
> + interrupts = <2 1>;
> reg = <0x0>;
> };
>
> phy2: ethernet-phy@2 {
> - interrupts = <2 1 0 0>;
> + interrupts = <1 1>;
> reg = <0x2>;
> };
#interrupt-cells is 4
-Scott
^ permalink raw reply
* Re: [PATCH] Device Tree bindings for DSP clusters and DSP CPUs
From: Scott Wood @ 2013-08-22 21:44 UTC (permalink / raw)
To: Poonam Aggrwal; +Cc: devicetree, linuxppc-dev
In-Reply-To: <1377077149-24347-1-git-send-email-poonam.aggrwal@freescale.com>
On Wed, 2013-08-21 at 14:55 +0530, Poonam Aggrwal wrote:
> Binding for DSP CPU clusters and DSP CPUs for Freescale SOCs which
> have DSP CPUs in addition to PowerPC CPUs. For example B4860.
>
> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> ---
> .../devicetree/bindings/powerpc/fsl/dsp-cpus.txt | 78 ++++++++++++++++++++
> 1 files changed, 78 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/dsp-cpus.txt
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dsp-cpus.txt b/Documentation/devicetree/bindings/powerpc/fsl/dsp-cpus.txt
> new file mode 100644
> index 0000000..da7f5d4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/dsp-cpus.txt
> @@ -0,0 +1,78 @@
> +===================================================================
> +Binding for DSP CPU clusters and DSP CPUs for Freescale SOCs which
> +have DSP CPUs in addition to PowerPC cpus.
> +Copyright 2013 Freescale Semiconductor Inc.
> +
> +Power Architecture CPUs in Freescale SOCs are represented in device trees as
> +per the definition in ePAPR.
> +
> +Required properties for DSP CPU cluster:
> +- compatible : should be "fsl,dsp-cluster" or "fsl,sc3900-cluster".
> +- reg : should contain the cluster index
> +
> +Required properties for DSP CPU:
> +- compatible : should be "fsl,dsp" or "fsl,sc3900".
> +- reg : should contain index of DSP CPU within the DSP clsuter.
s/clsuter/cluster/
Could you elaborate on "index of DSP CPU within the DSP cluster"? From
the examples it looks like the reg values are unique even across
clusters.
I wonder whether we should be describing this at all in the device tree
given that the topology is discoverable in registers... though that
applies to the PowerPC CPUs as well. :-)
-Scott
^ permalink raw reply
* Re: Ethernet over PCIe driver for Inter-Processor Communication
From: David Hawkins @ 2013-08-22 21:43 UTC (permalink / raw)
To: Saravanan S; +Cc: linuxppc-dev@lists.ozlabs.org, Ira W. Snyder
In-Reply-To: <CAEqOc-Rrsc2JoM4eeLzgyhGXqpJoe2Jfmf6uV4LjrTr7e8hhAw@mail.gmail.com>
Hi S.Saravanan,
> I have a custom board with four MPC8640 nodes connected over
> a transparent PCI express switch . In this configuration one node is
> configured as host(Root Complex) and others as agents(End Point). Thus
> the legacy PCI software works fine . However the mainline kernel lacks
> any standard support for Inter-processor communication over PCI. I am
> in the process of developing an Ethernet over PCI driver for the same
> on the lines of rionet . However I am facing the following problems.
>
> a) I can generate MSI interrupts from End Point to Root Complex over
> PCI . But the vice-versa is not possible . However i need a method to
> interrupt the End Point from the Root Complex to complete my driver.
Root complex's would normally interrupt a device via a PCIe write
to a register in a BAR on the end-point (or in extended configuration
space registers depending on the hardware implementation).
> Only previous references I can find are this post
> http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg25765.html
> However this uses doorbells and I think may not be possible in MPC8640.
PCIe drivers need some way to interrupt the processor, so there must
be an option somewhere ... for example, what are the message register
interrupts intended for? See p479
http://cache.freescale.com/files/32bit/doc/ref_manual/MPC8641DRM.pdf
(Ira and myself have not used the MPC8640 so are not familiar with
its user manual).
> Any pointers on this issue and guidance on this driver development would
> be helpful .
We use the Ethernet-over-PCI driver that Ira developed. Our next boards
will use an MPC8308, but we don't currently have any in a PCIe device
form-factor (just the MPC8038RDB), so he has not ported it to PCIe.
Feel free to discuss your ideas for your PCIe driver (eg., why start
with rionet rather than Ira's driver), either on-list, or email Ira
and myself directly.
Cheers,
Dave
^ permalink raw reply
* Re: Ethernet over PCIe driver for Inter-Processor Communication
From: Scott Wood @ 2013-08-22 21:38 UTC (permalink / raw)
To: Saravanan S; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAEqOc-Rrsc2JoM4eeLzgyhGXqpJoe2Jfmf6uV4LjrTr7e8hhAw@mail.gmail.com>
On Thu, 2013-08-22 at 21:04 +0530, Saravanan S wrote:
> a) I can generate MSI interrupts from End Point to Root Complex over
> PCI . But the vice-versa is not possible . However i need a method to
> interrupt the End Point from the Root Complex to complete my driver.
> Only previous references I can find are this post
> http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg25765.html . However this uses doorbells and I think may not be possible in MPC8640.
You should be able to write to the destination's MPIC registers to send
a doorbell.
-Scott
^ permalink raw reply
* Re: [RFC PATCH V3 3/5] powerpc/cpuidle: Generic powerpc backend cpuidle driver.
From: Scott Wood @ 2013-08-22 21:24 UTC (permalink / raw)
To: Deepthi Dharwar
Cc: Wood Scott-B07421, Wang Dongsheng-B40534,
daniel.lezcano@linaro.org, preeti@linux.vnet.ibm.com,
linux-pm@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <5215A69F.4090904@linux.vnet.ibm.com>
On Thu, 2013-08-22 at 11:20 +0530, Deepthi Dharwar wrote:
> On 08/22/2013 01:38 AM, Scott Wood wrote:
> > On Wed, 2013-08-21 at 10:23 +0530, Deepthi Dharwar wrote:
> >> On 08/19/2013 11:47 PM, Scott Wood wrote:
> >>> What actual functionality is common to all powerpc but not common to
> >>> other arches?
> >
>
> The functionality here is idle states on powerpc like the snooze loop
> that is common.
> Also, the basic registration of the driver, hotplug notifier etc for
> powerpc.
The snooze loop uses things like SPRN_PURR, get_lppaca(), and CTRL which
aren't common to all PPC (they might be common to all book3s64). I also
don't see any hook for the low power mode entry -- is "snooze" just a
busy loop plus the de-emphasis stuff like HMT and CTRL[RUN]? I'm not
familiar with the term "snooze" in this context. I don't think we'd use
anything like that on our chips; we'd always at least "wait" or "doze"
depending on the chip.
It's not clear what is powerpc-specific about the notifier -- perhaps it
should go in drivers/cpuidle/.
> > The way forward is to give this file a more appropriate name based on
> > the hardware that it actually targets -- and to refactor it so that the
> > answer to that question is not complicated.
>
> Sure, thanks.
> Our idea was to have POWER archs idle states merged at the first go.
> Only that is what is enabled in the current version (V4 posted out)
> ( Code is enabled for PSERIES and POWERNV only)
> If needed, other POWERPC archs might benefit by extending the same
> driver, that is why it is named cpuidle-powerpc.c
>
> But if having cpuidle backend-driver separately for other powerpc arcs
> makes sense such that each one have their own state information etc
> then it makes sense to name the files as cpuidle-power.c,
> cpuilde-ppc32.c and so on.
Thanks.
-Scott
^ permalink raw reply
* Re: [PATCH v5 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
From: Sascha Hauer @ 2013-08-22 21:00 UTC (permalink / raw)
To: Mark Rutland
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
lars@metafoo.de, Mike Turquette, ian.campbell@citrix.com,
Pawel Moll, swarren@wwwdotorg.org, festevam@gmail.com,
Nicolin Chen, Tomasz Figa, rob.herring@calxeda.com,
timur@tabi.org, broonie@kernel.org, p.zabel@pengutronix.de,
galak@codeaurora.org, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130822120930.GD9799@e106331-lin.cambridge.arm.com>
On Thu, Aug 22, 2013 at 01:09:31PM +0100, Mark Rutland wrote:
> On Thu, Aug 22, 2013 at 08:19:10AM +0100, Mike Turquette wrote:
> > Quoting Tomasz Figa (2013-08-21 14:34:55)
> > > On Wednesday 21 of August 2013 09:50:15 Mark Rutland wrote:
> > > > On Tue, Aug 20, 2013 at 01:06:25AM +0100, Mike Turquette wrote:
> > > > > Quoting Mark Rutland (2013-08-19 02:35:43)
> > > > >
> > > > > > On Sat, Aug 17, 2013 at 04:17:18PM +0100, Tomasz Figa wrote:
> > > > > > > On Saturday 17 of August 2013 16:53:16 Sascha Hauer wrote:
> > > > > > > > On Sat, Aug 17, 2013 at 02:28:04PM +0200, Tomasz Figa wrote:
> > > > > > > > > > > > Also I would make this option required. Use a dummy
> > > > > > > > > > > > clock for
> > > > > > > > > > > > mux
> > > > > > > > > > > > inputs that are grounded for a specific SoC.
> > > > > > > > > > >
> > > > > > > > > > > Some clocks are not from CCM and we haven't defined in
> > > > > > > > > > > imx6q-clk.txt,
> > > > > > > > > > > so in most cases we can't provide a phandle for them, eg:
> > > > > > > > > > > spdif_ext.
> > > > > > > > > > > I think it's a bit hard to force it to be 'required'. An
> > > > > > > > > > > 'optional'
> > > > > > > > > > > looks more flexible to me and a default one is ensured
> > > > > > > > > > > even if
> > > > > > > > > > > it's
> > > > > > > > > > > missing.
> > > > > > > > > >
> > > > > > > > > > <&clks 0> is the dummy clock. This can be used for all input
> > > > > > > > > > clocks
> > > > > > > > > > not
> > > > > > > > > > defined by the SoC.
> > > > > > > > >
> > > > > > > > > Where does this assumption come from? Is it documented
> > > > > > > > > anywhere?
> > > > > > > >
> > > > > > > > This is how all i.MX clock bindings currently are. See
> > > > > > > > Documentation/devicetree/bindings/clock/imx*-clock.txt
> > > > > > >
> > > > > > > OK, thanks.
> > > > > > >
> > > > > > > I guess we need some discussion on dummy clocks vs skipped clocks.
> > > > > > > I think we want some consistency on this, don't we?
> > > > > > >
> > > > > > > If we really need a dummy clock, then we might also want a generic
> > > > > > > way to specify it.
> > > > > >
> > > > > > What do we actually mean by a "dummy clock"? We already have
> > > > > > bindings
> > > > > > for "fixed-clock" and co friends describe relatively simple
> > > > > > preconfigured clocks.
> > > > >
> > > > > Some platforms have a fake clock which defines noops callbacks and
> > > > > basically doesn't do anything. This is analogous to the dummy
> > > > > regulator
> > > > > implementation. A central one could be registered by the clock core,
> > > > > as
> > > > > is done by the regulator core.
> > > >
> > > > When you say some platforms, you presumably mean the platform code in
> > > > Linux? A dummy clock sounds like a completely Linux-specific abstraction
> > > > rather than a description of the hardware, and I don't see why we need
> > > > that in the DT:
> > > >
> > > > * If a clock is wired up and running (as presumably the dummy clock is),
> > > > then surely it's a fixed-clock (it's running, we and we have no control
> > > > over it, but we presumably know its rate) and can be described as such?
> > > >
> > > > * If no clock is wired up, then we should be able to describe that. If a
> > > > driver believes that a clock is required when it isn't (for some level
> > > > of functionality), then that driver should be fixed up to support the
> > > > clock as being optional.
> > > >
> > > > Am I missing something?
> > >
> > > I second that.
> > >
> > > Moreover, I don't think that device tree should deal with dummy anything.
> > > It should be able to describe hardware that is available on given system,
> > > not list what hardware is not available.
> >
> > I wasn't clear. The dummy clock IS a completely Linux-specific
> > abstraction.
> >
> > I'm not advocating a dummy clock in DT. I am advocating consolidation of
> > the implementation of a clock that does nothing into the clock core.
> > This code could easily live in drivers/clk/clk.c instead of having
> > everyone open-code it.
> >
> > As far as specifying a dummy clock in DT? I dunno. DT should describe
> > real hardware so there isn't much use for a dummy clock.
>
>
> Sorry, I misunderstood. Good to hear we're on the same page :)
>
> >
> > I'm guessing one of the reasons for such a clock are drivers do not
> > honor the clk.h api and they freak out when clk_get gives them a NULL
> > pointer?
>
> I'm not sure. Sascha, could you shed some light on the matter?
The original reason introducing the dummy clocks in the i.MX dtbs
was to provide devices a clock which the driver requests but is
not software controllable. We often have the case where the same
devices are on several SoCs, but not on all of them all clocks have
a bit to en/disable them.
Anyway, to accomplish this we don't need dummy clocks. We can just
describe the real clocks.
BTW with the S/PDIF core on which not all mux inputs are connected
to actual clocks we could also describe the unconnected inputs as
ground clocks with rate 0. This way we describe something which
is really there instead of dummy clocks ;)
Background to why it might be a good idea to connect a ground clock
to the unconnected input pins is that a driver has a chance to
successfully grab all clocks. Otherwise how does the driver distinguish
between an unconnected and an erroneous clock?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v10 2/2] ASoC: fsl: Add S/PDIF machine driver
From: Mark Brown @ 2013-08-22 20:05 UTC (permalink / raw)
To: Stephen Warren
Cc: mark.rutland, devicetree, alsa-devel, lars, festevam, s.hauer,
Nicolin Chen, timur, rob.herring, tomasz.figa, p.zabel, R65777,
shawn.guo, linuxppc-dev
In-Reply-To: <52166CF0.9080402@wwwdotorg.org>
[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]
On Thu, Aug 22, 2013 at 01:56:32PM -0600, Stephen Warren wrote:
> On 08/22/2013 05:40 AM, Nicolin Chen wrote:
> > Documentation/devicetree/bindings/sound/spdif-receiver.txt
> > If I understand correctly, this doc for the dummy codec should be invalid?
> Yes, I'm not convinced that binding is a good idea; it describes
> something that often doesn't actually exist in HW. (Sometimes there's a
> real S/PDIF receiving device on board, but sometimes there's nothing
> except a jack/connector).
> It'd be useful if other DT binding maintainers could weigh in on this to
> confirm/deny my thoughts.
I think the binding should be changed to replace the word "dummy" with
"generic" and perhaps some verbiage about not requiring software
configuration. I think given the unidirectional nature of S/PDIF it's
reasonable to represent a jack like this - the hardware can't generally
tell if there's anything at the other end of the link anyway, for all
pratical purposes the transmit end just has to blindly send.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v10 2/2] ASoC: fsl: Add S/PDIF machine driver
From: Stephen Warren @ 2013-08-22 19:56 UTC (permalink / raw)
To: Nicolin Chen
Cc: mark.rutland, devicetree, alsa-devel, lars, festevam, s.hauer,
timur, rob.herring, tomasz.figa, broonie, p.zabel, R65777,
shawn.guo, linuxppc-dev
In-Reply-To: <20130822114027.GA4258@MrMyself>
On 08/22/2013 05:40 AM, Nicolin Chen wrote:
> Hi Stephen,
>
> On Wed, Aug 21, 2013 at 12:30:59PM -0600, Stephen Warren wrote:
>> I still don't think those two properties are correct.
>>
>> Exactly what node will those phandles point at?
>>
>> There definitely should not be a DT node for any "dummy CODEC",
>> irrespective of whether this binding calls the other node a "CODEC" or a
>> "dummy CODEC".
>>
>> If these properties are to contain phandles, it would be acceptable for
>> the referenced node to be:
>>
>> * A node representing the physical connector/jack on the board.
>>
>> * A node representing some other IP block on the board, such as an HDMI
>> encoder/display-controller
>>
>> I think those options are unlikely in general, so I think instead these
>> properties should just be Boolean indicating that "something" is
>> connector to the S/PDIF RX/TX, without specifying what that "something"
>> is. It doesn't matter what at least in the connector/jack case, although
>> perhaps it does in the HDMI encoder/display-controller?
>
> Documentation/devicetree/bindings/sound/spdif-receiver.txt
> If I understand correctly, this doc for the dummy codec should be invalid?
Yes, I'm not convinced that binding is a good idea; it describes
something that often doesn't actually exist in HW. (Sometimes there's a
real S/PDIF receiving device on board, but sometimes there's nothing
except a jack/connector).
It'd be useful if other DT binding maintainers could weigh in on this to
confirm/deny my thoughts.
> But this patch, the spdif machine driver, is based on this codec driver,
> pls check the following code:
>
> 164 + codec_rx_np = of_parse_phandle(np, "spdif-receiver", 0);
> 165 + if (codec_rx_np) {
> 169 + data->dai[num_links].codec_of_node = codec_rx_np;
> 173 + }
>
> Accordingly, the binding I planned to add in DT:
>
> 27 + spdif_rx_codec: spdif-receiver {
> 28 + compatible = "linux,spdif-dir";
> 29 + };
> 30 +
> 31 + sound-spdif {
> 32 + compatible = "fsl,imx-audio-spdif",
> 33 + "fsl,imx-sabreauto-spdif";
> 34 + model = "imx-spdif";
> 35 + spdif-controller = <&spdif>;
> 37 + spdif-receiver = <&spdif_rx_codec>;
> 38 + };
>
> So if the DT can't allow me to include this codec node, how could I
> handle it in the current baseline.
I would expect the machine driver's probe routine to create the dummy
S/PDIF receiver object itself, and register it by calling
snd_soc_register_codec(). That way, only the machine driver code need
know it (dummy CODEC) exists.
^ permalink raw reply
* Re: [RFC PATCH v2 3/4] powerpc: refactor of_get_cpu_node to support other architectures
From: Sudeep KarkadaNagesha @ 2013-08-22 16:51 UTC (permalink / raw)
To: Mark Rutland
Cc: Jonas Bonn, devicetree@vger.kernel.org, Michal Simek,
Lorenzo Pieralisi, linux-pm@vger.kernel.org,
Sudeep KarkadaNagesha, Tomasz Figa, rob.herring@calxeda.com,
linux-kernel@vger.kernel.org, Rafael J. Wysocki, Rob Herring,
grant.likely@linaro.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20130822135930.GC23152@e106331-lin.cambridge.arm.com>
On 22/08/13 14:59, Mark Rutland wrote:
> On Mon, Aug 19, 2013 at 02:56:10PM +0100, Sudeep KarkadaNagesha wrote:
>> On 19/08/13 14:02, Rob Herring wrote:
>>> On 08/19/2013 05:19 AM, Mark Rutland wrote:
>>>> On Sat, Aug 17, 2013 at 11:09:36PM +0100, Benjamin Herrenschmidt wrote=
:
>>>>> On Sat, 2013-08-17 at 12:50 +0200, Tomasz Figa wrote:
>>>>>> I wonder how would this handle uniprocessor ARM (pre-v7) cores, for
>>>>>> which=20
>>>>>> the updated bindings[1] define #address-cells =3D <0> and so no reg=
=20
>>>>>> property.
>>>>>>
>>>>>> [1] - http://thread.gmane.org/gmane.linux.ports.arm.kernel/260795
>>>>>
>>>>> Why did you do that in the binding ? That sounds like looking to crea=
te
>>>>> problems ...=20
>>>>>
>>>>> Traditionally, UP setups just used "0" as the "reg" property on other
>>>>> architectures, why do differently ?
>>>>
>>>> The decision was taken because we defined our reg property to refer to
>>>> the MPIDR register's Aff{2,1,0} bitfields, and on UP cores before v7
>>>> there's no MPIDR register at all. Given there can only be a single CPU
>>>> in that case, describing a register that wasn't present didn't seem
>>>> necessary or helpful.
>>>
>>> What exactly reg represents is up to the binding definition, but it
>>> still should be present IMO. I don't see any issue with it being
>>> different for pre-v7.
>>>
>> Yes it's better to have 'reg' with value 0 than not having it.
>> Otherwise this generic of_get_cpu_node implementation would need some
>> _hack_ to handle that case.
>=20
> I'm not sure that having some code to handle a difference in standard
> between two architectures is a hack. If anything, I'd argue encoding a
> reg of 0 that corresponds to a nonexistent MPIDR value (given that's
> what the reg property is defined to map to on ARM) is more of a hack ;)
>=20
Agreed. But I am more confused.
1. This raises another question as how much do we follow from ePAPR
standard. ePAPR marks the reg property in /cpu as required.
Does that mean we must have all the properties marked as required to be
present in DT ? On the contrary timebase/clock-frequency is some thing
that can be found dynamically and need not be present but they are
marked as required too.
> I'm not averse to having a reg value of 0 for this case, but given that
> there are existing devicetrees without it, requiring a reg property will
> break compatibility with them.
>=20
2. What exactly does backward compatibility has to cover ? This can't be
considered as breaking of the binding definition. In continuation to the
above argument that reg property is required, do we need to cover this
as it's clearly a case of missing required property(this holds only if
reg is required always).
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH] powerpc/kvm: Handle the boundary condition correctly
From: Alexander Graf @ 2013-08-22 16:48 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: paulus, linuxppc-dev, kvm-ppc
In-Reply-To: <1377171479-25738-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On 22.08.2013, at 12:37, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Isn't this you?
>=20
> We should be able to copy upto count bytes
Why?
Alex
>=20
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
> arch/powerpc/kvm/book3s_64_mmu_hv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c =
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> index 710d313..0ae6bb6 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> @@ -1362,7 +1362,7 @@ static ssize_t kvm_htab_read(struct file *file, =
char __user *buf,
> lbuf =3D (unsigned long __user *)buf;
>=20
> nb =3D 0;
> - while (nb + sizeof(hdr) + HPTE_SIZE < count) {
> + while (nb + sizeof(hdr) + HPTE_SIZE <=3D count) {
> /* Initialize header */
> hptr =3D (struct kvm_get_htab_header __user *)buf;
> hdr.n_valid =3D 0;
> @@ -1385,7 +1385,7 @@ static ssize_t kvm_htab_read(struct file *file, =
char __user *buf,
> /* Grab a series of valid entries */
> while (i < kvm->arch.hpt_npte &&
> hdr.n_valid < 0xffff &&
> - nb + HPTE_SIZE < count &&
> + nb + HPTE_SIZE <=3D count &&
> record_hpte(flags, hptp, hpte, revp, 1, =
first_pass)) {
> /* valid entry, write it out */
> ++hdr.n_valid;
> --=20
> 1.8.1.2
>=20
^ permalink raw reply
* Re: [PATCH] powerpc/kvm: Copy the pvr value after memset
From: Alexander Graf @ 2013-08-22 16:47 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: paulus, linuxppc-dev, kvm-ppc
In-Reply-To: <1377171519-25900-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On 22.08.2013, at 12:38, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>=20
> Otherwise we would clear the pvr value
>=20
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Thanks, applied to kvm-ppc-queue. Next time please do whitespace changes =
in a separate patch.
Alex
> ---
> arch/powerpc/kvm/book3s_hv.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/book3s_hv.c =
b/arch/powerpc/kvm/book3s_hv.c
> index 2efa9dd..dd1b72c 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -680,13 +680,12 @@ static int kvmppc_handle_exit(struct kvm_run =
*run, struct kvm_vcpu *vcpu,
> }
>=20
> int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
> - struct kvm_sregs *sregs)
> + struct kvm_sregs *sregs)
> {
> int i;
>=20
> - sregs->pvr =3D vcpu->arch.pvr;
> -
> memset(sregs, 0, sizeof(struct kvm_sregs));
> + sregs->pvr =3D vcpu->arch.pvr;
> for (i =3D 0; i < vcpu->arch.slb_max; i++) {
> sregs->u.s.ppc64.slb[i].slbe =3D =
vcpu->arch.slb[i].orige;
> sregs->u.s.ppc64.slb[i].slbv =3D =
vcpu->arch.slb[i].origv;
> @@ -696,7 +695,7 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu =
*vcpu,
> }
>=20
> int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
> - struct kvm_sregs *sregs)
> + struct kvm_sregs *sregs)
> {
> int i, j;
>=20
> --=20
> 1.8.1.2
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/iommu: check dev->iommu_group before remove a device from iommu_group
From: Alex Williamson @ 2013-08-22 16:17 UTC (permalink / raw)
To: Wei Yang; +Cc: Alexey Kardashevskiy, paulus, benh, linuxppc-dev, linux-kernel
In-Reply-To: <20130822154107.GC7393@weiyang.vnet.ibm.com>
On Thu, 2013-08-22 at 23:41 +0800, Wei Yang wrote:
> On Thu, Aug 22, 2013 at 09:28:23AM -0600, Alex Williamson wrote:
> >On Thu, 2013-08-22 at 15:52 +0800, Wei Yang wrote:
> >> On Thu, Aug 22, 2013 at 05:23:34PM +1000, Alexey Kardashevskiy wrote:
> >> >On 08/19/2013 11:55 AM, Wei Yang wrote:
> >> >> On Mon, Aug 19, 2013 at 11:39:49AM +1000, Alexey Kardashevskiy wrote:
> >> >>> On 08/19/2013 11:29 AM, Wei Yang wrote:
> >> >>>> On Fri, Aug 16, 2013 at 08:15:36PM +1000, Alexey Kardashevskiy wrote:
> >> >>>>> On 08/16/2013 08:08 PM, Wei Yang wrote:
> >> >>>>>> ---
> >> >>>>>> arch/powerpc/kernel/iommu.c | 3 ++-
> >> >>>>>> 1 files changed, 2 insertions(+), 1 deletions(-)
> >> >>>>>>
> >> >>>>>> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> >> >>>>>> index b20ff17..5abf7c3 100644
> >> >>>>>> --- a/arch/powerpc/kernel/iommu.c
> >> >>>>>> +++ b/arch/powerpc/kernel/iommu.c
> >> >>>>>> @@ -1149,7 +1149,8 @@ static int iommu_bus_notifier(struct notifier_block *nb,
> >> >>>>>> case BUS_NOTIFY_ADD_DEVICE:
> >> >>>>>> return iommu_add_device(dev);
> >> >>>>>> case BUS_NOTIFY_DEL_DEVICE:
> >> >>>>>> - iommu_del_device(dev);
> >> >>>>>> + if (dev->iommu_group)
> >> >>>>>> + iommu_del_device(dev);
> >> >>>>>> return 0;
> >> >>>>>> default:
> >> >>>>>> return 0;
> >> >>>>>>
> >> >>>>>
> >> >>>>> This one seems redundant, no?
> >> >>>>
> >> >>>> Sorry for the late.
> >> >>>>
> >> >>>> Yes, these two patches have the same purpose to guard the system, while in two
> >> >>>> different places. One is in powernv platform, the other is in the generic iommu
> >> >>>> driver.
> >> >>>>
> >> >>>> The one in powernv platform is used to correct the original logic.
> >> >>>>
> >> >>>> The one in generic iommu driver is to keep system safe in case other platform to
> >> >>>> call iommu_group_remove_device() without the check.
> >> >>>
> >> >>>
> >> >>> But I am moving bus notifier to powernv code (posted a patch last week,
> >> >>> otherwise Freescale's IOMMU conflicted) so this won't be the case.
> >> >>
> >> >> Yes, I see the patch.
> >> >>
> >> >> This means other platforms, besides powernv, will check the dev->iommu_group
> >> >> before remove the device? This would be a convention?
> >> >>
> >> >> If this is the case, the second patch is enough. We don't need to check it in
> >> >> generic iommu driver.
> >> >>
> >> >> Since I am not very familiar with the code convention, I post these two
> >> >> patches together. This doesn't mean I need to push both of them. Your comments
> >> >> are welcome, lets me understand which one is more suitable in this case.
> >> >
> >> >
> >> >Ok. So. I included the check in the bus notifier which I moved to powernv
> >> >platform, I guess I'll repost the series soon.
> >>
> >> Thanks, this check will guard the powernv platform.
> >>
> >> >
> >> >Good luck with pushing the fix for drivers/iommu/iommu.c :)
> >> >
> >>
> >> Alex,
> >>
> >> Sorry for not including you in the very beginning, which may spend you more
> >> efforts to track previous mails in this thread.
> >>
> >> Do you think it is reasonable to check the dev->iommu_group in
> >> iommu_group_remove_device()? Or we can count on the bus notifier to check it?
> >>
> >> Welcome your suggestions~
> >
> >I don't really see the point of patch 1/2. iommu_group_remove_device()
> >is specifically to remove a device from an iommu_group, so why would you
> >call it on a device that's not part of an iommu_group. If you want to
> >avoid testing dev->iommu_group, then implement the .remove_device
> >callback rather than using the notifier. Thanks,
> >
>
> You mean the .remove_device like intel_iommu_remove_device()?
>
> Hmm... this function didn't check the dev->iommu_group and just call
> iommu_group_remove_device(). I see this guard is put in iommu_bus_notifier(),
> which will check dev->iommu_group before invoke .remove_device.
>
> Let me explain the case to triger the problem a little.
>
> On some platform, like powernv, we implement another bus notifier when devices
> are added or removed in the system. Like Alexey mentioned, he missed the check
> for dev->iommu_group in the notifier before removing it from iommu_group. This
> trigger the crash.
>
> So do you think it is reasonable to guard the kernel in
> iommu_group_remove_device(), or we give the platform developers the
> responsibility to check the dev->iommu_group before calling it?
I don't see it as we need either patch 1/2 or patch 2/2. We absolutely
need some form of patch 2/2. Patch 1/2 isn't necessarily bad, but it
facilitates sloppy usage. The iommu driver shouldn't be calling
iommu_group_remove_device() on arbitrary devices that may or may not be
part of an iommu_group. Perhaps patch 1/2 should be:
if (WARN_ON(!group))
return;
Thanks,
Alex
^ permalink raw reply
* [PATCH V3] i2c: move of helpers into the core
From: Wolfram Sang @ 2013-08-22 16:00 UTC (permalink / raw)
To: linux-i2c
Cc: devel, devicetree, davinci-linux-open-source, linux-samsung-soc,
alsa-devel, linux-doc, Wolfram Sang, linux-kernel, dri-devel,
linux-acpi, linux-tegra, linux-omap, linuxppc-dev,
linux-arm-kernel, linux-media
I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
that it is much cleaner to have this in the core. This also removes a
circular dependency between the helpers and the core, and so we can
finally register child nodes in the core instead of doing this manually
in each driver. So, fix the drivers and documentation, too.
Acked-by: Rob Herring <rob.herring@calxeda.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
---
V2->V3: Was trying to be too smart by only fixing includes needed.
Took a more general approach this time, converting of_i2c.h
to i2c.h in case i2c.h was not already there. Otherwise
remove it. Improved my build scripts and no build failures,
no complaints from buildbot as well.
Documentation/acpi/enumeration.txt | 1 -
arch/powerpc/platforms/44x/warp.c | 1 -
drivers/gpu/drm/tilcdc/tilcdc_slave.c | 1 -
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 1 -
drivers/gpu/host1x/drm/output.c | 2 +-
drivers/i2c/busses/i2c-at91.c | 3 -
drivers/i2c/busses/i2c-cpm.c | 6 --
drivers/i2c/busses/i2c-davinci.c | 2 -
drivers/i2c/busses/i2c-designware-platdrv.c | 2 -
drivers/i2c/busses/i2c-gpio.c | 3 -
drivers/i2c/busses/i2c-i801.c | 2 -
drivers/i2c/busses/i2c-ibm_iic.c | 4 -
drivers/i2c/busses/i2c-imx.c | 3 -
drivers/i2c/busses/i2c-mpc.c | 2 -
drivers/i2c/busses/i2c-mv64xxx.c | 3 -
drivers/i2c/busses/i2c-mxs.c | 3 -
drivers/i2c/busses/i2c-nomadik.c | 3 -
drivers/i2c/busses/i2c-ocores.c | 3 -
drivers/i2c/busses/i2c-octeon.c | 3 -
drivers/i2c/busses/i2c-omap.c | 3 -
drivers/i2c/busses/i2c-pnx.c | 3 -
drivers/i2c/busses/i2c-powermac.c | 9 +-
drivers/i2c/busses/i2c-pxa.c | 2 -
drivers/i2c/busses/i2c-s3c2410.c | 2 -
drivers/i2c/busses/i2c-sh_mobile.c | 2 -
drivers/i2c/busses/i2c-sirf.c | 3 -
drivers/i2c/busses/i2c-stu300.c | 2 -
drivers/i2c/busses/i2c-tegra.c | 3 -
drivers/i2c/busses/i2c-versatile.c | 2 -
drivers/i2c/busses/i2c-wmt.c | 3 -
drivers/i2c/busses/i2c-xiic.c | 3 -
drivers/i2c/i2c-core.c | 109 +++++++++++++++++++++-
drivers/i2c/i2c-mux.c | 3 -
drivers/i2c/muxes/i2c-arb-gpio-challenge.c | 1 -
drivers/i2c/muxes/i2c-mux-gpio.c | 1 -
drivers/i2c/muxes/i2c-mux-pinctrl.c | 1 -
drivers/media/platform/exynos4-is/fimc-is-i2c.c | 4 +-
drivers/media/platform/exynos4-is/fimc-is.c | 2 +-
drivers/media/platform/exynos4-is/media-dev.c | 1 -
drivers/of/Kconfig | 6 --
drivers/of/Makefile | 1 -
drivers/of/of_i2c.c | 114 -----------------------
drivers/staging/imx-drm/imx-tve.c | 2 +-
include/linux/i2c.h | 20 ++++
include/linux/of_i2c.h | 46 ---------
sound/soc/fsl/imx-sgtl5000.c | 2 +-
sound/soc/fsl/imx-wm8962.c | 2 +-
47 files changed, 138 insertions(+), 262 deletions(-)
delete mode 100644 drivers/of/of_i2c.c
delete mode 100644 include/linux/of_i2c.h
diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt
index d9be7a9..958266e 100644
--- a/Documentation/acpi/enumeration.txt
+++ b/Documentation/acpi/enumeration.txt
@@ -238,7 +238,6 @@ An I2C bus (controller) driver does:
if (ret)
/* handle error */
- of_i2c_register_devices(adapter);
/* Enumerate the slave devices behind this bus via ACPI */
acpi_i2c_register_devices(adapter);
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
index 4cfa499..534574a 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -16,7 +16,6 @@
#include <linux/interrupt.h>
#include <linux/delay.h>
#include <linux/of_gpio.h>
-#include <linux/of_i2c.h>
#include <linux/slab.h>
#include <linux/export.h>
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index dfffaf0..a19f657 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -16,7 +16,6 @@
*/
#include <linux/i2c.h>
-#include <linux/of_i2c.h>
#include <linux/pinctrl/pinmux.h>
#include <linux/pinctrl/consumer.h>
#include <drm/drm_encoder_slave.h>
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index 925c7cd..c38b56b 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -16,7 +16,6 @@
*/
#include <linux/i2c.h>
-#include <linux/of_i2c.h>
#include <linux/gpio.h>
#include <linux/of_gpio.h>
#include <linux/pinctrl/pinmux.h>
diff --git a/drivers/gpu/host1x/drm/output.c b/drivers/gpu/host1x/drm/output.c
index 8140fc6..137ae81 100644
--- a/drivers/gpu/host1x/drm/output.c
+++ b/drivers/gpu/host1x/drm/output.c
@@ -9,7 +9,7 @@
#include <linux/module.h>
#include <linux/of_gpio.h>
-#include <linux/of_i2c.h>
+#include <linux/i2c.h>
#include "drm.h"
diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 6bb839b..fd05930 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -28,7 +28,6 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_device.h>
-#include <linux/of_i2c.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
#include <linux/platform_data/dma-atmel.h>
@@ -775,8 +774,6 @@ static int at91_twi_probe(struct platform_device *pdev)
return rc;
}
- of_i2c_register_devices(&dev->adapter);
-
dev_info(dev->dev, "AT91 i2c bus driver.\n");
return 0;
}
diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
index 2e1f7eb..b2b8aa9 100644
--- a/drivers/i2c/busses/i2c-cpm.c
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -42,7 +42,6 @@
#include <linux/dma-mapping.h>
#include <linux/of_device.h>
#include <linux/of_platform.h>
-#include <linux/of_i2c.h>
#include <sysdev/fsl_soc.h>
#include <asm/cpm.h>
@@ -681,11 +680,6 @@ static int cpm_i2c_probe(struct platform_device *ofdev)
dev_dbg(&ofdev->dev, "hw routines for %s registered.\n",
cpm->adap.name);
- /*
- * register OF I2C devices
- */
- of_i2c_register_devices(&cpm->adap);
-
return 0;
out_shut:
cpm_i2c_shutdown(cpm);
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index fa55605..62be3b3 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -38,7 +38,6 @@
#include <linux/slab.h>
#include <linux/cpufreq.h>
#include <linux/gpio.h>
-#include <linux/of_i2c.h>
#include <linux/of_device.h>
#include <mach/hardware.h>
@@ -728,7 +727,6 @@ static int davinci_i2c_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "failure adding adapter\n");
goto err_unuse_clocks;
}
- of_i2c_register_devices(adap);
return 0;
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 4c5fada..27ea436 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -35,7 +35,6 @@
#include <linux/err.h>
#include <linux/interrupt.h>
#include <linux/of.h>
-#include <linux/of_i2c.h>
#include <linux/platform_device.h>
#include <linux/pm.h>
#include <linux/pm_runtime.h>
@@ -172,7 +171,6 @@ static int dw_i2c_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "failure adding adapter\n");
return r;
}
- of_i2c_register_devices(adap);
acpi_i2c_register_devices(adap);
pm_runtime_set_autosuspend_delay(&pdev->dev, 1000);
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
index bc6e139..e5da9fe 100644
--- a/drivers/i2c/busses/i2c-gpio.c
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -16,7 +16,6 @@
#include <linux/platform_device.h>
#include <linux/gpio.h>
#include <linux/of_gpio.h>
-#include <linux/of_i2c.h>
struct i2c_gpio_private_data {
struct i2c_adapter adap;
@@ -224,8 +223,6 @@ static int i2c_gpio_probe(struct platform_device *pdev)
if (ret)
goto err_add_bus;
- of_i2c_register_devices(adap);
-
platform_set_drvdata(pdev, priv);
dev_info(&pdev->dev, "using pins %u (SDA) and %u (SCL%s)\n",
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 4ebceed..4296d17 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -87,7 +87,6 @@
#include <linux/slab.h>
#include <linux/wait.h>
#include <linux/err.h>
-#include <linux/of_i2c.h>
#if (defined CONFIG_I2C_MUX_GPIO || defined CONFIG_I2C_MUX_GPIO_MODULE) && \
defined CONFIG_DMI
@@ -1230,7 +1229,6 @@ static int i801_probe(struct pci_dev *dev, const struct pci_device_id *id)
goto exit_free_irq;
}
- of_i2c_register_devices(&priv->adapter);
i801_probe_optional_slaves(priv);
/* We ignore errors - multiplexing is optional */
i801_add_mux(priv);
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
index 973f516..ff3caa0 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -42,7 +42,6 @@
#include <linux/io.h>
#include <linux/i2c.h>
#include <linux/of_platform.h>
-#include <linux/of_i2c.h>
#include "i2c-ibm_iic.h"
@@ -759,9 +758,6 @@ static int iic_probe(struct platform_device *ofdev)
dev_info(&ofdev->dev, "using %s mode\n",
dev->fast_mode ? "fast (400 kHz)" : "standard (100 kHz)");
- /* Now register all the child nodes */
- of_i2c_register_devices(adap);
-
return 0;
error_cleanup:
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index e242797..bbbea6b 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -50,7 +50,6 @@
#include <linux/slab.h>
#include <linux/of.h>
#include <linux/of_device.h>
-#include <linux/of_i2c.h>
#include <linux/platform_data/i2c-imx.h>
/** Defines ********************************************************************
@@ -570,8 +569,6 @@ static int __init i2c_imx_probe(struct platform_device *pdev)
return ret;
}
- of_i2c_register_devices(&i2c_imx->adapter);
-
/* Set up platform driver data */
platform_set_drvdata(pdev, i2c_imx);
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 7607dc0..9f2513d 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -18,7 +18,6 @@
#include <linux/sched.h>
#include <linux/init.h>
#include <linux/of_platform.h>
-#include <linux/of_i2c.h>
#include <linux/slab.h>
#include <linux/io.h>
@@ -691,7 +690,6 @@ static int fsl_i2c_probe(struct platform_device *op)
dev_err(i2c->dev, "failed to add adapter\n");
goto fail_add;
}
- of_i2c_register_devices(&i2c->adap);
return result;
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index b1f42bf..8220322 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -21,7 +21,6 @@
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/of_irq.h>
-#include <linux/of_i2c.h>
#include <linux/clk.h>
#include <linux/err.h>
@@ -689,8 +688,6 @@ mv64xxx_i2c_probe(struct platform_device *pd)
goto exit_free_irq;
}
- of_i2c_register_devices(&drv_data->adapter);
-
return 0;
exit_free_irq:
diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c
index df8ff5a..62ed07d 100644
--- a/drivers/i2c/busses/i2c-mxs.c
+++ b/drivers/i2c/busses/i2c-mxs.c
@@ -27,7 +27,6 @@
#include <linux/stmp_device.h>
#include <linux/of.h>
#include <linux/of_device.h>
-#include <linux/of_i2c.h>
#include <linux/dma-mapping.h>
#include <linux/dmaengine.h>
@@ -701,8 +700,6 @@ static int mxs_i2c_probe(struct platform_device *pdev)
return err;
}
- of_i2c_register_devices(adap);
-
return 0;
}
diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
index 512dfe6..519df17 100644
--- a/drivers/i2c/busses/i2c-nomadik.c
+++ b/drivers/i2c/busses/i2c-nomadik.c
@@ -24,7 +24,6 @@
#include <linux/pm_runtime.h>
#include <linux/platform_data/i2c-nomadik.h>
#include <linux/of.h>
-#include <linux/of_i2c.h>
#include <linux/pinctrl/consumer.h>
#define DRIVER_NAME "nmk-i2c"
@@ -1045,8 +1044,6 @@ static int nmk_i2c_probe(struct amba_device *adev, const struct amba_id *id)
goto err_add_adap;
}
- of_i2c_register_devices(adap);
-
pm_runtime_put(&adev->dev);
return 0;
diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 0e1f824..0a52b78 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -24,7 +24,6 @@
#include <linux/i2c-ocores.h>
#include <linux/slab.h>
#include <linux/io.h>
-#include <linux/of_i2c.h>
#include <linux/log2.h>
struct ocores_i2c {
@@ -435,8 +434,6 @@ static int ocores_i2c_probe(struct platform_device *pdev)
if (pdata) {
for (i = 0; i < pdata->num_devices; i++)
i2c_new_device(&i2c->adap, pdata->devices + i);
- } else {
- of_i2c_register_devices(&i2c->adap);
}
return 0;
diff --git a/drivers/i2c/busses/i2c-octeon.c b/drivers/i2c/busses/i2c-octeon.c
index 956fe32..b929ba2 100644
--- a/drivers/i2c/busses/i2c-octeon.c
+++ b/drivers/i2c/busses/i2c-octeon.c
@@ -15,7 +15,6 @@
#include <linux/interrupt.h>
#include <linux/kernel.h>
#include <linux/module.h>
-#include <linux/of_i2c.h>
#include <linux/delay.h>
#include <linux/sched.h>
#include <linux/slab.h>
@@ -599,8 +598,6 @@ static int octeon_i2c_probe(struct platform_device *pdev)
}
dev_info(i2c->dev, "version %s\n", DRV_VERSION);
- of_i2c_register_devices(&i2c->adap);
-
return 0;
out:
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 142b694d..a9f0f80 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -38,7 +38,6 @@
#include <linux/clk.h>
#include <linux/io.h>
#include <linux/of.h>
-#include <linux/of_i2c.h>
#include <linux/of_device.h>
#include <linux/slab.h>
#include <linux/i2c-omap.h>
@@ -1245,8 +1244,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev_info(dev->dev, "bus %d rev%d.%d at %d kHz\n", adap->nr,
major, minor, dev->speed);
- of_i2c_register_devices(adap);
-
pm_runtime_mark_last_busy(dev->dev);
pm_runtime_put_autosuspend(dev->dev);
diff --git a/drivers/i2c/busses/i2c-pnx.c b/drivers/i2c/busses/i2c-pnx.c
index 5f39c6d..7b57d67 100644
--- a/drivers/i2c/busses/i2c-pnx.c
+++ b/drivers/i2c/busses/i2c-pnx.c
@@ -23,7 +23,6 @@
#include <linux/err.h>
#include <linux/clk.h>
#include <linux/slab.h>
-#include <linux/of_i2c.h>
#define I2C_PNX_TIMEOUT_DEFAULT 10 /* msec */
#define I2C_PNX_SPEED_KHZ_DEFAULT 100
@@ -741,8 +740,6 @@ static int i2c_pnx_probe(struct platform_device *pdev)
goto out_irq;
}
- of_i2c_register_devices(&alg_data->adapter);
-
dev_dbg(&pdev->dev, "%s: Master at %#8x, irq %d.\n",
alg_data->adapter.name, res->start, alg_data->irq);
diff --git a/drivers/i2c/busses/i2c-powermac.c b/drivers/i2c/busses/i2c-powermac.c
index 8dc90da..1010f2e 100644
--- a/drivers/i2c/busses/i2c-powermac.c
+++ b/drivers/i2c/busses/i2c-powermac.c
@@ -440,7 +440,9 @@ static int i2c_powermac_probe(struct platform_device *dev)
adapter->algo = &i2c_powermac_algorithm;
i2c_set_adapdata(adapter, bus);
adapter->dev.parent = &dev->dev;
- adapter->dev.of_node = dev->dev.of_node;
+
+ /* Clear of_node to skip automatic registration of i2c child nodes */
+ adapter->dev.of_node = NULL;
rc = i2c_add_adapter(adapter);
if (rc) {
printk(KERN_ERR "i2c-powermac: Adapter %s registration "
@@ -450,9 +452,8 @@ static int i2c_powermac_probe(struct platform_device *dev)
printk(KERN_INFO "PowerMac i2c bus %s registered\n", adapter->name);
- /* Cannot use of_i2c_register_devices() due to Apple device-tree
- * funkyness
- */
+ /* Use custom child registration due to Apple device-tree funkyness */
+ adapter->dev.of_node = dev->dev.of_node;
i2c_powermac_register_devices(adapter, bus);
return rc;
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index fbafed2..bc65014 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -31,7 +31,6 @@
#include <linux/i2c-pxa.h>
#include <linux/of.h>
#include <linux/of_device.h>
-#include <linux/of_i2c.h>
#include <linux/platform_device.h>
#include <linux/err.h>
#include <linux/clk.h>
@@ -1185,7 +1184,6 @@ static int i2c_pxa_probe(struct platform_device *dev)
printk(KERN_INFO "I2C: Failed to add bus\n");
goto eadapt;
}
- of_i2c_register_devices(&i2c->adap);
platform_set_drvdata(dev, i2c);
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index cab1c91..643426e 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -36,7 +36,6 @@
#include <linux/cpufreq.h>
#include <linux/slab.h>
#include <linux/io.h>
-#include <linux/of_i2c.h>
#include <linux/of_gpio.h>
#include <linux/pinctrl/consumer.h>
@@ -1154,7 +1153,6 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev)
return ret;
}
- of_i2c_register_devices(&i2c->adap);
platform_set_drvdata(pdev, i2c);
pm_runtime_enable(&pdev->dev);
diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
index debf745..aa1268f 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -27,7 +27,6 @@
#include <linux/platform_device.h>
#include <linux/interrupt.h>
#include <linux/i2c.h>
-#include <linux/of_i2c.h>
#include <linux/err.h>
#include <linux/pm_runtime.h>
#include <linux/clk.h>
@@ -758,7 +757,6 @@ static int sh_mobile_i2c_probe(struct platform_device *dev)
"I2C adapter %d with bus speed %lu Hz (L/H=%x/%x)\n",
adap->nr, pd->bus_speed, pd->iccl, pd->icch);
- of_i2c_register_devices(adap);
return 0;
err_all:
diff --git a/drivers/i2c/busses/i2c-sirf.c b/drivers/i2c/busses/i2c-sirf.c
index a63c7d5..0ff22e2 100644
--- a/drivers/i2c/busses/i2c-sirf.c
+++ b/drivers/i2c/busses/i2c-sirf.c
@@ -12,7 +12,6 @@
#include <linux/slab.h>
#include <linux/platform_device.h>
#include <linux/i2c.h>
-#include <linux/of_i2c.h>
#include <linux/clk.h>
#include <linux/err.h>
#include <linux/io.h>
@@ -366,8 +365,6 @@ static int i2c_sirfsoc_probe(struct platform_device *pdev)
clk_disable(clk);
- of_i2c_register_devices(adap);
-
dev_info(&pdev->dev, " I2C adapter ready to operate\n");
return 0;
diff --git a/drivers/i2c/busses/i2c-stu300.c b/drivers/i2c/busses/i2c-stu300.c
index d1a6b20..047546c 100644
--- a/drivers/i2c/busses/i2c-stu300.c
+++ b/drivers/i2c/busses/i2c-stu300.c
@@ -17,7 +17,6 @@
#include <linux/clk.h>
#include <linux/io.h>
#include <linux/slab.h>
-#include <linux/of_i2c.h>
/* the name of this kernel module */
#define NAME "stu300"
@@ -936,7 +935,6 @@ stu300_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dev);
dev_info(&pdev->dev, "ST DDC I2C @ %p, irq %d\n",
dev->virtbase, dev->irq);
- of_i2c_register_devices(adap);
return 0;
}
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 9aa1b60..c457cb4 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -25,7 +25,6 @@
#include <linux/interrupt.h>
#include <linux/delay.h>
#include <linux/slab.h>
-#include <linux/of_i2c.h>
#include <linux/of_device.h>
#include <linux/module.h>
#include <linux/clk/tegra.h>
@@ -802,8 +801,6 @@ static int tegra_i2c_probe(struct platform_device *pdev)
return ret;
}
- of_i2c_register_devices(&i2c_dev->adapter);
-
return 0;
}
diff --git a/drivers/i2c/busses/i2c-versatile.c b/drivers/i2c/busses/i2c-versatile.c
index f3a8790..6bb3a89 100644
--- a/drivers/i2c/busses/i2c-versatile.c
+++ b/drivers/i2c/busses/i2c-versatile.c
@@ -16,7 +16,6 @@
#include <linux/platform_device.h>
#include <linux/slab.h>
#include <linux/io.h>
-#include <linux/of_i2c.h>
#define I2C_CONTROL 0x00
#define I2C_CONTROLS 0x00
@@ -108,7 +107,6 @@ static int i2c_versatile_probe(struct platform_device *dev)
ret = i2c_bit_add_numbered_bus(&i2c->adap);
if (ret >= 0) {
platform_set_drvdata(dev, i2c);
- of_i2c_register_devices(&i2c->adap);
return 0;
}
diff --git a/drivers/i2c/busses/i2c-wmt.c b/drivers/i2c/busses/i2c-wmt.c
index baaa7d1..c65da3d 100644
--- a/drivers/i2c/busses/i2c-wmt.c
+++ b/drivers/i2c/busses/i2c-wmt.c
@@ -21,7 +21,6 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_address.h>
-#include <linux/of_i2c.h>
#include <linux/of_irq.h>
#include <linux/platform_device.h>
@@ -439,8 +438,6 @@ static int wmt_i2c_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, i2c_dev);
- of_i2c_register_devices(adap);
-
return 0;
}
diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c
index 3d0f052..8823db7 100644
--- a/drivers/i2c/busses/i2c-xiic.c
+++ b/drivers/i2c/busses/i2c-xiic.c
@@ -40,7 +40,6 @@
#include <linux/i2c-xiic.h>
#include <linux/io.h>
#include <linux/slab.h>
-#include <linux/of_i2c.h>
#define DRIVER_NAME "xiic-i2c"
@@ -752,8 +751,6 @@ static int xiic_i2c_probe(struct platform_device *pdev)
i2c_new_device(&i2c->adap, pdata->devices + i);
}
- of_i2c_register_devices(&i2c->adap);
-
return 0;
add_adapter_failed:
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index f32ca29..08ebd78 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -23,7 +23,11 @@
SMBus 2.0 support by Mark Studebaker <mdsxyz123@yahoo.com> and
Jean Delvare <khali@linux-fr.org>
Mux support by Rodolfo Giometti <giometti@enneenne.com> and
- Michael Lawnick <michael.lawnick.ext@nsn.com> */
+ Michael Lawnick <michael.lawnick.ext@nsn.com>
+ OF support is copyright (c) 2008 Jochen Friedrich <jochen@scram.de>
+ (based on a previous patch from Jon Smirl <jonsmirl@gmail.com>) and
+ (c) 2013 Wolfram Sang <wsa@the-dreams.de>
+ */
#include <linux/module.h>
#include <linux/kernel.h>
@@ -35,7 +39,9 @@
#include <linux/init.h>
#include <linux/idr.h>
#include <linux/mutex.h>
+#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/of_irq.h>
#include <linux/completion.h>
#include <linux/hardirq.h>
#include <linux/irqflags.h>
@@ -954,6 +960,104 @@ static void i2c_scan_static_board_info(struct i2c_adapter *adapter)
up_read(&__i2c_board_lock);
}
+/* OF support code */
+
+#if IS_ENABLED(CONFIG_OF)
+static void of_i2c_register_devices(struct i2c_adapter *adap)
+{
+ void *result;
+ struct device_node *node;
+
+ /* Only register child devices if the adapter has a node pointer set */
+ if (!adap->dev.of_node)
+ return;
+
+ dev_dbg(&adap->dev, "of_i2c: walking child nodes\n");
+
+ for_each_available_child_of_node(adap->dev.of_node, node) {
+ struct i2c_board_info info = {};
+ struct dev_archdata dev_ad = {};
+ const __be32 *addr;
+ int len;
+
+ dev_dbg(&adap->dev, "of_i2c: register %s\n", node->full_name);
+
+ if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
+ dev_err(&adap->dev, "of_i2c: modalias failure on %s\n",
+ node->full_name);
+ continue;
+ }
+
+ addr = of_get_property(node, "reg", &len);
+ if (!addr || (len < sizeof(int))) {
+ dev_err(&adap->dev, "of_i2c: invalid reg on %s\n",
+ node->full_name);
+ continue;
+ }
+
+ info.addr = be32_to_cpup(addr);
+ if (info.addr > (1 << 10) - 1) {
+ dev_err(&adap->dev, "of_i2c: invalid addr=%x on %s\n",
+ info.addr, node->full_name);
+ continue;
+ }
+
+ info.irq = irq_of_parse_and_map(node, 0);
+ info.of_node = of_node_get(node);
+ info.archdata = &dev_ad;
+
+ if (of_get_property(node, "wakeup-source", NULL))
+ info.flags |= I2C_CLIENT_WAKE;
+
+ request_module("%s%s", I2C_MODULE_PREFIX, info.type);
+
+ result = i2c_new_device(adap, &info);
+ if (result == NULL) {
+ dev_err(&adap->dev, "of_i2c: Failure registering %s\n",
+ node->full_name);
+ of_node_put(node);
+ irq_dispose_mapping(info.irq);
+ continue;
+ }
+ }
+}
+
+static int of_dev_node_match(struct device *dev, void *data)
+{
+ return dev->of_node == data;
+}
+
+/* must call put_device() when done with returned i2c_client device */
+struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
+{
+ struct device *dev;
+
+ dev = bus_find_device(&i2c_bus_type, NULL, node,
+ of_dev_node_match);
+ if (!dev)
+ return NULL;
+
+ return i2c_verify_client(dev);
+}
+EXPORT_SYMBOL(of_find_i2c_device_by_node);
+
+/* must call put_device() when done with returned i2c_adapter device */
+struct i2c_adapter *of_find_i2c_adapter_by_node(struct device_node *node)
+{
+ struct device *dev;
+
+ dev = bus_find_device(&i2c_bus_type, NULL, node,
+ of_dev_node_match);
+ if (!dev)
+ return NULL;
+
+ return i2c_verify_adapter(dev);
+}
+EXPORT_SYMBOL(of_find_i2c_adapter_by_node);
+#else
+static void of_i2c_register_devices(struct i2c_adapter *adap) { }
+#endif /* CONFIG_OF */
+
static int i2c_do_add_adapter(struct i2c_driver *driver,
struct i2c_adapter *adap)
{
@@ -1058,6 +1162,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
exit_recovery:
/* create pre-declared device nodes */
+ of_i2c_register_devices(adap);
+
if (adap->nr < __i2c_first_dynamic_bus_num)
i2c_scan_static_board_info(adap);
@@ -1282,7 +1388,6 @@ void i2c_del_adapter(struct i2c_adapter *adap)
}
EXPORT_SYMBOL(i2c_del_adapter);
-
/* ------------------------------------------------------------------------- */
int i2c_for_each_dev(void *data, int (*fn)(struct device *, void *))
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 7409ebb..797e311 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -25,7 +25,6 @@
#include <linux/i2c.h>
#include <linux/i2c-mux.h>
#include <linux/of.h>
-#include <linux/of_i2c.h>
/* multiplexer per channel data */
struct i2c_mux_priv {
@@ -185,8 +184,6 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter *parent,
dev_info(&parent->dev, "Added multiplexed i2c bus %d\n",
i2c_adapter_id(&priv->adap));
- of_i2c_register_devices(&priv->adap);
-
return &priv->adap;
}
EXPORT_SYMBOL_GPL(i2c_add_mux_adapter);
diff --git a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
index 210b6f7..b901638 100644
--- a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
+++ b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
@@ -21,7 +21,6 @@
#include <linux/i2c-mux.h>
#include <linux/init.h>
#include <linux/module.h>
-#include <linux/of_i2c.h>
#include <linux/of_gpio.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
diff --git a/drivers/i2c/muxes/i2c-mux-gpio.c b/drivers/i2c/muxes/i2c-mux-gpio.c
index 5a0ce00..128a981 100644
--- a/drivers/i2c/muxes/i2c-mux-gpio.c
+++ b/drivers/i2c/muxes/i2c-mux-gpio.c
@@ -16,7 +16,6 @@
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/gpio.h>
-#include <linux/of_i2c.h>
#include <linux/of_gpio.h>
struct gpiomux {
diff --git a/drivers/i2c/muxes/i2c-mux-pinctrl.c b/drivers/i2c/muxes/i2c-mux-pinctrl.c
index a43c0ce..859a6d2 100644
--- a/drivers/i2c/muxes/i2c-mux-pinctrl.c
+++ b/drivers/i2c/muxes/i2c-mux-pinctrl.c
@@ -20,7 +20,6 @@
#include <linux/i2c-mux.h>
#include <linux/init.h>
#include <linux/module.h>
-#include <linux/of_i2c.h>
#include <linux/pinctrl/consumer.h>
#include <linux/i2c-mux-pinctrl.h>
#include <linux/platform_device.h>
diff --git a/drivers/media/platform/exynos4-is/fimc-is-i2c.c b/drivers/media/platform/exynos4-is/fimc-is-i2c.c
index 617a798..9930556 100644
--- a/drivers/media/platform/exynos4-is/fimc-is-i2c.c
+++ b/drivers/media/platform/exynos4-is/fimc-is-i2c.c
@@ -12,7 +12,7 @@
#include <linux/clk.h>
#include <linux/module.h>
-#include <linux/of_i2c.h>
+#include <linux/i2c.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/slab.h>
@@ -67,8 +67,6 @@ static int fimc_is_i2c_probe(struct platform_device *pdev)
pm_runtime_enable(&pdev->dev);
pm_runtime_enable(&i2c_adap->dev);
- of_i2c_register_devices(i2c_adap);
-
return 0;
}
diff --git a/drivers/media/platform/exynos4-is/fimc-is.c b/drivers/media/platform/exynos4-is/fimc-is.c
index 967f6a9..2276fdc 100644
--- a/drivers/media/platform/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/exynos4-is/fimc-is.c
@@ -21,7 +21,7 @@
#include <linux/interrupt.h>
#include <linux/kernel.h>
#include <linux/module.h>
-#include <linux/of_i2c.h>
+#include <linux/i2c.h>
#include <linux/of_irq.h>
#include <linux/of_address.h>
#include <linux/of_platform.h>
diff --git a/drivers/media/platform/exynos4-is/media-dev.c b/drivers/media/platform/exynos4-is/media-dev.c
index 19f556c..f8c66b4 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -20,7 +20,6 @@
#include <linux/of.h>
#include <linux/of_platform.h>
#include <linux/of_device.h>
-#include <linux/of_i2c.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/types.h>
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 80e5c13..78cc760 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -48,12 +48,6 @@ config OF_IRQ
def_bool y
depends on !SPARC
-config OF_I2C
- def_tristate I2C
- depends on I2C
- help
- OpenFirmware I2C accessors
-
config OF_NET
depends on NETDEVICES
def_bool y
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 1f9c0c4..efd0510 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -3,7 +3,6 @@ obj-$(CONFIG_OF_FLATTREE) += fdt.o
obj-$(CONFIG_OF_PROMTREE) += pdt.o
obj-$(CONFIG_OF_ADDRESS) += address.o
obj-$(CONFIG_OF_IRQ) += irq.o
-obj-$(CONFIG_OF_I2C) += of_i2c.o
obj-$(CONFIG_OF_NET) += of_net.o
obj-$(CONFIG_OF_SELFTEST) += selftest.o
obj-$(CONFIG_OF_MDIO) += of_mdio.o
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
deleted file mode 100644
index b667264..0000000
--- a/drivers/of/of_i2c.c
+++ /dev/null
@@ -1,114 +0,0 @@
-/*
- * OF helpers for the I2C API
- *
- * Copyright (c) 2008 Jochen Friedrich <jochen@scram.de>
- *
- * Based on a previous patch from Jon Smirl <jonsmirl@gmail.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include <linux/i2c.h>
-#include <linux/irq.h>
-#include <linux/of.h>
-#include <linux/of_i2c.h>
-#include <linux/of_irq.h>
-#include <linux/module.h>
-
-void of_i2c_register_devices(struct i2c_adapter *adap)
-{
- void *result;
- struct device_node *node;
-
- /* Only register child devices if the adapter has a node pointer set */
- if (!adap->dev.of_node)
- return;
-
- dev_dbg(&adap->dev, "of_i2c: walking child nodes\n");
-
- for_each_available_child_of_node(adap->dev.of_node, node) {
- struct i2c_board_info info = {};
- struct dev_archdata dev_ad = {};
- const __be32 *addr;
- int len;
-
- dev_dbg(&adap->dev, "of_i2c: register %s\n", node->full_name);
-
- if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
- dev_err(&adap->dev, "of_i2c: modalias failure on %s\n",
- node->full_name);
- continue;
- }
-
- addr = of_get_property(node, "reg", &len);
- if (!addr || (len < sizeof(int))) {
- dev_err(&adap->dev, "of_i2c: invalid reg on %s\n",
- node->full_name);
- continue;
- }
-
- info.addr = be32_to_cpup(addr);
- if (info.addr > (1 << 10) - 1) {
- dev_err(&adap->dev, "of_i2c: invalid addr=%x on %s\n",
- info.addr, node->full_name);
- continue;
- }
-
- info.irq = irq_of_parse_and_map(node, 0);
- info.of_node = of_node_get(node);
- info.archdata = &dev_ad;
-
- if (of_get_property(node, "wakeup-source", NULL))
- info.flags |= I2C_CLIENT_WAKE;
-
- request_module("%s%s", I2C_MODULE_PREFIX, info.type);
-
- result = i2c_new_device(adap, &info);
- if (result == NULL) {
- dev_err(&adap->dev, "of_i2c: Failure registering %s\n",
- node->full_name);
- of_node_put(node);
- irq_dispose_mapping(info.irq);
- continue;
- }
- }
-}
-EXPORT_SYMBOL(of_i2c_register_devices);
-
-static int of_dev_node_match(struct device *dev, void *data)
-{
- return dev->of_node == data;
-}
-
-/* must call put_device() when done with returned i2c_client device */
-struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
-{
- struct device *dev;
-
- dev = bus_find_device(&i2c_bus_type, NULL, node,
- of_dev_node_match);
- if (!dev)
- return NULL;
-
- return i2c_verify_client(dev);
-}
-EXPORT_SYMBOL(of_find_i2c_device_by_node);
-
-/* must call put_device() when done with returned i2c_adapter device */
-struct i2c_adapter *of_find_i2c_adapter_by_node(struct device_node *node)
-{
- struct device *dev;
-
- dev = bus_find_device(&i2c_bus_type, NULL, node,
- of_dev_node_match);
- if (!dev)
- return NULL;
-
- return i2c_verify_adapter(dev);
-}
-EXPORT_SYMBOL(of_find_i2c_adapter_by_node);
-
-MODULE_LICENSE("GPL");
diff --git a/drivers/staging/imx-drm/imx-tve.c b/drivers/staging/imx-drm/imx-tve.c
index a56797d..2d76fd4 100644
--- a/drivers/staging/imx-drm/imx-tve.c
+++ b/drivers/staging/imx-drm/imx-tve.c
@@ -21,7 +21,7 @@
#include <linux/clk.h>
#include <linux/clk-provider.h>
#include <linux/module.h>
-#include <linux/of_i2c.h>
+#include <linux/i2c.h>
#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
#include <linux/spinlock.h>
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index e988fa9..2189189 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -542,6 +542,26 @@ static inline int i2c_adapter_id(struct i2c_adapter *adap)
#endif /* I2C */
+#if IS_ENABLED(CONFIG_OF)
+/* must call put_device() when done with returned i2c_client device */
+extern struct i2c_client *of_find_i2c_device_by_node(struct device_node *node);
+
+/* must call put_device() when done with returned i2c_adapter device */
+extern struct i2c_adapter *of_find_i2c_adapter_by_node(struct device_node *node);
+
+#else
+
+static inline struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
+{
+ return NULL;
+}
+
+static inline struct i2c_adapter *of_find_i2c_adapter_by_node(struct device_node *node)
+{
+ return NULL;
+}
+#endif /* CONFIG_OF */
+
#if IS_ENABLED(CONFIG_ACPI_I2C)
extern void acpi_i2c_register_devices(struct i2c_adapter *adap);
#else
diff --git a/include/linux/of_i2c.h b/include/linux/of_i2c.h
deleted file mode 100644
index cfb545c..0000000
--- a/include/linux/of_i2c.h
+++ /dev/null
@@ -1,46 +0,0 @@
-/*
- * Generic I2C API implementation for PowerPC.
- *
- * Copyright (c) 2008 Jochen Friedrich <jochen@scram.de>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#ifndef __LINUX_OF_I2C_H
-#define __LINUX_OF_I2C_H
-
-#if defined(CONFIG_OF_I2C) || defined(CONFIG_OF_I2C_MODULE)
-#include <linux/i2c.h>
-
-extern void of_i2c_register_devices(struct i2c_adapter *adap);
-
-/* must call put_device() when done with returned i2c_client device */
-extern struct i2c_client *of_find_i2c_device_by_node(struct device_node *node);
-
-/* must call put_device() when done with returned i2c_adapter device */
-extern struct i2c_adapter *of_find_i2c_adapter_by_node(
- struct device_node *node);
-
-#else
-static inline void of_i2c_register_devices(struct i2c_adapter *adap)
-{
- return;
-}
-
-static inline struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
-{
- return NULL;
-}
-
-/* must call put_device() when done with returned i2c_adapter device */
-static inline struct i2c_adapter *of_find_i2c_adapter_by_node(
- struct device_node *node)
-{
- return NULL;
-}
-#endif /* CONFIG_OF_I2C */
-
-#endif /* __LINUX_OF_I2C_H */
diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
index 3f726e4..f2fbde9 100644
--- a/sound/soc/fsl/imx-sgtl5000.c
+++ b/sound/soc/fsl/imx-sgtl5000.c
@@ -13,7 +13,7 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_platform.h>
-#include <linux/of_i2c.h>
+#include <linux/i2c.h>
#include <linux/clk.h>
#include <sound/soc.h>
diff --git a/sound/soc/fsl/imx-wm8962.c b/sound/soc/fsl/imx-wm8962.c
index 52a36a9..9fd7a65 100644
--- a/sound/soc/fsl/imx-wm8962.c
+++ b/sound/soc/fsl/imx-wm8962.c
@@ -15,7 +15,7 @@
#include <linux/module.h>
#include <linux/of_platform.h>
-#include <linux/of_i2c.h>
+#include <linux/i2c.h>
#include <linux/slab.h>
#include <linux/clk.h>
#include <sound/soc.h>
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 2/2] powerpc/iommu: check dev->iommu_group before remove a device from iommu_group
From: Wei Yang @ 2013-08-22 15:41 UTC (permalink / raw)
To: Alex Williamson
Cc: Alexey Kardashevskiy, paulus, benh, linuxppc-dev, linux-kernel
In-Reply-To: <1377185303.25163.13.camel@ul30vt.home>
On Thu, Aug 22, 2013 at 09:28:23AM -0600, Alex Williamson wrote:
>On Thu, 2013-08-22 at 15:52 +0800, Wei Yang wrote:
>> On Thu, Aug 22, 2013 at 05:23:34PM +1000, Alexey Kardashevskiy wrote:
>> >On 08/19/2013 11:55 AM, Wei Yang wrote:
>> >> On Mon, Aug 19, 2013 at 11:39:49AM +1000, Alexey Kardashevskiy wrote:
>> >>> On 08/19/2013 11:29 AM, Wei Yang wrote:
>> >>>> On Fri, Aug 16, 2013 at 08:15:36PM +1000, Alexey Kardashevskiy wrote:
>> >>>>> On 08/16/2013 08:08 PM, Wei Yang wrote:
>> >>>>>> ---
>> >>>>>> arch/powerpc/kernel/iommu.c | 3 ++-
>> >>>>>> 1 files changed, 2 insertions(+), 1 deletions(-)
>> >>>>>>
>> >>>>>> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
>> >>>>>> index b20ff17..5abf7c3 100644
>> >>>>>> --- a/arch/powerpc/kernel/iommu.c
>> >>>>>> +++ b/arch/powerpc/kernel/iommu.c
>> >>>>>> @@ -1149,7 +1149,8 @@ static int iommu_bus_notifier(struct notifier_block *nb,
>> >>>>>> case BUS_NOTIFY_ADD_DEVICE:
>> >>>>>> return iommu_add_device(dev);
>> >>>>>> case BUS_NOTIFY_DEL_DEVICE:
>> >>>>>> - iommu_del_device(dev);
>> >>>>>> + if (dev->iommu_group)
>> >>>>>> + iommu_del_device(dev);
>> >>>>>> return 0;
>> >>>>>> default:
>> >>>>>> return 0;
>> >>>>>>
>> >>>>>
>> >>>>> This one seems redundant, no?
>> >>>>
>> >>>> Sorry for the late.
>> >>>>
>> >>>> Yes, these two patches have the same purpose to guard the system, while in two
>> >>>> different places. One is in powernv platform, the other is in the generic iommu
>> >>>> driver.
>> >>>>
>> >>>> The one in powernv platform is used to correct the original logic.
>> >>>>
>> >>>> The one in generic iommu driver is to keep system safe in case other platform to
>> >>>> call iommu_group_remove_device() without the check.
>> >>>
>> >>>
>> >>> But I am moving bus notifier to powernv code (posted a patch last week,
>> >>> otherwise Freescale's IOMMU conflicted) so this won't be the case.
>> >>
>> >> Yes, I see the patch.
>> >>
>> >> This means other platforms, besides powernv, will check the dev->iommu_group
>> >> before remove the device? This would be a convention?
>> >>
>> >> If this is the case, the second patch is enough. We don't need to check it in
>> >> generic iommu driver.
>> >>
>> >> Since I am not very familiar with the code convention, I post these two
>> >> patches together. This doesn't mean I need to push both of them. Your comments
>> >> are welcome, lets me understand which one is more suitable in this case.
>> >
>> >
>> >Ok. So. I included the check in the bus notifier which I moved to powernv
>> >platform, I guess I'll repost the series soon.
>>
>> Thanks, this check will guard the powernv platform.
>>
>> >
>> >Good luck with pushing the fix for drivers/iommu/iommu.c :)
>> >
>>
>> Alex,
>>
>> Sorry for not including you in the very beginning, which may spend you more
>> efforts to track previous mails in this thread.
>>
>> Do you think it is reasonable to check the dev->iommu_group in
>> iommu_group_remove_device()? Or we can count on the bus notifier to check it?
>>
>> Welcome your suggestions~
>
>I don't really see the point of patch 1/2. iommu_group_remove_device()
>is specifically to remove a device from an iommu_group, so why would you
>call it on a device that's not part of an iommu_group. If you want to
>avoid testing dev->iommu_group, then implement the .remove_device
>callback rather than using the notifier. Thanks,
>
You mean the .remove_device like intel_iommu_remove_device()?
Hmm... this function didn't check the dev->iommu_group and just call
iommu_group_remove_device(). I see this guard is put in iommu_bus_notifier(),
which will check dev->iommu_group before invoke .remove_device.
Let me explain the case to triger the problem a little.
On some platform, like powernv, we implement another bus notifier when devices
are added or removed in the system. Like Alexey mentioned, he missed the check
for dev->iommu_group in the notifier before removing it from iommu_group. This
trigger the crash.
So do you think it is reasonable to guard the kernel in
iommu_group_remove_device(), or we give the platform developers the
responsibility to check the dev->iommu_group before calling it?
Thanks~
>Alex
--
Richard Yang
Help you, Help me
^ permalink raw reply
* Ethernet over PCIe driver for Inter-Processor Communication
From: Saravanan S @ 2013-08-22 15:34 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]
Hi All,
I have a custom board with four MPC8640 nodes connected over a
transparent PCI express switch . In this configuration one node is
configured as host(Root Complex) and others as agents(End Point) .Thus the
legacy PCI software works fine . However the mainline kernel lacks any
standard support for Inter-processor communication over PCI . I am in the
process of developing an Ethernet over PCI driver for the same on the
lines of rionet . However I am facing the following problems.
a) I can generate MSI interrupts from End Point to Root Complex over PCI
. But the vice-versa is not possible . However i need a method to interrupt
the End Point from the Root Complex to complete my driver. Only previous
references I can find are this post
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg25765.html .
However this uses doorbells and I think may not be possible in MPC8640.
b) Also i need a method to interrupt an End Point from another end point?
Is that possible ?
Any pointers on this issue and guidance on this driver development would be
helpful .
Regards,
S.Saravanan
[-- Attachment #2: Type: text/html, Size: 1327 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/iommu: check dev->iommu_group before remove a device from iommu_group
From: Alex Williamson @ 2013-08-22 15:28 UTC (permalink / raw)
To: Wei Yang; +Cc: Alexey Kardashevskiy, paulus, benh, linuxppc-dev, linux-kernel
In-Reply-To: <20130822075237.GA14479@weiyang.vnet.ibm.com>
On Thu, 2013-08-22 at 15:52 +0800, Wei Yang wrote:
> On Thu, Aug 22, 2013 at 05:23:34PM +1000, Alexey Kardashevskiy wrote:
> >On 08/19/2013 11:55 AM, Wei Yang wrote:
> >> On Mon, Aug 19, 2013 at 11:39:49AM +1000, Alexey Kardashevskiy wrote:
> >>> On 08/19/2013 11:29 AM, Wei Yang wrote:
> >>>> On Fri, Aug 16, 2013 at 08:15:36PM +1000, Alexey Kardashevskiy wrote:
> >>>>> On 08/16/2013 08:08 PM, Wei Yang wrote:
> >>>>>> ---
> >>>>>> arch/powerpc/kernel/iommu.c | 3 ++-
> >>>>>> 1 files changed, 2 insertions(+), 1 deletions(-)
> >>>>>>
> >>>>>> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> >>>>>> index b20ff17..5abf7c3 100644
> >>>>>> --- a/arch/powerpc/kernel/iommu.c
> >>>>>> +++ b/arch/powerpc/kernel/iommu.c
> >>>>>> @@ -1149,7 +1149,8 @@ static int iommu_bus_notifier(struct notifier_block *nb,
> >>>>>> case BUS_NOTIFY_ADD_DEVICE:
> >>>>>> return iommu_add_device(dev);
> >>>>>> case BUS_NOTIFY_DEL_DEVICE:
> >>>>>> - iommu_del_device(dev);
> >>>>>> + if (dev->iommu_group)
> >>>>>> + iommu_del_device(dev);
> >>>>>> return 0;
> >>>>>> default:
> >>>>>> return 0;
> >>>>>>
> >>>>>
> >>>>> This one seems redundant, no?
> >>>>
> >>>> Sorry for the late.
> >>>>
> >>>> Yes, these two patches have the same purpose to guard the system, while in two
> >>>> different places. One is in powernv platform, the other is in the generic iommu
> >>>> driver.
> >>>>
> >>>> The one in powernv platform is used to correct the original logic.
> >>>>
> >>>> The one in generic iommu driver is to keep system safe in case other platform to
> >>>> call iommu_group_remove_device() without the check.
> >>>
> >>>
> >>> But I am moving bus notifier to powernv code (posted a patch last week,
> >>> otherwise Freescale's IOMMU conflicted) so this won't be the case.
> >>
> >> Yes, I see the patch.
> >>
> >> This means other platforms, besides powernv, will check the dev->iommu_group
> >> before remove the device? This would be a convention?
> >>
> >> If this is the case, the second patch is enough. We don't need to check it in
> >> generic iommu driver.
> >>
> >> Since I am not very familiar with the code convention, I post these two
> >> patches together. This doesn't mean I need to push both of them. Your comments
> >> are welcome, lets me understand which one is more suitable in this case.
> >
> >
> >Ok. So. I included the check in the bus notifier which I moved to powernv
> >platform, I guess I'll repost the series soon.
>
> Thanks, this check will guard the powernv platform.
>
> >
> >Good luck with pushing the fix for drivers/iommu/iommu.c :)
> >
>
> Alex,
>
> Sorry for not including you in the very beginning, which may spend you more
> efforts to track previous mails in this thread.
>
> Do you think it is reasonable to check the dev->iommu_group in
> iommu_group_remove_device()? Or we can count on the bus notifier to check it?
>
> Welcome your suggestions~
I don't really see the point of patch 1/2. iommu_group_remove_device()
is specifically to remove a device from an iommu_group, so why would you
call it on a device that's not part of an iommu_group. If you want to
avoid testing dev->iommu_group, then implement the .remove_device
callback rather than using the notifier. Thanks,
Alex
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state
From: Scott Wood @ 2013-08-22 15:19 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Zhao Chenhui-B35336
In-Reply-To: <ABB05CD9C9F68C46A5CEDC7F1543925901027BD3@039-SN2MPN1-021.039d.mgd.msft.net>
On Wed, 2013-08-21 at 22:13 -0500, Wang Dongsheng-B40534 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, August 20, 2013 8:39 AM
> > To: Wang Dongsheng-B40534
> > Cc: Wood Scott-B07421; Kumar Gala; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter
> > altivec idle state
> >
> > It just seems wrong to have an ad-hoc mechanism for running
> > core-specific code when we have cputable... If we really need this,
> > maybe we should add a "cpu_setup_late" function pointer.
> >
> > With your patch, when does the power management register get set when
> > hot plugging a cpu?
> >
> Um.. I don't deal with this situation. I will fix it.
> __setup/restore_cpu_e6500 looks good. But only bootcpu call __setup_cpu_e6500, not on each cpu.
> I think this is a bug.
Other CPUs call __restore_cpu_e6500.
> > > > As for the PVR check, the upstream kernel doesn't need to care about
> > > > rev1, so knowing it's an e6500 is good enough.
> > > >
> > > But AltiVec idle & PW20 cannot work on rev1 platform.
> > > We didn't have to deal with it?
> >
> > Upstream does not run on rev1.
> >
> :), But already have customers in the use of rev1.
> Why we don't need to care about that?
rev1 is not production-qualified. Those customers are supposed to only
be using rev1 for evaluation and early development. It's not that we
don't care about rev1 now (we have the SDK for that) but that we won't
care about it long-term and don't want to have to carry around a bunch
of baggage for it. Some of the workarounds are pretty nasty (especially
A-006198).
-Scott
^ permalink raw reply
* [PATCH] powerpc: Unaligned stores and stmw are broken in PowerISA emulation code
From: Tom Musta @ 2013-08-22 14:25 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]
To: linuxppc-dev@lists.ozlabs.org
Subject: [PATCH] powerpc: Unaligned stores and stmw are broken in PowerISA
emulation code
From: Tom Musta <tmusta@us.ibm.com>
The stmw instruction was incorrectly decoded as an update form instruction
and thus the RA
register was being clobbered.
Also, the utility routine to write memory to unaligned addresses breaks the
operation into
smaller aligned accesses but was incorrectly incrementing the address by
only one; it needs
to increment the address by the size of the smaller aligned chunk.
Signed-off-by: Tom Musta <tmusta@us.ibm.com>
---
arch/powerpc/lib/sstep.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 9a52349..d220b88 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -100,8 +100,10 @@ static unsigned long __kprobes dform_ea(unsigned int
instr, struct pt_regs *regs
ea = (signed short) instr; /* sign-extend */
if (ra) {
ea += regs->gpr[ra];
- if (instr & 0x04000000) /* update forms */
- regs->gpr[ra] = ea;
+ if (instr & 0x04000000) { /* update forms */
+ if ((instr>>26) != 47) /* stmw is not an update
form */
+ regs->gpr[ra] = ea;
+ }
}
return truncate_if_32bit(regs->msr, ea);
@@ -279,7 +281,7 @@ static int __kprobes write_mem_unaligned(unsigned long
val, unsigned long ea,
err = write_mem_aligned(val >> (nb - c) * 8, ea, c);
if (err)
return err;
- ++ea;
+ ea += c;
}
return 0;
}
Tom Musta (tmusta@us.ibm.com)
Senior Software Engineer
Blue Gene Kernel Development
IBM Rochester
(507) 253-4119 (T/L 553-4119)
[-- Attachment #2: Type: text/html, Size: 3578 bytes --]
^ permalink raw reply related
* Re: [PATCH 3/4] powerpc/booke64: Use appropriate -mcpu
From: Scott Wood @ 2013-08-22 14:18 UTC (permalink / raw)
To: Rojhalat Ibrahim; +Cc: Catalin Udma, linuxppc-dev
In-Reply-To: <1753626.1M86qx3vEi@pcimr>
On Thu, 2013-08-22 at 15:56 +0200, Rojhalat Ibrahim wrote:
> Just out of curiosity: What's the difference (if any) between -mcpu=e500mc64
> and -mcpu=e5500? AFAIK -mcpu=e500mc64 is supported by gcc since at least
> version 4.6 whereas -mcpu=e5500 is only supported since gcc 4.8. But is there
> actually any difference?
I had asked our compiler person that before sending... the answer
wasn't very clear, but when I asked whether there was any benefit for
the kernel specifying e5500 (requiring an extra fallback check) he said
"probably not". Eventually they'll probably just become aliases for the
same thing. Currently they do have separate .md files though, so
they're not identical.
-Scott
^ permalink raw reply
* Re: [RFC PATCH v2 3/4] powerpc: refactor of_get_cpu_node to support other architectures
From: Mark Rutland @ 2013-08-22 13:59 UTC (permalink / raw)
To: Sudeep KarkadaNagesha
Cc: Jonas Bonn, devicetree@vger.kernel.org, Michal Simek,
Lorenzo Pieralisi, linux-pm@vger.kernel.org, Tomasz Figa,
rob.herring@calxeda.com, linux-kernel@vger.kernel.org,
Rafael J. Wysocki, Rob Herring, grant.likely@linaro.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <521223FA.5050903@arm.com>
On Mon, Aug 19, 2013 at 02:56:10PM +0100, Sudeep KarkadaNagesha wrote:
> On 19/08/13 14:02, Rob Herring wrote:
> > On 08/19/2013 05:19 AM, Mark Rutland wrote:
> >> On Sat, Aug 17, 2013 at 11:09:36PM +0100, Benjamin Herrenschmidt wrote:
> >>> On Sat, 2013-08-17 at 12:50 +0200, Tomasz Figa wrote:
> >>>> I wonder how would this handle uniprocessor ARM (pre-v7) cores, for
> >>>> which
> >>>> the updated bindings[1] define #address-cells = <0> and so no reg
> >>>> property.
> >>>>
> >>>> [1] - http://thread.gmane.org/gmane.linux.ports.arm.kernel/260795
> >>>
> >>> Why did you do that in the binding ? That sounds like looking to create
> >>> problems ...
> >>>
> >>> Traditionally, UP setups just used "0" as the "reg" property on other
> >>> architectures, why do differently ?
> >>
> >> The decision was taken because we defined our reg property to refer to
> >> the MPIDR register's Aff{2,1,0} bitfields, and on UP cores before v7
> >> there's no MPIDR register at all. Given there can only be a single CPU
> >> in that case, describing a register that wasn't present didn't seem
> >> necessary or helpful.
> >
> > What exactly reg represents is up to the binding definition, but it
> > still should be present IMO. I don't see any issue with it being
> > different for pre-v7.
> >
> Yes it's better to have 'reg' with value 0 than not having it.
> Otherwise this generic of_get_cpu_node implementation would need some
> _hack_ to handle that case.
I'm not sure that having some code to handle a difference in standard
between two architectures is a hack. If anything, I'd argue encoding a
reg of 0 that corresponds to a nonexistent MPIDR value (given that's
what the reg property is defined to map to on ARM) is more of a hack ;)
I'm not averse to having a reg value of 0 for this case, but given that
there are existing devicetrees without it, requiring a reg property will
break compatibility with them.
Mark.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox