* Re: [PATCH] ASoC: wm8903: add regulator handling
From: Stephen Warren @ 2017-03-30 19:42 UTC (permalink / raw)
To: Linus Walleij, Liam Girdwood, Mark Brown
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA, Stephen Warren, Charles Keepax
In-Reply-To: <20170320091352.4115-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 03/20/2017 03:13 AM, Linus Walleij wrote:
> The WM8903 has four different voltage inputs: AVDD, CPVDD, DBVDD
> and DCVDD. On the Qualcomm APQ8060 Dragonboard these are all
> supplied from proper regulators and thus need activating and
> binding.
>
> This is a quick-and-dirty solution just grabbing and enabling the
> regulator supplies on probe() and disabling them on remove() and
> the errorpath. More elaborate power management is likely possible.
>
> I assume the nVidia designs using this codec have some hard-wired
> always-on power and will be happy with using the dummy regulators
> for this. But someone from the nVidia camp should probably check
> whether they can bind these to proper regulators instead.
>
> We also amend the DT binding document. A small change like this
> does not warrant a separate patch for augmenting these.
Tested-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Sorry for the slow response.
Tested using NVIDIA springbank/seaboard board. Just in case anyone reads
this later and wonders how: I will point out that in the baseline
v4.11-rc4, the LCD (or perhaps just its backlight) doesn't work on this
HW any more, but since the GUI login prompt plays a sound, I was still
able to validate the WM8903 change.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V8 5/6] ACPI: Support the probing on the devices which apply indirect-IO
From: Rafael J. Wysocki @ 2017-03-30 20:31 UTC (permalink / raw)
To: zhichang.yuan
Cc: catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, rafael-DgEjT+Ai2ygdnm+yROfE0A,
arnd-r2nGTMty4D4,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
mark.rutland-5wv7dgnIgG8, brian.starkey-5wv7dgnIgG8,
olof-nZhT3qVonbNeoWH0uzbU5w, lorenzo.pieralisi-5wv7dgnIgG8,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linuxarm-hv44wF8Li93QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, minyard-HInyCGIudOg,
zourongrong-Re5JQEeQqe8AvxtiuMwx3w,
john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
zhichang.yuan02-Re5JQEeQqe8AvxtiuMwx3w, kantyzc-9Onoh4P/yGk,
xuwei5-C8/M+/jPZTeaMJb+Lgu22Q
In-Reply-To: <1490887619-61732-6-git-send-email-yuanzhichang-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
On Thursday, March 30, 2017 11:26:58 PM zhichang.yuan wrote:
> On some platforms(such as Hip06/Hip07), the legacy ISA/LPC devices access I/O
> with some special host-local I/O ports known on x86. To access the I/O
> peripherals, an indirect-IO mechanism is introduced to mapped the host-local
> I/O to system logical/fake PIO similar the PCI MMIO on architectures where no
> separate I/O space exists. Just as PCI MMIO, the host I/O range should be
> registered before probing the downstream devices and set up the I/O mapping.
> But current ACPI bus probing doesn't support these indirect-IO hosts/devices.
>
> This patch introdueces a new ACPI handler for this device category. Through the
> handler attach callback, the indirect-IO hosts I/O registration is done and
> all peripherals' I/O resources are translated into logic/fake PIO before
> starting the enumeration.
Can you explain to me briefly what exactly this code is expected to be doing?
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master
From: Benjamin Herrenschmidt @ 2017-03-30 20:50 UTC (permalink / raw)
To: Christopher Bostic, Joel Stanley
Cc: Mark Rutland, devicetree, Andrew Jeffery, Greg KH, Russell King,
rostedt, Linux Kernel Mailing List, Rob Herring, Jeremy Kerr,
Edward A . James, Alistair Popple, mingo, linux-arm-kernel
In-Reply-To: <0e1bcf3a-e8d7-9f50-bdf7-2a1e7466665b@linux.vnet.ibm.com>
On Thu, 2017-03-30 at 13:15 -0500, Christopher Bostic wrote:
> > > +static void serial_in(struct fsi_master_gpio *master, struct fsi_gpio_msg *msg,
> > > + uint8_t num_bits)
> > > +{
> > > + uint8_t bit, in_bit;
> > > +
> > > + set_sda_input(master);
> > > +
> > > + for (bit = 0; bit < num_bits; bit++) {
> > > + clock_toggle(master, 1);
> > > + in_bit = sda_in(master);
> > > + msg->msg <<= 1;
> > > + msg->msg |= ~in_bit & 0x1; /* Data is negative active */
> > > + }
> > > + msg->bits += num_bi ts;
> > > +}
> > > +
> > > +static void serial_out(struct fsi_master_gpio *master,
> > > + const struct fsi_gpio_msg *cmd)
> > > +{
> > > + uint8_t bit;
> > > + uint64_t msg = ~cmd->msg; /* Data is negative active */
> > > + uint64_t sda_mask = 0x1ULL << (cmd->bits - 1);
> > > + uint64_t last_bit = ~0;
> > > + int next_bit;
> > > +
> > > + if (!cmd->bits) {
> > > + dev_warn(master->dev, "trying to output 0 bits\n");
> > > + return;
> > > + }
> > > + set_sda_output(master, 0);
> > > +
> > > + /* Send the start bit */
> > > + sda_out(master, 0);
> > > + clock_toggle(master, 1);
> > > +
> > > + /* Send the message */
> > > + for (bit = 0; bit < cmd->bits; bit++) {
> > > + next_bit = (msg & sda_mask) >> (cmd->bits - 1);
> > > + if (last_bit ^ next_bit) {
> > > + sda_out(master, next_bit);
> > > + last_bit = next_bit;
> > > + }
> > > + clock_toggle(master, 1);
> > > + msg <<= 1;
> > > + }
> > > +}
As I mentioned privately, I don't think this is right, unless your
clock signal is inverted or my protocol spec is wrong...
Your clock toggle is written so you call it right after the rising
edge. It does delay, 0, delay, 1.
But according to the FSI timing diagram I have, you need to establish
the data around the falling edge, it gets sampled by the slave on the
rising edge. So as it is, your code risks violating the slave hold
time.
On input, you need to sample on the falling edge, right before it. You
are sampling after the rising edge, so you aren't leaving enough time
for the slave to establish the data.
You could probably just flip clock_toggle() around. Make it: 0, delay,
1, delay.
That way you can do for sends: sda_out + toggle, and for receive
toggle + sda_in. That will make you establish your output data and
sample right before the falling edge, which should be ok provided the
diagram I have is right.
Cheers,
Ben.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: r7s72100: fix ethernet clock parent
From: Chris Brandt @ 2017-03-30 21:16 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Mark Rutland, Geert Uytterhoeven
Cc: devicetree, linux-renesas-soc, Chris Brandt
Technically, the Ethernet block is run off the 133MHz Bus (B) clock, not
the 33MHz Peripheral 0 (P0) clock.
Fixes: 969244f9c720 ("ARM: dts: r7s72100: add ethernet clock to device tree")
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
---
arch/arm/boot/dts/r7s72100.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 34994afa9d15..c199c4eea73e 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -121,7 +121,7 @@
#clock-cells = <1>;
compatible = "renesas,r7s72100-mstp-clocks", "renesas,cpg-mstp-clocks";
reg = <0xfcfe0430 4>;
- clocks = <&p0_clk>;
+ clocks = <&b_clk>;
clock-indices = <R7S72100_CLK_ETHER>;
clock-output-names = "ether";
};
--
2.11.0
^ permalink raw reply related
* Applied "MAINTAINERS: Add missing regulator regex for Wolfson Arizona parts" to the regulator tree
From: Mark Brown @ 2017-03-30 21:23 UTC (permalink / raw)
To: Charles Keepax; +Cc: Mark Brown
In-Reply-To: <1490710484-25277-3-git-send-email-ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
The patch
MAINTAINERS: Add missing regulator regex for Wolfson Arizona parts
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From cdf4275e957c6bad3756e98942341667f1d7de7d Mon Sep 17 00:00:00 2001
From: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Date: Tue, 28 Mar 2017 15:14:39 +0100
Subject: [PATCH] MAINTAINERS: Add missing regulator regex for Wolfson Arizona
parts
The maintainers entry for the Wolfson parts seems to be missing
an entry that covers the Arizona regulator drivers, correct this by
adding one.
Signed-off-by: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9bf5aa617cf2..ef0c801aff45 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13119,6 +13119,7 @@ F: drivers/mfd/cs47l24*
F: drivers/power/supply/wm83*.c
F: drivers/rtc/rtc-wm83*.c
F: drivers/regulator/wm8*.c
+F: drivers/regulator/arizona*
F: drivers/video/backlight/wm83*_bl.c
F: drivers/watchdog/wm83*_wdt.c
F: include/linux/mfd/arizona/
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Applied "regulator: arizona-ldo1: Avoid potential memory leak reading init_data" to the regulator tree
From: Mark Brown @ 2017-03-30 21:23 UTC (permalink / raw)
To: Charles Keepax; +Cc: Mark Brown
In-Reply-To: <1490710484-25277-2-git-send-email-ckeepax@opensource.wolfsonmicro.com>
The patch
regulator: arizona-ldo1: Avoid potential memory leak reading init_data
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 0feb837a42c95fee901e03f76a1266db85ceb6ec Mon Sep 17 00:00:00 2001
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date: Tue, 28 Mar 2017 15:14:38 +0100
Subject: [PATCH] regulator: arizona-ldo1: Avoid potential memory leak reading
init_data
The device argument passed to of_get_regulator_init_data is used to
do some devres memory allocation. Currently the driver passes the MFD
device pointer to this function, this could result in the init_data
allocation being leaked if the regulator is unbound but the MFD isn't.
Correct this issue by correctly passing the local platform device.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/regulator/arizona-ldo1.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/arizona-ldo1.c b/drivers/regulator/arizona-ldo1.c
index 302b57cb89c6..cf558168664d 100644
--- a/drivers/regulator/arizona-ldo1.c
+++ b/drivers/regulator/arizona-ldo1.c
@@ -186,7 +186,8 @@ static const struct regulator_init_data arizona_ldo1_wm5110 = {
.num_consumer_supplies = 1,
};
-static int arizona_ldo1_of_get_pdata(struct arizona *arizona,
+static int arizona_ldo1_of_get_pdata(struct device *dev,
+ struct arizona *arizona,
struct regulator_config *config,
const struct regulator_desc *desc)
{
@@ -212,8 +213,7 @@ static int arizona_ldo1_of_get_pdata(struct arizona *arizona,
if (init_node) {
config->of_node = init_node;
- init_data = of_get_regulator_init_data(arizona->dev, init_node,
- desc);
+ init_data = of_get_regulator_init_data(dev, init_node, desc);
if (init_data) {
init_data->consumer_supplies = &ldo1->supply;
@@ -283,7 +283,8 @@ static int arizona_ldo1_probe(struct platform_device *pdev)
if (IS_ENABLED(CONFIG_OF)) {
if (!dev_get_platdata(arizona->dev)) {
- ret = arizona_ldo1_of_get_pdata(arizona, &config, desc);
+ ret = arizona_ldo1_of_get_pdata(&pdev->dev, arizona,
+ &config, desc);
if (ret < 0)
return ret;
}
--
2.11.0
^ permalink raw reply related
* Applied "regulator: arizona-micsupp: Avoid potential memory leak reading init_data" to the regulator tree
From: Mark Brown @ 2017-03-30 21:23 UTC (permalink / raw)
To: Charles Keepax; +Cc: Mark Brown
In-Reply-To: <1490710484-25277-1-git-send-email-ckeepax@opensource.wolfsonmicro.com>
The patch
regulator: arizona-micsupp: Avoid potential memory leak reading init_data
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 2543ef3173889373fc07df61520e1bb42a99c85e Mon Sep 17 00:00:00 2001
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date: Tue, 28 Mar 2017 15:14:37 +0100
Subject: [PATCH] regulator: arizona-micsupp: Avoid potential memory leak
reading init_data
The device argument passed to of_get_regulator_init_data is used to
do some devres memory allocation. Currently the driver passes the MFD
device pointer to this function, this could result in the init_data
allocation being leaked if the regulator is unbound but the MFD isn't.
Correct this issue by correctly passing the local platform device.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/regulator/arizona-micsupp.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/arizona-micsupp.c b/drivers/regulator/arizona-micsupp.c
index fcb98dbda837..0ed14e41de11 100644
--- a/drivers/regulator/arizona-micsupp.c
+++ b/drivers/regulator/arizona-micsupp.c
@@ -197,7 +197,8 @@ static const struct regulator_init_data arizona_micsupp_ext_default = {
.num_consumer_supplies = 1,
};
-static int arizona_micsupp_of_get_pdata(struct arizona *arizona,
+static int arizona_micsupp_of_get_pdata(struct device *dev,
+ struct arizona *arizona,
struct regulator_config *config,
const struct regulator_desc *desc)
{
@@ -211,7 +212,7 @@ static int arizona_micsupp_of_get_pdata(struct arizona *arizona,
if (np) {
config->of_node = np;
- init_data = of_get_regulator_init_data(arizona->dev, np, desc);
+ init_data = of_get_regulator_init_data(dev, np, desc);
if (init_data) {
init_data->consumer_supplies = &micsupp->supply;
@@ -266,8 +267,8 @@ static int arizona_micsupp_probe(struct platform_device *pdev)
if (IS_ENABLED(CONFIG_OF)) {
if (!dev_get_platdata(arizona->dev)) {
- ret = arizona_micsupp_of_get_pdata(arizona, &config,
- desc);
+ ret = arizona_micsupp_of_get_pdata(&pdev->dev, arizona,
+ &config, desc);
if (ret < 0)
return ret;
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCHv5 05/11] ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi
From: Krzysztof Kozlowski @ 2017-03-30 21:34 UTC (permalink / raw)
To: Hans Verkuil
Cc: linux-media, Daniel Vetter, Russell King, dri-devel,
linux-samsung-soc, Inki Dae, Marek Szyprowski,
Javier Martinez Canillas, Benjamin Gaignard, Hans Verkuil,
devicetree
In-Reply-To: <20170329141543.32935-6-hverkuil@xs4all.nl>
On Wed, Mar 29, 2017 at 04:15:37PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> Add the new hdmi phandle to exynos4.dtsi. This phandle is needed by the
> s5p-cec driver to initialize the CEC notifier framework.
>
> Tested with my Odroid U3.
>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> CC: linux-samsung-soc@vger.kernel.org
> CC: devicetree@vger.kernel.org
> CC: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> arch/arm/boot/dts/exynos4.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
Thanks, applied. Now I noticed that you need it for maintaining the
bisectability for this driver (although it is a staging driver). In that
case, if anyone needs this as well then:
The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-hdmi-cec-4.12
for you to fetch changes up to 192c1df4a75499a6ab70aca38c6a7e5e40013d77:
ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi (2017-03-31 00:21:18 +0300)
----------------------------------------------------------------
Add to hdmi-cec node a phandle to hdmi node for new hdmi-cec notifier.
----------------------------------------------------------------
Hans Verkuil (1):
ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi
arch/arm/boot/dts/exynos4.dtsi | 1 +
1 file changed, 1 insertion(+)
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCHv5 06/11] s5p-cec.txt: document the HDMI controller phandle
From: Krzysztof Kozlowski @ 2017-03-30 21:37 UTC (permalink / raw)
To: Hans Verkuil
Cc: linux-media, Daniel Vetter, Russell King, dri-devel,
linux-samsung-soc, Inki Dae, Marek Szyprowski,
Javier Martinez Canillas, Benjamin Gaignard, Hans Verkuil,
devicetree
In-Reply-To: <20170329141543.32935-7-hverkuil@xs4all.nl>
On Wed, Mar 29, 2017 at 04:15:38PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> Update the bindings documenting the new hdmi phandle.
>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> CC: linux-samsung-soc@vger.kernel.org
> CC: devicetree@vger.kernel.org
> CC: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> Documentation/devicetree/bindings/media/s5p-cec.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master (fwd)
From: Julia Lawall @ 2017-03-30 21:39 UTC (permalink / raw)
To: Christopher Bostic
Cc: joel-U3u1mxZcP9KHXe+LvDLADg, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
andrew-zrmu5oMJ5Fs, alistair-Y4h6yKqj69EXC2x5gXVKYQ,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r, Edward A . James,
Jeremy Kerr, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
rostedt-nx8X9YLhiw1AfugRpC6u6w, mingo-H+wXaHxf7aLQT0dZR+AlfA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
kbuild-all-JC7UmRfGjtg
Is master on line 514 allocated with kmalloc, or the devm call on line
522?
julia
---------- Forwarded message ----------
Date: Fri, 31 Mar 2017 00:15:09 +0800
From: kbuild test robot <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: kbuild-JC7UmRfGjtg@public.gmane.org
Cc: Julia Lawall <julia.lawall-L2FTfq7BK8M@public.gmane.org>
Subject: Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master
Hi Chris,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.11-rc4 next-20170330]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Christopher-Bostic/FSI-device-driver-implementation/20170330-184914
:::::: branch date: 5 hours ago
:::::: commit date: 5 hours ago
>> drivers/fsi/fsi-master-gpio.c:514:1-6: WARNING: invalid free of devm_ allocated data
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout f4bd3b6a41c7a59e9ce2e65947a4d3dfc2ee4a29
vim +514 drivers/fsi/fsi-master-gpio.c
f4bd3b6a Chris Bostic 2017-03-29 498 {
f4bd3b6a Chris Bostic 2017-03-29 499 struct fsi_master_gpio *master = to_fsi_master_gpio(_master);
f4bd3b6a Chris Bostic 2017-03-29 500
f4bd3b6a Chris Bostic 2017-03-29 501 if (link != 0)
f4bd3b6a Chris Bostic 2017-03-29 502 return -ENODEV;
f4bd3b6a Chris Bostic 2017-03-29 503 if (master->gpio_enable)
f4bd3b6a Chris Bostic 2017-03-29 504 gpiod_set_value(master->gpio_enable, 1);
f4bd3b6a Chris Bostic 2017-03-29 505
f4bd3b6a Chris Bostic 2017-03-29 506 return 0;
f4bd3b6a Chris Bostic 2017-03-29 507 }
f4bd3b6a Chris Bostic 2017-03-29 508
f4bd3b6a Chris Bostic 2017-03-29 509 static void fsi_master_gpio_release(struct device *dev)
f4bd3b6a Chris Bostic 2017-03-29 510 {
f4bd3b6a Chris Bostic 2017-03-29 511 struct fsi_master_gpio *master = to_fsi_master_gpio(
f4bd3b6a Chris Bostic 2017-03-29 512 dev_to_fsi_master(dev));
f4bd3b6a Chris Bostic 2017-03-29 513
f4bd3b6a Chris Bostic 2017-03-29 @514 kfree(master);
f4bd3b6a Chris Bostic 2017-03-29 515 }
f4bd3b6a Chris Bostic 2017-03-29 516
f4bd3b6a Chris Bostic 2017-03-29 517 static int fsi_master_gpio_probe(struct platform_device *pdev)
f4bd3b6a Chris Bostic 2017-03-29 518 {
f4bd3b6a Chris Bostic 2017-03-29 519 struct fsi_master_gpio *master;
f4bd3b6a Chris Bostic 2017-03-29 520 struct gpio_desc *gpio;
f4bd3b6a Chris Bostic 2017-03-29 521
f4bd3b6a Chris Bostic 2017-03-29 522 master = devm_kzalloc(&pdev->dev, sizeof(*master), GFP_KERNEL);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V8 0/7] LPC: legacy ISA I/O support
From: dann frazier @ 2017-03-30 21:42 UTC (permalink / raw)
To: zhichang.yuan
Cc: Catalin Marinas, Will Deacon, Rob Herring, Frank Rowand,
Bjorn Helgaas, rafael, Arnd Bergmann, linux-arm-kernel,
Mark Rutland, devicetree@vger.kernel.org, lorenzo.pieralisi,
Gabriele Paoloni, Corey Minyard, benh, John Garry,
linux-kernel@vger.kernel.org, xuwei5, linuxarm, linux-acpi,
Zou Rongrong, linux-pci, olof
In-Reply-To: <1490887619-61732-1-git-send-email-yuanzhichang@hisilicon.com>
On Thu, Mar 30, 2017 at 9:26 AM, zhichang.yuan
<yuanzhichang@hisilicon.com> wrote:
> This patchset supports the IPMI-bt device attached to the Low-Pin-Count
> interface implemented on Hisilicon Hip06/Hip07 SoC.
> -----------
> | LPC host|
> | |
> -----------
> |
> _____________V_______________LPC
> | |
> V V
> ------------
> | BT(ipmi)|
> ------------
>
> When master accesses those peripherals beneath the Hip06/Hip07 LPC, a specific
> LPC driver is needed to make LPC host generate the standard LPC I/O cycles with
> the target peripherals'I/O port addresses. But on curent arm64 world, there is
> no real I/O accesses. All the I/O operations through in/out pair are based on
> MMIO which is not satisfied the I/O mechanism on Hip06/Hip07 LPC.
> To solve this issue and keep the relevant existing peripherals' driver
> untouched, this patchset implements:
> - introduces a generic I/O space management framwork, LIBIO, to support I/O
> operations of both MMIO buses and the host controllers which access their
> peripherals with host local I/O addresses;
> - redefines the in/out accessors to provide unified interfaces for MMIO and
> legacy I/O. Based on the LIBIO, the calling of in/out() from upper-layer
> drivers, such as ipmi-si, will be redirected to the corresponding
> device-specific I/O hooks to perfrom the I/O accesses.
> Based on this patch-set, all the I/O accesses to Hip06/Hip07 LPC peripherals can
> be supported without any changes on the existing ipmi-si driver.
>
> Changes from V7:
> - Based on Arnd's comment, rename the LIBIO as LOGIC_PIO;
> - Improved the mapping process in LOGIC_PIO to gain better efficiency when
> redirecting the I/O accesses to right device driver;
> - To reduce the impact on PCI MMIO to a minimum, add a new
> CONFIG_INDIRECT_PIO for indirect-IO hosts/devices;
> - Added a new ACPI handler for indirect-IO hosts/devices;
> - Fixed the compile issues on V6;
>
> Changes from V6:
> - According to the comments from Bjorn and Alex, merge PCI IO and indirect-IO
> into a generic I/O space management, LIBIO;
> - Adopted the '_DEP' to replace the platform bus notifier. In this way, we can
> ensure the LPC peripherals' I/O resources had been translated to logical IO
> before the LPC peripheral enumeration;
> - Replaced the rwlock with rcu list based on Alex's suggestion;
> - Applied relaxed write/read to LPC driver;
> - Some bugs fixing and some optimazations based on the comments of V6;
>
> Changes from V5:
> - Made the extio driver more generic and locate in lib/;
> - Supported multiple indirect-IO bus instances;
> - Extended the pci_register_io_range() to support indirect-IO, then dropped
> the I/O reservation used in previous patchset;
> - Reimplemented the ACPI LPC support;
> - Fixed some bugs, including the compile error on other archs, the module
> building failure found by Ming Lei, etc;
>
> Changes from V4:
> - Some revises based on the comments from Bjorn, Rob on V4;
> - Fixed the compile error on some platforms, such as openrisc;
>
> Changes from V3:
> - UART support deferred to a separate patchset; This patchset only support
> ipmi device under LPC;
> - LPC bus I/O range is fixed to 0 ~ (PCIBIOS_MIN_IO - 1), which is separeted
> from PCI/PCIE PIO space;
> - Based on Arnd's remarks, removed the ranges property from Hip06 lpc dts and
> added a new fixup function, of_isa_indirect_io(), to get the I/O address
> directly from LPC dts configurations;
> - Support in(w,l)/out(w,l) for Hip06 lpc I/O;
> - Decouple the header file dependency on the gerenic io.h by defining in/out
> as normal functions in c file;
> - removed unused macro definitions in the LPC driver;
>
> Changes from V2:
> - Support the PIO retrieval from the linux PIO generated by
> pci_address_to_pio. This method replace the 4K PIO reservation in V2;
> - Support the flat-tree earlycon;
> - Some revises based on Arnd's remarks;
> - Make sure the linux PIO range allocated to Hip06 LPC peripherals starts
> from non-ZERO;
>
> Changes from V1:
> - Support the ACPI LPC device;
> - Optimize the dts LPC driver in ISA compatible mode;
> - Reserve the IO range below 4K in avoid the possible conflict with PCI host
> IO ranges;
> - Support the LPC uart and relevant earlycon;
>
> V7 thread here: https://lkml.org/lkml/2017/3/12/279
> v6 thread here: https://lkml.org/lkml/2017/1/24/25
> v5 thread here: https://lkml.org/lkml/2016/11/7/955
> v4 thread here: https://lkml.org/lkml/2016/10/20/149
> v3 thread here: https://lkml.org/lkml/2016/9/14/326
> v2 thread here: https://lkml.org/lkml/2016/9/7/356
> v1 thread here: https://lkml.org/lkml/2015/12/29/154
>
>
> Signed-off-by: Zhichang Yuan <yuanzhichang@hisilicon.com>
> zhichang.yuan (6):
> LIBIO: Introduce a generic PIO mapping method
> PCI: Apply the new generic I/O management on PCI IO hosts
> OF: Add missing I/O range exception for indirect-IO devices
> LPC: Support the device-tree LPC host on Hip06/Hip07
> ACPI: Support the probing on the devices which apply indirect-IO
> LPC: Add the ACPI LPC support
>
> .../arm/hisilicon/hisilicon-low-pin-count.txt | 33 ++
> MAINTAINERS | 8 +
> arch/arm64/boot/dts/hisilicon/hip06-d03.dts | 4 +
> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 14 +
> arch/arm64/boot/dts/hisilicon/hip07-d05.dts | 4 +
> arch/arm64/boot/dts/hisilicon/hip07.dtsi | 14 +
> drivers/acpi/Makefile | 1 +
> drivers/acpi/acpi_indirectio.c | 344 +++++++++++++
> drivers/acpi/internal.h | 5 +
> drivers/acpi/pci_root.c | 8 +-
> drivers/acpi/scan.c | 1 +
> drivers/bus/Kconfig | 9 +
> drivers/bus/Makefile | 1 +
> drivers/bus/hisi_lpc.c | 547 +++++++++++++++++++++
> drivers/of/address.c | 95 +++-
> drivers/pci/pci.c | 104 +---
> include/asm-generic/io.h | 50 ++
> include/linux/logic_pio.h | 174 +++++++
> include/linux/pci.h | 3 +-
> lib/Kconfig | 26 +
> lib/Makefile | 2 +
> lib/logic_pio.c | 413 ++++++++++++++++
> 22 files changed, 1758 insertions(+), 102 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> create mode 100644 drivers/acpi/acpi_indirectio.c
> create mode 100644 drivers/bus/hisi_lpc.c
> create mode 100644 include/linux/logic_pio.h
> create mode 100644 lib/logic_pio.c
Booted up on a D05, was able to use the LPC-connected IPMI interface.
Tested-by: dann frazier <dann.frazier@canonical.com>
^ permalink raw reply
* Re: [PATCH 1/2] drm/bridge: ti-tfp410: support hpd via gpio
From: Christopher Spinrath @ 2017-03-30 21:51 UTC (permalink / raw)
To: Archit Taneja, Jyri Sarha
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David Airlie, Fabio Estevam, Russell King - ARM Linux,
DRI mailing list, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
Igor Grinberg, Sascha Hauer, Fabio Estevam, Shawn Guo,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <e63e628794b044c2a615091697622d50-cBaz+nnMw18umhiu9RXYRl5UTUQ924AY@public.gmane.org>
Hi,
On 03/30/2017 11:49 AM, Archit Taneja wrote:
>
>
> On 03/28/2017 07:02 PM, Jyri Sarha wrote:
>> On 03/27/17 08:58, Archit Taneja wrote:
>>> Hi,
>>>
>>> On 03/07/2017 03:21 AM, Christopher Spinrath wrote:
>>>> Hi Fabio,
>>>>
>>>> On 03/06/2017 10:46 PM, Fabio Estevam wrote:
>>>>> Hi Christopher,
>>>>>
>>>>> On Mon, Mar 6, 2017 at 6:40 PM,
>>>>> <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org> wrote:
>>>>>> From: Christopher Spinrath <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org>
>>>>>>
>>>>>> On some boards the hpd pin of a hdmi connector is wired up to a gpio
>>>>>> pin. Since in the DRM world the tfp410 driver is responsible for
>>>>>> handling the connector, add support for hpd gpios in this very
>>>>>> driver.
>>>>>>
>>>>>> Signed-off-by: Christopher Spinrath
>>>>>> <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org>
>>>>>> ---
>>>>>> drivers/gpu/drm/bridge/ti-tfp410.c | 72
>>>>>> ++++++++++++++++++++++++++++++++++++--
>>>>>
>> ...
>>>>
>>>
>>> The patch looks good to me.
>>>
>>> Jyri,
>>>
>>> Is it possible for you to verify this on Beaglebone platform?
>>>
>>
>> If I read my BeagleBone DVI-D Cape docs right, it does not have the HPD
>> pin connected. At least it does not mention any gpio that could be used
>> for the purpose. So I can not easily test this patch in real world
>> situation. For what it is worth the patch looks ok to me too.
>
> Thanks for the review. I looked at the tfp410 data sheet[1], there isn't
> a HPD pin on the chip at all. My guess is that boards using tfp410 most
> likely have the HPD pin routed to the SoC from the HDMI connector
> (with a level shifter/shield in between).
Exactly. I tried to say that in the commit message (and, actually,
that's what I did in Patch 2/2 for the Utilite Pro).
Thanks,
Christopher
> We would eventually need to move the both ddc and hpd stuff to
> a generic hdmi connector driver later on. I've queued this to
> drm-misc-next.
>
> [1]: http://www.ti.com/lit/ds/symlink/tfp410.pdf
>
> Archit
>
>>
>> Best regards,
>> Jyri
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] mtd: move code reading DT specified part probes to the common place
From: Rafał Miłecki @ 2017-03-30 21:53 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Handling (creating) partitions for flash devices requires using a proper
driver that will read partition table (out of somewhere). We can't
simply try all existing drivers one by one, so MTD subsystem allows
drivers to specify a list of applicable part probes.
So far physmap_of was the only driver with support for linux,part-probe
DT property. Other ones had list or probes hardcoded which wasn't making
them really flexible. It prevented using common flash drivers on
platforms that required some specific partition table access.
This commit moves support for mentioned DT property to the common place
so it can be reused by other drivers.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
This patch is based on top of
[PATCH] mtd: physmap_of: use OF helpers for reading strings
---
drivers/mtd/maps/physmap_of.c | 39 ++++++---------------------------------
drivers/of/Kconfig | 6 ++++++
drivers/of/Makefile | 1 +
drivers/of/of_mtd.c | 30 ++++++++++++++++++++++++++++++
include/linux/of_mtd.h | 25 +++++++++++++++++++++++++
5 files changed, 68 insertions(+), 33 deletions(-)
create mode 100644 drivers/of/of_mtd.c
create mode 100644 include/linux/of_mtd.h
diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index 62fa6836f218..fa54c07eb118 100644
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -22,6 +22,7 @@
#include <linux/mtd/concat.h>
#include <linux/of.h>
#include <linux/of_address.h>
+#include <linux/of_mtd.h>
#include <linux/of_platform.h>
#include <linux/slab.h>
#include "physmap_of_gemini.h"
@@ -114,33 +115,6 @@ static struct mtd_info *obsolete_probe(struct platform_device *dev,
static const char * const part_probe_types_def[] = {
"cmdlinepart", "RedBoot", "ofpart", "ofoldpart", NULL };
-static const char * const *of_get_probes(struct device_node *dp)
-{
- const char **res;
- int count;
-
- count = of_property_count_strings(dp, "linux,part-probe");
- if (count < 0)
- return part_probe_types_def;
-
- res = kzalloc((count + 1) * sizeof(*res), GFP_KERNEL);
- if (!res)
- return NULL;
-
- count = of_property_read_string_array(dp, "linux,part-probe", res,
- count);
- if (count < 0)
- return NULL;
-
- return res;
-}
-
-static void of_free_probes(const char * const *probes)
-{
- if (probes != part_probe_types_def)
- kfree(probes);
-}
-
static const struct of_device_id of_flash_match[];
static int of_flash_probe(struct platform_device *dev)
{
@@ -310,14 +284,13 @@ static int of_flash_probe(struct platform_device *dev)
info->cmtd->dev.parent = &dev->dev;
mtd_set_of_node(info->cmtd, dp);
- part_probe_types = of_get_probes(dp);
- if (!part_probe_types) {
- err = -ENOMEM;
- goto err_out;
- }
+ part_probe_types = of_mtd_get_probes(dp);
+ if (!part_probe_types)
+ part_probe_types = part_probe_types_def;
mtd_device_parse_register(info->cmtd, part_probe_types, NULL,
NULL, 0);
- of_free_probes(part_probe_types);
+ if (part_probe_types != part_probe_types_def)
+ of_mtd_free_probes(part_probe_types);
kfree(mtd_list);
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index ba7b034b2b91..18ac835a1ce4 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -78,6 +78,12 @@ config OF_MDIO
help
OpenFirmware MDIO bus (Ethernet PHY) accessors
+config OF_MTD
+ def_tristate MTD
+ depends on MTD
+ help
+ OpenFirmware MTD accessors
+
config OF_PCI
def_tristate PCI
depends on PCI
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index d7efd9d458aa..965c2a691337 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_OF_IRQ) += irq.o
obj-$(CONFIG_OF_NET) += of_net.o
obj-$(CONFIG_OF_UNITTEST) += unittest.o
obj-$(CONFIG_OF_MDIO) += of_mdio.o
+obj-$(CONFIG_OF_MTD) += of_mtd.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
diff --git a/drivers/of/of_mtd.c b/drivers/of/of_mtd.c
new file mode 100644
index 000000000000..ff851d7742d5
--- /dev/null
+++ b/drivers/of/of_mtd.c
@@ -0,0 +1,30 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/of.h>
+#include <linux/of_mtd.h>
+
+const char * const *of_mtd_get_probes(struct device_node *np)
+{
+ const char **res;
+ int count;
+
+ count = of_property_count_strings(np, "linux,part-probe");
+ if (count < 0)
+ return NULL;
+
+ res = kzalloc((count + 1) * sizeof(*res), GFP_KERNEL);
+ if (!res)
+ return NULL;
+
+ count = of_property_read_string_array(np, "linux,part-probe", res,
+ count);
+ if (count < 0)
+ return NULL;
+
+ return res;
+}
+EXPORT_SYMBOL(of_mtd_get_probes);
diff --git a/include/linux/of_mtd.h b/include/linux/of_mtd.h
new file mode 100644
index 000000000000..d55f4aa684c5
--- /dev/null
+++ b/include/linux/of_mtd.h
@@ -0,0 +1,25 @@
+#ifndef __OF_MTD_H
+#define __OF_MTD_H
+
+#include <linux/slab.h>
+
+struct device_node;
+
+#ifdef CONFIG_OF_MTD
+const char * const *of_mtd_get_probes(struct device_node *np);
+static inline void of_mtd_free_probes(const char * const *probes)
+{
+ kfree(probes);
+}
+#else
+const char * const *of_mtd_get_probes(struct device_node *np)
+{
+ return NULL;
+}
+
+static inline void of_mtd_free_probes(const char * const *probes)
+{
+}
+#endif
+
+#endif
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: mtd: document linux,part-probe property
From: Rafał Miłecki @ 2017-03-30 21:53 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170330215332.32699-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Support for this property has been introduced in 2010 with commit
9d5da3a9b849 ("mtd: extend physmap_of to let the device tree specify the
parition probe") but it was never documented. Fix this by adding a
proper description and example.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
Documentation/devicetree/bindings/mtd/common.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/common.txt b/Documentation/devicetree/bindings/mtd/common.txt
index fc068b923d7a..1ada70e718b2 100644
--- a/Documentation/devicetree/bindings/mtd/common.txt
+++ b/Documentation/devicetree/bindings/mtd/common.txt
@@ -6,10 +6,17 @@ Optional properties:
controller based name) in order to ease flash device identification
and/or describe what they are used for.
+- linux,part-probe: if present, this property should contain a list of strings
+ with partition probes to be used for the flash device. A role of partition
+ probe (parser) is to read/construct partition table and register found
+ partitions. Getting partition table may be platform or device specific so
+ various devices may use various Linux drivers for this purpose.
+
Example:
flash@0 {
label = "System-firmware";
+ linux,part-probe = "cmdlinepart", "ofpart";
/* flash type specific properties */
};
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] Documentation: dt: Add binding for /secure-chosen/stdout-path
From: Rob Herring @ 2017-03-30 22:28 UTC (permalink / raw)
To: Jerome Forissier
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
jens.wiklander-QSEj5FYQhm4dnm+yROfE0A,
christoffer.dall-QSEj5FYQhm4dnm+yROfE0A,
peter.maydell-QSEj5FYQhm4dnm+yROfE0A, robin.murphy-5wv7dgnIgG8
In-Reply-To: <e3e007ef9ee6a622ae4ccc74fd0fca32b3c5dfb5.1488531370.git.jerome.forissier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Fri, Mar 03, 2017 at 10:24:33AM +0100, Jerome Forissier wrote:
> Some platforms may use a single device tree to describe two address
> spaces, as described in d9f43babb998 ("Documentation: dt: Add bindings
> for Secure-only devices"). For these platforms it makes sense to define
> a secure counterpart of /chosen, namely: /secure-chosen. This new node
> is meant to be used by the secure firmware to pass data to the secure
> OS. Only the stdout-path property is supported for now.
>
> Signed-off-by: Jerome Forissier <jerome.forissier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/arm/secure.txt | 19 ++++++++++++++++++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> v2
>
> - Clarify the expected behavior when /secure-chosen/stdout-path is not
> present (either the property or the node itself), as proposed by Peter
> and Robin. Note that I have made the fallback to /chosen optional.
I'm okay with this, but would like to hold off merging it until your are
really using it. You did say you were "experimenting" and it doesn't
sound like the DT usage in secure world is that far along. I just want
to see if there are other issues that come up.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] clk: qcom: Update DT bindings for MSM8660 LCC
From: Rob Herring @ 2017-03-30 22:31 UTC (permalink / raw)
To: Linus Walleij
Cc: Michael Turquette, Stephen Boyd, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170324082424.6143-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Fri, Mar 24, 2017 at 09:24:24AM +0100, Linus Walleij wrote:
> This adds the right compatible string and header for the
> MSM8660 LCC and some new defines to the dt-bindings header.
>
> Take this opportunity to spell out the acronym LPASS for
> Low-power Audio Subsystem.
>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> .../devicetree/bindings/clock/qcom,lcc.txt | 5 +--
> include/dt-bindings/clock/qcom,lcc-msm8660.h | 40 ++++++++++++++++++++++
> 2 files changed, 43 insertions(+), 2 deletions(-)
> create mode 100644 include/dt-bindings/clock/qcom,lcc-msm8660.h
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc
From: Rob Herring @ 2017-03-30 22:39 UTC (permalink / raw)
To: Jacopo Mondi
Cc: geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490368934-12494-3-git-send-email-jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
On Fri, Mar 24, 2017 at 04:22:09PM +0100, Jacopo Mondi wrote:
> Add device tree bindings documentation for Renesas RZ/A1 gpio and pin
> controller.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
> ---
> .../bindings/pinctrl/renesas,rza1-pinctrl.txt | 143 +++++++++++++++++++++
> 1 file changed, 143 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] doc: Add bindings document for Xilinx LogiCore PR Decoupler
From: Rob Herring @ 2017-03-30 22:44 UTC (permalink / raw)
To: Alan Tull
Cc: Greg Kroah-Hartman, Moritz Fischer,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fpga-u79uwXL29TY76Z2rM5mHXA, Moritz Fischer, Michal Simek,
Sören Brinkmann, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170324153321.4168-2-atull-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Fri, Mar 24, 2017 at 10:33:20AM -0500, Alan Tull wrote:
> From: Moritz Fischer <mdf-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Please use "dt-bindings: fpga: ..." for the subject.
>
> This adds the binding documentation for the Xilinx LogiCORE PR
> Decoupler soft core.
>
> Signed-off-by: Moritz Fischer <mdf-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Michal Simek <michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
> Acked-by: Alan Tull <atull-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
I'm confused why you are sending these instead of Moritz? If it goes
through you, then it should have your S-o-B too.
> Cc: Sören Brinkmann <soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
> .../bindings/fpga/xilinx-pr-decoupler.txt | 35 ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
>
> diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> new file mode 100644
> index 000000000000..2c527ac30398
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> @@ -0,0 +1,35 @@
> +Xilinx LogiCORE Partial Reconfig Decoupler Softcore
> +
> +The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
> +decouplers / fpga bridges.
> +The controller can decouple/disable the bridges which prevents signal
> +changes from passing through the bridge. The controller can also
> +couple / enable the bridges which allows traffic to pass through the
> +bridge normally.
> +
> +The Driver supports only MMIO handling. A PR region can have multiple
> +PR Decouplers which can be handled independently or chained via decouple/
> +decouple_status signals.
> +
> +Required properties:
> +- compatible : Should contain "xlnx,pr-decoupler-1.00" or "xlnx,pr-decoupler"
I'd drop xlnx,pr-decoupler, but in any case, it should not be OR rather
"followed by". Plus the example has both.
> +- regs : base address and size for decoupler module
> +- clocks : input clock to IP
> +- clock-names : should contain "aclk"
> +
> +Optional properties:
> +- bridge-enable : 0 if driver should disable bridge at startup
> + 1 if driver should enable bridge at startup
> + Default is to leave bridge in current state.
> +
> +See Documentation/devicetree/bindings/fpga/fpga-region.txt for generic bindings.
> +
> +Example:
> + fpga-bridge@100000450 {
> + compatible = "xlnx,pr-decoupler-1.00",
> + "xlnx-pr-decoupler";
> + regs = <0x10000045 0x10>;
> + clocks = <&clkc 15>;
> + clock-names = "aclk";
> + bridge-enable = <0>;
> + };
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH linux v5 1/2] Documentation: dt-bindings: Document bindings for ASPEED AST2400/AST2500 PWM and Fan tach controller device driver
From: Rob Herring @ 2017-03-30 22:46 UTC (permalink / raw)
To: Jaghathiswari Rankappagounder Natarajan
Cc: joel, jdelvare, linux, linux-hwmon, linux-kernel, openbmc, corbet,
linux-doc, mark.rutland, devicetree
In-Reply-To: <20170324181723.29379-2-jaghu@google.com>
On Fri, Mar 24, 2017 at 11:17:22AM -0700, Jaghathiswari Rankappagounder Natarajan wrote:
> This binding provides interface for adding values related to ASPEED
> AST2400/2500 PWM and Fan tach controller support.
> The PWM controller can support upto 8 PWM output ports.
> The Fan tach controller can support upto 16 tachometer inputs.
>
> Signed-off-by: Jaghathiswari Rankappagounder Natarajan <jaghu@google.com>
> ---
> v5:
> - Changed the naming scheme to aspeed,ast2400/2500-pwm-tacho
> - Removed gpio pin muxing
> - Added aspeed vendor prefix for fan-tach-ch
> - Changed to fan@0/1
> - Changed reg to 32 bits
>
> v4:
> - Used 'reg'
>
> v3:
> - Made the structure more common
>
> v2:
> - Removed '_' in node and property names
> - Gave some explanation for the properties used
>
> .../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt | 68 ++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
>
> diff --git a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
> new file mode 100644
> index 000000000000..f96d32bfcdfa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
> @@ -0,0 +1,68 @@
> +ASPEED AST2400/AST2500 PWM and Fan Tacho controller device driver
> +
> +The ASPEED PWM controller can support upto 8 PWM outputs. The ASPEED Fan Tacho
> +controller can support upto 16 Fan tachometer inputs.
> +
> +There can be upto 8 fans supported. Each fan can have one PWM output and
> +one/two Fan tach inputs.
> +
> +Required properties for pwm-tacho node:
> +- #address-cells : should be 1.
> +
> +- #size-cells : should be 1.
> +
> +- reg : address and length of the register set for the device.
> +
> +- pinctrl-names : a pinctrl state named "default" must be defined.
> +
> +- pinctrl-0 : phandle referencing pin configuration of the PWM ports.
> +
> +- compatible : should be "aspeed,ast2400-pwm-tacho" for AST2400 and
> + "aspeed,ast2500-pwm-tacho" for AST2500.
> +
> +- clocks : a fixed clock providing input clock frequency(PWM
> + and Fan Tach clock)
> +
> +fan subnode format:
> +===================
> +Under fan subnode there can upto 8 child nodes, with each child node
> +representing a fan. If there are 8 fans each fan can have one PWM port and
> +one/two Fan tach inputs.
> +
> +Required properties for each child node:
> +- reg : should specify PWM source port.
> + integer value in the range 0 to 7 with 0 indicating PWM port A and
> + 7 indicating PWM port H.
> +
> +- aspeed-fan-tach-ch : should specify the Fan tach input channel.
aspeed,fan-tach-ch
With that,
Acked-by: Rob Herring <robh@kernel.org>
> + integer value in the range 0 through 15, with 0 indicating
> + Fan tach channel 0 and 15 indicating Fan tach channel 15.
> + Atleast one Fan tach input channel is required.
> +
> +Examples:
> +
> +pwm_tacho_fixed_clk: fixedclk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <24000000>;
> +}
> +
> +pwm_tacho: pwmtachocontroller@1e786000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x1E786000 0x1000>;
> + compatible = "aspeed,ast2500-pwm-tacho";
> + clocks = <&pwm_tacho_fixed_clk>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm0_default &pinctrl_pwm1_default>;
> +
> + fan@0 {
> + reg = <0x00>;
> + aspeed-fan-tach-ch = /bits/ 8 <0x00>;
> + };
> +
> + fan@1 {
> + reg = <0x01>;
> + aspeed-fan-tach-ch = /bits/ 8 <0x01 0x02>;
> + };
> +};
> --
> 2.12.1.578.ge9c3154ca4-goog
>
^ permalink raw reply
* Re: [PATCH 1/2] Documentation: dt-bindings: add a Meson8b compatible to the SAR ADC
From: Rob Herring @ 2017-03-30 22:47 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
mark.rutland-5wv7dgnIgG8, linux-iio-u79uwXL29TY76Z2rM5mHXA,
carlo-KA+7E9HrN00dnm+yROfE0A, khilman-rdvid1DuHRBWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170325162938.28659-2-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On Sat, Mar 25, 2017 at 05:29:37PM +0100, Martin Blumenstingl wrote:
> The Amlogic Meson SAR ADC driver can be used on Meson8b as well
> (probably on earlier SoC generations as well, but I don't have any
> hardware available for testing that).
> Add a separate compatible for Meson8b because it does not need any of
> the BL30 magic (unlike the GX SoCs).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> ---
> Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt | 1 +
> 1 file changed, 1 insertion(+)
If you respin, "dt-bindings: iio: adc: ..." for the subject. Otherwise,
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v5 1/9] coresight: bindings for CPU debug module
From: Rob Herring @ 2017-03-30 22:49 UTC (permalink / raw)
To: Leo Yan
Cc: Jonathan Corbet, Mark Rutland, Wei Xu, Catalin Marinas,
Will Deacon, Andy Gross, David Brown, Michael Turquette,
Stephen Boyd, Mathieu Poirier, Guodong Xu, John Stultz, linux-doc,
linux-kernel, devicetree, linux-arm-kernel, linux-arm-msm,
linux-soc, linux-clk, mike.leach, Suzuki.Poulose, sudeep.holla
In-Reply-To: <1490466197-29163-2-git-send-email-leo.yan@linaro.org>
On Sun, Mar 26, 2017 at 02:23:09AM +0800, Leo Yan wrote:
> According to ARMv8 architecture reference manual (ARM DDI 0487A.k)
> Chapter 'Part H: External debug', the CPU can integrate debug module
> and it can support self-hosted debug and external debug. Especially
> for supporting self-hosted debug, this means the program can access
> the debug module from mmio region; and usually the mmio region is
> integrated with coresight.
>
> So add document for binding debug component, includes binding to APB
> clock; and also need specify the CPU node which the debug module is
> dedicated to specific CPU.
>
> Suggested-by: Mike Leach <mike.leach@linaro.org>
> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
> .../bindings/arm/coresight-cpu-debug.txt | 48 ++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master
From: Joel Stanley @ 2017-03-30 22:57 UTC (permalink / raw)
To: Christopher Bostic
Cc: Rob Herring, Mark Rutland, Russell King,
rostedt-nx8X9YLhiw1AfugRpC6u6w, mingo-H+wXaHxf7aLQT0dZR+AlfA,
Greg KH, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Linux Kernel Mailing List, Andrew Jeffery, Alistair Popple,
Benjamin Herrenschmidt, Edward A . James, Jeremy Kerr
In-Reply-To: <0e1bcf3a-e8d7-9f50-bdf7-2a1e7466665b-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Fri, Mar 31, 2017 at 4:45 AM, Christopher Bostic
<cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> wrote:
> Where would you recommend they be placed? I assume we want them somewhere
> in the patch set.
Send them as a separate patch set to the Aspeed maintainer (me) and
the ARM list.
Cheers,
Joel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v5 1/2] Documentation: dtb: lm87: Add hwmon binding documentation
From: Chris Packham @ 2017-03-30 23:00 UTC (permalink / raw)
To: linux-hwmon, linux
Cc: Mahoda Ratnayaka, Chris Packham, Rob Herring, Mark Rutland,
devicetree, linux-kernel
In-Reply-To: <20170330230100.989-1-chris.packham@alliedtelesis.co.nz>
From: Mahoda Ratnayaka <mahoda.ratnayaka@alliedtelesis.co.nz>
This patch adds lm87 hwmon device tree node documentation.
Signed-off-by: Mahoda Ratnayaka <mahoda.ratnayaka@alliedtelesis.co.nz>
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Acked-by: Rob Herring <robh+dt@kernel.org>
---
- Changes since v1:
As suggested include all the changes are moved in
to the same patch and the all the optional properties
are now defined instead of using a single variable to
indicate those properties.
- Changes since v2:
Changed has-vcc-5v to use regulator binding and fixed
a minor copy paste mistake.
- Changes since v3:
Update the vcc-supply description.
- Changes since v4:
Collect Ack from Rob Herring
Documentation/devicetree/bindings/hwmon/lm87.txt | 30 ++++++++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/lm87.txt
diff --git a/Documentation/devicetree/bindings/hwmon/lm87.txt b/Documentation/devicetree/bindings/hwmon/lm87.txt
new file mode 100644
index 000000000000..e1b79903f204
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/lm87.txt
@@ -0,0 +1,30 @@
+*LM87 hwmon sensor.
+
+Required properties:
+- compatible: Should be
+ "ti,lm87"
+
+- reg: I2C address
+
+optional properties:
+- has-temp3: This configures pins 18 and 19 to be used as a second
+ remote temperature sensing channel. By default the pins
+ are configured as voltage input pins in0 and in5.
+
+- has-in6: When set, pin 5 is configured to be used as voltage input
+ in6. Otherwise the pin is set as FAN1 input.
+
+- has-in7: When set, pin 6 is configured to be used as voltage input
+ in7. Otherwise the pin is set as FAN2 input.
+
+- vcc-supply: a Phandle for the regulator supplying power, can be
+ cofigured to measure 5.0V power supply. Default is 3.3V.
+
+Example:
+
+lm87@2e {
+ compatible = "ti,lm87";
+ reg = <0x2e>;
+ has-temp3;
+ vcc-supply = <®_5v0>;
+};
--
2.11.0.24.ge6920cf
^ permalink raw reply related
* Re: [PATCH 1/2] iio:imu:mpu6050 update i2c bindings to reflect i2c-gate and supported parts
From: Rob Herring @ 2017-03-30 23:02 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark.Rutland-5wv7dgnIgG8
In-Reply-To: <20170326111100.2571-2-jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Sun, Mar 26, 2017 at 12:10:59PM +0100, Jonathan Cameron wrote:
> These bindings are somewhat lagging the state of the driver. The i2c-gate
> bindings are documented elsewhere, but it seems sensible to at least have
> an example and cross reference in here. SPI bindings will need to be the
> subject of a future patch.
>
> Signed-off-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> .../devicetree/bindings/iio/imu/inv_mpu6050.txt | 23 ++++++++++++++++++++--
> 1 file changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt b/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt
> index a9fc11e43b45..e18e04f3c6f4 100644
> --- a/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt
> +++ b/Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt
> @@ -3,14 +3,17 @@ InvenSense MPU-6050 Six-Axis (Gyro + Accelerometer) MEMS MotionTracking Device
> http://www.invensense.com/mems/gyro/mpu6050.html
>
> Required properties:
> - - compatible : should be "invensense,mpu6050"
> + - compatible : should be "invensense,mpu6050", "invensense,mpu6500",
> + "invensense,mpu9150" or "invensense,icm20608"
One per line please. With that,
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] iio:imu:mpu6050 add explicit mpu9250 support
From: Rob Herring @ 2017-03-30 23:18 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark.Rutland-5wv7dgnIgG8
In-Reply-To: <20170326111100.2571-3-jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Sun, Mar 26, 2017 at 12:11:00PM +0100, Jonathan Cameron wrote:
> The mpu9250 is a SIP containing an mpu6500 and an ak8975. If this was all
> there was too it there would be no need for explicit handling in the driver.
> Arguably the bindings would also only reflect the presence of an mpu6500 with
> the ak8975 hanging off it, as the kernel doesn't care that they are in one
> package.
>
> However, the WHOAMI value changes as well so best to add explicit support.
>
> Signed-off-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt | 2 +-
> drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 6 ++++++
> drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 5 +++++
> drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 2 ++
> drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c | 1 +
> 5 files changed, 15 insertions(+), 1 deletion(-)
Same one per line comment, but
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ 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