* [PATCH v2] efi/libstub: arm*: Pass latest memory map to the kernel
From: James Morse @ 2016-12-19 14:24 UTC (permalink / raw)
To: linux-arm-kernel
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
As reported by James, the current libstub code involving the annotated
memory map only works somewhat correctly by accident, due to the fact
that a pool allocation happens to be reused immediately, retaining its
former contents.
Instead of juggling memory maps, which makes the code more complex than
it needs to be, simply put a placholder value into the FDT, and only
write the actual value after ExitBootServices() has been called.
Reported-by: James Morse <james.morse@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
[Update mmap-size too, remove updated_fdt()s unused params and header entry]
Signed-off-by: James Morse <james.morse@arm.com>
---
Hi Ard,
This is a v2 of your patch that updates the mmap-size too. This solves the
truncated memmap problem I saw with v1 on Seattle.
The original patch was CC-stable, so I think this should also have:
Cc: <stable@vger.kernel.org>
Fixes: ed9cc156c42f ("efi/libstub: Use efi_exit_boot_services() in FDT")
Thanks,
James
drivers/firmware/efi/libstub/efistub.h | 8 ----
drivers/firmware/efi/libstub/fdt.c | 75 +++++++++++++++++++++-------------
2 files changed, 47 insertions(+), 36 deletions(-)
diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index ee49cd23ee63..fac67992bede 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -30,14 +30,6 @@ efi_status_t efi_file_close(void *handle);
unsigned long get_dram_base(efi_system_table_t *sys_table_arg);
-efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
- unsigned long orig_fdt_size,
- void *fdt, int new_fdt_size, char *cmdline_ptr,
- u64 initrd_addr, u64 initrd_size,
- efi_memory_desc_t *memory_map,
- unsigned long map_size, unsigned long desc_size,
- u32 desc_ver);
-
efi_status_t allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
void *handle,
unsigned long *new_fdt_addr,
diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
index a6a93116a8f0..6d33d709f6b3 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -16,13 +16,11 @@
#include "efistub.h"
-efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
- unsigned long orig_fdt_size,
- void *fdt, int new_fdt_size, char *cmdline_ptr,
- u64 initrd_addr, u64 initrd_size,
- efi_memory_desc_t *memory_map,
- unsigned long map_size, unsigned long desc_size,
- u32 desc_ver)
+static efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
+ unsigned long orig_fdt_size,
+ void *fdt, int new_fdt_size, char *cmdline_ptr,
+ u64 initrd_addr, u64 initrd_size,
+ unsigned long desc_size, u32 desc_ver)
{
int node, num_rsv;
int status;
@@ -101,13 +99,13 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
if (status)
goto fdt_set_fail;
- fdt_val64 = cpu_to_fdt64((u64)(unsigned long)memory_map);
+ fdt_val64 = U64_MAX; /* placeholder */
status = fdt_setprop(fdt, node, "linux,uefi-mmap-start",
&fdt_val64, sizeof(fdt_val64));
if (status)
goto fdt_set_fail;
- fdt_val32 = cpu_to_fdt32(map_size);
+ fdt_val32 = U32_MAX; /* placeholder */
status = fdt_setprop(fdt, node, "linux,uefi-mmap-size",
&fdt_val32, sizeof(fdt_val32));
if (status)
@@ -148,6 +146,32 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
return EFI_LOAD_ERROR;
}
+static efi_status_t update_fdt_memmap(void *fdt, u64 memmap, u32 map_size)
+{
+ int node = fdt_path_offset(fdt, "/chosen");
+ efi_status_t status;
+
+ if (node < 0)
+ return EFI_LOAD_ERROR;
+
+ memmap = cpu_to_fdt64(memmap);
+ status = fdt_setprop_inplace(fdt, node, "linux,uefi-mmap-start",
+ &memmap, sizeof(memmap));
+
+ if (status)
+ return EFI_LOAD_ERROR;
+
+ map_size = cpu_to_fdt32(map_size);
+ status = fdt_setprop_inplace(fdt, node, "linux,uefi-mmap-size",
+ &map_size, sizeof(map_size));
+
+ if (status)
+ return EFI_LOAD_ERROR;
+
+
+ return EFI_SUCCESS;
+}
+
#ifndef EFI_FDT_ALIGN
#define EFI_FDT_ALIGN EFI_PAGE_SIZE
#endif
@@ -243,20 +267,11 @@ efi_status_t allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
goto fail;
}
- /*
- * Now that we have done our final memory allocation (and free)
- * we can get the memory map key needed for
- * exit_boot_services().
- */
- status = efi_get_memory_map(sys_table, &map);
- if (status != EFI_SUCCESS)
- goto fail_free_new_fdt;
-
status = update_fdt(sys_table,
(void *)fdt_addr, fdt_size,
(void *)*new_fdt_addr, new_fdt_size,
cmdline_ptr, initrd_addr, initrd_size,
- memory_map, map_size, desc_size, desc_ver);
+ desc_size, desc_ver);
/* Succeeding the first time is the expected case. */
if (status == EFI_SUCCESS)
@@ -266,20 +281,16 @@ efi_status_t allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
/*
* We need to allocate more space for the new
* device tree, so free existing buffer that is
- * too small. Also free memory map, as we will need
- * to get new one that reflects the free/alloc we do
- * on the device tree buffer.
+ * too small.
*/
efi_free(sys_table, new_fdt_size, *new_fdt_addr);
- sys_table->boottime->free_pool(memory_map);
new_fdt_size += EFI_PAGE_SIZE;
} else {
pr_efi_err(sys_table, "Unable to construct new device tree.\n");
- goto fail_free_mmap;
+ goto fail_free_new_fdt;
}
}
- sys_table->boottime->free_pool(memory_map);
priv.runtime_map = runtime_map;
priv.runtime_entry_count = &runtime_entry_count;
status = efi_exit_boot_services(sys_table, handle, &map, &priv,
@@ -288,6 +299,17 @@ efi_status_t allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
if (status == EFI_SUCCESS) {
efi_set_virtual_address_map_t *svam;
+ status = update_fdt_memmap((void *)*new_fdt_addr,
+ (u64)memory_map, (u32)map_size);
+ if (status != EFI_SUCCESS) {
+ /*
+ * The kernel won't get far without the memory map, but
+ * may still be able to print something meaningful so
+ * return success here.
+ */
+ return EFI_SUCCESS;
+ }
+
/* Install the new virtual address map */
svam = sys_table->runtime->set_virtual_address_map;
status = svam(runtime_entry_count * desc_size, desc_size,
@@ -319,9 +341,6 @@ efi_status_t allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
pr_efi_err(sys_table, "Exit boot services failed.\n");
-fail_free_mmap:
- sys_table->boottime->free_pool(memory_map);
-
fail_free_new_fdt:
efi_free(sys_table, new_fdt_size, *new_fdt_addr);
--
2.10.1
^ permalink raw reply related
* [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: linux-arm-kernel
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 at 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
* [PATCH v2] ARM: dts: sun8i: add opp-v2 table for A33
From: Quentin Schulz @ 2016-12-19 14:30 UTC (permalink / raw)
To: 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 at 648000000 {
>>>> + opp-hz = /bits/ 64 <648000000>;
>>>> + opp-microvolt = <1040000>;
>>>> + clock-latency-ns = <244144>; /* 8 32k periods */
>>>> + };
>>>> +
>>>> + opp at 816000000 {
>>>> + opp-hz = /bits/ 64 <816000000>;
>>>> + opp-microvolt = <1100000>;
>>>> + clock-latency-ns = <244144>; /* 8 32k periods */
>>>> + };
>>>> +
>>>> + opp at 1008000000 {
>>>> + opp-hz = /bits/ 64 <1008000000>;
>>>> + opp-microvolt = <1200000>;
>>>> + clock-latency-ns = <244144>; /* 8 32k periods */
>>>> + };
>>>> +
>>>> + opp at 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
* [PATCH v1] mtd: nand: tango: Update DT binding description
From: Marc Gonzalez @ 2016-12-19 14:30 UTC (permalink / raw)
To: linux-arm-kernel
Visually separate register ranges (address/size pairs) in reg prop.
Change DMA channel name, for consistency with other drivers.
Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
---
Documentation/devicetree/bindings/mtd/tango-nand.txt | 6 +++---
drivers/mtd/nand/tango_nand.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/tango-nand.txt b/Documentation/devicetree/bindings/mtd/tango-nand.txt
index ad5a02f2ac8c..cd1bf2ac9055 100644
--- a/Documentation/devicetree/bindings/mtd/tango-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/tango-nand.txt
@@ -5,7 +5,7 @@ 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"
+- dma-names: "rxtx"
- clocks: reference to the system clock
- #address-cells: <1>
- #size-cells: <0>
@@ -17,9 +17,9 @@ Example:
nandc: nand-controller at 2c000 {
compatible = "sigma,smp8758-nand";
- reg = <0x2c000 0x30 0x2d000 0x800 0x20000 0x1000>;
+ reg = <0x2c000 0x30>, <0x2d000 0x800>, <0x20000 0x1000>;
dmas = <&dma0 3>;
- dma-names = "nfc_sbox";
+ dma-names = "rxtx";
clocks = <&clkgen SYS_CLK>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/drivers/mtd/nand/tango_nand.c b/drivers/mtd/nand/tango_nand.c
index cc23db64f0ca..51dc88d6b8da 100644
--- a/drivers/mtd/nand/tango_nand.c
+++ b/drivers/mtd/nand/tango_nand.c
@@ -629,7 +629,7 @@ static int tango_nand_probe(struct platform_device *pdev)
if (IS_ERR(clk))
return PTR_ERR(clk);
- nfc->chan = dma_request_chan(&pdev->dev, "nfc_sbox");
+ nfc->chan = dma_request_chan(&pdev->dev, "rxtx");
if (IS_ERR(nfc->chan))
return PTR_ERR(nfc->chan);
--
2.10.0
^ permalink raw reply related
* [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: linux-arm-kernel
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
* [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: linux-arm-kernel
In-Reply-To: <20161219141610.30934-5-romain.perier@free-electrons.com>
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + switch0phy0: switch0phy0 at 0 {
> + reg = <0x11>;
Since the reg is 0x11, this should be called switch0phy0 at 11. Please
follow the same scheme for the other phys.
Andrew
^ permalink raw reply
* [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-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 at 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
* [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-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 2/9] ARM: dts: omap3: Add an empty chosen node to top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482158681-4530-1-git-send-email-javier@osg.samsung.com>
Commit 008a2ebcd677 ("ARM: dts: omap3: 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: 008a2ebcd677 ("ARM: dts: omap3: 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/omap3.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index ecf5eb584c75..a3ff4933dbc1 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -17,6 +17,7 @@
interrupt-parent = <&intc>;
#address-cells = <1>;
#size-cells = <1>;
+ chosen { };
aliases {
i2c0 = &i2c1;
--
2.7.4
^ permalink raw reply related
* [PATCH 3/9] ARM: dts: omap4: Add an empty chosen node to top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482158681-4530-1-git-send-email-javier@osg.samsung.com>
Commit da6269e7e3dd ("ARM: dts: omap4: 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: da6269e7e3dd ("ARM: dts: omap4: 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/omap4.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 8087456b5fbe..578c53f08309 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -15,6 +15,7 @@
interrupt-parent = <&wakeupgen>;
#address-cells = <1>;
#size-cells = <1>;
+ chosen { };
aliases {
i2c0 = &i2c1;
--
2.7.4
^ permalink raw reply related
* [PATCH 4/9] ARM: dts: omap5: Add an empty chosen node to top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482158681-4530-1-git-send-email-javier@osg.samsung.com>
Commit 76a8548ea987 ("ARM: dts: omap5: 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: 76a8548ea987 ("ARM: dts: omap5: 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/omap5.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 968c67a49dbd..7cd92babc41a 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -17,6 +17,7 @@
compatible = "ti,omap5";
interrupt-parent = <&wakeupgen>;
+ chosen { };
aliases {
i2c0 = &i2c1;
--
2.7.4
^ permalink raw reply related
* [PATCH 5/9] ARM: dts: am33xx: Add an empty chosen node to top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482158681-4530-1-git-send-email-javier@osg.samsung.com>
Commit f8bf01611c99 ("ARM: dts: am33xx: 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: f8bf01611c99 ("ARM: dts: am33xx: 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/am33xx.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 64c8aa9057a3..18d72a245e88 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -16,6 +16,7 @@
interrupt-parent = <&intc>;
#address-cells = <1>;
#size-cells = <1>;
+ chosen { };
aliases {
i2c0 = &i2c0;
--
2.7.4
^ permalink raw reply related
* [PATCH 6/9] ARM: dts: am4372: Add an empty chosen node to top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482158681-4530-1-git-send-email-javier@osg.samsung.com>
Commit 75813028bbd7 ("ARM: dts: am4372: 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: 75813028bbd7 ("ARM: dts: am4372: 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/am4372.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ac55f93fc91e..2df9e6050c2f 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -16,6 +16,7 @@
interrupt-parent = <&wakeupgen>;
#address-cells = <1>;
#size-cells = <1>;
+ chosen { };
memory at 0 {
device_type = "memory";
--
2.7.4
^ permalink raw reply related
* [PATCH 7/9] ARM: dts: dm814x: Add an empty chosen node to top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482158681-4530-1-git-send-email-javier@osg.samsung.com>
Commit 76155b378c59 ("ARM: dts: dm814x: 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: 76155b378c59 ("ARM: dts: dm814x: 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/dm814x.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
index 1facc5f12cef..81b8cecb5820 100644
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -12,6 +12,7 @@
interrupt-parent = <&intc>;
#address-cells = <1>;
#size-cells = <1>;
+ chosen { };
aliases {
i2c0 = &i2c1;
--
2.7.4
^ permalink raw reply related
* [PATCH 8/9] ARM: dts: dm816x: Add an empty chosen node to top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482158681-4530-1-git-send-email-javier@osg.samsung.com>
Commit 06bfb9c19957 ("ARM: dts: dm816x: 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: 06bfb9c19957 ("ARM: dts: dm816x: 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/dm816x.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index 61dd2f6b02bc..6db652ae9bd5 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -12,6 +12,7 @@
interrupt-parent = <&intc>;
#address-cells = <1>;
#size-cells = <1>;
+ chosen { };
aliases {
i2c0 = &i2c1;
--
2.7.4
^ permalink raw reply related
* [PATCH 9/9] ARM: dts: dra7: Add an empty chosen node to top level DTSI
From: Javier Martinez Canillas @ 2016-12-19 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482158681-4530-1-git-send-email-javier@osg.samsung.com>
Commit 55871eb6e2cc ("ARM: dts: dra7: 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: 55871eb6e2cc ("ARM: dts: dra7: 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/dra7.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index addb7530cfbe..1faf24acd521 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -18,6 +18,7 @@
compatible = "ti,dra7xx";
interrupt-parent = <&crossbar_mpu>;
+ chosen { };
aliases {
i2c0 = &i2c1;
--
2.7.4
^ permalink raw reply related
* [PATCH v2] drm: tilcdc: simplify the recovery from sync lost error on rev1
From: Bartosz Golaszewski @ 2016-12-19 14:47 UTC (permalink / raw)
To: linux-arm-kernel
Revision 2 of LCDC suffers from an issue where a SYNC_LOST error
caused by limited memory bandwidth may leave the picture shifted a
couple pixels to the right.
This issue has not been observed on revision 1, while the recovery
mechanism introduces a different issue, where the END_OF_FRAME
interrupt doesn't fire while drm is waiting for vblanks.
On rev1: recover from sync lost errors by simply clearing the
RASTER_ENABLE bit in the RASTER_CTRL register and re-enabling it
again as is suggested by the datasheet.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
v1 -> v2:
- add a check to see if the RASTER_ENABLE bit is set before clearing it
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 9942b05..2004107 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -856,7 +856,7 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct tilcdc_drm_private *priv = dev->dev_private;
- uint32_t stat;
+ uint32_t stat, reg;
stat = tilcdc_read_irqstatus(dev);
tilcdc_clear_irqstatus(dev, stat);
@@ -921,17 +921,26 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
dev_err_ratelimited(dev->dev, "%s(0x%08x): Sync lost",
__func__, stat);
tilcdc_crtc->frame_intact = false;
- if (tilcdc_crtc->sync_lost_count++ >
- SYNC_LOST_COUNT_LIMIT) {
- dev_err(dev->dev, "%s(0x%08x): Sync lost flood detected, recovering", __func__, stat);
- queue_work(system_wq, &tilcdc_crtc->recover_work);
- if (priv->rev == 1)
+ if (priv->rev == 1) {
+ reg = tilcdc_read(dev, LCDC_RASTER_CTRL_REG);
+ if (reg & LCDC_RASTER_ENABLE) {
tilcdc_clear(dev, LCDC_RASTER_CTRL_REG,
- LCDC_V1_SYNC_LOST_INT_ENA);
- else
+ LCDC_RASTER_ENABLE);
+ tilcdc_set(dev, LCDC_RASTER_CTRL_REG,
+ LCDC_RASTER_ENABLE);
+ }
+ } else {
+ if (tilcdc_crtc->sync_lost_count++ >
+ SYNC_LOST_COUNT_LIMIT) {
+ dev_err(dev->dev,
+ "%s(0x%08x): Sync lost flood detected, recovering",
+ __func__, stat);
+ queue_work(system_wq,
+ &tilcdc_crtc->recover_work);
tilcdc_write(dev, LCDC_INT_ENABLE_CLR_REG,
LCDC_SYNC_LOST);
- tilcdc_crtc->sync_lost_count = 0;
+ tilcdc_crtc->sync_lost_count = 0;
+ }
}
}
--
2.9.3
^ permalink raw reply related
* [PATCH 3/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341/88E6141
From: Andrew Lunn @ 2016-12-19 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161219141610.30934-4-romain.perier@free-electrons.com>
Hi Romain
> 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,
Even if it i 100% compatible with the 6532, you should still add an
ops structure for it. All chips have their own, even when the are
exactly the same as other in the family.
> --- 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
Ah, err..
These should be in numerical order of the macro.
PORT_SWITCH_ID_PROD_NUM_6320 is however in the wrong place. Please
put the 6341 after the 6321.
Thanks
Andrew
^ permalink raw reply
* [PATCH 2/4] net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >= num_of_ports
From: Andrew Lunn @ 2016-12-19 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161219141610.30934-3-romain.perier@free-electrons.com>
On Mon, Dec 19, 2016 at 03:16:07PM +0100, Romain Perier wrote:
> 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>
So it is not quite compatible with the 6352. Thanks Marvell :-(
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH 1/4] net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address 0x1
From: Romain Perier @ 2016-12-19 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161219143848.GA10048@lunn.ch>
Hi Andrew,
Le 19/12/2016 ? 15:38, Andrew Lunn a ?crit :
> 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?
Until last friday it was based onto next-20161216, I rebased onto the
torvalds's tree this morning (so ~4.10-pre-rc1).
>
> Please see:
>
> https://www.spinics.net/lists/netdev/msg409156.html
Oh, it's already fixed, good. I did not see this patch :)
>
> It would be nicer to use Volodymyr, since it has been reviewed.
As the fix is already there, I will use it, sure.
Thanks,
Romain
^ permalink raw reply
* [PATCH 3/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341/88E6141
From: Romain Perier @ 2016-12-19 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161219145227.GC10048@lunn.ch>
Hi Andrew,
Le 19/12/2016 ? 15:52, Andrew Lunn a ?crit :
> Hi Romain
>
>> 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,
>
> Even if it i 100% compatible with the 6532, you should still add an
> ops structure for it. All chips have their own, even when the are
> exactly the same as other in the family.
Ack, I will fix this.
>
>> --- 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
>
> Ah, err..
>
> These should be in numerical order of the macro.
> PORT_SWITCH_ID_PROD_NUM_6320 is however in the wrong place. Please
> put the 6341 after the 6321.
good catch, ok.
Thanks,
Romain
^ permalink raw reply
* [PATCH 4/4] arm64: dts: marvell: Add ethernet switch definition for the EXPRESSObin
From: Thomas Petazzoni @ 2016-12-19 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161219141610.30934-5-romain.perier@free-electrons.com>
Hello,
On Mon, 19 Dec 2016 15:16:09 +0100, Romain Perier wrote:
> This defines and enables the Marvell ethernet switch MVE886341 on the
> Marvell EXPRESSObin board.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
I didn't want to make this (silly) comment but since you got another
comment that will let you send a new iteration, here is my silly
comment: the name of the board is EspressoBin, not ExpressoBin.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/4] net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address 0x1
From: Andrew Lunn @ 2016-12-19 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <292d4f15-c58b-3565-26ec-98a025b6adb3@free-electrons.com>
On Mon, Dec 19, 2016 at 03:56:34PM +0100, Romain Perier wrote:
> Hi Andrew,
>
> Le 19/12/2016 ? 15:38, Andrew Lunn a ?crit :
> >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?
>
> Until last friday it was based onto next-20161216, I rebased onto
> the torvalds's tree this morning (so ~4.10-pre-rc1).
This patchset is 80% networking. So please see:
Documentation/networking/netdev-FAQ.txt
> Oh, it's already fixed, good. I did not see this patch :)
>
> >
> >It would be nicer to use Volodymyr, since it has been reviewed.
>
>
> As the fix is already there, I will use it, sure.
Im not sure what happened to it. It might of fallen through the
cracks. Lets see what Volodymyr says. It might need resubmitting once
netdev reopens.
Andrew
^ permalink raw reply
* [PATCH 4/4] arm64: dts: marvell: Add ethernet switch definition for the EXPRESSObin
From: Romain Perier @ 2016-12-19 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161219155819.4cdf0f40@free-electrons.com>
Hi,
Le 19/12/2016 ? 15:58, Thomas Petazzoni a ?crit :
> Hello,
>
> On Mon, 19 Dec 2016 15:16:09 +0100, Romain Perier wrote:
>> This defines and enables the Marvell ethernet switch MVE886341 on the
>> Marvell EXPRESSObin board.
>>
>> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
>
> I didn't want to make this (silly) comment but since you got another
> comment that will let you send a new iteration, here is my silly
> comment: the name of the board is EspressoBin, not ExpressoBin.
>
> Thanks!
>
> Thomas
>
Ack for the two feedback (I don't know why I have replaced "es" by "ex"
:/, anyway...)
Thanks,
Romain
^ permalink raw reply
* [PATCH net 0/3] Fix integration of eee-broken-modes
From: Jerome Brunet @ 2016-12-19 15:05 UTC (permalink / raw)
To: linux-arm-kernel
The purpose of this series is to fix the integration of the ethernet phy
property "eee-broken-modes" [0]
The v3 of this series has been merged, missing a fix (error reported by
kbuild robot) available in the v4 [1]
More importantly, Florian opposed adding a DT property mapping a device
register this directly [2]. The concern was that the property could be
abused to implement platform configuration policy. After discussing it,
I think we agreed that such information about the HW (defect) should appear
in the platform DT. However, the preferred way is to add a boolean property
for each EEE broken mode.
[0]: http://lkml.kernel.org/r/1480326409-25419-1-git-send-email-jbrunet at baylibre.com
[1]: http://lkml.kernel.org/r/1480348229-25672-1-git-send-email-jbrunet at baylibre.com
[2]: http://lkml.kernel.org/r/e14a3b0c-dc34-be14-48b3-518a0ad0c080 at gmail.com
Jerome Brunet (3):
net: phy: fix sign type error in genphy_config_eee_advert
net: phy: use boolean dt properties for eee broken modes
dt: bindings: net: use boolean dt properties for eee broken modes
Documentation/devicetree/bindings/net/phy.txt | 10 ++++++++--
drivers/net/phy/phy_device.c | 22 +++++++++++++++++-----
include/dt-bindings/net/mdio.h | 19 -------------------
3 files changed, 25 insertions(+), 26 deletions(-)
delete mode 100644 include/dt-bindings/net/mdio.h
--
2.7.4
^ 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