* Re: [PATCH 2/2] memory: ti-emif-sram: introduce relocatable suspend/resume handlers
From: Russell King - ARM Linux @ 2017-04-06 19:00 UTC (permalink / raw)
To: Dave Gerlach
Cc: Tony Lindgren, Rob Herring, Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Keerthy J
In-Reply-To: <5cd63e14-52df-6010-4193-c926cdd76839-l0cyMroinI0@public.gmane.org>
On Wed, Apr 05, 2017 at 09:48:26AM -0500, Dave Gerlach wrote:
> Russell,
> On 04/05/2017 09:33 AM, Tony Lindgren wrote:
> >* Russell King - ARM Linux <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> [170405 07:02]:
> >>I'm not going to comment on this yet, but I'll instead comment on the
> >>newly appeared sram_exec_copy() stuff.
> >>
> >>So, a few years ago, we went to significant effort in ARM land to come
> >>up with a way to _safely_ copy assembler from the kernel into SRAM,
> >>because copying code to SRAM that is compiled in thumb mode and then
> >>executing it is _not_ as simple as memcpy(), cast the pointer to a
> >>function pointer, and then call the function pointer.
> >>
> >>The SRAM stuff throws all that out, instead preferring the dumb memcpy()
> >>approach.
> >>
> >>This needs resolving, and I'd like to see it resolved to the satisfaction
> >>of architecture maintainers before we progress any further down this
> >>route.
>
> I'm sure you are referring to fncpy, correct? This is what we used before
> with ARM specific code to do the copy, but we've moved into drivers now.
Right, and as I explained above, fncpy() exists with very good reason.
The following does not work on ARM:
sram = alloc(function_size);
memcpy(sram, function, function_size);
sram_ptr = (function_cast_t)sram;
sram_ptr(args);
when the function is Thumb. There are two problems with the above code
that fncpy() solves, both stemming from the same root cause:
1. The address of "function" will be offset by one byte, so the memcpy()
will miss copying the first byte of the function.
2. sram_ptr will not be offset by one byte.
This is because, with Thumb functions, the "address" of the function is
offset by one byte - by the architecture requirements - to indicate that
it is to be called in Thumb mode.
> What are your thoughts on exposing fncpy outside of arch/arm?
You may use it by including asm/fncpy.h, but you may not move it out of
that file. fncpy() is there exactly because it's _architecture_ specific.
If you're looking to make this generic, then we need cross-arch agreement
on how we can copy functions, and I'd recommend that fncpy() becomes that
generic copy function. fncpy() has advantages over memcpy() besides
encoding the architecture specific knowledge - the biggest one is that
it guarantees type safety as well. It ensures that the function pointer
that it's returning conforms with the function it's being asked to copy.
It strikes me, looking at the SRAM stuff, that the baby has been
completely thrown out with the bath water...
And really, this SRAM stuff _should_ have been through architecture
maintainer review before being merged into mainline so that these issues
could have been highlighted before hand.
This looks to me like yet another huge big review failure in kernel land,
because people are insistant on continually dividing stuff up by
sub-directory. This has got to stop.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] Extend pca9532 device tree support
From: Jacek Anaszewski @ 2017-04-06 19:00 UTC (permalink / raw)
To: Pavel Machek, Felix Brack
Cc: rpurdie-Fm38FmjxZ/leoWH0uzbU5w, mark.rutland-5wv7dgnIgG8,
riku.voipio-X3B1VOXEql0, linux-leds-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170406155005.GA10363@amd>
Hi Pavel,
On 04/06/2017 05:50 PM, Pavel Machek wrote:
> Hi!
>
>>> diff --git a/Documentation/devicetree/bindings/leds/leds-pca9532.txt b/Documentation/devicetree/bindings/leds/leds-pca9532.txt
>>> index 198f3ba..8374075 100644
>>> --- a/Documentation/devicetree/bindings/leds/leds-pca9532.txt
>>> +++ b/Documentation/devicetree/bindings/leds/leds-pca9532.txt
>>> @@ -17,6 +17,8 @@ Optional sub-node properties:
>>> - label: see Documentation/devicetree/bindings/leds/common.txt
>>> - type: Output configuration, see dt-bindings/leds/leds-pca9532.h (default NONE)
>>> - linux,default-trigger: see Documentation/devicetree/bindings/leds/common.txt
>>> + - default-state: see Documentation/devicetree/bindings/leds/common.txt
>>> + This property is only valid for sub-nodes of type <PCA9532_TYPE_LED>.
>>>
>>> Example:
>>> #include <dt-bindings/leds/leds-pca9532.h>
>>> @@ -33,6 +35,14 @@ Example:
>>> label = "pca:green:power";
>>> type = <PCA9532_TYPE_LED>;
>>> };
>>> + kernel-booting {
>>> + type = <PCA9532_TYPE_LED>;
>>> + default-state = "on";
>>> + };
>>> + sys-stat {
>>> + type = <PCA9532_TYPE_LED>;
>>> + default-state = "keep"; // don't touch, was set by U-Boot
>>> + };
>>
>> Adjusted above indentation to match the preceding lines.
>
>>> @@ -475,6 +494,16 @@ pca9532_of_populate_pdata(struct device *dev, struct device_node *np)
>>> of_property_read_u32(child, "type", &pdata->leds[i].type);
>>> of_property_read_string(child, "linux,default-trigger",
>>> &pdata->leds[i].default_trigger);
>>> + if (!of_property_read_string(child, "default-state", &state)) {
>>> + if (!strcmp(state, "on"))
>>> + pdata->leds[i].state = PCA9532_ON;
>>> + else if (!strcmp(state, "keep"))
>>> + pdata->leds[i].state = PCA9532_KEEP;
>>> + else if (!strcmp(state, "pwm0"))
>>> + pdata->leds[i].state = PCA9532_PWM0;
>>> + else if (!strcmp(state, "pwm1"))
>>> + pdata->leds[i].state = PCA9532_PWM1;
>>> + }
>>> if (++i >= maxleds) {
>>> of_node_put(child);
>>> break;
>
> This seems to look for "pwm0" and "pwm1" strings, which do not seem to
> be documented.
>
> Plus... is it useful to have default-state? We already have default
> trigger. If we keep the value by default (on PC, we do something like
> that) this patch should not be neccessary?
Thanks for the heads-up. Dropping the patch for now.
I guess that pwm0/1 got propagated to v2 by an omission.
Regarding default-on: Felix, do you have any use case that require
default-on set to "keep"?
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] memory: ti-emif-sram: introduce relocatable suspend/resume handlers
From: Dave Gerlach @ 2017-04-06 19:09 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Tony Lindgren, Rob Herring, Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Keerthy J
In-Reply-To: <20170406190008.GO23750-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
On 04/06/2017 02:00 PM, Russell King - ARM Linux wrote:
> On Wed, Apr 05, 2017 at 09:48:26AM -0500, Dave Gerlach wrote:
>> Russell,
>> On 04/05/2017 09:33 AM, Tony Lindgren wrote:
>>> * Russell King - ARM Linux <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> [170405 07:02]:
>>>> I'm not going to comment on this yet, but I'll instead comment on the
>>>> newly appeared sram_exec_copy() stuff.
>>>>
>>>> So, a few years ago, we went to significant effort in ARM land to come
>>>> up with a way to _safely_ copy assembler from the kernel into SRAM,
>>>> because copying code to SRAM that is compiled in thumb mode and then
>>>> executing it is _not_ as simple as memcpy(), cast the pointer to a
>>>> function pointer, and then call the function pointer.
>>>>
>>>> The SRAM stuff throws all that out, instead preferring the dumb memcpy()
>>>> approach.
>>>>
>>>> This needs resolving, and I'd like to see it resolved to the satisfaction
>>>> of architecture maintainers before we progress any further down this
>>>> route.
>>
>> I'm sure you are referring to fncpy, correct? This is what we used before
>> with ARM specific code to do the copy, but we've moved into drivers now.
>
> Right, and as I explained above, fncpy() exists with very good reason.
> The following does not work on ARM:
>
> sram = alloc(function_size);
>
> memcpy(sram, function, function_size);
>
> sram_ptr = (function_cast_t)sram;
>
> sram_ptr(args);
>
> when the function is Thumb. There are two problems with the above code
> that fncpy() solves, both stemming from the same root cause:
>
> 1. The address of "function" will be offset by one byte, so the memcpy()
> will miss copying the first byte of the function.
>
> 2. sram_ptr will not be offset by one byte.
>
> This is because, with Thumb functions, the "address" of the function is
> offset by one byte - by the architecture requirements - to indicate that
> it is to be called in Thumb mode.
Thanks for the explanation.
>
>> What are your thoughts on exposing fncpy outside of arch/arm?
>
> You may use it by including asm/fncpy.h, but you may not move it out of
> that file. fncpy() is there exactly because it's _architecture_ specific.
Yes agreed, and I already include asm/cacheflush.h for ARM arch to make use of
the set_memory_* APIs you helped extend.
>
> If you're looking to make this generic, then we need cross-arch agreement
> on how we can copy functions, and I'd recommend that fncpy() becomes that
> generic copy function. fncpy() has advantages over memcpy() besides
> encoding the architecture specific knowledge - the biggest one is that
> it guarantees type safety as well. It ensures that the function pointer
> that it's returning conforms with the function it's being asked to copy.
I agree with this, I sent a patch yesterday here [1] that uses fncpy instead of
memcpy. I also laid out the constraint that an arch will just need to define
fncpy that guarantees safe copy of a function in order to make use of the
sram_exec functionality. It is already only selected for CONFIG_ARM in Kconfig
because of the dependency on set_memory_* APIs.
[1] http://www.spinics.net/lists/linux-omap/msg136517.html
>
> It strikes me, looking at the SRAM stuff, that the baby has been
> completely thrown out with the bath water...
>
> And really, this SRAM stuff _should_ have been through architecture
> maintainer review before being merged into mainline so that these issues
> could have been highlighted before hand.
>
> This looks to me like yet another huge big review failure in kernel land,
> because people are insistant on continually dividing stuff up by
> sub-directory. This has got to stop.
>
This just seemed like a logical place for me to add this as executable SRAM is a
shared resource and if the generic sram driver is handling allocation of memory
regions it should handle the page attributes of these regions as well.
Regards,
Dave
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V10 06/12] of: device: Fix overflow of coherent_dma_mask
From: Frank Rowand @ 2017-04-06 19:24 UTC (permalink / raw)
To: Robin Murphy, Sricharan R, will.deacon, joro, lorenzo.pieralisi,
iommu, linux-arm-kernel, linux-arm-msm, m.szyprowski, bhelgaas,
linux-pci, linux-acpi, tn, hanjun.guo, okaya, robh+dt, devicetree,
linux-kernel, sudeep.holla, rjw, lenb, catalin.marinas, arnd,
linux-arch, gregkh
In-Reply-To: <b081f333-084d-ffa5-635f-f7f1c0232ac3@arm.com>
On 04/06/17 03:24, Robin Murphy wrote:
> On 06/04/17 08:01, Frank Rowand wrote:
>> On 04/04/17 03:18, Sricharan R wrote:
>>> Size of the dma-range is calculated as coherent_dma_mask + 1
>>> and passed to arch_setup_dma_ops further. It overflows when
>>> the coherent_dma_mask is set for full 64 bits 0xFFFFFFFFFFFFFFFF,
>>> resulting in size getting passed as 0 wrongly. Fix this by
>>> passsing in max(mask, mask + 1). Note that in this case
>>> when the mask is set to full 64bits, we will be passing the mask
>>> itself to arch_setup_dma_ops instead of the size. The real fix
>>> for this should be to make arch_setup_dma_ops receive the
>>> mask and handle it, to be done in the future.
>>>
>>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>>> ---
>>> drivers/of/device.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>>> index c17c19d..c2ae6bb 100644
>>> --- a/drivers/of/device.c
>>> +++ b/drivers/of/device.c
>>> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>>> ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>>> if (ret < 0) {
>>> dma_addr = offset = 0;
>>> - size = dev->coherent_dma_mask + 1;
>>> + size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>>> } else {
>>> offset = PFN_DOWN(paddr - dma_addr);
>>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
>>>
>>
>> NACK.
>>
>> Passing an invalid size to arch_setup_dma_ops() is only part of the problem.
>> size is also used in of_dma_configure() before calling arch_setup_dma_ops():
>>
>> dev->coherent_dma_mask = min(dev->coherent_dma_mask,
>> DMA_BIT_MASK(ilog2(dma_addr + size)));
>> *dev->dma_mask = min((*dev->dma_mask),
>> DMA_BIT_MASK(ilog2(dma_addr + size)));
>>
>> which would be incorrect for size == 0xffffffffffffffffULL when
>> dma_addr != 0. So the proposed fix really is not papering over
>> the base problem very well.
>
> I'm not sure I agree there. Granted, there exist many more problematic
> aspects than are dealt with here (I've got more patches cooking to sort
> out some of the other issues we have with dma-ranges), but considering
> size specifically:
>
> - It is not possible to explicitly specify a range with a size of 2^64
> in DT. If someone does specify a size of 0, they've done a silly thing
> and should not be surprised that it ends badly.
>
> - It *is* perfectly legitimate for bus code (or a previous device
> driver, once we start coming here at probe time) to have set a device's
> DMA mask to 0xffffffffffffffffULL. If this code then blindly overflows
> and infers an invalid size of 0 from that, breaking things in the
> process, that is this code's fault alone. It just so happens that
> nothing managed to trigger the latent problem until patch #7 here shakes
> up the callsites.
The existing code that uses size does not appear capable of dealing with
the case of DMA mask of 0xffffffffffffffffULL since 2^64 does not fit
into size.
The code affected by the DMA mask is not within my area of knowledge, so
take the following with a grain of salt. If a DMA mask of
0xffffffffffffffffULL is provided, would the code still work without error
(though with reduced capability) if the mask was changed to
0xefffffffffffffffULL? I would guess that the location to do so would
be where dev->coherent_dma_mask is set, or some other location that
is not of_dma_configure(). This would just be a temporary workaround.
> Yes, wacky impossible base + size combinations in DT were a theoretical
> problem before, and remain a theoretical problem, but also fall into the
> "how did you ever expect this to work?" category. There's certainly
> plenty more we can do to improve the DT parsing/validation, but that
> still doesn't apply to this path where the information is *not* coming
> from the DT at all.
>
>> I agree that the proper solution involves passing a mask instead
>> of a size to arch_setup_dma_ops().
>
> Having started writing that patch too, I can tell you it's a big bugger
> touching multiple architectures and fixing up various drivers doing
> stupid things, hence why I'm happy with this point fix being the lesser
> of two evils in terms of not holding up this mostly-orthogonal series.
>
> Robin.
>
>>
>> -Frank
>>
>
>
^ permalink raw reply
* [PATCH] of: Make of_match_node() an inline stub for CONFIG_OF=n
From: Florian Fainelli @ 2017-04-06 19:32 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: andrew-g2DYL2Zd6BY,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/, Florian Fainelli,
Rob Herring, Frank Rowand,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE
Make of_match_node() an inline function when CONFIG_OF=n which allows the
compiler to eliminate warnings about unused variables.
Suggested-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
include/linux/of.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index 21e6323de0f3..2803a85e81ec 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -839,7 +839,11 @@ static inline void of_property_clear_flag(struct property *p, unsigned long flag
}
#define of_match_ptr(_ptr) NULL
-#define of_match_node(_matches, _node) NULL
+static inline const struct of_device_id *of_match_node(
+ const struct of_device_id *matches, const struct device_node *node)
+{
+ return NULL;
+}
#endif /* CONFIG_OF */
/* Default string compare functions, Allow arch asm/prom.h to override */
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH V10 06/12] of: device: Fix overflow of coherent_dma_mask
From: Frank Rowand @ 2017-04-06 19:34 UTC (permalink / raw)
To: Sricharan R, robin.murphy-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
joro-zLv9SwRftAIdnm+yROfE0A, lorenzo.pieralisi-5wv7dgnIgG8,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, tn-nYOzD4b6Jr9Wk0Htik3J/w,
hanjun.guo-QSEj5FYQhm4dnm+yROfE0A, okaya-sgV2jX0FEOL9JmXXK+q4OQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, sudeep.holla-5wv7dgnIgG8,
rjw-LthD3rsA81gm4RdzfppkhA, lenb-DgEjT+Ai2ygdnm+yROfE0A,
catalin.marinas-5wv7dgnIgG8, arnd-r2nGTMty4D4,
linux-arch-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
In-Reply-To: <b77e3405-f060-bcd5-99f6-7d76f9edf08a-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 04/06/17 04:01, Sricharan R wrote:
> Hi Frank,
>
> On 4/6/2017 12:31 PM, Frank Rowand wrote:
>> On 04/04/17 03:18, Sricharan R wrote:
>>> Size of the dma-range is calculated as coherent_dma_mask + 1
>>> and passed to arch_setup_dma_ops further. It overflows when
>>> the coherent_dma_mask is set for full 64 bits 0xFFFFFFFFFFFFFFFF,
>>> resulting in size getting passed as 0 wrongly. Fix this by
>>> passsing in max(mask, mask + 1). Note that in this case
>>> when the mask is set to full 64bits, we will be passing the mask
>>> itself to arch_setup_dma_ops instead of the size. The real fix
>>> for this should be to make arch_setup_dma_ops receive the
>>> mask and handle it, to be done in the future.
>>>
>>> Signed-off-by: Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>> ---
>>> drivers/of/device.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>>> index c17c19d..c2ae6bb 100644
>>> --- a/drivers/of/device.c
>>> +++ b/drivers/of/device.c
>>> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>>> ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>>> if (ret < 0) {
>>> dma_addr = offset = 0;
>>> - size = dev->coherent_dma_mask + 1;
>>> + size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>>> } else {
>>> offset = PFN_DOWN(paddr - dma_addr);
>>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
>>>
>>
>> NACK.
>>
>> Passing an invalid size to arch_setup_dma_ops() is only part of the problem.
>> size is also used in of_dma_configure() before calling arch_setup_dma_ops():
>>
>> dev->coherent_dma_mask = min(dev->coherent_dma_mask,
>> DMA_BIT_MASK(ilog2(dma_addr + size)));
>> *dev->dma_mask = min((*dev->dma_mask),
>> DMA_BIT_MASK(ilog2(dma_addr + size)));
>>
>> which would be incorrect for size == 0xffffffffffffffffULL when
>> dma_addr != 0. So the proposed fix really is not papering over
>> the base problem very well.
>>
>
> Ok, but with your fix for of_dma_get_range and the above fix,
> dma_addr will be '0' when size = 0xffffffffffffffffULL,
> but DMA_BIT_MASK(ilog2(dma_addr + size)) would be wrong though,
> making coherent_dma_mask to be smaller 0x7fffffffffffffffULL.
Yes, that was my point. Setting size to 0x7fffffffffffffffULL
affects several places. Another potential location (based only
on the function header comment, not from reading the code) is
iommu_dma_init_domain(). The header comment says:
* @base and @size should be exact multiples of IOMMU page granularity to
* avoid rounding surprises.
I have not read enough context to really understand of_dma_configure(), but
it seems there is yet another issue in how the error return case from
of_dma_get_range() is handled (with the existing code, as well as if
my patch gets accepted). An error return value can mean _either_
there is no dma-ranges property _or_ "an other problem occurred". Should
the "an other problem occurred" case be handled by defaulting size to
a value based on dev->coherent_dma_mask (the current case) or should the
attempt to set up the DMA configuration just fail?
>
> Regards,
> Sricharan
>
>> I agree that the proper solution involves passing a mask instead
>> of a size to arch_setup_dma_ops().
>>
>
^ permalink raw reply
* Re: [PATCH] of: Make of_match_node() an inline stub for CONFIG_OF=n
From: Andrew Lunn @ 2017-04-06 19:54 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/, Rob Herring,
Frank Rowand, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE
In-Reply-To: <20170406193224.10046-1-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Apr 06, 2017 at 12:32:24PM -0700, Florian Fainelli wrote:
> Make of_match_node() an inline function when CONFIG_OF=n which allows the
> compiler to eliminate warnings about unused variables.
>
> Suggested-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Thanks Florian,
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 2/2] i2c: mux: ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: Peter Rosin @ 2017-04-06 20:03 UTC (permalink / raw)
To: michael.hennerich-OyLXuOCK7orQT0dZR+AlfA,
wsa-z923LK4zBo2bacvFa/9K2g, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linus.walleij-QSEj5FYQhm4dnm+yROfE0A
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <376f970f-9e0f-1d44-3813-93691c849b83-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
On 2017-04-06 13:31, Michael Hennerich wrote:
> On 06.04.2017 10:39, Peter Rosin wrote:
>> Hi Michael,
>>
>> I would still like to hear from someone with more gpio experience.
>
> I'll ping Linus.
>
>>
>> Anyway, from my point of view, there's just a few minor things left,
>> with comments inline as usual.
>>
>> Thanks for you patience!
s/you/your/
>
> Thanks for review.
>
>>
>> Cheers,
>> peda
>>
>> On 2017-04-05 15:07, michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org wrote:
>>> From: Michael Hennerich <michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
>>>
>>> This patch adds support for the Analog Devices / Linear Technology
>>> LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches.
>>> The LTC4306 optionally provides two general purpose input/output pins
>>> (GPIOs) that can be configured as logic inputs, opendrain outputs or
>>> push-pull outputs via the generic GPIOLIB framework.
>>>
>>> Signed-off-by: Michael Hennerich <michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
>>>
>>> ---
>>>
>>> Changes since v1:
>>>
>>> - Sort makefile entries
>>> - Sort driver includes
>>> - Use proper defines
>>> - Miscellaneous coding style fixups
>>> - Rename mux select callback
>>> - Revise i2c-mux-idle-disconnect handling
>>> - Add ENABLE GPIO handling on error and device removal.
>>> - Remove surplus of_match_device call.
>>>
>>> Changes since v2:
>>>
>>> - Stop double error reporting (i2c_mux_add_adapter)
>>> - Change subject
>>> - Split dt bindings to separate patch
>>>
>>> Changes since v3:
>>>
>>> - Change subject and add spaces
>>> - Convert to I2C_MUX_LOCKED
>>> - Convert to regmap
>>> - Remove local register cache
>>> - Restore previous ENABLE GPIO handling
>>> - Initially pulse ENABLE low
>>> - Eliminate i2c client struct in driver state structure
>>> - Simplify error return path
>>> - Misc minor cleanups
>>> ---
>>> MAINTAINERS | 8 +
>>> drivers/i2c/muxes/Kconfig | 11 ++
>>> drivers/i2c/muxes/Makefile | 1 +
>>> drivers/i2c/muxes/i2c-mux-ltc4306.c | 310 ++++++++++++++++++++++++++++++++++++
>>> 4 files changed, 330 insertions(+)
>>> create mode 100644 drivers/i2c/muxes/i2c-mux-ltc4306.c
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index c776906..9a27a19 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -7698,6 +7698,14 @@ S: Maintained
>>> F: Documentation/hwmon/ltc4261
>>> F: drivers/hwmon/ltc4261.c
>>>
>>> +LTC4306 I2C MULTIPLEXER DRIVER
>>> +M: Michael Hennerich <michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
>>> +W: http://ez.analog.com/community/linux-device-drivers
>>> +L: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> +S: Supported
>>> +F: drivers/i2c/muxes/i2c-mux-ltc4306.c
>>> +F: Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
>>> +
>>> LTP (Linux Test Project)
>>> M: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
>>> M: Cyril Hrubis <chrubis-AlSwsSmVLrQ@public.gmane.org>
>>> diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
>>> index 10b3d17..41153b4 100644
>>> --- a/drivers/i2c/muxes/Kconfig
>>> +++ b/drivers/i2c/muxes/Kconfig
>>> @@ -30,6 +30,17 @@ config I2C_MUX_GPIO
>>> This driver can also be built as a module. If so, the module
>>> will be called i2c-mux-gpio.
>>>
>>> +config I2C_MUX_LTC4306
>>> + tristate "LTC LTC4306/5 I2C multiplexer"
>>> + select GPIOLIB
>>> + select REGMAP_I2C
>>> + help
>>> + If you say yes here you get support for the LTC LTC4306 or LTC4305
>>
>> This reads a bit funny, and I think you should just spell out the
>> first LTC? But perhaps not in the tristate above though, depending
>> on how long it gets?
>
> Ok - I rename LTC -> Analog Devices
>
>>
>>> + I2C mux/switch devices.
>>> +
>>> + This driver can also be built as a module. If so, the module
>>> + will be called i2c-mux-ltc4306.
>>> +
>>> config I2C_MUX_PCA9541
>>> tristate "NXP PCA9541 I2C Master Selector"
>>> help
>>> diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
>>> index 9948fa4..ff7618c 100644
>>> --- a/drivers/i2c/muxes/Makefile
>>> +++ b/drivers/i2c/muxes/Makefile
>>> @@ -6,6 +6,7 @@ obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE) += i2c-arb-gpio-challenge.o
>>> obj-$(CONFIG_I2C_DEMUX_PINCTRL) += i2c-demux-pinctrl.o
>>>
>>> obj-$(CONFIG_I2C_MUX_GPIO) += i2c-mux-gpio.o
>>> +obj-$(CONFIG_I2C_MUX_LTC4306) += i2c-mux-ltc4306.o
>>> obj-$(CONFIG_I2C_MUX_MLXCPLD) += i2c-mux-mlxcpld.o
>>> obj-$(CONFIG_I2C_MUX_PCA9541) += i2c-mux-pca9541.o
>>> obj-$(CONFIG_I2C_MUX_PCA954x) += i2c-mux-pca954x.o
>>> diff --git a/drivers/i2c/muxes/i2c-mux-ltc4306.c b/drivers/i2c/muxes/i2c-mux-ltc4306.c
>>> new file mode 100644
>>> index 0000000..7d34434
>>> --- /dev/null
>>> +++ b/drivers/i2c/muxes/i2c-mux-ltc4306.c
>>> @@ -0,0 +1,310 @@
>>> +/*
>>> + * Linear Technology LTC4306 and LTC4305 I2C multiplexer/switch
>>> + *
>>> + * Copyright (C) 2017 Analog Devices Inc.
>>> + *
>>> + * Licensed under the GPL-2.
>>> + *
>>> + * Based on: i2c-mux-pca954x.c
>>> + *
>>> + * Datasheet: http://cds.linear.com/docs/en/datasheet/4306.pdf
>>> + */
>>> +
>>> +#include <linux/device.h>
>>> +#include <linux/gpio.h>
>>> +#include <linux/gpio/consumer.h>
>>> +#include <linux/gpio/driver.h>
>>> +#include <linux/i2c-mux.h>
>>> +#include <linux/i2c.h>
>>> +#include <linux/module.h>
>>> +#include <linux/of.h>
>>> +#include <linux/of_device.h>
>>> +#include <linux/regmap.h>
>>> +#include <linux/slab.h>
>>> +
>>> +#define LTC4305_MAX_NCHANS 2
>>> +#define LTC4306_MAX_NCHANS 4
>>> +
>>> +#define LTC_REG_STATUS 0x0
>>> +#define LTC_REG_CONFIG 0x1
>>> +#define LTC_REG_MODE 0x2
>>> +#define LTC_REG_SWITCH 0x3
>>> +
>>> +#define LTC_DOWNSTREAM_ACCL_EN BIT(6)
>>> +#define LTC_UPSTREAM_ACCL_EN BIT(7)
>>> +
>>> +#define LTC_GPIO_ALL_INPUT 0xC0
>>> +#define LTC_SWITCH_MASK 0xF0
>>> +
>>> +enum ltc_type {
>>> + ltc_4305,
>>> + ltc_4306,
>>> +};
>>> +
>>> +struct chip_desc {
>>> + u8 nchans;
>>> + u8 num_gpios;
>>> +};
>>> +
>>> +struct ltc4306 {
>>> + struct regmap *regmap;
>>> + struct gpio_chip gpiochip;
>>> + const struct chip_desc *chip;
>>> +};
>>> +
>>> +static const struct chip_desc chips[] = {
>>> + [ltc_4305] = {
>>> + .nchans = LTC4305_MAX_NCHANS,
>>> + },
>>> + [ltc_4306] = {
>>> + .nchans = LTC4306_MAX_NCHANS,
>>> + .num_gpios = 2,
>>> + },
>>> +};
>>> +
>>> +static bool ltc4306_is_volatile_reg(struct device *dev, unsigned int reg)
>>> +{
>>> + return (reg == LTC_REG_CONFIG) ? true : false;
>>> +}
>>> +
>>> +static const struct regmap_config ltc4306_regmap_config = {
>>> + .reg_bits = 8,
>>> + .val_bits = 8,
>>> + .max_register = LTC_REG_SWITCH,
>>> + .volatile_reg = ltc4306_is_volatile_reg,
>>> + .cache_type = REGCACHE_RBTREE,
>>
>> Did you consider REGCACHE_FLAT? There are very few registers and no hole
>> in the map, and maintaining a tree seems like total overkill.
>
> There is no reason to use REGCACHE_FLAT, in our case it will be a single
> node.
Ok, so that makes me wonder what need REGCACHE_FLAT satisfies? To me,
a flat regmap seems like a perfect fit here. Oh well...
>>
>>> +};
>>> +
>>> +static int ltc4306_gpio_get(struct gpio_chip *chip, unsigned int offset)
>>> +{
>>> + struct ltc4306 *data = gpiochip_get_data(chip);
>>> + unsigned int val;
>>> + int ret;
>>> +
>>> + ret = regmap_read(data->regmap, LTC_REG_CONFIG, &val);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + return (val & BIT(1 - offset));
>>
>> The outer parentheses do not add anything, and I think they might remain
>> from when you just removed a double negation at some point. But is it
>> good practice to indicate "high" with anything other than one? Sure, the
>> gpiolib function that wraps the ->get() op does the !! dance for you,
>> but even so, every single one of the half dozen random gpio providers I
>> looked at had code to coerce the value to 0/1 (or error). Which makes me
>> think you should also have it. And the gpio_chip documentation on ->get()
>> agrees with me...
>
> I'll restore the double negations.
Thanks!
>>
>>> +}
>>> +
>>> +static void ltc4306_gpio_set(struct gpio_chip *chip, unsigned int offset,
>>> + int value)
>>> +{
>>> + struct ltc4306 *data = gpiochip_get_data(chip);
>>> +
>>> + regmap_update_bits(data->regmap, LTC_REG_CONFIG, BIT(5 - offset),
>>> + value ? BIT(5 - offset) : 0);
>>> +}
>>> +
>>> +static int ltc4306_gpio_direction_input(struct gpio_chip *chip,
>>> + unsigned int offset)
>>> +{
>>> + struct ltc4306 *data = gpiochip_get_data(chip);
>>> +
>>> + return regmap_update_bits(data->regmap, LTC_REG_MODE,
>>> + BIT(7 - offset), BIT(7 - offset));
>>> +}
>>> +
>>> +static int ltc4306_gpio_direction_output(struct gpio_chip *chip,
>>> + unsigned int offset, int value)
>>> +{
>>> + struct ltc4306 *data = gpiochip_get_data(chip);
>>> +
>>> + ltc4306_gpio_set(chip, offset, value);
>>> + return regmap_update_bits(data->regmap, LTC_REG_MODE,
>>> + BIT(7 - offset), 0);
>>> +}
>>> +
>>> +static int ltc4306_gpio_set_config(struct gpio_chip *chip,
>>> + unsigned int offset, unsigned long config)
>>> +{
>>> + struct ltc4306 *data = gpiochip_get_data(chip);
>>> + unsigned int val;
>>> +
>>> + switch (pinconf_to_config_param(config)) {
>>> + case PIN_CONFIG_DRIVE_OPEN_DRAIN:
>>> + val = 0;
>>> + break;
>>> + case PIN_CONFIG_DRIVE_PUSH_PULL:
>>> + val = BIT(4 - offset);
>>> + break;
>>> + default:
>>> + return -ENOTSUPP;
>>> + }
>>> +
>>> + return regmap_update_bits(data->regmap, LTC_REG_MODE,
>>> + BIT(4 - offset), val);
>>> +}
>>> +
>>> +static int ltc4306_gpio_init(struct ltc4306 *data)
>>> +{
>>> + struct device *dev = regmap_get_device(data->regmap);
>>> +
>>> + if (!data->chip->num_gpios)
>>> + return 0;
>>> +
>>> + data->gpiochip.label = dev_name(dev);
>>> + data->gpiochip.base = -1;
>>> + data->gpiochip.ngpio = data->chip->num_gpios;
>>> + data->gpiochip.parent = dev;
>>> + data->gpiochip.can_sleep = true;
>>> + data->gpiochip.direction_input = ltc4306_gpio_direction_input;
>>> + data->gpiochip.direction_output = ltc4306_gpio_direction_output;
>>
>> I'm missing a get_direction op?
>
> No - its purely optional - the vast majority of gpiochips don't
> implement it.
>
> linux/drivers/gpio$ grep -lr --include \*.c get_direction | wc
> 36 36 523
> linux/drivers/gpio$ grep -Lr --include \*.c get_direction | wc
> 101 101 1461
Ok, but while optional, why not provide it? The implementation would
be about as simple as ltc4306_gpio_get, no?
>>
>>> + data->gpiochip.get = ltc4306_gpio_get;
>>> + data->gpiochip.set = ltc4306_gpio_set;
>>> + data->gpiochip.set_config = ltc4306_gpio_set_config;
>>> + data->gpiochip.owner = THIS_MODULE;
>>> +
>>> + /* gpiolib assumes all GPIOs default input */
>>> + regmap_write(data->regmap, LTC_REG_MODE, LTC_GPIO_ALL_INPUT);
>>> +
>>> + return devm_gpiochip_add_data(dev, &data->gpiochip, data);
>>> +}
>>> +
>>> +static int ltc4306_select_mux(struct i2c_mux_core *muxc, u32 chan)
>>> +{
>>> + struct ltc4306 *data = i2c_mux_priv(muxc);
>>> +
>>> + return regmap_update_bits(data->regmap, LTC_REG_SWITCH,
>>> + LTC_SWITCH_MASK, BIT(7 - chan));
>>
>> Since the bits outside the mask are ignored for writes, I'd go with
>> regmap_write. Especially since those bits are volatile, which admittedly
>> will not have much impact until there is a need to read those volatile
>> bits outside the mask. But still.
>
> Yes they are volatile - but not declared as such.
> So regmap cache just ignores them.
> And we totally ignore these RONLY status bits, too.
Of course. I was referring to future changes that would perhaps
need to get at those status bits.
> regmap_write() will always write and ignore the cache, while
> regmap_update_bits() uses the cached value.
Ah, I was not aware of that.
> Are these callbacks guaranteed to be never called with the same CHAN
> sequentially? if yes - use regmap_write() otherwise its more efficient
> to use regmap_update_bits().
If you have the mux disconnect on idle, then yes, we are guaranteed
to not call with the same "CHAN". But, if not disconnecting and given
the above, it is more efficient to rely on the cache given the above
properties of regmap. So, let's do it your way and keep update_bits
and worry about volatile etc when/if it happens.
Ok, move on, nothing to see. And thanks for explaining.
Cheers,
peda
>>
>>> +}
>>> +
>>> +static int ltc4306_deselect_mux(struct i2c_mux_core *muxc, u32 chan)
>>> +{
>>> + struct ltc4306 *data = i2c_mux_priv(muxc);
>>> +
>>> + return regmap_update_bits(data->regmap, LTC_REG_SWITCH,
>>> + LTC_SWITCH_MASK, 0);
>>
>> Dito.
>>
>>> +}
>>> +
>>> +static const struct i2c_device_id ltc4306_id[] = {
>>> + { "ltc4305", ltc_4305 },
>>> + { "ltc4306", ltc_4306 },
>>> + { }
>>> +};
>>> +MODULE_DEVICE_TABLE(i2c, ltc4306_id);
>>> +
>>> +static const struct of_device_id ltc4306_of_match[] = {
>>> + { .compatible = "lltc,ltc4305", .data = &chips[ltc_4305] },
>>> + { .compatible = "lltc,ltc4306", .data = &chips[ltc_4306] },
>>> + { }
>>> +};
>>> +MODULE_DEVICE_TABLE(of, ltc4306_of_match);
>>> +
>>> +static int ltc4306_probe(struct i2c_client *client,
>>> + const struct i2c_device_id *id)
>>> +{
>>> + struct i2c_adapter *adap = to_i2c_adapter(client->dev.parent);
>>> + struct device_node *of_node = client->dev.of_node;
>>> + struct i2c_mux_core *muxc;
>>> + struct ltc4306 *data;
>>> + struct gpio_desc *gpio;
>>> + bool idle_disc = false;
>>> + int num, ret;
>>> +
>>> + if (of_node)
>>> + idle_disc = of_property_read_bool(of_node,
>>> + "i2c-mux-idle-disconnect");
>>> +
>>> + muxc = i2c_mux_alloc(adap, &client->dev,
>>> + LTC4306_MAX_NCHANS, sizeof(*data),
>>
>> Hmmm, I didn't see this before, but if you do some more rearranging, it
>> should be possible to replace LTC4306_MAX_NCHANS with data->chip->nchans
>> and reduce resource waste for ltc4305. But it's just storage for two
>> pointers which is really really minor... Feel free to ignore.
>>
>> But you want to set a good example, right :-)
>>
>>> + I2C_MUX_LOCKED, ltc4306_select_mux,
>>> + idle_disc ? ltc4306_deselect_mux : NULL);
>>> + if (!muxc)
>>> + return -ENOMEM;
>>> + data = i2c_mux_priv(muxc);
>>> +
>>> + i2c_set_clientdata(client, muxc);
>>> +
>>> + data->regmap = devm_regmap_init_i2c(client, <c4306_regmap_config);
>>> + if (IS_ERR(data->regmap)) {
>>> + ret = PTR_ERR(data->regmap);
>>> + dev_err(&client->dev, "Failed to allocate register map: %d\n",
>>> + ret);
>>> + return ret;
>>> + }
>>> +
>>> + /* Reset and enable the mux if an enable GPIO is specified. */
>>> + gpio = devm_gpiod_get_optional(&client->dev, "enable", GPIOD_OUT_LOW);
>>> + if (IS_ERR(gpio))
>>> + return PTR_ERR(gpio);
>>> +
>>> + if (gpio) {
>>> + udelay(1);
>>> + gpiod_set_value(gpio, 1);
>>> + }
>>> +
>>> + /*
>>> + * Write the mux register at addr to verify
>>> + * that the mux is in fact present. This also
>>> + * initializes the mux to disconnected state.
>>> + */
>>> + if (regmap_write(data->regmap, LTC_REG_SWITCH, 0) < 0) {
>>> + dev_warn(&client->dev, "probe failed\n");
>>> + return -ENODEV;
>>> + }
>>> +
>>> + if (of_node) {
>>> + unsigned int val = 0;
>>> +
>>> + data->chip = of_device_get_match_data(&client->dev);
>>> +
>>> + if (of_property_read_bool(of_node,
>>> + "ltc,downstream-accelerators-enable"))
>>> + val |= LTC_DOWNSTREAM_ACCL_EN;
>>> +
>>> + if (of_property_read_bool(of_node,
>>> + "ltc,upstream-accelerators-enable"))
>>> + val |= LTC_UPSTREAM_ACCL_EN;
>>> +
>>> + if (regmap_write(data->regmap, LTC_REG_CONFIG, val) < 0)
>>> + return -ENODEV;
>>> + } else {
>>> + data->chip = &chips[id->driver_data];
>>> + }
>>> +
>>> + ret = ltc4306_gpio_init(data);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + /* Now create an adapter for each channel */
>>> + for (num = 0; num < data->chip->nchans; num++) {
>>> + ret = i2c_mux_add_adapter(muxc, 0, num, 0);
>>> + if (ret) {
>>> + i2c_mux_del_adapters(muxc);
>>> + return ret;
>>> + }
>>> + }
>>> +
>>> + dev_info(&client->dev,
>>> + "registered %d multiplexed busses for I2C switch %s\n",
>>> + num, client->name);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int ltc4306_remove(struct i2c_client *client)
>>> +{
>>> + struct i2c_mux_core *muxc = i2c_get_clientdata(client);
>>> +
>>> + i2c_mux_del_adapters(muxc);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static struct i2c_driver ltc4306_driver = {
>>> + .driver = {
>>> + .name = "ltc4306",
>>> + .of_match_table = of_match_ptr(ltc4306_of_match),
>>> + },
>>> + .probe = ltc4306_probe,
>>> + .remove = ltc4306_remove,
>>> + .id_table = ltc4306_id,
>>> +};
>>> +
>>> +module_i2c_driver(ltc4306_driver);
>>> +
>>> +MODULE_AUTHOR("Michael Hennerich <michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>");
>>> +MODULE_DESCRIPTION("Linear Technology LTC4306, LTC4305 I2C mux/switch driver");
>>> +MODULE_LICENSE("GPL v2");
>>>
>>
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/2] mtd: spi-nor: add stm32 qspi driver
From: Cyrille Pitchen @ 2017-04-06 20:07 UTC (permalink / raw)
To: Marek Vasut, Ludovic BARRE, Cyrille Pitchen
Cc: Boris Brezillon, Alexandre Torgue, devicetree, Richard Weinberger,
linux-kernel, Rob Herring, linux-mtd, Brian Norris,
David Woodhouse
In-Reply-To: <e04fa293-63d4-7a7e-a998-37aab31167e5@gmail.com>
Hi all,
Le 30/03/2017 à 12:15, Marek Vasut a écrit :
> On 03/30/2017 09:31 AM, Ludovic BARRE wrote:
>> hi Cyrille
>>
>> I see your patch series
>>
>> [PATCH v5 0/6] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories
>>
>> No problem, I rebase my V2 onto your patch
>
> I still didn't review that, so it might take a bit until it hits
> mainline. I think the stm32 stuff looks pretty OK, so we can take that
> before the SFDP stuff, no?
>
About the SFDP patches they are still RFC so yes, they can wait, no
problem with that. Anyway I was working on them this afternoon so they
are not finalized yet.
However the first 3 patches of the series, especially patch
"mtd: spi-nor: introduce more SPI protocols and the Dual Transfer Mode",
are needed as a base to fix other long time pending issues.
Those patches are available from both the github/spi-nor and linux-next
tree. So I think Ludovic can rebase his patches, test them then send v3
to the linux-mtd mailing list with the relevant ChangeLog in the cover
letter.
For your information:
2016-06-20 https://patchwork.ozlabs.org/patch/638138/
2016-10-04 https://patchwork.ozlabs.org/patch/678162/
2016-10-05 https://patchwork.ozlabs.org/patch/678404/
2016-10-24 https://patchwork.ozlabs.org/patch/685981/
2016-11-21 https://patchwork.ozlabs.org/patch/697268/
2017-01-25 https://patchwork.ozlabs.org/patch/719777/
2017-03-22 https://patchwork.ozlabs.org/patch/742376/
Sorry but I think the patch changing the 3rd argument of spi_nor_scan()
has precedence over newer patches in the queue to be mainlined.
Best regards,
Cyrille
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v3 07/12] clk: mediatek: add clk support for MT6797
From: Stephen Boyd @ 2017-04-06 20:08 UTC (permalink / raw)
To: Mars Cheng
Cc: Matthias Brugger, Rob Herring, Marc Zyngier, Michael Turquette,
CC Hwang, Loda Chou, Miles Chen, Jades Shih, Yingjoe Chen,
My Chuang, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
wsd_upstream-NuS5LvNUpcJWk0Htik3J/w,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Kevin-CW Chen
In-Reply-To: <1489937193-2953-8-git-send-email-mars.cheng-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On 03/19, Mars Cheng wrote:
> From: Kevin-CW Chen <kevin-cw.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> Add MT6797 clock support, include topckgen, apmixedsys, infracfg
> and subsystem clocks
>
> Signed-off-by: Kevin-CW Chen <kevin-cw.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Mars Cheng <mars.cheng-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Tested-by: Matthias Brugger <matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Looks fine to me except for the one comment below. Did you want
me to merge it into clk tree?
> diff --git a/drivers/clk/mediatek/clk-mt6797.c b/drivers/clk/mediatek/clk-mt6797.c
> new file mode 100644
> index 0000000..7ebb7f1
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mt6797.c
> @@ -0,0 +1,716 @@
> +/*
> + * Copyright (c) 2016 MediaTek Inc.
> + * Author: Kevin Chen <kevin-cw.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk.h>
Is this include used? Please include clk-provider if the file is
a clk driver. Same comment applies to other files in this patch.
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +
> +#include "clk-mtk.h"
> +#include "clk-gate.h"
> +
> +#include <dt-bindings/clock/mt6797-clk.h>
> +
> +/*
> + * For some clocks, we don't care what their actual rates are. And these
> + * clocks may change their rate on different products or different scenarios.
> + * So we model these clocks' rate as 0, to denote it's not an actual rate.
> + */
> +
> +static DEFINE_SPINLOCK(mt6797_clk_lock);
> +
> +static const struct mtk_fixed_factor top_fixed_divs[] = {
> + FACTOR(CLK_TOP_SYSPLL_CK, "syspll_ck", "mainpll", 1, 1),
> + FACTOR(CLK_TOP_SYSPLL_D2, "syspll_d2", "mainpll", 1, 2),
> + FACTOR(CLK_TOP_SYSPLL1_D2, "syspll1_d2", "syspll_d2", 1, 2),
[...]
> + clk_init = of_device_get_match_data(&pdev->dev);
> + if (!clk_init)
> + return -EINVAL;
> +
> + r = clk_init(pdev);
> + if (r)
> + dev_err(&pdev->dev,
> + "could not register clock provider: %s: %d\n",
> + pdev->name, r);
> +
> + return r;
> +}
> +
> +static struct platform_driver clk_mt6797_drv = {
> + .probe = clk_mt6797_probe,
> + .driver = {
> + .name = "clk-mt6797",
> + .owner = THIS_MODULE,
This can be removed, platform_driver_register() does it already.
> + .of_match_table = of_match_clk_mt6797,
> + },
> +};
> +
> +static int __init clk_mt6797_init(void)
> +{
> + return platform_driver_register(&clk_mt6797_drv);
> +}
> +
> +arch_initcall(clk_mt6797_init);
> diff --git a/include/dt-bindings/clock/mt6797-clk.h b/include/dt-bindings/clock/mt6797-clk.h
> new file mode 100644
> index 0000000..e48aa47
> --- /dev/null
> +++ b/include/dt-bindings/clock/mt6797-clk.h
> @@ -0,0 +1,281 @@
I think arm-soc folks don't want us merging whole drivers into
the DT branch anymore, so please split off the dt-bindings header
into a different patch that we can apply directly. Then we can
layer the driver on top and just send off the header to arm-soc
via a stable clk branch.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 05/10] dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel
From: Thierry Reding @ 2017-04-06 21:27 UTC (permalink / raw)
To: Yannick Fertre
Cc: Alexandre TORGUE, David Airlie, Maxime Coquelin, Russell King,
Mark Rutland, Rob Herring, Arnd Bergmann, Benjamin Gaignard,
Philippe Cornu, Mickael Reulier, Gabriel FERNANDEZ,
Vincent Abriou, Fabien Dessenne, kernel-F5mvAk5X5gdBDgjK7y7TUQ,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1490694293-18358-6-git-send-email-yannick.fertre-qxv4g6HH51o@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]
On Tue, Mar 28, 2017 at 11:44:48AM +0200, Yannick Fertre wrote:
> This patch adds documentation of device tree bindings for the WVGA panel
> Ampire AM-480272H3TMQW-T01H.
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Yannick Fertre <yannick.fertre-qxv4g6HH51o@public.gmane.org>
> ---
> .../display/panel/ampire,am-480272h3tmqw-t01h.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
Applied, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v5 06/10] drm/panel: simple: Add support for Ampire AM-480272H3TMQW-T01H
From: Thierry Reding @ 2017-04-06 21:27 UTC (permalink / raw)
To: Yannick Fertre
Cc: Alexandre TORGUE, David Airlie, Maxime Coquelin, Russell King,
Mark Rutland, Rob Herring, Arnd Bergmann, Benjamin Gaignard,
Philippe Cornu, Mickael Reulier, Gabriel FERNANDEZ,
Vincent Abriou, Fabien Dessenne, kernel-F5mvAk5X5gdBDgjK7y7TUQ,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1490694293-18358-7-git-send-email-yannick.fertre-qxv4g6HH51o@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 396 bytes --]
On Tue, Mar 28, 2017 at 11:44:49AM +0200, Yannick Fertre wrote:
> Add simple-panel support for the Ampire AM-480272H3TMQW-T01H,
> which is a 4.3" WQVGA panel.
>
> Signed-off-by: Yannick Fertre <yannick.fertre-qxv4g6HH51o@public.gmane.org>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
Applied, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v11 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
From: Thierry Reding @ 2017-04-06 21:33 UTC (permalink / raw)
To: Hoegeun Kwon
Cc: airlied-cv59FeDIM0c, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, kgene-DgEjT+Ai2ygdnm+yROfE0A,
krzk-DgEjT+Ai2ygdnm+yROfE0A,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
javier-JPH+aEBZ4P+UEJcrhfAQsw, inki.dae-Sze3O3UU22JBDgjK7y7TUQ,
a.hajda-Sze3O3UU22JBDgjK7y7TUQ, cw00.choi-Sze3O3UU22JBDgjK7y7TUQ,
jh80.chung-Sze3O3UU22JBDgjK7y7TUQ,
andi.shyti-Sze3O3UU22JBDgjK7y7TUQ, Donghwa Lee, Hyungwon Hwang
In-Reply-To: <1488937357-5623-3-git-send-email-hoegeun.kwon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 987 bytes --]
On Wed, Mar 08, 2017 at 10:42:36AM +0900, Hoegeun Kwon wrote:
> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
> driver. This panel has 1440x2560 resolution in 5.7-inch physical
> panel in the TM2 device.
>
> Signed-off-by: Donghwa Lee <dh09.lee-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Hyungwon Hwang <human.hwang-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Hoegeun Kwon <hoegeun.kwon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Tested-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Reviewed-by: Andrzej Hajda <a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> drivers/gpu/drm/panel/Kconfig | 6 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 739 ++++++++++++++++++++++++++
> 3 files changed, 746 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
Applied, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v11 1/3] dt-bindings: Add support for samsung s6e3ha2 panel binding
From: Thierry Reding @ 2017-04-06 21:33 UTC (permalink / raw)
To: Hoegeun Kwon
Cc: airlied, robh+dt, mark.rutland, catalin.marinas, will.deacon,
kgene, krzk, dri-devel, devicetree, linux-arm-kernel,
linux-samsung-soc, linux-kernel, javier, inki.dae, a.hajda,
cw00.choi, jh80.chung, andi.shyti, Donghwa Lee, Hyungwon Hwang
In-Reply-To: <1488937357-5623-2-git-send-email-hoegeun.kwon@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 743 bytes --]
On Wed, Mar 08, 2017 at 10:42:35AM +0900, Hoegeun Kwon wrote:
> The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected
> using MIPI-DSI interfaces.
>
> Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
> Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> .../bindings/display/panel/samsung,s6e3ha2.txt | 28 ++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
Applied, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: display: panel: Add bindings for the Sitronix ST7789V panel
From: Thierry Reding @ 2017-04-06 21:52 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, Rob Herring, Daniel Vetter, David Airlie,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
noralf-L59+Z2yzLopAfugRpC6u6w
In-Reply-To: <85ff9c2013ed43f3ad4c566d3430fab380d9a80a.1491226701.git-series.maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 658 bytes --]
On Mon, Apr 03, 2017 at 03:38:31PM +0200, Maxime Ripard wrote:
> The Sitronix ST7789V is an LCD panel controller, controlled over SPI, that
> can drive 18-bits 240x320 LCD displays.
>
> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt | 37 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 37 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt
Applied, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/2] drm/panel: Add driver for sitronix ST7789V LCD controller
From: Thierry Reding @ 2017-04-06 21:53 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, linux-kernel, dri-devel, Rob Herring,
Daniel Vetter
In-Reply-To: <fb8ed97ce3e32b6d292fef4715cde188dff6a8a5.1491226701.git-series.maxime.ripard@free-electrons.com>
[-- Attachment #1.1: Type: text/plain, Size: 739 bytes --]
On Mon, Apr 03, 2017 at 03:38:32PM +0200, Maxime Ripard wrote:
> The Sitronix ST7789v controller is used to drive 240x320 LCD panels through
> various interfaces, including SPI and RGB/Parallel.
>
> The current driver is configuring it for the latter. Support for tinyDRM
> can always be added later.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/gpu/drm/panel/Kconfig | 7 +-
> drivers/gpu/drm/panel/Makefile | 1 +-
> drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 449 ++++++++++++++++++-
> 3 files changed, 457 insertions(+), 0 deletions(-)
> create mode 100644 drivers/gpu/drm/panel/panel-sitronix-st7789v.c
Applied, thanks.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/2] devicetree: add vendor prefix for Winstar Display Corp.
From: Thierry Reding @ 2017-04-06 21:59 UTC (permalink / raw)
To: Richard Genoud
Cc: Mark Rutland, devicetree, Rob Herring, linux-kernel, dri-devel
In-Reply-To: <20170303152156.31370-1-richard.genoud@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 381 bytes --]
On Fri, Mar 03, 2017 at 04:21:55PM +0100, Richard Genoud wrote:
> Winstar Display Corp. is specialized in LCD displays for embedded
> products.
> cf: http://www.winstar.com.tw
>
> Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Applied, thanks.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 1/3] ARM: dts: rockchip: Add support for phyCORE-RK3288 SoM
From: Heiko Stuebner @ 2017-04-06 22:21 UTC (permalink / raw)
To: Wadim Egorov
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491483866-18368-1-git-send-email-w.egorov-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
Am Donnerstag, 6. April 2017, 15:04:24 CEST schrieb Wadim Egorov:
> The phyCORE-RK3288 is a SoM (System on Module) containing a RK3288 SoC.
> The module can be connected to different carrier boards.
> It can be also equipped with different RAM, SPI flash and eMMC variants.
> The Rapid Development Kit option is using the following setup:
>
> - 1 GB DDR3 RAM (2 Banks)
> - 1x 4 KB EEPROM
> - DP83867 Gigabit Ethernet PHY
> - 16 MB SPI Flash
> - 4 GB eMMC Flash
>
> Signed-off-by: Wadim Egorov <w.egorov-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
applied all 3 for 4.12 .
One minor change was making the touchscreen node name in patch2 read
touchscreen@44
Same rationale as before, nodes should be named after the device-category
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] ARM: dts: rockchip: rock2: Setup usb vbus-supply
From: Heiko Stuebner @ 2017-04-06 22:23 UTC (permalink / raw)
To: Sjoerd Simons
Cc: John Youn, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Mark Rutland, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170405140613.4444-3-sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
Am Mittwoch, 5. April 2017, 16:06:11 CEST schrieb Sjoerd Simons:
> Now that the rockchip usb phy has a vbus-supply property use that to
> control the vbus regulator on rock2.
>
> Signed-off-by: Sjoerd Simons <sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
I've queued this for 4.13 .
Not eligible for 4.12, as the patch alone (when testing my tree or armsoc)
would regress the sata-bridge, due to the regulator-always-on going away.
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] of: change fixup of dma-ranges size to error
From: Rob Herring @ 2017-04-06 22:41 UTC (permalink / raw)
To: Frank Rowand
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <58E68ADC.6040603-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Apr 6, 2017 at 1:37 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 04/06/17 07:03, Rob Herring wrote:
>> On Thu, Apr 6, 2017 at 1:18 AM, <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> From: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
>>>
>>> of_dma_get_range() has workaround code to fixup a device tree that
>>> incorrectly specified a mask instead of a size for property
>>> dma-ranges. That device tree was fixed a year ago in v4.6, so
>>> the workaround is no longer needed. Leave a data validation
>>> check in place, but no longer do the fixup. Move the check
>>> one level deeper in the call stack so that other possible users
>>> of dma-ranges will also be protected.
>>>
>>> The fix to the device tree was in
>>> commit c91cb9123cdd ("dtb: amd: Fix DMA ranges in device tree").
>>
>> NACK.
>> This was by design. You can't represent a size of 2^64 or 2^32.
>
> I agree that being unable to represent a size of 2^32 in a u32 and
> a size of 2^64 in a u64 is the underlying issue.
>
> But the code to convert a mask to a size is _not_ design, it is a
> hack that temporarily worked around a device tree that did not follow
> the dma-ranges binding in the ePAPR.
Since when is (2^64 - 1) not a size. It's a perfectly valid size in
DT. And there's probably not a system in the world that needs access
to that last byte. Is it completely accurate description if we
subtract off 1? No, but it is still a valid range (so would be
subtracting 12345).
> That device tree was corrected a year ago to provide a size instead of
> a mask.
You are letting Linux implementation details influence your DT
thinking. DT is much more flexible in that it supports a base address
and size (and multiple of them) while Linux can only deal with a
single address mask. If Linux dealt with base + size, then we wouldn't
be having this conversation. As long as Linux only deals with masks,
we're going to have to have some sort of work-around to deal with
them.
>> Well, technically you can for the latter, but then you have to grow
>> #size-cells to 2 for an otherwise all 32-bit system which seems kind
>> of pointless and wasteful. You could further restrict this to only
>> allow ~0 and not just any case with bit 0 set.
>>
>> I'm pretty sure AMD is not the only system. There were 32-bit systems too.
>
> I examined all instances of property dma-ranges in in tree dts files in
> Linux 4.11-rc1. There are none that incorrectly specify mask instead of
> size.
Okay, but there are ones for ranges at least. See ecx-2000.dts.
> #size-cells only changes to 2 for the dma-ranges property and the ranges
> property when size is 2^32, so that is a very small amount of space.
>
> The patch does not allow for a size of 2^64. If a system requires a
> size of 2^64 then the type of size needs to increase to be larger
> than a u64. If you would like for the code to be defensive and
> detect a device tree providing a size of 2^64 then I can add a
> check to of_dma_get_range() to return -EINVAL if #size-cells > 2.
> When that error triggers, the type of size can be changed.
#size-cells > 2 is completely broken for anything but PCI. I doubt it
is easily fixed without some special casing (i.e. a different hack)
until we have 128-bit support. I hope to retire before we need to
support that.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 07/12] clk: mediatek: add clk support for MT6797
From: Mars Cheng @ 2017-04-06 23:35 UTC (permalink / raw)
To: Stephen Boyd
Cc: Matthias Brugger, Rob Herring, Marc Zyngier, Michael Turquette,
CC Hwang, Loda Chou, Miles Chen, Jades Shih, Yingjoe Chen,
My Chuang, linux-kernel, linux-mediatek, devicetree, wsd_upstream,
linux-clk, Kevin-CW Chen
In-Reply-To: <20170406200852.GQ7065@codeaurora.org>
Hi Stephen
On Thu, 2017-04-06 at 13:08 -0700, Stephen Boyd wrote:
> On 03/19, Mars Cheng wrote:
> > From: Kevin-CW Chen <kevin-cw.chen@mediatek.com>
> >
> > Add MT6797 clock support, include topckgen, apmixedsys, infracfg
> > and subsystem clocks
> >
> > Signed-off-by: Kevin-CW Chen <kevin-cw.chen@mediatek.com>
> > Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> > Tested-by: Matthias Brugger <matthias.bgg@gmail.com>
>
> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
>
> Looks fine to me except for the one comment below. Did you want
> me to merge it into clk tree?
To prevent another run, I really like you to merge it.
However, I also want to make the patch set more cleaner.
So I will send v4 later. :-)
>
> > diff --git a/drivers/clk/mediatek/clk-mt6797.c b/drivers/clk/mediatek/clk-mt6797.c
> > new file mode 100644
> > index 0000000..7ebb7f1
> > --- /dev/null
> > +++ b/drivers/clk/mediatek/clk-mt6797.c
> > @@ -0,0 +1,716 @@
> > +/*
> > + * Copyright (c) 2016 MediaTek Inc.
> > + * Author: Kevin Chen <kevin-cw.chen@mediatek.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <linux/clk.h>
>
> Is this include used? Please include clk-provider if the file is
> a clk driver. Same comment applies to other files in this patch.
>
Should be removed. Will be done in v4.
> > +#include <linux/of.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +
> > +#include "clk-mtk.h"
> > +#include "clk-gate.h"
> > +
> > +#include <dt-bindings/clock/mt6797-clk.h>
> > +
> > +/*
> > + * For some clocks, we don't care what their actual rates are. And these
> > + * clocks may change their rate on different products or different scenarios.
> > + * So we model these clocks' rate as 0, to denote it's not an actual rate.
> > + */
> > +
> > +static DEFINE_SPINLOCK(mt6797_clk_lock);
> > +
> > +static const struct mtk_fixed_factor top_fixed_divs[] = {
> > + FACTOR(CLK_TOP_SYSPLL_CK, "syspll_ck", "mainpll", 1, 1),
> > + FACTOR(CLK_TOP_SYSPLL_D2, "syspll_d2", "mainpll", 1, 2),
> > + FACTOR(CLK_TOP_SYSPLL1_D2, "syspll1_d2", "syspll_d2", 1, 2),
> [...]
> > + clk_init = of_device_get_match_data(&pdev->dev);
> > + if (!clk_init)
> > + return -EINVAL;
> > +
> > + r = clk_init(pdev);
> > + if (r)
> > + dev_err(&pdev->dev,
> > + "could not register clock provider: %s: %d\n",
> > + pdev->name, r);
> > +
> > + return r;
> > +}
> > +
> > +static struct platform_driver clk_mt6797_drv = {
> > + .probe = clk_mt6797_probe,
> > + .driver = {
> > + .name = "clk-mt6797",
> > + .owner = THIS_MODULE,
>
> This can be removed, platform_driver_register() does it already.
>
got it, will be removed.
> > + .of_match_table = of_match_clk_mt6797,
> > + },
> > +};
> > +
> > +static int __init clk_mt6797_init(void)
> > +{
> > + return platform_driver_register(&clk_mt6797_drv);
> > +}
> > +
> > +arch_initcall(clk_mt6797_init);
> > diff --git a/include/dt-bindings/clock/mt6797-clk.h b/include/dt-bindings/clock/mt6797-clk.h
> > new file mode 100644
> > index 0000000..e48aa47
> > --- /dev/null
> > +++ b/include/dt-bindings/clock/mt6797-clk.h
> > @@ -0,0 +1,281 @@
>
> I think arm-soc folks don't want us merging whole drivers into
> the DT branch anymore, so please split off the dt-bindings header
> into a different patch that we can apply directly. Then we can
> layer the driver on top and just send off the header to arm-soc
> via a stable clk branch.
>
Got it. Will be done in v4.
Thanks for your review.
^ permalink raw reply
* Re: [PATCH v6 19/39] media: Add i.MX media core driver
From: Steve Longerbeam @ 2017-04-06 23:51 UTC (permalink / raw)
To: Philipp Zabel
Cc: robh+dt, mark.rutland, shawnguo, kernel, fabio.estevam, linux,
mchehab, hverkuil, nick, markus.heiser, laurent.pinchart+renesas,
bparrot, geert, arnd, sudipm.mukherjee, minghsiu.tsai,
tiffany.lin, jean-christophe.trotin, horms+renesas,
niklas.soderlund+renesas, robert.jarzmik, songjun.wu,
andrew-ct.chen, gregkh, shuah, sakari.ailus, pavel, devicetree,
linux-kernel, linux-arm-kernel, linux-media
In-Reply-To: <1491471814.2392.11.camel@pengutronix.de>
On 04/06/2017 02:43 AM, Philipp Zabel wrote:
> On Mon, 2017-03-27 at 17:40 -0700, Steve Longerbeam wrote:
>> Add the core media driver for i.MX SOC.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> [...]
>> diff --git a/drivers/staging/media/imx/imx-media-of.c b/drivers/staging/media/imx/imx-media-of.c
>> new file mode 100644
>> index 0000000..b383be4
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-media-of.c
>> @@ -0,0 +1,267 @@
> [...]
>> +/*
>> + * find the remote device node and remote port id (remote pad #)
>> + * given local endpoint node
>> + */
>> +static void of_get_remote_pad(struct device_node *epnode,
>> + struct device_node **remote_node,
>> + int *remote_pad)
>> +{
>> + struct device_node *rp, *rpp;
>> + struct device_node *remote;
>> +
>> + rp = of_graph_get_remote_port(epnode);
>> + rpp = of_graph_get_remote_port_parent(epnode);
>> +
>> + if (of_device_is_compatible(rpp, "fsl,imx6q-ipu")) {
>> + /* the remote is one of the CSI ports */
>> + remote = rp;
>> + *remote_pad = 0;
>> + of_node_put(rpp);
>> + } else {
>> + remote = rpp;
>> + of_property_read_u32(rp, "reg", remote_pad);
>
> If this fails because there is no reg property, *remote_pad will keep
> the previous value. It should be set to 0 in this case.
Ok, I will apply this change.
Steve
>
> ----------8<----------
> --- a/drivers/staging/media/imx/imx-media-of.c
> +++ b/drivers/staging/media/imx/imx-media-of.c
> @@ -85,7 +85,9 @@ static void of_get_remote_pad(struct device_node *epnode,
> of_node_put(rpp);
> } else {
> remote = rpp;
> - of_property_read_u32(rp, "reg", remote_pad);
> + /* FIXME port number and pad index are not the same */
> + if (of_property_read_u32(rp, "reg", remote_pad))
> + *remote_pad = 0;
> of_node_put(rp);
> }
>
> ---------->8----------
>
> regards
> Philipp
>
^ permalink raw reply
* Re: [PATCH v2 2/2] mtd: spi-nor: add driver for STM32 quad spi flash controller
From: Marek Vasut @ 2017-04-06 23:55 UTC (permalink / raw)
To: Ludovic Barre, Cyrille Pitchen
Cc: David Woodhouse, Brian Norris, Boris Brezillon,
Richard Weinberger, Alexandre Torgue, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490979724-10905-3-git-send-email-ludovic.Barre-qxv4g6HH51o@public.gmane.org>
On 03/31/2017 07:02 PM, Ludovic Barre wrote:
> From: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
>
> The quadspi is a specialized communication interface targeting single,
> dual or quad SPI Flash memories.
>
> It can operate in any of the following modes:
> -indirect mode: all the operations are performed using the quadspi
> registers
> -read memory-mapped mode: the external Flash memory is mapped to the
> microcontroller address space and is seen by the system as if it was
> an internal memory
>
> Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
> ---
> drivers/mtd/spi-nor/Kconfig | 7 +
> drivers/mtd/spi-nor/Makefile | 1 +
> drivers/mtd/spi-nor/stm32-quadspi.c | 690 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 698 insertions(+)
> create mode 100644 drivers/mtd/spi-nor/stm32-quadspi.c
>
[...]
> +struct stm32_qspi_flash {
> + struct spi_nor nor;
> + u32 cs;
> + u32 fsize;
> + u32 presc;
> + struct stm32_qspi *qspi;
> +};
[...]
> +struct stm32_qspi_cmd {
> + struct {
> + u8 addr_width;
> + u8 dummy;
> + u8 data;
> + } conf;
Is there any benefit in having this structure here or could you just
make the struct stm32_qspi_cmd flat ?
> + u8 opcode;
> + u32 framemode;
> + u32 qspimode;
> + u32 addr;
> + size_t len;
> + void *buf;
> +};
[...]
> +static ssize_t stm32_qspi_read(struct spi_nor *nor, loff_t from, size_t len,
> + u_char *buf)
> +{
> + struct stm32_qspi_flash *flash = nor->priv;
> + struct stm32_qspi *qspi = flash->qspi;
> + struct stm32_qspi_cmd cmd;
> + int err;
> +
> + dev_dbg(qspi->dev, "read(%#.2x): buf:%p from:%#.8x len:%#x\n",
> + nor->read_opcode, buf, (u32)from, len);
> +
> + memset(&cmd, 0, sizeof(cmd));
> + cmd.opcode = nor->read_opcode;
> + cmd.conf.addr_width = nor->addr_width;
> + cmd.addr = (u32)from;
loff_t (from) can be 64bit ... how do we handle this ?
> + cmd.conf.data = 1;
> + cmd.conf.dummy = nor->read_dummy;
> + cmd.len = len;
> + cmd.buf = buf;
> + cmd.qspimode = qspi->read_mode;
> +
> + stm32_qspi_set_framemode(nor, &cmd, true);
> + err = stm32_qspi_send(flash, &cmd);
> +
> + return err ? err : len;
> +}
[...]
> +static irqreturn_t stm32_qspi_irq(int irq, void *dev_id)
> +{
> + struct stm32_qspi *qspi = (struct stm32_qspi *)dev_id;
> + u32 cr, sr, fcr = 0;
> +
> + cr = readl_relaxed(qspi->io_base + QUADSPI_CR);
> + sr = readl_relaxed(qspi->io_base + QUADSPI_SR);
> +
> + if ((cr & CR_TCIE) && (sr & SR_TCF)) {
> + /* tx complete */
> + fcr |= FCR_CTCF;
> + complete(&qspi->cmd_completion);
> + } else {
> + dev_info(qspi->dev, "spurious interrupt\n");
You probably want to ratelimit this one ...
> + }
> +
> + writel_relaxed(fcr, qspi->io_base + QUADSPI_FCR);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int stm32_qspi_prep(struct spi_nor *nor, enum spi_nor_ops ops)
> +{
> + struct stm32_qspi_flash *flash = nor->priv;
> + struct stm32_qspi *qspi = flash->qspi;
> +
> + mutex_lock(&qspi->lock);
> + return 0;
> +}
> +
> +static void stm32_qspi_unprep(struct spi_nor *nor, enum spi_nor_ops ops)
> +{
> + struct stm32_qspi_flash *flash = nor->priv;
> + struct stm32_qspi *qspi = flash->qspi;
> +
> + mutex_unlock(&qspi->lock);
> +}
> +
> +static int stm32_qspi_flash_setup(struct stm32_qspi *qspi,
> + struct device_node *np)
> +{
> + u32 width, flash_read, presc, cs_num, max_rate = 0;
> + struct stm32_qspi_flash *flash;
> + struct mtd_info *mtd;
> + int ret;
> +
> + of_property_read_u32(np, "reg", &cs_num);
> + if (cs_num >= STM32_MAX_NORCHIP)
> + return -EINVAL;
> +
> + of_property_read_u32(np, "spi-max-frequency", &max_rate);
> + if (!max_rate)
> + return -EINVAL;
> +
> + presc = DIV_ROUND_UP(qspi->clk_rate, max_rate) - 1;
> +
> + if (of_property_read_u32(np, "spi-rx-bus-width", &width))
> + width = 1;
> +
> + if (width == 4)
> + flash_read = SPI_NOR_QUAD;
> + else if (width == 2)
> + flash_read = SPI_NOR_DUAL;
> + else if (width == 1)
> + flash_read = SPI_NOR_NORMAL;
> + else
> + return -EINVAL;
> +
> + flash = &qspi->flash[cs_num];
> + flash->qspi = qspi;
> + flash->cs = cs_num;
> + flash->presc = presc;
> +
> + flash->nor.dev = qspi->dev;
> + spi_nor_set_flash_node(&flash->nor, np);
> + flash->nor.priv = flash;
> + mtd = &flash->nor.mtd;
> + mtd->priv = &flash->nor;
> +
> + flash->nor.read = stm32_qspi_read;
> + flash->nor.write = stm32_qspi_write;
> + flash->nor.erase = stm32_qspi_erase;
> + flash->nor.read_reg = stm32_qspi_read_reg;
> + flash->nor.write_reg = stm32_qspi_write_reg;
> + flash->nor.prepare = stm32_qspi_prep;
> + flash->nor.unprepare = stm32_qspi_unprep;
> +
> + writel_relaxed(LPTR_DFT_TIMEOUT, qspi->io_base + QUADSPI_LPTR);
> +
> + writel_relaxed(CR_PRESC(presc) | CR_FTHRES(3) | CR_TCEN | CR_SSHIFT
> + | CR_EN, qspi->io_base + QUADSPI_CR);
> +
> + /*
> + * in stm32 qspi controller, QUADSPI_DCR register has a fsize field
> + * which define the size of nor flash.
> + * if fsize is NULL, the controller can't sent spi-nor command.
> + * set a temporary value just to discover the nor flash with
> + * "spi_nor_scan". After, the right value (mtd->size) can be set.
> + */
Is 25 the smallest value ? Use a macro for this ...
> + flash->fsize = 25;
> +
> + ret = spi_nor_scan(&flash->nor, NULL, flash_read);
> + if (ret) {
> + dev_err(qspi->dev, "device scan failed\n");
> + return ret;
> + }
> +
> + /* number of bytes in Flash memory = 2^[FSIZE+1] */
> + flash->fsize = __fls(mtd->size) - 1;
> +
> + writel_relaxed(DCR_CSHT(1), qspi->io_base + QUADSPI_DCR);
> +
> + ret = mtd_device_register(mtd, NULL, 0);
> + if (ret) {
> + dev_err(qspi->dev, "mtd device parse failed\n");
> + return ret;
> + }
> +
> + dev_dbg(qspi->dev, "read mm:%s cs:%d bus:%d\n",
> + qspi->read_mode == CCR_FMODE_MM ? "yes" : "no", cs_num, width);
> +
> + return 0;
> +}
[...]
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: aspeed: add SPI controller bindings to Romulus
From: Joel Stanley @ 2017-04-07 1:50 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Rob Herring, Mark Rutland, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree
In-Reply-To: <1490198683-5796-1-git-send-email-clg-Bxea+6Xhats@public.gmane.org>
On Thu, Mar 23, 2017 at 2:34 AM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
> Romulus systems have one MX25L25635 (32768 Kbytes) flash module for
> the BMC firmware and other MT25QL512A (65536 Kbytes) for the host.
>
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
Thanks, applied.
Cheers,
Joel
> ---
> arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> index 7a3b2b50c884..e3c6358bc7d9 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> @@ -31,6 +31,26 @@
> };
> };
>
> +&fmc {
> + status = "okay";
> + flash@0 {
> + status = "okay";
> + label = "bmc";
> + };
> +};
> +
> +&spi1 {
> + status = "okay";
> + flash@0 {
> + status = "okay";
> + label = "pnor";
> + };
> +};
> +
> +&spi2 {
> + status = "okay";
> +};
> +
> &uart5 {
> status = "okay";
> };
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 0/5] arm64: dts: hisi: add NIC, RoCE and SAS support for hip07
From: Wei.Xu @ 2017-04-07 2:07 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
arnd-r2nGTMty4D4
Cc: xuwei5-C8/M+/jPZTeaMJb+Lgu22Q, john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
wangzhou1-C8/M+/jPZTeaMJb+Lgu22Q,
liudongdong3-hv44wF8Li93QT0dZR+AlfA,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
salil.mehta-hv44wF8Li93QT0dZR+AlfA,
majun258-hv44wF8Li93QT0dZR+AlfA,
wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
guohanjun-hv44wF8Li93QT0dZR+AlfA, linuxarm-hv44wF8Li93QT0dZR+AlfA,
liguozhu-C8/M+/jPZTeaMJb+Lgu22Q, yimin-hv44wF8Li93QT0dZR+AlfA,
chenxiang66-C8/M+/jPZTeaMJb+Lgu22Q,
tanxiaofei-hv44wF8Li93QT0dZR+AlfA,
lipeng321-hv44wF8Li93QT0dZR+AlfA,
yankejian-hv44wF8Li93QT0dZR+AlfA,
huangdaode-C8/M+/jPZTeaMJb+Lgu22Q,
charles.chenxin-hv44wF8Li93QT0dZR+AlfA,
shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
This patch series adds Mbigen, NIC, RoCE and SAS nodes for the hip07
SoC and enables the NIC, RoCE and SAS on the hip07 d05 board.
Wei Xu (5):
arm64: dts: hisi: add mbigen nodes for the hip07 SoC
arm64: dts: hisi: add network related nodes for the hip07 SoC
arm64: dts: hisi: add RoCE nodes for the hip07 SoC
arm64: dts: hisi: add SAS nodes for the hip07 SoC
arm64: dts: hisi: enalbe the NIC and SAS for the hip07-d05 board
arch/arm64/boot/dts/hisilicon/hip07-d05.dts | 24 ++
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 479 ++++++++++++++++++++++++++++
2 files changed, 503 insertions(+)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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