* [PATCH 1/9] ARM: dts: omap2: Add an empty chosen node to top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, Tony Lindgren, Russell King,
Javier Martinez Canillas, Rob Herring, Benoît Cousson,
Pali Rohar, linux-omap, linux-arm-kernel
In-Reply-To: <1482158681-4530-1-git-send-email-javier@osg.samsung.com>
Commit d1f3156fc8c7 ("ARM: dts: omap2: Remove skeleton.dtsi usage")
removed the skeleton.dtsi usage since we want to get rid of it.
But this can cause issues when booting a kernel with a boot-loader
that doesn't create a chosen node if this isn't present in the DTB
since the decompressor relies on a pre-existing chosen node to be
available to insert the command line and merge other ATAGS info.
Fixes: d1f3156fc8c7 ("ARM: dts: omap2: Remove skeleton.dtsi usage")
Reported-by: Pali Rohar <pali.rohar@gmail.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm/boot/dts/omap2.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 4f793a025a72..f1d6de8b3c19 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -17,6 +17,7 @@
interrupt-parent = <&intc>;
#address-cells = <1>;
#size-cells = <1>;
+ chosen { };
aliases {
serial0 = &uart1;
--
2.7.4
^ permalink raw reply related
* [PATCH 0/9] ARM: omap: Add empty chosen node in SoCs top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, Tony Lindgren, Russell King,
Javier Martinez Canillas, Rob Herring, Benoît Cousson,
Pali Rohar, linux-omap, linux-arm-kernel
Hello Tony,
As discussed in [0], there's a regression when booting a kernel with a DTB
that doesn't have a pre-existing chosen node. This is usually not an issue
for most boards since u-boot creates an empty chosen node if isn't present
in the DTB.
But it can be an issue for others bootloaders as Pali pointed out with the
N9/900/950 phones and the Nokia Loader (NoLo).
This patch series add chosen nodes in the top level DTSI for all OMAP SoCs.
[0]: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1294379.html
Best regards,
Javier
Javier Martinez Canillas (9):
ARM: dts: omap2: Add an empty chosen node to top level DTSI
ARM: dts: omap3: Add an empty chosen node to top level DTSI
ARM: dts: omap4: Add an empty chosen node to top level DTSI
ARM: dts: omap5: Add an empty chosen node to top level DTSI
ARM: dts: am33xx: Add an empty chosen node to top level DTSI
ARM: dts: am4372: Add an empty chosen node to top level DTSI
ARM: dts: dm814x: Add an empty chosen node to top level DTSI
ARM: dts: dm816x: Add an empty chosen node to top level DTSI
ARM: dts: dra7: Add an empty chosen node to top level DTSI
arch/arm/boot/dts/am33xx.dtsi | 1 +
arch/arm/boot/dts/am4372.dtsi | 1 +
arch/arm/boot/dts/dm814x.dtsi | 1 +
arch/arm/boot/dts/dm816x.dtsi | 1 +
arch/arm/boot/dts/dra7.dtsi | 1 +
arch/arm/boot/dts/omap2.dtsi | 1 +
arch/arm/boot/dts/omap3.dtsi | 1 +
arch/arm/boot/dts/omap4.dtsi | 1 +
arch/arm/boot/dts/omap5.dtsi | 1 +
9 files changed, 9 insertions(+)
--
2.7.4
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: marvell: Add ethernet switch definition for the EXPRESSObin
From: Andrew Lunn @ 2016-12-19 14:44 UTC (permalink / raw)
To: Romain Perier
Cc: Mark Rutland, devicetree, Florian Fainelli, Jason Cooper,
Pawel Moll, Vivien Didelot, netdev, Ian Campbell, Nadav Haklai,
Rob Herring, Kumar Gala, Gregory Clement, Thomas Petazzoni,
linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20161219141610.30934-5-romain.perier@free-electrons.com>
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + switch0phy0: switch0phy0@0 {
> + reg = <0x11>;
Since the reg is 0x11, this should be called switch0phy0@11. Please
follow the same scheme for the other phys.
Andrew
^ permalink raw reply
* Re: [PATCH 1/4] net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address 0x1
From: Andrew Lunn @ 2016-12-19 14:38 UTC (permalink / raw)
To: Romain Perier, Volodymyr Bendiuga
Cc: Vivien Didelot, Florian Fainelli, Jason Cooper,
Sebastian Hesselbarth, Gregory Clement, netdev, devicetree,
Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel, Thomas Petazzoni, Nadav Haklai
In-Reply-To: <20161219141610.30934-2-romain.perier@free-electrons.com>
On Mon, Dec 19, 2016 at 03:16:06PM +0100, Romain Perier wrote:
> Currently, the function mv88e6xxx_smi_init() returns -EINVAL if the bit
> zero of sw_addr is 0x1. However, on some platforms, ethernet switches
> are configured in Multi chip addressing mode and available at MDIO
> address 0x1.
Hi Romain
What branch is this against? net-next?
Please see:
https://www.spinics.net/lists/netdev/msg409156.html
It would be nicer to use Volodymyr, since it has been reviewed.
Volodymyr, what happened to your version 2? Did David accept it?
Andrew
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: sun8i: add opp-v2 table for A33
From: Quentin Schulz @ 2016-12-19 14:30 UTC (permalink / raw)
To: Icenowy Zheng, Chen-Yu Tsai, Maxime Ripard
Cc: devicetree, linux-kernel, Hans de Goede, linux-sunxi, linux-clk,
linux-arm-kernel
In-Reply-To: <11975791482156406@web2g.yandex.ru>
On 19/12/2016 15:06, Icenowy Zheng wrote:
>
>
> 19.12.2016, 16:54, "Chen-Yu Tsai" <wens@csie.org>:
>> On Mon, Dec 19, 2016 at 4:46 PM, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>>> On Fri, Dec 16, 2016 at 02:27:54AM +0800, Icenowy Zheng wrote:
>>>> An operating point table is needed for the cpu frequency adjusting to
>>>> work.
>>>>
>>>> The operating point table is converted from the common value in
>>>> extracted script.fex from many A33 board/tablets.
>>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>>>> ---
>>>> Changes since v1:
>>>> - Fix format problem (blank lines).
>>>> - Removed the 1.344GHz operating point, as it's overvoltage and overclocked.
>>>>
>>>> This patch depends on the following patchset:
>>>>
>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473962.html
>>>>
>>>> It's the v2 of the [PATCH 4/6] in this patchset.
>>>>
>>>> I think this operating point table may also apply to A23, as there's no
>>>> difference except the points over 1.2GHz between A23 and A33's stock dvfs table.
>>>>
>>>> But as A23 CCU may not have the necessary fixes, I won't add the table to A23
>>>> now.
>>>>
>>>> Chen-Yu, could you test the CCU fixes I described in the patchset above on A23,
>>>> then test this operating points table?
>>>>
>>>> If it's necessary, you can send out the CCU fixes and add one more patch that
>>>> moves this opp-v2 table to sun8i-a23-a33.dtsi .
>>>>
>>>> arch/arm/boot/dts/sun8i-a33.dtsi | 35 +++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 35 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
>>>> index 504996cbee29..0f5b2af72981 100644
>>>> --- a/arch/arm/boot/dts/sun8i-a33.dtsi
>>>> +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
>>>> @@ -46,7 +46,42 @@
>>>> #include <dt-bindings/dma/sun4i-a10.h>
>>>>
>>>> / {
>>>> + cpu0_opp_table: opp_table0 {
>>>> + compatible = "operating-points-v2";
>>>> + opp-shared;
>>>> +
>>>> + opp@648000000 {
>>>> + opp-hz = /bits/ 64 <648000000>;
>>>> + opp-microvolt = <1040000>;
>>>> + clock-latency-ns = <244144>; /* 8 32k periods */
>>>> + };
>>>> +
>>>> + opp@816000000 {
>>>> + opp-hz = /bits/ 64 <816000000>;
>>>> + opp-microvolt = <1100000>;
>>>> + clock-latency-ns = <244144>; /* 8 32k periods */
>>>> + };
>>>> +
>>>> + opp@1008000000 {
>>>> + opp-hz = /bits/ 64 <1008000000>;
>>>> + opp-microvolt = <1200000>;
>>>> + clock-latency-ns = <244144>; /* 8 32k periods */
>>>> + };
>>>> +
>>>> + opp@1200000000 {
>>>> + opp-hz = /bits/ 64 <1200000000>;
>>>> + opp-microvolt = <1320000>;
>>>> + clock-latency-ns = <244144>; /* 8 32k periods */
>>>> + };
>>>> + };
>>>> +
Also, there are a lot more operating points for the A33, see:
https://github.com/QSchulz/linux/blob/v4.9-rc4_adc_a31_v7/cpufreq_a33/arch/arm/boot/dts/sun8i-a33.dtsi#L323-L340
They are present in the Allwinner Linux source code and in the fex of
all A33-based boards.
Is there a reason for not adding all opp?
Quentin
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] ARM: dts: sun8i-q8-common: enable bluetooth on SDIO Wi-Fi
From: Chen-Yu Tsai @ 2016-12-19 14:24 UTC (permalink / raw)
To: Icenowy Zheng
Cc: devicetree@vger.kernel.org, linux-kernel, Hans de Goede,
Chen-Yu Tsai, Maxime Ripard, linux-arm-kernel@lists.infradead.org
In-Reply-To: <11985541482156512@web2g.yandex.ru>
On Mon, Dec 19, 2016 at 10:08 PM, Icenowy Zheng <icenowy@aosc.xyz> wrote:
>
>
> 19.12.2016, 18:09, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>> On Fri, Dec 16, 2016 at 10:40:00PM +0800, Icenowy Zheng wrote:
>>> >> > > &r_pio {
>>> >> > > wifi_pwrseq_pin_q8: wifi_pwrseq_pin@0 {
>>> >> > > - pins = "PL6", "PL7", "PL11";
>>> >> > > + pins = "PL6", "PL7", "PL8", "PL11";
>>> >> > > function = "gpio_in";
>>> >> > > bias-pull-up;
>>> >> > > };
>>> >> >
>>> >> > There's several things wrong here. The first one is that you rely
>>> >> > solely on the pinctrl state to maintain a reset line. This is very
>>> >> > fragile (especially since the GPIO pinctrl state are likely to go away
>>> >> > at some point), but it also means that if your driver wants to recover
>>> >> > from that situation at some point, it won't work.
>>> >> >
>>> >> > The other one is that the bluetooth and wifi chips are two devices in
>>> >> > linux, and you assign that pin to the wrong device (wifi).
>>> >> >
>>> >> > rfkill-gpio is made just for that, so please use it.
>>> >>
>>> >> The GPIO is not for the radio, but for the full Bluetooth part.
>>> >
>>> > I know.
>>> >
>>> >> If it's set to 0, then the bluetooth part will reset, and the
>>> >> hciattach will fail.
>>> >
>>> > Both rfkill-gpio and rfkill-regulator will shutdown when called
>>> > (either by poking the reset pin or shutting down the regulator), so
>>> > that definitely seems like an expected behavior to put the device in
>>> > reset.
>>> >
>>> >> The BSP uses this as a rfkill, and the result is that the bluetooth
>>> >> on/off switch do not work properly.
>>> >
>>> > Then rfkill needs fixing, but working around it by hoping that the
>>> > core will probe an entirely different device, and enforcing a default
>>> > that the rest of the kernel might or might not change is both fragile
>>> > and wrong.
>>>
>>> I think a rfkill-gpio here works just like the BSP rfkill...
>>>
>>> The real problem is that the Realtek UART bluetooth driver is a userspace
>>> program (a modified hciattach), which is not capable of the GPIO reset...
>>
>> Can't you run rfkill before attaching? What is the problem exactly?
>> It's not in reset for long enough?
>>
>> This seems more and more like an issue in the BT stack you're
>> using. We might consider workarounds in the kernel, but they have to
>> be correct.
>
> One more rfkill interface will be generated for hci0 after hciattach, which can
> be safely toggled block and unblock.
>
> However, if the GPIO is toggled down, the hciattach program will die.
>
> The bluetooth stack I used is fd.o's BlueZ.
I think the bigger issue is that the tty/serial subsystem does not have
power sequencing support. Here we're trying to use rfkill to do that,
but that doesn't seem to be what it was intended for. It might work with
standalone USB bluetooth controllers that don't need any special setup,
since the device will just appear and get registered. But it might not
work so well with UART based adapters that need userspace fiddling with
firmware and hciattach.
And like Icenowy mentioned, the bluetooth stack registers another rfkill
control, which presumable just blocks transmissions.
Regards
ChenYu
>
>>
>> Maxime
>>
>> --
>> Maxime Ripard, Free Electrons
>> Embedded Linux and Kernel engineering
>> http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: sun8i: add opp-v2 table for A33
From: Quentin Schulz @ 2016-12-19 14:18 UTC (permalink / raw)
To: Icenowy Zheng, Chen-Yu Tsai, Maxime Ripard
Cc: devicetree, linux-kernel, Hans de Goede, linux-sunxi, linux-clk,
linux-arm-kernel
In-Reply-To: <11975791482156406@web2g.yandex.ru>
Hi,
On 19/12/2016 15:06, Icenowy Zheng wrote:
>
> After proper testing of A23 ccu, the operating points can also apply to A23.
> (According to A23 devices' fex)
>
I disagree. I've looked into using the same operating points for A23 and
A33 for CPUfreq and I came to the conclusion that not all A23-based
boards share the same operating points. You can find the fex files for
the different boards here:
https://github.com/linux-sunxi/sunxi-boards/tree/master/sys_config/a23
After gathering all supported frequencies/voltages for each A23-based
boards, I found that only the following frequencies and voltages are
supported by all A23-based boards:
- 1008 MHz, 1220 mV
- 816 MHz, 1120 mV
- 600 MHz, 1040 mV
Quentin
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 4/4] arm64: dts: marvell: Add ethernet switch definition for the EXPRESSObin
From: Romain Perier @ 2016-12-19 14:16 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Jason Cooper,
Sebastian Hesselbarth, Gregory Clement
Cc: Mark Rutland, devicetree, Romain Perier, Pawel Moll, Ian Campbell,
netdev, Nadav Haklai, Rob Herring, Kumar Gala, Thomas Petazzoni,
linux-arm-kernel
In-Reply-To: <20161219141610.30934-1-romain.perier@free-electrons.com>
This defines and enables the Marvell ethernet switch MVE886341 on the
Marvell EXPRESSObin board.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
.../boot/dts/marvell/armada-3720-espressobin.dts | 67 ++++++++++++++++++++++
1 file changed, 67 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
index 83178d9..8ba6c0b 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
@@ -80,3 +80,70 @@
&usb3 {
status = "okay";
};
+
+&mdio {
+ switch0: switch0@0 {
+ compatible = "marvell,mv88e6085";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ dsa,member = <0 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <ð0>;
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "wan";
+ phy-handle = <&switch0phy0>;
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan0";
+ phy-handle = <&switch0phy1>;
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan1";
+ phy-handle = <&switch0phy2>;
+ };
+
+ };
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ switch0phy0: switch0phy0@0 {
+ reg = <0x11>;
+ };
+ switch0phy1: switch0phy1@1 {
+ reg = <0x12>;
+ };
+ switch0phy2: switch0phy2@2 {
+ reg = <0x13>;
+ };
+ };
+ };
+};
+
+ð0 {
+ phy-mode = "rgmii-id";
+ status = "okay";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH 3/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341/88E6141
From: Romain Perier @ 2016-12-19 14:16 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Jason Cooper,
Sebastian Hesselbarth, Gregory Clement
Cc: Mark Rutland, devicetree, Romain Perier, Pawel Moll, Ian Campbell,
netdev, Nadav Haklai, Rob Herring, Kumar Gala, Thomas Petazzoni,
linux-arm-kernel
In-Reply-To: <20161219141610.30934-1-romain.perier@free-electrons.com>
The Marvell 88E6341 device is single-chip, 6-port ethernet switch with
four integrated 10/100/1000Mbps ethernet transceivers and one high speed
SerDes interfaces. It is compatible with switches of family 88E6352.
This commit adds basic support for this switch by describing its
capabilities to the driver.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 14 ++++++++++++++
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 4 +++-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 76d944e..72ba24b 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4086,6 +4086,20 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.ops = &mv88e6321_ops,
},
+ [MV88E6341] = {
+ .prod_num = PORT_SWITCH_ID_PROD_NUM_6341,
+ .family = MV88E6XXX_FAMILY_6352,
+ .name = "Marvell 88E6341",
+ .num_databases = 4096,
+ .num_ports = 6,
+ .port_base_addr = 0x10,
+ .global1_addr = 0x1b,
+ .age_time_coeff = 15000,
+ .tag_protocol = DSA_TAG_PROTO_EDSA,
+ .flags = MV88E6XXX_FLAGS_FAMILY_6352,
+ .ops = &mv88e6352_ops,
+ },
+
[MV88E6350] = {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6350,
.family = MV88E6XXX_FAMILY_6351,
diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
index af54bae..176d6c4 100644
--- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
@@ -86,6 +86,7 @@
#define PORT_SWITCH_ID_PROD_NUM_6097 0x099
#define PORT_SWITCH_ID_PROD_NUM_6131 0x106
#define PORT_SWITCH_ID_PROD_NUM_6320 0x115
+#define PORT_SWITCH_ID_PROD_NUM_6341 0x340
#define PORT_SWITCH_ID_PROD_NUM_6123 0x121
#define PORT_SWITCH_ID_PROD_NUM_6161 0x161
#define PORT_SWITCH_ID_PROD_NUM_6165 0x165
@@ -432,6 +433,7 @@ enum mv88e6xxx_model {
MV88E6290,
MV88E6320,
MV88E6321,
+ MV88E6341,
MV88E6350,
MV88E6351,
MV88E6352,
@@ -448,7 +450,7 @@ enum mv88e6xxx_family {
MV88E6XXX_FAMILY_6185, /* 6108 6121 6122 6131 6152 6155 6182 6185 */
MV88E6XXX_FAMILY_6320, /* 6320 6321 */
MV88E6XXX_FAMILY_6351, /* 6171 6175 6350 6351 */
- MV88E6XXX_FAMILY_6352, /* 6172 6176 6240 6352 */
+ MV88E6XXX_FAMILY_6352, /* 6172 6176 6240 6341 6352 */
MV88E6XXX_FAMILY_6390, /* 6190 6190X 6191 6290 6390 6390X */
};
--
2.9.3
^ permalink raw reply related
* [PATCH 2/4] net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >= num_of_ports
From: Romain Perier @ 2016-12-19 14:16 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Jason Cooper,
Sebastian Hesselbarth, Gregory Clement
Cc: netdev, devicetree, Rob Herring, Ian Campbell, Pawel Moll,
Mark Rutland, Kumar Gala, linux-arm-kernel, Thomas Petazzoni,
Nadav Haklai, Romain Perier
In-Reply-To: <20161219141610.30934-1-romain.perier@free-electrons.com>
Some Marvell ethernet switches have internal ethernet transceivers with
hardcoded phy addresses. These addresses can be grearer than the number
of ports or its value might be different than the associated port number.
This is for example the case for MV88E6341 that has 6 ports and internal
Port 1 to Port4 PHYs mapped at SMI addresses from 0x11 to 0x14.
This commits fixes the issue by removing the condition in MDIO callbacks.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index b5f0e1e..76d944e 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2881,9 +2881,6 @@ static int mv88e6xxx_mdio_read(struct mii_bus *bus, int phy, int reg)
u16 val;
int err;
- if (phy >= mv88e6xxx_num_ports(chip))
- return 0xffff;
-
mutex_lock(&chip->reg_lock);
err = mv88e6xxx_phy_read(chip, phy, reg, &val);
mutex_unlock(&chip->reg_lock);
@@ -2896,9 +2893,6 @@ static int mv88e6xxx_mdio_write(struct mii_bus *bus, int phy, int reg, u16 val)
struct mv88e6xxx_chip *chip = bus->priv;
int err;
- if (phy >= mv88e6xxx_num_ports(chip))
- return 0xffff;
-
mutex_lock(&chip->reg_lock);
err = mv88e6xxx_phy_write(chip, phy, reg, val);
mutex_unlock(&chip->reg_lock);
--
2.9.3
^ permalink raw reply related
* [PATCH 1/4] net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address 0x1
From: Romain Perier @ 2016-12-19 14:16 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Jason Cooper,
Sebastian Hesselbarth, Gregory Clement
Cc: netdev, devicetree, Rob Herring, Ian Campbell, Pawel Moll,
Mark Rutland, Kumar Gala, linux-arm-kernel, Thomas Petazzoni,
Nadav Haklai, Romain Perier
In-Reply-To: <20161219141610.30934-1-romain.perier@free-electrons.com>
Currently, the function mv88e6xxx_smi_init() returns -EINVAL if the bit
zero of sw_addr is 0x1. However, on some platforms, ethernet switches
are configured in Multi chip addressing mode and available at MDIO
address 0x1.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index f7222dc..b5f0e1e 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4240,10 +4240,6 @@ static void mv88e6xxx_phy_destroy(struct mv88e6xxx_chip *chip)
static int mv88e6xxx_smi_init(struct mv88e6xxx_chip *chip,
struct mii_bus *bus, int sw_addr)
{
- /* ADDR[0] pin is unavailable externally and considered zero */
- if (sw_addr & 0x1)
- return -EINVAL;
-
if (sw_addr == 0)
chip->smi_ops = &mv88e6xxx_smi_single_chip_ops;
else if (mv88e6xxx_has(chip, MV88E6XXX_FLAGS_MULTI_CHIP))
--
2.9.3
^ permalink raw reply related
* [PATCH 0/4] Add support for the ethernet switch on the EXPRESSObin
From: Romain Perier @ 2016-12-19 14:16 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Jason Cooper,
Sebastian Hesselbarth, Gregory Clement
Cc: Mark Rutland, devicetree, Romain Perier, Pawel Moll, Ian Campbell,
netdev, Nadav Haklai, Rob Herring, Kumar Gala, Thomas Petazzoni,
linux-arm-kernel
This set of patches adds support for the Marvell ethernet switch 88E6341.
It also add the devicetree definition of thid switch to the DT board.
Romain Perier (4):
net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address
0x1
net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >=
num_of_ports
net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341/88E6141
arm64: dts: marvell: Add ethernet switch definition for the
EXPRESSObin
.../boot/dts/marvell/armada-3720-espressobin.dts | 67 ++++++++++++++++++++++
drivers/net/dsa/mv88e6xxx/chip.c | 24 ++++----
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 4 +-
3 files changed, 84 insertions(+), 11 deletions(-)
--
2.9.3
^ permalink raw reply
* Re: [PATCH] ARM: dts: sun8i-q8-common: enable bluetooth on SDIO Wi-Fi
From: Icenowy Zheng @ 2016-12-19 14:08 UTC (permalink / raw)
To: Maxime Ripard
Cc: Hans de Goede, Chen-Yu Tsai, linux-kernel,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <20161219100952.bspym36nsehda3za@lukather>
19.12.2016, 18:09, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Fri, Dec 16, 2016 at 10:40:00PM +0800, Icenowy Zheng wrote:
>> >> > > &r_pio {
>> >> > > wifi_pwrseq_pin_q8: wifi_pwrseq_pin@0 {
>> >> > > - pins = "PL6", "PL7", "PL11";
>> >> > > + pins = "PL6", "PL7", "PL8", "PL11";
>> >> > > function = "gpio_in";
>> >> > > bias-pull-up;
>> >> > > };
>> >> >
>> >> > There's several things wrong here. The first one is that you rely
>> >> > solely on the pinctrl state to maintain a reset line. This is very
>> >> > fragile (especially since the GPIO pinctrl state are likely to go away
>> >> > at some point), but it also means that if your driver wants to recover
>> >> > from that situation at some point, it won't work.
>> >> >
>> >> > The other one is that the bluetooth and wifi chips are two devices in
>> >> > linux, and you assign that pin to the wrong device (wifi).
>> >> >
>> >> > rfkill-gpio is made just for that, so please use it.
>> >>
>> >> The GPIO is not for the radio, but for the full Bluetooth part.
>> >
>> > I know.
>> >
>> >> If it's set to 0, then the bluetooth part will reset, and the
>> >> hciattach will fail.
>> >
>> > Both rfkill-gpio and rfkill-regulator will shutdown when called
>> > (either by poking the reset pin or shutting down the regulator), so
>> > that definitely seems like an expected behavior to put the device in
>> > reset.
>> >
>> >> The BSP uses this as a rfkill, and the result is that the bluetooth
>> >> on/off switch do not work properly.
>> >
>> > Then rfkill needs fixing, but working around it by hoping that the
>> > core will probe an entirely different device, and enforcing a default
>> > that the rest of the kernel might or might not change is both fragile
>> > and wrong.
>>
>> I think a rfkill-gpio here works just like the BSP rfkill...
>>
>> The real problem is that the Realtek UART bluetooth driver is a userspace
>> program (a modified hciattach), which is not capable of the GPIO reset...
>
> Can't you run rfkill before attaching? What is the problem exactly?
> It's not in reset for long enough?
>
> This seems more and more like an issue in the BT stack you're
> using. We might consider workarounds in the kernel, but they have to
> be correct.
One more rfkill interface will be generated for hci0 after hciattach, which can
be safely toggled block and unblock.
However, if the GPIO is toggled down, the hciattach program will die.
The bluetooth stack I used is fd.o's BlueZ.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: sun8i: add opp-v2 table for A33
From: Icenowy Zheng @ 2016-12-19 14:06 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard
Cc: Hans de Goede, Quentin Schulz, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-sunxi
In-Reply-To: <CAGb2v65YWntCrFHtSbxhtTWkt+UwkW3xoY-ae26MpH+-ULLXSQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
19.12.2016, 16:54, "Chen-Yu Tsai" <wens-jdAy2FN1RRM@public.gmane.org>:
> On Mon, Dec 19, 2016 at 4:46 PM, Maxime Ripard
> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>> On Fri, Dec 16, 2016 at 02:27:54AM +0800, Icenowy Zheng wrote:
>>> An operating point table is needed for the cpu frequency adjusting to
>>> work.
>>>
>>> The operating point table is converted from the common value in
>>> extracted script.fex from many A33 board/tablets.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>> ---
>>> Changes since v1:
>>> - Fix format problem (blank lines).
>>> - Removed the 1.344GHz operating point, as it's overvoltage and overclocked.
>>>
>>> This patch depends on the following patchset:
>>>
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473962.html
>>>
>>> It's the v2 of the [PATCH 4/6] in this patchset.
>>>
>>> I think this operating point table may also apply to A23, as there's no
>>> difference except the points over 1.2GHz between A23 and A33's stock dvfs table.
>>>
>>> But as A23 CCU may not have the necessary fixes, I won't add the table to A23
>>> now.
>>>
>>> Chen-Yu, could you test the CCU fixes I described in the patchset above on A23,
>>> then test this operating points table?
>>>
>>> If it's necessary, you can send out the CCU fixes and add one more patch that
>>> moves this opp-v2 table to sun8i-a23-a33.dtsi .
>>>
>>> arch/arm/boot/dts/sun8i-a33.dtsi | 35 +++++++++++++++++++++++++++++++++++
>>> 1 file changed, 35 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
>>> index 504996cbee29..0f5b2af72981 100644
>>> --- a/arch/arm/boot/dts/sun8i-a33.dtsi
>>> +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
>>> @@ -46,7 +46,42 @@
>>> #include <dt-bindings/dma/sun4i-a10.h>
>>>
>>> / {
>>> + cpu0_opp_table: opp_table0 {
>>> + compatible = "operating-points-v2";
>>> + opp-shared;
>>> +
>>> + opp@648000000 {
>>> + opp-hz = /bits/ 64 <648000000>;
>>> + opp-microvolt = <1040000>;
>>> + clock-latency-ns = <244144>; /* 8 32k periods */
>>> + };
>>> +
>>> + opp@816000000 {
>>> + opp-hz = /bits/ 64 <816000000>;
>>> + opp-microvolt = <1100000>;
>>> + clock-latency-ns = <244144>; /* 8 32k periods */
>>> + };
>>> +
>>> + opp@1008000000 {
>>> + opp-hz = /bits/ 64 <1008000000>;
>>> + opp-microvolt = <1200000>;
>>> + clock-latency-ns = <244144>; /* 8 32k periods */
>>> + };
>>> +
>>> + opp@1200000000 {
>>> + opp-hz = /bits/ 64 <1200000000>;
>>> + opp-microvolt = <1320000>;
>>> + clock-latency-ns = <244144>; /* 8 32k periods */
>>> + };
>>> + };
>>> +
>>> cpus {
>>> + cpu0: cpu@0 {
>>
>> There's no need to duplicate the label here. I removed it and applied.
>
> I think using the label to directly reference cpu0 would be better,
> instead of duplicating the cpu@0 block.
After proper testing of A23 ccu, the operating points can also apply to A23.
(According to A23 devices' fex)
>
> ChenYu
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Alim Akhtar @ 2016-12-19 13:35 UTC (permalink / raw)
To: Krzysztof Kozlowski, Doug Anderson
Cc: Bartlomiej Zolnierkiewicz, Javier Martinez Canillas, Arjun K V,
Kukjin Kim, Rob Herring, Mark Rutland, Russell King,
Andreas Faerber, Thomas Abraham, Ben Gamari, linux-samsung-soc,
linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20161216073720.GA3489@kozik-lap>
Hi,
On 12/16/2016 01:07 PM, Krzysztof Kozlowski wrote:
> On Thu, Dec 15, 2016 at 04:52:58PM -0800, Doug Anderson wrote:
>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>> (unfortunately Inderpal's email is no longer working). ]
>>>
>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>> IOW if the problem exists it is already present in the mainline
>>> kernel.
>>
>> Interesting. In the ChromeOS tree I see significantly higher voltages
>> needed... Note that one might naively look at
>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#178>.
>>
>> 1362500, /* L0 2100 */
>> 1312500, /* L1 2000 */
>>
>> ..but, amazingly enough those voltages aren't used at all. Surprise!
>>
>> I believe that the above numbers are actually not used and the ASV
>> numbers are used instead. See
>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/include/mach/asv-exynos542x.h#452>
>>
>> { 2100000,
>> 1350000, 1350000, 1350000, 1350000, 1350000,
>> 1337500, 1325000, 1312500, 1300000, 1287500,
>> 1275000, 1262500, 1250000, 1237500 },
>>
>> I believe that interpretation there is: some bins of the CPU can run
>> at 2.1 GHz just fine at 1.25 V but others need up to 1.35V.
>
> That is definitely the case. One could just look at vendors ASV table
> (for 1.9 GHz):
> { 1900000, 1300000, 1287500, 1262500, 1237500, 1225000, 1212500,
> 1200000, 1187500, 1175000, 1162500, 1150000,
> 1137500, 1125000, 1112500, 1112500},
>
> The theoretical difference is up to 1.875V! From my experiments I saw
> BIN1 chips which should be the same... but some working on 1.2V, some on
> 1.225V (@1.9 GHz). I didn't see any requiring higher voltages but that
> does not mean that there aren't such...
>
>> ...so if you're running at 2.1 GHz at 1.25V then perhaps you're just
>> running on a CPU from a nice bin?
>
> Would be nice to see a dump of PKG_ID and AUX_INFO chipid registers
> along with name of tested board. Because the "Tested on XU3" is not
> sufficient.
>
I agree, we should be dumping PKG_ID and other chip info to know on
which BIN sample this patch is tested on...
As far as Peach-{pit/pi} boards are concerns, this is what I can remember:
1> 5420 (PIT) -> max recommended target frequency is 1800 MHz for A15
2> 5800 (PI)-> max recommended target frequency can go upto 2000 MHz,
with INT rail locking.
INT rail locking schemes never made to mainline, so to be safer side
instead of bumping the clock and voltages better to keep it at safer
range for pit and pi, probably thats why it was kept at 1800MHz.
I am not sure if the same limitation applies to Odroid-XU3 samples.
> Best regards,
> Krzysztof
>
>
>
^ permalink raw reply
* Re: [PATCH/RFC v2 3/7] spi: core: Add support for registering SPI slave controllers
From: Mark Brown @ 2016-12-19 13:28 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert Uytterhoeven, Rob Herring, Mark Rutland, Magnus Damm,
Wolfram Sang, Hisashi Nakamura, Hiromitsu Yamasaki, linux-spi,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdXJu0-iTFu3KMWXbbgidB63Mxy0oAWmTKKt0UUKuPbprA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]
On Mon, Dec 19, 2016 at 11:02:07AM +0100, Geert Uytterhoeven wrote:
> On Thu, Dec 15, 2016 at 6:53 PM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > On Mon, Sep 12, 2016 at 10:50:42PM +0200, Geert Uytterhoeven wrote:
> >> TBD:
> >> - s/spi_master/spi_controller/ where appropriate,
> >> - Provide wrappers (e.g. "#define spi_master spi_controller" until all
> >> SPI drivers have been converted),
> >> - Do we want a separate spi_register_slave() instead?
> > This basically looks fine to me - there's these TBDs so I might be
> > missing things and we probably need some GPIO chip select handling but
> Given the hard real-time requirements of SPI slave, supporting GPIO chip
> select may not be feasible.
It's not unknown for SPI devices to have some minimum time requirement
from chip select to first clock so it's workable and probably something
people will want at some point. It can always be done later though.
> As I managed to fix the issue with spi_slave_abort() on MSIOF, I think
> the remaining
> obstacle is the DT binding. Do you have any feedback or other
> suggestions in that area?
> IMHO having the ability to bind to an SPI slave handler either from DT or
> by using the sysfs virtual file is useful to have.
I think it'd be useful to have DT support but really I think the DT
maintainers are going to have more opinions on this than me.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 19/21] MIPS memblock: Add print out method of kernel virtual memory layout
From: Serge Semin @ 2016-12-19 13:15 UTC (permalink / raw)
To: James Hogan
Cc: Matt Redfearn, ralf, paul.burton, rabinv, alexander.sverdlin,
robh+dt, frowand.list, Sergey.Semin, linux-mips, devicetree,
linux-kernel
In-Reply-To: <20161219130236.GJ27950@jhogan-linux.le.imgtec.org>
On Mon, Dec 19, 2016 at 01:02:37PM +0000, James Hogan <james.hogan@imgtec.com> wrote:
> Hi Matt,
>
> On Mon, Dec 19, 2016 at 12:04:54PM +0000, Matt Redfearn wrote:
> > On 19/12/16 02:07, Serge Semin wrote:
> > > It's useful to have some printed map of the kernel virtual memory,
> > > at least for debugging purpose.
> > >
> > > Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> > > ---
>
> > > @@ -106,6 +107,49 @@ static void __init zone_sizes_init(void)
> > > }
> > >
> > > /*
> > > + * Print out kernel memory layout
> > > + */
> > > +#define MLK(b, t) b, t, ((t) - (b)) >> 10
> > > +#define MLM(b, t) b, t, ((t) - (b)) >> 20
> > > +#define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
> > > +static void __init mem_print_kmap_info(void)
> > > +{
> > > + pr_notice("Virtual kernel memory layout:\n"
> > > + " lowmem : 0x%08lx - 0x%08lx (%4ld MB)\n"
> > > + " vmalloc : 0x%08lx - 0x%08lx (%4ld MB)\n"
> > > +#ifdef CONFIG_HIGHMEM
> > > + " pkmap : 0x%08lx - 0x%08lx (%4ld MB)\n"
> > > +#endif
> > > + " fixmap : 0x%08lx - 0x%08lx (%4ld kB)\n"
> > > + " .text : 0x%p" " - 0x%p" " (%4td kB)\n"
> > > + " .data : 0x%p" " - 0x%p" " (%4td kB)\n"
> > > + " .init : 0x%p" " - 0x%p" " (%4td kB)\n",
> > > + MLM(PAGE_OFFSET, (unsigned long)high_memory),
> > > + MLM(VMALLOC_START, VMALLOC_END),
> > > +#ifdef CONFIG_HIGHMEM
> > > + MLM(PKMAP_BASE, (PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE)),
> > > +#endif
> > > + MLK(FIXADDR_START, FIXADDR_TOP),
> > > + MLK_ROUNDUP(_text, _etext),
> > > + MLK_ROUNDUP(_sdata, _edata),
> > > + MLK_ROUNDUP(__init_begin, __init_end));
> >
> > Please drop printing the kernel addresses, or at least only do it if
> > KASLR is not turned on, otherwise you're removing the advantage of
> > KASLR, that critical kernel addresses cannot be determined easily from
> > userspace.
>
> According to Documentation/printk-formats.txt, this is what %pK is for.
> Better to use that instead?
>
> Cheers
> James
>
The function is called from the kernel directly, which is privileged
enough to do the printing. So I suppose Matt is right, to hide this
prints out unless debug is enabled.
Thanks,
-Sergey
> >
> > It may be better to merge the functionality of show_kernel_relocation
> > http://lxr.free-electrons.com/source/arch/mips/kernel/relocate.c#L354
> > into this function, but only print it under the same conditions as
> > currently, i.e.
> > #if defined(CONFIG_DEBUG_KERNEL) && defined(CONFIG_DEBUG_INFO)
> > http://lxr.free-electrons.com/source/arch/mips/kernel/setup.c#L530
> >
> > Thanks,
> > Matt
^ permalink raw reply
* Re: [PATCH 19/21] MIPS memblock: Add print out method of kernel virtual memory layout
From: James Hogan @ 2016-12-19 13:02 UTC (permalink / raw)
To: Matt Redfearn
Cc: Serge Semin, ralf, paul.burton, rabinv, alexander.sverdlin,
robh+dt, frowand.list, Sergey.Semin, linux-mips, devicetree,
linux-kernel
In-Reply-To: <db27f41e-4121-bb83-6533-6727c26b9c5b@imgtec.com>
[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]
Hi Matt,
On Mon, Dec 19, 2016 at 12:04:54PM +0000, Matt Redfearn wrote:
> On 19/12/16 02:07, Serge Semin wrote:
> > It's useful to have some printed map of the kernel virtual memory,
> > at least for debugging purpose.
> >
> > Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> > ---
> > @@ -106,6 +107,49 @@ static void __init zone_sizes_init(void)
> > }
> >
> > /*
> > + * Print out kernel memory layout
> > + */
> > +#define MLK(b, t) b, t, ((t) - (b)) >> 10
> > +#define MLM(b, t) b, t, ((t) - (b)) >> 20
> > +#define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
> > +static void __init mem_print_kmap_info(void)
> > +{
> > + pr_notice("Virtual kernel memory layout:\n"
> > + " lowmem : 0x%08lx - 0x%08lx (%4ld MB)\n"
> > + " vmalloc : 0x%08lx - 0x%08lx (%4ld MB)\n"
> > +#ifdef CONFIG_HIGHMEM
> > + " pkmap : 0x%08lx - 0x%08lx (%4ld MB)\n"
> > +#endif
> > + " fixmap : 0x%08lx - 0x%08lx (%4ld kB)\n"
> > + " .text : 0x%p" " - 0x%p" " (%4td kB)\n"
> > + " .data : 0x%p" " - 0x%p" " (%4td kB)\n"
> > + " .init : 0x%p" " - 0x%p" " (%4td kB)\n",
> > + MLM(PAGE_OFFSET, (unsigned long)high_memory),
> > + MLM(VMALLOC_START, VMALLOC_END),
> > +#ifdef CONFIG_HIGHMEM
> > + MLM(PKMAP_BASE, (PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE)),
> > +#endif
> > + MLK(FIXADDR_START, FIXADDR_TOP),
> > + MLK_ROUNDUP(_text, _etext),
> > + MLK_ROUNDUP(_sdata, _edata),
> > + MLK_ROUNDUP(__init_begin, __init_end));
>
> Please drop printing the kernel addresses, or at least only do it if
> KASLR is not turned on, otherwise you're removing the advantage of
> KASLR, that critical kernel addresses cannot be determined easily from
> userspace.
According to Documentation/printk-formats.txt, this is what %pK is for.
Better to use that instead?
Cheers
James
>
> It may be better to merge the functionality of show_kernel_relocation
> http://lxr.free-electrons.com/source/arch/mips/kernel/relocate.c#L354
> into this function, but only print it under the same conditions as
> currently, i.e.
> #if defined(CONFIG_DEBUG_KERNEL) && defined(CONFIG_DEBUG_INFO)
> http://lxr.free-electrons.com/source/arch/mips/kernel/setup.c#L530
>
> Thanks,
> Matt
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v7 1/2] mtd: nand: add tango NFC dt bindings doc
From: Boris Brezillon @ 2016-12-19 12:59 UTC (permalink / raw)
To: Marc Gonzalez
Cc: Arnd Bergmann, linux-mtd, Richard Weinberger, DT, Rob Herring,
Mark Rutland, Mason, Sebastian Frias
In-Reply-To: <d3cbfda6-23bf-4ad1-b1ce-c179b765272f-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org>
On Fri, 16 Dec 2016 11:56:38 +0100
Marc Gonzalez <marc_gonzalez-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org> wrote:
> On 07/11/2016 10:18, Arnd Bergmann wrote:
> > On Tuesday, October 25, 2016 3:15:50 PM CET Marc Gonzalez wrote:
> >> Add the tango NAND Flash Controller dt bindings documentation.
> >>
> >> Signed-off-by: Marc Gonzalez <marc_gonzalez-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org>
> >> ---
> >> Documentation/devicetree/bindings/mtd/tango-nand.txt | 38 ++++++++++++++++++++++++++++++
> >> 1 file changed, 38 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mtd/tango-nand.txt b/Documentation/devicetree/bindings/mtd/tango-nand.txt
> >> new file mode 100644
> >> index 000000000000..3cbf95d6595a
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mtd/tango-nand.txt
> >> @@ -0,0 +1,38 @@
> >> +Sigma Designs Tango4 NAND Flash Controller (NFC)
> >> +
> >> +Required properties:
> >> +
> >> +- compatible: "sigma,smp8758-nand"
> >> +- reg: address/size of nfc_reg, nfc_mem, and pbus_reg
> >> +- dmas: reference to the DMA channel used by the controller
> >> +- dma-names: "nfc_sbox"
> >
> > Drop the "nfc_" prefix here, it seems redundant.
>
> I took a closer look at Documentation/devicetree/bindings and
> arch/arm/boot/dts and it seems the overwhelming nomenclature
> is "rx", "tx" (with variants around these two).
>
> Should I just use "rxtx" for my driver?
>
> >> +- clocks: reference to the system clock
> >> +- #address-cells: <1>
> >> +- #size-cells: <0>
> >> +
> >> +Children nodes represent the available NAND chips.
> >> +See Documentation/devicetree/bindings/mtd/nand.txt for generic bindings.
> >> +
> >> +Example:
> >> +
> >> + nand: nand@2c000 {
> >> + compatible = "sigma,smp8758-nand";
> >> + reg = <0x2c000 0x30 0x2d000 0x800 0x20000 0x1000>;
> >
> > It would be nicer to write this as
> >
> > reg = <0x2c000 0x30>, <0x2d000 0x800>, <0x20000 0x1000>;
> >
> > which is identical in binary format.
>
> This is indeed a marked improvement. Boris, if I fix these two nits,
> can I submit a single patch, or do you want them split?
Sure, just describe the different binding changes in your commit
message.
--
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 v6 3/8] PWM: add pwm-stm32 DT bindings
From: Lee Jones @ 2016-12-19 12:55 UTC (permalink / raw)
To: Rob Herring
Cc: Benjamin Gaignard, Mark Rutland, Alexandre Torgue,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Thierry Reding, Linux PWM List, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Fabrice Gasnier, Gerald Baeza, Arnaud POULIQUEN
In-Reply-To: <CAL_JsqL8pJSFb8LbABAYJOQ0URaMpyupbFryk_mS2ToN1kStdA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 13 Dec 2016, Rob Herring wrote:
> On Tue, Dec 13, 2016 at 5:11 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > On Mon, 12 Dec 2016, Rob Herring wrote:
> >
> >> On Fri, Dec 09, 2016 at 03:15:14PM +0100, Benjamin Gaignard wrote:
> >> > Define bindings for pwm-stm32
> >> >
> >> > version 6:
> >> > - change st,breakinput parameter format to make it usuable on stm32f7 too.
> >> >
> >> > version 2:
> >> > - use parameters instead of compatible of handle the hardware configuration
> >> >
> >> > Signed-off-by: Benjamin Gaignard <benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
> >> > ---
> >> > .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++++++++++++++++++++++
> >> > 1 file changed, 33 insertions(+)
> >> > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> >> > new file mode 100644
> >> > index 0000000..866f222
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> >> > @@ -0,0 +1,33 @@
> >> > +STMicroelectronics STM32 Timers PWM bindings
> >> > +
> >> > +Must be a sub-node of an STM32 Timers device tree node.
> >> > +See ../mfd/stm32-timers.txt for details about the parent node.
> >> > +
> >> > +Required parameters:
> >> > +- compatible: Must be "st,stm32-pwm".
> >> > +- pinctrl-names: Set to "default".
> >> > +- pinctrl-0: List of phandles pointing to pin configuration nodes for PWM module.
> >> > + For Pinctrl properties see ../pinctrl/pinctrl-bindings.txt
> >> > +
> >> > +Optional parameters:
> >> > +- st,breakinput: Arrays of three u32 <index level filter> to describe break input configurations.
> >> > + "index" indicates on which break input the configuration should be applied.
> >> > + "level" gives the active level (0=low or 1=high) for this configuration.
> >> > + "filter" gives the filtering value to be applied.
> >> > +
> >> > +Example:
> >> > + timers@40010000 {
> >>
> >> timer@...
> >
> > No, it should be timers.
>
> Read the spec. "timer" is a generic node name. "timers" is not. How
> many is not relevant.
It's not the amount of timers that there are, it's the different types
of timers which this one IP contains.
In MFD we usually list the part number or IP name, however in this
case its difficult because the same IP doesn't have a specific name
listed, and provides; advanced, general purpose and basic timers, as
well as PWM functionality.
This IP is not a timer (although one of its children is one). It's
the parent device of many different types of timer.
timer {
timer {
};
pwm {
};
};
... looks weird.
"timer" is not right for the parent IP. Happy for you to provide an
alternative to "timers" though?
> > The 's' is intentional, since this parent (MFD) device houses 3
> > different types of timers. The "timer" node is a child of this one.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v2 02/11] mfd: axp20x: add volatile and writeable reg ranges for VBUS power supply driver
From: Quentin Schulz @ 2016-12-19 12:28 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Sebastian Reichel, Rob Herring, Mark Rutland, Russell King,
Maxime Ripard, Lee Jones, open list:THERMAL, devicetree,
linux-kernel, linux-arm-kernel, Thomas Petazzoni
In-Reply-To: <CAGb2v66jDsU2rt4d-0ydWR926y-hHTfOBJQmyYVdKd7rcm1WWQ@mail.gmail.com>
Hi Chen-Yu,
On 14/12/2016 16:43, Chen-Yu Tsai wrote:
> On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
> <quentin.schulz@free-electrons.com> wrote:
>> The X-Powers AXP20X and AXP22X PMICs allow to choose the maximum voltage
>> and minimum current delivered by the VBUS power supply.
>>
>> This adds the register used by the VBUS power supply driver to the range
>> of volatile and writeable regs ranges.
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>> ---
>>
>> added in v2
>>
>> drivers/mfd/axp20x.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
>> index ba130be..6ee2cc6 100644
>> --- a/drivers/mfd/axp20x.c
>> +++ b/drivers/mfd/axp20x.c
>> @@ -65,12 +65,14 @@ static const struct regmap_access_table axp152_volatile_table = {
>>
>> static const struct regmap_range axp20x_writeable_ranges[] = {
>> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
>> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
>
> This is already covered by the previous entry.
>
>> regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
>> regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),
>> };
>>
>> static const struct regmap_range axp20x_volatile_ranges[] = {
>> regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_USB_OTG_STATUS),
>> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
>
> And I'm not sure why you specify it as volatile? The PMIC doesn't change any
> of the bits in this register on its own.
>
I got things mixed up between the work on the battery driver I'll soon
send (which actually needs updated reg ranges) and this VBUS driver.
Sorry for that.
> Same for the AXP22x bits. So basically I think you don't need this patch.
>
Indeed. Should I send a v3 to remove this patch or is it fine for you to
ignore this one?
Thanks!
Quentin
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v10 8/8] dt-bindings: mmc: Add Cavium SOCs MMC bindings
From: Jan Glauber @ 2016-12-19 12:15 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, linux-kernel, David Daney, Steven J . Hill,
Jan Glauber, Rob Herring, Mark Rutland, devicetree
In-Reply-To: <20161219121552.18316-1-jglauber@cavium.com>
Add description of Cavium Octeon and ThunderX SOC device tree bindings.
CC: Ulf Hansson <ulf.hansson@linaro.org>
CC: Rob Herring <robh+dt@kernel.org>
CC: Mark Rutland <mark.rutland@arm.com>
CC: devicetree@vger.kernel.org
Signed-off-by: Jan Glauber <jglauber@cavium.com>
---
.../devicetree/bindings/mmc/octeon-mmc.txt | 59 ++++++++++++++++++++++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/octeon-mmc.txt
diff --git a/Documentation/devicetree/bindings/mmc/octeon-mmc.txt b/Documentation/devicetree/bindings/mmc/octeon-mmc.txt
new file mode 100644
index 0000000..aad02eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/octeon-mmc.txt
@@ -0,0 +1,59 @@
+* Cavium Octeon & ThunderX MMC controller
+
+The highspeed MMC host controller on Caviums SoCs provides an interface
+for MMC and SD types of memory cards.
+
+Supported maximum speeds are the ones of the eMMC standard 4.41 as well
+as the speed of SD standard 4.0. Only 3.3 Volt is supported.
+
+Required properties:
+ - compatible : should be one of:
+ * "cavium,octeon-6130-mmc"
+ * "cavium,octeon-6130-mmc-slot"
+ * "cavium,octeon-7890-mmc"
+ * "cavium,octeon-7890-mmc-slot"
+ * "cavium,thunder-8190-mmc"
+ * "cavium,thunder-8190-mmc-slot"
+ * "cavium,thunder-8390-mmc"
+ * "cavium,thunder-8390-mmc-slot"
+ - reg : mmc controller base registers
+ - clocks : phandle
+
+Optional properties:
+ - for cd, bus-width and additional generic mmc parameters
+ please refer to mmc.txt within this directory
+ - "cavium,cmd-clk-skew" : number of coprocessor clocks before sampling command
+ - "cavium,dat-clk-skew" : number of coprocessor clocks before sampling data
+
+Deprecated properties:
+- spi-max-frequency : use max-frequency instead
+- "cavium,bus-max-width" : use bus-width instead
+
+Examples:
+ - Within .dtsi:
+ mmc_1_4: mmc@1,4 {
+ compatible = "cavium,thunder-8390-mmc";
+ reg = <0x0c00 0 0 0 0>; /* DEVFN = 0x0c (1:4) */
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&sclk>;
+ };
+
+ - Within dts:
+ mmc-slot@0 {
+ compatible = "cavium,thunder-8390-mmc-slot";
+ reg = <0>;
+ voltage-ranges = <3300 3300>;
+ max-frequency = <42000000>;
+ bus-width = <4>;
+ cap-sd-highspeed;
+ };
+ mmc-slot@1 {
+ compatible = "cavium,thunder-8390-mmc-slot";
+ reg = <1>;
+ voltage-ranges = <3300 3300>;
+ max-frequency = <42000000>;
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ non-removable;
+ };
--
2.9.0.rc0.21.g7777322
^ permalink raw reply related
* Re: [PATCH 19/21] MIPS memblock: Add print out method of kernel virtual memory layout
From: Serge Semin @ 2016-12-19 12:09 UTC (permalink / raw)
To: Matt Redfearn
Cc: ralf, paul.burton, rabinv, james.hogan, alexander.sverdlin,
robh+dt, frowand.list, Sergey.Semin, linux-mips, devicetree,
linux-kernel
In-Reply-To: <db27f41e-4121-bb83-6533-6727c26b9c5b@imgtec.com>
On Mon, Dec 19, 2016 at 12:04:54PM +0000, Matt Redfearn <matt.redfearn@imgtec.com> wrote:
Hello Matt.
> Hi Serge,
>
>
> On 19/12/16 02:07, Serge Semin wrote:
> >It's useful to have some printed map of the kernel virtual memory,
> >at least for debugging purpose.
> >
> >Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> >---
> > arch/mips/mm/init.c | 47 +++++++++++++++++++++++++++++++++++
> > 1 file changed, 47 insertions(+)
> >
> >diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c
> >index 13a032f..35e7ba8 100644
> >--- a/arch/mips/mm/init.c
> >+++ b/arch/mips/mm/init.c
> >@@ -32,6 +32,7 @@
> > #include <linux/hardirq.h>
> > #include <linux/gfp.h>
> > #include <linux/kcore.h>
> >+#include <linux/sizes.h>
> > #include <asm/asm-offsets.h>
> > #include <asm/bootinfo.h>
> >@@ -106,6 +107,49 @@ static void __init zone_sizes_init(void)
> > }
> > /*
> >+ * Print out kernel memory layout
> >+ */
> >+#define MLK(b, t) b, t, ((t) - (b)) >> 10
> >+#define MLM(b, t) b, t, ((t) - (b)) >> 20
> >+#define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
> >+static void __init mem_print_kmap_info(void)
> >+{
> >+ pr_notice("Virtual kernel memory layout:\n"
> >+ " lowmem : 0x%08lx - 0x%08lx (%4ld MB)\n"
> >+ " vmalloc : 0x%08lx - 0x%08lx (%4ld MB)\n"
> >+#ifdef CONFIG_HIGHMEM
> >+ " pkmap : 0x%08lx - 0x%08lx (%4ld MB)\n"
> >+#endif
> >+ " fixmap : 0x%08lx - 0x%08lx (%4ld kB)\n"
> >+ " .text : 0x%p" " - 0x%p" " (%4td kB)\n"
> >+ " .data : 0x%p" " - 0x%p" " (%4td kB)\n"
> >+ " .init : 0x%p" " - 0x%p" " (%4td kB)\n",
> >+ MLM(PAGE_OFFSET, (unsigned long)high_memory),
> >+ MLM(VMALLOC_START, VMALLOC_END),
> >+#ifdef CONFIG_HIGHMEM
> >+ MLM(PKMAP_BASE, (PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE)),
> >+#endif
> >+ MLK(FIXADDR_START, FIXADDR_TOP),
> >+ MLK_ROUNDUP(_text, _etext),
> >+ MLK_ROUNDUP(_sdata, _edata),
> >+ MLK_ROUNDUP(__init_begin, __init_end));
>
> Please drop printing the kernel addresses, or at least only do it if KASLR
> is not turned on, otherwise you're removing the advantage of KASLR, that
> critical kernel addresses cannot be determined easily from userspace.
>
> It may be better to merge the functionality of show_kernel_relocation
> http://lxr.free-electrons.com/source/arch/mips/kernel/relocate.c#L354
> into this function, but only print it under the same conditions as
> currently, i.e.
> #if defined(CONFIG_DEBUG_KERNEL) && defined(CONFIG_DEBUG_INFO)
> http://lxr.free-electrons.com/source/arch/mips/kernel/setup.c#L530
>
> Thanks,
> Matt
>
Understood. Will be fixed within the next patchset.
> >+
> >+ /* Check some fundamental inconsistencies. May add something else? */
> >+#ifdef CONFIG_HIGHMEM
> >+ BUILD_BUG_ON(VMALLOC_END < PAGE_OFFSET);
> >+ BUG_ON(VMALLOC_END < (unsigned long)high_memory);
> >+#endif
> >+ BUILD_BUG_ON((PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE) < PAGE_OFFSET);
> >+ BUG_ON((PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE) <
> >+ (unsigned long)high_memory);
> >+ BUILD_BUG_ON(FIXADDR_TOP < PAGE_OFFSET);
> >+ BUG_ON(FIXADDR_TOP < (unsigned long)high_memory);
> >+}
> >+#undef MLK
> >+#undef MLM
> >+#undef MLK_ROUNDUP
> >+
> >+/*
> > * Not static inline because used by IP27 special magic initialization code
> > */
> > void setup_zero_pages(void)
> >@@ -492,6 +536,9 @@ void __init mem_init(void)
> > /* Free highmemory registered in memblocks */
> > mem_init_free_highmem();
> >+ /* Print out kernel memory layout */
> >+ mem_print_kmap_info();
> >+
> > /* Print out memory areas statistics */
> > mem_init_print_info(NULL);
>
^ permalink raw reply
* Re: [PATCH 19/21] MIPS memblock: Add print out method of kernel virtual memory layout
From: Matt Redfearn @ 2016-12-19 12:04 UTC (permalink / raw)
To: Serge Semin, ralf, paul.burton, rabinv, james.hogan,
alexander.sverdlin, robh+dt, frowand.list
Cc: Sergey.Semin, linux-mips, devicetree, linux-kernel
In-Reply-To: <1482113266-13207-20-git-send-email-fancer.lancer@gmail.com>
Hi Serge,
On 19/12/16 02:07, Serge Semin wrote:
> It's useful to have some printed map of the kernel virtual memory,
> at least for debugging purpose.
>
> Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> ---
> arch/mips/mm/init.c | 47 +++++++++++++++++++++++++++++++++++
> 1 file changed, 47 insertions(+)
>
> diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c
> index 13a032f..35e7ba8 100644
> --- a/arch/mips/mm/init.c
> +++ b/arch/mips/mm/init.c
> @@ -32,6 +32,7 @@
> #include <linux/hardirq.h>
> #include <linux/gfp.h>
> #include <linux/kcore.h>
> +#include <linux/sizes.h>
>
> #include <asm/asm-offsets.h>
> #include <asm/bootinfo.h>
> @@ -106,6 +107,49 @@ static void __init zone_sizes_init(void)
> }
>
> /*
> + * Print out kernel memory layout
> + */
> +#define MLK(b, t) b, t, ((t) - (b)) >> 10
> +#define MLM(b, t) b, t, ((t) - (b)) >> 20
> +#define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
> +static void __init mem_print_kmap_info(void)
> +{
> + pr_notice("Virtual kernel memory layout:\n"
> + " lowmem : 0x%08lx - 0x%08lx (%4ld MB)\n"
> + " vmalloc : 0x%08lx - 0x%08lx (%4ld MB)\n"
> +#ifdef CONFIG_HIGHMEM
> + " pkmap : 0x%08lx - 0x%08lx (%4ld MB)\n"
> +#endif
> + " fixmap : 0x%08lx - 0x%08lx (%4ld kB)\n"
> + " .text : 0x%p" " - 0x%p" " (%4td kB)\n"
> + " .data : 0x%p" " - 0x%p" " (%4td kB)\n"
> + " .init : 0x%p" " - 0x%p" " (%4td kB)\n",
> + MLM(PAGE_OFFSET, (unsigned long)high_memory),
> + MLM(VMALLOC_START, VMALLOC_END),
> +#ifdef CONFIG_HIGHMEM
> + MLM(PKMAP_BASE, (PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE)),
> +#endif
> + MLK(FIXADDR_START, FIXADDR_TOP),
> + MLK_ROUNDUP(_text, _etext),
> + MLK_ROUNDUP(_sdata, _edata),
> + MLK_ROUNDUP(__init_begin, __init_end));
Please drop printing the kernel addresses, or at least only do it if
KASLR is not turned on, otherwise you're removing the advantage of
KASLR, that critical kernel addresses cannot be determined easily from
userspace.
It may be better to merge the functionality of show_kernel_relocation
http://lxr.free-electrons.com/source/arch/mips/kernel/relocate.c#L354
into this function, but only print it under the same conditions as
currently, i.e.
#if defined(CONFIG_DEBUG_KERNEL) && defined(CONFIG_DEBUG_INFO)
http://lxr.free-electrons.com/source/arch/mips/kernel/setup.c#L530
Thanks,
Matt
> +
> + /* Check some fundamental inconsistencies. May add something else? */
> +#ifdef CONFIG_HIGHMEM
> + BUILD_BUG_ON(VMALLOC_END < PAGE_OFFSET);
> + BUG_ON(VMALLOC_END < (unsigned long)high_memory);
> +#endif
> + BUILD_BUG_ON((PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE) < PAGE_OFFSET);
> + BUG_ON((PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE) <
> + (unsigned long)high_memory);
> + BUILD_BUG_ON(FIXADDR_TOP < PAGE_OFFSET);
> + BUG_ON(FIXADDR_TOP < (unsigned long)high_memory);
> +}
> +#undef MLK
> +#undef MLM
> +#undef MLK_ROUNDUP
> +
> +/*
> * Not static inline because used by IP27 special magic initialization code
> */
> void setup_zero_pages(void)
> @@ -492,6 +536,9 @@ void __init mem_init(void)
> /* Free highmemory registered in memblocks */
> mem_init_free_highmem();
>
> + /* Print out kernel memory layout */
> + mem_print_kmap_info();
> +
> /* Print out memory areas statistics */
> mem_init_print_info(NULL);
>
^ permalink raw reply
* Re: [PATCH v10 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager
From: Geert Uytterhoeven @ 2016-12-19 11:16 UTC (permalink / raw)
To: Joel Holdsworth
Cc: atull, Moritz Fischer, Rob Herring, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-spi, Marek Vasut, linux-fpga
In-Reply-To: <1482039234-21335-2-git-send-email-joel@airwebreathe.org.uk>
Hi Joel,
On Sun, Dec 18, 2016 at 6:33 AM, Joel Holdsworth
<joel@airwebreathe.org.uk> wrote:
> This adds documentation of the device tree bindings of the Lattice iCE40
> FPGA driver for the FPGA manager framework.
>
> Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Alan Tull <atull@opensource.altera.com>
> Acked-by: Moritz Fischer <moritz.fischer@ettus.com>
> Acked-by: Marek Vasut <marex@denx.de>
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
> @@ -0,0 +1,21 @@
> +Lattice iCE40 FPGA Manager
> +
> +Required properties:
> +- compatible: Should contain "lattice,ice40-fpga-mgr"
> +- reg: SPI chip select
> +- spi-max-frequency: Maximum SPI frequency (>=1000000, <=25000000)
> +- cdone-gpios: GPIO input connected to CDONE pin
> +- reset-gpios: Active-low GPIO output connected to CRESET_B pin. Note
> + that unless the GPIO is held low during startup, the
> + FPGA will enter Master SPI mode and drive SCK with a
> + clock signal potentially jamming other devices on the
> + bus until the firmware is loaded.
> +
> +Example:
> + ice40: ice40@0 {
As per ePAPR, node names should be generic names, e.g. "fpga@0".
Sorry for not noticing before.
> + compatible = "lattice,ice40-fpga-mgr";
> + reg = <0>;
> + spi-max-frequency = <1000000>;
> + cdone-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&gpio 22 GPIO_ACTIVE_LOW>;
> + };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ 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