* [PATCH 1/3] of: base: add support to get machine compatible string
From: Sekhar Nori @ 2016-11-23 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2a644b8c-d91e-5ab1-200b-00f749a36307@arm.com>
On Wednesday 23 November 2016 03:35 PM, Sudeep Holla wrote:
>
>
> On 23/11/16 07:49, Sekhar Nori wrote:
>> On Tuesday 22 November 2016 09:16 PM, Sudeep Holla wrote:
>>> Hi Sekhar,
>>>
>>> On 22/11/16 15:06, Sekhar Nori wrote:
>>>> Hi Sudeep,
>>>>
>>>> On Tuesday 22 November 2016 04:23 PM, Sudeep Holla wrote:
>>>>>
>>>>>
>>>>> On 22/11/16 10:41, Bartosz Golaszewski wrote:
>>>>>> Add a function allowing to retrieve the compatible string of the root
>>>>>> node of the device tree.
>>>>>>
>>>>>
>>>>> Rob has queued [1] and it's in -next today. You can reuse that if you
>>>>> are planning to target this for v4.11 or just use open coding in your
>>>>> driver for v4.10 and target this move for v4.11 to avoid cross tree
>>>>> dependencies as I already mentioned in your previous thread.
>>>>
>>>> I dont have your original patch in my mailbox, but I wonder if
>>>> returning a pointer to property string for a node whose reference has
>>>> already been released is safe to do? Probably not an issue for the root
>>>> node, but still feels counter-intuitive.
>>>>
>>>
>>> I am not sure if I understand the issue here. Are you referring a case
>>> where of_root is freed ?
>>
>> Yes, right, thats what I was hinting at. Since you are giving up the
>> reference to the device node before the function returns, the user can
>> be left with a dangling reference.
>>
>
> Yes I agree.
So, the if(!of_node_get()) is just an expensive NULL pointer check. I think
it is better to be explicit about it by not using of_node_get/put() at all.
How about:
+int of_machine_get_model_name(const char **model)
+{
+ int error;
+
+ if (!of_root)
+ return -EINVAL;
+
+ error = of_property_read_string(of_root, "model", model);
+ if (error)
+ error = of_property_read_string_index(of_root, "compatible",
+ 0, model);
+ return error;
+}
+EXPORT_SYMBOL(of_machine_get_model_name);
I know the patch is already in -next so I guess it depends on how strongly
Rob feels about this.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] dt-bindings: mfd: Improve readability for TPS65217 interrupt sources
From: Arnd Bergmann @ 2016-11-23 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bd4944d8-3cef-b3f7-4fba-6de590493047@gmail.com>
On Wednesday, November 23, 2016 8:38:00 PM CET Milo Kim wrote:
> On 11/23/2016 12:57 AM, Lee Jones wrote:
> >> pwrbutton {
> >> > - interrupts = <TPS65217_IRQ_PB>;
> >> > + interrupts = <TPS65217_IRQ_PUSHBUTTON>;
> > Push button or power button?
> >
>
> According to the datasheet, push button interrupt is correct.
>
> http://www.ti.com/lit/ds/symlink/tps65217.pdf
>
> This is used for a power button input in Beaglebone boards. In other
> words, the power button is one of push button usages.
>
> So, I'd like to keep general name for the interrupt.
Ah, the numbers come from the data sheet. Please just remove the
header then, there is no need to keep them as an ABI, in particular
when the driver doesn't even include that header today.
I see you even have names for them in the node:
charger {
- interrupts = <TPS65217_IRQ_AC>, <TPS65217_IRQ_USB>;
+ interrupts = <TPS65217_IRQ_AC_POWER>, <TPS65217_IRQ_USB_POWER>;
interrupts-names = "AC", "USB";
status = "okay";
What matters here is the binding documentation in
Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
Please fix that instead to mandate that the two interrupts are
required, what their functions are, and what the interrupt-names
(not interrupts-names) property must list.
Arnd
^ permalink raw reply
* [PATCH v16 13/15] acpi/arm64: Add memory-mapped timer support in GTDT driver
From: Fu Wei @ 2016-11-23 11:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118142249.GA18029@red-moon>
Hi Lorenzo,
On 18 November 2016 at 22:22, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> On Wed, Nov 16, 2016 at 09:49:06PM +0800, fu.wei at linaro.org wrote:
>> From: Fu Wei <fu.wei@linaro.org>
>>
>> On platforms booting with ACPI, architected memory-mapped timers'
>> configuration data is provided by firmware through the ACPI GTDT
>> static table.
>>
>> The clocksource architected timer kernel driver requires a firmware
>> interface to collect timer configuration and configure its driver.
>> this infrastructure is present for device tree systems, but it is
>> missing on systems booting with ACPI.
>>
>> Implement the kernel infrastructure required to parse the static
>> ACPI GTDT table so that the architected timer clocksource driver can
>> make use of it on systems booting with ACPI, therefore enabling
>> the corresponding timers configuration.
>>
>> Signed-off-by: Fu Wei <fu.wei@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> drivers/acpi/arm64/gtdt.c | 95 +++++++++++++++++++++++++++++++++++++++++++++++
>> include/linux/acpi.h | 1 +
>> 2 files changed, 96 insertions(+)
>>
>> diff --git a/drivers/acpi/arm64/gtdt.c b/drivers/acpi/arm64/gtdt.c
>> index 2de79aa..08d9506 100644
>> --- a/drivers/acpi/arm64/gtdt.c
>> +++ b/drivers/acpi/arm64/gtdt.c
>> @@ -51,6 +51,14 @@ static inline bool is_timer_block(void *platform_timer)
>> return gh->type == ACPI_GTDT_TYPE_TIMER_BLOCK;
>> }
>>
>> +static inline struct acpi_gtdt_timer_block *get_timer_block(unsigned int index)
>> +{
>> + if (index >= acpi_gtdt_desc.timer_block_count || !timer_block)
>> + return NULL;
>> +
>> + return timer_block[index];
>> +}
>> +
>> static inline bool is_watchdog(void *platform_timer)
>> {
>> struct acpi_gtdt_header *gh = platform_timer;
>> @@ -214,3 +222,90 @@ int __init acpi_gtdt_init(struct acpi_table_header *table)
>> acpi_gtdt_release();
>> return -EINVAL;
>> }
>> +
>> +/*
>> + * Get ONE GT block info for memory-mapped timer from GTDT table.
>> + * @data: the GT block data (parsing result)
>> + * @index: the index number of GT block
>> + * Note: we already verify @data in caller, it can't be NULL here.
>> + * Returns 0 if success, -EINVAL/-ENODEV if error.
>> + */
>
> Documentation/kernel-doc-nano-HOWTO.txt
Great thanks , will fix all the comments :-)
>
>> +int __init gtdt_arch_timer_mem_init(struct arch_timer_mem *data,
>> + unsigned int index)
>
> Nit: acpi_arch_timer_mem_init() to make it consistent with other ACPI
> calls ?
yes, it makes sense, will do this way for the function which is exported
>
>> +{
>> + struct acpi_gtdt_timer_block *block;
>> + struct acpi_gtdt_timer_entry *frame;
>> + int i;
>> +
>> + block = get_timer_block(index);
>> + if (!block)
>> + return -ENODEV;
>> +
>> + if (!block->timer_count) {
>> + pr_err(FW_BUG "GT block present, but frame count is zero.");
>> + return -ENODEV;
>> + }
>> +
>> + if (block->timer_count > ARCH_TIMER_MEM_MAX_FRAMES) {
>> + pr_err(FW_BUG "GT block lists %d frames, ACPI spec only allows 8\n",
>> + block->timer_count);
>> + return -EINVAL;
>> + }
>
> Nit: these two checks can be carried out at GTDT init where the GTDT
> is parsed first. Actually you could have two functions one to init
this check is the verify the data in GT block, but the GTDT init
won't get into the block,
so I think that is better to keep this in GT block init function
"acpi_arch_timer_mem_init()"
> timers (say acpi_gtdt_timers_init()) and one watchdogs, that would
> eliminate the duplicated timer_block/watchdog arrays (both sized
> Platform Timer Count) and acpi_gtdt_timers_init() can return
> the number of entries found so that you can loop with a determined
> upper bound in the arm arch timer driver.
Yes, I did this way in previous patchset, but we still need to do scan
loop in both functions for
two types of platform timer.
So I decide to keep the scan loop in the acpi_gtdt_init to get the
number and the entries pointer
of each type of platform timers in one go. then we don't need to scan
GTDT in two functions.
>
> Just thinking aloud, these are just improvements I can carry them
> out later, the more important question here is the interface between the
> parsing code and the arch timer probing code which depends on other
> patches and that needs to be agreed, this patch is not really a problem.
yes, every time I modify the interface I have to change the driver :-(
>
>> + data->cntctlbase = (phys_addr_t)block->block_address;
>> + /*
>> + * We can NOT get the size info from GTDT table,
>> + * but according to "Table * CNTCTLBase memory map" of
>> + * <ARM Architecture Reference Manual> for ARMv8,
>> + * it should be 4KB(Offset 0x000 ? 0xFFC).
>
> That's the reason why it is not explicit in the GTDT table :)
>
>> + data->size = SZ_4K;
>> + data->num_frames = block->timer_count;
>> +
>> + frame = (void *)block + block->timer_offset;
>> + if (frame + block->timer_count != (void *)block + block->header.length)
>> + return -EINVAL;
>> +
>> + /*
>> + * Get the GT timer Frame data for every GT Block Timer
>> + */
>> + for (i = 0; i < block->timer_count; i++, frame++) {
>> + if (!frame->base_address || !frame->timer_interrupt)
>> + return -EINVAL;
>> +
>> + data->frame[i].phys_irq = map_gt_gsi(frame->timer_interrupt,
>> + frame->timer_flags);
>> + if (data->frame[i].phys_irq <= 0) {
>> + pr_warn("failed to map physical timer irq in frame %d.\n",
>> + i);
>> + return -EINVAL;
>> + }
>> +
>> + if (frame->virtual_timer_interrupt) {
>> + data->frame[i].virt_irq =
>> + map_gt_gsi(frame->virtual_timer_interrupt,
>> + frame->virtual_timer_flags);
>> + if (data->frame[i].virt_irq <= 0) {
>> + pr_warn("failed to map virtual timer irq in frame %d.\n",
>> + i);
>> + return -EINVAL;
>
> You should unregister phys_irq here for correctness, right ?
yup, thanks for pointing this bug out. :-)
>
>> + }
>> + }
>> +
>> + data->frame[i].frame_nr = frame->frame_number;
>> + data->frame[i].cntbase = frame->base_address;
>> + /*
>> + * We can NOT get the size info from GTDT table,
>> + * but according to "Table * CNTBaseN memory map" of
>> + * <ARM Architecture Reference Manual> for ARMv8,
>> + * it should be 4KB(Offset 0x000 ? 0xFFC).
>
> See above.
yes, you are right, I will fix both comments
>
>> + */
>> + data->frame[i].size = SZ_4K;
>> + }
>> +
>> + if (acpi_gtdt_desc.timer_block_count)
>> + pr_info("parsed No.%d of %d memory-mapped timer block(s).\n",
>> + index, acpi_gtdt_desc.timer_block_count);
>
> I am not sure how helpful this message can be honestly.
yup, I will simplify it :-)
>
>> +
>> + return 0;
>> +}
>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>> index a1611d1..44b8c1b 100644
>> --- a/include/linux/acpi.h
>> +++ b/include/linux/acpi.h
>> @@ -582,6 +582,7 @@ int acpi_gtdt_init(struct acpi_table_header *table);
>> int acpi_gtdt_map_ppi(int type);
>> bool acpi_gtdt_c3stop(int type);
>> void acpi_gtdt_release(void);
>> +int gtdt_arch_timer_mem_init(struct arch_timer_mem *data, unsigned int index);
>
> See above.
>
> Overall it looks fine as long as the interface with clocksource is
> settled, which is what really needs to be agreed upon in this series.
Thanks for your help :-)
>
> Lorenzo
>
>> #endif
>>
>> #else /* !CONFIG_ACPI */
>> --
>> 2.7.4
>>
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH v16 11/15] acpi/arm64: Add GTDT table parse driver
From: Fu Wei @ 2016-11-23 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118201250.GO1197@leverpostej>
Hi Mark,
On 19 November 2016 at 04:12, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Nov 16, 2016 at 09:49:04PM +0800, fu.wei at linaro.org wrote:
>
>> +#define for_each_platform_timer(_g) for (; _g; _g = next_platform_timer(_g))
>
> This doesn't fit the usual for_each_* pattern, since _g has to be
> manually initialised first. Either come up with a way of maknig this fit
> the usual pattern, or get rid of this, and use:
>
> t = however_you_get_the_first_timer();
>
> if (!t)
> bailt_out_somehow();
>
> do {
> ...
> } while (t = next_platform_timer(t));
Thanks, will do
>
>> +/*
>> + * Release the memory we have allocated in acpi_gtdt_init.
>> + * This should be called, when the driver who called "acpi_gtdt_init" previously
>> + * doesn't need the GTDT info anymore.
>> + */
>> +void __init acpi_gtdt_release(void)
>> +{
>> + kfree(timer_block);
>> + kfree(watchdog);
>> + timer_block = NULL;
>> + watchdog = NULL;
>> +}
>
> Why is this not simply in the error path of acpi_gtdt_init()?
>
>> +
>> +/*
>> + * Get some basic info from GTDT table, and init the global variables above
>> + * for all timers initialization of Generic Timer.
>> + * This function does some validation on GTDT table.
>> + */
>> +int __init acpi_gtdt_init(struct acpi_table_header *table)
>> +{
>
>> + timer_block = kcalloc(timer_count,
>> + sizeof(struct acpi_gtdt_timer_block *),
>> + GFP_KERNEL);
>> + if (!timer_block)
>> + return -ENOMEM;
>> +
>> + watchdog = kcalloc(timer_count, sizeof(struct acpi_gtdt_watchdog *),
>> + GFP_KERNEL);
>> + if (!watchdog) {
>> + kfree(timer_block);
>> + timer_block = NULL;
>> + return -ENOMEM;
>> + }
>
> Please have a common error path below, and branch to that when you need
> to free these.
OK , will do
>
>> +error:
>> + acpi_gtdt_release();
>> + return -EINVAL;
>> +}
>
> [...]
>
>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>> index 61a3d90..a1611d1 100644
>> --- a/include/linux/acpi.h
>> +++ b/include/linux/acpi.h
>> @@ -577,6 +577,13 @@ enum acpi_reconfig_event {
>> int acpi_reconfig_notifier_register(struct notifier_block *nb);
>> int acpi_reconfig_notifier_unregister(struct notifier_block *nb);
>>
>> +#ifdef CONFIG_ACPI_GTDT
>> +int acpi_gtdt_init(struct acpi_table_header *table);
>> +int acpi_gtdt_map_ppi(int type);
>> +bool acpi_gtdt_c3stop(int type);
>> +void acpi_gtdt_release(void);
>
> Why do these need to be here?
>
> What possible value is ther in exporting acpi_gtdt_release() !?
because I need to release these after mem timer init,
But like your comment in 14/15, if I fill in the entire arch_timer_mem
in one go, I don't need to export acpi_gtdt_release.
Will try this way in v17
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH v2 1/3] ARM: davinci: da8xx: Fix ohci device name
From: Sekhar Nori @ 2016-11-23 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103160308.29588-2-ahaslam@baylibre.com>
On Thursday 03 November 2016 09:33 PM, Axel Haslam wrote:
> While the clk lookup table is making reference to "ohci"
> other subsystems (such as phy) are trying to match "ohci.0"
>
> Since there is a single ohci instance, instead of changing
> the clk name, change the dev id to -1, and add the "-da8xx"
> postfix to match the driver name that will also be changed
> in a subsequent patch.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Applied to v4.10/soc
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 1/3] of: base: add support to get machine compatible string
From: Sudeep Holla @ 2016-11-23 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ff1ea88a-87c6-6721-8e63-ddb05900cc58@ti.com>
On 23/11/16 11:47, Sekhar Nori wrote:
> On Wednesday 23 November 2016 03:35 PM, Sudeep Holla wrote:
>>
>>
>> On 23/11/16 07:49, Sekhar Nori wrote:
>>> On Tuesday 22 November 2016 09:16 PM, Sudeep Holla wrote:
>>>> Hi Sekhar,
>>>>
>>>> On 22/11/16 15:06, Sekhar Nori wrote:
>>>>> Hi Sudeep,
>>>>>
>>>>> On Tuesday 22 November 2016 04:23 PM, Sudeep Holla wrote:
>>>>>>
>>>>>>
>>>>>> On 22/11/16 10:41, Bartosz Golaszewski wrote:
>>>>>>> Add a function allowing to retrieve the compatible string of the root
>>>>>>> node of the device tree.
>>>>>>>
>>>>>>
>>>>>> Rob has queued [1] and it's in -next today. You can reuse that if you
>>>>>> are planning to target this for v4.11 or just use open coding in your
>>>>>> driver for v4.10 and target this move for v4.11 to avoid cross tree
>>>>>> dependencies as I already mentioned in your previous thread.
>>>>>
>>>>> I dont have your original patch in my mailbox, but I wonder if
>>>>> returning a pointer to property string for a node whose reference has
>>>>> already been released is safe to do? Probably not an issue for the root
>>>>> node, but still feels counter-intuitive.
>>>>>
>>>>
>>>> I am not sure if I understand the issue here. Are you referring a case
>>>> where of_root is freed ?
>>>
>>> Yes, right, thats what I was hinting at. Since you are giving up the
>>> reference to the device node before the function returns, the user can
>>> be left with a dangling reference.
>>>
>>
>> Yes I agree.
>
> So, the if(!of_node_get()) is just an expensive NULL pointer check. I think
> it is better to be explicit about it by not using of_node_get/put() at all.
> How about:
>
Are we planning to use this in any time sensitive paths? Anyways I am
fine removing them.
> +int of_machine_get_model_name(const char **model)
> +{
> + int error;
> +
> + if (!of_root)
> + return -EINVAL;
> +
> + error = of_property_read_string(of_root, "model", model);
> + if (error)
> + error = of_property_read_string_index(of_root, "compatible",
> + 0, model);
> + return error;
> +}
> +EXPORT_SYMBOL(of_machine_get_model_name);
>
> I know the patch is already in -next so I guess it depends on how strongly
> Rob feels about this.
Frank expressed his concerns and it may be reverted.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 1/3] of: base: add support to get machine compatible string
From: Sekhar Nori @ 2016-11-23 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f0ba1a7a-8948-21c3-8a96-d46bf105bb7e@arm.com>
On Wednesday 23 November 2016 05:37 PM, Sudeep Holla wrote:
>> So, the if(!of_node_get()) is just an expensive NULL pointer check. I
>> think
>> it is better to be explicit about it by not using of_node_get/put() at
>> all.
>> How about:
>>
>
> Are we planning to use this in any time sensitive paths? Anyways I am
> fine removing them.
Not worried about the time taken as much as it serving as a bad example
and getting carried over to other places where the impact might actually
be real.
>
>> +int of_machine_get_model_name(const char **model)
>> +{
>> + int error;
>> +
>> + if (!of_root)
>> + return -EINVAL;
>> +
>> + error = of_property_read_string(of_root, "model", model);
>> + if (error)
>> + error = of_property_read_string_index(of_root,
>> "compatible",
>> + 0, model);
>> + return error;
>> +}
>> +EXPORT_SYMBOL(of_machine_get_model_name);
>>
>> I know the patch is already in -next so I guess it depends on how
>> strongly
>> Rob feels about this.
>
> Frank expressed his concerns and it may be reverted.
Didn't notice that. I will check that thread. Thanks!
Regards,
Sekhar
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Måns Rullgård @ 2016-11-23 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58356EA8.2010806@free.fr>
Mason <slash.tmp@free.fr> writes:
> Hello,
>
> On my platform, setting up a DMA transfer is a two-step process:
>
> 1) configure the "switch box" to connect a device to a memory channel
> 2) configure the transfer details (address, size, command)
>
> When the transfer is done, the sbox setup can be torn down,
> and the DMA driver can start another transfer.
>
> The current software architecture for my NFC (NAND Flash controller)
> driver is as follows (for one DMA transfer).
>
> sg_init_one
> dma_map_sg
> dmaengine_prep_slave_sg
> dmaengine_submit
> dma_async_issue_pending
> configure_NFC_transfer
> wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT
> wait_for_NFC_idle
> dma_unmap_sg
>
> The problem is that the DMA driver tears down the sbox setup
> as soon as it receives the IRQ. However, when writing to the
> device, the interrupt only means "I have pushed all data from
> memory to the memory channel". These data have not reached
> the device yet, and may still be "in flight". Thus the sbox
> setup can only be torn down after the NFC is idle.
>
> How do I call back into the DMA driver after wait_for_NFC_idle,
> to request sbox tear down?
>
> The new architecture would become:
>
> sg_init_one
> dma_map_sg
> dmaengine_prep_slave_sg
> dmaengine_submit
> dma_async_issue_pending
> configure_NFC_transfer
> wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT
> wait_for_NFC_idle
> request_sbox_tear_down /*** HOW TO DO THAT ***/
> dma_unmap_sg
>
> As far as I can tell, my NFC driver should call dmaengine_synchronize ??
> (In other words request_sbox_tear_down == dmaengine_synchronize)
>
> So the DMA driver should implement the device_synchronize hook,
> and tear the sbox down in that function.
>
> Is that correct? Or am I on the wrong track?
dmaengine_synchronize() is not meant for this. See the documentation:
/**
* dmaengine_synchronize() - Synchronize DMA channel termination
* @chan: The channel to synchronize
*
* Synchronizes to the DMA channel termination to the current context. When this
* function returns it is guaranteed that all transfers for previously issued
* descriptors have stopped and and it is safe to free the memory assoicated
* with them. Furthermore it is guaranteed that all complete callback functions
* for a previously submitted descriptor have finished running and it is safe to
* free resources accessed from within the complete callbacks.
*
* The behavior of this function is undefined if dma_async_issue_pending() has
* been called between dmaengine_terminate_async() and this function.
*
* This function must only be called from non-atomic context and must not be
* called from within a complete callback of a descriptor submitted on the same
* channel.
*/
This is for use after a dmaengine_terminate_async() call to wait for the
dma engine to finish whatever it was doing. This is not the problem
here. Your problem is that the dma engine interrupt fires before the
transfer is actually complete. Although you get an indication from the
target device when it has received all the data, there is no way to make
the dma driver wait for this.
--
M?ns Rullg?rd
^ permalink raw reply
* [PATCH 0/3] arm64: dts: r8a7796: Add CAN/CAN FD support
From: Chris Paterson @ 2016-11-23 12:14 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds CAN and CAN FD support to the r8a7796.
Based on renesas-devel-20161122-v4.9-rc6.
Chris Paterson (3):
arm64: dts: r8a7796: Add CAN external clock support
arm64: dts: r8a7796: Add CAN support
arm64: dts: r8a7796: Add CAN FD support
.../devicetree/bindings/net/can/rcar_can.txt | 12 +++--
.../devicetree/bindings/net/can/rcar_canfd.txt | 12 +++--
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 61 ++++++++++++++++++++++
3 files changed, 75 insertions(+), 10 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/3] arm64: dts: r8a7796: Add CAN external clock support
From: Chris Paterson @ 2016-11-23 12:14 UTC (permalink / raw)
To: linux-arm-kernel
Adds external CAN clock node for r8a7796. This clock can be used as
fCAN clock of CAN and CAN FD controller.
Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 41a050d..91d716e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -69,6 +69,13 @@
clock-frequency = <0>;
};
+ /* External CAN clock - to be overridden by boards that provide it */
+ can_clk: can {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
/* External SCIF clock - to be overridden by boards that provide it */
scif_clk: scif {
compatible = "fixed-clock";
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: r8a7796: Add CAN support
From: Chris Paterson @ 2016-11-23 12:14 UTC (permalink / raw)
To: linux-arm-kernel
Adds CAN controller nodes for r8a7796.
Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
---
.../devicetree/bindings/net/can/rcar_can.txt | 12 +++++----
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 30 ++++++++++++++++++++++
2 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
index 8d40ab2..06bb7cc 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
@@ -10,6 +10,7 @@ Required properties:
"renesas,can-r8a7793" if CAN controller is a part of R8A7793 SoC.
"renesas,can-r8a7794" if CAN controller is a part of R8A7794 SoC.
"renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC.
+ "renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC.
"renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device.
"renesas,rcar-gen2-can" for a generic R-Car Gen2 compatible device.
"renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device.
@@ -24,11 +25,12 @@ Required properties:
- pinctrl-0: pin control group to be used for this controller.
- pinctrl-names: must be "default".
-Required properties for "renesas,can-r8a7795" compatible:
-In R8A7795 SoC, "clkp2" can be CANFD clock. This is a div6 clock and can be
-used by both CAN and CAN FD controller at the same time. It needs to be scaled
-to maximum frequency if any of these controllers use it. This is done using
-the below properties.
+Required properties for "renesas,can-r8a7795" and "renesas,can-r8a7796"
+compatible:
+In R8A7795 and R8A7796 SoCs, "clkp2" can be CANFD clock. This is a div6 clock
+and can be used by both CAN and CAN FD controller at the same time. It needs to
+be scaled to maximum frequency if any of these controllers use it. This is done
+using the below properties:
- assigned-clocks: phandle of clkp2(CANFD) clock.
- assigned-clock-rates: maximum frequency of this clock.
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 91d716e..95857fc 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -362,6 +362,36 @@
status = "disabled";
};
+ can0: can at e6c30000 {
+ compatible = "renesas,can-r8a7796",
+ "renesas,rcar-gen3-can";
+ reg = <0 0xe6c30000 0 0x1000>;
+ interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 916>,
+ <&cpg CPG_CORE R8A7796_CLK_CANFD>,
+ <&can_clk>;
+ clock-names = "clkp1", "clkp2", "can_clk";
+ assigned-clocks = <&cpg CPG_CORE R8A7796_CLK_CANFD>;
+ assigned-clock-rates = <40000000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ can1: can at e6c38000 {
+ compatible = "renesas,can-r8a7796",
+ "renesas,rcar-gen3-can";
+ reg = <0 0xe6c38000 0 0x1000>;
+ interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 915>,
+ <&cpg CPG_CORE R8A7796_CLK_CANFD>,
+ <&can_clk>;
+ clock-names = "clkp1", "clkp2", "can_clk";
+ assigned-clocks = <&cpg CPG_CORE R8A7796_CLK_CANFD>;
+ assigned-clock-rates = <40000000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
scif2: serial at e6e88000 {
compatible = "renesas,scif-r8a7796",
"renesas,rcar-gen3-scif", "renesas,scif";
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: r8a7796: Add CAN FD support
From: Chris Paterson @ 2016-11-23 12:14 UTC (permalink / raw)
To: linux-arm-kernel
Adds CAN FD controller node for r8a7796.
Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
---
.../devicetree/bindings/net/can/rcar_canfd.txt | 12 ++++++-----
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 24 ++++++++++++++++++++++
2 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
index 22a6f10..788f273 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
@@ -5,6 +5,7 @@ Required properties:
- compatible: Must contain one or more of the following:
- "renesas,rcar-gen3-canfd" for R-Car Gen3 compatible controller.
- "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller.
+ - "renesas,r8a7796-canfd" for R8A7796 (R-Car M3) compatible controller.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first, followed by the
@@ -23,11 +24,12 @@ The name of the child nodes are "channel0" and "channel1" respectively. Each
child node supports the "status" property only, which is used to
enable/disable the respective channel.
-Required properties for "renesas,r8a7795-canfd" compatible:
-In R8A7795 SoC, canfd clock is a div6 clock and can be used by both CAN
-and CAN FD controller at the same time. It needs to be scaled to maximum
-frequency if any of these controllers use it. This is done using the
-below properties.
+Required properties for "renesas,r8a7795-canfd" and "renesas,r8a7796-canfd"
+compatible:
+In R8A7795 and R8A7796 SoCs, canfd clock is a div6 clock and can be used by both
+CAN and CAN FD controller at the same time. It needs to be scaled to maximum
+frequency if any of these controllers use it. This is done using the below
+properties:
- assigned-clocks: phandle of canfd clock.
- assigned-clock-rates: maximum frequency of this clock.
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 95857fc..c069d77 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -392,6 +392,30 @@
status = "disabled";
};
+ canfd: can at e66c0000 {
+ compatible = "renesas,r8a7796-canfd",
+ "renesas,rcar-gen3-canfd";
+ reg = <0 0xe66c0000 0 0x8000>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 914>,
+ <&cpg CPG_CORE R8A7796_CLK_CANFD>,
+ <&can_clk>;
+ clock-names = "fck", "canfd", "can_clk";
+ assigned-clocks = <&cpg CPG_CORE R8A7796_CLK_CANFD>;
+ assigned-clock-rates = <40000000>;
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ status = "disabled";
+
+ channel0 {
+ status = "disabled";
+ };
+
+ channel1 {
+ status = "disabled";
+ };
+ };
+
scif2: serial at e6e88000 {
compatible = "renesas,scif-r8a7796",
"renesas,rcar-gen3-scif", "renesas,scif";
--
1.9.1
^ permalink raw reply related
* [PATCH 1/3] of: base: add support to get machine compatible string
From: Sudeep Holla @ 2016-11-23 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <11467504-c700-cbfa-a945-be9ec8776144@ti.com>
On 23/11/16 12:13, Sekhar Nori wrote:
> On Wednesday 23 November 2016 05:37 PM, Sudeep Holla wrote:
>>> So, the if(!of_node_get()) is just an expensive NULL pointer check. I
>>> think
>>> it is better to be explicit about it by not using of_node_get/put() at
>>> all.
>>> How about:
>>>
>>
>> Are we planning to use this in any time sensitive paths? Anyways I am
>> fine removing them.
>
> Not worried about the time taken as much as it serving as a bad example
> and getting carried over to other places where the impact might actually
> be real.
>
Ah OK, sure.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v16 14/15] clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer
From: Fu Wei @ 2016-11-23 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118202000.GP1197@leverpostej>
Hi Mark,
On 19 November 2016 at 04:20, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Nov 16, 2016 at 09:49:07PM +0800, fu.wei at linaro.org wrote:
>> From: Fu Wei <fu.wei@linaro.org>
>>
>> The patch add memory-mapped timer register support by using the
>> information provided by the new GTDT driver of ACPI.
>>
>> Signed-off-by: Fu Wei <fu.wei@linaro.org>
>> ---
>> drivers/clocksource/arm_arch_timer.c | 26 +++++++++++++++++++++++++-
>> 1 file changed, 25 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
>> index c494ca8..0aad60a 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -1067,7 +1067,28 @@ CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
>> arch_timer_mem_of_init);
>>
>> #ifdef CONFIG_ACPI_GTDT
>> -/* Initialize per-processor generic timer */
>> +static int __init arch_timer_mem_acpi_init(void)
>> +{
>> + struct arch_timer_mem *timer_mem;
>> + int ret = 0;
>> + int i = 0;
>> +
>> + timer_mem = kzalloc(sizeof(*timer_mem), GFP_KERNEL);
>
> Why do you need it zeroed? You don't clear it between iterations, so
> either you don't need this, or you have a bug in the loop.
>
>> + if (!timer_mem)
>> + return -ENOMEM;
>> +
>> + while (!gtdt_arch_timer_mem_init(timer_mem, i)) {
>
> Huh?
>
> Why doesn't GTDT expose a function to fill in the entire arch_timer_mem
> in one go?
Yes, that is a good idea, but I need to find a way to get the number of
GT block in GTDT, then allocate a struct arch_timer_mem array for all GT block
>
> There shouldn't be multiple instances, as far as I am aware. Am I
> mistaken?
I don't see any doc says : there is only one memory-mapped timer
in a soc.
Maybe we have more than one GT block in GTDT or
(in another word) we may have more than one memory-mapped
timer in a soc, right ??
Please correct me, If I miss something.
>
>> + ret = arch_timer_mem_init(timer_mem);
>> + if (ret)
>> + break;
>> + i++;
>> + }
>> +
>> + kfree(timer_mem);
>> + return ret;
>> +}
>
>
> Regardless, arch_timer_mem is small enough that you don't need dynamic
> allocaiton. Just put it on the stack, e.g.
>
> static int __init arch_timer_mem_acpi_init(void)
> {
> int i = 0;
> struct arch_timer_mem timer_mem;
>
> while (!gtdt_arch_timer_mem_init(timer_mem, i)) {
> int ret = arch_timer_mem_init();
> if (ret)
> return ret;
> i++
> }
>
> return 0;
> }
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH v2 1/2] ARM64: dts: Add support for Meson GXM
From: Martin Blumenstingl @ 2016-11-23 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122100046.25899-2-narmstrong@baylibre.com>
On Tue, Nov 22, 2016 at 11:00 AM, Neil Armstrong
<narmstrong@baylibre.com> wrote:
> Following the Amlogic Linux kernel, it seem the only differences
> between the GXL and GXM SoCs are the CPU Clusters.
>
> This commit renames the gxl-s905d-p23x DTSI in a common file for
> S905D p23x and S912 q20x boards.
>
> Then adds a meson-gxm dtsi and reproduce the P23x to Q20x boards
> dts files since the S905D and S912 SoCs shares the same pinout
> and the P23x and Q20x boards are identical.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
I have tested this successfully on a Mecool BB2 (similar to the Q200
reference board).
^ permalink raw reply
* [PATCH v3 1/3] bus: da8xx-mstpri: drop the call to of_flat_dt_get_machine_name()
From: Sekhar Nori @ 2016-11-23 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479899187-10199-2-git-send-email-bgolaszewski@baylibre.com>
Hi Bartosz,
On Wednesday 23 November 2016 04:36 PM, Bartosz Golaszewski wrote:
> In order to avoid a section mismatch use a locally implemented routine
> instead of of_flat_dt_get_machine_name() when printing the error
> message.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> drivers/bus/da8xx-mstpri.c | 23 +++++++++++++++++++++--
> 1 file changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bus/da8xx-mstpri.c b/drivers/bus/da8xx-mstpri.c
> index 85f0b53..064eeb9 100644
> --- a/drivers/bus/da8xx-mstpri.c
> +++ b/drivers/bus/da8xx-mstpri.c
> @@ -16,7 +16,6 @@
> #include <linux/platform_device.h>
> #include <linux/io.h>
> #include <linux/regmap.h>
> -#include <linux/of_fdt.h>
>
> /*
> * REVISIT: Linux doesn't have a good framework for the kind of performance
> @@ -190,6 +189,26 @@ static const struct da8xx_mstpri_board_priorities da8xx_mstpri_board_confs[] = {
> },
> };
>
> +/*
> + * FIXME Remove this function once of/base gets a general routine for getting
> + * the machine model/compatible string.
> + */
> +static const char *da8xx_mstpri_machine_get_compatible(void)
> +{
> + struct device_node *root;
> + const char *compatible;
> + int ret = -1;
> +
> + root = of_find_node_by_path("/");
> + if (root) {
> + ret = of_property_read_string_index(root, "compatible",
> + 0, &compatible);
> + of_node_put(root);
> + }
> +
> + return ret ? NULL : compatible;
> +}
As I just noted in the thread for v1 of this patch, calling
of_node_put(root) while keeping a reference to its compatible property
for later use sounds really broken.
I think it is safest to fix this by not including the compatible name in
error message at all. The error message will be little less descriptive,
but thats better than adding questionable code.
Thats what Frank suggested first up, but I did not realize at that time
that printing compatible name will be this much effort.
Can you please send a v4?
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] PCI: Add information about describing PCI in ACPI
From: Lorenzo Pieralisi @ 2016-11-23 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-TW__+eZFS2p=1ZLN7fBs7pqQ+SitbEX46Z4JiS64egA@mail.gmail.com>
On Wed, Nov 23, 2016 at 07:28:12AM +0000, Ard Biesheuvel wrote:
> On 23 November 2016 at 01:06, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Tue, Nov 22, 2016 at 10:09:50AM +0000, Ard Biesheuvel wrote:
> >> On 17 November 2016 at 17:59, Bjorn Helgaas <bhelgaas@google.com> wrote:
> >
> >> > +PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should
> >> > +describe all the address space they consume. In principle, this would
> >> > +be all the windows they forward down to the PCI bus, as well as the
> >> > +bridge registers themselves. The bridge registers include things like
> >> > +secondary/subordinate bus registers that determine the bus range below
> >> > +the bridge, window registers that describe the apertures, etc. These
> >> > +are all device-specific, non-architected things, so the only way a
> >> > +PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which
> >> > +contain the device-specific details. These bridge registers also
> >> > +include ECAM space, since it is consumed by the bridge.
> >> > +
> >> > +ACPI defined a Producer/Consumer bit that was intended to distinguish
> >> > +the bridge apertures from the bridge registers [4, 5]. However,
> >> > +BIOSes didn't use that bit correctly, and the result is that OSes have
> >> > +to assume that everything in a PCI host bridge _CRS is a window. That
> >> > +leaves no way to describe the bridge registers in the PNP0A03/PNP0A08
> >> > +device itself.
> >>
> >> Is that universally true? Or is it still possible to do the right
> >> thing here on new ACPI architectures such as arm64?
> >
> > That's a very good question. I had thought that the ACPI spec had
> > given up on Consumer/Producer completely, but I was wrong. In the 6.0
> > spec, the Consumer/Producer bit is still documented in the Extended
> > Address Space Descriptor (sec 6.4.3.5.4). It is documented as
> > "ignored" in the QWord, DWord, and Word descriptors (sec 6.4.3.5.1,2,3).
> >
> > Linux looks at the producer_consumer bit in acpi_decode_space(), which
> > I think is used for all these descriptors (QWord, DWord, Word, and
> > Extended). This doesn't quite follow the spec -- we probably should
> > ignore it except for Extended. In any event, acpi_decode_space() sets
> > IORESOURCE_WINDOW for Producer descriptors, but we don't test
> > IORESOURCE_WINDOW in the PCI host bridge code.
> >
> > x86 and ia64 supply their own pci_acpi_root_prepare_resources()
> > functions that call acpi_pci_probe_root_resources(), which parses _CRS
> > and looks at producer_consumer. Then they do a little arch-specific
> > stuff on the result.
> >
> > On arm64 we use acpi_pci_probe_root_resources() directly, with no
> > arch-specific stuff.
> >
> > On all three arches, we ignore the Consumer/Producer bit, so all the
> > resources are treated as Producers, e.g., as bridge windows.
> >
> > I think we *could* implement an arm64 version of
> > pci_acpi_root_prepare_resources() that would pay attention to the
> > Consumer/Producer bit by checking IORESOURCE_WINDOW. To be spec
> > compliant, we would have to use Extended descriptors for all bridge
> > windows, even if they would fit in a DWord or QWord.
> >
> > Should we do that? I dunno. I'd like to hear your opinion(s).
> >
>
> Yes, I think we should. If the spec allows for a way for a PNP0A03
> device to describe all of its resources unambiguously, we should not
> be relying on workarounds that were designed for another architecture
> in another decade (for, presumably, another OS)
That was the idea I floated at LPC16. We can override the
acpi_pci_root_ops prepare_resources() function pointer with a function
that checks IORESOURCE_WINDOW and filters resources accordingly (and
specific quirk "drivers" may know how to intepret resources that aren't
IORESOURCE_WINDOW - ie they can use it to describe the PCI ECAM config
space quirk region in their _CRS).
In a way that's something that makes sense anyway because given
that we are starting from a clean slate on ARM64 considering resources
that are not IORESOURCE_WINDOW as host bridge windows is just something
we are inheriting from x86, it is not really ACPI specs compliant (is
it ?).
> Just for my understanding, we will need to use extended descriptors
> for all consumed *and* produced regions, even though dword/qword are
> implicitly produced-only, due to the fact that the bit is ignored?
That's something that has to be clarified within the ASWG ie why the
consumer bit is ignored for *some* descriptors and not for others.
As things stand unfortunately the answer seems yes (I do not know
why).
> > It *would* be nice to have bridge registers in the bridge _CRS. That
> > would eliminate the need for looking up the HISI0081/PNP0C02 devices
> > to find the bridge registers. Avoiding that lookup is only a
> > temporary advantage -- the next round of bridges are supposed to fully
> > implement ECAM, and then we won't need to know where the registers
> > are.
> >
> > Apart from the lookup, there's still some advantage in describing the
> > registers in the PNP0A03 device instead of an unrelated PNP0C02
> > device, because it makes /proc/iomem more accurate and potentially
> > makes host bridge hotplug cleaner. We would have to enhance the host
> > bridge driver to do the reservations currently done by pnp/system.c.
> >
> > There's some value in doing it the same way as on x86, even though
> > that way is somewhat broken.
> >
> > Whatever we decide, I think it's very important to get it figured out
> > ASAP because it affects the ECAM quirks that we're trying to merge in
> > v4.10.
> >
>
> I agree. What exactly is the impact for the quirks mechanism as proposed?
The impact is that we could just use the PNP0A03 _CRS to report the PCI
ECAM config space quirk region through a consumer resource keeping in
mind what I say above (actually I think that's what was done on APM
firmware initially, for the records).
Lorenzo
^ permalink raw reply
* [git pull] soc_device_match() interface for matching against soc_bus attributes
From: Geert Uytterhoeven @ 2016-11-23 12:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Kevin, Arnd,
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git tags/soc-device-match-tag1
for you to fetch changes up to da65a1589dacc7ec44ea0557a14d70a39d991f32:
base: soc: Provide a dummy implementation of soc_device_match() (2016-11-10 10:10:37 +0100)
----------------------------------------------------------------
soc_device_match() interface for matching against soc_bus attributes
This provides core infrastructure as a dependency for several users
(Freescale/NXP, Samsung, Renesas).
Its core parts have been acked by Greg, and the fixes by Arnd and/or
Greg (the last fix only received an informal ack, that's why I hadn't
added the ack).
This has already been pulled by Ulf, and is present in mmc/next, as a
dependency for a Freescale/NXP driver update.
Thanks for pulling!
----------------------------------------------------------------
Arnd Bergmann (1):
base: soc: Introduce soc_device_match() interface
Geert Uytterhoeven (3):
base: soc: Early register bus when needed
base: soc: Check for NULL SoC device attributes
base: soc: Provide a dummy implementation of soc_device_match()
drivers/base/Kconfig | 1 +
drivers/base/soc.c | 79 +++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/sys_soc.h | 9 ++++++
3 files changed, 89 insertions(+)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [git pull] Renesas RZ/G1M and RZ/G1E CPG Core Clock Definitions
From: Geert Uytterhoeven @ 2016-11-23 12:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Kevin, Arnd,
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git tags/rzg-clock-defs-tag1
for you to fetch changes up to 1fa8a875df6b8aa864f6c4f2b65dbc2ed477b859:
clk: renesas: Add r8a7745 CPG Core Clock Definitions (2016-11-07 15:13:30 +0100)
----------------------------------------------------------------
Renesas RZ/G1M and RZ/G1E CPG Core Clock Definitions
This contains clock definitions shared by clock drivers and DTS files,
and is provided as a dependency for the latter.
This has already been pulled by Stephen as part of a larger pull
request, and is present in clk/clk-next, together with the corresponding
clock drivers.
Thanks for pulling!
----------------------------------------------------------------
Sergei Shtylyov (2):
clk: renesas: Add r8a7743 CPG Core Clock Definitions
clk: renesas: Add r8a7745 CPG Core Clock Definitions
include/dt-bindings/clock/r8a7743-cpg-mssr.h | 43 +++++++++++++++++++++++++++
include/dt-bindings/clock/r8a7745-cpg-mssr.h | 44 ++++++++++++++++++++++++++++
2 files changed, 87 insertions(+)
create mode 100644 include/dt-bindings/clock/r8a7743-cpg-mssr.h
create mode 100644 include/dt-bindings/clock/r8a7745-cpg-mssr.h
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Mason @ 2016-11-23 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xpolmbdih.fsf@unicorn.mansr.com>
On 23/11/2016 13:13, M?ns Rullg?rd wrote:
> Mason wrote:
>
>> On my platform, setting up a DMA transfer is a two-step process:
>>
>> 1) configure the "switch box" to connect a device to a memory channel
>> 2) configure the transfer details (address, size, command)
>>
>> When the transfer is done, the sbox setup can be torn down,
>> and the DMA driver can start another transfer.
>>
>> The current software architecture for my NFC (NAND Flash controller)
>> driver is as follows (for one DMA transfer).
>>
>> sg_init_one
>> dma_map_sg
>> dmaengine_prep_slave_sg
>> dmaengine_submit
>> dma_async_issue_pending
>> configure_NFC_transfer
>> wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT
>> wait_for_NFC_idle
>> dma_unmap_sg
>>
>> The problem is that the DMA driver tears down the sbox setup
>> as soon as it receives the IRQ. However, when writing to the
>> device, the interrupt only means "I have pushed all data from
>> memory to the memory channel". These data have not reached
>> the device yet, and may still be "in flight". Thus the sbox
>> setup can only be torn down after the NFC is idle.
>>
>> How do I call back into the DMA driver after wait_for_NFC_idle,
>> to request sbox tear down?
>>
>> The new architecture would become:
>>
>> sg_init_one
>> dma_map_sg
>> dmaengine_prep_slave_sg
>> dmaengine_submit
>> dma_async_issue_pending
>> configure_NFC_transfer
>> wait_for_IRQ_from_DMA_engine // via DMA_PREP_INTERRUPT
>> wait_for_NFC_idle
>> request_sbox_tear_down /*** HOW TO DO THAT ***/
>> dma_unmap_sg
>>
>> As far as I can tell, my NFC driver should call dmaengine_synchronize ??
>> (In other words request_sbox_tear_down == dmaengine_synchronize)
>>
>> So the DMA driver should implement the device_synchronize hook,
>> and tear the sbox down in that function.
>>
>> Is that correct? Or am I on the wrong track?
>
> dmaengine_synchronize() is not meant for this. See the documentation:
>
> /**
> * dmaengine_synchronize() - Synchronize DMA channel termination
> * @chan: The channel to synchronize
> *
> * Synchronizes to the DMA channel termination to the current context. When this
> * function returns it is guaranteed that all transfers for previously issued
> * descriptors have stopped and and it is safe to free the memory assoicated
> * with them. Furthermore it is guaranteed that all complete callback functions
> * for a previously submitted descriptor have finished running and it is safe to
> * free resources accessed from within the complete callbacks.
> *
> * The behavior of this function is undefined if dma_async_issue_pending() has
> * been called between dmaengine_terminate_async() and this function.
> *
> * This function must only be called from non-atomic context and must not be
> * called from within a complete callback of a descriptor submitted on the same
> * channel.
> */
>
> This is for use after a dmaengine_terminate_async() call to wait for the
> dma engine to finish whatever it was doing. This is not the problem
> here. Your problem is that the dma engine interrupt fires before the
> transfer is actually complete. Although you get an indication from the
> target device when it has received all the data, there is no way to make
> the dma driver wait for this.
Hello Mans,
I'm confused. Are you saying there is no solution to my problem
within the existing DMA framework?
In its current form, the tangox-dma.c driver will fail randomly
for writes to a device (SATA, NFC).
Maybe an extra hook can be added to the DMA framework?
I'd like to hear from the framework's maintainers. Perhaps they
can provide some guidance.
Regards.
^ permalink raw reply
* [PATCH 0/7] efi: Pass secure boot mode to kernel [ver #3]
From: David Howells @ 2016-11-23 12:53 UTC (permalink / raw)
To: linux-arm-kernel
Here's a set of patches that can determine the secure boot state of the
UEFI BIOS and pass that along to the main kernel image. This involves
generalising ARM's efi_get_secureboot() function and making it mixed-mode
safe.
The patches can be found here also:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-secure-boot
at tag:
efi-secure-boot-20161123-2
Note that the patches are not terminal on the branch.
David
---
Ard Biesheuvel (1):
efi: use typed function pointers for runtime services table
David Howells (4):
x86/efi: Allow invocation of arbitrary runtime services
arm/efi: Allow invocation of arbitrary runtime services
efi: Add SHIM and image security database GUID definitions
efi: Get the secure boot status
Josh Boyer (2):
efi: Disable secure boot if shim is in insecure mode
efi: Add EFI_SECURE_BOOT bit
Documentation/x86/zero-page.txt | 2 +
arch/arm/include/asm/efi.h | 1
arch/arm64/include/asm/efi.h | 1
arch/x86/boot/compressed/eboot.c | 3 +
arch/x86/boot/compressed/head_32.S | 6 +-
arch/x86/boot/compressed/head_64.S | 8 +-
arch/x86/include/asm/efi.h | 5 ++
arch/x86/include/uapi/asm/bootparam.h | 3 +
arch/x86/kernel/setup.c | 5 ++
drivers/firmware/efi/libstub/Makefile | 2 -
drivers/firmware/efi/libstub/arm-stub.c | 46 --------------
drivers/firmware/efi/libstub/secureboot.c | 93 +++++++++++++++++++++++++++++
include/linux/efi.h | 42 +++++++------
13 files changed, 144 insertions(+), 73 deletions(-)
create mode 100644 drivers/firmware/efi/libstub/secureboot.c
^ permalink raw reply
* [PATCH 1/7] efi: use typed function pointers for runtime services table [ver #3]
From: David Howells @ 2016-11-23 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147990561294.7576.6464430479448167484.stgit@warthog.procyon.org.uk>
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Instead of using void pointers, and casting them to correctly typed
function pointers upon use, declare the runtime services pointers
as function pointers using their respective prototypes, for which
typedefs are already available.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: David Howells <dhowells@redhat.com>
---
include/linux/efi.h | 36 ++++++++++++++++++------------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/include/linux/efi.h b/include/linux/efi.h
index a07a476178cd..93a82de167eb 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -508,24 +508,6 @@ typedef struct {
u64 query_variable_info;
} efi_runtime_services_64_t;
-typedef struct {
- efi_table_hdr_t hdr;
- void *get_time;
- void *set_time;
- void *get_wakeup_time;
- void *set_wakeup_time;
- void *set_virtual_address_map;
- void *convert_pointer;
- void *get_variable;
- void *get_next_variable;
- void *set_variable;
- void *get_next_high_mono_count;
- void *reset_system;
- void *update_capsule;
- void *query_capsule_caps;
- void *query_variable_info;
-} efi_runtime_services_t;
-
typedef efi_status_t efi_get_time_t (efi_time_t *tm, efi_time_cap_t *tc);
typedef efi_status_t efi_set_time_t (efi_time_t *tm);
typedef efi_status_t efi_get_wakeup_time_t (efi_bool_t *enabled, efi_bool_t *pending,
@@ -560,6 +542,24 @@ typedef efi_status_t efi_query_variable_store_t(u32 attributes,
unsigned long size,
bool nonblocking);
+typedef struct {
+ efi_table_hdr_t hdr;
+ efi_get_time_t *get_time;
+ efi_set_time_t *set_time;
+ efi_get_wakeup_time_t *get_wakeup_time;
+ efi_set_wakeup_time_t *set_wakeup_time;
+ efi_set_virtual_address_map_t *set_virtual_address_map;
+ void *convert_pointer;
+ efi_get_variable_t *get_variable;
+ efi_get_next_variable_t *get_next_variable;
+ efi_set_variable_t *set_variable;
+ efi_get_next_high_mono_count_t *get_next_high_mono_count;
+ efi_reset_system_t *reset_system;
+ efi_update_capsule_t *update_capsule;
+ efi_query_capsule_caps_t *query_capsule_caps;
+ efi_query_variable_info_t *query_variable_info;
+} efi_runtime_services_t;
+
void efi_native_runtime_setup(void);
/*
^ permalink raw reply related
* [PATCH 2/7] x86/efi: Allow invocation of arbitrary runtime services [ver #3]
From: David Howells @ 2016-11-23 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147990561294.7576.6464430479448167484.stgit@warthog.procyon.org.uk>
Provide the ability to perform mixed-mode runtime service calls for x86 in
the same way that commit 0a637ee61247bd4bed9b2a07568ef7a1cfc76187
("x86/efi: Allow invocation of arbitrary boot services") provides the
ability to invoke arbitrary boot services.
Suggested-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: David Howells <dhowells@redhat.com>
---
arch/x86/boot/compressed/eboot.c | 1 +
arch/x86/boot/compressed/head_32.S | 6 +++---
arch/x86/boot/compressed/head_64.S | 8 ++++----
arch/x86/include/asm/efi.h | 5 +++++
4 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index ff01c8fc76f7..c8c32ebcdfdb 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -32,6 +32,7 @@ static void setup_boot_services##bits(struct efi_config *c) \
\
table = (typeof(table))sys_table; \
\
+ c->runtime_services = table->runtime; \
c->boot_services = table->boottime; \
c->text_output = table->con_out; \
}
diff --git a/arch/x86/boot/compressed/head_32.S b/arch/x86/boot/compressed/head_32.S
index fd0b6a272dd5..d85b9625e836 100644
--- a/arch/x86/boot/compressed/head_32.S
+++ b/arch/x86/boot/compressed/head_32.S
@@ -82,7 +82,7 @@ ENTRY(efi_pe_entry)
/* Relocate efi_config->call() */
leal efi32_config(%esi), %eax
- add %esi, 32(%eax)
+ add %esi, 40(%eax)
pushl %eax
call make_boot_params
@@ -108,7 +108,7 @@ ENTRY(efi32_stub_entry)
/* Relocate efi_config->call() */
leal efi32_config(%esi), %eax
- add %esi, 32(%eax)
+ add %esi, 40(%eax)
pushl %eax
2:
call efi_main
@@ -264,7 +264,7 @@ relocated:
#ifdef CONFIG_EFI_STUB
.data
efi32_config:
- .fill 4,8,0
+ .fill 5,8,0
.long efi_call_phys
.long 0
.byte 0
diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
index efdfba21a5b2..beab8322f72a 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -265,7 +265,7 @@ ENTRY(efi_pe_entry)
/*
* Relocate efi_config->call().
*/
- addq %rbp, efi64_config+32(%rip)
+ addq %rbp, efi64_config+40(%rip)
movq %rax, %rdi
call make_boot_params
@@ -285,7 +285,7 @@ handover_entry:
* Relocate efi_config->call().
*/
movq efi_config(%rip), %rax
- addq %rbp, 32(%rax)
+ addq %rbp, 40(%rax)
2:
movq efi_config(%rip), %rdi
call efi_main
@@ -457,14 +457,14 @@ efi_config:
#ifdef CONFIG_EFI_MIXED
.global efi32_config
efi32_config:
- .fill 4,8,0
+ .fill 5,8,0
.quad efi64_thunk
.byte 0
#endif
.global efi64_config
efi64_config:
- .fill 4,8,0
+ .fill 5,8,0
.quad efi_call
.byte 1
#endif /* CONFIG_EFI_STUB */
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index e99675b9c861..2f77bcefe6b4 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -191,6 +191,7 @@ static inline efi_status_t efi_thunk_set_virtual_address_map(
struct efi_config {
u64 image_handle;
u64 table;
+ u64 runtime_services;
u64 boot_services;
u64 text_output;
efi_status_t (*call)(unsigned long, ...);
@@ -226,6 +227,10 @@ static inline bool efi_is_64bit(void)
#define __efi_call_early(f, ...) \
__efi_early()->call((unsigned long)f, __VA_ARGS__);
+#define efi_call_runtime(f, ...) \
+ __efi_early()->call(efi_table_attr(efi_runtime_services, f, \
+ __efi_early()->runtime_services), __VA_ARGS__)
+
extern bool efi_reboot_required(void);
#else
^ permalink raw reply related
* [PATCH 3/7] arm/efi: Allow invocation of arbitrary runtime services [ver #3]
From: David Howells @ 2016-11-23 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147990561294.7576.6464430479448167484.stgit@warthog.procyon.org.uk>
efi_call_runtime() is provided for x86 to be able abstract mixed mode
support. Provide this for ARM also so that common code work in mixed mode
also.
Suggested-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: David Howells <dhowells@redhat.com>
---
arch/arm/include/asm/efi.h | 1 +
arch/arm64/include/asm/efi.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/include/asm/efi.h b/arch/arm/include/asm/efi.h
index 0b06f5341b45..e4e6a9d6a825 100644
--- a/arch/arm/include/asm/efi.h
+++ b/arch/arm/include/asm/efi.h
@@ -55,6 +55,7 @@ void efi_virtmap_unload(void);
#define efi_call_early(f, ...) sys_table_arg->boottime->f(__VA_ARGS__)
#define __efi_call_early(f, ...) f(__VA_ARGS__)
+#define efi_call_runtime(f, ...) sys_table_arg->runtime->f(__VA_ARGS__)
#define efi_is_64bit() (false)
#define efi_call_proto(protocol, f, instance, ...) \
diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index 771b3f0bc757..d74ae223d89f 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -49,6 +49,7 @@ int efi_set_mapping_permissions(struct mm_struct *mm, efi_memory_desc_t *md);
#define efi_call_early(f, ...) sys_table_arg->boottime->f(__VA_ARGS__)
#define __efi_call_early(f, ...) f(__VA_ARGS__)
+#define efi_call_runtime(f, ...) sys_table_arg->runtime->f(__VA_ARGS__)
#define efi_is_64bit() (true)
#define efi_call_proto(protocol, f, instance, ...) \
^ permalink raw reply related
* [PATCH 4/7] efi: Add SHIM and image security database GUID definitions [ver #3]
From: David Howells @ 2016-11-23 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147990561294.7576.6464430479448167484.stgit@warthog.procyon.org.uk>
Add the definitions for shim and image security database, both of which
are used widely in various Linux distros.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
include/linux/efi.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 93a82de167eb..c7904556d7a8 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -610,6 +610,9 @@ void efi_native_runtime_setup(void);
#define EFI_CONSOLE_OUT_DEVICE_GUID EFI_GUID(0xd3b36f2c, 0xd551, 0x11d4, 0x9a, 0x46, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
#define APPLE_PROPERTIES_PROTOCOL_GUID EFI_GUID(0x91bd12fe, 0xf6c3, 0x44fb, 0xa5, 0xb7, 0x51, 0x22, 0xab, 0x30, 0x3a, 0xe0)
+#define EFI_IMAGE_SECURITY_DATABASE_GUID EFI_GUID(0xd719b2cb, 0x3d3a, 0x4596, 0xa3, 0xbc, 0xda, 0xd0, 0x0e, 0x67, 0x65, 0x6f)
+#define EFI_SHIM_LOCK_GUID EFI_GUID(0x605dab50, 0xe046, 0x4300, 0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23)
+
/*
* This GUID is used to pass to the kernel proper the struct screen_info
* structure that was populated by the stub based on the GOP protocol instance
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox