* [PATCH v2 3/5] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: kbuild test robot @ 2016-10-28 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <202cdeff42a2de149c471630110a8b2657ccf5ca.1477669745.git.stillcompiling@gmail.com>
Hi Joshua,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc2 next-20161028]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/Joshua-Clayton/lib-add-bitrev8x4/20161029-012535
config: openrisc-allmodconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc
All errors (new ones prefixed by >>):
drivers/fpga/cyclone-ps-spi.c: In function 'cyclonespi_write':
drivers/fpga/cyclone-ps-spi.c:89:19: error: 'SZ_4K' undeclared (first use in this function)
drivers/fpga/cyclone-ps-spi.c:89:19: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/fpga/cyclone-ps-spi.c:89:19: error: type defaults to 'int' in declaration of '__UNIQUE_ID_min2_15'
vim +89 drivers/fpga/cyclone-ps-spi.c
83 struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
84 const char *fw_data = buf;
85 const char *fw_data_end = fw_data + count;
86
87 while (fw_data < fw_data_end) {
88 int ret;
> 89 size_t stride = min(fw_data_end - fw_data, SZ_4K);
90
91 rev_buf((void *)fw_data, stride);
92 ret = spi_write(conf->spi, fw_data, stride);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 39284 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161029/d37f2726/attachment-0001.gz>
^ permalink raw reply
* [PATCH] fpga zynq: Check the bitstream for validity
From: Jason Gunthorpe @ 2016-10-28 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028182308.GB18325@live.com>
On Fri, Oct 28, 2016 at 11:23:08AM -0700, Moritz Fischer wrote:
> I'm fine with checking for boundary cases where the bitstreams are
> obviously too small or wrong size, I'm not convinced that checking using
> internal knowledge about the bistream format inside the kernel is the
> right place.
To be clear, the sync word is documented in the Xilinx public docs, it
is mandatory. I don't think there is anything wrong with doing basic
validation on the structure of the bitstream before sending it.
> > The problem with the way it is now is how hard it is to figure out
> > what the right bitstream format should be. Clear instructions to
> > canonize by droping the header before the sync word and byteswap so
> > the sync word is in the given order is much clearer..
>
> I don't know about you, but for my designs I can just use what drops out
> of my Vivado build.
Are you sure? With a 4.8 kernel?
# (in vivado 2016.3) write_bitstream -bin_file foo
$ hexdump -C foo.bin
00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000020 00 00 00 bb 11 22 00 44 ff ff ff ff ff ff ff ff |.....".D........|
00000030 aa 99 55 66 20 00 00 00 30 02 20 01 00 00 00 00 |..Uf ...0. .....|
So that isn't going to work, it needs byte swapping
$ hexdump -C foo.bit
000000a0 bb 11 22 00 44 ff ff ff ff ff ff ff ff aa 99 55 |..".D..........U|
000000b0 66 20 00 00 00 30 02 20 01 00 00 00 00 30 02 00 |f ...0. .....0..|
This also is not going to work, it needs byteswapping and the sync word
has to be 4 byte aligned.
What did you do to get a working bitfile? Are you using one of the
Vivado automatic flows that 'handles' this for you? I am not.
Remember, 4.8 now has the patch to remove the autodetection that used
to correct both of the above two problems..
So from my perspective, this driver is incompatible with the output of
the Xilinx tools. I don't really care, we always post-process the
output of write_bitfile, and I am happy to provide a canonized
bitstream, but the driver needs to do more to help people get this
right.
> Are you unhappy with the way we document which format to use, or
> that we don't slice off the beginning (that gets ignored by hardware?).
Well, I'm unhappy I spent an hour wondering why things didn't work
with no information on what the expected format was now for this
driver. For a bit I wondered if there was a driver bug as this stuff
all worked for me with the original xdevcfg driver.
Some of the problems were bugs on my part (which would have been found
much faster with validation), but at the end of the day this is
horribly unfriendly. You get a timeout and a 'Failed' message, thats
it.
I think all common bitstream formatting errors would be detected by
simply validating the sync word.
Jason
^ permalink raw reply
* [PATCH 0/3] Support userspace irqchip with arch timers
From: Alexander Graf @ 2016-10-28 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56812724-4bac-8265-b6f6-b1ff00308ec0@arm.com>
> Am 28.10.2016 um 17:57 schrieb Marc Zyngier <marc.zyngier@arm.com>:
>
>> On 28/10/16 16:52, Alexander Graf wrote:
>>
>>
>>> Am 28.10.2016 um 16:38 schrieb Marc Zyngier <marc.zyngier@arm.com>:
>>>
>>> Alex,
>>>
>>>> On 30/09/16 20:31, Alexander Graf wrote:
>>>>
>>>>
>>>>>> On 30.09.16 17:43, Christoffer Dall wrote:
>>>>>> On Fri, Sep 30, 2016 at 05:38:11PM +0200, Alexander Graf wrote:
>>>>>>
>>>>>>
>>>>>>> On 30.09.16 16:54, Alexander Graf wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On 27.09.16 21:08, Christoffer Dall wrote:
>>>>>>>> Hi Alex,
>>>>>>>>
>>>>>>>> Marc and I have been looking at this during Linaro connect and have
>>>>>>>> slightly reworked your patch into this small series.
>>>>>>>>
>>>>>>>> It would be good if you could have a look at it and test it out.
>>>>>>>>
>>>>>>>> I've tested it with your QEMU, and it works for UP, but secondary CPUs
>>>>>>>> fail to come up, and it looks like the kernel never gets an IPI for
>>>>>>>> those CPUs from userspace. Any chance you're willing to take a look at
>>>>>>>> that?
>>>>>>>
>>>>>>> I still need to see whether I can come up with a prettier solution, but
>>>>>>> for now this works:
>>>>>>>
>>>>>>> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
>>>>>>
>>>>>> Eh, no, not in i386 code :). But the problem seems to be a missing
>>>>>> mpstate sync.
>>>>>>
>>>>> Yeah, that looked really dodgy. Have you tested it? :)
>>>>
>>>> This time around tested with the correct command line parameters I hope
>>>> :). I'll send a pretty patch later.
>>>>
>>>> diff --git a/target-arm/kvm.c b/target-arm/kvm.c
>>>> index b4c8fe2..b549f00 100644
>>>> --- a/target-arm/kvm.c
>>>> +++ b/target-arm/kvm.c
>>>> @@ -173,6 +173,12 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
>>>> */
>>>> kvm_async_interrupts_allowed = true;
>>>>
>>>> + /*
>>>> + * PSCI wakes up secondary cores, so we always need to
>>>> + * have vCPUs waiting in kernel space
>>>> + */
>>>> + kvm_halt_in_kernel_allowed = true;
>>>> +
>>>> cap_has_mp_state = kvm_check_extension(s, KVM_CAP_MP_STATE);
>>>>
>>>> type_register_static(&host_arm_cpu_type_info);
>>>
>>> What the status of userspace for this thing? Are QEMU patches being
>>> posted and reviewed?
>>
>> I didn't see a notification that the patches were merged. Are they in
>> Linus' tree yet? Then I can post enablement to qemu-devel.
>
> I think you got it backward. I have no intention of merging them until I
> see a vague consensus on the userspace API, and a set of patches ready
> to be merged in QEMU.
That's not how kvm apis are made.
Alex
^ permalink raw reply
* [PATCH v2] irqchip/bcm2836: Prevent spurious interrupts
From: Thomas Gleixner @ 2016-10-28 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87bmy4qxnb.fsf@eliezer.anholt.net>
On Fri, 28 Oct 2016, Eric Anholt wrote:
> Thomas Gleixner <tglx@linutronix.de> writes:
>
> > On Thu, 27 Oct 2016, Eric Anholt wrote:
> >
> >> From: Phil Elwell <phil@raspberrypi.org>
> >>
> >> The old arch-specific IRQ macros included a dsb to ensure the
Which old arch-specific macros?
> >> write to clear the mailbox interrupt completed before returning
> >> from the interrupt.
That's not what the patch does. It makes sure that the interrupt it cleared
_before_ the IPI handler is called.
> >> The BCM2836 irqchip driver needs the same precaution to avoid
> >> spurious interrupts.
Please describe issues proper. Something like this:
The interrupt demultiplexer code clears a pending mailbox interrupt by
writing the pending bit back to the hardware, but it does not ensure that
the write is completed before proceeding. This causes the machine to
catch fire and scares my cat. <<-- Replace by a proper description.
The write() macro which was used, when the driver was developed,
contained the necessary data sycnhronization barrier, but it was replaced
by writel() when the driver got merged without adding the explicit
barrier after the write.
Add and document the barrier.
Can you spot the difference?
> writel(1 << ipi, mailbox0);
/* Barriers need to be documented with a comment */
> + dsb(sy);
> handle_IPI(ipi, regs);
> > This is missing a fixes tag. I have no idea when that problem was
> > introduced, so I have no way to decide whether this needs to be tagged
> > stable or not.
>
> This code has been there since introduction of the driver, so:
>
> Fixes: 1a15aaa998dc ("irqchip: Add bcm2836 interrupt controller for Raspberry Pi 2")
So it want's a stable tag, right?
Thanks,
tglx
^ permalink raw reply
* [PATCH v2 5/5] fpga manager: cyclone-ps-spi: make delay variable
From: Joshua Clayton @ 2016-10-28 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028174142.GA18325@live.com>
Hi Moritz,
Thanks for the review.
On 10/28/2016 10:41 AM, Moritz Fischer wrote:
> Hi Joshua,
>
> looks good to me; however, I think since you're adding initial support,
> I'd squash this together with [3/5].
I agree. I didn't want to squash it in before putting it up for review, though.
>
> On Fri, Oct 28, 2016 at 09:56:42AM -0700, Joshua Clayton wrote:
>> The status pin may not show ready in the time described in the
>> Altetera manual. check the value several times before giving up
> s/Altetera/Altera
Thanks. I'll fix this. And it will go away when it gets squashed.
>> For the hardware I am working on, the status pin takes 250 us,
>> 5 times as long as described by Altera.
>>
>> Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
>> ---
>> drivers/fpga/cyclone-ps-spi.c | 13 ++++++++-----
>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/fpga/cyclone-ps-spi.c b/drivers/fpga/cyclone-ps-spi.c
>> index 4b70d5c..c368223 100644
>> --- a/drivers/fpga/cyclone-ps-spi.c
>> +++ b/drivers/fpga/cyclone-ps-spi.c
>> @@ -20,6 +20,7 @@
>>
>> #define FPGA_RESET_TIME 50 /* time in usecs to trigger FPGA config */
>> -#define FPGA_MIN_DELAY 250 /* min usecs to wait for config status */
>> +#define FPGA_MIN_DELAY 50 /* min usecs to wait for config status */
>> +#define FPGA_MAX_DELAY 1000 /* max usecs to wait for config status */
>>
>> struct cyclonespi_conf {
>> struct gpio_desc *config;
>> @@ -42,6 +43,7 @@ static int cyclonespi_write_init(struct fpga_manager *mgr, u32 flags,
>> const char *buf, size_t count)
>> {
>> struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
>> + int i;
>>
>> if (flags & FPGA_MGR_PARTIAL_RECONFIG) {
>> dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
>> @@ -56,13 +58,14 @@ static int cyclonespi_write_init(struct fpga_manager *mgr, u32 flags,
>> }
>>
>> gpiod_set_value(conf->config, 1);
>> - usleep_range(FPGA_MIN_DELAY, FPGA_MIN_DELAY + 20);
>> - if (gpiod_get_value(conf->status) == 0) {
>> - dev_err(&mgr->dev, "Status pin not ready.\n");
>> - return -EIO;
>> + for (i = 0; i < (FPGA_MAX_DELAY / FPGA_MIN_DELAY); i++) {
>> + usleep_range(FPGA_MIN_DELAY, FPGA_MIN_DELAY + 20);
>> + if (gpiod_get_value(conf->status))
>> + return 0;
>> }
>>
>> - return 0;
>> + dev_err(&mgr->dev, "Status pin not ready.\n");
>> + return -EIO;
>> }
>>
>> static void rev_buf(void *buf, size_t len)
>> --
>> 2.7.4
>>
> Cheers,
>
> Moritz
Joshua
^ permalink raw reply
* [PATCH v3 11/14] ACPI: irq: introduce interrupt producer
From: agustinv at codeaurora.org @ 2016-10-28 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477408169-22217-12-git-send-email-guohanjun@huawei.com>
Hey Hanjun,
On 2016-10-25 11:09, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> In ACPI 6.1 spec, section 19.6.62, Interrupt Resource Descriptor Macro,
>
> Interrupt (ResourceUsage, EdgeLevel, ActiveLevel, Shared,
> ResourceSourceIndex, ResourceSource, DescriptorName)
> { InterruptList } => Buffer
>
> For the arguement ResourceUsage and DescriptorName, which means:
>
> ResourceUsage describes whether the device consumes the specified
> interrupt ( ResourceConsumer ) or produces it for use by a child
> device ( ResourceProducer ).
> If nothing is specified, then ResourceConsumer is assumed.
>
> DescriptorName evaluates to a name string which refers to the
> entire resource descriptor.
>
> So it can be used for devices connecting to a specific interrupt
> prodcucer instead of the main interrupt controller in MADT. In the
> real world, we have irqchip such as mbi-gen which connecting to
> a group of wired interrupts and then issue msi to the ITS, devices
> connecting to such interrupt controller fit this scope.
>
> For now the irq for ACPI only pointer to the main interrupt
> controller's irqdomain, for devices not connecting to those
> irqdomains, which need to present its irq parent, we can use
> following ASL code to represent it:
>
> Interrupt(ResourceConsumer,..., "\_SB.IRQP") {12,14,....}
>
> then we can parse the interrupt producer with the full
> path name "\_SB.IRQP".
>
> In order to do that, we introduce a pointer interrupt_producer
> in struct acpi_device, and fill it when scanning irq resources
> for acpi device if it specifies the interrupt producer.
>
> But for now when parsing the resources for acpi devices, we don't
> pass the acpi device for acpi_walk_resoures() in
> drivers/acpi/resource.c,
> so introduce a adev in struct res_proc_context to pass it as a context
> to scan the interrupt resources, then finally pass to
> acpi_register_gsi()
> to find its interrupt producer to get the virq from diffrent domains.
>
> With steps above ready, rework acpi_register_gsi() to get other
> interrupt producer if devices not connecting to main interrupt
> controller.
>
> Since we often pass NULL to acpi_register_gsi() and there is no
> interrupt
> producer for devices connect to gicd on ARM or io-apic on X86, so it
> will
> use the default irqdomain for those deivces and no functional changes
> to
> those devices.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Agustin Vega-Frias <agustinv@codeaurora.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> ---
> drivers/acpi/gsi.c | 10 ++++--
> drivers/acpi/resource.c | 85
> ++++++++++++++++++++++++++++++++++---------------
> include/acpi/acpi_bus.h | 1 +
> 3 files changed, 68 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/acpi/gsi.c b/drivers/acpi/gsi.c
> index ee9e0f2..29ee547 100644
> --- a/drivers/acpi/gsi.c
> +++ b/drivers/acpi/gsi.c
> @@ -55,13 +55,19 @@ int acpi_register_gsi(struct device *dev, u32 gsi,
> int trigger,
> int polarity)
> {
> struct irq_fwspec fwspec;
> + struct acpi_device *adev = dev ? to_acpi_device(dev) : NULL;
>
> - if (WARN_ON(!acpi_gsi_domain_id)) {
> + if (adev && &adev->fwnode && adev->interrupt_producer)
> + /* devices in DSDT connecting to spefic interrupt producer */
> + fwspec.fwnode = adev->interrupt_producer;
> + else if (acpi_gsi_domain_id)
> + /* devices connecting to gicd in default */
> + fwspec.fwnode = acpi_gsi_domain_id;
> + else {
> pr_warn("GSI: No registered irqchip, giving up\n");
> return -EINVAL;
> }
>
> - fwspec.fwnode = acpi_gsi_domain_id;
> fwspec.param[0] = gsi;
> fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
> fwspec.param_count = 2;
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 56241eb..f1371cf 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -381,7 +381,7 @@ static void acpi_dev_irqresource_disabled(struct
> resource *res, u32 gsi)
> res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
> }
>
> -static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
> +static void acpi_dev_get_irqresource(struct acpi_device *adev, struct
> resource *res, u32 gsi,
> u8 triggering, u8 polarity, u8 shareable,
> bool legacy)
> {
> @@ -415,7 +415,7 @@ static void acpi_dev_get_irqresource(struct
> resource *res, u32 gsi,
> }
>
> res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
> - irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
> + irq = acpi_register_gsi(&adev->dev, gsi, triggering, polarity);
> if (irq >= 0) {
> res->start = irq;
> res->end = irq;
> @@ -424,27 +424,9 @@ static void acpi_dev_get_irqresource(struct
> resource *res, u32 gsi,
> }
> }
>
> -/**
> - * acpi_dev_resource_interrupt - Extract ACPI interrupt resource
> information.
> - * @ares: Input ACPI resource object.
> - * @index: Index into the array of GSIs represented by the resource.
> - * @res: Output generic resource object.
> - *
> - * Check if the given ACPI resource object represents an interrupt
> resource
> - * and @index does not exceed the resource's interrupt count (true is
> returned
> - * in that case regardless of the results of the other checks)). If
> that's the
> - * case, register the GSI corresponding to @index from the array of
> interrupts
> - * represented by the resource and populate the generic resource
> object pointed
> - * to by @res accordingly. If the registration of the GSI is not
> successful,
> - * IORESOURCE_DISABLED will be set it that object's flags.
> - *
> - * Return:
> - * 1) false with res->flags setting to zero: not the expected resource
> type
> - * 2) false with IORESOURCE_DISABLED in res->flags: valid unassigned
> resource
> - * 3) true: valid assigned resource
> - */
> -bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int
> index,
> - struct resource *res)
> +static bool __acpi_dev_resource_interrupt(struct acpi_device *adev,
> + struct acpi_resource *ares, int index,
> + struct resource *res)
> {
> struct acpi_resource_irq *irq;
> struct acpi_resource_extended_irq *ext_irq;
> @@ -460,7 +442,7 @@ bool acpi_dev_resource_interrupt(struct
> acpi_resource *ares, int index,
> acpi_dev_irqresource_disabled(res, 0);
> return false;
> }
> - acpi_dev_get_irqresource(res, irq->interrupts[index],
> + acpi_dev_get_irqresource(adev, res, irq->interrupts[index],
> irq->triggering, irq->polarity,
> irq->sharable, true);
> break;
> @@ -470,7 +452,31 @@ bool acpi_dev_resource_interrupt(struct
> acpi_resource *ares, int index,
> acpi_dev_irqresource_disabled(res, 0);
> return false;
> }
> - acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
> +
> + /*
> + * It's a interrupt consumer device and connecting to specfic
> + * interrupt controller. For now, we only support connecting
> + * interrupts to one irq controller for a single device
> + */
> + if (ext_irq->producer_consumer == ACPI_CONSUMER
> + && ext_irq->resource_source.string_length != 0
> + && !adev->interrupt_producer) {
> + acpi_status status;
> + acpi_handle handle;
> + struct acpi_device *device;
> +
> + status = acpi_get_handle(NULL,
> ext_irq->resource_source.string_ptr, &handle);
> + if (ACPI_FAILURE(status))
> + return false;
> +
> + device = acpi_bus_get_acpi_device(handle);
> + if (!device)
> + return false;
> +
> + adev->interrupt_producer = &device->fwnode;
You are missing an 'acpi_bus_put_acpi_device(device)' call here.
Besides that, this approach will not work in the case where a device
wants to consume interrupts from multiple controllers since you are
forcing adev->interrupt_producer to be the first resource_source
found.
That's the reason I was advocating dynamic lookup (see [1]).
I am about to submit V6 of my series where I also address the probe
ordering issues by enabling re-initialization of platform_device
resources when the resource was marked disabled due to the domain
nor being there during ACPI bus scan.
Thanks,
Agustin
[1] https://lkml.org/lkml/2016/10/18/592
> + }
> +
> + acpi_dev_get_irqresource(adev, res, ext_irq->interrupts[index],
> ext_irq->triggering, ext_irq->polarity,
> ext_irq->sharable, false);
> break;
> @@ -481,6 +487,31 @@ bool acpi_dev_resource_interrupt(struct
> acpi_resource *ares, int index,
>
> return true;
> }
> +
> +/**
> + * acpi_dev_resource_interrupt - Extract ACPI interrupt resource
> information.
> + * @ares: Input ACPI resource object.
> + * @index: Index into the array of GSIs represented by the resource.
> + * @res: Output generic resource object.
> + *
> + * Check if the given ACPI resource object represents an interrupt
> resource
> + * and @index does not exceed the resource's interrupt count (true is
> returned
> + * in that case regardless of the results of the other checks)). If
> that's the
> + * case, register the GSI corresponding to @index from the array of
> interrupts
> + * represented by the resource and populate the generic resource
> object pointed
> + * to by @res accordingly. If the registration of the GSI is not
> successful,
> + * IORESOURCE_DISABLED will be set it that object's flags.
> + *
> + * Return:
> + * 1) false with res->flags setting to zero: not the expected resource
> type
> + * 2) false with IORESOURCE_DISABLED in res->flags: valid unassigned
> resource
> + * 3) true: valid assigned resource
> + */
> +bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int
> index,
> + struct resource *res)
> +{
> + return __acpi_dev_resource_interrupt(NULL, ares, index, res);
> +}
> EXPORT_SYMBOL_GPL(acpi_dev_resource_interrupt);
>
> /**
> @@ -499,6 +530,7 @@ struct res_proc_context {
> void *preproc_data;
> int count;
> int error;
> + struct acpi_device *adev;
> };
>
> static acpi_status acpi_dev_new_resource_entry(struct resource_win
> *win,
> @@ -546,7 +578,7 @@ static acpi_status
> acpi_dev_process_resource(struct acpi_resource *ares,
> || acpi_dev_resource_ext_address_space(ares, &win))
> return acpi_dev_new_resource_entry(&win, c);
>
> - for (i = 0; acpi_dev_resource_interrupt(ares, i, res); i++) {
> + for (i = 0; __acpi_dev_resource_interrupt(c->adev, ares, i, res);
> i++) {
> acpi_status status;
>
> status = acpi_dev_new_resource_entry(&win, c);
> @@ -599,6 +631,7 @@ int acpi_dev_get_resources(struct acpi_device
> *adev, struct list_head *list,
> c.preproc_data = preproc_data;
> c.count = 0;
> c.error = 0;
> + c.adev = adev;
> status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS,
> acpi_dev_process_resource, &c);
> if (ACPI_FAILURE(status)) {
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index 4242c31..5410d3b 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -355,6 +355,7 @@ struct acpi_device {
> int device_type;
> acpi_handle handle; /* no handle for fixed hardware */
> struct fwnode_handle fwnode;
> + struct fwnode_handle *interrupt_producer;
> struct acpi_device *parent;
> struct list_head children;
> struct list_head node;
> --
> 1.7.12.4
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v3 1/2] clk: imx: fix integer overflow in AV PLL round rate
From: Fabio Estevam @ 2016-10-28 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028181316.GI16026@codeaurora.org>
On Fri, Oct 28, 2016 at 4:13 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> The clk-fixes branch is for patches that fix problems in code
> merged during the merge window as well as small one-liners and
> things that are causing great pain for people on the latest
> release. Given that this fixes a regression in v4.8 and we're
> trying to stabilize v4.9 it looked like it could wait until
> v4.10.
The regression affects 4.8 and 4.9.
> So is there something going on here where the pain is too much to
> wait for the next merge window? If so the commit text should
Yes, people reported HDMI issues because of this bug:
https://www.spinics.net/lists/arm-kernel/msg535304.html
> mention something about what's causing that pain. Perhaps by
> referencing the commit that merged outside of clk tree that
> caused problems.
This patch clearly states that the problem is caused by ba7f4f557eb6
("clk: imx: correct AV PLL rate formula").
Since this is a regression, I don't understand why we need to wait
until 4.10 to get it applied.
^ permalink raw reply
* [PATCH v2 3/5] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: kbuild test robot @ 2016-10-28 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <202cdeff42a2de149c471630110a8b2657ccf5ca.1477669745.git.stillcompiling@gmail.com>
Hi Joshua,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc2 next-20161028]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/Joshua-Clayton/lib-add-bitrev8x4/20161029-012535
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All error/warnings (new ones prefixed by >>):
In file included from drivers/fpga/cyclone-ps-spi.c:13:0:
drivers/fpga/cyclone-ps-spi.c: In function 'rev_buf':
>> include/linux/bitrev.h:12:21: error: implicit declaration of function '__arch_bitrev8x4' [-Werror=implicit-function-declaration]
#define __bitrev8x4 __arch_bitrev8x4
^
>> include/linux/bitrev.h:101:2: note: in expansion of macro '__bitrev8x4'
__bitrev8x4(__x); \
^~~~~~~~~~~
>> drivers/fpga/cyclone-ps-spi.c:75:11: note: in expansion of macro 'bitrev8x4'
*fw32 = bitrev8x4(*fw32);
^~~~~~~~~
In file included from include/linux/delay.h:10:0,
from drivers/fpga/cyclone-ps-spi.c:14:
drivers/fpga/cyclone-ps-spi.c: In function 'cyclonespi_write':
include/linux/kernel.h:739:16: warning: comparison of distinct pointer types lacks a cast
(void) (&min1 == &min2); \
^
include/linux/kernel.h:742:2: note: in expansion of macro '__min'
__min(typeof(x), typeof(y), \
^~~~~
drivers/fpga/cyclone-ps-spi.c:89:19: note: in expansion of macro 'min'
size_t stride = min(fw_data_end - fw_data, SZ_4K);
^~~
cc1: some warnings being treated as errors
vim +/__arch_bitrev8x4 +12 include/linux/bitrev.h
556d2f05 Yalin Wang 2014-11-03 6 #ifdef CONFIG_HAVE_ARCH_BITREVERSE
556d2f05 Yalin Wang 2014-11-03 7 #include <asm/bitrev.h>
556d2f05 Yalin Wang 2014-11-03 8
556d2f05 Yalin Wang 2014-11-03 9 #define __bitrev32 __arch_bitrev32
556d2f05 Yalin Wang 2014-11-03 10 #define __bitrev16 __arch_bitrev16
556d2f05 Yalin Wang 2014-11-03 11 #define __bitrev8 __arch_bitrev8
69ff2a81 Joshua Clayton 2016-10-28 @12 #define __bitrev8x4 __arch_bitrev8x4
a5cfc1ec Akinobu Mita 2006-12-08 13
556d2f05 Yalin Wang 2014-11-03 14 #else
556d2f05 Yalin Wang 2014-11-03 15 extern u8 const byte_rev_table[256];
556d2f05 Yalin Wang 2014-11-03 16 static inline u8 __bitrev8(u8 byte)
a5cfc1ec Akinobu Mita 2006-12-08 17 {
a5cfc1ec Akinobu Mita 2006-12-08 18 return byte_rev_table[byte];
a5cfc1ec Akinobu Mita 2006-12-08 19 }
a5cfc1ec Akinobu Mita 2006-12-08 20
556d2f05 Yalin Wang 2014-11-03 21 static inline u16 __bitrev16(u16 x)
556d2f05 Yalin Wang 2014-11-03 22 {
556d2f05 Yalin Wang 2014-11-03 23 return (__bitrev8(x & 0xff) << 8) | __bitrev8(x >> 8);
556d2f05 Yalin Wang 2014-11-03 24 }
556d2f05 Yalin Wang 2014-11-03 25
556d2f05 Yalin Wang 2014-11-03 26 static inline u32 __bitrev32(u32 x)
556d2f05 Yalin Wang 2014-11-03 27 {
556d2f05 Yalin Wang 2014-11-03 28 return (__bitrev16(x & 0xffff) << 16) | __bitrev16(x >> 16);
556d2f05 Yalin Wang 2014-11-03 29 }
556d2f05 Yalin Wang 2014-11-03 30
69ff2a81 Joshua Clayton 2016-10-28 31 static inline u32 __bitrev8x4(u32 x)
69ff2a81 Joshua Clayton 2016-10-28 32 {
69ff2a81 Joshua Clayton 2016-10-28 33 return(__bitrev8(x & 0xff) |
69ff2a81 Joshua Clayton 2016-10-28 34 (__bitrev8((x >> 8) & 0xff) << 8) |
69ff2a81 Joshua Clayton 2016-10-28 35 (__bitrev8((x >> 16) & 0xff) << 16) |
69ff2a81 Joshua Clayton 2016-10-28 36 (__bitrev8((x >> 24) & 0xff) << 24));
69ff2a81 Joshua Clayton 2016-10-28 37 }
69ff2a81 Joshua Clayton 2016-10-28 38
556d2f05 Yalin Wang 2014-11-03 39 #endif /* CONFIG_HAVE_ARCH_BITREVERSE */
556d2f05 Yalin Wang 2014-11-03 40
556d2f05 Yalin Wang 2014-11-03 41 #define __constant_bitrev32(x) \
556d2f05 Yalin Wang 2014-11-03 42 ({ \
556d2f05 Yalin Wang 2014-11-03 43 u32 __x = x; \
556d2f05 Yalin Wang 2014-11-03 44 __x = (__x >> 16) | (__x << 16); \
556d2f05 Yalin Wang 2014-11-03 45 __x = ((__x & (u32)0xFF00FF00UL) >> 8) | ((__x & (u32)0x00FF00FFUL) << 8); \
556d2f05 Yalin Wang 2014-11-03 46 __x = ((__x & (u32)0xF0F0F0F0UL) >> 4) | ((__x & (u32)0x0F0F0F0FUL) << 4); \
556d2f05 Yalin Wang 2014-11-03 47 __x = ((__x & (u32)0xCCCCCCCCUL) >> 2) | ((__x & (u32)0x33333333UL) << 2); \
556d2f05 Yalin Wang 2014-11-03 48 __x = ((__x & (u32)0xAAAAAAAAUL) >> 1) | ((__x & (u32)0x55555555UL) << 1); \
556d2f05 Yalin Wang 2014-11-03 49 __x; \
556d2f05 Yalin Wang 2014-11-03 50 })
556d2f05 Yalin Wang 2014-11-03 51
556d2f05 Yalin Wang 2014-11-03 52 #define __constant_bitrev16(x) \
556d2f05 Yalin Wang 2014-11-03 53 ({ \
556d2f05 Yalin Wang 2014-11-03 54 u16 __x = x; \
556d2f05 Yalin Wang 2014-11-03 55 __x = (__x >> 8) | (__x << 8); \
556d2f05 Yalin Wang 2014-11-03 56 __x = ((__x & (u16)0xF0F0U) >> 4) | ((__x & (u16)0x0F0FU) << 4); \
556d2f05 Yalin Wang 2014-11-03 57 __x = ((__x & (u16)0xCCCCU) >> 2) | ((__x & (u16)0x3333U) << 2); \
556d2f05 Yalin Wang 2014-11-03 58 __x = ((__x & (u16)0xAAAAU) >> 1) | ((__x & (u16)0x5555U) << 1); \
556d2f05 Yalin Wang 2014-11-03 59 __x; \
556d2f05 Yalin Wang 2014-11-03 60 })
556d2f05 Yalin Wang 2014-11-03 61
69ff2a81 Joshua Clayton 2016-10-28 62 #define __constant_bitrev8x4(x) \
69ff2a81 Joshua Clayton 2016-10-28 63 ({ \
69ff2a81 Joshua Clayton 2016-10-28 64 u32 __x = x; \
69ff2a81 Joshua Clayton 2016-10-28 65 __x = ((__x & (u32)0xF0F0F0F0UL) >> 4) | ((__x & (u32)0x0F0F0F0FUL) << 4); \
69ff2a81 Joshua Clayton 2016-10-28 66 __x = ((__x & (u32)0xCCCCCCCCUL) >> 2) | ((__x & (u32)0x33333333UL) << 2); \
69ff2a81 Joshua Clayton 2016-10-28 67 __x = ((__x & (u32)0xAAAAAAAAUL) >> 1) | ((__x & (u32)0x55555555UL) << 1); \
69ff2a81 Joshua Clayton 2016-10-28 68 __x; \
69ff2a81 Joshua Clayton 2016-10-28 69 })
69ff2a81 Joshua Clayton 2016-10-28 70
556d2f05 Yalin Wang 2014-11-03 71 #define __constant_bitrev8(x) \
556d2f05 Yalin Wang 2014-11-03 72 ({ \
556d2f05 Yalin Wang 2014-11-03 73 u8 __x = x; \
556d2f05 Yalin Wang 2014-11-03 74 __x = (__x >> 4) | (__x << 4); \
556d2f05 Yalin Wang 2014-11-03 75 __x = ((__x & (u8)0xCCU) >> 2) | ((__x & (u8)0x33U) << 2); \
556d2f05 Yalin Wang 2014-11-03 76 __x = ((__x & (u8)0xAAU) >> 1) | ((__x & (u8)0x55U) << 1); \
556d2f05 Yalin Wang 2014-11-03 77 __x; \
556d2f05 Yalin Wang 2014-11-03 78 })
556d2f05 Yalin Wang 2014-11-03 79
556d2f05 Yalin Wang 2014-11-03 80 #define bitrev32(x) \
556d2f05 Yalin Wang 2014-11-03 81 ({ \
556d2f05 Yalin Wang 2014-11-03 82 u32 __x = x; \
556d2f05 Yalin Wang 2014-11-03 83 __builtin_constant_p(__x) ? \
556d2f05 Yalin Wang 2014-11-03 84 __constant_bitrev32(__x) : \
556d2f05 Yalin Wang 2014-11-03 85 __bitrev32(__x); \
556d2f05 Yalin Wang 2014-11-03 86 })
556d2f05 Yalin Wang 2014-11-03 87
556d2f05 Yalin Wang 2014-11-03 88 #define bitrev16(x) \
556d2f05 Yalin Wang 2014-11-03 89 ({ \
556d2f05 Yalin Wang 2014-11-03 90 u16 __x = x; \
556d2f05 Yalin Wang 2014-11-03 91 __builtin_constant_p(__x) ? \
556d2f05 Yalin Wang 2014-11-03 92 __constant_bitrev16(__x) : \
556d2f05 Yalin Wang 2014-11-03 93 __bitrev16(__x); \
556d2f05 Yalin Wang 2014-11-03 94 })
a5cfc1ec Akinobu Mita 2006-12-08 95
69ff2a81 Joshua Clayton 2016-10-28 96 #define bitrev8x4(x) \
69ff2a81 Joshua Clayton 2016-10-28 97 ({ \
69ff2a81 Joshua Clayton 2016-10-28 98 u32 __x = x; \
69ff2a81 Joshua Clayton 2016-10-28 99 __builtin_constant_p(__x) ? \
69ff2a81 Joshua Clayton 2016-10-28 100 __constant_bitrev8x4(__x) : \
69ff2a81 Joshua Clayton 2016-10-28 @101 __bitrev8x4(__x); \
69ff2a81 Joshua Clayton 2016-10-28 102 })
69ff2a81 Joshua Clayton 2016-10-28 103
556d2f05 Yalin Wang 2014-11-03 104 #define bitrev8(x) \
:::::: The code at line 12 was first introduced by commit
:::::: 69ff2a81709e0969b2d1a0efaa9a010e0093917c lib: add bitrev8x4()
:::::: TO: Joshua Clayton <stillcompiling@gmail.com>
:::::: CC: 0day robot <fengguang.wu@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 52470 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161029/eb4a95b7/attachment-0001.gz>
^ permalink raw reply
* [PATCH v2 3/5] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: kbuild test robot @ 2016-10-28 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <202cdeff42a2de149c471630110a8b2657ccf5ca.1477669745.git.stillcompiling@gmail.com>
Hi Joshua,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc2 next-20161028]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/Joshua-Clayton/lib-add-bitrev8x4/20161029-012535
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
In file included from include/linux/delay.h:10:0,
from drivers/fpga/cyclone-ps-spi.c:14:
drivers/fpga/cyclone-ps-spi.c: In function 'cyclonespi_write':
>> drivers/fpga/cyclone-ps-spi.c:89:46: error: 'SZ_4K' undeclared (first use in this function)
size_t stride = min(fw_data_end - fw_data, SZ_4K);
^
include/linux/kernel.h:738:2: note: in definition of macro '__min'
t2 min2 = (y); \
^~
>> drivers/fpga/cyclone-ps-spi.c:89:19: note: in expansion of macro 'min'
size_t stride = min(fw_data_end - fw_data, SZ_4K);
^~~
drivers/fpga/cyclone-ps-spi.c:89:46: note: each undeclared identifier is reported only once for each function it appears in
size_t stride = min(fw_data_end - fw_data, SZ_4K);
^
include/linux/kernel.h:738:2: note: in definition of macro '__min'
t2 min2 = (y); \
^~
>> drivers/fpga/cyclone-ps-spi.c:89:19: note: in expansion of macro 'min'
size_t stride = min(fw_data_end - fw_data, SZ_4K);
^~~
vim +/SZ_4K +89 drivers/fpga/cyclone-ps-spi.c
8 * Works on Cyclone V. Should work on cyclone series.
9 * May work on other Altera fpgas.
10 *
11 */
12
13 #include <linux/bitrev.h>
> 14 #include <linux/delay.h>
15 #include <linux/fpga/fpga-mgr.h>
16 #include <linux/gpio/consumer.h>
17 #include <linux/module.h>
18 #include <linux/of_gpio.h>
19 #include <linux/spi/spi.h>
20
21 #define FPGA_RESET_TIME 50 /* time in usecs to trigger FPGA config */
22 #define FPGA_MIN_DELAY 250 /* min usecs to wait for config status */
23
24 struct cyclonespi_conf {
25 struct gpio_desc *config;
26 struct gpio_desc *status;
27 struct spi_device *spi;
28 };
29
30 static const struct of_device_id of_ef_match[] = {
31 { .compatible = "altr,cyclone-ps-spi-fpga-mgr", },
32 {}
33 };
34 MODULE_DEVICE_TABLE(of, of_ef_match);
35
36 static enum fpga_mgr_states cyclonespi_state(struct fpga_manager *mgr)
37 {
38 return mgr->state;
39 }
40
41 static int cyclonespi_write_init(struct fpga_manager *mgr, u32 flags,
42 const char *buf, size_t count)
43 {
44 struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
45
46 if (flags & FPGA_MGR_PARTIAL_RECONFIG) {
47 dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
48 return -EINVAL;
49 }
50
51 gpiod_set_value(conf->config, 0);
52 usleep_range(FPGA_RESET_TIME, FPGA_RESET_TIME + 20);
53 if (gpiod_get_value(conf->status) == 1) {
54 dev_err(&mgr->dev, "Status pin should be low.\n");
55 return -EIO;
56 }
57
58 gpiod_set_value(conf->config, 1);
59 usleep_range(FPGA_MIN_DELAY, FPGA_MIN_DELAY + 20);
60 if (gpiod_get_value(conf->status) == 0) {
61 dev_err(&mgr->dev, "Status pin not ready.\n");
62 return -EIO;
63 }
64
65 return 0;
66 }
67
68 static void rev_buf(void *buf, size_t len)
69 {
70 u32 *fw32 = (u32 *)buf;
71 const u32 *fw_end = (u32 *)(buf + len);
72
73 /* set buffer to lsb first */
74 while (fw32 < fw_end) {
75 *fw32 = bitrev8x4(*fw32);
76 fw32++;
77 }
78 }
79
80 static int cyclonespi_write(struct fpga_manager *mgr, const char *buf,
81 size_t count)
82 {
83 struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
84 const char *fw_data = buf;
85 const char *fw_data_end = fw_data + count;
86
87 while (fw_data < fw_data_end) {
88 int ret;
> 89 size_t stride = min(fw_data_end - fw_data, SZ_4K);
90
91 rev_buf((void *)fw_data, stride);
92 ret = spi_write(conf->spi, fw_data, stride);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 56833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161029/6a9787c0/attachment-0001.gz>
^ permalink raw reply
* [PATCH v2 1/5] lib: add bitrev8x4()
From: kbuild test robot @ 2016-10-28 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bc92eb1507448731163ae67fc888668d327f9168.1477669745.git.stillcompiling@gmail.com>
Hi Joshua,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.9-rc2 next-20161028]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/Joshua-Clayton/lib-add-bitrev8x4/20161029-012535
config: arm-s5pv210_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All warnings (new ones prefixed by >>):
In file included from include/linux/bitrev.h:7:0,
from include/linux/crc32.h:9,
from lib/crc32.c:29:
arch/arm/include/asm/bitrev.h: In function '__arch_bitrev8x4':
>> arch/arm/include/asm/bitrev.h:23:1: warning: no return statement in function returning non-void [-Wreturn-type]
}
^
vim +23 arch/arm/include/asm/bitrev.h
7 return x;
8 }
9
10 static __always_inline __attribute_const__ u16 __arch_bitrev16(u16 x)
11 {
12 return __arch_bitrev32((u32)x) >> 16;
13 }
14
15 static __always_inline __attribute_const__ u8 __arch_bitrev8(u8 x)
16 {
17 return __arch_bitrev32((u32)x) >> 24;
18 }
19
20 static __always_inline __attribute_const__ u32 __arch_bitrev8x4(u32 x)
21 {
22 __asm__ ("rbit %0, %1; rev %0, %0" : "=r" (x) : "r" (x));
> 23 }
24
25 #endif
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 10244 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161029/c7c967b4/attachment-0001.gz>
^ permalink raw reply
* [PATCH V2] arm64: Add support of R_AARCH64_PREL32 relocation in purgatory
From: Geoff Levand @ 2016-10-28 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f970f7938109c40833fc45e3d6d72b1dcdf14595.1477627895.git.panand@redhat.com>
On 10/27/2016 09:16 PM, Pratyush Anand wrote:
> gcc version in fedora koji is 6.2.1-2.fc25. kexec-tools compiled with this
> gcc produced another relocation error:
>
> machine_apply_elf_rel: ERROR Unknown type: 261
>
> This patch fixes the above error.
Looks good. Simon, please apply.
Reviewed-by: Geoff Levand <geoff@infradead.org>
^ permalink raw reply
* SMR masking and PCI
From: Stuart Yoder @ 2016-10-28 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c39b785a-0f18-fc0a-ce08-7ebe3cfaf8c5@arm.com>
> -----Original Message-----
> From: Stuart Yoder
> Sent: Friday, October 28, 2016 12:12 PM
> To: 'Robin Murphy' <robin.murphy@arm.com>; Mark Rutland <mark.rutland@arm.com>
> Cc: linux-arm-kernel at lists.infradead.org; Will Deacon <will.deacon@arm.com>; Diana Madalina Craciun
> <diana.craciun@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; iommu at lists.linux-foundation.org
> Subject: RE: SMR masking and PCI
>
>
>
> > -----Original Message-----
> > From: Robin Murphy [mailto:robin.murphy at arm.com]
> > Sent: Friday, October 28, 2016 11:17 AM
> > To: Stuart Yoder <stuart.yoder@nxp.com>; Mark Rutland <mark.rutland@arm.com>
> > Cc: linux-arm-kernel at lists.infradead.org; Will Deacon <will.deacon@arm.com>; Diana Madalina Craciun
> > <diana.craciun@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; iommu at lists.linux-foundation.org
> > Subject: Re: SMR masking and PCI
> >
> > Hi Stuart,
> >
> > On 27/10/16 18:10, Stuart Yoder wrote:
> > > Hi Robin,
> > >
> > > A question about how the SMR masking defined in the arm,smmu binding
> > > relates to the PCI iommu-map.
> > >
> > > The #iommu-cells property defines the number of cells an "IOMMU specifier"
> > > takes and 2 is specified to be:
> > >
> > > SMMUs with stream matching support and complex masters
> > > may use a value of 2, where the second cell represents
> > > an SMR mask to combine with the ID in the first cell.
> > >
> > > An iommu-map entry is defined as:
> > >
> > > (rid-base,iommu,iommu-base,length)
> > >
> > > What seems to be currently missing in the iommu-map support is
> > > the possibility the case where #iommu-cells=<2>.
> >
> > Indeed. The bindings have so far rather implicitly assumed the case of
> > #{msi,iommu}-cells = 1, and the code has followed suit.
> >
> > > In this case iommu-base which is an IOMMU specifier should
> > > occupy 2 cells. For example on an ls2085a we would want:
> > >
> > > iommu-map = <0x0 0x6 0x7 0x3ff 0x1
> > > 0x100 0x6 0x8 0x3ff 0x1>;
> > >
> > > ...to mask our stream IDs to 10 bits.
> > >
> > > This should work in theory and comply with the bindings, no?
> >
> > In theory, but now consider:
> >
> > iommu-map = <0x0 0x6 0x7 0x3ff 0x2>;
> >
> > faced with ID 1. The input base is 0, the output base is the 2-cell
> > value 0x7000003ff, so the final ID value should be 0x700000400, right?
>
> No. The second cell as per the SMMU binding is the SMR mask...applied
> by the SMMU before matching stream IDs.
I think I now understand what you mean. I missed that you envisioned the
ID and mask being returned as a single unit and concatenated together...and
are split apart later by the SMMU driver.
> In our case we want to mask off the upper TBU ID bits that the SMMU tags
> onto the stream ID in our RID->SID LUT table.
>
> RID = 0
> SID in LUT and seen by SMMU = 7
> SMMU-500 TBU appends bits, making SID something like: 0xC07
> SMR mask of 0x3ff should be applied making the SID: 0x7
>
> > > of_pci_map_rid() seems to have a hardcoded assumption that
> > > each field in the map is 4 bytes.
> >
> > It does. I guess we should explicitly check that #{msi,iommu}-cells = 1
> > on the target node, and maybe clarify in the binding that that cell
> > should represent a plain linear ID value (although that's pretty obvious
> > from context IMO).
> >
> > > (Also, I guess that msi-map is not affected by this since it
> > > is not related to the IOMMU...but we do have common code
> > > handling both maps.)
> >
> > I'd say it's definitely affected, since #msi-cells can equally be more
> > than 1, and encodes an equally opaque value.
> >
> > It seems pretty reasonable to me that we could extend the binding to
> > accommodate #cells > 1 iff length == 1. Mark?
>
> I'm not following why the length matters.
Never mind the comment...think I follow now. Supporting #cells > 1 if
length == 1 sounds good.
Stuart
^ permalink raw reply
* [PATCH v2 3/3] reset: Add the TI SCI reset driver
From: Andrew F. Davis @ 2016-10-28 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkyiC9o9h_mq4D-6pMKNVAKQEnXR5rswiCVa8-mbtgRoJg@mail.gmail.com>
On 10/28/2016 12:43 PM, Mathieu Poirier wrote:
> On 27 October 2016 at 15:49, Andrew F. Davis <afd@ti.com> wrote:
>> Some TI Keystone family of SoCs contain a system controller (like the
>> Power Management Micro Controller (PMMC) on K2G SoCs) that manage the
>> low-level device control (like clocks, resets etc) for the various
>> hardware modules present on the SoC. These device control operations
>> are provided to the host processor OS through a communication protocol
>> called the TI System Control Interface (TI SCI) protocol.
>>
>> This patch adds a reset driver that communicates to the system
>> controller over the TI SCI protocol for performing reset management
>> of various devices present on the SoC. Various reset functionalities
>> are achieved by the means of different TI SCI device operations
>> provided by the TI SCI framework.
>>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> [s-anna at ti.com: documentation changes, revised commit message]
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> ---
>> MAINTAINERS | 1 +
>> drivers/reset/Kconfig | 9 ++
>> drivers/reset/Makefile | 1 +
>> drivers/reset/reset-ti-sci.c | 262 +++++++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 273 insertions(+)
>> create mode 100644 drivers/reset/reset-ti-sci.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index accf991..b93d91a 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -11901,6 +11901,7 @@ F: include/dt-bindings/clock/k2g.h
>> F: drivers/clk/keystone/sci-clk.c
>> F: Documentation/devicetree/bindings/reset/ti,sci-reset.txt
>> F: include/dt-bindings/reset/k2g.h
>> +F: drivers/reset/reset-ti-sci.c
>>
>> THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
>> M: Hans Verkuil <hverkuil@xs4all.nl>
>> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
>> index 06d9fa2..4c21c9d 100644
>> --- a/drivers/reset/Kconfig
>> +++ b/drivers/reset/Kconfig
>> @@ -66,6 +66,15 @@ config RESET_SUNXI
>> help
>> This enables the reset driver for Allwinner SoCs.
>>
>> +config RESET_TI_SCI
>> + tristate "TI System Control Interface (TI-SCI) reset driver"
>> + depends on RESET_CONTROLLER
>> + depends on TI_SCI_PROTOCOL
>> + help
>> + This enables the reset driver support over TI System Control Interface
>> + available on some new TI SoCs. If you wish to use reset resources
>> + managed by the TI System Controller, say Y here. Otherwise, say N.
>> +
>> config TI_SYSCON_RESET
>> tristate "TI SYSCON Reset Driver"
>> depends on HAS_IOMEM
>> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
>> index bbe7026..36321f2 100644
>> --- a/drivers/reset/Makefile
>> +++ b/drivers/reset/Makefile
>> @@ -10,6 +10,7 @@ obj-$(CONFIG_RESET_PISTACHIO) += reset-pistachio.o
>> obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
>> obj-$(CONFIG_RESET_STM32) += reset-stm32.o
>> obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
>> +obj-$(CONFIG_RESET_TI_SCI) += reset-ti-sci.o
>> obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
>> obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
>> obj-$(CONFIG_RESET_ZYNQ) += reset-zynq.o
>> diff --git a/drivers/reset/reset-ti-sci.c b/drivers/reset/reset-ti-sci.c
>> new file mode 100644
>> index 0000000..42ccf12
>> --- /dev/null
>> +++ b/drivers/reset/reset-ti-sci.c
>> @@ -0,0 +1,262 @@
>> +/*
>> + * Texas Instrument's System Control Interface (TI-SCI) reset driver
>> + *
>> + * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
>> + * Andrew F. Davis <afd@ti.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 "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/idr.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/reset-controller.h>
>> +#include <linux/soc/ti/ti_sci_protocol.h>
>> +
>> +/**
>> + * struct ti_sci_reset_control - reset control structure
>> + * @dev_id: SoC-specific device identifier
>> + * @reset_mask: reset mask to use for toggling reset
>> + */
>> +struct ti_sci_reset_control {
>> + u32 dev_id;
>> + u32 reset_mask;
>> +};
>> +
>> +/**
>> + * struct ti_sci_reset_data - reset controller information structure
>> + * @rcdev: reset controller entity
>> + * @dev: reset controller device pointer
>> + * @sci: TI SCI handle used for communication with system controller
>> + * @idr: idr structure for mapping ids to reset control structures
>> + */
>> +struct ti_sci_reset_data {
>> + struct reset_controller_dev rcdev;
>> + struct device *dev;
>> + const struct ti_sci_handle *sci;
>> + struct idr idr;
>> +};
>> +
>> +#define to_ti_sci_reset_data(p) \
>> + container_of((p), struct ti_sci_reset_data, rcdev)
>> +
>> +/**
>> + * ti_sci_reset_set() - program a device's reset
>> + * @rcdev: reset controller entity
>> + * @id: ID of the reset to toggle
>> + * @assert: boolean flag to indicate assert or deassert
>> + *
>> + * This is a common internal function used to assert or deassert a device's
>> + * reset using the TI SCI protocol. The device's reset is asserted if the
>> + * @assert argument is true, or deasserted if @assert argument is false.
>> + * The mechanism itself is a read-modify-write procedure, the current device
>> + * reset register is read using a TI SCI device operation, the new value is
>> + * set or un-set using the reset's mask, and the new reset value written by
>> + * using another TI SCI device operation.
>> + *
>> + * Return: 0 for successful request, else a corresponding error value
>> + */
>> +static int ti_sci_reset_set(struct reset_controller_dev *rcdev,
>> + unsigned long id, bool assert)
>> +{
>> + struct ti_sci_reset_data *data = to_ti_sci_reset_data(rcdev);
>> + const struct ti_sci_handle *sci = data->sci;
>> + const struct ti_sci_dev_ops *dev_ops = &sci->ops.dev_ops;
>> + struct ti_sci_reset_control *control;
>> + u32 reset_state;
>> + int ret;
>> +
>> + control = idr_find(&data->idr, id);
>> + if (!control)
>> + return -EINVAL;
>> +
>> + ret = dev_ops->get_device_resets(sci, control->dev_id,
>> + &reset_state);
>> + if (ret)
>> + return ret;
>> +
>> + if (assert)
>> + reset_state |= control->reset_mask;
>> + else
>> + reset_state &= ~control->reset_mask;
>> +
>> + return dev_ops->set_device_resets(sci, control->dev_id,
>> + reset_state);
>> +}
>> +
>> +/**
>> + * ti_sci_reset_assert() - assert device reset
>> + * @rcdev: reset controller entity
>> + * @id: ID of the reset to be asserted
>> + *
>> + * This function implements the reset driver op to assert a device's reset
>> + * using the TI SCI protocol. This invokes the function ti_sci_reset_set()
>> + * with the corresponding parameters as passed in, but with the @assert
>> + * argument set to true for asserting the reset.
>> + *
>> + * Return: 0 for successful request, else a corresponding error value
>> + */
>> +static int ti_sci_reset_assert(struct reset_controller_dev *rcdev,
>> + unsigned long id)
>> +{
>> + return ti_sci_reset_set(rcdev, id, true);
>> +}
>> +
>> +/**
>> + * ti_sci_reset_deassert() - deassert device reset
>> + * @rcdev: reset controller entity
>> + * @id: ID of the reset to be deasserted
>> + *
>> + * This function implements the reset driver op to deassert a device's reset
>> + * using the TI SCI protocol. This invokes the function ti_sci_reset_set()
>> + * with the corresponding parameters as passed in, but with the @assert
>> + * argument set to false for deasserting the reset.
>> + *
>> + * Return: 0 for successful request, else a corresponding error value
>> + */
>> +static int ti_sci_reset_deassert(struct reset_controller_dev *rcdev,
>> + unsigned long id)
>> +{
>> + return ti_sci_reset_set(rcdev, id, false);
>> +}
>> +
>> +/**
>> + * ti_sci_reset_status() - check device reset status
>> + * @rcdev: reset controller entity
>> + * @id: ID of reset to be checked
>> + *
>> + * This function implements the reset driver op to return the status of a
>> + * device's reset using the TI SCI protocol. The reset register value is read
>> + * by invoking the TI SCI device opertation .get_device_resets(), and the
>> + * status of the specific reset is extracted and returned using this reset's
>> + * reset mask.
>> + *
>> + * Return: 0 if reset is deasserted, or a non-zero value if reset is asserted
>> + */
>> +static int ti_sci_reset_status(struct reset_controller_dev *rcdev,
>> + unsigned long id)
>> +{
>> + struct ti_sci_reset_data *data = to_ti_sci_reset_data(rcdev);
>> + const struct ti_sci_handle *sci = data->sci;
>> + const struct ti_sci_dev_ops *dev_ops = &sci->ops.dev_ops;
>> + struct ti_sci_reset_control *control;
>> + u32 reset_state;
>> + int ret;
>> +
>> + control = idr_find(&data->idr, id);
>> + if (!control)
>> + return -EINVAL;
>> +
>> + ret = dev_ops->get_device_resets(sci, control->dev_id,
>> + &reset_state);
>> + if (ret)
>> + return ret;
>> +
>> + return reset_state & control->reset_mask;
>> +}
>> +
>> +static struct reset_control_ops ti_sci_reset_ops = {
>> + .assert = ti_sci_reset_assert,
>> + .deassert = ti_sci_reset_deassert,
>> + .status = ti_sci_reset_status,
>> +};
>> +
>> +/**
>> + * ti_sci_reset_of_xlate() - translate a set of OF arguments to a reset ID
>> + * @rcdev: reset controller entity
>> + * @reset_spec: OF reset argument specifier
>> + *
>> + * This function performs the translation of the reset argument specifier
>> + * values defined in a reset consumer device node. The function allocates a
>> + * reset control structure for that device reset, and will be used by the
>> + * driver for performing any reset functions on that reset. An idr structure
>> + * is allocated and used to map to the reset control structure. This idr
>> + * is used by the driver to do reset lookups.
>> + *
>> + * Return: 0 for successful request, else a corresponding error value
>> + */
>> +static int ti_sci_reset_of_xlate(struct reset_controller_dev *rcdev,
>> + const struct of_phandle_args *reset_spec)
>> +{
>> + struct ti_sci_reset_data *data = to_ti_sci_reset_data(rcdev);
>> + struct ti_sci_reset_control *control;
>> +
>> + if (WARN_ON(reset_spec->args_count != rcdev->of_reset_n_cells))
>> + return -EINVAL;
>> +
>> + control = devm_kzalloc(data->dev, sizeof(*control), GFP_KERNEL);
>> + if (!control)
>> + return -ENOMEM;
>> +
>> + control->dev_id = reset_spec->args[0];
>> + control->reset_mask = reset_spec->args[1];
>> +
>> + return idr_alloc(&data->idr, control, 0, 0, GFP_KERNEL);
>> +}
>> +
>> +static const struct of_device_id ti_sci_reset_of_match[] = {
>> + { .compatible = "ti,sci-reset", },
>> + { /* sentinel */ },
>> +};
>> +MODULE_DEVICE_TABLE(of, ti_sci_reset_of_match);
>> +
>> +static int ti_sci_reset_probe(struct platform_device *pdev)
>> +{
>> + struct ti_sci_reset_data *data;
>> +
>> + if (!pdev->dev.of_node)
>> + return -ENODEV;
>> +
>> + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
>> + if (!data)
>> + return -ENOMEM;
>> +
>> + data->sci = devm_ti_sci_get_handle(&pdev->dev);
>> + if (IS_ERR(data->sci))
>> + return PTR_ERR(data->sci);
>> +
>> + data->rcdev.ops = &ti_sci_reset_ops;
>> + data->rcdev.owner = THIS_MODULE;
>> + data->rcdev.of_node = pdev->dev.of_node;
>> + data->rcdev.of_reset_n_cells = 2;
>> + data->rcdev.of_xlate = ti_sci_reset_of_xlate;
>> + data->dev = &pdev->dev;
>> + idr_init(&data->idr);
>
> Hello Andrew,
>
> For my own education, is there a specific reason to use a struct idr
> as opposed to keeping a pointer to a struct ti_sci_reset_control in
> truct ti_sci_reset_data? I'm not opposed to the way you've done
> things but simply keeping a pointer sound more intuitive to me.
>
> Thanks,
> Mathieu
>
Hi Mathieu,
There is one ti_sci_reset_data per reset controller, and each reset
controller can have many resets (each described by a
ti_sci_reset_control instance). When a consumer requests a reset we need
to both generate a unique ID to give back to the consumer to reference
this reset and then internally map this ID to a new ti_sci_reset_control
instance for later look-up when the consumer uses this reset, IDR does
both of these for us.
Thanks,
Andrew
>> +
>> + platform_set_drvdata(pdev, data);
>> +
>> + return reset_controller_register(&data->rcdev);
>> +}
>> +
>> +static int ti_sci_reset_remove(struct platform_device *pdev)
>> +{
>> + struct ti_sci_reset_data *data = platform_get_drvdata(pdev);
>> +
>> + reset_controller_unregister(&data->rcdev);
>> +
>> + idr_destroy(&data->idr);
>> +
>> + return 0;
>> +}
>> +
>> +static struct platform_driver ti_sci_reset_driver = {
>> + .probe = ti_sci_reset_probe,
>> + .remove = ti_sci_reset_remove,
>> + .driver = {
>> + .name = "ti-sci-reset",
>> + .of_match_table = ti_sci_reset_of_match,
>> + },
>> +};
>> +module_platform_driver(ti_sci_reset_driver);
>> +
>> +MODULE_AUTHOR("Andrew F. Davis <afd@ti.com>");
>> +MODULE_DESCRIPTION("TI System Control Interface (TI SCI) Reset driver");
>> +MODULE_LICENSE("GPL v2");
>> --
>> 2.10.1
>>
^ permalink raw reply
* [PATCH] fpga zynq: Check the bitstream for validity
From: Moritz Fischer @ 2016-10-28 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028165555.GA17998@obsidianresearch.com>
On Fri, Oct 28, 2016 at 10:55:55AM -0600, Jason Gunthorpe wrote:
> On Fri, Oct 28, 2016 at 06:36:06PM +0200, Matthias Brugger wrote:
>
> > Sure but we are checking here that the bitstream passed to the kernel is
> > correct.
>
> The intent to check if it *possible* that the bitstream is
> correct. Correct means that DONE will assert after programming. A 4
> byte bitstream will never assert DONE.
>
> Arguably the threshold should be larger but we don't know what the
> true minimum is.
>
> > + /* All valid bitstreams are multiples of 32 bits */
> > + if (!count || (count % 4) != 0)
> > + return -EINVAL;
> > +
>
> Too clever for my taste.
>
> Aside from this, is the general idea even OK? In my world I cannonize
> the bitstream to start with the sync word, but others may not be doing
> that.
>
> I designed this patch based on the prior work to remove the
> auto-detection, eg that the driver should be passed a canonized
> bitstream.
I'm fine with checking for boundary cases where the bitstreams are
obviously too small or wrong size, I'm not convinced that checking using
internal knowledge about the bistream format inside the kernel is the
right place.
> The problem with the way it is now is how hard it is to figure out
> what the right bitstream format should be. Clear instructions to
> canonize by droping the header before the sync word and byteswap so
> the sync word is in the given order is much clearer..
I don't know about you, but for my designs I can just use what drops out
of my Vivado build. Are you unhappy with the way we document which
format to use, or that we don't slice off the beginning (that gets
ignored by hardware?).
Thanks for addressing the issues with the length calculations,
Moritz
^ permalink raw reply
* [PATCH v12 RESEND 0/4] generic TEE subsystem
From: Mark Brown @ 2016-10-28 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1e532aeb-4944-62e4-c8c4-1e23438b92cd@ti.com>
On Fri, Oct 28, 2016 at 10:43:24AM -0500, Andrew F. Davis wrote:
> Do we see this as a chicken and egg situation, or is there any harm
> beyond the pains of supporting an out-of-tree driver for a while, to
> wait until we have at least one other TEE to add to this subsystem
> before merging?
We haven't been overburneded with TEE vendors wanting to get their
driver code into mainline - do we have any reasonable prospect of other
TEE vendors with an interest in mainline turning up in any kind of
reasonable timeframe?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161028/3adb9948/attachment.sig>
^ permalink raw reply
* [PATCH v6] soc: qcom: add l2 cache perf events driver
From: Leeder, Neil @ 2016-10-28 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028160213.GH1076@arm.com>
On 10/28/2016 12:02 PM, Will Deacon wrote:
> On Tue, Oct 04, 2016 at 12:25:54PM -0400, Neil Leeder wrote:
>> Thanks Mark. I'll move it, rebase on 4.9-rc1 and run perf fuzzer.
>
> Did the fuzzer explode, or do you have a new version you can post?
>
> Will
Hi Will,
I was delayed by some logistical problems, but the fuzzer ran fine and I
will post the updated patch shortly - sorry for the delay.
Neil
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v2] spi: spi-fsl-dspi: Add DMA support for Vybrid
From: Mark Brown @ 2016-10-28 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017062308.GA3478@Sanchayan-Arch.localdomain>
On Mon, Oct 17, 2016 at 11:53:08AM +0530, maitysanchayan at gmail.com wrote:
> Hello,
>
> Ping?
Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holiday, attend conferences and so
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review. If there have been
review comments then people may be waiting for those to be addressed.
Sending content free pings just adds to the mail volume (if they are
seen at all) and if something has gone wrong you'll have to resend the
patches anyway.
Please don't top post, reply in line with needed context. This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161028/2a48a59a/attachment.sig>
^ permalink raw reply
* [PATCH v2] phy: sun4i: check PMU presence when poking unknown bit of pmu
From: Hans de Goede @ 2016-10-28 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028162701.4531-1-icenowy@aosc.xyz>
Hi,
On 28-10-16 18:27, Icenowy Zheng wrote:
> Allwinner SoC's PHY 0, when used as OTG controller, have no pmu part.
> The code that poke some unknown bit of PMU for H3/A64 didn't check
> the PHY, and will cause kernel oops when PHY 0 is used.
>
> This patch will check whether the pmu is not NULL before poking.
>
> Fixes: b3e0d141ca9f (phy: sun4i: add support for A64 usb phy)
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Patch LGTM too:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
> ---
> drivers/phy/phy-sun4i-usb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index b9342a2..fec34f5 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -264,7 +264,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
> return ret;
> }
>
> - if (data->cfg->enable_pmu_unk1) {
> + if (phy->pmu && data->cfg->enable_pmu_unk1) {
> val = readl(phy->pmu + REG_PMU_UNK1);
> writel(val & ~2, phy->pmu + REG_PMU_UNK1);
> }
>
^ permalink raw reply
* [PATCH v3 1/2] clk: imx: fix integer overflow in AV PLL round rate
From: Stephen Boyd @ 2016-10-28 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5Co32XUpNFz4Hd2DEmNnMBvD5fKmsyjcmsgawea4dJR9g@mail.gmail.com>
On 10/28, Fabio Estevam wrote:
> On Thu, Oct 27, 2016 at 11:41 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> > On 10/12, Emil Lundmark wrote:
> >> Since 'parent_rate * mfn' may overflow 32 bits, the result should be
> >> stored using 64 bits.
> >>
> >> The problem was discovered when trying to set the rate of the audio PLL
> >> (pll4_post_div) on an i.MX6Q. The desired rate was 196.608 MHz, but
> >> the actual rate returned was 192.000570 MHz. The round rate function should
> >> have been able to return 196.608 MHz, i.e., the desired rate.
> >>
> >> Fixes: ba7f4f557eb6 ("clk: imx: correct AV PLL rate formula")
> >> Cc: Anson Huang <b20788@freescale.com>
> >> Signed-off-by: Emil Lundmark <emil@limesaudio.com>
> >> ---
> >
> > Applied to clk-next
>
> This one fixes a regression caused by ba7f4f557eb6 ("clk: imx: correct
> AV PLL rate formula").
>
> So it should go to clk-fixes instead with the stable tag:
>
> Cc: <stable@vger.kernel.org> # 4.8.x
>
The clk-fixes branch is for patches that fix problems in code
merged during the merge window as well as small one-liners and
things that are causing great pain for people on the latest
release. Given that this fixes a regression in v4.8 and we're
trying to stabilize v4.9 it looked like it could wait until
v4.10.
So is there something going on here where the pain is too much to
wait for the next merge window? If so the commit text should
mention something about what's causing that pain. Perhaps by
referencing the commit that merged outside of clk tree that
caused problems.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [linux-sunxi] [PATCH RESEND 1/2] dt: bindings: add allwinner,otg-routed property for phy-sun4i-usb
From: Hans de Goede @ 2016-10-28 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86c3fad4-e0c1-9aaf-76c5-b9428110464f@redhat.com>
HI,
On 26-10-16 12:14, Hans de Goede wrote:
> Hi,
>
> On 26-10-16 10:52, Icenowy Zheng wrote:
>>
>>
>> 26.10.2016, 16:28, "Hans de Goede" <hdegoede@redhat.com>:
>>> Hi,
>>>
>>> On 25-10-16 06:11, Icenowy Zheng wrote:
>>>> On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
>>>> the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
>>>> (which is a Host-only controller, but more stable and easy to implement).
>>>>
>>>> This property marks whether on a certain board which controller should be
>>>> attached to the PHY.
>>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>>>
>>> Icenowy, I appreciate your work on this, but we really need full otg
>>> support with dynamic switching rather then hardwiring the routing, so
>>> this cannot go in as is.
>>
>> Now I have both PHY0 controllers' drivers.
>>
>> In the tree of https://github.com/Icenowy/linux/tree/ice-a64-v6.1 , I have already
>> enabled MUSB controller.
>>
>> And this patchset is for those prefer a stable USB host implement to dual-role
>> implementation. MUSB is a good UDC, but not a good host controller. My USB
>> sound card cannot work on MUSB on A33. Even connecting a R8's MUSB (Serial
>> Gadget) to an A33's MUSB cannot work.
>
> The idea is for dual-role setups to used the MUSB in gadget mode and the EHCI/OHCI
> pair when in host mode. So for otg setups you would runtime change the mux
> from one controller to the other based on the id pin value.
>
> Take a look at drivers/phy/phy-sun4i-usb.c, around line 512:
>
> if (id_det != data->id_det) {
> ...
> }
>
> This deals with id_det changes (including the initial id_det "change"
> for hardwired host-only ports). This currently assumes that the musb
> will be used for host mode too, we will want to change this to
> something like this:
>
> if (id_det != data->id_det) {
> if (data->cfg->separate_phy0_host_controller) {
> if (id_det) {
> /* Change to gadget mode (id_det == 1), switch phy mux to musb */
> actual code to switch phy mux to musb...
> } else {
> /* Change to host mode (id_det == 0), switch phy mux to ehci/ohci */
> actual code to switch phy mux to ehci/ohci...
> }
> }
> /* old code */
> }
>
> Note this will then still rely on the musb code to actually turn
> the regulator on, so you do need to have the musb driver build and
> loaded. This can be fixed but lets start with the above.
>
> If you combine this with dr_mode = "host"; in the dts, then
> sun4i_usb_phy0_get_id_det() will return 0 so on its first run
> sun4i_usb_phy0_id_vbus_det_scan() will throw the mux to the ehci/ohci
> and everything should work as you want without needing the custom
> "allwinner,otg-routed" property, and we should be more or less
> ready to support full otg on other boards.
I've just found further proof that the musb on the H3 at least
only is intended for gadget mode and that we must dynamically
switch for host-mode. If you look at:
drivers/usb/sunxi_usb/include/sunxi_udc.h
In the h3 sdk then you will see that for the H3 a different fifo
endpoint table is used, as the total fifo space is only 4k where
as previous SoCs had 8k. This means that we need to have 2
different ep tables in drivers/usb/musb/sunxi.c and select by
compatible.
Regards,
Hans
^ permalink raw reply
* [PATCH] staging: vc04_services: call sg_init_table to init scatterlist
From: Michael Zoran @ 2016-10-28 17:58 UTC (permalink / raw)
To: linux-arm-kernel
Call the sg_init_table function to correctly initialze
the DMA scatterlist. This function is required to completely
initialize the list and is mandatory if DMA debugging is
enabled in the build configuration.
One of the purposes of sg_init_table is to set
the magic "cookie" on each list element and ensure
the chain end is marked.
Signed-off-by: Michael Zoran <mzoran@crowfest.net>
---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index 6fa2b5a..21b26e5 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -464,6 +464,12 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
pagelist->type = type;
pagelist->offset = offset;
+ /*
+ * Initialize the scatterlist so that the magic cookie
+ * is filled if debugging is enabled
+ */
+ sg_init_table(scatterlist, num_pages);
+ /* Now set the pages for each scatterlist */
for (i = 0; i < num_pages; i++)
sg_set_page(scatterlist + i, pages[i], PAGE_SIZE, 0);
--
2.10.1
^ permalink raw reply related
* [PATCH] [ARM] Fix stack alignment when processing backtraces
From: Jason Gunthorpe @ 2016-10-28 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018170510.GA12248@obsidianresearch.com>
On Tue, Oct 18, 2016 at 11:05:10AM -0600, Jason Gunthorpe wrote:
> The dumpstm helper within c_backtrace pushed 5 dwords onto the stack
> causing the stack to become unaligned and then calls printk. This
> causes memory corruption in the kernel which assumes AAPCS calling
> convention.
>
> Since this bit of asm doesn't use the standard prologue just add
> another register to restore alignment.
>
> Fixes: 7ab3f8d595a1b ("[ARM] Add ability to dump exception stacks to kernel backtraces")
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> arch/arm/lib/backtrace.S | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> In my case the kernel was hitting a WARN_ON during boot and then
> reliably failed to start the compiled-in initramfs.
>
> I'm inferring that the stack misalignment caused some kind of memory
> corruption which wiped out the unpacked initramfs.
>
> Saw with gcc 5.4.0 on a kirkwood armv5te
Since there are no comments, I will send this to RMK's patch system..
Thanks,
Jason
> diff --git a/arch/arm/lib/backtrace.S b/arch/arm/lib/backtrace.S
> index fab5a50503ae..25e1cce19991 100644
> +++ b/arch/arm/lib/backtrace.S
> @@ -116,7 +116,8 @@ ENDPROC(c_backtrace)
> #define reg r5
> #define stack r6
>
> -.Ldumpstm: stmfd sp!, {instr, reg, stack, r7, lr}
> + /* Must maintain 8 byte stack alignment */
> +.Ldumpstm: stmfd sp!, {r3, instr, reg, stack, r7, lr}
> mov stack, r0
> mov instr, r1
> mov reg, #10
> @@ -140,7 +141,7 @@ ENDPROC(c_backtrace)
> teq r7, #0
> adrne r0, .Lcr
> blne printk
> - ldmfd sp!, {instr, reg, stack, r7, pc}
> + ldmfd sp!, {r3, instr, reg, stack, r7, pc}
>
> .Lfp: .asciz " r%d:%08x%s"
> .Lcr: .asciz "\n"
^ permalink raw reply
* [PATCH] ASoC: samsung: Drop AC97 drivers
From: Mark Brown @ 2016-10-28 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477671072-742-1-git-send-email-s.nawrocki@samsung.com>
On Fri, Oct 28, 2016 at 06:11:12PM +0200, Sylwester Nawrocki wrote:
> The AC97 drivers are broken and it seems these have not been used
> for a long time. This patch removes the unused code, i.e. Samsung
> SoC AC97 controller driver and related machine drivers:
> ln2440sbc_alc650, smdk2443_wm9710, smdk_wm9713.
This needs rebasing against some of the recent fixes, sorry.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161028/cddf7f0f/attachment.sig>
^ permalink raw reply
* [PATCH v2 3/3] reset: Add the TI SCI reset driver
From: Mathieu Poirier @ 2016-10-28 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027214941.24641-4-afd@ti.com>
On 27 October 2016 at 15:49, Andrew F. Davis <afd@ti.com> wrote:
> Some TI Keystone family of SoCs contain a system controller (like the
> Power Management Micro Controller (PMMC) on K2G SoCs) that manage the
> low-level device control (like clocks, resets etc) for the various
> hardware modules present on the SoC. These device control operations
> are provided to the host processor OS through a communication protocol
> called the TI System Control Interface (TI SCI) protocol.
>
> This patch adds a reset driver that communicates to the system
> controller over the TI SCI protocol for performing reset management
> of various devices present on the SoC. Various reset functionalities
> are achieved by the means of different TI SCI device operations
> provided by the TI SCI framework.
>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> [s-anna at ti.com: documentation changes, revised commit message]
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> MAINTAINERS | 1 +
> drivers/reset/Kconfig | 9 ++
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-ti-sci.c | 262 +++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 273 insertions(+)
> create mode 100644 drivers/reset/reset-ti-sci.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index accf991..b93d91a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11901,6 +11901,7 @@ F: include/dt-bindings/clock/k2g.h
> F: drivers/clk/keystone/sci-clk.c
> F: Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> F: include/dt-bindings/reset/k2g.h
> +F: drivers/reset/reset-ti-sci.c
>
> THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
> M: Hans Verkuil <hverkuil@xs4all.nl>
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index 06d9fa2..4c21c9d 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -66,6 +66,15 @@ config RESET_SUNXI
> help
> This enables the reset driver for Allwinner SoCs.
>
> +config RESET_TI_SCI
> + tristate "TI System Control Interface (TI-SCI) reset driver"
> + depends on RESET_CONTROLLER
> + depends on TI_SCI_PROTOCOL
> + help
> + This enables the reset driver support over TI System Control Interface
> + available on some new TI SoCs. If you wish to use reset resources
> + managed by the TI System Controller, say Y here. Otherwise, say N.
> +
> config TI_SYSCON_RESET
> tristate "TI SYSCON Reset Driver"
> depends on HAS_IOMEM
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
> index bbe7026..36321f2 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_RESET_PISTACHIO) += reset-pistachio.o
> obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
> obj-$(CONFIG_RESET_STM32) += reset-stm32.o
> obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
> +obj-$(CONFIG_RESET_TI_SCI) += reset-ti-sci.o
> obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
> obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
> obj-$(CONFIG_RESET_ZYNQ) += reset-zynq.o
> diff --git a/drivers/reset/reset-ti-sci.c b/drivers/reset/reset-ti-sci.c
> new file mode 100644
> index 0000000..42ccf12
> --- /dev/null
> +++ b/drivers/reset/reset-ti-sci.c
> @@ -0,0 +1,262 @@
> +/*
> + * Texas Instrument's System Control Interface (TI-SCI) reset driver
> + *
> + * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
> + * Andrew F. Davis <afd@ti.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 "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/idr.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/reset-controller.h>
> +#include <linux/soc/ti/ti_sci_protocol.h>
> +
> +/**
> + * struct ti_sci_reset_control - reset control structure
> + * @dev_id: SoC-specific device identifier
> + * @reset_mask: reset mask to use for toggling reset
> + */
> +struct ti_sci_reset_control {
> + u32 dev_id;
> + u32 reset_mask;
> +};
> +
> +/**
> + * struct ti_sci_reset_data - reset controller information structure
> + * @rcdev: reset controller entity
> + * @dev: reset controller device pointer
> + * @sci: TI SCI handle used for communication with system controller
> + * @idr: idr structure for mapping ids to reset control structures
> + */
> +struct ti_sci_reset_data {
> + struct reset_controller_dev rcdev;
> + struct device *dev;
> + const struct ti_sci_handle *sci;
> + struct idr idr;
> +};
> +
> +#define to_ti_sci_reset_data(p) \
> + container_of((p), struct ti_sci_reset_data, rcdev)
> +
> +/**
> + * ti_sci_reset_set() - program a device's reset
> + * @rcdev: reset controller entity
> + * @id: ID of the reset to toggle
> + * @assert: boolean flag to indicate assert or deassert
> + *
> + * This is a common internal function used to assert or deassert a device's
> + * reset using the TI SCI protocol. The device's reset is asserted if the
> + * @assert argument is true, or deasserted if @assert argument is false.
> + * The mechanism itself is a read-modify-write procedure, the current device
> + * reset register is read using a TI SCI device operation, the new value is
> + * set or un-set using the reset's mask, and the new reset value written by
> + * using another TI SCI device operation.
> + *
> + * Return: 0 for successful request, else a corresponding error value
> + */
> +static int ti_sci_reset_set(struct reset_controller_dev *rcdev,
> + unsigned long id, bool assert)
> +{
> + struct ti_sci_reset_data *data = to_ti_sci_reset_data(rcdev);
> + const struct ti_sci_handle *sci = data->sci;
> + const struct ti_sci_dev_ops *dev_ops = &sci->ops.dev_ops;
> + struct ti_sci_reset_control *control;
> + u32 reset_state;
> + int ret;
> +
> + control = idr_find(&data->idr, id);
> + if (!control)
> + return -EINVAL;
> +
> + ret = dev_ops->get_device_resets(sci, control->dev_id,
> + &reset_state);
> + if (ret)
> + return ret;
> +
> + if (assert)
> + reset_state |= control->reset_mask;
> + else
> + reset_state &= ~control->reset_mask;
> +
> + return dev_ops->set_device_resets(sci, control->dev_id,
> + reset_state);
> +}
> +
> +/**
> + * ti_sci_reset_assert() - assert device reset
> + * @rcdev: reset controller entity
> + * @id: ID of the reset to be asserted
> + *
> + * This function implements the reset driver op to assert a device's reset
> + * using the TI SCI protocol. This invokes the function ti_sci_reset_set()
> + * with the corresponding parameters as passed in, but with the @assert
> + * argument set to true for asserting the reset.
> + *
> + * Return: 0 for successful request, else a corresponding error value
> + */
> +static int ti_sci_reset_assert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + return ti_sci_reset_set(rcdev, id, true);
> +}
> +
> +/**
> + * ti_sci_reset_deassert() - deassert device reset
> + * @rcdev: reset controller entity
> + * @id: ID of the reset to be deasserted
> + *
> + * This function implements the reset driver op to deassert a device's reset
> + * using the TI SCI protocol. This invokes the function ti_sci_reset_set()
> + * with the corresponding parameters as passed in, but with the @assert
> + * argument set to false for deasserting the reset.
> + *
> + * Return: 0 for successful request, else a corresponding error value
> + */
> +static int ti_sci_reset_deassert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + return ti_sci_reset_set(rcdev, id, false);
> +}
> +
> +/**
> + * ti_sci_reset_status() - check device reset status
> + * @rcdev: reset controller entity
> + * @id: ID of reset to be checked
> + *
> + * This function implements the reset driver op to return the status of a
> + * device's reset using the TI SCI protocol. The reset register value is read
> + * by invoking the TI SCI device opertation .get_device_resets(), and the
> + * status of the specific reset is extracted and returned using this reset's
> + * reset mask.
> + *
> + * Return: 0 if reset is deasserted, or a non-zero value if reset is asserted
> + */
> +static int ti_sci_reset_status(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct ti_sci_reset_data *data = to_ti_sci_reset_data(rcdev);
> + const struct ti_sci_handle *sci = data->sci;
> + const struct ti_sci_dev_ops *dev_ops = &sci->ops.dev_ops;
> + struct ti_sci_reset_control *control;
> + u32 reset_state;
> + int ret;
> +
> + control = idr_find(&data->idr, id);
> + if (!control)
> + return -EINVAL;
> +
> + ret = dev_ops->get_device_resets(sci, control->dev_id,
> + &reset_state);
> + if (ret)
> + return ret;
> +
> + return reset_state & control->reset_mask;
> +}
> +
> +static struct reset_control_ops ti_sci_reset_ops = {
> + .assert = ti_sci_reset_assert,
> + .deassert = ti_sci_reset_deassert,
> + .status = ti_sci_reset_status,
> +};
> +
> +/**
> + * ti_sci_reset_of_xlate() - translate a set of OF arguments to a reset ID
> + * @rcdev: reset controller entity
> + * @reset_spec: OF reset argument specifier
> + *
> + * This function performs the translation of the reset argument specifier
> + * values defined in a reset consumer device node. The function allocates a
> + * reset control structure for that device reset, and will be used by the
> + * driver for performing any reset functions on that reset. An idr structure
> + * is allocated and used to map to the reset control structure. This idr
> + * is used by the driver to do reset lookups.
> + *
> + * Return: 0 for successful request, else a corresponding error value
> + */
> +static int ti_sci_reset_of_xlate(struct reset_controller_dev *rcdev,
> + const struct of_phandle_args *reset_spec)
> +{
> + struct ti_sci_reset_data *data = to_ti_sci_reset_data(rcdev);
> + struct ti_sci_reset_control *control;
> +
> + if (WARN_ON(reset_spec->args_count != rcdev->of_reset_n_cells))
> + return -EINVAL;
> +
> + control = devm_kzalloc(data->dev, sizeof(*control), GFP_KERNEL);
> + if (!control)
> + return -ENOMEM;
> +
> + control->dev_id = reset_spec->args[0];
> + control->reset_mask = reset_spec->args[1];
> +
> + return idr_alloc(&data->idr, control, 0, 0, GFP_KERNEL);
> +}
> +
> +static const struct of_device_id ti_sci_reset_of_match[] = {
> + { .compatible = "ti,sci-reset", },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, ti_sci_reset_of_match);
> +
> +static int ti_sci_reset_probe(struct platform_device *pdev)
> +{
> + struct ti_sci_reset_data *data;
> +
> + if (!pdev->dev.of_node)
> + return -ENODEV;
> +
> + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + data->sci = devm_ti_sci_get_handle(&pdev->dev);
> + if (IS_ERR(data->sci))
> + return PTR_ERR(data->sci);
> +
> + data->rcdev.ops = &ti_sci_reset_ops;
> + data->rcdev.owner = THIS_MODULE;
> + data->rcdev.of_node = pdev->dev.of_node;
> + data->rcdev.of_reset_n_cells = 2;
> + data->rcdev.of_xlate = ti_sci_reset_of_xlate;
> + data->dev = &pdev->dev;
> + idr_init(&data->idr);
Hello Andrew,
For my own education, is there a specific reason to use a struct idr
as opposed to keeping a pointer to a struct ti_sci_reset_control in
truct ti_sci_reset_data? I'm not opposed to the way you've done
things but simply keeping a pointer sound more intuitive to me.
Thanks,
Mathieu
> +
> + platform_set_drvdata(pdev, data);
> +
> + return reset_controller_register(&data->rcdev);
> +}
> +
> +static int ti_sci_reset_remove(struct platform_device *pdev)
> +{
> + struct ti_sci_reset_data *data = platform_get_drvdata(pdev);
> +
> + reset_controller_unregister(&data->rcdev);
> +
> + idr_destroy(&data->idr);
> +
> + return 0;
> +}
> +
> +static struct platform_driver ti_sci_reset_driver = {
> + .probe = ti_sci_reset_probe,
> + .remove = ti_sci_reset_remove,
> + .driver = {
> + .name = "ti-sci-reset",
> + .of_match_table = ti_sci_reset_of_match,
> + },
> +};
> +module_platform_driver(ti_sci_reset_driver);
> +
> +MODULE_AUTHOR("Andrew F. Davis <afd@ti.com>");
> +MODULE_DESCRIPTION("TI System Control Interface (TI SCI) Reset driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.10.1
>
^ permalink raw reply
* SMR masking and PCI
From: Mark Rutland @ 2016-10-28 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c39b785a-0f18-fc0a-ce08-7ebe3cfaf8c5@arm.com>
Hi,
On Fri, Oct 28, 2016 at 05:16:37PM +0100, Robin Murphy wrote:
> On 27/10/16 18:10, Stuart Yoder wrote:
> > A question about how the SMR masking defined in the arm,smmu binding
> > relates to the PCI iommu-map.
> >
> > The #iommu-cells property defines the number of cells an "IOMMU specifier"
> > takes and 2 is specified to be:
> >
> > SMMUs with stream matching support and complex masters
> > may use a value of 2, where the second cell represents
> > an SMR mask to combine with the ID in the first cell.
> >
> > An iommu-map entry is defined as:
> >
> > (rid-base,iommu,iommu-base,length)
> >
> > What seems to be currently missing in the iommu-map support is
> > the possibility the case where #iommu-cells=<2>.
>
> Indeed. The bindings have so far rather implicitly assumed the case of
> #{msi,iommu}-cells = 1, and the code has followed suit.
The intention was that neither the iommu or msi bindings had such a
requirement, but evidently I did not specify the intended behaviour
thoroughly enough.
I had intended that the offset was added to the final cell of the
iommu-specifier (i.e. that the iommu-specifier was treated as a large
number).
You can handle this case by adding additional entries in the map table,
with a single entry length.
> > In this case iommu-base which is an IOMMU specifier should
> > occupy 2 cells. For example on an ls2085a we would want:
> >
> > iommu-map = <0x0 0x6 0x7 0x3ff 0x1
> > 0x100 0x6 0x8 0x3ff 0x1>;
> >
> > ...to mask our stream IDs to 10 bits.
> >
> > This should work in theory and comply with the bindings, no?
>
> In theory, but now consider:
>
> iommu-map = <0x0 0x6 0x7 0x3ff 0x2>;
>
> faced with ID 1. The input base is 0, the output base is the 2-cell
> value 0x7000003ff, so the final ID value should be 0x700000400, right?
That was the intended behaviour, yes.
> > (Also, I guess that msi-map is not affected by this since it
> > is not related to the IOMMU...but we do have common code
> > handling both maps.)
>
> I'd say it's definitely affected, since #msi-cells can equally be more
> than 1, and encodes an equally opaque value.
Yes.
> It seems pretty reasonable to me that we could extend the binding to
> accommodate #cells > 1 iff length == 1. Mark?
I will try to come up with the wording to make the above explicit, for
both bindings.
Thanks,
Mark.
^ 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