* [PATCH v3 0/7] Marvell NAND controller rework with ->exec_op()
From: Miquel RAYNAL @ 2018-01-11 22:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87efmwb8bj.fsf@belgarion.home>
Hi Robert,
On Thu, 11 Jan 2018 18:42:56 +0100
Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Boris Brezillon <boris.brezillon@free-electrons.com> writes:
>
> Hi Boris and Miquel,
>
> > So, here is the plan: since the driver has been tested on various
> > mvebu platforms and is known to work fine on these platforms, I'd
> > like to queue the driver and the patch modifying mvebu defconfigs
> > (patches 1 to 4) for 4.16.
> That's all right.
>
> > I'll leave other patches for 4.17, which means I'd like remaining
> > bugs to be fixed during the 4.16 release cycle so that we can
> > eventually get rid of the old driver. That's really important to me
> > that we don't keep both drivers around for too long, because my
> > previous experience showed that, when you have 2 drivers for the
> > same HW, people don't switch to the new one until they're forced to
> > do it.
> >
> > Robert, are you fine with this approach? What about the tests you
> > were doing? Did you make any progress? Did you find other issues?
> So far, with the latest branch from Miquel of tip commit 12b9e62c851c
> ("ARM64: dts: marvell: use reworked NAND controller driver on Armada
> 8K"), the bad blocks issue is still there, ie :
> - the old pxa3xx driver doesn't see any bad block and mounts the
> ext2/ubifs correctly
> - barebox doesn't see any bad block
> - marvell_nand sees all (or most all) blocks as bad with
> "flash_bbt=0" in platform data, which is very surprising
>
> I'm really surprised that in your tests on the cm_x300, in a
> platform_data setup (ie. not device-tree setup), you're not seeing
> these errors ...
I have no problems with the cm_x300 board (using platform data) but
there is one big difference: the bootloader. You are using Barebox
while I am using U-Boot.
Please pull this branch which is for testing purpose [1].
There are two "HACK"s:
1/ Dump the timing registers: this is to see how Barebox does
initialize these registers. I will put these values back into my setup
and see how the board reacts.
2/ Dump the OOB area while reading. This is to see why the driver
declares all blocks as bad.
Can you please run this branch first?
Then, can you please:
- boot the old driver
- dump both NDTR[0|1] registers that should be well initialized
- boot the new driver with the values previously retrieved (you can
assign these values where exactly HACK 1/ adds the printk's).
Thank you,
Miqu?l
[1]
https://github.com/miquelraynal/linux/commits/marvell/nand-next/nfc-pxa-bug
^ permalink raw reply
* [PATCH v3 2/7] dt-bindings: mtd: add Marvell NAND controller documentation
From: Rob Herring @ 2018-01-11 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109103637.23798-3-miquel.raynal@free-electrons.com>
On Tue, Jan 09, 2018 at 11:36:32AM +0100, Miquel Raynal wrote:
> Document the legacy and the new bindings for Marvell NAND controller.
>
> The pxa3xx_nand.c driver does only support legacy bindings, which are
> incomplete and inaccurate. A rework of this controller (called
> marvell_nand.c) does support both.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
> .../devicetree/bindings/mtd/marvell-nand.txt | 123 +++++++++++++++++++++
> 1 file changed, 123 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/marvell-nand.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 0/7] Marvell NAND controller rework with ->exec_op()
From: Willy Tarreau @ 2018-01-11 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109103637.23798-1-miquel.raynal@free-electrons.com>
Hi Miquel,
On Tue, Jan 09, 2018 at 11:36:30AM +0100, Miquel Raynal wrote:
> These changes have been tested on:
> - PXA3xx platform with a CM-X300 board (2kiB page NAND, 1b/512B
> strength, Hamming ECC engine) [32 bits]
> - Armada 385 DB AP (4kiB page NAND, 4b/512B, BCH ECC engine) [32 bits]
> - Armada 398 DB (4kiB page NAND, 8b/512B, BCH ECC engine using a layout
> with a last chunk different than the others) [32 bits]
> - Armada 7040 DB and Armada 8040 DB (4kiB page NAND, 4b/512B, BCH ECC
> engine) [64 bits]
> - Triax dvb-tc board (2kiB page NAND, 4b/512B, BCH ECC engine) [32 bits]
If you're interested, I have a mirabox with an armada 370 which uses the
same driver. I've not powered it up for a while but if that can be useful
I can try to find some time for this.
Just let me know
Willy
^ permalink raw reply
* [1/5] clk: divider: read-only divider can propagate rate change
From: David Lechner @ 2018-01-11 22:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105170959.17266-2-jbrunet@baylibre.com>
On 01/05/2018 11:09 AM, Jerome Brunet wrote:
> When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the
> register shall be left un-touched, but it does not mean the clock
> should stop rate propagation if CLK_SET_RATE_PARENT is set
>
> This is properly handled in qcom clk-regmap-divider but it was not in
> the generic divider
>
> Fixes: e6d5e7d90be9 ("clk-divider: Fix READ_ONLY when divider > 1")
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> drivers/clk/clk-divider.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index b49942b9fe50..a851d3e04c7f 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -348,6 +348,7 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
> unsigned long *prate)
> {
> struct clk_divider *divider = to_clk_divider(hw);
> + struct clk_hw *hw_parent = clk_hw_get_parent(hw);
Very minor suggestion: This could be moved inside the if block since it is only used there.
> int bestdiv;
>
> /* if read only, just return current value */
> @@ -356,6 +357,15 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
> bestdiv &= div_mask(divider->width);
> bestdiv = _get_div(divider->table, bestdiv, divider->flags,
> divider->width);
> +
> + /* Even a read-only clock can propagate a rate change */
> + if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
> + if (!hw_parent)
> + return -EINVAL;
> +
> + *prate = clk_hw_round_rate(hw_parent, rate * bestdiv);
> + }
> +
> return DIV_ROUND_UP_ULL((u64)*prate, bestdiv);
> }
>
>
Tested-by: David Lechner <david@lechnology.com>
^ permalink raw reply
* [linux, dev-4.10, 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon
From: Jae Hyun Yoo @ 2018-01-11 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111214035.GA14748@roeck-us.net>
On 1/11/2018 1:40 PM, Guenter Roeck wrote:
> On Thu, Jan 11, 2018 at 11:47:01AM -0800, Jae Hyun Yoo wrote:
>> On 1/10/2018 1:47 PM, Guenter Roeck wrote:
>>> On Tue, Jan 09, 2018 at 02:31:26PM -0800, Jae Hyun Yoo wrote:
>>>> This commit adds driver implementation for a generic PECI hwmon.
>>>>
>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>
> [ ... ]
>
>>>> +
>>>> + if (priv->temp.tcontrol.valid &&
>>>> + time_before(jiffies, priv->temp.tcontrol.last_updated +
>>>> + UPDATE_INTERVAL_MIN))
>>>> + return 0;
>>>> +
>>>
>>> Is the delay necessary ? Otherwise I would suggest to drop it.
>>> It adds a lot of complexity to the driver. Also, if the user polls
>>> values more often, that is presumably on purpose.
>>>
>>
>> I was intended to reduce traffic on PECI bus because it's low speed single
>> wired bus, and temperature values don't change frequently because the value
>> is sampled and averaged in CPU itself. I'll keep this.
>>
> Then please try to move the common code into a single function.
>
That makes sense. I'll move the common code into a single function.
> [ ... ]
>
>>>> +
>>>> + rc = of_property_read_u32(np, "cpu-id", &priv->cpu_id);
>>>
>>> What entity determines cpu-id ?
>>>
>>
>> CPU ID numbering is determined by hardware SOCKET_ID strap pins. In this
>> driver implementation, cpu-id is being used as CPU client indexing.
>>
> Seems to me the necessary information to identify a given CPU should
> be provided by the PECI core. Also, there are already "cpu" nodes
> in devicetree which, if I recall correctly, may include information
> such as CPU Ids.
>
This driver is implemented to support only BMC (Baseboard Management
Controllers) chipset which is running on a separated linux kernel from a
host server system. Through a PECI connection between them, this driver
collects the host server system's CPU and DIMM temperature information
which is running on a separated OS. That could be a linux, a Windows OS
or any other OSes. I mean, there is no shared devicetree data between
them so it is why the 'cpu_id' was added into dt configuration of this
driver.
Using quite limited hardware connections such as PECI, KSC, eSPI and
SMBus, the BMC manages the host server and this hwmon is one of features
of BMC.
>>>> + if (rc || priv->cpu_id >= CPU_ID_MAX) {
>>>> + dev_err(dev, "Invalid cpu-id configuration\n");
>>>> + return rc;
>>>> + }
>>>> +
>>>> + rc = of_property_read_u32(np, "dimm-nums", &priv->dimm_nums);
>>>
>>> This is an odd devicetree attribute. Normally the number of DIMMs
>>> is dynamic. Isn't there a means to get all that information dynamically
>>> instead of having to set it through devicetree ? What if someone adds
>>> or removes a DIMM ? Who updates the devicetree ?
>>>
>>
>> It means the number of DIMM slots each CPU has, doesn't mean the number of
>> currently installed DIMM components. If a DIMM is inserted a slot, CPU
>> reports its actual temperature but on empty slot, CPU reports 0 instead of
>> reporting an error so it is the reason why this driver enumerates all DIMM
>> slots' attribute.
>>
> And there is no other means to get the number of DIMM slots per CPU ?
> It just seems to be that this is the wrong location to provide such
> information.
>
This devicetree attribute will be configured at runtime using dt overlay
based on the host server's hardware configuration which will be parsed
and managed by a userspace BMC service.
> [ ... ]
>
>>>> +
>>>> +static const struct of_device_id peci_of_table[] = {
>>>> + { .compatible = "peci-hwmon", },
>>>
>>> This does not look like a reference to some piece of hardware.
>>>
>>
>> This driver provides generic PECI hwmon function to which controller has
>> PECI HW such as Aspeed or Nuvoton BMC chip so it's not dependant on a
>> specific hardware. Should I remove this or any suggestion?
>>
>
> I don't really know enough about the system to make a recommendation.
> It seems to me that the PECI core should identify which functionality
> it supports and instantiate the necessary driver(s). Maybe there should
> be sub-nodes to the peci node with relevant information. Those sub-nodes
> should specify the supported functionality in more detail, though -
> such as indicating the supported CPU and/or DIMM sensors.
>
> Guenter
>
As I explained above, BMC and host server are running on separated OSes
so this driver cannot be (actually, doesn't need to be) directly
associated with other kernel modules in the BMC side OS for identifying
the host server system's functionality. My thought is, this driver will
use PECI only for identifying the host server's CPU and DIMM information
and the userspace BMC service could deliver any additional host server
information thru dt overlay if needed before the BMC service initiates
this driver at runtime.
Thanks a lot,
Jae
^ permalink raw reply
* [3/5] clk: divider: add divider_ro_round_rate helper
From: David Lechner @ 2018-01-11 23:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105170959.17266-4-jbrunet@baylibre.com>
On 01/05/2018 11:09 AM, Jerome Brunet wrote:
> Like divider_round_rate, a couple a of driver are doing more or less
> the same operation to round the rate of the divider when it is read-only.
>
> We can factor this code so let's provide an helper function for this
Perhaps you could also make use of this new helper here (clk-divider.c):
const struct clk_ops clk_divider_ro_ops = {
.recalc_rate = clk_divider_recalc_rate,
.round_rate = clk_divider_round_rate,
};
EXPORT_SYMBOL_GPL(clk_divider_ro_ops);
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> drivers/clk/clk-divider.c | 43 ++++++++++++++++++++++++++++---------------
> include/linux/clk-provider.h | 15 +++++++++++++++
> 2 files changed, 43 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index a851d3e04c7f..3eb2b27f3513 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -344,29 +344,42 @@ long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
> }
> EXPORT_SYMBOL_GPL(divider_round_rate_parent);
>
It is nice to have documentation comments on public functions. Especially
in this case where @prate is an in/out parameter and @table is optional.
> +long divider_ro_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
> + unsigned long rate, unsigned long *prate,
> + const struct clk_div_table *table, u8 width,
> + unsigned long flags, unsigned int val)
> +{
> + int div;
> +
> + div = _get_div(table, val, flags, width);
> +
> + /* Even a read-only clock can propagate a rate change */
> + if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
> + if (!parent)
> + return -EINVAL;
> +
> + *prate = clk_hw_round_rate(parent, rate * div);
> + }
> +
> + return DIV_ROUND_UP_ULL((u64)*prate, div);
> +}
> +EXPORT_SYMBOL_GPL(divider_ro_round_rate_parent);
> +
> +
> static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
> unsigned long *prate)
> {
> struct clk_divider *divider = to_clk_divider(hw);
> - struct clk_hw *hw_parent = clk_hw_get_parent(hw);
> - int bestdiv;
> + u32 val;
>
> /* if read only, just return current value */
> if (divider->flags & CLK_DIVIDER_READ_ONLY) {
> - bestdiv = clk_readl(divider->reg) >> divider->shift;
> - bestdiv &= div_mask(divider->width);
> - bestdiv = _get_div(divider->table, bestdiv, divider->flags,
> - divider->width);
> -
> - /* Even a read-only clock can propagate a rate change */
> - if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
> - if (!hw_parent)
> - return -EINVAL;
> -
> - *prate = clk_hw_round_rate(hw_parent, rate * bestdiv);
> - }
> + val = clk_readl(divider->reg) >> divider->shift;
> + val &= div_mask(divider->width);
>
> - return DIV_ROUND_UP_ULL((u64)*prate, bestdiv);
> + return divider_ro_round_rate(hw, rate, prate, divider->table,
> + divider->width, divider->flags,
> + val);
> }
>
> return divider_round_rate(hw, rate, prate, divider->table,
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 175a62a15619..eb2c3a035e98 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -417,6 +417,10 @@ long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
> unsigned long rate, unsigned long *prate,
> const struct clk_div_table *table,
> u8 width, unsigned long flags);
> +long divider_ro_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
> + unsigned long rate, unsigned long *prate,
> + const struct clk_div_table *table, u8 width,
> + unsigned long flags, unsigned int val);
> int divider_get_val(unsigned long rate, unsigned long parent_rate,
> const struct clk_div_table *table, u8 width,
> unsigned long flags);
> @@ -772,6 +776,17 @@ static inline long divider_round_rate(struct clk_hw *hw, unsigned long rate,
> rate, prate, table, width, flags);
> }
>
Same here (about documentation comment).
> +static inline long divider_ro_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *prate,
> + const struct clk_div_table *table,
> + u8 width, unsigned long flags,
> + unsigned int val)
> +{
> + return divider_ro_round_rate_parent(hw, clk_hw_get_parent(hw),
> + rate, prate, table, width, flags,
> + val);
> +}
> +
> /*
> * FIXME clock api without lock protection
> */
>
^ permalink raw reply
* [linux, dev-4.10, 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon
From: Jae Hyun Yoo @ 2018-01-11 23:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111221845.GA9278@lunn.ch>
On 1/11/2018 2:18 PM, Andrew Lunn wrote:
>>>>> +static const struct of_device_id peci_of_table[] = {
>>>>> + { .compatible = "peci-hwmon", },
>>>>
>>>> This does not look like a reference to some piece of hardware.
>>>>
>>>
>>> This driver provides generic PECI hwmon function to which controller has
>>> PECI HW such as Aspeed or Nuvoton BMC chip so it's not dependant on a
>>> specific hardware. Should I remove this or any suggestion?
>
> PECI seems to be an Intel thing. So at least it should be
>
> { .compatible = "intel,peci-hwmon", }
>
> assuming it is actually compatible with the Intel specification.
>
> Andrew
>
Yes, PECI is an Intel thing but this driver is running on an ARM kernel
on Aspeed or Nuvoton chipsets for now. This driver will be monitoring a
host server's Intel CPU and DIMM which is running on a separated OS.
Thanks,
Jae
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: David Lechner @ 2018-01-11 23:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xL=h_g6HK2ey82r_w5qRbXg9+68Og+84YUYuePsjYd-Vg@mail.gmail.com>
On 01/11/2018 12:09 PM, Adam Ford wrote:
> On Thu, Jan 11, 2018 at 11:22 AM, David Lechner <david@lechnology.com> wrote:
>> On 01/11/2018 06:45 AM, Adam Ford wrote:
>>>
>>> On Wed, Jan 10, 2018 at 8:50 PM, David Lechner <david@lechnology.com>
>>> wrote:
>>>>
>>>> On 01/10/2018 04:24 PM, Adam Ford wrote:
>>>>>
>>>>>
>>>>>
>>>>> I am available tomorrow to build and test patches against the
>>>>> da850-evm. I just need to know which version(s) to test.
>>>>
>>>>
>>>>
>>>> Great. As per the cover letter:
>>>>
>>>> You can find a working branch with everything included in the
>>>> "common-clk-v5"
>>>> branch of https://github.com/dlech/ev3dev-kernel.git.
>>>
>>>
>>> I wasn't sure if things had changed after some of the dialog about the
>>> bindings and device tree.
>>
>>
>> Not yet. ;-)
>>
>>>
>>> Here is my log with DEBUG_LL and CONFIG_EARLY_PRINTK set :
>>>
>>> Starting kernel ...
>>>
>>> Uncompressing Linux... done, booting the kernel.
>>> Booting Linux on physical CPU 0x0
>>> Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
>>> (Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
>>> CST 2018
>>> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
>>> CPU: VIVT data cache, VIVT instruction cache
>>> OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
>>
>>
>> OK, using device tree...
>
> Sorry, I thought I was supposed to. I retested using the board file,
> but it also resulted in a hang.
>
>>
>>
> [snip]
>>
>>
>> If you are getting to this point, you probably don't need DEBUG_LL.
>> It looks like "earlyprint" is not being passed to the command line
>> anyway, so CONFIG_EARLY_PRINTK is not actually doing anything.
>>
>>> brd: module loaded
>>> libphy: Fixed MDIO Bus: probed
>>> davinci_mdio 1e24000.mdio: failed to get device clock
>>> davinci_mdio: probe of 1e24000.mdio failed with error -2
>>
>>
>> It looks like this needs a clock-names property in the device tree.
>> Please make this change and try again:
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index 08a9817..fd3e316 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -713,6 +713,7 @@
>> #size-cells = <0>;
>> reg = <0x224000 0x1000>;
>> clocks = <&psc1 5>;
>> + clock-names = "fck";
>> status = "disabled";
>> };
>> eth0: ethernet at 220000 {
>>
>>
> [snip]
>
> I added your copy-names entry to my device tree and we get a login prompt. :-)
>
>> I'm not sure why there is an error here. I'm using I2C0 on my board,
>> so I am fairly confident that it is not a problem introduced by this
>> series.
>>
>>> console [netcon0] enabled
>>> netconsole: network logging started
>>> davinci_emac 1e20000.ethernet: incompatible machine/device type for
>>> reading mac address
>>> hctosys: unable to open rtc device (rtc0)
>>>
>>
>> What is normally the next line after this in a working boot?
>>
>> Also please try passing "clk_ignore_unused" to the kernel command line.
>
> Here is the log. There seems to be some garbled characters that don't
> seem to appear. I'm going to double check those against the stock
> kernel.
>
>
> Starting kernel ...
>
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
> (Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
> CST 2018
> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
> CPU: VIVT data cache, VIVT instruction cache
> OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
> debug: ignoring loglevel setting.
> bootconsole [earlycon0] enabled
> Memory policy: Data cache writethrough
> cma: Reserved 16 MiB at 0xc2c00000
> DaVinci da850/omap-l138 variant 0x0
> On node 0 totalpages: 16384
> DMA zone: 128 pages used for memmap
> DMA zone: 0 pages reserved
> DMA zone: 16384 pages, LIFO batch:3
> random: fast init done
> pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> pcpu-alloc: [0] 0
> Built 1 zonelists, mobility grouping on. Total pages: 16256
> Kernel command line: console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw
> rootfstype=ext4 rootwait ignore_loglevel earlyprintk clk_ignore_unused
> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Memory: 42164K/65536K available (4548K kernel code, 280K rwdata, 1044K
> rodata, 232K init, 143K bss, 6988K reserved, 16384K cma-reserved)
> Virtual kernel memory layout:
> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
> vmalloc : 0xc4800000 - 0xff800000 ( 944 MB)
> lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
> modules : 0xbf000000 - 0xc0000000 ( 16 MB)
> .text : 0x(ptrval) - 0x(ptrval) (4550 kB)
> .init : 0x(ptrval) - 0x(ptrval) ( 232 kB)
> .data : 0x(ptrval) -&?p`? rval) Qm^?`} b ? $\???? ?! ?
> "V ? ???@ B- d?????}bf ?f? i?console [ttyS2] enabled
> console [ttyS2] enabled??F 0x(ptrval) ( 144 kB)
> bootconsole [earlycon0] disabledObjects=0, CP&?p^?-?Mdes=1
> bootconsole [earlycon0] disabledb ?f? i?a ?F $\????
> brd: module loaded??} ??B
> libphy: Fixed MDIO Bus: probed &?p^?-?I
> davinci_mdio 1e24000.mdio: davinci mdio revision 1.5, bus freq 2200000
> a- R? /^???? ???v at a??.???? ^\?`&?`l??f ?????M??? ?E ??????)?)! ?}?y
> ya bK????? ???
> davinci_mdio 1e24000.mdio: detected phy mask
> fffffffe ??I ")=M??-?)!iD????mi-??I ?k??
> ???)? r??.????i2? ?v? ?k$^????-?-!mD??q} ] ?K???? 6m?R?`? q)?M ???^??
> ??
> libphy: 1e24000.mdio:
> probed&?????a I?j?`?a?I???} 2/?p? bv VK,?q? 6M?- ? ??? ?I ??f??a?I???}
> 2 A-!?a-? ?K????!aMq- ")=I??-?-!mD??} 2 A-!?a-? ?K -? &-=M??-?-!mD?
> davinci_mdio 1e24000.mdio: phy[0]: device 1e24000.mdio:00, driver SMSC
> LAN8710/LAN8720??? I?Sm??aM?-! &??P-4RhR?
> ??-? ?K?^t@?
> i2c /dev entries driver
> davinci_mmc 1c40000.mmc: Using DMA, 4-bit mode
> NET: Registered protocol family 10
> Segment Routing with IPv6
> sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> NET: Registered protocol family 17
> Loading compiled-in X.509 certificates
> mmc0: host does not support reading read-only switch, assuming write-enable
> mmc0: new high speed SDHC card at address b368
> mmcblk0: mmc0:b368 00000 3.75 GiB
> mmcblk0: p1 p2
> pca953x 0-0020: 0-0020 supply vcc not found, using dummy regulator
> pca953x 0-0020: failed reading register
> pca953x: probe of 0-0020 failed with error -121
> console [netcon0] enabled
> netconsole: network logging started
> davinci_emac 1e20000.ethernet: incompatible machine/device type for
> reading mac address
> hctosys: unable to open rtc device (rtc0)
> clk: Not disabling unused clocks
> vbat: disabling
> EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
> VFS: Mounted root (ext4 filesystem) on device 179:2.
> devtmpfs: mounted
> Freeing unused kernel memory: 232K
> This architecture does not have kernel memory protection.
> EXT4-fs (mmcblk0p2): re-mounted. Opts: data=ordered
> Starting logging: OK
> Initializing random number generator... done.
> Starting network: OK
>
> Welcome to Buildroot
> buildroot login:
>
>
>>
>
> However, I get a reboot failure:
>
> umount: devtmpfs busy - remounted read-only
> EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
> The system is going down NOW!
> Sent SIGTERM to all processes
> Sent SIGKILL to all processes
> Requesting system reboot
>
> reboot: Restarting system
> Reboot failed -- System halted
>
Adam,
Did this reboot issue get resolved?
^ permalink raw reply
* [PATCH 34/38] arm: Implement thread_struct whitelist for hardened usercopy
From: Kees Cook @ 2018-01-11 23:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111102400.GT17719@n2100.armlinux.org.uk>
On Thu, Jan 11, 2018 at 2:24 AM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, Jan 10, 2018 at 06:03:06PM -0800, Kees Cook wrote:
>> ARM does not carry FPU state in the thread structure, so it can declare
>> no usercopy whitelist at all.
>
> This comment seems to be misleading. We have stored FP state in the
> thread structure for a long time - for example, VFP state is stored
> in thread->vfpstate.hard, so we _do_ have floating point state in
> the thread structure.
>
> What I think this commit message needs to describe is why we don't
> need a whitelist _despite_ having FP state in the thread structure.
>
> At the moment, the commit message is making me think that this patch
> is wrong and will introduce a regression.
Yeah, I will improve this comment; it's not clear enough. The places
where I see state copied to/from userspace are all either static sizes
or already use bounce buffers (or both). e.g.:
err |= __copy_from_user(&hwstate->fpregs, &ufp->fpregs,
sizeof(hwstate->fpregs));
I will adjust the commit log and comment to more clearly describe the
lack of whitelisting due to all-static sized copies.
Thanks!
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* [PATCH] usb: dwc2: Fix endless deferral probe
From: Arnd Bergmann @ 2018-01-11 23:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7ef21b99-67c8-b246-cc9a-b7202264a7a0@i2se.com>
On Wed, Jan 10, 2018 at 1:15 PM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Hi Arnd,
>
>
> Am 09.01.2018 um 22:33 schrieb Arnd Bergmann:
>>
>> On Tue, Jan 9, 2018 at 8:28 PM, Stefan Wahren <stefan.wahren@i2se.com>
>> wrote:
>>>
>>> The dwc2 USB driver tries to find a generic PHY first and then look
>>> for an old style USB PHY. In case of a valid generic PHY node without
>>> a PHY driver, the PHY layer will return -EPROBE_DEFER forever. So dwc2
>>> will never tries for an USB PHY.
>>>
>>> Fix this issue by finding a generic PHY and an old style USB PHY
>>> at once.
>>
>> This would fix only one of the USB controllers (dwc2), but not the others
>> that are affected. As I wrote in my suggested patch, dwc3 appears to be
>> affected the same way, and all other host drivers that call usb_add_hcd()
>> without first setting hcd->phy would suffer from this as well.
>>
>> If we go down the route of addressing it here in the hcd drivers, we
>> should
>> at least change all three of those, and hope this doesn't regress in
>> another way.
>>
>> Arnd
>
>
> i fully unterstand. But we leaving the path of "fixing a critical issue on
> BCM2835" and go to "fixing multiple USB host controller". I do this all in
> my spare time and don't have any of the other USB controller available. So
> before i proceed with any other patch i like so see some feedback from John,
> Greg or Felipe.
>
> After finalizing this patch i think the chance is little that this would be
> applied to 4.15. So i seems to me that we still revert my DT clean up patch.
Could you confirm that this simpler patch fixes the problem for you?
My feeling right now is that this would be the least invasive variant.
This is obviously a critical regression for BCM2835, but I'm fairly sure
it's just as critical for a lot of other SoCs that haven't done as much
testing on linux-next.
Hans has already verified the earlier (more complex) version, but my
analysis today has made it very likely that this one is fully sufficient
to fix all affected platforms.
Reverting all nine patches that add #phy-cells would still be an option,
but seems way more invasive at this point.
Arnd
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index b4964b067aec..93b55fb71d54 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -410,6 +410,10 @@ static struct phy *_of_phy_get(struct device_node
*np, int index)
if (ret)
return ERR_PTR(-ENODEV);
+ /* This phy type handled by the usb-phy subsystem for now */
+ if (of_device_is_compatible(np, "usb-nop-xceiv"))
+ return ERR_PTR(-ENODEV);
+
mutex_lock(&phy_provider_mutex);
phy_provider = of_phy_provider_lookup(args.np);
if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
^ permalink raw reply related
* [linux, dev-4.10, 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon
From: Andrew Lunn @ 2018-01-11 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <463412a8-ad34-264d-0f44-bd383f100b44@linux.intel.com>
On Thu, Jan 11, 2018 at 03:14:37PM -0800, Jae Hyun Yoo wrote:
> On 1/11/2018 2:18 PM, Andrew Lunn wrote:
> >>>>>+static const struct of_device_id peci_of_table[] = {
> >>>>>+ { .compatible = "peci-hwmon", },
> >>>>
> >>>>This does not look like a reference to some piece of hardware.
> >>>>
> >>>
> >>>This driver provides generic PECI hwmon function to which controller has
> >>>PECI HW such as Aspeed or Nuvoton BMC chip so it's not dependant on a
> >>>specific hardware. Should I remove this or any suggestion?
> >
> >PECI seems to be an Intel thing. So at least it should be
> >
> > { .compatible = "intel,peci-hwmon", }
> >
> >assuming it is actually compatible with the Intel specification.
> >
> > Andrew
> >
>
> Yes, PECI is an Intel thing but this driver is running on an ARM kernel on
> Aspeed or Nuvoton chipsets for now. This driver will be monitoring a host
> server's Intel CPU and DIMM which is running on a separated OS.
Hi Jae
You need to be careful with the name then. You should not claim the
name 'peci' in case somebody actually implements a PECI driver which
is compatible with Intel PECI.
However, looking at other comments, it seems like this part is going
away, if you turn your code into a bus driver.
Andrew
^ permalink raw reply
* [patch v15 3/4] Documentation: jtag: Add bindings for Aspeed SoC 24xx and 25xx families JTAG master driver
From: Joel Stanley @ 2018-01-11 23:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8XfH-4r0mBQYA+BwvUo2+RF8igai2jy+RqTDQcxx2-acsQ@mail.gmail.com>
On Thu, Jan 11, 2018 at 9:50 AM, Joel Stanley <joel@jms.id.au> wrote:
> On Mon, Dec 25, 2017 at 3:53 AM, Oleksandr Shamray <oleksandrs@mellanox.com> wrote:
>> +jtag: jtag at 1e6e4000 {
>> + compatible = "aspeed,ast2500-jtag";
>> + reg = <0x1e6e4000 0x1c>;
>> + clocks = <&clk_apb>;
>
> We've now got a proper clock driver upstream. Can you update the
> example to match the newly added bindings?
>
> clocks = <&syscon ASPEED_CLK_APB>;
>
I think we need to ensure the reset is deasserted as well. You will need:
resets = <&syscon ASPEED_RESET_JTAG_MASTER>;
In addition, we need to make sure the reset line is deasserted in the
driver. Take a look at how I did this in the i2c driver:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=edd20e95bca4a5434f264d8ab40d729761479825
+ bus->rst = devm_reset_control_get_shared(&pdev->dev, NULL);
+ if (IS_ERR(bus->rst)) {
+ dev_err(&pdev->dev,
+ "missing or invalid reset controller device
tree entry");
+ return PTR_ERR(bus->rst);
+ }
+ reset_control_deassert(bus->rst);
Please give this a test with an upstream kernel from a fresh power on.
Cheers,
Joel
^ permalink raw reply
* [PATCH V4 00/26] PCI: deprecate pci_get_bus_and_slot()
From: Bjorn Helgaas @ 2018-01-11 23:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
On Tue, Dec 19, 2017 at 12:37:36AM -0500, Sinan Kaya wrote:
> Deprecate pci_get_bus_and_slot() in favor of pci_get_domain_bus_and_slot()
> in order to remove domain 0 assumptions in the kernel.
>
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't
> extract the domain number. Other places, use the actual domain number from
> the device.
>
> Changes from v3:
> * rebase to linux-next
> * drop drm i915 as it is going through the drm tip
> * commit summary cleanups
>
> Sinan Kaya (26):
I applied most of these on pci/deprecate-get-bus-and-slot for v4.16.
Details below:
> alpha/PCI: deprecate pci_get_bus_and_slot()
Applied.
> powerpc/PCI: deprecate pci_get_bus_and_slot()
Aplied with Michael's ack.
> x86/PCI: deprecate pci_get_bus_and_slot()
> ata: deprecate pci_get_bus_and_slot()
> agp: nvidia: deprecate pci_get_bus_and_slot()
> edd: deprecate pci_get_bus_and_slot()
> ibft: deprecate pci_get_bus_and_slot()
> drm/gma500: deprecate pci_get_bus_and_slot()
> drm/nouveau: deprecate pci_get_bus_and_slot()
Applied.
> Drivers: ide: deprecate pci_get_bus_and_slot()
Applied with David's ack.
> iommu/amd: deprecate pci_get_bus_and_slot()
Applied with Gary's informal approval converted to
Reviewed-by: Gary R Hook <gary.hook@amd.com>.
> powerpc/powermac: deprecate pci_get_bus_and_slot()
Applied.
> bnx2x: deprecate pci_get_bus_and_slot()
> pch_gbe: deprecate pci_get_bus_and_slot()
Applied with David's ack.
> PCI: cpqhp: deprecate pci_get_bus_and_slot()
> PCI: ibmphp: deprecate pci_get_bus_and_slot()
Applied.
> PCI/quirks: deprecate pci_get_bus_and_slot()
> PCI/syscall: deprecate pci_get_bus_and_slot()
Applied (squashed together).
> xen: deprecate pci_get_bus_and_slot()
Applied.
> openprom: deprecate pci_get_bus_and_slot()
Applied with David's ack.
> backlight: deprecate pci_get_bus_and_slot()
Dropped because Lee applied it.
> video: fbdev: intelfb: deprecate pci_get_bus_and_slot()
> video: fbdev: nvidia: deprecate pci_get_bus_and_slot()
> video: fbdev: riva: deprecate pci_get_bus_and_slot()
Applied with Bartlomiej's ack.
> i7300_idle: remove unused file
Dropped because Greg KH picked it up.
> PCI: Remove pci_get_bus_and_slot() function
Deferred so pull requests during the merge window can happen in any
order. We can remove it at the end of the merge window or during the
next cycle.
Bjorn
^ permalink raw reply
* PM regression in next
From: Tony Lindgren @ 2018-01-12 0:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I'm seeing a considerable idle power consumption regression in
Linux next, with power consumption for my idle test system going
to 17.5mW compared to the usual 8mW on my test device.
Git bisect points to merge commit e130bc1d00a4 ("Merge branch
'akpm-current/current'") being the first bad commit.
I have also verified that commit 70286688e5ad ("ipc/mqueue.c:
have RT tasks queue in by priority in wq_add()") is good, and
commit e2d7fe89e8ae ("Merge remote-tracking branch
'init_task/init_task'") is good.
Any ideas?
Regards,
Tony
^ permalink raw reply
* [PATCHv2] ARM: dts: Update ti-sysc data for existing users
From: Tony Lindgren @ 2018-01-12 0:06 UTC (permalink / raw)
To: linux-arm-kernel
Let's update the existing users with features and clock data as
specified in the binding. This is currently the smartreflex for most
part, and also few omap4 modules with no child device driver like
mcasp, abe iss and gfx.
Note that we had few mistakes that did not get noticed as we're still
probing the SmartReflex driver with legacy platform data and using
"ti,hwmods" legacy property for ti-sysc driver.
So let's fix the omap4 and dra7 smartreflex registers as there is no
no revision register.
And on omap4, the mcasp module has a revision register according to
the TRM.
And for omap34xx we need a different configuration compared to 36xx.
And the smartreflex on 3517 we've always kept disabled so let's
remove any references to it.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
Here's this one again, turns out more smartreflex fixes were needed
---
arch/arm/boot/dts/am3517.dtsi | 4 --
arch/arm/boot/dts/dra7.dtsi | 26 +++++++---
arch/arm/boot/dts/omap3.dtsi | 14 ------
arch/arm/boot/dts/omap34xx.dtsi | 39 +++++++++++++++
arch/arm/boot/dts/omap36xx.dtsi | 46 ++++++++++++++++++
arch/arm/boot/dts/omap4.dtsi | 104 +++++++++++++++++++++++++++++++++++-----
6 files changed, 198 insertions(+), 35 deletions(-)
diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
--- a/arch/arm/boot/dts/am3517.dtsi
+++ b/arch/arm/boot/dts/am3517.dtsi
@@ -99,9 +99,5 @@
status = "disabled";
};
-&smartreflex_mpu_iva {
- status = "disabled";
-};
-
/include/ "am35xx-clocks.dtsi"
/include/ "omap36xx-am35xx-omap3430es2plus-clocks.dtsi"
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -7,6 +7,8 @@
* Based on "omap4.dtsi"
*/
+#include <dt-bindings/bus/ti-sysc.h>
+#include <dt-bindings/clock/dra7.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/pinctrl/dra.h>
#include <dt-bindings/clock/dra7.h>
@@ -1523,9 +1525,15 @@
target-module at 4a0dd000 {
compatible = "ti,sysc-omap4-sr", "ti,sysc";
ti,hwmods = "smartreflex_core";
- reg = <0x4a0dd000 0x4>,
- <0x4a0dd008 0x4>;
- reg-names = "rev", "sysc";
+ reg = <0x4a0dd038 0x4>;
+ reg-names = "sysc";
+ ti,sysc-mask = <SYSC_OMAP3_SR_ENAWAKEUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ clocks = <&coreaon_clkctrl DRA7_SMARTREFLEX_CORE_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x4a0dd000 0x001000>;
@@ -1536,9 +1544,15 @@
target-module at 4a0d9000 {
compatible = "ti,sysc-omap4-sr", "ti,sysc";
ti,hwmods = "smartreflex_mpu";
- reg = <0x4a0d9000 0x4>,
- <0x4a0d9008 0x4>;
- reg-names = "rev", "sysc";
+ reg = <0x4a0d9038 0x4>;
+ reg-names = "sysc";
+ ti,sysc-mask = <SYSC_OMAP3_SR_ENAWAKEUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ clocks = <&coreaon_clkctrl DRA7_SMARTREFLEX_MPU_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x4a0d9000 0x001000>;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -587,20 +587,6 @@
dma-names = "rx";
};
- smartreflex_core: smartreflex at 480cb000 {
- compatible = "ti,omap3-smartreflex-core";
- ti,hwmods = "smartreflex_core";
- reg = <0x480cb000 0x400>;
- interrupts = <19>;
- };
-
- smartreflex_mpu_iva: smartreflex at 480c9000 {
- compatible = "ti,omap3-smartreflex-mpu-iva";
- ti,hwmods = "smartreflex_mpu_iva";
- reg = <0x480c9000 0x400>;
- interrupts = <18>;
- };
-
timer1: timer at 48318000 {
compatible = "ti,omap3430-timer";
reg = <0x48318000 0x400>;
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -8,6 +8,7 @@
* kind, whether express or implied.
*/
+#include <dt-bindings/bus/ti-sysc.h>
#include <dt-bindings/media/omap3-isp.h>
#include "omap3.dtsi"
@@ -61,6 +62,44 @@
compatible = "ti,omap34xx-bandgap";
#thermal-sensor-cells = <0>;
};
+
+ target-module at 480cb000 {
+ compatible = "ti,sysc-omap3430-sr", "ti,sysc";
+ ti,hwmods = "smartreflex_core";
+ reg = <0x480cb024 0x4>;
+ reg-names = "sysc";
+ ti,sysc-mask = <SYSC_OMAP2_CLOCKACTIVITY>;
+ clocks = <&sr2_fck>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x480cb000 0x001000>;
+
+ smartreflex_core: smartreflex at 0 {
+ compatible = "ti,omap3-smartreflex-core";
+ reg = <0 0x400>;
+ interrupts = <19>;
+ };
+ };
+
+ target-module at 480c9000 {
+ compatible = "ti,sysc-omap3430-sr", "ti,sysc";
+ ti,hwmods = "smartreflex_mpu_iva";
+ reg = <0x480c9024 0x4>;
+ reg-names = "sysc";
+ ti,sysc-mask = <SYSC_OMAP2_CLOCKACTIVITY>;
+ clocks = <&sr1_fck>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x480c9000 0x001000>;
+
+ smartreflex_mpu_iva: smartreflex at 480c9000 {
+ compatible = "ti,omap3-smartreflex-mpu-iva";
+ reg = <0 0x400>;
+ interrupts = <18>;
+ };
+ };
};
thermal_zones: thermal-zones {
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -8,6 +8,7 @@
* kind, whether express or implied.
*/
+#include <dt-bindings/bus/ti-sysc.h>
#include <dt-bindings/media/omap3-isp.h>
#include "omap3.dtsi"
@@ -93,6 +94,51 @@
compatible = "ti,omap36xx-bandgap";
#thermal-sensor-cells = <0>;
};
+
+ target-module at 480cb000 {
+ compatible = "ti,sysc-omap3630-sr", "ti,sysc";
+ ti,hwmods = "smartreflex_core";
+ reg = <0x480cb038 0x4>;
+ reg-names = "sysc";
+ ti,sysc-mask = <SYSC_OMAP3_SR_ENAWAKEUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>;
+ clocks = <&sr2_fck>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x480cb000 0x001000>;
+
+ smartreflex_core: smartreflex at 0 {
+ compatible = "ti,omap3-smartreflex-core";
+ reg = <0 0x400>;
+ interrupts = <19>;
+ };
+ };
+
+ target-module at 480c9000 {
+ compatible = "ti,sysc-omap3630-sr", "ti,sysc";
+ ti,hwmods = "smartreflex_mpu_iva";
+ reg = <0x480c9038 0x4>;
+ reg-names = "sysc";
+ ti,sysc-mask = <SYSC_OMAP3_SR_ENAWAKEUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>;
+ clocks = <&sr1_fck>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x480c9000 0x001000>;
+
+
+ smartreflex_mpu_iva: smartreflex at 480c9000 {
+ compatible = "ti,omap3-smartreflex-mpu-iva";
+ reg = <0 0x400>;
+ interrupts = <18>;
+ };
+ };
};
thermal_zones: thermal-zones {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -6,6 +6,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/bus/ti-sysc.h>
+#include <dt-bindings/clock/omap4.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/pinctrl/omap.h>
@@ -398,6 +400,13 @@
reg = <0x48076000 0x4>,
<0x48076010 0x4>;
reg-names = "rev", "sysc";
+ ti,sysc-mask = <SYSC_OMAP4_SOFTRESET>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ clocks = <&l4_per_clkctrl OMAP4_SLIMBUS2_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x48076000 0x001000>;
@@ -468,9 +477,15 @@
target-module at 4a0db000 {
compatible = "ti,sysc-omap4-sr", "ti,sysc";
ti,hwmods = "smartreflex_iva";
- reg = <0x4a0db000 0x4>,
- <0x4a0db008 0x4>;
- reg-names = "rev", "sysc";
+ reg = <0x4a0db038 0x4>;
+ reg-names = "sysc";
+ ti,sysc-mask = <SYSC_OMAP3_SR_ENAWAKEUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ clocks = <&l4_ao_clkctrl OMAP4_SMARTREFLEX_IVA_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x4a0db000 0x001000>;
@@ -485,9 +500,15 @@
target-module at 4a0dd000 {
compatible = "ti,sysc-omap4-sr", "ti,sysc";
ti,hwmods = "smartreflex_core";
- reg = <0x4a0dd000 0x4>,
- <0x4a0dd008 0x4>;
- reg-names = "rev", "sysc";
+ reg = <0x4a0dd038 0x4>;
+ reg-names = "sysc";
+ ti,sysc-mask = <SYSC_OMAP3_SR_ENAWAKEUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ clocks = <&l4_ao_clkctrl OMAP4_SMARTREFLEX_CORE_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x4a0dd000 0x001000>;
@@ -502,9 +523,15 @@
target-module at 4a0d9000 {
compatible = "ti,sysc-omap4-sr", "ti,sysc";
ti,hwmods = "smartreflex_mpu";
- reg = <0x4a0d9000 0x4>,
- <0x4a0d9008 0x4>;
- reg-names = "rev", "sysc";
+ reg = <0x4a0d9038 0x4>;
+ reg-names = "sysc";
+ ti,sysc-mask = <SYSC_OMAP3_SR_ENAWAKEUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ clocks = <&l4_ao_clkctrl OMAP4_SMARTREFLEX_MPU_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x4a0d9000 0x001000>;
@@ -725,6 +752,18 @@
reg = <0x52000000 0x4>,
<0x52000010 0x4>;
reg-names = "rev", "sysc";
+ ti,sysc-mask = <SYSC_OMAP4_SOFTRESET>;
+ ti,sysc-midle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ ti,sysc-delay-us = <2>;
+ clocks = <&iss_clkctrl OMAP4_ISS_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x52000000 0x1000000>;
@@ -829,8 +868,15 @@
target-module at 40128000 {
compatible = "ti,sysc-mcasp", "ti,sysc";
ti,hwmods = "mcasp";
- reg = <0x40128004 0x4>;
- reg-names = "sysc";
+ reg = <0x40128000 0x4>,
+ <0x40128004 0x4>;
+ reg-names = "rev", "sysc";
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ clocks = <&abe_clkctrl OMAP4_MCASP_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x40128000 0x1000>, /* MPU */
@@ -850,6 +896,13 @@
reg = <0x4012c000 0x4>,
<0x4012c010 0x4>;
reg-names = "rev", "sysc";
+ ti,sysc-mask = <SYSC_OMAP4_SOFTRESET>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ clocks = <&abe_clkctrl OMAP4_SLIMBUS1_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x4012c000 0x1000>, /* MPU */
@@ -864,6 +917,15 @@
reg = <0x401f1000 0x4>,
<0x401f1010 0x4>;
reg-names = "rev", "sysc";
+ ti,sysc-midle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>;
+ clocks = <&abe_clkctrl OMAP4_AESS_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x401f1000 0x1000>, /* MPU */
@@ -970,6 +1032,16 @@
reg = <0x4a10a000 0x4>,
<0x4a10a010 0x4>;
reg-names = "rev", "sysc";
+ ti,sysc-mask = <SYSC_OMAP4_SOFTRESET>;
+ ti,sysc-midle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>;
+ ti,sysc-delay-us = <2>;
+ clocks = <&iss_clkctrl OMAP4_FDIF_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x4a10a000 0x1000>;
@@ -1199,6 +1271,16 @@
reg = <0x5601fc00 0x4>,
<0x5601fc10 0x4>;
reg-names = "rev", "sysc";
+ ti,sysc-midle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ ti,sysc-sidle = <SYSC_IDLE_FORCE>,
+ <SYSC_IDLE_NO>,
+ <SYSC_IDLE_SMART>,
+ <SYSC_IDLE_SMART_WKUP>;
+ clocks = <&l3_gfx_clkctrl OMAP4_GPU_CLKCTRL 0>;
+ clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x56000000 0x2000000>;
--
2.15.0
^ permalink raw reply
* PM regression in next
From: Andrew Morton @ 2018-01-12 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112000037.GA3875@atomide.com>
On Thu, 11 Jan 2018 16:01:13 -0800 Tony Lindgren <tony@atomide.com> wrote:
> Hi all,
>
> I'm seeing a considerable idle power consumption regression in
> Linux next, with power consumption for my idle test system going
> to 17.5mW compared to the usual 8mW on my test device.
>
> Git bisect points to merge commit e130bc1d00a4 ("Merge branch
> 'akpm-current/current'") being the first bad commit.
>
> I have also verified that commit 70286688e5ad ("ipc/mqueue.c:
> have RT tasks queue in by priority in wq_add()") is good, and
> commit e2d7fe89e8ae ("Merge remote-tracking branch
> 'init_task/init_task'") is good.
Do you mean that everything up to and including 70286688e5ad
("ipc/mqueue.c: have RT tasks queue in by priority in wq_add()") is
good?
^ permalink raw reply
* PM regression in next
From: Tony Lindgren @ 2018-01-12 0:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111161837.f1c1d891a1b80d97e30a9b1b@linux-foundation.org>
* Andrew Morton <akpm@linux-foundation.org> [180112 00:18]:
> On Thu, 11 Jan 2018 16:01:13 -0800 Tony Lindgren <tony@atomide.com> wrote:
>
> > Hi all,
> >
> > I'm seeing a considerable idle power consumption regression in
> > Linux next, with power consumption for my idle test system going
> > to 17.5mW compared to the usual 8mW on my test device.
> >
> > Git bisect points to merge commit e130bc1d00a4 ("Merge branch
> > 'akpm-current/current'") being the first bad commit.
> >
> > I have also verified that commit 70286688e5ad ("ipc/mqueue.c:
> > have RT tasks queue in by priority in wq_add()") is good, and
> > commit e2d7fe89e8ae ("Merge remote-tracking branch
> > 'init_task/init_task'") is good.
>
> Do you mean that everything up to and including 70286688e5ad
> ("ipc/mqueue.c: have RT tasks queue in by priority in wq_add()") is
> good?
Yes I'm not seeing the regression in your branch at commit
70286688e5ad. I'm seeing it only with the merge commit
e130bc1d00a4.
Regards,
Tony
^ permalink raw reply
* [linux, dev-4.10, 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon
From: Jae Hyun Yoo @ 2018-01-12 0:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111235346.GA13443@lunn.ch>
On 1/11/2018 3:53 PM, Andrew Lunn wrote:
> On Thu, Jan 11, 2018 at 03:14:37PM -0800, Jae Hyun Yoo wrote:
>> On 1/11/2018 2:18 PM, Andrew Lunn wrote:
>>>>>>> +static const struct of_device_id peci_of_table[] = {
>>>>>>> + { .compatible = "peci-hwmon", },
>>>>>>
>>>>>> This does not look like a reference to some piece of hardware.
>>>>>>
>>>>>
>>>>> This driver provides generic PECI hwmon function to which controller has
>>>>> PECI HW such as Aspeed or Nuvoton BMC chip so it's not dependant on a
>>>>> specific hardware. Should I remove this or any suggestion?
>>>
>>> PECI seems to be an Intel thing. So at least it should be
>>>
>>> { .compatible = "intel,peci-hwmon", }
>>>
>>> assuming it is actually compatible with the Intel specification.
>>>
>>> Andrew
>>>
>>
>> Yes, PECI is an Intel thing but this driver is running on an ARM kernel on
>> Aspeed or Nuvoton chipsets for now. This driver will be monitoring a host
>> server's Intel CPU and DIMM which is running on a separated OS.
>
> Hi Jae
>
> You need to be careful with the name then. You should not claim the
> name 'peci' in case somebody actually implements a PECI driver which
> is compatible with Intel PECI.
>
> However, looking at other comments, it seems like this part is going
> away, if you turn your code into a bus driver.
>
> Andrew
>
Hi Andrew,
I see. I'll keep that in mind and will keep finding if there is any
better way. Thanks for sharing your thought.
Jae
^ permalink raw reply
* [PATCH 2/9] iommu/rockchip: Fix error handling in attach
From: JeffyChen @ 2018-01-12 0:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <427ecf29-2024-b746-c567-903c1ce02e75@arm.com>
Hi Robin,
thanks for your reply.
On 01/11/2018 11:47 PM, Robin Murphy wrote:
>>
>> + for (i = 0; i < iommu->num_irq; i++) {
>> + ret = devm_request_irq(iommu->dev, iommu->irq[i], rk_iommu_irq,
>> + IRQF_SHARED, dev_name(dev), iommu);
>
> Why aren't we simply requesting the IRQ once in rk_iommu_probe()? Given
> that the hardware doesn't handle multiple translation contexts, there
> doesn't seem to be much point in being this dynamic about it.
>
it make sense, will do it in next version:)
> Robin.
^ permalink raw reply
* PM regression in next
From: Andrew Morton @ 2018-01-12 0:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112002322.GB3875@atomide.com>
On Thu, 11 Jan 2018 16:23:22 -0800 Tony Lindgren <tony@atomide.com> wrote:
> * Andrew Morton <akpm@linux-foundation.org> [180112 00:18]:
> > On Thu, 11 Jan 2018 16:01:13 -0800 Tony Lindgren <tony@atomide.com> wrote:
> >
> > > Hi all,
> > >
> > > I'm seeing a considerable idle power consumption regression in
> > > Linux next, with power consumption for my idle test system going
> > > to 17.5mW compared to the usual 8mW on my test device.
> > >
> > > Git bisect points to merge commit e130bc1d00a4 ("Merge branch
> > > 'akpm-current/current'") being the first bad commit.
> > >
> > > I have also verified that commit 70286688e5ad ("ipc/mqueue.c:
> > > have RT tasks queue in by priority in wq_add()") is good, and
> > > commit e2d7fe89e8ae ("Merge remote-tracking branch
> > > 'init_task/init_task'") is good.
> >
> > Do you mean that everything up to and including 70286688e5ad
> > ("ipc/mqueue.c: have RT tasks queue in by priority in wq_add()") is
> > good?
>
> Yes I'm not seeing the regression in your branch at commit
> 70286688e5ad. I'm seeing it only with the merge commit
> e130bc1d00a4.
>
That's weird. All I'm seeing between 70286688e5ad and end-of-mm is:
tools-objtool-makefile-dont-assume-sync-checksh-is-executable.patch
ipc-mqueue-add-missing-error-code-in-init_mqueue_fs.patch
vfs-remove-might_sleep-from-clear_inode.patch
mm-remove-duplicate-includes.patch
mm-remove-unneeded-kallsyms-include.patch
hrtimer-remove-unneeded-kallsyms-include.patch
genirq-remove-unneeded-kallsyms-include.patch
mm-memblock-memblock_is_map-region_memory-can-be-boolean.patch
lib-lockref-__lockref_is_dead-can-be-boolean.patch
kernel-cpuset-current_cpuset_is_being_rebound-can-be-boolean.patch
kernel-resource-iomem_is_exclusive-can-be-boolean.patch
kernel-module-module_is_live-can-be-boolean.patch
kernel-mutex-mutex_is_locked-can-be-boolean.patch
crash_dump-is_kdump_kernel-can-be-boolean.patch
fix-const-confusion-in-certs-blacklist.patch
fix-read-buffer-overflow-in-delta-ipc.patch
kasan-rework-kconfig-settings.patch
sparc64-ng4-memset-32-bits-overflow.patch
lib-crc-ccitt-add-ccitt-false-crc16-variant.patch
And I don't see how any of those can cause this. Did anything else
change, like context switch rates, interrupt rates, etc?
^ permalink raw reply
* [GIT PULL v2 5/5] i.MX defconfig updates for 4.16
From: Olof Johansson @ 2018-01-12 0:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515209554-21082-1-git-send-email-shawnguo@kernel.org>
On Sat, Jan 06, 2018 at 11:32:34AM +0800, Shawn Guo wrote:
> Changes for v2:
> Drop savedefconfig changes from patch 'ARM: imx_v6_v7_defconfig: enable
> CONFIG_CPU_FREQ_STAT'.
>
> The following changes since commit 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36:
>
> Linux 4.15-rc3 (2017-12-10 17:56:26 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-defconfig-4.16
>
> for you to fetch changes up to 495a68d74dfe25f8d441e3493ba447fb1ed209f1:
>
> ARM: imx_v6_v7_defconfig: enable CONFIG_CPU_FREQ_STAT (2018-01-06 10:45:51 +0800)
>
> ----------------------------------------------------------------
> i.MX defconfig updates for 4.16:
> - Enable CPU_FREQ_STAT for cpufreq transtion statistics support.
> - Enable SRTC driver RTC_DRV_MXC_V2 for i.MX53.
> - Turn on a few drivers useful for DART-MX6 SoM support, SERDEV
> bluetooth, SERIAL_DEV_BUS, WL18XX, and DEFAULT_ON LED Trigger.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT changes for v4.16, round 3
From: Olof Johansson @ 2018-01-12 0:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hh8rz25of.fsf@baylibre.com>
On Fri, Jan 05, 2018 at 04:26:40PM -0800, Kevin Hilman wrote:
> Arnd, Olof,
>
> A final round of 64-bit DT changes for Amlogic SoCs.
>
> These were just waiting for the clock dependencies to land in the clock
> tree which they now have. I've merged the same tag into this branch to
> avoid any dependency issues.
>
> Thanks,
Thanks, merged.
-Olof
^ permalink raw reply
* [GIT PULL] Allwinner DT changes for 4.16, step 2
From: Olof Johansson @ 2018-01-12 0:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a09eNwCZbjxxDad8hANmm8m_a_eeGK2bB+1N_Q9152Z1w@mail.gmail.com>
On Fri, Jan 05, 2018 at 05:51:35PM +0100, Arnd Bergmann wrote:
> On Fri, Jan 5, 2018 at 11:22 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi Arnd, Olof,
> >
> > Happy new year :)
> >
> > Here is the second bunch of changes we talked about in our first PR.
> >
> > There's one fix for 4.16, and the other patches have been around for
> > quite a while that I'm feeling confident that we should merge them.
>
> Pulled into next/dt
Looks like this went into fixes instead of next/dt, so I've moved it over.
> > On a side note, my GPG key changed recently. The new fingerprint is
> > 2BA0E943D27E3D2094B10B24D824ECA89C346DCE, and you'll find that it has
> > been signed by a bunch of kernel developpers already. The old one is
> > superseeded, but has not been compromised.
>
> Ok.
Thanks for the heads up!
-Olof
^ permalink raw reply
* [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS
From: Eric W. Biederman @ 2018-01-12 0:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87373b6ghs.fsf@xmission.com>
Setting si_code to 0 results in a userspace seeing an si_code of 0.
This is the same si_code as SI_USER. Posix and common sense requires
that SI_USER not be a signal specific si_code. As such this use of 0
for the si_code is a pretty horribly broken ABI.
Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
value of __SI_KILL and now sees a value of SIL_KILL with the result
that uid and pid fields are copied and which might copying the si_addr
field by accident but certainly not by design. Making this a very
flakey implementation.
Utilizing FPE_FIXME, BUS_FIXME, TRAP_FIXME siginfo_layout will now return
SIL_FAULT and the appropriate fields will be reliably copied.
But folks this is a new and unique kind of bad. This is massively
untested code bad. This is inventing new and unique was to get
siginfo wrong bad. This is don't even think about Posix or what
siginfo means bad. This is lots of eyeballs all missing the fact
that the code does the wrong thing bad. This is getting stuck
and keep making the same mistake bad.
I really hope we can find a non userspace breaking fix for this on a
port as new as arm64.
Possible ABI fixes include:
- Send the signal without siginfo
- Don't generate a signal
- Possibly assign and use an appropriate si_code
- Don't handle cases which can't happen
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Tyler Baicar <tbaicar@codeaurora.org>
Cc: James Morse <james.morse@arm.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Nicolas Pitre <nico@linaro.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel at lists.infradead.org
Ref: 53631b54c870 ("arm64: Floating point and SIMD")
Ref: 32015c235603 ("arm64: exception: handle Synchronous External Abort")
Ref: 1d18c47c735e ("arm64: MMU fault handling and page table management")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
arch/arm64/include/uapi/asm/siginfo.h | 21 +++++++
arch/arm64/kernel/fpsimd.c | 2 +-
arch/arm64/mm/fault.c | 114 +++++++++++++++++-----------------
kernel/signal.c | 4 ++
4 files changed, 83 insertions(+), 58 deletions(-)
diff --git a/arch/arm64/include/uapi/asm/siginfo.h b/arch/arm64/include/uapi/asm/siginfo.h
index 574d12f86039..9b4d91277742 100644
--- a/arch/arm64/include/uapi/asm/siginfo.h
+++ b/arch/arm64/include/uapi/asm/siginfo.h
@@ -21,4 +21,25 @@
#include <asm-generic/siginfo.h>
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+/*
+ * SIGBUS si_codes
+ */
+#ifdef __KERNEL__
+#define BUS_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+/*
+ * SIGTRAP si_codes
+ */
+#ifdef __KERNEL__
+#define TRAP_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
#endif
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index fae81f7964b4..ad0edf31e247 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -867,7 +867,7 @@ asmlinkage void do_fpsimd_acc(unsigned int esr, struct pt_regs *regs)
asmlinkage void do_fpsimd_exc(unsigned int esr, struct pt_regs *regs)
{
siginfo_t info;
- unsigned int si_code = 0;
+ unsigned int si_code = FPE_FIXME;
if (esr & FPEXC_IOF)
si_code = FPE_FLTINV;
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 9b7f89df49db..abe200587334 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -596,7 +596,7 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
info.si_signo = SIGBUS;
info.si_errno = 0;
- info.si_code = 0;
+ info.si_code = BUS_FIXME;
if (esr & ESR_ELx_FnV)
info.si_addr = NULL;
else
@@ -607,70 +607,70 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
}
static const struct fault_info fault_info[] = {
- { do_bad, SIGBUS, 0, "ttbr address size fault" },
- { do_bad, SIGBUS, 0, "level 1 address size fault" },
- { do_bad, SIGBUS, 0, "level 2 address size fault" },
- { do_bad, SIGBUS, 0, "level 3 address size fault" },
+ { do_bad, SIGBUS, BUS_FIXME, "ttbr address size fault" },
+ { do_bad, SIGBUS, BUS_FIXME, "level 1 address size fault" },
+ { do_bad, SIGBUS, BUS_FIXME, "level 2 address size fault" },
+ { do_bad, SIGBUS, BUS_FIXME, "level 3 address size fault" },
{ do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 0 translation fault" },
{ do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 1 translation fault" },
{ do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 2 translation fault" },
{ do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 3 translation fault" },
- { do_bad, SIGBUS, 0, "unknown 8" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 8" },
{ do_page_fault, SIGSEGV, SEGV_ACCERR, "level 1 access flag fault" },
{ do_page_fault, SIGSEGV, SEGV_ACCERR, "level 2 access flag fault" },
{ do_page_fault, SIGSEGV, SEGV_ACCERR, "level 3 access flag fault" },
- { do_bad, SIGBUS, 0, "unknown 12" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 12" },
{ do_page_fault, SIGSEGV, SEGV_ACCERR, "level 1 permission fault" },
{ do_page_fault, SIGSEGV, SEGV_ACCERR, "level 2 permission fault" },
{ do_page_fault, SIGSEGV, SEGV_ACCERR, "level 3 permission fault" },
- { do_sea, SIGBUS, 0, "synchronous external abort" },
- { do_bad, SIGBUS, 0, "unknown 17" },
- { do_bad, SIGBUS, 0, "unknown 18" },
- { do_bad, SIGBUS, 0, "unknown 19" },
- { do_sea, SIGBUS, 0, "level 0 (translation table walk)" },
- { do_sea, SIGBUS, 0, "level 1 (translation table walk)" },
- { do_sea, SIGBUS, 0, "level 2 (translation table walk)" },
- { do_sea, SIGBUS, 0, "level 3 (translation table walk)" },
- { do_sea, SIGBUS, 0, "synchronous parity or ECC error" }, // Reserved when RAS is implemented
- { do_bad, SIGBUS, 0, "unknown 25" },
- { do_bad, SIGBUS, 0, "unknown 26" },
- { do_bad, SIGBUS, 0, "unknown 27" },
- { do_sea, SIGBUS, 0, "level 0 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
- { do_sea, SIGBUS, 0, "level 1 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
- { do_sea, SIGBUS, 0, "level 2 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
- { do_sea, SIGBUS, 0, "level 3 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
- { do_bad, SIGBUS, 0, "unknown 32" },
+ { do_sea, SIGBUS, BUS_FIXME, "synchronous external abort" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 17" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 18" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 19" },
+ { do_sea, SIGBUS, BUS_FIXME, "level 0 (translation table walk)" },
+ { do_sea, SIGBUS, BUS_FIXME, "level 1 (translation table walk)" },
+ { do_sea, SIGBUS, BUS_FIXME, "level 2 (translation table walk)" },
+ { do_sea, SIGBUS, BUS_FIXME, "level 3 (translation table walk)" },
+ { do_sea, SIGBUS, BUS_FIXME, "synchronous parity or ECC error" }, // Reserved when RAS is implemented
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 25" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 26" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 27" },
+ { do_sea, SIGBUS, BUS_FIXME, "level 0 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
+ { do_sea, SIGBUS, BUS_FIXME, "level 1 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
+ { do_sea, SIGBUS, BUS_FIXME, "level 2 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
+ { do_sea, SIGBUS, BUS_FIXME, "level 3 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 32" },
{ do_alignment_fault, SIGBUS, BUS_ADRALN, "alignment fault" },
- { do_bad, SIGBUS, 0, "unknown 34" },
- { do_bad, SIGBUS, 0, "unknown 35" },
- { do_bad, SIGBUS, 0, "unknown 36" },
- { do_bad, SIGBUS, 0, "unknown 37" },
- { do_bad, SIGBUS, 0, "unknown 38" },
- { do_bad, SIGBUS, 0, "unknown 39" },
- { do_bad, SIGBUS, 0, "unknown 40" },
- { do_bad, SIGBUS, 0, "unknown 41" },
- { do_bad, SIGBUS, 0, "unknown 42" },
- { do_bad, SIGBUS, 0, "unknown 43" },
- { do_bad, SIGBUS, 0, "unknown 44" },
- { do_bad, SIGBUS, 0, "unknown 45" },
- { do_bad, SIGBUS, 0, "unknown 46" },
- { do_bad, SIGBUS, 0, "unknown 47" },
- { do_bad, SIGBUS, 0, "TLB conflict abort" },
- { do_bad, SIGBUS, 0, "Unsupported atomic hardware update fault" },
- { do_bad, SIGBUS, 0, "unknown 50" },
- { do_bad, SIGBUS, 0, "unknown 51" },
- { do_bad, SIGBUS, 0, "implementation fault (lockdown abort)" },
- { do_bad, SIGBUS, 0, "implementation fault (unsupported exclusive)" },
- { do_bad, SIGBUS, 0, "unknown 54" },
- { do_bad, SIGBUS, 0, "unknown 55" },
- { do_bad, SIGBUS, 0, "unknown 56" },
- { do_bad, SIGBUS, 0, "unknown 57" },
- { do_bad, SIGBUS, 0, "unknown 58" },
- { do_bad, SIGBUS, 0, "unknown 59" },
- { do_bad, SIGBUS, 0, "unknown 60" },
- { do_bad, SIGBUS, 0, "section domain fault" },
- { do_bad, SIGBUS, 0, "page domain fault" },
- { do_bad, SIGBUS, 0, "unknown 63" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 34" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 35" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 36" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 37" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 38" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 39" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 40" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 41" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 42" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 43" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 44" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 45" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 46" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 47" },
+ { do_bad, SIGBUS, BUS_FIXME, "TLB conflict abort" },
+ { do_bad, SIGBUS, BUS_FIXME, "Unsupported atomic hardware update fault" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 50" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 51" },
+ { do_bad, SIGBUS, BUS_FIXME, "implementation fault (lockdown abort)" },
+ { do_bad, SIGBUS, BUS_FIXME, "implementation fault (unsupported exclusive)" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 54" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 55" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 56" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 57" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 58" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 59" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 60" },
+ { do_bad, SIGBUS, BUS_FIXME, "section domain fault" },
+ { do_bad, SIGBUS, BUS_FIXME, "page domain fault" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 63" },
};
int handle_guest_sea(phys_addr_t addr, unsigned int esr)
@@ -739,11 +739,11 @@ static struct fault_info __refdata debug_fault_info[] = {
{ do_bad, SIGTRAP, TRAP_HWBKPT, "hardware breakpoint" },
{ do_bad, SIGTRAP, TRAP_HWBKPT, "hardware single-step" },
{ do_bad, SIGTRAP, TRAP_HWBKPT, "hardware watchpoint" },
- { do_bad, SIGBUS, 0, "unknown 3" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 3" },
{ do_bad, SIGTRAP, TRAP_BRKPT, "aarch32 BKPT" },
- { do_bad, SIGTRAP, 0, "aarch32 vector catch" },
+ { do_bad, SIGTRAP, TRAP_FIXME, "aarch32 vector catch" },
{ early_brk64, SIGTRAP, TRAP_BRKPT, "aarch64 BRK" },
- { do_bad, SIGBUS, 0, "unknown 7" },
+ { do_bad, SIGBUS, BUS_FIXME, "unknown 7" },
};
void __init hook_debug_fault_code(int nr,
diff --git a/kernel/signal.c b/kernel/signal.c
index c894162ec96c..fd182a845490 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2711,6 +2711,10 @@ enum siginfo_layout siginfo_layout(int sig, int si_code)
#ifdef FPE_FIXME
if ((sig == SIGFPE) && (si_code == FPE_FIXME))
layout = SIL_FAULT;
+#endif
+#ifdef BUS_FIXME
+ if ((sig == SIGBUS) && (si_code == BUS_FIXME))
+ layout = SIL_FAULT;
#endif
}
return layout;
--
2.14.1
^ permalink raw reply related
* [PATCH 08/11] signal/arm: Document conflicts with SI_USER and SIGFPE
From: Eric W. Biederman @ 2018-01-12 0:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87373b6ghs.fsf@xmission.com>
Setting si_code to 0 results in a userspace seeing an si_code of 0.
This is the same si_code as SI_USER. Posix and common sense requires
that SI_USER not be a signal specific si_code. As such this use of 0
for the si_code is a pretty horribly broken ABI.
Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
value of __SI_KILL and now sees a value of SIL_KILL with the result
that uid and pid fields are copied and which might copying the si_addr
field by accident but certainly not by design. Making this a very
flakey implementation.
Utilizing FPE_FIXME, siginfo_layout will now return SIL_FAULT and the
appropriate fields will be reliably copied.
Possible ABI fixes includee:
- Send the signal without siginfo
- Don't generate a signal
- Possibly assign and use an appropriate si_code
- Don't handle cases which can't happen
Cc: Russell King <rmk@flint.arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Ref: 451436b7bbb2 ("[ARM] Add support code for ARM hardware vector floating point")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
arch/arm/include/uapi/asm/siginfo.h | 13 +++++++++++++
arch/arm/vfp/vfpmodule.c | 2 +-
2 files changed, 14 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/include/uapi/asm/siginfo.h
diff --git a/arch/arm/include/uapi/asm/siginfo.h b/arch/arm/include/uapi/asm/siginfo.h
new file mode 100644
index 000000000000..d0513880be21
--- /dev/null
+++ b/arch/arm/include/uapi/asm/siginfo.h
@@ -0,0 +1,13 @@
+#ifndef __ASM_SIGINFO_H
+#define __ASM_SIGINFO_H
+
+#include <asm-generic/siginfo.h>
+
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+#endif
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index a71a48e71fff..03c6a3c72f9c 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -257,7 +257,7 @@ static void vfp_raise_exceptions(u32 exceptions, u32 inst, u32 fpscr, struct pt_
if (exceptions == VFP_EXCEPTION_ERROR) {
vfp_panic("unhandled bounce", inst);
- vfp_raise_sigfpe(0, regs);
+ vfp_raise_sigfpe(FPE_FIXME, regs);
return;
}
--
2.14.1
^ permalink raw reply related
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