* [PATCH] ACPI: introduce CONFIG_ACPI_REDUCED_HARDWARE_ONLY to enforce this ACPI mode
From: Al Stone @ 2014-01-16 2:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15081767.3kxW799CSQ@wuerfel>
On 01/14/2014 02:26 PM, Arnd Bergmann wrote:
> On Tuesday 14 January 2014 13:37:02 al.stone at linaro.org wrote:
>> +config ACPI_REDUCED_HARDWARE_ONLY
>> + bool "Hardware-reduced ACPI support only"
>> + def_bool n
>> + depends on ACPI && EXPERT
>
> I think this will cause a Kconfig warning if you try to select this
> on ARM64 without turning on EXPERT as well.
>
> It should be ok if you express it as
>
> config ACPI_REDUCED_HARDWARE_ONLY
> bool "Hardware-reduced ACPI support only" if EXPERT
> def_bool n
> depends on ACPI
>
>
> Arnd
>
I am very puzzled. I went back and re-did my configs from
before, tried a few new ones, and tried with both expressions
above, but I could not get a Kconfig warning. Do you have an
example .config that shows the warning?
Thanks.
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Linaro Enterprise Group
al.stone at linaro.org
-----------------------------------
^ permalink raw reply
* [PATCH v3 4/6] arm: add early_ioremap support
From: Mark Salter @ 2014-01-16 2:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D72883.3020500@codeaurora.org>
On Wed, 2014-01-15 at 16:32 -0800, Laura Abbott wrote:
> On 1/9/2014 7:50 PM, Mark Salter wrote:
> ....
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 987a7f5..038fb75 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -36,6 +36,7 @@
> > #include <asm/cpu.h>
> > #include <asm/cputype.h>
> > #include <asm/elf.h>
> > +#include <asm/io.h>
> > #include <asm/procinfo.h>
> > #include <asm/psci.h>
> > #include <asm/sections.h>
> > @@ -887,6 +888,8 @@ void __init setup_arch(char **cmdline_p)
> >
> > parse_early_param();
> >
> > + early_ioremap_init();
> > +
> > sort(&meminfo.bank, meminfo.nr_banks, sizeof(meminfo.bank[0]), meminfo_cmp, NULL);
> >
> > early_paging_init(mdesc, lookup_processor_type(read_cpuid_id()));
>
> Any chance we could do this even earlier, say right after
> setup_processor? It would be nice to be able to do this while FDT
> scanning (I have a use case in mind, potential patches are in the works)
It looks like that would work...
^ permalink raw reply
* [PATCH] mmc: dw_mmc: fix dw_mci_get_cd
From: zhangfei @ 2014-01-16 2:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115162210.GP15937@n2100.arm.linux.org.uk>
On 01/16/2014 12:22 AM, Russell King - ARM Linux wrote:
> Well, having this in the gpio level as well as in subsystems like MMC
> is going to create confusion - and from the results of this patch _IS_
> causing confusion. You've just encouraged one implementation to have
> things setup such that mmc_gpio_get_cd() returns false when a card is
> inserted, rather than it correctly returning true.
>
> The issue here is that we'll potentially now end up with _three_
> inversions. One in the GPIO layers. One in mmc_gpio_get_cd(), and
> another in every driver which uses the GPIO layer inversion. This
> is hardly the right approach as it leads to multiple points where
> confusion about the inverted status can occur.
>
Thanks Russell, make sense.
Double checked with the hardware guy, cd pin is high when card inserted
on the board.
The cd pin is originally connected to vout via a resister, and
internally short to gound, which is broken when card inserted.
Then Optional properties "caps2-mmc-cd-active-high" has to be added.
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+* caps2-mmc-cd-active-high: cd pin is high when card present
@@ -2411,6 +2414,9 @@ static struct dw_mci_board *dw_mci_parse_dt(struct
dw_mci *host)
if (of_find_property(np, "caps2-mmc-hs200-1_2v", NULL))
pdata->caps2 |= MMC_CAP2_HS200_1_2V_SDR;
+ if (of_find_property(np, "caps2-mmc-cd-active-high", NULL))
+ pdata->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
+
Thanks
^ permalink raw reply
* [PATCH 3/3] Binding: atmel-wm8904: add option to choose clock
From: Bo Shen @ 2014-01-16 1:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D6C2A1.4080405@atmel.com>
Hi Nicolas,
On 01/16/2014 01:17 AM, Nicolas Ferre wrote:
> On 14/01/2014 04:25, Bo Shen :
>> Add the option to choose clock output on which pin connect to SSC.
>> Default is on TK pin to SSC, add clk_from_rk_pin option, the clock
>
> Please do not use "_" in DT properties. It is a common pattern to use
> "-" instead.
OK, I will use "-" instead in next version.
>> is on RK pin to SSC.
>>
>> Signed-off-by: Bo Shen <voice.shen@atmel.com>
>> ---
>>
>> Documentation/devicetree/bindings/sound/atmel-wm8904.txt | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
>> index 8bbe50c..68a5c1a 100644
>> --- a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
>> +++ b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
>> @@ -33,6 +33,8 @@ Required properties:
>>
>> Optional properties:
>> - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt
>> + - clk_from_rk_pin: according to hardware design, clk privide on rk pin
>
> typo + more description is needed:
> Please tell that it is a boolean property, that by default it is using
> the TK pin (like in the commit message in fact).
OK, I will add more description for it.
Thanks
> Bye,
>
>> + to ssc device
>>
>> Example:
>> sound {
>>
>
>
Best Regards,
Bo Shen
^ permalink raw reply
* [PATCH v5 2/4] devicetree: bindings: Document Krait CPU/L1 EDAC
From: Stephen Boyd @ 2014-01-16 1:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115165623.GJ14405@codeaurora.org>
On 01/15, Stephen Boyd wrote:
>
> Ah sorry, I forgot to put the compatible property here like in
> the dts change. I'll do that in the next revision. Yes we need a
> compatible property here to match the platform driver.
>
This is the replacement patch
-----8<------
From: Stephen Boyd <sboyd@codeaurora.org>
Subject: [PATCH v9] devicetree: bindings: Document Krait CPU/L1 EDAC
The Krait CPU/L1 error reporting device is made up a per-CPU
interrupt. While we're here, document the next-level-cache
property that's used by the Krait EDAC driver.
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: <devicetree@vger.kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
Documentation/devicetree/bindings/arm/cpus.txt | 58 ++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index 91304353eea4..03a529e791c4 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -62,6 +62,20 @@ nodes to be present and contain the properties described below.
Value type: <u32>
Definition: must be set to 0
+ - compatible
+ Usage: optional
+ Value type: <string>
+ Definition: should be one of the compatible strings listed
+ in the cpu node compatible property. This property
+ shall only be present if all the cpu nodes have the
+ same compatible property.
+
+ - interrupts
+ Usage: required when node contains cpus with compatible
+ string "qcom,krait".
+ Value type: <prop-encoded-array>
+ Definition: L1/CPU error interrupt
+
- cpu node
Description: Describes a CPU in an ARM based system
@@ -191,6 +205,11 @@ nodes to be present and contain the properties described below.
property identifying a 64-bit zero-initialised
memory location.
+ - next-level-cache
+ Usage: optional
+ Value type: <phandle>
+ Definition: phandle pointing to the next level cache
+
Example 1 (dual-cluster big.LITTLE system 32-bit):
cpus {
@@ -382,3 +401,42 @@ cpus {
cpu-release-addr = <0 0x20000000>;
};
};
+
+
+Example 5 (Krait 32-bit system):
+
+cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <1 9 0xf04>;
+ compatible = "qcom,krait";
+
+ cpu at 0 {
+ device_type = "cpu";
+ reg = <0>;
+ next-level-cache = <&L2>;
+ };
+
+ cpu at 1 {
+ device_type = "cpu";
+ reg = <1>;
+ next-level-cache = <&L2>;
+ };
+
+ cpu at 2 {
+ device_type = "cpu";
+ reg = <2>;
+ next-level-cache = <&L2>;
+ };
+
+ cpu at 3 {
+ device_type = "cpu";
+ reg = <3>;
+ next-level-cache = <&L2>;
+ };
+
+ L2: l2-cache {
+ compatible = "cache";
+ interrupts = <0 2 0x4>;
+ };
+};
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH 3/3] Binding: atmel-wm8904: add option to choose clock
From: Bo Shen @ 2014-01-16 1:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115115417.GA9558@ns203013.ovh.net>
Hi J,
On 01/15/2014 07:54 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 11:25 Tue 14 Jan , Bo Shen wrote:
>> Add the option to choose clock output on which pin connect to SSC.
>> Default is on TK pin to SSC, add clk_from_rk_pin option, the clock
>> is on RK pin to SSC.
>>
>> Signed-off-by: Bo Shen <voice.shen@atmel.com>
>> ---
>>
>> Documentation/devicetree/bindings/sound/atmel-wm8904.txt | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
>> index 8bbe50c..68a5c1a 100644
>> --- a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
>> +++ b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
>> @@ -33,6 +33,8 @@ Required properties:
>>
>> Optional properties:
>> - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt
>> + - clk_from_rk_pin: according to hardware design, clk privide on rk pin
> provide
>
> ?? no example?
If this patch set is acceptable. The sama5 audio will use it (I will
send patch after this patch set). Do I still need to put the example in
the binding document?
>> + to ssc device
>>
>> Example:
>> sound {
>> --
>> 1.8.5.2
>>
Best Regards,
Bo Shen
^ permalink raw reply
* [PATCH 2/3] ASoC: atmel_wm8904: make it available to choose clock
From: Bo Shen @ 2014-01-16 1:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140114203650.GX15567@sirena.org.uk>
Hi Mark,
On 01/15/2014 04:36 AM, Mark Brown wrote:
> On Tue, Jan 14, 2014 at 11:25:55AM +0800, Bo Shen wrote:
>> Make it available to choose the clock from TK pin or RK pin. This
>> is hardware design decided.
>
>> --- a/sound/soc/atmel/atmel_wm8904.c
>> +++ b/sound/soc/atmel/atmel_wm8904.c
>> @@ -108,6 +108,7 @@ static int atmel_asoc_wm8904_dt_init(struct platform_device *pdev)
>> struct device_node *codec_np, *cpu_np;
>> struct snd_soc_card *card = &atmel_asoc_wm8904_card;
>> struct snd_soc_dai_link *dailink = &atmel_asoc_wm8904_dailink;
>> + struct atmel_ssc_info *ssc_info;
>> int ret;
>>
>> if (!np) {
>> @@ -115,6 +116,15 @@ static int atmel_asoc_wm8904_dt_init(struct platform_device *pdev)
>> return -EINVAL;
>> }
>>
>> + ssc_info = devm_kzalloc(&pdev->dev, sizeof(*ssc_info), GFP_KERNEL);
>> + if (!ssc_info)
>> + return -ENOMEM;
>> +
>> + ssc_info->clk_from_rk_pin =
>> + of_property_read_bool(np, "clk_from_rk_pin");
>> +
>> + card->drvdata = (void *)ssc_info;
>
> Shouldn't this code be in the DAI driver? Otherwise this series looks
> fine to me, though the DT folks might have something to say I guess.
For audio on Atmel SoC, it depends on three device nodes, one is SSC
node, one is the codec node and the sound node.
The sound node will parse by machine driver, and machine driver is
mainly for hardware connection. As the "clk_from_rk_pin" is decided by
hardware, so, I put it here.
If I move the code to dai driver, it will parse the sound node in dai
driver, I think it will make the code a little bit not explicit. What do
you think?
Best Regards,
Bo Shen
^ permalink raw reply
* [PATCH v5 net-next 1/4] sh_eth: Use bool as return type of sh_eth_is_gether()
From: Simon Horman @ 2014-01-16 1:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389778520.14001.16.camel@joe-AO722>
On Wed, Jan 15, 2014 at 01:35:20AM -0800, Joe Perches wrote:
> On Wed, 2014-01-15 at 15:12 +0900, Simon Horman wrote:
> > Return a boolean and use true and false.
> []
> > diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> []
> > @@ -310,12 +310,12 @@ static const u16 sh_eth_offset_fast_sh3_sh2[SH_ETH_MAX_REGISTER_OFFSET] = {
> > [TSU_ADRL31] = 0x01fc,
> > };
> >
> > -static int sh_eth_is_gether(struct sh_eth_private *mdp)
> > +static bool sh_eth_is_gether(struct sh_eth_private *mdp)
> > {
> > if (mdp->reg_offset == sh_eth_offset_gigabit)
> > - return 1;
> > + return true;
> > else
> > - return 0;
> > + return false;
> > }
>
> Or maybe:
>
> static bool sh_eth_is_gether(struct sh_eth_private *mdp)
> {
> return mdp->reg_offset == sh_eth_offset_gigabit;
> }
Thanks, will do.
^ permalink raw reply
* Deadlock in do_page_fault() on ARM (old kernel)
From: Alan Ott @ 2014-01-16 1:13 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
I have a deadlock that I'm trying to understand. The symptom is multiple
tasks trying to acquire a read lock (down_read()) on mm->mmap_sem in
do_page_fault(). I'll be right up front and say that this is a fairly
old kernel (2.6.37 TI PSP kernel) on a fairly old processor DaVinci 6446.
At the time of the deadlock, sysrq's show-all-tasks shows the following
for three of the tasks which are deadlocked (there are more, but I just
picked the interesting ones; the full output is at [1]):
ui D c0ea8208 0 1405 1293 0x00000000
[<c0ea8208>] (schedule+0x33c/0x3c4) from [<c0eaa3b4>]
(__down_read+0xbc/0xd4)
[<c0eaa3b4>] (__down_read+0xbc/0xd4) from [<c0c0b378>]
(do_page_fault+0x94/0x248)
[<c0c0b378>] (do_page_fault+0x94/0x248) from [<c0c052e0>]
(do_DataAbort+0x34/0x94)
[<c0c052e0>] (do_DataAbort+0x34/0x94) from [<c0c05b0c>]
(__dabt_svc+0x4c/0x60)
Exception stack(0xc048dce8 to 0xc048dd30)
dce0: 400e9a94 c048ddb0 ffffffec 00000000 c048c000
c048dda4
dd00: 400e9a94 00000000 ffffff92 c048c000 00000000 00000001 00000014
c048dd34
dd20: 00000000 c0d1f68c 00000013 ffffffff
[<c0c05b0c>] (__dabt_svc+0x4c/0x60) from [<c0d1f68c>]
(__copy_to_user_std+0xcc/0x3a8)
ui D c0ea8208 0 1406 1293 0x00000000
[<c0ea8208>] (schedule+0x33c/0x3c4) from [<c0eaa3b4>]
(__down_read+0xbc/0xd4)
[<c0eaa3b4>] (__down_read+0xbc/0xd4) from [<c0c0b378>]
(do_page_fault+0x94/0x248)
[<c0c0b378>] (do_page_fault+0x94/0x248) from [<c0c052e0>]
(do_DataAbort+0x34/0x94)
[<c0c052e0>] (do_DataAbort+0x34/0x94) from [<c0c05f0c>]
(ret_from_exception+0x0/0x10)
Exception stack(0xc048ffb0 to 0xc048fff8)
ffa0: 00000060 0000000a 000000a8
0010d000
ffc0: 00c23d80 00c23de8 405af06c 00000000 405af03c 405af074 00000050
000001ff
ffe0: 405ae000 40185748 404f5c4c 404f393c 80000010 ffffffff
ui D c0ea8208 0 1411 1293 0x00000000
[<c0ea8208>] (schedule+0x33c/0x3c4) from [<c0eaa3b4>]
(__down_read+0xbc/0xd4)
[<c0eaa3b4>] (__down_read+0xbc/0xd4) from [<c0c0b378>]
(do_page_fault+0x94/0x248)
[<c0c0b378>] (do_page_fault+0x94/0x248) from [<c0c052e0>]
(do_DataAbort+0x34/0x94)
[<c0c052e0>] (do_DataAbort+0x34/0x94) from [<c0c05f0c>]
(ret_from_exception+0x0/0x10)
Exception stack(0xc053bfb0 to 0xc053bff8)
bfa0: 00000000 00000001 00ba3610
00000000
bfc0: 00000000 00ba3610 00bb6020 00ba3610 40074000 00b91024 415e4930
00000583
bfe0: 00b611a0 415e38e0 4005f3e4 ffff0fc0 60000010 ffffffff
---- [snip] ----
Showing all locks held in the system:
1 lock held by getty/1294:
#0: (&tty->atomic_read_lock){+.+...}, at: [<c0d45bf0>]
n_tty_read+0x21c/0x670
1 lock held by ui/1405:
#0: (&mm->mmap_sem){++++++}, at: [<c0c0b378>] do_page_fault+0x94/0x248
1 lock held by ui/1406:
#0: (&mm->mmap_sem){++++++}, at: [<c0c0b378>] do_page_fault+0x94/0x248
1 lock held by ui/1408:
#0: (&mm->mmap_sem){++++++}, at: [<c0c0b378>] do_page_fault+0x94/0x248
1 lock held by ui/1409:
#0: (&mm->mmap_sem){++++++}, at: [<c0c0b378>] do_page_fault+0x94/0x248
1 lock held by ui/1411:
#0: (&mm->mmap_sem){++++++}, at: [<c0c0b378>] do_page_fault+0x94/0x248
1 lock held by ui/1416:
#0: (&mm->mmap_sem){++++++}, at: [<c0c6e604>] sys_mmap_pgoff+0x70/0xc0
1 lock held by ui/1418:
#0: (&mm->mmap_sem){++++++}, at: [<c0c0b378>] do_page_fault+0x94/0x248
1 lock held by ui/1420:
#0: (&mm->mmap_sem){++++++}, at: [<c0c6e604>] sys_mmap_pgoff+0x70/0xc0
1 lock held by ui/1434:
#0: (&tty->atomic_read_lock){+.+...}, at: [<c0d45bf0>]
n_tty_read+0x21c/0x670
Note that above, do_page_fault() takes out a read lock (down_read()) and
sys_mmap_pgoff() takes out a write lock (down_write()).
I've searched for this kind of problem and found two patches which seem
to be related to this issue[2]. I have applied both with no better results.
So my questions are:
1. Why don't I see a full backtrace beyond the exception stack? It's the
same when dump_stack() is called manually.
2. __copy_to_user_memcpy() takes a read lock (down_read()) on
mm->mmap_sem. While that lock is held, __copy_to_user_memcpy() can
generate a page fault, causing do_page_fault() to get called, which will
also try to get a read lock (down_read()) on mm->mmap_sem. Multiple read
locks can be taken on an rw_semaphore, but deadlock will occur if
another thread tries to get a write lock (down_write()) in between. For
example:
Task 1: Task 2:
down_read(sem)
down_write(sem) <-- Goes to sleep
down_read(sem) <-- Goes to sleep
There is a thread from 2005[3] which seems to discuss the same concept
of recursive rw_semaphores, but for futexes.
Other comments:
1. My analysis of this probably wrong. Otherwise it seems many others
would have the same problem, and they don't seem to. I'm hoping this
email will help to correct my understanding.
2. I looked through the git logs for recent (since 2.6.37 time frame)
and nothing else jumped out@me as being an obvious fix for this
situation.
Thanks for any insight you can give,
Alan.
[1] http://www.signal11.us/~alan/show-all-tasks-deadlock.txt
[2] Some websites/bugtrackers mention this commit with a similar issue,
but I'm not entirely sure how it's related:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8878a539ff19a43cf3729e7562cd528f490246ae
This one seems obviously related, but has no effect on my system:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=435a7ef52db7d86e67a009b36cac1457f8972391
[3] http://thread.gmane.org/gmane.linux.kernel/280900
^ permalink raw reply
* [PATCH v3 7/7] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445
From: Marc C @ 2014-01-16 1:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <61E0E2A7-F7FC-4397-8E92-06CC409912B9@gmail.com>
Hello Arnd,
> And then you can add a regular device driver to drivers/reset that provides a
> device_reset() API to other drivers, or a system-reset function to be registered as
> arm_pm_restart. This driver would use syscon_regmap_lookup_by_phandle() to get access
> to a regmap pointer, and then use either hardcoded offsets into the regmap, or get
> those offsets from numbers in the devicetree, as provided in the example above.
I was able to port a standalone "reboot" driver using syscon + regmap. However, for the
SMP initialization case, it turns out that syscon is configured *after* SMP init. Do you
have any advice for this type of situation?
I'd hate to go around in circles, but without resorting to hard-coded offsets, perhaps I
can just add the remaining "non-regmap" register offsets in the DT?
Thanks,
Marc
On 01/15/2014 10:22 AM, Marc wrote:
> Hi Arnd,
>
> Thank you for the suggestion - it's exactly what we were looking for!
>
> Regards,
> Marc
>
> Sent from my phone
>
>> On Jan 15, 2014, at 5:10 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>>> On Wednesday 15 January 2014, Marc Carino wrote:
>>> + gen-ctrl {
>>> + compatible = "brcm,brcmstb-gen-ctrl-v1";
>>> + reg = <0xf0404304 0x4
>>> + 0xf0404308 0x4
>>> + 0xf03e2578 0x4
>>> + 0xf03e2488 0x10
>>> + 0xf0452000 0x20>;
>>> + };
>>
>> Sorry I didn't get back to you on this when we discussed the previous
>> version. I'm actually less happy with this DT representation than the
>> original. What I take from your description is that you have multiple
>> register ranges that basically combine more-or-less random registers
>> that belong into different Linux subsystems.
>>
>> I think the best way to deal with this is to have the "syscon" driver
>> handle the multiplexing between the various drivers that need access
>> to the registers. It would look something like (taking the numbers
>> from your previous patch):
>>
>> ahb {
>> ranges = <0 0xf0000000 0x1000000>; /* 16 MB remapped registers */
>>
>> hif-cpubuictrl: syscon at 3e2400 {
>> compatible = "brcm,7445-cpubioctrl", "syscon";
>> reg = <0x3e2000, 0x1000>;
>> };
>>
>> hif-continuation: syscon at 45200 {
>> compatible = "brcm,7445-hif-continuation", "syscon";
>> reg = <0x452000, 0x1000>;
>> };
>>
>> sun-top-ctrl: ...
>> };
>>
>> This lets the syscon driver find and map the three register areas.
>> Drivers that need access to the registers then do
>>
>> reset {
>> compatible = "brcm,7445-reset-ctrl";
>> syscon = <&sun-top-ctrl 0x300 0x100>;
>> #reset-cells = <1>;
>> };
>>
>> And then you can add a regular device driver to drivers/reset that provides
>> a device_reset() API to other drivers, or a system-reset function to be
>> registered as arm_pm_restart. This driver would use
>> syscon_regmap_lookup_by_phandle() to get access to a regmap pointer,
>> and then use either hardcoded offsets into the regmap, or get those
>> offsets from numbers in the devicetree, as provided in the example
>> above.
>>
>> Arnd
^ permalink raw reply
* [PATCH] ARM: shmobile: Break out R-Car SYSC PM code
From: Simon Horman @ 2014-01-16 0:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87txd47od8.wl%kuninori.morimoto.gx@gmail.com>
On Wed, Jan 15, 2014 at 04:37:58PM -0800, Kuninori Morimoto wrote:
>
> Hi Magnus, Simon
>
> > >> Break out the R-Car SYSC power management code from
> > >> the r8a7779 SoC code. With this new shared R-Car SYSC
> > >> code base it is possible to hook in Generation 2 SoCs
> > >> as well.
> > >
> > > Is this also useful for the r8a7778 (the other Gen 1 SoC in mainline) ?
> >
> > I don't know actually. =) What does Morimoto-san say about this?
>
> Thank you for this patch.
> it is useful, but, unfortunately r8a7778 (= M1) doesn't have SYSC
Thanks, one less thing to worry about :)
^ permalink raw reply
* [PATCH v4 net-next 2/4] sh_eth: Add support for r7s72100
From: Simon Horman @ 2014-01-16 0:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D70F12.9080800@cogentembedded.com>
On Thu, Jan 16, 2014 at 01:43:30AM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 01/09/2014 08:03 AM, Simon Horman wrote:
>
> >>>This is a fast ethernet controller.
>
> >>>Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> >>[...]
>
> >>>diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> >>>index 4b38533..cc6d4af 100644
> >>>--- a/drivers/net/ethernet/renesas/sh_eth.c
> >>>+++ b/drivers/net/ethernet/renesas/sh_eth.c
> >>>@@ -190,6 +190,59 @@ static const u16 sh_eth_offset_fast_rcar[SH_ETH_MAX_REGISTER_OFFSET] = {
> [...]
> >>>@@ -701,6 +762,35 @@ static struct sh_eth_cpu_data r8a7740_data = {
> >>> .shift_rd0 = 1,
> >>> };
> >>>
> >>>+/* R7S72100 */
> >>>+static struct sh_eth_cpu_data r7s72100_data = {
> >>>+ .chip_reset = sh_eth_chip_reset,
> >>>+ .set_duplex = sh_eth_set_duplex,
> >>>+
> >>>+ .register_type = SH_ETH_REG_FAST_RZ,
> >>>+
> >>>+ .ecsr_value = ECSR_ICD,
> >>>+ .ecsipr_value = ECSIPR_ICDIP,
> >>>+ .eesipr_value = 0xff7f009f,
> >>>+
> >>>+ .tx_check = EESR_TC1 | EESR_FTC,
> >>>+ .eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
> >>>+ EESR_RFE | EESR_RDE | EESR_RFRMER | EESR_TFE |
> >>>+ EESR_TDE | EESR_ECI,
> >>>+ .fdr_value = 0x0000070f,
> >>>+ .rmcr_value = RMCR_RNC,
> >>>+
> >>>+ .apr = 1,
> >>>+ .mpr = 1,
> >>>+ .tpauser = 1,
> >>>+ .hw_swap = 1,
> >>>+ .rpadir = 1,
> >>>+ .rpadir_value = 2 << 16,
> >>>+ .no_trimd = 1,
> >>>+ .tsu = 1,
> >>>+ .shift_rd0 = 1,
>
> >> Perhaps this field should be renamed to something talking about
> >>check summing support (since bits 0..15 of RD0 contain a frame check
> >>sum for those SoCs). Or maybe it should be just merged with the
> >>'hw_crc' field...
>
> >I have no feelings about that one way or another.
>
> Do you happen to have R8A7740 manual by chance? If so, does it
> talk about RX check summing support and using RD0 for that?
Yes and yes.
I have taken a quick look and the documentation for RX checksumming on the
R8A7740 appears to be very similar if not the same as that of the R7S72100.
In particular both refer to using the bottom 16 bits of RD0 as
containing the packet checksum.
> >But it seems to be orthogonal to this patch.
>
> Of course, was a note to self. :-)
>
> [...]
> >>>@@ -880,6 +970,8 @@ static unsigned long sh_eth_get_edtrr_trns(struct sh_eth_private *mdp)
> >>> {
> >>> if (sh_eth_is_gether(mdp))
> >>> return EDTRR_TRNS_GETHER;
> >>>+ else if (sh_eth_is_rz_fast_ether(mdp))
> >>>+ return EDTRR_TRNS_RZ_ETHER;
>
> >> I'd just merge this with the GEther case.
>
> >Sure, but in that case should we change the name.
> >As both you and Magnus pointed out to me, the rz is not gigabit.
>
> See below.
>
> >>> else
> >>> return EDTRR_TRNS_ETHER;
> >>> }
> >>[...]
> >>>@@ -1062,7 +1155,8 @@ static void sh_eth_ring_format(struct net_device *ndev)
> >>> if (i == 0) {
> >>> /* Tx descriptor address set */
> >>> sh_eth_write(ndev, mdp->tx_desc_dma, TDLAR);
> >>>- if (sh_eth_is_gether(mdp))
> >>>+ if (sh_eth_is_gether(mdp) ||
> >>>+ sh_eth_is_rz_fast_ether(mdp))
> >>> sh_eth_write(ndev, mdp->tx_desc_dma, TDFAR);
>
> >> Hmm, TDFAR exists also on SH4 Ethers...
>
> >Lets fix that separately.
>
> Of course, was just another not to self.
>
> [...]
> >>>diff --git a/drivers/net/ethernet/renesas/sh_eth.h b/drivers/net/ethernet/renesas/sh_eth.h
> >>>index 0fe35b7..0bcde90 100644
> >>>--- a/drivers/net/ethernet/renesas/sh_eth.h
> >>>+++ b/drivers/net/ethernet/renesas/sh_eth.h
> [...]
> >>>@@ -191,6 +192,7 @@ enum DMAC_M_BIT {
> >>> /* EDTRR */
> >>> enum DMAC_T_BIT {
> >>> EDTRR_TRNS_GETHER = 0x03,
> >>>+ EDTRR_TRNS_RZ_ETHER = 0x03,
>
> >> I doubt we need a special case here. You didn't introduce one for
> >>the software reset bits.
>
> >True, but RZ is not Gigabit. So I think we either need two names
> >or to choose a more generic name.
>
> Well, R7S72100 manual calls these bits just TR[1:0]. Don't know
> what SoCs having Gigabit call it in the manuals...
>
> >>> EDTRR_TRNS_ETHER = 0x01,
>
> R-Car manuals seem to call the bit TRNS (as well as the
> prehistoric SH manuals probably). Perhaps we could use that
> difference, TRNS vs TR, don't know...
Perhaps we should just leave it as-is, using EDTRR_TRNS_GETHER and
EDTRR_TRNS_RZ_ETHER, after all.
At least until we can think of a better names :)
^ permalink raw reply
* linux-next: manual merge of the libata tree with the arm-soc tree
From: Stephen Rothwell @ 2014-01-16 0:48 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tejun,
Today's linux-next merge of the libata tree got a conflict in
arch/arm/boot/dts/armada-370-xp.dtsi between commit a095b1c78a35 ("ARM:
mvebu: sort DT nodes by address") from the arm-soc tree and commit
a96cc303e42a ("ARM: mvebu: update the SATA compatible string for Armada
370/XP") from the libata tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
diff --cc arch/arm/boot/dts/armada-370-xp.dtsi
index b6b253924893,df141a1d6448..000000000000
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@@ -236,12 -183,13 +236,12 @@@
status = "disabled";
};
- i2c0: i2c at 11000 {
- compatible = "marvell,mv64xxx-i2c";
- #address-cells = <1>;
- #size-cells = <0>;
- interrupts = <31>;
- timeout-ms = <1000>;
- clocks = <&coreclk 0>;
+ sata at a0000 {
- compatible = "marvell,orion-sata";
++ compatible = "marvell,armada-370-sata";
+ reg = <0xa0000 0x5000>;
+ interrupts = <55>;
+ clocks = <&gateclk 15>, <&gateclk 30>;
+ clock-names = "0", "1";
status = "disabled";
};
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140116/c343270b/attachment.sig>
^ permalink raw reply
* [RFC PATCH net-next] etherdevice: Use ether_addr_copy to copy an Ethernet address
From: David Miller @ 2014-01-16 0:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389830878.14001.39.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Wed, 15 Jan 2014 16:07:58 -0800
> If you want the ones for net-next net/ now (but not
> for batman-adv, that maybe could use a new function like
> ether_addr_copy_unaligned) here's a changestat.
>
> Otherwise, I'll wait for the next cycle.
This looks fine, why don't you toss it my way over the weekend as I
still have some backlog to process at the moment?
Thanks.
^ permalink raw reply
* [PATCH] ARM: shmobile: Break out R-Car SYSC PM code
From: Kuninori Morimoto @ 2014-01-16 0:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANqRtoQ8sLLXQWKHaxbFpSb+3oBF2Spn_nUZx91OWsmb_+kMnA@mail.gmail.com>
Hi Magnus, Simon
> >> Break out the R-Car SYSC power management code from
> >> the r8a7779 SoC code. With this new shared R-Car SYSC
> >> code base it is possible to hook in Generation 2 SoCs
> >> as well.
> >
> > Is this also useful for the r8a7778 (the other Gen 1 SoC in mainline) ?
>
> I don't know actually. =) What does Morimoto-san say about this?
Thank you for this patch.
it is useful, but, unfortunately r8a7778 (= M1) doesn't have SYSC
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* [PATCH v3 4/6] arm: add early_ioremap support
From: Russell King - ARM Linux @ 2014-01-16 0:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D72883.3020500@codeaurora.org>
On Wed, Jan 15, 2014 at 04:32:03PM -0800, Laura Abbott wrote:
> Neither x86 nor arm64 get rid of existing mapping in paging_init. Is
> there a reason this needs to be here for arm? Are there concerns about
> alias mappings?
The early mappings we setup in the assembly code are imperfect - they're
an approximation. We map just about enough memory to get the kernel
going, and we setup a mapping for the debug stuff using a section
mapping, which may not be appropriate.
The permissions too are a just chosen to get things going, and the
subsequent replacement of the page table entries is to fix all that up.
We really don't want any old entries left behind.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v3 4/6] arm: add early_ioremap support
From: Laura Abbott @ 2014-01-16 0:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389325833-16535-5-git-send-email-msalter@redhat.com>
On 1/9/2014 7:50 PM, Mark Salter wrote:
....
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 987a7f5..038fb75 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -36,6 +36,7 @@
> #include <asm/cpu.h>
> #include <asm/cputype.h>
> #include <asm/elf.h>
> +#include <asm/io.h>
> #include <asm/procinfo.h>
> #include <asm/psci.h>
> #include <asm/sections.h>
> @@ -887,6 +888,8 @@ void __init setup_arch(char **cmdline_p)
>
> parse_early_param();
>
> + early_ioremap_init();
> +
> sort(&meminfo.bank, meminfo.nr_banks, sizeof(meminfo.bank[0]), meminfo_cmp, NULL);
>
> early_paging_init(mdesc, lookup_processor_type(read_cpuid_id()));
Any chance we could do this even earlier, say right after
setup_processor? It would be nice to be able to do this while FDT
scanning (I have a use case in mind, potential patches are in the works)
<snip>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 580ef2d..bef59b9 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -34,6 +34,7 @@
> #include <asm/mach/arch.h>
> #include <asm/mach/map.h>
> #include <asm/mach/pci.h>
> +#include <asm/early_ioremap.h>
>
> #include "mm.h"
> #include "tcm.h"
> @@ -1405,6 +1406,7 @@ void __init paging_init(const struct machine_desc *mdesc)
> {
> void *zero_page;
>
> + early_ioremap_reset();
> build_mem_type_table();
> prepare_page_table();
> map_lowmem();
>
Neither x86 nor arm64 get rid of existing mapping in paging_init. Is
there a reason this needs to be here for arm? Are there concerns about
alias mappings?
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v5 net-next 2/4] sh_eth: Add support for r7s72100
From: Simon Horman @ 2014-01-16 0:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D70B03.9040506@cogentembedded.com>
On Thu, Jan 16, 2014 at 01:26:11AM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 01/15/2014 09:12 AM, Simon Horman wrote:
>
> >This is a fast ethernet controller.
>
> I have to say it's not exact enough patch description: R7S72100
> is not Ethernet controller itself, it's a SoC containing the
> Ethernet controller.
I will update the text to the following:
The r7s72100 SoC includes a fast ethernet controller.
>
> >Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> >---
> >v5
> >* As suggested by Sergei Shtylyov
> > - Do not use sh_eth_chip_reset_r8a7740 as it accesses non-existent
> > RMII registers. Instead use sh_eth_chip_reset.
> > - Do not use sh_eth_set_rate_gether as it accesses non-existent registers.
> > - Do not use reserved LCHNG bit of ECSR
> > - Do not use reserved LCHNGIP bit of ECSIPR
> > - Document that R8A779x also needs a 16 bit shift of the RFS bits
> > - Do not document that the R7S72100 has GECMR, it does not
>
> The above change list was moved from v2 section and doesn't match
> the real changes done in v5. ;-)
I'll fix that up so that when its automatically discarded by git
it can rest in peace in /dev/null.
>
> >v4
> >* As requested by David Miller
> > - Use a boolean for the return value of sh_eth_is_rz_fast_ether()
> > - Correct coding style in sh_eth_get_stats()
>
> >v3
> >* No change
>
> >v2
> >* As suggested by Magnus Damm and Sergei Shtylyov
> > - r7s72100 ethernet is not gigabit so do not refer to it as such
>
> >* As suggested by Magnus Damm
> > - As RZ specific register layout rather than using the gigabit layout
> > which includes registers that do not exist on this chip.
> >---
> > drivers/net/ethernet/renesas/sh_eth.c | 126 ++++++++++++++++++++++++++++++++--
> > drivers/net/ethernet/renesas/sh_eth.h | 3 +-
> > 2 files changed, 121 insertions(+), 8 deletions(-)
>
> >diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> >index 4f5cfad..a7a0555 100644
> >--- a/drivers/net/ethernet/renesas/sh_eth.c
> >+++ b/drivers/net/ethernet/renesas/sh_eth.c
> >@@ -190,6 +190,64 @@ static const u16 sh_eth_offset_fast_rcar[SH_ETH_MAX_REGISTER_OFFSET] = {
> > [TRIMD] = 0x027c,
> > };
> >
> >+static const u16 sh_eth_offset_fast_rz[SH_ETH_MAX_REGISTER_OFFSET] = {
>
> Shouldn't this map precede R-Car one since this SoC is newer the
> same way you've reordered *enum* values, etc.? Sorry for not
> noticing in the previous review...
I will move it, thanks.
> [...]
> >+ [ARSTR] = 0x0000,
> >+ [TSU_CTRST] = 0x0004,
> >+ [TSU_VTAG0] = 0x0058,
> >+ [TSU_ADSBSY] = 0x0060,
> >+ [TSU_TEN] = 0x0064,
> >+ [TXNLCR0] = 0x0080,
> >+ [TXALCR0] = 0x0084,
> >+ [RXNLCR0] = 0x0088,
> >+ [RXALCR0] = 0x008C,
>
> Well, the above counter register subgroup stands out from the
> TSU_* registers in the Gigabit mapping, not sure if we should follow
> that. These registers are not currently used anyway...
I will add a blank line.
>
> >+ [TSU_ADRH0] = 0x0100,
> >+ [TSU_ADRL0] = 0x0104,
> >+ [TSU_ADRH31] = 0x01f8,
> >+ [TSU_ADRL31] = 0x01fc,
> >+};
> >+
> > static const u16 sh_eth_offset_fast_sh4[SH_ETH_MAX_REGISTER_OFFSET] = {
> > [ECMR] = 0x0100,
> > [RFLR] = 0x0108,
> >@@ -318,6 +376,14 @@ static bool sh_eth_is_gether(struct sh_eth_private *mdp)
> > return false;
> > }
> >
> >+static bool sh_eth_is_rz_fast_ether(struct sh_eth_private *mdp)
> >+{
> >+ if (mdp->reg_offset == sh_eth_offset_fast_rz)
> >+ return true;
> >+ else
> >+ return false;
>
> Perhaps you should compress the above functions to one-liners as
> Joe has suggested. Or I/you could do it in a separate patch...
Will do, Joe's suggestion is a good one.
>
> >+}
> >+
> > static void sh_eth_select_mii(struct net_device *ndev)
> > {
> > u32 value = 0x0;
> [...]
> >@@ -1309,9 +1409,9 @@ static int sh_eth_rx(struct net_device *ndev, u32 intr_status, int *quota)
> >
> > /* In case of almost all GETHER/ETHERs, the Receive Frame State
> > * (RFS) bits in the Receive Descriptor 0 are from bit 9 to
> >- * bit 0. However, in case of the R8A7740's GETHER, the RFS
> >- * bits are from bit 25 to bit 16. So, the driver needs right
> >- * shifting by 16.
> >+ * bit 0. However, in case of the R8A7740, R8A779x and
>
> Small nit: comma needed before "and" as far as I know English grammar.
To be honest I don't think it is. But I'll add one for you.
>
> >+ * R7S72100 the RFS bits are from bit 25 to bit 16. So, the
> >+ * driver needs right shifting by 16.
> > */
> > if (mdp->cd->shift_rd0)
> > desc_status >>= 16;
>
> Other than that, this looks fine now, you can add my:
>
> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Thanks.
^ permalink raw reply
* [PATCH v7 2/2] ehci-platform: Add support for clks and phy passed through devicetree
From: Florian Fainelli @ 2014-01-16 0:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389813883-567-3-git-send-email-hdegoede@redhat.com>
2014/1/15 Hans de Goede <hdegoede@redhat.com>:
> Currently ehci-platform is only used in combination with devicetree when used
> with some Via socs. By extending it to (optionally) get clks and a phy from
> devicetree, and enabling / disabling those on power_on / off, it can be used
> more generically. Specifically after this commit it can be used for the
> ehci controller on Allwinner sunxi SoCs.
>
> Since ehci-platform is intended to handle any generic enough non pci ehci
> device, add a "usb-ehci" compatibility string.
>
> There already is a usb-ehci device-tree bindings document, update this
> with clks and phy bindings info.
>
> Although actually quite generic so far the via,vt8500 compatibilty string
> had its own bindings document. Somehow we even ended up with 2 of them. Since
> these provide no extra information over the generic usb-ehci documentation,
> this patch removes them.
>
> The ehci-ppc-of.c driver also claims the usb-ehci compatibility string,
> even though it mostly is ibm,usb-ehci-440epx specific. ehci-platform.c is
> not needed on ppc platforms, so add a !PPC_OF dependency to it to avoid
> 2 drivers claiming the same compatibility string getting build on ppc.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> Acked-by: Alan Stern <stern@rowland.harvard.edu>
> ---
> Documentation/devicetree/bindings/usb/usb-ehci.txt | 25 +++-
> .../devicetree/bindings/usb/via,vt8500-ehci.txt | 15 ---
> .../devicetree/bindings/usb/vt8500-ehci.txt | 12 --
> drivers/usb/host/Kconfig | 1 +
> drivers/usb/host/ehci-platform.c | 149 +++++++++++++++++----
> 5 files changed, 142 insertions(+), 60 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
> delete mode 100644 Documentation/devicetree/bindings/usb/vt8500-ehci.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt
> index fa18612..fad10f3 100644
> --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
> @@ -7,13 +7,14 @@ Required properties:
> (debug-port or other) can be also specified here, but only after
> definition of standard EHCI registers.
> - interrupts : one EHCI interrupt should be described here.
> -If device registers are implemented in big endian mode, the device
> -node should have "big-endian-regs" property.
> -If controller implementation operates with big endian descriptors,
> -"big-endian-desc" property should be specified.
> -If both big endian registers and descriptors are used by the controller
> -implementation, "big-endian" property can be specified instead of having
> -both "big-endian-regs" and "big-endian-desc".
> +
> +Optional properties:
> + - big-endian-regs : boolean, set this for hcds with big-endian registers
> + - big-endian-desc : boolean, set this for hcds with big-endian descriptors
> + - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc
These properties are specified here in the documentation binding, but
they are not handled by the ehci-platform driver, is that intentional?
Fairly quickly people will start adopting the ehci-platform driver on
DT-aware platforms, so it would be nice to support those 2 (3)
properties right away?
--
Florian
^ permalink raw reply
* [RFC PATCH net-next] etherdevice: Use ether_addr_copy to copy an Ethernet address
From: Joe Perches @ 2014-01-16 0:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115.153951.743060257410154565.davem@davemloft.net>
On Wed, 2014-01-15 at 15:39 -0800, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Tue, 14 Jan 2014 15:18:47 -0800
>
> > Some systems can use the normally known u16 alignment of
> > Ethernet addresses to save some code/text bytes and cycles.
> >
> > This does not change currently emitted code on x86 by gcc 4.8.
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
>
> This looks fine, in fact I'll apply it.
OK, good.
There are a couple thousand memcpy(foo, bar, ETH_ALEN)
in the kernel tree that could be converted.
Some will have a small performance improvement for
arm and powerpc.
If you want the ones for net-next net/ now (but not
for batman-adv, that maybe could use a new function like
ether_addr_copy_unaligned) here's a changestat.
Otherwise, I'll wait for the next cycle.
(done via coccinelle)
net/8021q/vlan.c | 2 +-
net/8021q/vlan_dev.c | 6 ++--
net/appletalk/aarp.c | 10 +++---
net/atm/lec.c | 9 ++---
net/atm/mpc.c | 2 +-
net/bluetooth/bnep/core.c | 19 +++++-----
net/bluetooth/bnep/netdev.c | 14 ++++----
net/bridge/br_device.c | 4 +--
net/bridge/br_fdb.c | 4 +--
net/bridge/br_multicast.c | 4 +--
net/bridge/br_netfilter.c | 2 +-
net/bridge/br_stp_if.c | 10 +++---
net/bridge/netfilter/ebt_among.c | 2 +-
net/bridge/netfilter/ebt_dnat.c | 2 +-
net/bridge/netfilter/ebt_redirect.c | 6 ++--
net/bridge/netfilter/ebt_snat.c | 2 +-
net/caif/caif_usb.c | 4 +--
net/core/netpoll.c | 4 +--
net/core/pktgen.c | 8 ++---
net/decnet/dn_dev.c | 2 +-
net/decnet/dn_neigh.c | 6 ++--
net/decnet/dn_route.c | 6 ++--
net/dsa/slave.c | 2 +-
net/ethernet/eth.c | 18 +++++-----
net/hsr/hsr_device.c | 8 ++---
net/hsr/hsr_framereg.c | 21 +++++------
net/hsr/hsr_main.c | 4 +--
net/ipv4/netfilter/ipt_CLUSTERIP.c | 2 +-
net/mac80211/agg-rx.c | 10 +++---
net/mac80211/agg-tx.c | 18 +++++-----
net/mac80211/cfg.c | 34 +++++++++---------
net/mac80211/debugfs_netdev.c | 12 +++----
net/mac80211/ht.c | 16 ++++-----
net/mac80211/ibss.c | 14 ++++----
net/mac80211/iface.c | 27 +++++++-------
net/mac80211/mesh.c | 30 ++++++++--------
net/mac80211/mesh_hwmp.c | 32 ++++++++---------
net/mac80211/mesh_pathtbl.c | 20 +++++------
net/mac80211/mesh_plink.c | 6 ++--
net/mac80211/mesh_ps.c | 2 +-
net/mac80211/mlme.c | 32 ++++++++---------
net/mac80211/rx.c | 14 ++++----
net/mac80211/spectmgmt.c | 6 ++--
net/mac80211/sta_info.c | 8 ++---
net/mac80211/tx.c | 60 +++++++++++++++----------------
net/mac80211/util.c | 22 ++++++------
net/mac80211/wpa.c | 4 +--
net/netfilter/ipset/ip_set_bitmap_ipmac.c | 6 ++--
net/openvswitch/actions.c | 4 +--
net/openvswitch/flow.c | 16 ++++-----
net/openvswitch/flow_netlink.c | 14 ++++----
net/tipc/eth_media.c | 2 +-
net/wireless/core.c | 2 +-
net/wireless/ibss.c | 11 +++---
net/wireless/lib80211_crypt_ccmp.c | 4 +--
net/wireless/lib80211_crypt_tkip.c | 18 +++++-----
net/wireless/mlme.c | 2 +-
net/wireless/nl80211.c | 6 ++--
net/wireless/scan.c | 6 ++--
net/wireless/sme.c | 18 +++++-----
net/wireless/util.c | 42 +++++++++++-----------
net/wireless/wext-compat.c | 8 ++---
net/wireless/wext-sme.c | 5 +--
net/wireless/wext-spy.c | 8 ++---
64 files changed, 365 insertions(+), 357 deletions(-)
^ permalink raw reply
* [PATCH v9 2/4] Documentation: Add documentation for APM X-Gene SoC SATA host controller DTS binding
From: Loc Ho @ 2014-01-15 23:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPw-ZTmn-aNJcLd1mZPRtog_ncq=GC94ULCJb-400oYqERYK5g@mail.gmail.com>
Hi,
>>> >> >> +- clocks : Reference to the clock entry.
>>> >> >> +- phys : PHY reference with parameter 0.
>>> >> >
>>> >> > The specific value of the phy-specifier shouldn't matter to this
>>> >> > binding. What should matter is what it logically corresponds to.
>>> >>
>>> >> I not quite following this. Are you suggest that I drop the value 0.
>>> >> In the binding, one needs to specify the mode of operation - 0 is for
>>> >> SATA. Can you explain more?
>>> >
>>> > The SATA device should not care what the argument for the PHY
>>> > device is. You could connect the same device to another PHY
>>> > that has a different set of arguments, which is the whole point
>>> > of abstracting it.
>>> >
>>>
>>> I understand what you wrote here. We should not have an argument from
>>> the host controller. Then my question is how should the PHY node
>>> indicates that it needs to be configured itself as an SATA PHY?
>>
>> The "phys" property should specify whatever the configuration of
>> the phy device is supposed to be. It's just not the business of
>> the sata driver or the sata binding to know what that configuration
>> is.
>>
>
> Here is what I have and I am trying to piece this together:
>
> phy1 {
> #phy-cells = <0>; /* No parameter as suggest by Mark */
> };
>
> sata1 {
> :::
> phys = <&phy1>;
> };
>
> What I don't get is how does one specify the mode
> (SATA/USB/SGMII/etc)? As another parameter in the phy1 node?
>
May be I misread what Mark mentioned. The binding documentation should
not specify the requirement of 0. And the binding of the dts should be
as is:
phy1 {
#phy-cells = <1>;
};
sata1 {
:::
phys = <&phy1 0>; where 0 indicates the mode of operation?
};
-Loc
^ permalink raw reply
* [PATCHv4 6/7] hwspinlock/omap: enable module before reading SYSSTATUS register
From: Anna, Suman @ 2014-01-15 23:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D56C3A.7000704@ti.com>
Felipe,
>
> On 01/14/2014 08:04 AM, Felipe Balbi wrote:
>> Hi again,
>>
>> On Tue, Jan 14, 2014 at 07:10:52AM -0600, Felipe Balbi wrote:
>>>> diff --git a/drivers/hwspinlock/omap_hwspinlock.c
>>>> b/drivers/hwspinlock/omap_hwspinlock.c
>>>> index 9f56fb2..194886e 100644
>>>> --- a/drivers/hwspinlock/omap_hwspinlock.c
>>>> +++ b/drivers/hwspinlock/omap_hwspinlock.c
>>>> @@ -101,10 +101,23 @@ static int omap_hwspinlock_probe(struct
>>>> platform_device *pdev)
>>>> if (!io_base)
>>>> return -ENOMEM;
>>>>
>>>> + /*
>>>> + * make sure the module is enabled and clocked before reading
>>>> + * the module SYSSTATUS register
>>>> + */
>>>> + pm_runtime_enable(&pdev->dev);
>>>> + pm_runtime_get_sync(&pdev->dev);
>>
>> another thing, you need to check return of pm_runtime_get_sync()
>
> OK, let me check this and your other comment, and the fix is probably a
> separate patch.
>
I realized the changes relevant to your comments were introduced in this
patch, so just refreshed the patch with fixes instead of doing a
separate patch. I didn't do a v5 just for these change, and will do so
if there are more comments on the DT adaptation.
regards
Suman
^ permalink raw reply
* [Intel-gfx] [PATCH 1/2] drm: share drm_add_fake_info_node
From: Daniel Vetter @ 2014-01-15 23:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115200819.GB1210@bwidawsk.net>
On Wed, Jan 15, 2014 at 12:08:19PM -0800, Ben Widawsky wrote:
> On Wed, Jan 15, 2014 at 09:45:28AM +0100, Daniel Vetter wrote:
> > On Wed, Jan 15, 2014 at 9:39 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > > On Wed, Jan 15, 2014 at 12:40 AM, Russell King - ARM Linux
> > > <linux@arm.linux.org.uk> wrote:
> > >> On Wed, Jan 15, 2014 at 12:25:10AM +0100, Daniel Vetter wrote:
> > >>> On Tue, Jan 14, 2014 at 06:14:06AM -0800, Ben Widawsky wrote:
> > >>> > Both i915 and Armada had the exact same implementation. For an upcoming
> > >>> > patch, I'd like to call this function from two different source files in
> > >>> > i915, and having it available externally helps there too.
> > >>> >
> > >>> > While moving, add 'debugfs_' to the name in order to match the other drm
> > >>> > debugfs helper functions.
> > >>> >
> > >>> > Cc: linux-arm-kernel at lists.infradead.org
> > >>> > Cc: intel-gfx at lists.freedesktop.org
> > >>> > Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> > >>>
> > >>> drm_debugfs_create_files in drm_debugfs.c has the almost same code again.
> > >>> Now the problem here is that the interface is a bit botched up, since all
> > >>> the users in i915 and armada actaully faile to clean up teh debugfs dentry
> > >>> if drm_add_fake_info_node.
> > >>
> > >> That's not correct - armada does clean up these, I think you need to
> > >> take a closer look at the code.
> > >>
> > >> We do this by setting node->info_ent to the file operations structure,
> > >> which is a unique key to the file being registered.
> > >>
> > >> Upon failure to create the fake node, we appropriately call
> > >> drm_debugfs_remove_files() with the first argument being a pointer to
> > >> the file operations. This causes drm_debugfs_remove_files() to match
> > >> the fake entry, call debugfs_remove() on the dentry, and remove the
> > >> node from the list, and free the node structure we allocated.
> > >>
> > >> Upon driver teardown, we also call drm_debugfs_remove_files() but with
> > >> each fops which should be registered, thus cleaning up each fake node
> > >> which was created.
> > >>
> > >> So, Armada does clean up these entries properly.
> > >
> > > Indeed I've missed that and it's just i915 that botches this. I still
> > > think the helper would be saner if it cleans up all its leftovers in
> > > the failure case.
> >
> > Ok, now I've actually page all the stuff back in - if
> > drm_add_fake_info_node fails we don't set up a drm_info_node structure
> > and link it anywhere. Which means drm_debugfs_remove_files won't ever
> > find it and hence can't possibly call debugfs_remove. Which means the
> > debugfs dentry is leaked. So I think the semantics of that new debugfs
> > helper should get fixed to also allocate and clean up the debugfs
> > node.
> >
> > I agree that i915 is even worse since it doesn't bother to clean up
> > any debugfs files at all in the failure case.
> > -Daniel
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
> Perhaps I don't understand what you want here. The only failure path in
> the fake entry creation does already call debugfs_remove.
>
> if (node == NULL) {
> debugfs_remove(ent);
> return -ENOMEM;
> }
>
> So long as the function succeeds, the node will be findable and removable.
Oh dear, I didn't see that. Still stand by my opinion though that we
should shovel the debugfs_create_file into the helper - callers allocating
something and then the helper freeing it (but only if it fails) is rather
funky semantics.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH net-next 0/2] net: mvneta: simple cleanups
From: David Miller @ 2014-01-15 23:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1389742334.git.arno@natisbad.org>
From: Arnaud Ebalard <arno@natisbad.org>
Date: Wed, 15 Jan 2014 00:45:31 +0100
>
> Those two patches are intended for net-next. They apply on top of
> performance improvements patches from Willy for mvneta driver.
> They provide some simple cleanups for unused variables, function
> params or return values.
>
> Arnaud Ebalard (2):
> net: mvneta: mvneta_tx_done_gbe() cleanups
> net: mvneta: make mvneta_txq_done() return void
These patches do not apply to net-next, please respin.
Thanks.
^ permalink raw reply
* [UPDATED PATCHv4 6/7] hwspinlock/omap: enable module before reading SYSSTATUS register
From: Suman Anna @ 2014-01-15 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389658764-39199-7-git-send-email-s-anna@ti.com>
The number of hwspinlocks are determined based on the value read
from the IP block's SYSSTATUS register. However, the module may
not be enabled and clocked, and the read may result in a bus error.
This particular issue is seen rather easily on AM33XX, since the
module wakeup is software controlled, and it is disabled out of
reset. Make sure the module is enabled and clocked before reading
the SYSSTATUS register.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
drivers/hwspinlock/omap_hwspinlock.c | 27 ++++++++++++++++++++-------
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c
index 9f56fb2..7764291 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -101,10 +101,29 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
if (!io_base)
return -ENOMEM;
+ /*
+ * make sure the module is enabled and clocked before reading
+ * the module SYSSTATUS register
+ */
+ pm_runtime_enable(&pdev->dev);
+ ret = pm_runtime_get_sync(&pdev->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(&pdev->dev);
+ goto iounmap_base;
+ }
+
/* Determine number of locks */
i = readl(io_base + SYSSTATUS_OFFSET);
i >>= SPINLOCK_NUMLOCKS_BIT_OFFSET;
+ /*
+ * runtime PM will make sure the clock of this module is
+ * enabled again iff at least one lock is requested
+ */
+ ret = pm_runtime_put_sync(&pdev->dev);
+ if (ret < 0)
+ goto iounmap_base;
+
/* one of the four lsb's must be set, and nothing else */
if (hweight_long(i & 0xf) != 1 || i > 8) {
ret = -EINVAL;
@@ -124,12 +143,6 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
for (i = 0, hwlock = &bank->lock[0]; i < num_locks; i++, hwlock++)
hwlock->priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
- /*
- * runtime PM will make sure the clock of this module is
- * enabled iff at least one lock is requested
- */
- pm_runtime_enable(&pdev->dev);
-
ret = hwspin_lock_register(bank, &pdev->dev, &omap_hwspinlock_ops,
base_id, num_locks);
if (ret)
@@ -138,9 +151,9 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
return 0;
reg_fail:
- pm_runtime_disable(&pdev->dev);
kfree(bank);
iounmap_base:
+ pm_runtime_disable(&pdev->dev);
iounmap(io_base);
return ret;
}
--
1.8.4.3
^ 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