* [PATCH net-next v4 05/10] drivers: base: Add device_find_in_class_name()
From: Andy Shevchenko @ 2017-01-17 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117232152.1661-6-f.fainelli@gmail.com>
On Wed, Jan 18, 2017 at 1:21 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Add a helper function to lookup a device reference given a class name.
> This is a preliminary patch to remove adhoc code from net/dsa/dsa.c and
> make it more generic.
> +static int device_class_name_match(struct device *dev, void *class)
And why not const char *class?
> +{
> + if (dev->class != NULL && !strcmp(dev->class->name, class))
if (dev->class && ...)
> + return 1;
> +
> + return 0;
Perhaps even one line:
return dev->class && ...;
> +}
> +
> +/**
> + * device_find_in_class_name - device iterator for locating a particular device
> + * within the specified class name
> + * @parent: parent struct device
> + * @class_name: Class name to match against
> + *
> + * This function returns 1 if the device (specified by @parent), or one of its child
> + * is in the class whose name is specified by @class_name. Returns 0 otherwise.
> + *
> + * NOTE: you will need to drop the reference with put_device() after use.
> + */
> +struct device *device_find_in_class_name(struct device *parent,
> + char *class_name)
const char *class_name
> +{
> + if (device_class_name_match(parent, class_name)) {
> + get_device(parent);
> + return parent;
> + }
> +
> + return device_find_child(parent, class_name, device_class_name_match);
> +}
> +EXPORT_SYMBOL_GPL(device_find_in_class_name);
> +extern struct device *device_find_in_class_name(struct device *parent,
> + char *class_name);
Ditto.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* CONFIG_PCIEASPM breaks PCIe on Marvell Armada 385 machine
From: David Daney @ 2017-01-17 23:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117222229.GA6534@bhelgaas-glaptop.roam.corp.google.com>
On 01/17/2017 02:22 PM, Bjorn Helgaas wrote:
> [+cc David]
>
> On Tue, Jan 17, 2017 at 09:02:58PM +0000, Russell King - ARM Linux wrote:
>> On Tue, Jan 17, 2017 at 07:34:14PM +0000, Russell King - ARM Linux wrote:
>>> Uwe, can you try:
>>>
>>> setpci -s <whatever-the-id-of-the-root-is-it's-blanked-out-in-the-above> \
>>> 0x50.w=0x60
>>>
>>> and see whether it remains alive (you can check by reading the root
>>> register 0x52.w - bit 12 should be set once bit 11 clears again.
>>
>> For reference, this I got wrong...
>>
>> 0xf1041a04 bit 0 indicates link status (0 = link up, 1 = link down).
>>
>>> If that's successful, maybe setting the common clock bit on the PCIe
>>> device is what's causing the problem, in which case:
>>>
>>> setpci -s 02:00.0 0x80.w=0x40
>>> setpci -s <whatever-the-id-of-the-root-is-it's-blanked-out-in-the-above> \
>>> 0x50.w=0x60
>>
>> Having worked with Uwe over IRC, it seems that any request to retrain
>> causes the link to go down, either with or without the common clock bit
>> set:
>>
>> # setpci -s 2.0 0x50.w=0x60
>> # setpci -s 2.0 0x52.w
>> 0011
>> # memtool md 0xf1041a04+4
>> f1041a04: 00010201
>> ... reboot ...
>> # setpci -s 2.0 0x50.w=0x20
>> # memtool md 0xf1041a04+4
>> f1041a04: 00010201
>>
>> which doesn't point towards ASPM itself, but the problem is caused by
>> a side effect of ASPM's setup code which always triggers a retrain.
>>
>> Bit 5 in that register is documented (at least in the Armada 370 docs
>> and Armada XP docs I have) as:
>>
>> 5 RetrnLnk RW Retrain Link
>> 0x0 This bit forces the device to initiate link retraining.
>> Always returns 0 when read.
>> NOTE: If configured as an Endpoint, this field is
>> reserved and has no effect.
>>
>> Bjorn, are you aware of similar situations where a request for the PCIe
>> link to be retrained causes it to fail?
Link (re)training can fail for several reasons including, but not
limited to:
- Poor signal propagation through the chips/packages/boards/connectors,
also known as Signal Integrity (SI) problmes.
- Incorrect implementation, in hardware, of link training protocols at
either end of the link
Usually, system and PCIe device vendors do a lot of testing and signal
analysis across a variety of configurations with the end goal being that
PCIe looks like a bullet-proof interconnect to the end consumer.
Unfortunatly, sometimes it doesn't work. In these cases, the vendors of
the devices on each end of the link tend to point fingers at the link
partner for being detective in some way.
This patch:
>
> The only one that comes to mind is this patch from David (CC'd) that
> avoids ASPM-related retrains when we know the link doesn't support ASPM:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e53f9a28bee3
>
Is an attempt to work around the problem from the system (host) end. If
the system vendor knows a priori that a defective PCIe device is present
in the system, the PCIe root port can be configured to indicate no ASPM
is supported, resulting (with the patch) in no link retraining being
attempted.
To me it feels that we need a black list of devices that fail at a high
rate in the link retraining, that when encountered would disable ASPM on
the link where they reside.
Just my $0.02
David Daney
> Side note: it looks like we don't use the recommended retrain
> algorithm in the implementation note about avoiding race conditions in
> PCIe r3.0, sec 7.8.7.
>
^ permalink raw reply
* [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains
From: Rob Herring @ 2017-01-17 23:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4cb25cf9-216f-2e18-f45d-ef7e48fa6c5e@ti.com>
On Tue, Jan 17, 2017 at 1:48 AM, Tero Kristo <t-kristo@ti.com> wrote:
> On 17/01/17 00:12, Dave Gerlach wrote:
>>
>> On 01/13/2017 08:40 PM, Rob Herring wrote:
>>>
>>> On Fri, Jan 13, 2017 at 2:28 PM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>>>
>>>> On 01/13/2017 01:25 PM, Rob Herring wrote:
>>>>>
>>>>>
>>>>> On Thu, Jan 12, 2017 at 9:27 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>>>>>
>>>>>>
>>>>>> Rob,
>>>>>>
>>>>>> On 01/11/2017 03:34 PM, Rob Herring wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jan 9, 2017 at 11:57 AM, Dave Gerlach <d-gerlach@ti.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Rob,
>>>>>>>>
>>>>>>>> On 01/09/2017 11:50 AM, Rob Herring wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>>>>>>>> will hook into the genpd framework and allow the TI SCI
>>>>>>>>>> protocol to
>>>>>>>>>> control device power states.
>>>>>>>>>>
>>>>>>>>>> Also, provide macros representing each device index as understood
>>>>>>>>>> by TI SCI to be used in the device node power-domain references.
>>>>>>>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>>>>>>>> ---
>>>>>>>>>> v2->v3:
>>>>>>>>>> Update k2g_pds node docs to show it should be a child
>>>>>>>>>> of pmmc
>>>>>>>>>> node.
>>>>>>>>>> In early versions a phandle was used to point to pmmc and
>>>>>>>>>> docs
>>>>>>>>>> still
>>>>>>>>>> incorrectly showed this.
>>>>>>>>>>
>>>>>>>>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 59
>>>>>>>>>> ++++++++++++++
>>>>>>>>>> MAINTAINERS | 2 +
>>>>>>>>>> include/dt-bindings/genpd/k2g.h | 90
>>>>>>>>>> ++++++++++++++++++++++
>>>>>>>>>> 3 files changed, 151 insertions(+)
>>>>>>>>>> create mode 100644
>>>>>>>>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>>>>>>>
>>>>>>>>>> diff --git
>>>>>>>>>> a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>>>> new file mode 100644
>>>>>>>>>> index 000000000000..4c9064e512cb
>>>>>>>>>> --- /dev/null
>>>>>>>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>>>> @@ -0,0 +1,59 @@
>>>>>>>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>>>>>>>> +---------------------------------------------
>>>>>>>>>> +
>>>>>>>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...)
>>>>>>>>>> that
>>>>>>>>>> is
>>>>>>>>>> +responsible for controlling the state of the IPs that are
>>>>>>>>>> present.
>>>>>>>>>> +Communication between the host processor running an OS and the
>>>>>>>>>> system
>>>>>>>>>> +controller happens through a protocol known as TI-SCI [1].
>>>>>>>>>> This pm
>>>>>>>>>> domain
>>>>>>>>>> +implementation plugs into the generic pm domain framework and
>>>>>>>>>> makes
>>>>>>>>>> use
>>>>>>>>>> of
>>>>>>>>>> +the TI SCI protocol power on and off each device when needed.
>>>>>>>>>> +
>>>>>>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>>>>>>> +
>>>>>>>>>> +PM Domain Node
>>>>>>>>>> +==============
>>>>>>>>>> +The PM domain node represents the global PM domain managed by the
>>>>>>>>>> PMMC,
>>>>>>>>>> +which in this case is the single implementation as documented
>>>>>>>>>> by the
>>>>>>>>>> generic
>>>>>>>>>> +PM domain bindings in
>>>>>>>>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>>>>>>>>> +Because this relies on the TI SCI protocol to communicate with
>>>>>>>>>> the
>>>>>>>>>> PMMC
>>>>>>>>>> it
>>>>>>>>>> +must be a child of the pmmc node.
>>>>>>>>>> +
>>>>>>>>>> +Required Properties:
>>>>>>>>>> +--------------------
>>>>>>>>>> +- compatible: should be "ti,sci-pm-domain"
>>>>>>>>>> +- #power-domain-cells: Must be 0.
>>>>>>>>>> +
>>>>>>>>>> +Example (K2G):
>>>>>>>>>> +-------------
>>>>>>>>>> + pmmc: pmmc {
>>>>>>>>>> + compatible = "ti,k2g-sci";
>>>>>>>>>> + ...
>>>>>>>>>> +
>>>>>>>>>> + k2g_pds: k2g_pds {
>>>>>>>>>> + compatible = "ti,sci-pm-domain";
>>>>>>>>>> + #power-domain-cells = <0>;
>>>>>>>>>> + };
>>>>>>>>>> + };
>>>>>>>>>> +
>>>>>>>>>> +PM Domain Consumers
>>>>>>>>>> +===================
>>>>>>>>>> +Hardware blocks that require SCI control over their state must
>>>>>>>>>> provide
>>>>>>>>>> +a reference to the sci-pm-domain they are part of and a unique
>>>>>>>>>> device
>>>>>>>>>> +specific ID that identifies the device.
>>>>>>>>>> +
>>>>>>>>>> +Required Properties:
>>>>>>>>>> +--------------------
>>>>>>>>>> +- power-domains: phandle pointing to the corresponding PM domain
>>>>>>>>>> node.
>>>>>>>>>> +- ti,sci-id: index representing the device id to be passed
>>>>>>>>>> oevr SCI
>>>>>>>>>> to
>>>>>>>>>> + be used for device control.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As I've already stated before, this goes in power-domain cells.
>>>>>>>>> When
>>>>>>>>> you
>>>>>>>>> have a single thing (i.e. node) that controls multiple things, then
>>>>>>>>> you
>>>>>>>>> you need to specify the ID for each of them in phandle args.
>>>>>>>>> This is
>>>>>>>>> how
>>>>>>>>> irqs, gpio, clocks, *everything* in DT works.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> You think the reasoning for doing it this way provided by both
>>>>>>>> Ulf and
>>>>>>>> myself on v2 [1] is not valid then?
>>>>>>>>
>>>>>>>> From Ulf:
>>>>>>>>
>>>>>>>> To me, the TI SCI ID, is similar to a "conid" for any another
>>>>>>>> "device
>>>>>>>> resource" (like clock, pinctrl, regulator etc) which we can describe
>>>>>>>> in DT and assign to a device node. The only difference here, is that
>>>>>>>> we don't have common API to fetch the resource (like clk_get(),
>>>>>>>> regulator_get()), but instead we fetches the device's resource from
>>>>>>>> SoC specific code, via genpd's device ->attach() callback.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sorry, but that sounds like a kernel problem to me and has nothing to
>>>>>>> do with DT bindings.
>>>>>>>
>>>>>>>> From me:
>>>>>>>>
>>>>>>>> Yes, you've pretty much hit it on the head. It is not an index
>>>>>>>> into a
>>>>>>>> list
>>>>>>>> of genpds but rather identifies the device *within* a single
>>>>>>>> genpd. It
>>>>>>>> is
>>>>>>>> a
>>>>>>>> property specific to each device that resides in a ti-sci-genpd,
>>>>>>>> not a
>>>>>>>> mapping describing which genpd the device belongs to. The generic
>>>>>>>> power
>>>>>>>> domain binding is concerned with mapping the device to a specific
>>>>>>>> genpd,
>>>>>>>> which is does fine for us, but we have a sub mapping for devices
>>>>>>>> that
>>>>>>>> exist
>>>>>>>> inside a genpd which, we must describe as well, hence the ti,sci-id.
>>>>>>>>
>>>>>>>>
>>>>>>>> So to summarize, the genpd framework does interpret the phandle
>>>>>>>> arg as
>>>>>>>> an
>>>>>>>> index into multiple genpds, just as you've said other frameworks do,
>>>>>>>> but
>>>>>>>> this is not what I am trying to do, we have multiple devices within
>>>>>>>> this
>>>>>>>> *single* genpd, hence the need for the ti,sci-id property.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Fix the genpd framework rather than work around it in DT.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I still disagree that this has nothing to do with DT bindings, as the
>>>>>> current DT binding represents something different already. I am
>>>>>> trying to
>>>>>> extend it to give me additional information needed for our
>>>>>> platforms. Are
>>>>>> you saying that we should break what the current DT binding already
>>>>>> represents to mean something else?
>>>>>
>>>>>
>>>>>
>>>>> No idea because what's the current binding? From the patch, looks like
>>>>> a new binding to me.
>>>>
>>>>
>>>>
>>>> Yes, ti,sci-id is a new binding. I am referring to the current
>>>> meaning of
>>>> the "power-domains" binding, which is where you are asking this
>>>> property to
>>>> be added, in "power-domains" cells. This is documented here [1] in the
>>>> kernel, although looking at it I must admit it is not very clear.
>>>>
>>>> The power-domains cell represents an offset into an array of power
>>>> domains,
>>>> if you choose to use it. That's what the genpd framework is hard
>>>> coded to
>>>> interpret it as. This is correct, as it is an index into a static
>>>> list of
>>>> power domains, used to identify which power domain a device belongs to,
>>>> which is exactly what the genpd framework itself is concerned with.
>>>> This is
>>>> already how it is used in the kernel today.
>>>
>>>
>>> Strictly speaking, the cells are purely for the interpretation of the
>>> phandle they are associated with. If some controller wants to have 20
>>> cells, then it could assuming a good reason. The reality is we tend to
>>> align the meaning of the cells. If genpd is interpreting the cells and
>>> not letting the driver for the power domain controller interpret them,
>>> then still, genpd needs to be fixed.
>>
>>
>> Ok, perhaps the genpd folks on the thread can jump in here with any
>> thoughts that they have.
>>
>>>
>>> IIRC, initially it was said genpd required 0 cells, hence my confusion.
>>>
>>>> My ti,sci-id is not an index into a list of power domains, so it
>>>> should not
>>>> go in the power-domains cells and go against what the power-domains
>>>> binding
>>>> says that the cell expects. We have one single power domain, and the new
>>>> ti,sci-id binding is not something the genpd framework itself is
>>>> concerned
>>>> with as it's our property to identify a device inside a power domain,
>>>> not to
>>>> identify which power domain it is associated with.
>>>
>>>
>>> What is the id used for? I can understand why you need to know what
>>> power domain a device is in (as power-domains identifies), but not
>>> what devices are in a power domain.
>>
>>
>> We have a system control processor that provides power management
>> services to the OS and it responsible for handling the power state of
>> each device. This control happens over a communication interface we have
>> called TI SCI (implemented at drivers/firmware/ti-sci.c). The
>> communication protocol uses these ids to identify each device within the
>> power domain so that the control processor can do what is necessary to
>> enable that device.
>
>
> I think a minor detail here that Rob might be missing right now is, that the
> ti,sci-id is only controlling the PM runtime handling, and providing the ID
> per-device for this purpose only. AFAIK, it is not really connected to the
> power domain anymore as such, as we don't have power-domains / per device
> anymore as was the case in some earlier revision of this work.
So you used to have multiple power domains and now you don't? Did the
h/w change?
> One could argue though that the whole usage of power-domains is now moot, as
> we basically only have implemented one genpd in the whole SoC, which doesn't
> really reflect the reality. I wonder if better approach would be to have
> this replaced with proper power domains at some point (if needed), and just
> have a runtime-pm implementation in place for the devices that require it.
We're talking about bindings here. Any explanation in terms of
runtime-pm and genpd a) goes over my head and b) isn't relevant to
describing the hardware.
I'm still confused with how many power domains (as defined by the h/w
design) there are controlled by the SCI? Is it 1 or multiple? If 1,
then why do you need the sci-id? For other things that are not the
power domain?
Or perhaps the SCI abstracts things such that you don't really know
what the relationship between devices and power domains is? IOW, you
can't tell from the SCI interface how many power domains there are.
>
> So, as an example in DT, we would only have:
>
> uart0: serial at 02530c00 {
> compatible = "xyz";
> ...
> ti,sci-id = <K2G_DEV_UART0>;
> };
>
> This is somewhat analogous to what OMAP family of SoCs have in place now,
> under "ti,hwmods" property. I also wonder if the "ti,sci-id" should be
> replaced with something like "ti,sci-dev-id" to make its purpose clearer.
Describing in terms of hwmods doesn't help me either. Never understood
that either. Sorry.
Rob
^ permalink raw reply
* [PATCH] ARM: smp: Remove CPU: shutdown notice
From: Florian Fainelli @ 2017-01-17 23:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117232314.GI27312@n2100.armlinux.org.uk>
On 01/17/2017 03:23 PM, Russell King - ARM Linux wrote:
> On Tue, Jan 17, 2017 at 03:07:12PM -0800, Florian Fainelli wrote:
>> This message is not particularly informative, and is not paired with an
>> identical message when a CPU is brought online. Finally, it slows the
>> CPU hotplug path down, thus allowing less CPU hotplug operations per
>> second. Just remove it.
>
> CPU hotplug isn't a fast operation anyway - it's also fairly disruptive
> in that it uses stop_machine() to halt activity everywhere while taking
> the CPU offline.
We have a test that consists in shutting down all CPUs as frequently as
we can and do this for about 2 million iterations which takes roughly
24h, and this printk slows thing down by a reasonable amount. Here are
some numbers on 500 hotplug operations:
w/ printk:
real 0m9.997s
user 0m0.725s
sys 0m3.030s
#
w/o printk:
real 0m8.547s
user 0m0.436s
sys 0m1.838s
>
> If you're worried about a single printk slowing things down, it sounds
> like you're doing something wrong here - maybe you should be using
> cpuidle for power management rather than trying to make CPU hotplug do
> that for you?
No, this is not about power management considerations here, just how
fast we can bang it.
>
> A rapidly changing CPU hotplug state has other side effects - such as
> reading /proc/interrupts is meaningless, because as soon as you've read
> it the CPUs could have changed. It also makes a farce of spreading
> interrupts over the available CPUs.
>
> All in all, I don't think this is a good idea...
Well, for one it's inconsistent, and it also leaves room for subtle
timing/caching issues with some platforms (OK, maybe not so much).
Improving the speed and consistency was the primary motive.
--
Florian
^ permalink raw reply
* [PATCH net-next v4 05/10] drivers: base: Add device_find_in_class_name()
From: Florian Fainelli @ 2017-01-17 23:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VfE8t+_2Yu1NYMErKopnCNwFakO6pyDRmqAU-ZsGuyvmg@mail.gmail.com>
On 01/17/2017 03:34 PM, Andy Shevchenko wrote:
> On Wed, Jan 18, 2017 at 1:21 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> Add a helper function to lookup a device reference given a class name.
>> This is a preliminary patch to remove adhoc code from net/dsa/dsa.c and
>> make it more generic.
>
>
>> +static int device_class_name_match(struct device *dev, void *class)
>
> And why not const char *class?
This was raised back in v2, and the same response applies:
https://www.mail-archive.com/netdev at vger.kernel.org/msg147559.html
Changing the signature of a callback is out of the scope of this patch
series.
--
Florian
^ permalink raw reply
* [PATCH v19 05/15] clocksource/drivers/arm_arch_timer: rework PPI determination
From: Fu Wei @ 2017-01-17 23:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116172927.GI5908@leverpostej>
Hi Mark,
On 17 January 2017 at 01:29, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Dec 21, 2016 at 02:45:53PM +0800, fu.wei at linaro.org wrote:
> [...]
>
>> - if (is_hyp_mode_available() || !arch_timer_ppi[ARCH_TIMER_VIRT_PPI]) {
>> - bool has_ppi;
>> + if (is_hyp_mode_available() && is_kernel_in_hyp_mode())
>> + return ARCH_TIMER_HYP_PPI;
>>
>> - if (is_kernel_in_hyp_mode()) {
>> - arch_timer_uses_ppi = ARCH_TIMER_HYP_PPI;
>> - has_ppi = !!arch_timer_ppi[ARCH_TIMER_HYP_PPI];
>> - } else {
>> - arch_timer_uses_ppi = ARCH_TIMER_PHYS_SECURE_PPI;
>> - has_ppi = (!!arch_timer_ppi[ARCH_TIMER_PHYS_SECURE_PPI] ||
>> - !!arch_timer_ppi[ARCH_TIMER_PHYS_NONSECURE_PPI]);
>> - }
>> + if (arch_timer_ppi[ARCH_TIMER_VIRT_PPI])
>> + return ARCH_TIMER_VIRT_PPI;
>>
>> - if (!has_ppi) {
>> - pr_warn("No interrupt available, giving up\n");
>> - return -EINVAL;
>> - }
>> - }
>> + if (IS_ENABLED(CONFIG_ARM64))
>> + return ARCH_TIMER_PHYS_NONSECURE_PPI;
>> +
>> + return ARCH_TIMER_PHYS_SECURE_PPI;
>
> For a 32-bit platform booted at hyp (with a virt PPI available), the new
> logic will select ARCH_TIMER_VIRT_PPI. I beleive that will break KVM.
>
> I think the logic should be:
>
> if (is_kernel_in_hyp_mode())
> return ARCH_TIMER_HYP_PPI;
>
> if (!is_hyp_mode_available() &&
> arch_timer_ppi[ARCH_TIMER_VIRT_PPI])
> return ARCH_TIMER_VIRT_PPI;
>
> if (IS_ENABLED(CONFIG_ARM64))
> return ARCH_TIMER_PHYS_NONSECURE_PPI;
>
> return ARCH_TIMER_PHYS_SECURE_PPI;
>
> Please use that instead (keeping the comment you retained).
Great thanks for pointing it out, that is bug.
also got this bug report from Huawei engineer.
I have fixed it using your example code, thanks!
>
>> +static int __init arch_timer_init(void)
>> +{
>> + int ret;
>>
>> ret = arch_timer_register();
>> if (ret)
>> @@ -904,6 +906,13 @@ static int __init arch_timer_of_init(struct device_node *np)
>> if (IS_ENABLED(CONFIG_ARM) &&
>> of_property_read_bool(np, "arm,cpu-registers-not-fw-configured"))
>> arch_timer_uses_ppi = ARCH_TIMER_PHYS_SECURE_PPI;
>> + else
>> + arch_timer_uses_ppi = arch_timer_select_ppi();
>> +
>> + if (!arch_timer_ppi[arch_timer_uses_ppi]) {
>> + pr_err("No interrupt available, giving up\n");
>> + return -EINVAL;
>> + }
>>
>> /* On some systems, the counter stops ticking when in suspend. */
>> arch_counter_suspend_stop = of_property_read_bool(np,
>> @@ -1049,6 +1058,12 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *table)
>> /* Get the frequency from CNTFRQ */
>> arch_timer_detect_rate(NULL, NULL);
>>
>> + arch_timer_uses_ppi = arch_timer_select_ppi();
>> + if (!arch_timer_ppi[arch_timer_uses_ppi]) {
>> + pr_err("No interrupt available, giving up\n");
>> + return -EINVAL;
>> + }
>
> I see that we have to duplicate this so we can special-case the
> DT-specific behaviour, so that's fine by me.
Yes, that is the reason of the duplication :-)
>
> If you can fix the arch_timer_select_ppi() logic as above, this should
> be fine.
Done, thanks :-)
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH net-next v4 05/10] drivers: base: Add device_find_in_class_name()
From: Andy Shevchenko @ 2017-01-18 0:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b8cc0d2f-f544-0e06-32bd-47e6b9be5393@gmail.com>
On Wed, Jan 18, 2017 at 1:43 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 01/17/2017 03:34 PM, Andy Shevchenko wrote:
>> On Wed, Jan 18, 2017 at 1:21 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>> +static int device_class_name_match(struct device *dev, void *class)
>>
>> And why not const char *class?
>
> This was raised back in v2, and the same response applies:
>
> https://www.mail-archive.com/netdev at vger.kernel.org/msg147559.html
>
> Changing the signature of a callback is out of the scope of this patch
> series.
Ah, right.
But why not to use void *class_name to be consistent with callback and
device_find_child()?
Btw,
return get_device(parent);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Andreas Färber @ 2017-01-18 0:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ecb5ff50-f5d5-ffe6-0732-faf5e51906f8@baylibre.com>
Hi Neil,
Am 17.01.2017 um 09:21 schrieb Neil Armstrong:
> As I finally understand, the real issue here is the usage of the "linux,useable-memory" property that
> overrides the reg property that is changed by the bootloader to provide the "real" memory size.
Yes, exactly. It assured that 0..0x01000000 was always unavailable, as
intended, but at the same time it ignored any lowered or heightened
upper limit coming from the bootloader side.
As a rule of thumb, any nodes that have device_type set can be expected
to be modified during boot.
> As I understand the mainline U-Boot does it right, and it's a good news, and it seems uEFI need to provide
> some specialized memory range aswell, but the vendor U-Boot versions only provide the full memory range here.
> It seems obvious that whatever range is provided by u-boot, the first 16MiB should be reserved.
>
> The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
> zones,
Thanks, its binary is called stress-ng in openSUSE Tumbleweed. ;)
> but I also got the issue while running a fully fledged Desktop Environment thanks to the
> recently merged DRM driver.
I'll happily test once HDMI is ready. :)
> You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
> https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
> But it should be confirmed.
Confirming no issues on three runs on meson-gxm-rbox-pro:
boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s &
[1] 2528
boxer:~ # stress-ng: info: [2528] dispatching hogs: 4 vm
stress-ng: info: [2528] cache allocate: default cache size: 256K
stress-ng: info: [2528] successful run completed in 10.07s
[1]+ Done stress-ng --vm 4 --vm-bytes 128M --timeout 10s
boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
stress-ng: info: [2537] dispatching hogs: 4 vm
stress-ng: info: [2537] cache allocate: default cache size: 256K
stress-ng: info: [2537] successful run completed in 10.07s
boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
stress-ng: info: [2546] dispatching hogs: 4 vm
stress-ng: info: [2546] cache allocate: default cache size: 256K
stress-ng: info: [2546] successful run completed in 10.07s
boxer:~ #
> Kevin asked me initially to handle this "start of ddr" reserved zone via a reserved-memory entry, but
> at that time it seemed a better idea to use "linux,useable-memory", but I recon it may be an error.
>
> I will push a v5 with a supplementary reserved-memory entry and will postpone the boards memory size
> fixup for a future DTS cleanup.
>
> Andreas, is this ok for you ?
Yes, sounds fine to me, thanks. I'll note a few more nits to consider.
Kevin, I noticed that this supposedly applied patch did not show up in
linux-next for testing - could you merge your fixes branch into for-next
please for those of us working on new stuff?
> This issue exists since forever on mainline linux, and even 4.9 has it.
> Olof, How could a similar fix go in 4.9 stable ?
I guess it would then be best to consider splitting this patch up per
board/SoC so that you can set appropriate Fixes: headers indicating how
far back each one needs to be fixed.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH net-next v4 05/10] drivers: base: Add device_find_in_class_name()
From: Florian Fainelli @ 2017-01-18 0:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75Ve9xn6wDxFwnkPDyY8yVwVysK3-pUsoxv3GfVbbEVZoBg@mail.gmail.com>
On 01/17/2017 04:00 PM, Andy Shevchenko wrote:
> On Wed, Jan 18, 2017 at 1:43 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> On 01/17/2017 03:34 PM, Andy Shevchenko wrote:
>>> On Wed, Jan 18, 2017 at 1:21 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>>>> +static int device_class_name_match(struct device *dev, void *class)
>>>
>>> And why not const char *class?
>>
>> This was raised back in v2, and the same response applies:
>>
>> https://www.mail-archive.com/netdev at vger.kernel.org/msg147559.html
>>
>> Changing the signature of a callback is out of the scope of this patch
>> series.
>
> Ah, right.
>
> But why not to use void *class_name to be consistent with callback and
> device_find_child()?
The top-level function: device_find_in_class_name() should have a
stronger typing of its argument even if it internally uses
device_find_child() and a callback that takes a void * argument, that's
how I see it.
>
> Btw,
>
> return get_device(parent);
Not sure I follow what that means here?
--
Florian
^ permalink raw reply
* [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains
From: Kevin Hilman @ 2017-01-18 0:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4cb25cf9-216f-2e18-f45d-ef7e48fa6c5e@ti.com>
Tero Kristo <t-kristo@ti.com> writes:
> On 17/01/17 00:12, Dave Gerlach wrote:
>> On 01/13/2017 08:40 PM, Rob Herring wrote:
>>> On Fri, Jan 13, 2017 at 2:28 PM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>>> On 01/13/2017 01:25 PM, Rob Herring wrote:
>>>>>
>>>>> On Thu, Jan 12, 2017 at 9:27 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>>>>>
>>>>>> Rob,
>>>>>>
>>>>>> On 01/11/2017 03:34 PM, Rob Herring wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jan 9, 2017 at 11:57 AM, Dave Gerlach <d-gerlach@ti.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Rob,
>>>>>>>>
>>>>>>>> On 01/09/2017 11:50 AM, Rob Herring wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>>>>>>>> will hook into the genpd framework and allow the TI SCI
>>>>>>>>>> protocol to
>>>>>>>>>> control device power states.
>>>>>>>>>>
>>>>>>>>>> Also, provide macros representing each device index as understood
>>>>>>>>>> by TI SCI to be used in the device node power-domain references.
>>>>>>>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>>>>>>>> ---
>>>>>>>>>> v2->v3:
>>>>>>>>>> Update k2g_pds node docs to show it should be a child
>>>>>>>>>> of pmmc
>>>>>>>>>> node.
>>>>>>>>>> In early versions a phandle was used to point to pmmc and
>>>>>>>>>> docs
>>>>>>>>>> still
>>>>>>>>>> incorrectly showed this.
>>>>>>>>>>
>>>>>>>>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 59
>>>>>>>>>> ++++++++++++++
>>>>>>>>>> MAINTAINERS | 2 +
>>>>>>>>>> include/dt-bindings/genpd/k2g.h | 90
>>>>>>>>>> ++++++++++++++++++++++
>>>>>>>>>> 3 files changed, 151 insertions(+)
>>>>>>>>>> create mode 100644
>>>>>>>>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>>>>>>>
>>>>>>>>>> diff --git
>>>>>>>>>> a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>>>> new file mode 100644
>>>>>>>>>> index 000000000000..4c9064e512cb
>>>>>>>>>> --- /dev/null
>>>>>>>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>>>> @@ -0,0 +1,59 @@
>>>>>>>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>>>>>>>> +---------------------------------------------
>>>>>>>>>> +
>>>>>>>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...)
>>>>>>>>>> that
>>>>>>>>>> is
>>>>>>>>>> +responsible for controlling the state of the IPs that are
>>>>>>>>>> present.
>>>>>>>>>> +Communication between the host processor running an OS and the
>>>>>>>>>> system
>>>>>>>>>> +controller happens through a protocol known as TI-SCI [1].
>>>>>>>>>> This pm
>>>>>>>>>> domain
>>>>>>>>>> +implementation plugs into the generic pm domain framework and
>>>>>>>>>> makes
>>>>>>>>>> use
>>>>>>>>>> of
>>>>>>>>>> +the TI SCI protocol power on and off each device when needed.
>>>>>>>>>> +
>>>>>>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>>>>>>> +
>>>>>>>>>> +PM Domain Node
>>>>>>>>>> +==============
>>>>>>>>>> +The PM domain node represents the global PM domain managed by the
>>>>>>>>>> PMMC,
>>>>>>>>>> +which in this case is the single implementation as documented
>>>>>>>>>> by the
>>>>>>>>>> generic
>>>>>>>>>> +PM domain bindings in
>>>>>>>>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>>>>>>>>> +Because this relies on the TI SCI protocol to communicate with
>>>>>>>>>> the
>>>>>>>>>> PMMC
>>>>>>>>>> it
>>>>>>>>>> +must be a child of the pmmc node.
>>>>>>>>>> +
>>>>>>>>>> +Required Properties:
>>>>>>>>>> +--------------------
>>>>>>>>>> +- compatible: should be "ti,sci-pm-domain"
>>>>>>>>>> +- #power-domain-cells: Must be 0.
>>>>>>>>>> +
>>>>>>>>>> +Example (K2G):
>>>>>>>>>> +-------------
>>>>>>>>>> + pmmc: pmmc {
>>>>>>>>>> + compatible = "ti,k2g-sci";
>>>>>>>>>> + ...
>>>>>>>>>> +
>>>>>>>>>> + k2g_pds: k2g_pds {
>>>>>>>>>> + compatible = "ti,sci-pm-domain";
>>>>>>>>>> + #power-domain-cells = <0>;
>>>>>>>>>> + };
>>>>>>>>>> + };
>>>>>>>>>> +
>>>>>>>>>> +PM Domain Consumers
>>>>>>>>>> +===================
>>>>>>>>>> +Hardware blocks that require SCI control over their state must
>>>>>>>>>> provide
>>>>>>>>>> +a reference to the sci-pm-domain they are part of and a unique
>>>>>>>>>> device
>>>>>>>>>> +specific ID that identifies the device.
>>>>>>>>>> +
>>>>>>>>>> +Required Properties:
>>>>>>>>>> +--------------------
>>>>>>>>>> +- power-domains: phandle pointing to the corresponding PM domain
>>>>>>>>>> node.
>>>>>>>>>> +- ti,sci-id: index representing the device id to be passed
>>>>>>>>>> oevr SCI
>>>>>>>>>> to
>>>>>>>>>> + be used for device control.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As I've already stated before, this goes in power-domain cells.
>>>>>>>>> When
>>>>>>>>> you
>>>>>>>>> have a single thing (i.e. node) that controls multiple things, then
>>>>>>>>> you
>>>>>>>>> you need to specify the ID for each of them in phandle args.
>>>>>>>>> This is
>>>>>>>>> how
>>>>>>>>> irqs, gpio, clocks, *everything* in DT works.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> You think the reasoning for doing it this way provided by both
>>>>>>>> Ulf and
>>>>>>>> myself on v2 [1] is not valid then?
>>>>>>>>
>>>>>>>> From Ulf:
>>>>>>>>
>>>>>>>> To me, the TI SCI ID, is similar to a "conid" for any another
>>>>>>>> "device
>>>>>>>> resource" (like clock, pinctrl, regulator etc) which we can describe
>>>>>>>> in DT and assign to a device node. The only difference here, is that
>>>>>>>> we don't have common API to fetch the resource (like clk_get(),
>>>>>>>> regulator_get()), but instead we fetches the device's resource from
>>>>>>>> SoC specific code, via genpd's device ->attach() callback.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sorry, but that sounds like a kernel problem to me and has nothing to
>>>>>>> do with DT bindings.
>>>>>>>
>>>>>>>> From me:
>>>>>>>>
>>>>>>>> Yes, you've pretty much hit it on the head. It is not an index
>>>>>>>> into a
>>>>>>>> list
>>>>>>>> of genpds but rather identifies the device *within* a single
>>>>>>>> genpd. It
>>>>>>>> is
>>>>>>>> a
>>>>>>>> property specific to each device that resides in a ti-sci-genpd,
>>>>>>>> not a
>>>>>>>> mapping describing which genpd the device belongs to. The generic
>>>>>>>> power
>>>>>>>> domain binding is concerned with mapping the device to a specific
>>>>>>>> genpd,
>>>>>>>> which is does fine for us, but we have a sub mapping for devices
>>>>>>>> that
>>>>>>>> exist
>>>>>>>> inside a genpd which, we must describe as well, hence the ti,sci-id.
>>>>>>>>
>>>>>>>>
>>>>>>>> So to summarize, the genpd framework does interpret the phandle
>>>>>>>> arg as
>>>>>>>> an
>>>>>>>> index into multiple genpds, just as you've said other frameworks do,
>>>>>>>> but
>>>>>>>> this is not what I am trying to do, we have multiple devices within
>>>>>>>> this
>>>>>>>> *single* genpd, hence the need for the ti,sci-id property.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Fix the genpd framework rather than work around it in DT.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I still disagree that this has nothing to do with DT bindings, as the
>>>>>> current DT binding represents something different already. I am
>>>>>> trying to
>>>>>> extend it to give me additional information needed for our
>>>>>> platforms. Are
>>>>>> you saying that we should break what the current DT binding already
>>>>>> represents to mean something else?
>>>>>
>>>>>
>>>>> No idea because what's the current binding? From the patch, looks like
>>>>> a new binding to me.
>>>>
>>>>
>>>> Yes, ti,sci-id is a new binding. I am referring to the current
>>>> meaning of
>>>> the "power-domains" binding, which is where you are asking this
>>>> property to
>>>> be added, in "power-domains" cells. This is documented here [1] in the
>>>> kernel, although looking at it I must admit it is not very clear.
>>>>
>>>> The power-domains cell represents an offset into an array of power
>>>> domains,
>>>> if you choose to use it. That's what the genpd framework is hard
>>>> coded to
>>>> interpret it as. This is correct, as it is an index into a static
>>>> list of
>>>> power domains, used to identify which power domain a device belongs to,
>>>> which is exactly what the genpd framework itself is concerned with.
>>>> This is
>>>> already how it is used in the kernel today.
>>>
>>> Strictly speaking, the cells are purely for the interpretation of the
>>> phandle they are associated with. If some controller wants to have 20
>>> cells, then it could assuming a good reason. The reality is we tend to
>>> align the meaning of the cells. If genpd is interpreting the cells and
>>> not letting the driver for the power domain controller interpret them,
>>> then still, genpd needs to be fixed.
>>
>> Ok, perhaps the genpd folks on the thread can jump in here with any
>> thoughts that they have.
>>
>>>
>>> IIRC, initially it was said genpd required 0 cells, hence my confusion.
>>>
>>>> My ti,sci-id is not an index into a list of power domains, so it
>>>> should not
>>>> go in the power-domains cells and go against what the power-domains
>>>> binding
>>>> says that the cell expects. We have one single power domain, and the new
>>>> ti,sci-id binding is not something the genpd framework itself is
>>>> concerned
>>>> with as it's our property to identify a device inside a power domain,
>>>> not to
>>>> identify which power domain it is associated with.
>>>
>>> What is the id used for? I can understand why you need to know what
>>> power domain a device is in (as power-domains identifies), but not
>>> what devices are in a power domain.
>>
>> We have a system control processor that provides power management
>> services to the OS and it responsible for handling the power state of
>> each device. This control happens over a communication interface we have
>> called TI SCI (implemented at drivers/firmware/ti-sci.c). The
>> communication protocol uses these ids to identify each device within the
>> power domain so that the control processor can do what is necessary to
>> enable that device.
>
> I think a minor detail here that Rob might be missing right now is,
> that the ti,sci-id is only controlling the PM runtime handling, and
> providing the ID per-device for this purpose only. AFAIK, it is not
> really connected to the power domain anymore as such, as we don't have
> power-domains / per device anymore as was the case in some earlier
> revision of this work.
I think this gets to the heart of things. IMO The confusion arises
because we're throwing around the term "power domain" when there isn't
an actual hardware power domain here.
Unfortunately, the genpd bindings have used the terminology power-domain
when in fact genpd is more generic than that and can be used not just
for hardware power domains, but for arbitrary grouping of devices that
have common PM properties. That's why genpd actually stands for generic
PM domain, not power domain. Unfortunately, the bindings have grown
primarily out of the usage for hardware power domains.
> One could argue though that the whole usage of power-domains is now
> moot, as we basically only have implemented one genpd in the whole
> SoC, which doesn't really reflect the reality. I wonder if better
> approach would be to have this replaced with proper power domains at
> some point (if needed), and just have a runtime-pm implementation in
> place for the devices that require it.
>
> So, as an example in DT, we would only have:
>
> uart0: serial at 02530c00 {
> compatible = "xyz";
> ...
> ti,sci-id = <K2G_DEV_UART0>;
> };
>
> This is somewhat analogous to what OMAP family of SoCs have in place
> now, under "ti,hwmods" property. I also wonder if the "ti,sci-id"
> should be replaced with something like "ti,sci-dev-id" to make its
> purpose clearer.
Unless I'm missing something, that still begs the question of who reads
that property and takes care of the call into TI-SCI though.
Kevin
^ permalink raw reply
* [PATCH net-next v4 05/10] drivers: base: Add device_find_in_class_name()
From: Andy Shevchenko @ 2017-01-18 0:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e3132d31-f94f-8794-1121-0fe25be2f61b@gmail.com>
On Wed, Jan 18, 2017 at 2:04 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 01/17/2017 04:00 PM, Andy Shevchenko wrote:
>> On Wed, Jan 18, 2017 at 1:43 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>> On 01/17/2017 03:34 PM, Andy Shevchenko wrote:
>>>> On Wed, Jan 18, 2017 at 1:21 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> But why not to use void *class_name to be consistent with callback and
>> device_find_child()?
>
> The top-level function: device_find_in_class_name() should have a
> stronger typing of its argument even if it internally uses
> device_find_child() and a callback that takes a void * argument, that's
> how I see it.
Fair enough.
>> Btw,
>> return get_device(parent);
>
> Not sure I follow what that means here?
Missed remark. Instead of
get_device(parent);
return parent;
you can use
return get_device(parent);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Andreas Färber @ 2017-01-18 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484129414-23325-1-git-send-email-narmstrong@baylibre.com>
Am 11.01.2017 um 11:10 schrieb Neil Armstrong:
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> index eada0b5..66677b5 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> @@ -55,6 +55,18 @@
> #address-cells = <2>;
> #size-cells = <2>;
>
> + reserved-memory {
Should this get a label for future gx*-level additions?
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /* 2MiB reserved for ARM Trusted Firmware (BL31) */
"2 MiB" please. Ditto for the to-be-refactored 16 MiB node.
> + secmon: secmon {
> + reg = <0x0 0x10000000 0x0 0x200000>;
> + no-map;
> + };
> + };
> +
> cpus {
> #address-cells = <0x2>;
> #size-cells = <0x0>;
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [GIT PULL] omap fixes for v4.10-rc4
From: Tony Lindgren @ 2017-01-18 0:12 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 1a38de880992764d4bd5bccbd306b87d860e377d:
ARM: dts: am572x-idk: Add gpios property to control PCIE_RESETn (2016-12-30 10:59:56 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.10/fixes-rc4
for you to fetch changes up to 1ea6af3216b092ec97129ac81bd95cf254c4b140:
ARM: dts: omap3: Fix Card Detect and Write Protect on Logic PD SOM-LV (2017-01-17 13:50:55 -0800)
----------------------------------------------------------------
Fixes for omaps for v4.10-rc cycle. Mostly a DMA regression fix for
omap1, and then a handful of trivial fixes for boards and devices to
work:
- Fixes TI wilink bluetooth strange platform data baud rate
- Remove duplicate pinmux line for am335x-icev2
- Fix omap1 dma regression
- Fix uninitialized return value for wkup_m3_ipc_probe()
- Fix Ethernet PHY binding typo for dra72-evm
- Fix init for omap5 and dra7 sata ports
- Fix mmc card detect pin for Logic PD SOM-LV
----------------------------------------------------------------
Adam Ford (2):
ARM: OMAP2+: Fix WL1283 Bluetooth Baud Rate
ARM: dts: omap3: Fix Card Detect and Write Protect on Logic PD SOM-LV
Jean-Jacques Hiblot (1):
ARM: dts: OMAP5 / DRA7: indicate that SATA port 0 is available.
Lokesh Vutla (1):
ARM: dts: am335x-icev2: Remove the duplicated pinmux setting
Peter Ujfalusi (1):
ARM: OMAP1: DMA: Correct the number of logical channels
Sekhar Nori (1):
ARM: dts: dra72-evm-revc: fix typo in ethernet-phy node
Wei Yongjun (1):
soc: ti: wkup_m3_ipc: Fix error return code in wkup_m3_ipc_probe()
arch/arm/boot/dts/am335x-icev2.dts | 1 -
arch/arm/boot/dts/dra7.dtsi | 1 +
arch/arm/boot/dts/dra72-evm-revc.dts | 2 +-
arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts | 11 +++--------
arch/arm/boot/dts/omap5.dtsi | 1 +
arch/arm/mach-omap1/dma.c | 16 +++++++---------
arch/arm/mach-omap2/pdata-quirks.c | 2 +-
drivers/soc/ti/wkup_m3_ipc.c | 1 +
8 files changed, 15 insertions(+), 20 deletions(-)
^ permalink raw reply
* [PATCH net-next v4 05/10] drivers: base: Add device_find_in_class_name()
From: Florian Fainelli @ 2017-01-18 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VeqLb2hDgj2jfWzQgw4wa31gckSw=jZS0UhUAnZgNA14Q@mail.gmail.com>
On 01/17/2017 04:07 PM, Andy Shevchenko wrote:
> On Wed, Jan 18, 2017 at 2:04 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> On 01/17/2017 04:00 PM, Andy Shevchenko wrote:
>>> On Wed, Jan 18, 2017 at 1:43 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>> On 01/17/2017 03:34 PM, Andy Shevchenko wrote:
>>>>> On Wed, Jan 18, 2017 at 1:21 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>>> But why not to use void *class_name to be consistent with callback and
>>> device_find_child()?
>>
>> The top-level function: device_find_in_class_name() should have a
>> stronger typing of its argument even if it internally uses
>> device_find_child() and a callback that takes a void * argument, that's
>> how I see it.
>
> Fair enough.
>
>>> Btw,
>>> return get_device(parent);
>>
>> Not sure I follow what that means here?
>
> Missed remark. Instead of
>
> get_device(parent);
> return parent;
>
> you can use
>
> return get_device(parent);
Seems reasonable, if I have to respin a v5, will add that, thanks!
--
Florian
^ permalink raw reply
* [PATCH] ARM: davinci: da850-evm: fix read access to SPI flash
From: Kevin Hilman @ 2017-01-18 0:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117125742.9536-1-fparent@baylibre.com>
Fabien Parent <fparent@baylibre.com> writes:
> Read access to the SPI flash are broken on da850-evm, i.e. the data
> read is not what is actually programmed on the flash.
> According to the datasheet for the M25P64 part present on the da850-evm,
> if the SPI frequency is higher than 20MHz then the READ command is not
> usable anymore and only the FAST_READ command can be used to read data.
>
> This commit specifies in the DTS that we should use FAST_READ command
> instead of the READ command.
>
> Signed-off-by: Fabien Parent <fparent@baylibre.com>
Tested on da850-evm on top of v4.10-rc3. This gets the DT boot
functionatliy in line with the legacy (board-file) boot.
Tested-by: Kevin Hilman <khilman@baylibre.com>
Kevin
^ permalink raw reply
* [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Andreas Färber @ 2017-01-18 0:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <04113569-e342-77ff-f79a-2c9c4dc4c602@suse.de>
Am 18.01.2017 um 01:00 schrieb Andreas F?rber:
> Am 17.01.2017 um 09:21 schrieb Neil Armstrong:
>> The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
>> zones, but I also got the issue while running a fully fledged Desktop Environment thanks to the
>> recently merged DRM driver.
>> You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
>> https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
>> But it should be confirmed.
>
> Confirming no issues on three runs on meson-gxm-rbox-pro:
>
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s &
> [1] 2528
> boxer:~ # stress-ng: info: [2528] dispatching hogs: 4 vm
> stress-ng: info: [2528] cache allocate: default cache size: 256K
> stress-ng: info: [2528] successful run completed in 10.07s
>
> [1]+ Done stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info: [2537] dispatching hogs: 4 vm
> stress-ng: info: [2537] cache allocate: default cache size: 256K
> stress-ng: info: [2537] successful run completed in 10.07s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info: [2546] dispatching hogs: 4 vm
> stress-ng: info: [2546] cache allocate: default cache size: 256K
> stress-ng: info: [2546] successful run completed in 10.07s
> boxer:~ #
Similar results on meson-gxbb-vega-s95-telos (except 512K cache size),
with both mainline EFI and vendor U-Boot.
I notice that I don't have CONFIG_DRM enabled - maybe related?
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH 1/2] [media] exynos-gsc: Fix unbalanced pm_runtime_enable() error
From: Javier Martinez Canillas @ 2017-01-18 0:30 UTC (permalink / raw)
To: linux-arm-kernel
Commit a006c04e6218 ("[media] exynos-gsc: Fixup clock management at
->remove()") changed the driver's .remove function logic to fist do
a pm_runtime_get_sync() to make sure the device is powered before
attempting to gate the gsc clock.
But the commit also removed a pm_runtime_disable() call that leads
to an unbalanced pm_runtime_enable() error if the driver is removed
and re-probed:
exynos-gsc 13e00000.video-scaler: Unbalanced pm_runtime_enable!
exynos-gsc 13e10000.video-scaler: Unbalanced pm_runtime_enable!
Fixes: a006c04e6218 ("[media] exynos-gsc: Fixup clock management at ->remove()")
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
drivers/media/platform/exynos-gsc/gsc-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
index cbf75b6194b4..83272f10722d 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1118,6 +1118,7 @@ static int gsc_remove(struct platform_device *pdev)
clk_disable_unprepare(gsc->clock[i]);
pm_runtime_put_noidle(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] [media] exynos-gsc: Fix imprecise external abort due disabled power domain
From: Javier Martinez Canillas @ 2017-01-18 0:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484699402-28738-1-git-send-email-javier@osg.samsung.com>
Commit 15f90ab57acc ("[media] exynos-gsc: Make driver functional when
CONFIG_PM is unset") removed the implicit dependency that the driver
had with CONFIG_PM, since it relied on the config option to be enabled.
In order to work with !CONFIG_PM, the GSC reset logic that happens in
the runtime resume callback had to be executed on the probe function.
The problem is that if CONFIG_PM is enabled, the power domain for the
GSC could be disabled and so an attempt to write to the GSC_SW_RESET
register leads to an unhandled fault / imprecise external abort error:
[ 10.178825] Unhandled fault: imprecise external abort (0x1406) at 0x00000000
[ 10.186982] pgd = ed728000
[ 10.190847] [00000000] *pgd=00000000
[ 10.195553] Internal error: : 1406 [#1] PREEMPT SMP ARM
[ 10.229761] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 10.237134] task: ed49e400 task.stack: ed724000
[ 10.242934] PC is at gsc_wait_reset+0x5c/0x6c [exynos_gsc]
[ 10.249710] LR is at gsc_probe+0x300/0x33c [exynos_gsc]
[ 10.256139] pc : [<bf2429e0>] lr : [<bf240734>] psr: 60070013
[ 10.256139] sp : ed725d30 ip : 00000000 fp : 00000001
[ 10.271492] r10: eea74800 r9 : ecd6a2c0 r8 : ed7d8854
[ 10.277912] r7 : ed7d8c08 r6 : ed7d8810 r5 : ffff8ecd r4 : c0c03900
[ 10.285664] r3 : 00000000 r2 : 00000001 r1 : ed7d8b98 r0 : ed7d8810
So only do a GSC reset if CONFIG_PM is disabled, since if is enabled the
runtime PM resume callback will be called by the VIDIOC_STREAMON ioctl,
making the reset in probe unneeded.
Fixes: 15f90ab57acc ("[media] exynos-gsc: Make driver functional when CONFIG_PM is unset")
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
I-ve only tested with CONFIG_PM enabled since my Exynos5422 Odroid
XU4 board fails to boot when the config option is disabled.
Best regards,
Javier
drivers/media/platform/exynos-gsc/gsc-core.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
index 83272f10722d..42e1e09ea915 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1083,8 +1083,10 @@ static int gsc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, gsc);
- gsc_hw_set_sw_reset(gsc);
- gsc_wait_reset(gsc);
+ if (!IS_ENABLED(CONFIG_PM)) {
+ gsc_hw_set_sw_reset(gsc);
+ gsc_wait_reset(gsc);
+ }
vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
--
2.7.4
^ permalink raw reply related
* [PATCH v2 14/14] ARM: dts: da850-lcdk: enable the SATA node
From: Kevin Hilman @ 2017-01-18 0:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484655976-25382-15-git-send-email-bgolaszewski@baylibre.com>
Bartosz Golaszewski <bgolaszewski@baylibre.com> writes:
> Enable the SATA node for da850-lcdk. We omit the pinctrl property on
> purpose - the muxed SATA pins are not hooked up to anything
> SATA-related on the lcdk.
>
> The REFCLKN/P rate on the board is 100MHz, so we need a multiplier of
> 15 for 1.5GHz PLL rate.
leftover comment from previous version?
Kevin
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/boot/dts/da850-lcdk.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
> index afcb482..fbeee3c 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -105,6 +105,10 @@
> status = "okay";
> };
>
> +&sata {
> + status = "okay";
> +};
> +
> &mdio {
> pinctrl-names = "default";
> pinctrl-0 = <&mdio_pins>;
^ permalink raw reply
* [PATCHv2 0/3] OF phandle nexus support + GPIO nexus
From: Stephen Boyd @ 2017-01-18 0:50 UTC (permalink / raw)
To: linux-arm-kernel
This is one small chunk of work related to DT overlays for expansion
boards. It would be good to have a way to expose #<list>-cells types of
providers through a connector in a standard way. So we introduce a way
to make "nexus" nodes for these types of properties to remap the consumer
number space to the other side of the connector's number space. It's
basically a copy of the interrupt nexus implementation, but without
the address space matching design and interrupt-parent walking.
The first patch implements a generic method to do this, and the second patch
adds a unit test for it. The third patch is more of an example than anything
else. It shows how we would modify frameworks to use the new API.
I wasn't certain what more to document, but I
Changes since v1:
* Addition of optional pass-thru parameter
* Reduction of strings passed to 1 instead of 3 (or 4 now)
* Updated gpio patch for the new function signature
* Updated test-case for new funciton signature and pass-thru parameter
* Updated kernel-doc to be correct and highlighted difference between
this API and of_parse_phandle_with_args()
Stephen Boyd (3):
of: Support parsing phandle argument lists through a nexus node
of: unittest: Add phandle remapping test
gpio: Support gpio nexus dt bindings
drivers/gpio/gpiolib-of.c | 4 +-
drivers/of/base.c | 186 ++++++++++++++++++++++++++++
drivers/of/unittest-data/testcases.dts | 11 ++
drivers/of/unittest-data/tests-phandle.dtsi | 25 ++++
drivers/of/unittest.c | 120 ++++++++++++++++++
include/linux/of.h | 12 ++
6 files changed, 356 insertions(+), 2 deletions(-)
--
2.10.0.297.gf6727b0
^ permalink raw reply
* [PATCH v2 1/3] of: Support parsing phandle argument lists through a nexus node
From: Stephen Boyd @ 2017-01-18 0:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118005038.9216-1-stephen.boyd@linaro.org>
Platforms like 96boards have a standardized connector/expansion
slot that exposes signals like GPIOs to expansion boards in an
SoC agnostic way. We'd like the DT overlays for the expansion
boards to be written once without knowledge of the SoC on the
other side of the connector. This avoids the unscalable
combinatorial explosion of a different DT overlay for each
expansion board and SoC pair.
We need a way to describe the GPIOs routed through the connector
in an SoC agnostic way. Let's introduce nexus property parsing
into the OF core to do this. This is largely based on the
interrupt nexus support we already have. This allows us to remap
a phandle list in a consumer node (e.g. reset-gpios) through a
connector in a generic way (e.g. via gpio-map). Do this in a
generic routine so that we can remap any sort of variable length
phandle list.
Taking GPIOs as an example, the connector would be a GPIO nexus,
supporting the remapping of a GPIO specifier space to multiple
GPIO providers on the SoC. DT would look as shown below, where
'soc_gpio1' and 'soc_gpio2' are inside the SoC, 'connector' is an
expansion port where boards can be plugged in, and
'expansion_device' is a device on the expansion board.
soc {
soc_gpio1: gpio-controller1 {
#gpio-cells = <2>;
};
soc_gpio2: gpio-controller2 {
#gpio-cells = <2>;
};
};
connector: connector {
#gpio-cells = <2>;
gpio-map = <0 0 &soc_gpio1 1 0>,
<1 0 &soc_gpio2 4 0>,
<2 0 &soc_gpio1 3 0>,
<3 0 &soc_gpio2 2 0>;
gpio-map-mask = <0xf 0x0>;
gpio-map-pass-thru = <0x0 0x1>
};
expansion_device {
reset-gpios = <&connector 2 GPIO_ACTIVE_LOW>;
};
The GPIO core would use of_parse_phandle_with_args_map() instead
of of_parse_phandle_with_args() and arrive at the same type of
result, a phandle and argument list. The difference is that the
phandle and arguments will be remapped through the nexus node to
the underlying SoC GPIO controller node. In the example above,
we would remap 'reset-gpios' from <&connector 2 GPIO_ACTIVE_LOW>
to <&soc_gpio1 3 GPIO_ACTIVE_LOW>.
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
---
drivers/of/base.c | 186 +++++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/of.h | 12 ++++
2 files changed, 198 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4bea3c797d6..277a81ff0479 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1775,6 +1775,192 @@ int of_parse_phandle_with_args(const struct device_node *np, const char *list_na
EXPORT_SYMBOL(of_parse_phandle_with_args);
/**
+ * of_parse_phandle_with_args_map() - Find a node pointed by phandle in a list and remap it
+ * @np: pointer to a device tree node containing a list
+ * @list_name: property name that contains a list
+ * @stem_name: stem of property names that specify phandles' arguments count
+ * @index: index of a phandle to parse out
+ * @out_args: optional pointer to output arguments structure (will be filled)
+ *
+ * This function is useful to parse lists of phandles and their arguments.
+ * Returns 0 on success and fills out_args, on error returns appropriate errno
+ * value. The difference between this function and of_parse_phandle_with_args()
+ * is that this API remaps a phandle if the node the phandle points to has
+ * a <@stem_name>-map property.
+ *
+ * Caller is responsible to call of_node_put() on the returned out_args->np
+ * pointer.
+ *
+ * Example:
+ *
+ * phandle1: node1 {
+ * #list-cells = <2>;
+ * }
+ *
+ * phandle2: node2 {
+ * #list-cells = <1>;
+ * }
+ *
+ * phandle3: node3 {
+ * #list-cells = <1>;
+ * list-map = <0 &phandle2 3>,
+ * <1 &phandle2 2>,
+ * <2 &phandle1 5 1>;
+ * list-map-mask = <0x3>;
+ * };
+ *
+ * node4 {
+ * list = <&phandle1 1 2 &phandle3 0>;
+ * }
+ *
+ * To get a device_node of the `node2' node you may call this:
+ * of_parse_phandle_with_args(node4, "list", "list", 1, &args);
+ */
+int of_parse_phandle_with_args_map(const struct device_node *np,
+ const char *list_name,
+ const char *stem_name,
+ int index, struct of_phandle_args *out_args)
+{
+ char *cells_name, *map_name = NULL, *mask_name = NULL;
+ char *pass_name = NULL;
+ struct device_node *cur, *new = NULL;
+ const __be32 *map, *mask, *pass, *tmp;
+ const __be32 dummy_mask[] = { [0 ... MAX_PHANDLE_ARGS] = ~0 };
+ const __be32 dummy_pass[] = { [0 ... MAX_PHANDLE_ARGS] = 0 };
+ __be32 initial_match_array[MAX_PHANDLE_ARGS];
+ const __be32 *match_array = initial_match_array;
+ int i, ret, map_len, match;
+ u32 list_size, new_size;
+
+ if (index < 0)
+ return -EINVAL;
+
+ cells_name = kasprintf(GFP_KERNEL, "#%s-cells", stem_name);
+ if (!cells_name)
+ return -ENOMEM;
+
+ ret = -ENOMEM;
+ map_name = kasprintf(GFP_KERNEL, "%s-map", stem_name);
+ if (!map_name)
+ goto free;
+
+ mask_name = kasprintf(GFP_KERNEL, "%s-map-mask", stem_name);
+ if (!mask_name)
+ goto free;
+
+ pass_name = kasprintf(GFP_KERNEL, "%s-map-pass-thru", stem_name);
+ if (!pass_name)
+ goto free;
+
+ ret = __of_parse_phandle_with_args(np, list_name, cells_name, 0, index,
+ out_args);
+ if (ret)
+ goto free;
+
+ /* Get the #<list>-cells property */
+ cur = out_args->np;
+ ret = of_property_read_u32(cur, cells_name, &list_size);
+ if (ret < 0)
+ goto put;
+
+ /* Precalculate the match array - this simplifies match loop */
+ for (i = 0; i < list_size; i++)
+ initial_match_array[i] = cpu_to_be32(out_args->args[i]);
+
+ ret = -EINVAL;
+ while (cur) {
+ /* Get the <list>-map property */
+ map = of_get_property(cur, map_name, &map_len);
+ if (!map) {
+ ret = 0;
+ goto free;
+ }
+ map_len /= sizeof(u32);
+
+ /* Get the <list>-map-mask property (optional) */
+ mask = of_get_property(cur, mask_name, NULL);
+ if (!mask)
+ mask = dummy_mask;
+ /* Iterate through <list>-map property */
+ match = 0;
+ while (map_len > (list_size + 1) && !match) {
+ /* Compare specifiers */
+ match = 1;
+ for (i = 0; i < list_size; i++, map_len--)
+ match &= !((match_array[i] ^ *map++) & mask[i]);
+
+ of_node_put(new);
+ new = of_find_node_by_phandle(be32_to_cpup(map));
+ map++;
+ map_len--;
+
+ /* Check if not found */
+ if (!new)
+ goto put;
+
+ if (!of_device_is_available(new))
+ match = 0;
+
+ tmp = of_get_property(new, cells_name, NULL);
+ if (!tmp)
+ goto put;
+
+ new_size = be32_to_cpu(*tmp);
+
+ /* Check for malformed properties */
+ if (WARN_ON(new_size > MAX_PHANDLE_ARGS))
+ goto put;
+ if (map_len < new_size)
+ goto put;
+
+ /* Move forward by new node's #<list>-cells amount */
+ map += new_size;
+ map_len -= new_size;
+ }
+ if (!match)
+ goto put;
+
+ /* Get the <list>-map-pass-thru property (optional) */
+ pass = of_get_property(cur, pass_name, NULL);
+ if (!pass)
+ pass = dummy_pass;
+
+ /*
+ * Successfully parsed a <list>-map translation; copy new
+ * specifier into the out_args structure, keeping the
+ * bits specified in <list>-map-pass-thru.
+ */
+ match_array = map - new_size;
+ for (i = 0; i < new_size; i++) {
+ __be32 val = *(map - new_size + i);
+
+ if (i < list_size) {
+ val &= ~pass[i];
+ val |= cpu_to_be32(out_args->args[i]) & pass[i];
+ }
+
+ out_args->args[i] = be32_to_cpu(val);
+ }
+ out_args->args_count = list_size = new_size;
+ /* Iterate again with new provider */
+ out_args->np = new;
+ of_node_put(cur);
+ cur = new;
+ }
+put:
+ of_node_put(cur);
+ of_node_put(new);
+free:
+ kfree(mask_name);
+ kfree(map_name);
+ kfree(cells_name);
+ kfree(pass_name);
+
+ return ret;
+}
+EXPORT_SYMBOL(of_parse_phandle_with_args_map);
+
+/**
* of_parse_phandle_with_fixed_args() - Find a node pointed by phandle in a list
* @np: pointer to a device tree node containing a list
* @list_name: property name that contains a list
diff --git a/include/linux/of.h b/include/linux/of.h
index 011c4984cdf5..f22d4a83ca07 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -344,6 +344,9 @@ extern struct device_node *of_parse_phandle(const struct device_node *np,
extern int of_parse_phandle_with_args(const struct device_node *np,
const char *list_name, const char *cells_name, int index,
struct of_phandle_args *out_args);
+extern int of_parse_phandle_with_args_map(const struct device_node *np,
+ const char *list_name, const char *stem_name, int index,
+ struct of_phandle_args *out_args);
extern int of_parse_phandle_with_fixed_args(const struct device_node *np,
const char *list_name, int cells_count, int index,
struct of_phandle_args *out_args);
@@ -738,6 +741,15 @@ static inline int of_parse_phandle_with_args(const struct device_node *np,
return -ENOSYS;
}
+static inline int of_parse_phandle_with_args_map(const struct device_node *np,
+ const char *list_name,
+ const char *stem_name,
+ int index,
+ struct of_phandle_args *out_args)
+{
+ return -ENOSYS;
+}
+
static inline int of_parse_phandle_with_fixed_args(const struct device_node *np,
const char *list_name, int cells_count, int index,
struct of_phandle_args *out_args)
--
2.10.0.297.gf6727b0
^ permalink raw reply related
* [PATCH v2 2/3] of: unittest: Add phandle remapping test
From: Stephen Boyd @ 2017-01-18 0:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118005038.9216-1-stephen.boyd@linaro.org>
Test the functionality of of_parse_phandle_with_args_map().
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
---
drivers/of/unittest-data/testcases.dts | 11 +++
drivers/of/unittest-data/tests-phandle.dtsi | 25 ++++++
drivers/of/unittest.c | 120 ++++++++++++++++++++++++++++
3 files changed, 156 insertions(+)
diff --git a/drivers/of/unittest-data/testcases.dts b/drivers/of/unittest-data/testcases.dts
index 12f7c3d649c8..173b96f39cd0 100644
--- a/drivers/of/unittest-data/testcases.dts
+++ b/drivers/of/unittest-data/testcases.dts
@@ -26,12 +26,23 @@
/ { __local_fixups__ {
testcase-data {
phandle-tests {
+ provider4 {
+ phandle-map = <0x00000008 0x00000018
+ 0x00000024 0x0000003c
+ 0x00000050 0x00000064>;
+ };
consumer-a {
phandle-list = <0x00000000 0x00000008
0x00000018 0x00000028
0x00000034 0x00000038>;
phandle-list-bad-args = <0x00000000 0x0000000c>;
};
+ consumer-b {
+ phandle-list = <0x00000000 0x00000008
+ 0x00000018 0x00000024
+ 0x00000030 0x00000034>;
+ phandle-list-bad-args = <0x00000000 0x0000000c>;
+ };
};
interrupts {
intmap0 {
diff --git a/drivers/of/unittest-data/tests-phandle.dtsi b/drivers/of/unittest-data/tests-phandle.dtsi
index 5b1527e8a7fb..59e297f497d1 100644
--- a/drivers/of/unittest-data/tests-phandle.dtsi
+++ b/drivers/of/unittest-data/tests-phandle.dtsi
@@ -25,6 +25,18 @@
#phandle-cells = <3>;
};
+ provider4: provider4 {
+ #phandle-cells = <2>;
+ phandle-map = <0 1 &provider1 3>,
+ <4 0 &provider0>,
+ <16 5 &provider3 3 5 0>,
+ <200 8 &provider2 23 6>,
+ <19 0 &provider2 15 0>,
+ <2 3 &provider3 2 5 3>;
+ phandle-map-mask = <0xff 0xf>;
+ phandle-map-pass-thru = <0x0 0xf0>;
+ };
+
consumer-a {
phandle-list = <&provider1 1>,
<&provider2 2 0>,
@@ -43,6 +55,19 @@
unterminated-string = [40 41 42 43];
unterminated-string-list = "first", "second", [40 41 42 43];
};
+
+ consumer-b {
+ phandle-list = <&provider1 1>,
+ <&provider4 2 3>,
+ <0>,
+ <&provider4 4 0x100>,
+ <&provider4 0 0x61>,
+ <&provider0>,
+ <&provider4 19 0x20>;
+ phandle-list-bad-phandle = <12345678 0 0>;
+ phandle-list-bad-args = <&provider2 1 0>,
+ <&provider4 0>;
+ };
};
};
};
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 53c83d66eb7e..5baa40d0d83b 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -386,6 +386,125 @@ static void __init of_unittest_parse_phandle_with_args(void)
unittest(rc == -EINVAL, "expected:%i got:%i\n", -EINVAL, rc);
}
+static void __init of_unittest_parse_phandle_with_args_map(void)
+{
+ struct device_node *np, *p0, *p1, *p2, *p3;
+ struct of_phandle_args args;
+ int i, rc;
+
+ np = of_find_node_by_path("/testcase-data/phandle-tests/consumer-b");
+ if (!np) {
+ pr_err("missing testcase data\n");
+ return;
+ }
+
+ p0 = of_find_node_by_path("/testcase-data/phandle-tests/provider0");
+ if (!p0) {
+ pr_err("missing testcase data\n");
+ return;
+ }
+
+ p1 = of_find_node_by_path("/testcase-data/phandle-tests/provider1");
+ if (!p1) {
+ pr_err("missing testcase data\n");
+ return;
+ }
+
+ p2 = of_find_node_by_path("/testcase-data/phandle-tests/provider2");
+ if (!p2) {
+ pr_err("missing testcase data\n");
+ return;
+ }
+
+ p3 = of_find_node_by_path("/testcase-data/phandle-tests/provider3");
+ if (!p3) {
+ pr_err("missing testcase data\n");
+ return;
+ }
+
+ rc = of_count_phandle_with_args(np, "phandle-list", "#phandle-cells");
+ unittest(rc == 7, "of_count_phandle_with_args() returned %i, expected 7\n", rc);
+
+ for (i = 0; i < 8; i++) {
+ bool passed = true;
+
+ rc = of_parse_phandle_with_args_map(np, "phandle-list",
+ "phandle", i, &args);
+
+ /* Test the values from tests-phandle.dtsi */
+ switch (i) {
+ case 0:
+ passed &= !rc;
+ passed &= (args.np == p1);
+ passed &= (args.args_count == 1);
+ passed &= (args.args[0] == 1);
+ break;
+ case 1:
+ passed &= !rc;
+ passed &= (args.np == p3);
+ passed &= (args.args_count == 3);
+ passed &= (args.args[0] == 2);
+ passed &= (args.args[1] == 5);
+ passed &= (args.args[2] == 3);
+ break;
+ case 2:
+ passed &= (rc == -ENOENT);
+ break;
+ case 3:
+ passed &= !rc;
+ passed &= (args.np == p0);
+ passed &= (args.args_count == 0);
+ break;
+ case 4:
+ passed &= !rc;
+ passed &= (args.np == p1);
+ passed &= (args.args_count == 1);
+ passed &= (args.args[0] == 3);
+ break;
+ case 5:
+ passed &= !rc;
+ passed &= (args.np == p0);
+ passed &= (args.args_count == 0);
+ break;
+ case 6:
+ passed &= !rc;
+ passed &= (args.np == p2);
+ passed &= (args.args_count == 2);
+ passed &= (args.args[0] == 15);
+ passed &= (args.args[1] == 0x20);
+ break;
+ case 7:
+ passed &= (rc == -ENOENT);
+ break;
+ default:
+ passed = false;
+ }
+
+ unittest(passed, "index %i - data error on node %s rc=%i\n",
+ i, args.np->full_name, rc);
+ }
+
+ /* Check for missing list property */
+ rc = of_parse_phandle_with_args_map(np, "phandle-list-missing",
+ "phandle", 0, &args);
+ unittest(rc == -ENOENT, "expected:%i got:%i\n", -ENOENT, rc);
+
+ /* Check for missing cells,map,mask property */
+ rc = of_parse_phandle_with_args_map(np, "phandle-list",
+ "phandle-missing", 0, &args);
+ unittest(rc == -EINVAL, "expected:%i got:%i\n", -EINVAL, rc);
+
+ /* Check for bad phandle in list */
+ rc = of_parse_phandle_with_args_map(np, "phandle-list-bad-phandle",
+ "phandle", 0, &args);
+ unittest(rc == -EINVAL, "expected:%i got:%i\n", -EINVAL, rc);
+
+ /* Check for incorrectly formed argument list */
+ rc = of_parse_phandle_with_args_map(np, "phandle-list-bad-args",
+ "phandle", 1, &args);
+ unittest(rc == -EINVAL, "expected:%i got:%i\n", -EINVAL, rc);
+}
+
static void __init of_unittest_property_string(void)
{
const char *strings[4];
@@ -1951,6 +2070,7 @@ static int __init of_unittest(void)
of_unittest_find_node_by_name();
of_unittest_dynamic();
of_unittest_parse_phandle_with_args();
+ of_unittest_parse_phandle_with_args_map();
of_unittest_property_string();
of_unittest_property_copy();
of_unittest_changeset();
--
2.10.0.297.gf6727b0
^ permalink raw reply related
* [PATCH v2 3/3] gpio: Support gpio nexus dt bindings
From: Stephen Boyd @ 2017-01-18 0:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118005038.9216-1-stephen.boyd@linaro.org>
Platforms like 96boards have a standardized connector/expansion
slot that exposes signals like GPIOs to expansion boards in an
SoC agnostic way. We'd like the DT overlays for the expansion
boards to be written once without knowledge of the SoC on the
other side of the connector. This avoids the unscalable
combinatorial explosion of a different DT overlay for each
expansion board and SoC pair.
Now that we have nexus support in the OF core let's change the
function call here that parses the phandle lists of gpios to use
the nexus variant. This allows us to remap phandles and their
arguments through any number of nexus nodes and end up with the
actual gpio provider being used.
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
---
drivers/gpio/gpiolib-of.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 92b185f19232..17bca36d4ebb 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -75,8 +75,8 @@ struct gpio_desc *of_get_named_gpiod_flags(struct device_node *np,
struct gpio_desc *desc;
int ret;
- ret = of_parse_phandle_with_args(np, propname, "#gpio-cells", index,
- &gpiospec);
+ ret = of_parse_phandle_with_args_map(np, propname, "gpio", index,
+ &gpiospec);
if (ret) {
pr_debug("%s: can't parse '%s' property of node '%s[%d]'\n",
__func__, propname, np->full_name, index);
--
2.10.0.297.gf6727b0
^ permalink raw reply related
* [PATCH] ARM: dts: sun6i: sina31s: Enable USB OTG controller in peripheral mode
From: Chen-Yu Tsai @ 2017-01-18 1:01 UTC (permalink / raw)
To: linux-arm-kernel
While the SinA31s does have a proper 5-pin mini USB OTG port, the ID
pin does not seem to work. The pin used in the schematics is always low,
regardless of the attached OTG cable or SoC internal pin bias settings.
The v1.5 board is missing bias resistors shown in the schematics for
earlier revisions, and the connections of the remaining one does not
match the schematics either.
In addition, VBUS for this port is disconnected from the board's 5V
power rail. The board features a pad to solder jumper pins to connect
VBUS to 5V manually.
Given the above and the fact that the board has 5 more USB host ports,
it makes more sense to have the OTG port work in peripheral mode.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun6i-a31s-sina31s.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31s-sina31s.dts b/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
index 8743aeed1275..7ff68bdd7109 100644
--- a/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-sina31s.dts
@@ -153,6 +153,11 @@
regulator-name = "vcc-gmac-phy";
};
+&usb_otg {
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
&usbphy {
status = "okay";
};
--
2.11.0
^ permalink raw reply related
* [PATCH 2/2] ARM: BCM5301X: Add DT for Luxul XWR-1200
From: Florian Fainelli @ 2017-01-18 1:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484447368-7622-2-git-send-email-dhaab@luxul.com>
On 01/14/2017 06:29 PM, Dan Haab wrote:
> Luxul XWR-1200 in a dual-band router based on BCM47081. It uses serial
> flash (for bootloader and NVRAM) and NAND flash (for firmware).
>
> Signed-off-by: Dan Haab <dhaab@luxul.com>
Applied thanks
--
Florian
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox