* [PATCH] ARM: dts: socfpga: add nand controller nodes
From: Steffen Trumtrar @ 2016-11-10 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a7127bcd-ec0e-cb47-592d-06f404857d50@kernel.org>
On Wed, Nov 09, 2016 at 12:48:21PM -0600, Dinh Nguyen wrote:
>
>
> On 11/09/2016 01:35 AM, Steffen Trumtrar wrote:
> > Add the denali nand controller to the socfpga dtsi.
> >
> > Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> > ---
> > arch/arm/boot/dts/socfpga.dtsi | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
> > index 9f48141270b8..6b0c23ca5e88 100644
> > --- a/arch/arm/boot/dts/socfpga.dtsi
> > +++ b/arch/arm/boot/dts/socfpga.dtsi
> > @@ -700,6 +700,19 @@
> > status = "disabled";
> > };
> >
> > + nand0: nand at ff900000 {
> > + #address-cells = <0x1>;
> > + #size-cells = <0x1>;
> > + compatible = "denali,denali-nand-dt";
> > + reg = <0xff900000 0x100000>,
> > + <0xffb80000 0x10000>;
> > + reg-names = "nand_data", "denali_reg";
> > + interrupts = <0x0 0x90 0x4>;
> > + dma-mask = <0xffffffff>;
> > + clocks = <&nand_clk>;
> > + status = "disabled";
> > + };
> > +
> > ocram: sram at ffff0000 {
> > compatible = "mmio-sram";
> > reg = <0xffff0000 0x10000>;
> >
>
> Since there's only 1 NAND node, do we need to call the node "nand0"? No
> need to resend a patch, I can change it locally if we agree that the
> node should be just:
>
> nand: nand at ff900000
>
Okay with me. Go ahead.
Thanks,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Hans de Goede @ 2016-11-10 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109192301.GS26979@atomide.com>
Hi,
On 09-11-16 20:23, Tony Lindgren wrote:
> Hi,
>
> Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing
> the sysfs brightness attr for changes.") breaks runtime PM for me.
>
> On my omap dm3730 based test system, idle power consumption is over 70
> times higher now with this patch! It goes from about 6mW for the core
> system to over 440mW during idle meaning there's some busy timer now
> active.
Do you have any blinking LEDs or LED triggers defined on the system ?
> Reverting this patch fixes the issue. Any ideas?
All I can think of is something calling led_set_brightness quite often,
the patch in question makes led_set_brightness somewhat more expensive,
but it should not cause such a big difference unless something is
really calling led_set_brightness quite often maybe something is calling
it with the same value all the time ?
Regards,
Hans
^ permalink raw reply
* [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: zhichang.yuan @ 2016-11-10 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478647002.7430.69.camel@kernel.crashing.org>
Hi, Ben,
On 2016/11/9 7:16, Benjamin Herrenschmidt wrote:
> On Tue, 2016-11-08 at 12:03 +0000, Mark Rutland wrote:
>> On Tue, Nov 08, 2016 at 11:47:07AM +0800, zhichang.yuan wrote:
>>>
>>> For arm64, there is no I/O space as other architectural platforms, such as
>>> X86. Most I/O accesses are achieved based on MMIO. But for some arm64 SoCs,
>>> such as Hip06, when accessing some legacy ISA devices connected to LPC, those
>>> known port addresses are used to control the corresponding target devices, for
>>> example, 0x2f8 is for UART, 0xe4 is for ipmi-bt. It is different from the
>>> normal MMIO mode in using.
>>
>> This has nothing to do with arm64. Hardware with this kind of indirect
>> bus access could be integrated with a variety of CPU architectures. It
>> simply hasn't been, yet.
>
> On some ppc's we also use similar indirect access methods for IOs. We
> have a generic infrastructure for re-routing some memory or IO regions
> to hooks.
>
I am interested on the generic infrastructure on PPC.
Could you point out where those drivers are?
want to take a look..
Thanks,
Zhichang
> On POWER8, our PCIe doesn't do IO at all, but we have an LPC bus behind
> firmware calls ;-) We use that infrastructure to plumb in the LPC bus.
>
>>> To drive these devices, this patch introduces a method named indirect-IO.
>>> In this method the in/out pair in arch/arm64/include/asm/io.h will be
>>> redefined. When upper layer drivers call in/out with those known legacy port
>>> addresses to access the peripherals, the hooking functions corrresponding to
>>> those target peripherals will be called. Through this way, those upper layer
>>> drivers which depend on in/out can run on Hip06 without any changes.
>>
>> As above, this has nothing to do with arm64, and as such, should live in
>> generic code, exactly as we would do if we had higher-level ISA
>> accessor ops.
>>
>> Regardless, given the multi-instance case, I don't think this is
>> sufficient in general (and I think we need higher-level ISA accessors
>> to handle the indirection).
>
> Multi-instance with IO is tricky to do generically because archs already
> have all sort of hacks to deal with the fact that inb/outb don't require
> an explicit ioremap, so an IO resource can take all sort of shape depending
> on the arch.
>
> Overall it boils down to applying some kind of per-instance "offset" to
> the IO port number though.
>
^ permalink raw reply
* [PATCH] PCI: mvebu: Take control of mbus windows setup by the firmware
From: Thomas Petazzoni @ 2016-11-10 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026174440.GA24717@obsidianresearch.com>
Hello,
On Wed, 26 Oct 2016 11:44:40 -0600, Jason Gunthorpe wrote:
> The firmware may setup the mbus to access PCI-E and indicate this
> has happened with a ranges mapping for the PCI-E ID. If this happens
> then the mbus setup and the pci dynamic setup conflict, creating
> problems.
>
> Have PCI-E assume control of the firmware specified default mapping by
> setting the value of the bridge window to match the firmware mapping.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Sorry for the late feedback. I am not sure to fully understand what you
are trying to do here.
However, one thing that confuses me specifically is how can the kernel
get any MBus mapping set up by the firmware? Indeed, when the
mvebu-mbus driver initializes, it destroys all existing MBus windows
that might have been left by the firmware/bootloader:
static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
phys_addr_t mbuswins_phys_base,
size_t mbuswins_size,
phys_addr_t sdramwins_phys_base,
size_t sdramwins_size,
phys_addr_t mbusbridge_phys_base,
size_t mbusbridge_size,
bool is_coherent)
[...]
for (win = 0; win < mbus->soc->num_wins; win++)
mvebu_mbus_disable_window(mbus, win);
Why does Linux needs to rely on what the firmware has setup in terms of
MBus windows? Why can't Linux just find out the right BAR base/size
like it is doing for all other devices?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom DT warning
From: Thomas Petazzoni @ 2016-11-10 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110001000.10619-5-gregory.clement@free-electrons.com>
Hello,
On Thu, 10 Nov 2016 01:09:50 +0100, Gregory CLEMENT wrote:
> - bootrom {
> + bootrom at 0 {
> compatible = "marvell,bootrom";
> reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
I am still not sure whether this "0" unit address is correct compared
to the reg property being passed.
A good example of why I'm worried is the sa-sram case:
+ crypto_sram0: sa-sram0 at 0 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
+ crypto_sram1: sa-sram1 at 0 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
The node names should be just "sram" without a number. Indeed for UARTs
for example, you use uart at XYZ, uart at ABC and not uart0 at XYZ and
uart1 at ABC. But then, if you do that, with your scheme, you end up with
both nodes named sa-sram at 0.
Which clearly shows that the way you set this unit-address is not
correct: those two devices are mapped at completely different
locations, but you end up with an identical unit address.
I have no idea what is the rule for setting the unit address in this
case, but I'm pretty sure the rule you've chosen is not good.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v4] regulator: lp873x: Add support for populating input supply
From: Lee Jones @ 2016-11-10 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110052915.4898-1-lokeshvutla@ti.com>
On Thu, 10 Nov 2016, Lokesh Vutla wrote:
> In order to have a proper topology of regulators for a platform, each
> registering regulator needs to populate supply_name field for identifying
> its supply's name. Add supply_name field for lp873x regulators.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> Changes since v3:
> - Applied Rob's ack.
> - Sending this patch separately so that this can be merged via Regulator tree.
> - Link to v3: https://patchwork.kernel.org/patch/9408545/
>
> Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> drivers/regulator/lp873x-regulator.c | 1 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt b/Documentation/devicetree/bindings/mfd/lp873x.txt
> index 52766c2..ae9cf39 100644
> --- a/Documentation/devicetree/bindings/mfd/lp873x.txt
> +++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
> @@ -7,6 +7,9 @@ Required properties:
> - #gpio-cells: Should be two. The first cell is the pin number and
> the second cell is used to specify flags.
> See ../gpio/gpio.txt for more information.
> + - xxx-in-supply: Phandle to parent supply node of each regulator
> + populated under regulators node. xxx can be
> + buck0, buck1, ldo0 or ldo1.
> - regulators: List of child nodes that specify the regulator
> initialization data.
> Example:
> @@ -17,6 +20,11 @@ pmic: lp8733 at 60 {
> gpio-controller;
> #gpio-cells = <2>;
>
> + buck0-in-supply = <&vsys_3v3>;
> + buck1-in-supply = <&vsys_3v3>;
> + ldo0-in-supply = <&vsys_3v3>;
> + ldo1-in-supply = <&vsys_3v3>;
> +
> regulators {
> lp8733_buck0: buck0 {
> regulator-name = "lp8733-buck0";
> diff --git a/drivers/regulator/lp873x-regulator.c b/drivers/regulator/lp873x-regulator.c
> index e504b91..70e3df6 100644
> --- a/drivers/regulator/lp873x-regulator.c
> +++ b/drivers/regulator/lp873x-regulator.c
> @@ -24,6 +24,7 @@
> [_id] = { \
> .desc = { \
> .name = _name, \
> + .supply_name = _of "-in", \
> .id = _id, \
> .of_match = of_match_ptr(_of), \
> .regulators_node = of_match_ptr("regulators"),\
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2] ARM: at91/dt: fixes dbgu pinctrl, set pullup on rx, clear pullup on tx
From: Peter Rosin @ 2016-11-10 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110000923.ltpouekbkx7onzm7@piout.net>
On 2016-11-10 01:09, Alexandre Belloni wrote:
> On 10/11/2016 at 00:41:37 +0100, Peter Rosin wrote :
>> On 2016-10-20 15:35, Alexandre Belloni wrote
>>> On 16/10/2016 at 18:21:45 +0200, Sylvain Rochet wrote :
>>>> Remove pullup on dbgu DTXD signal, it is a push-pull output thus the
>>>> pullup is pointless.
>>>>
>>>> Add pullup on dbgu DRXD signal, it prevents the DRXD signal to be left
>>>> floating and so consuming a useless extra amount of power in crowbarred
>>>> state if nothing is externally connected to dbgu.
>>> Applied, thanks.
>>
>> I can't seem to find this patch in any of the repos I'm looking at,
>> so I'm wondering where it was applied and when it might hit mainline?
>>
>
> It is applied there:
> http://git.kernel.org/cgit/linux/kernel/git/abelloni/linux.git/log/?h=at91-dt
>
> It will land in 4.10. I'll do the PR to arm-soc soon.
Great, thanks! (expected it to be in -next by now and got worried, and
couldn't find it in https://github.com/linux4sam/linux-at91 either...)
Cheers,
Peter
^ permalink raw reply
* [PATCH] mfd: qcom-pm8xxx: Clean up PM8XXX namespace
From: Jacek Anaszewski @ 2016-11-10 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZe0VO=ABfbven8mU0FGb=sJNY_tjk2_GpAP30wsiDkvQ@mail.gmail.com>
On 11/09/2016 11:19 PM, Linus Walleij wrote:
> On Wed, Nov 9, 2016 at 4:47 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
>> How many more Acks do we need?
>
> Jacek and one of the ARM SoC people ideally...
>
> Jacek? Arnd/Olof?
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH] ARM: dts: at91: sama5d3_uart: fix reg sizes to match documentation
From: Peter Rosin @ 2016-11-10 7:46 UTC (permalink / raw)
To: linux-arm-kernel
The new size (0x100) also matches the size given in sama5d3.dtsi
Documentation reference: section 43.6 "Universal Asynchronous
Receiver Transmitter (UART) User Interface", table 43-4 "Register
Mapping" in [1].
[1] Atmel-11121F-ATARM-SAMA5D3-Series-Datasheet_02-Feb-16
Signed-off-by: Peter Rosin <peda@axentia.se>
---
arch/arm/boot/dts/sama5d3_uart.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sama5d3_uart.dtsi b/arch/arm/boot/dts/sama5d3_uart.dtsi
index 2511d748867b..186377d41c91 100644
--- a/arch/arm/boot/dts/sama5d3_uart.dtsi
+++ b/arch/arm/boot/dts/sama5d3_uart.dtsi
@@ -55,7 +55,7 @@
uart0: serial at f0024000 {
compatible = "atmel,at91sam9260-usart";
- reg = <0xf0024000 0x200>;
+ reg = <0xf0024000 0x100>;
interrupts = <16 IRQ_TYPE_LEVEL_HIGH 5>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart0>;
@@ -66,7 +66,7 @@
uart1: serial at f8028000 {
compatible = "atmel,at91sam9260-usart";
- reg = <0xf8028000 0x200>;
+ reg = <0xf8028000 0x100>;
interrupts = <17 IRQ_TYPE_LEVEL_HIGH 5>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1>;
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] mfd: pm8921: add support to pm8821
From: kbuild test robot @ 2016-11-10 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478622577-20699-1-git-send-email-srinivas.kandagatla@linaro.org>
Hi Srinivas,
[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.9-rc4 next-20161110]
[cannot apply to robh/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Srinivas-Kandagatla/mfd-pm8921-add-support-to-pm8821/20161109-013248
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: arm-pxa_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 error/warnings (new ones prefixed by >>):
drivers/mfd/pm8921-core.c: In function 'pm8921_probe':
>> drivers/mfd/pm8921-core.c:630:58: warning: dereferencing 'void *' pointer
data = of_match_node(pm8921_id_table, pdev->dev.of_node)->data;
^~
>> drivers/mfd/pm8921-core.c:630:58: error: request for member 'data' in something not a structure or union
vim +/data +630 drivers/mfd/pm8921-core.c
624 const struct pm8xxx_data *data;
625 int irq, rc;
626 unsigned int val;
627 u32 rev;
628 struct pm_irq_chip *chip;
629
> 630 data = of_match_node(pm8921_id_table, pdev->dev.of_node)->data;
631 if (!data) {
632 dev_err(&pdev->dev, "No matching driver data found\n");
633 return -EINVAL;
---
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: 30088 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161110/a54a422b/attachment-0001.gz>
^ permalink raw reply
* [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Benjamin Herrenschmidt @ 2016-11-10 7:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109111959.GB17020@leverpostej>
On Wed, 2016-11-09 at 11:20 +0000, Mark Rutland wrote:
> The big change would be to handle !MMIO translations, for which we'd
> need a runtime registry of ISA bus instance to find the relevant
> accessor ops and instance-specific data.
Yes. We do something a bit like that on ppc, we find the PCI bus
for which the IO ports match and I have a hook to register the
special indirect ISA.
It's a bit messy, we could do something nicer generically.
Cheers,
Ben.
^ permalink raw reply
* [PATCH v2 2/2] mm: hugetlb: support gigantic surplus pages
From: Huang Shijie @ 2016-11-10 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109165549.1cf320c5@thinkpad>
On Wed, Nov 09, 2016 at 04:55:49PM +0100, Gerald Schaefer wrote:
> > index 9fdfc24..5dbfd62 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -1095,6 +1095,9 @@ static struct page *alloc_gigantic_page(int nid, unsigned int order)
> > unsigned long ret, pfn, flags;
> > struct zone *z;
> >
> > + if (nid == NUMA_NO_NODE)
> > + nid = numa_mem_id();
> > +
>
> Now counter.sh works (on s390) w/o the lockdep warning. However, it looks
Good news to me :)
We have found the root cause of the s390 issue.
> like this change will now result in inconsistent behavior compared to the
> normal sized hugepages, regarding surplus page allocation. Setting nid to
> numa_mem_id() means that only the node of the current CPU will be considered
> for allocating a gigantic page, as opposed to just "preferring" the current
> node in the normal size case (__hugetlb_alloc_buddy_huge_page() ->
> alloc_pages_node()) with a fallback to using other nodes.
Yes.
>
> I am not really familiar with NUMA, and I might be wrong here, but if
> this is true then gigantic pages, which may be hard allocate at runtime
> in general, will be even harder to find (as surplus pages) because you
> only look on the current node.
Okay, I will try to fix this in the next version.
>
> I honestly do not understand why alloc_gigantic_page() needs a nid
> parameter at all, since it looks like it will only be called from
> alloc_fresh_gigantic_page_node(), which in turn is only called
> from alloc_fresh_gigantic_page() in a "for_each_node" loop (at least
> before your patch).
>
> Now it could be an option to also use alloc_fresh_gigantic_page()
> in your patch, instead of directly calling alloc_gigantic_page(),
Yes, a good suggestion. But I need to do some change to the
alloc_fresh_gigantic_page().
Thanks
Huang Shijie
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: zhichang.yuan @ 2016-11-10 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2825537.ADCNsGqGxn@wuerfel>
Hi, Arnd,
On 2016/11/10 5:34, Arnd Bergmann wrote:
> On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni wrote:
>>> On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
>>>> + /*
>>>> + * The first PCIBIOS_MIN_IO is reserved specifically for
>>> indirectIO.
>>>> + * It will separate indirectIO range from pci host bridge to
>>>> + * avoid the possible PIO conflict.
>>>> + * Set the indirectIO range directly here.
>>>> + */
>>>> + lpcdev->io_ops.start = 0;
>>>> + lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
>>>> + lpcdev->io_ops.devpara = lpcdev;
>>>> + lpcdev->io_ops.pfin = hisilpc_comm_in;
>>>> + lpcdev->io_ops.pfout = hisilpc_comm_out;
>>>> + lpcdev->io_ops.pfins = hisilpc_comm_ins;
>>>> + lpcdev->io_ops.pfouts = hisilpc_comm_outs;
>>>
>>> I have to look at patch 2 in more detail again, after missing a few
>>> review
>>> rounds. I'm still a bit skeptical about hardcoding a logical I/O port
>>> range here, and would hope that we can just go through the same
>>> assignment of logical port ranges that we have for PCI buses,
>>> decoupling
>>> the bus addresses from the linux-internal ones.
>>
>> The point here is that we want to avoid any conflict/overlap between
>> the LPC I/O space and the PCI I/O space. With the assignment above
>> we make sure that LPC never interfere with PCI I/O space.
>
> But we already abstract the PCI I/O space using dynamic registration.
> There is no need to hardcode the logical address for ISA, though
> I think we can hardcode the bus address to start at zero here.
Do you means that we can pick up the maximal I/O address from all children's
device resources??
Thanks,
Zhichang
>
> Arnd
>
> .
>
^ permalink raw reply
* [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: zhichang.yuan @ 2016-11-10 6:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109165044.GE10219@e106497-lin.cambridge.arm.com>
Hi,Liviu,
Thanks for your comments!
On 2016/11/10 0:50, liviu.dudau at arm.com wrote:
> On Wed, Nov 09, 2016 at 04:16:17PM +0000, Gabriele Paoloni wrote:
>> Hi Liviu
>>
>> Thanks for reviewing
>>
>
> [removed some irrelevant part of discussion, avoid crazy formatting]
>
>>>> +/**
>>>> + * addr_is_indirect_io - check whether the input taddr is for
>>> indirectIO.
>>>> + * @taddr: the io address to be checked.
>>>> + *
>>>> + * Returns 1 when taddr is in the range; otherwise return 0.
>>>> + */
>>>> +int addr_is_indirect_io(u64 taddr)
>>>> +{
>>>> + if (arm64_extio_ops->start > taddr || arm64_extio_ops->end <
>>> taddr)
>>>
>>> start >= taddr ?
>>
>> Nope... if (taddr < arm64_extio_ops->start || taddr > arm64_extio_ops->end)
>> then taddr is outside the range [start; end] and will return 0; otherwise
>> it will return 1...
>
> Oops, sorry, did not pay attention to the returned value. The check is
> correct as it is, no need to change then.
>
>>
>>>
>>>> + return 0;
>>>> +
>>>> + return 1;
>>>> +}
>>>>
>>>> BUILD_EXTIO(b, u8)
>>>>
>>>> diff --git a/drivers/of/address.c b/drivers/of/address.c
>>>> index 02b2903..cc2a05d 100644
>>>> --- a/drivers/of/address.c
>>>> +++ b/drivers/of/address.c
>>>> @@ -479,6 +479,50 @@ static int of_empty_ranges_quirk(struct
>>> device_node *np)
>>>> return false;
>>>> }
>>>>
>>>> +
>>>> +/*
>>>> + * of_isa_indirect_io - get the IO address from some isa reg
>>> property value.
>>>> + * For some isa/lpc devices, no ranges property in ancestor node.
>>>> + * The device addresses are described directly in their regs
>>> property.
>>>> + * This fixup function will be called to get the IO address of
>>> isa/lpc
>>>> + * devices when the normal of_translation failed.
>>>> + *
>>>> + * @parent: points to the parent dts node;
>>>> + * @bus: points to the of_bus which can be used to parse
>>> address;
>>>> + * @addr: the address from reg property;
>>>> + * @na: the address cell counter of @addr;
>>>> + * @presult: store the address paresed from @addr;
>>>> + *
>>>> + * return 1 when successfully get the I/O address;
>>>> + * 0 will return for some failures.
>>>
>>> Bah, you are returning a signed int, why 0 for failure? Return a
>>> negative value with
>>> error codes. Otherwise change the return value into a bool.
>>
>> Yes we'll move to bool
>>
>>>
>>>> + */
>>>> +static int of_get_isa_indirect_io(struct device_node *parent,
>>>> + struct of_bus *bus, __be32 *addr,
>>>> + int na, u64 *presult)
>>>> +{
>>>> + unsigned int flags;
>>>> + unsigned int rlen;
>>>> +
>>>> + /* whether support indirectIO */
>>>> + if (!indirect_io_enabled())
>>>> + return 0;
>>>> +
>>>> + if (!of_bus_isa_match(parent))
>>>> + return 0;
>>>> +
>>>> + flags = bus->get_flags(addr);
>>>> + if (!(flags & IORESOURCE_IO))
>>>> + return 0;
>>>> +
>>>> + /* there is ranges property, apply the normal translation
>>> directly. */
>>>
>>> s/there is ranges/if we have a 'ranges'/
>>
>> Thanks for spotting this
>>
>>>
>>>> + if (of_get_property(parent, "ranges", &rlen))
>>>> + return 0;
>>>> +
>>>> + *presult = of_read_number(addr + 1, na - 1);
>>>> + /* this fixup is only valid for specific I/O range. */
>>>> + return addr_is_indirect_io(*presult);
>>>> +}
>>>> +
>>>> static int of_translate_one(struct device_node *parent, struct
>>> of_bus *bus,
>>>> struct of_bus *pbus, __be32 *addr,
>>>> int na, int ns, int pna, const char *rprop)
>>>> @@ -595,6 +639,15 @@ static u64 __of_translate_address(struct
>>> device_node *dev,
>>>> result = of_read_number(addr, na);
>>>> break;
>>>> }
>>>> + /*
>>>> + * For indirectIO device which has no ranges property, get
>>>> + * the address from reg directly.
>>>> + */
>>>> + if (of_get_isa_indirect_io(dev, bus, addr, na, &result)) {
>>>> + pr_debug("isa indirectIO matched(%s)..addr =
>>> 0x%llx\n",
>>>> + of_node_full_name(dev), result);
>>>> + break;
>>>> + }
>>>>
>>>> /* Get new parent bus and counts */
>>>> pbus = of_match_bus(parent);
>>>> @@ -688,8 +741,9 @@ static int __of_address_to_resource(struct
>>> device_node *dev,
>>>> if (taddr == OF_BAD_ADDR)
>>>> return -EINVAL;
>>>> memset(r, 0, sizeof(struct resource));
>>>> - if (flags & IORESOURCE_IO) {
>>>> + if (flags & IORESOURCE_IO && taddr >= PCIBIOS_MIN_IO) {
>>>> unsigned long port;
>>>> +
>>>> port = pci_address_to_pio(taddr);
>>>> if (port == (unsigned long)-1)
>>>> return -EINVAL;
>>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>>> index ba34907..1a08511 100644
>>>> --- a/drivers/pci/pci.c
>>>> +++ b/drivers/pci/pci.c
>>>> @@ -3263,7 +3263,7 @@ int __weak pci_register_io_range(phys_addr_t
>>> addr, resource_size_t size)
>>>>
>>>> #ifdef PCI_IOBASE
>>>> struct io_range *range;
>>>> - resource_size_t allocated_size = 0;
>>>> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
>>>>
>>>> /* check if the range hasn't been previously recorded */
>>>> spin_lock(&io_range_lock);
>>>> @@ -3312,7 +3312,7 @@ phys_addr_t pci_pio_to_address(unsigned long
>>> pio)
>>>>
>>>> #ifdef PCI_IOBASE
>>>> struct io_range *range;
>>>> - resource_size_t allocated_size = 0;
>>>> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
>>>
>>> Have you checked that pci_pio_to_address still returns valid values
>>> after this? I know that
>>> you are trying to take into account PCIBIOS_MIN_IO limit when
>>> allocating reserving the IO ranges,
>>> but the values added in the io_range_list are still starting from zero,
>>> no from PCIBIOS_MIN_IO,
>>
>> I think you're wrong here as in pci_address_to_pio we have:
>> + resource_size_t offset = PCIBIOS_MIN_IO;
>>
>> This should be enough to guarantee that the PIOs start at
>> PCIBIOS_MIN_IO...right?
>
> I don't think you can guarantee that the pio value that gets passed into
> pci_pio_to_address() always comes from a previously returned value by
> pci_address_to_pio(). Maybe you can add a check in pci_pio_to_address()
>
> if (pio < PCIBIOS_MIN_IO)
> return address;
>
> to avoid adding more checks in the list_for_each_entry() loop.
>
I will register some ranges to the list and test it later.
But from my understanding, pci_pio_to_address() should can return the right
original physical address.
According to the algorithm, the output PIO ranges are consecutive? just like this:
input pio of pci_pio_to_address()
|
V
|----------------|--------------------------|------|-----------|
^
|
allocated_size is here
The change of this patch just make the start PIO from ZERO to PCIBIOS_MIN_IO.
in pci_pio_to_address(), for one input pio which fall into any PIO segment, the
return address will be:
address = range->start + pio - allocated_size;
Since allocated_size is the total range size of all IO ranges before the one
where pio belong, then (pio - allocated_size) is the offset to the range start,
So....
Thanks!
Zhichang
> Best regards,
> Liviu
>
>>
>>
>>> so the calculation of the address in this function could return
>>> negative values casted to pci_addr_t.
>>>
>>> Maybe you want to adjust the range->start value in
>>> pci_register_io_range() as well to have it
>>> offset by PCIBIOS_MIN_IO as well.
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>> if (pio > IO_SPACE_LIMIT)
>>>> return address;
>>>> @@ -3335,7 +3335,7 @@ unsigned long __weak
>>> pci_address_to_pio(phys_addr_t address)
>>>> {
>>>> #ifdef PCI_IOBASE
>>>> struct io_range *res;
>>>> - resource_size_t offset = 0;
>>>> + resource_size_t offset = PCIBIOS_MIN_IO;
>>>> unsigned long addr = -1;
>>>>
>>>> spin_lock(&io_range_lock);
>>>> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
>>>> index 3786473..deec469 100644
>>>> --- a/include/linux/of_address.h
>>>> +++ b/include/linux/of_address.h
>>>> @@ -24,6 +24,23 @@ struct of_pci_range {
>>>> #define for_each_of_pci_range(parser, range) \
>>>> for (; of_pci_range_parser_one(parser, range);)
>>>>
>>>> +
>>>> +#ifndef indirect_io_enabled
>>>> +#define indirect_io_enabled indirect_io_enabled
>>>> +static inline bool indirect_io_enabled(void)
>>>> +{
>>>> + return false;
>>>> +}
>>>> +#endif
>>>> +
>>>> +#ifndef addr_is_indirect_io
>>>> +#define addr_is_indirect_io addr_is_indirect_io
>>>> +static inline int addr_is_indirect_io(u64 taddr)
>>>> +{
>>>> + return 0;
>>>> +}
>>>> +#endif
>>>> +
>>>> /* Translate a DMA address from device space to CPU space */
>>>> extern u64 of_translate_dma_address(struct device_node *dev,
>>>> const __be32 *in_addr);
>>>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>>>> index 0e49f70..7f6bbb6 100644
>>>> --- a/include/linux/pci.h
>>>> +++ b/include/linux/pci.h
>>>> @@ -2130,4 +2130,12 @@ static inline bool pci_ari_enabled(struct
>>> pci_bus *bus)
>>>> /* provide the legacy pci_dma_* API */
>>>> #include <linux/pci-dma-compat.h>
>>>>
>>>> +/*
>>>> + * define this macro here to refrain from compilation error for some
>>>> + * platforms. Please keep this macro at the end of this header file.
>>>> + */
>>>> +#ifndef PCIBIOS_MIN_IO
>>>> +#define PCIBIOS_MIN_IO 0
>>>> +#endif
>>>> +
>>>> #endif /* LINUX_PCI_H */
>>>> --
>>>> 1.9.1
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-pci"
>>> in
>>>> the body of a message to majordomo at vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 1/10] clk: sunxi-ng: multiplier: Add fractionnal support
From: Chen-Yu Tsai @ 2016-11-10 6:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b3d3436c03e0597de205f674061892dbc9498a7e.1478625788.git-series.maxime.ripard@free-electrons.com>
On Wed, Nov 9, 2016 at 1:23 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Nit: Typo in the subject ("fractional"). Maybe mention what clock on what SoC
needs this in the commit message?
Otherwise,
Acked-by: Chen-Yu Tsai <wens@csie.org>
> ---
> drivers/clk/sunxi-ng/ccu_mult.c | 8 ++++++++
> drivers/clk/sunxi-ng/ccu_mult.h | 2 ++
> 2 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_mult.c b/drivers/clk/sunxi-ng/ccu_mult.c
> index 678b6cb49f01..826302464650 100644
> --- a/drivers/clk/sunxi-ng/ccu_mult.c
> +++ b/drivers/clk/sunxi-ng/ccu_mult.c
> @@ -75,6 +75,9 @@ static unsigned long ccu_mult_recalc_rate(struct clk_hw *hw,
> unsigned long val;
> u32 reg;
>
> + if (ccu_frac_helper_is_enabled(&cm->common, &cm->frac))
> + return ccu_frac_helper_read_rate(&cm->common, &cm->frac);
> +
> reg = readl(cm->common.base + cm->common.reg);
> val = reg >> cm->mult.shift;
> val &= (1 << cm->mult.width) - 1;
> @@ -102,6 +105,11 @@ static int ccu_mult_set_rate(struct clk_hw *hw, unsigned long rate,
> unsigned long flags;
> u32 reg;
>
> + if (ccu_frac_helper_has_rate(&cm->common, &cm->frac, rate))
> + return ccu_frac_helper_set_rate(&cm->common, &cm->frac, rate);
> + else
> + ccu_frac_helper_disable(&cm->common, &cm->frac);
> +
> ccu_mux_helper_adjust_parent_for_prediv(&cm->common, &cm->mux, -1,
> &parent_rate);
>
> diff --git a/drivers/clk/sunxi-ng/ccu_mult.h b/drivers/clk/sunxi-ng/ccu_mult.h
> index c1a2134bdc71..bd2e38b5a32a 100644
> --- a/drivers/clk/sunxi-ng/ccu_mult.h
> +++ b/drivers/clk/sunxi-ng/ccu_mult.h
> @@ -2,6 +2,7 @@
> #define _CCU_MULT_H_
>
> #include "ccu_common.h"
> +#include "ccu_frac.h"
> #include "ccu_mux.h"
>
> struct ccu_mult_internal {
> @@ -23,6 +24,7 @@ struct ccu_mult_internal {
> struct ccu_mult {
> u32 enable;
>
> + struct ccu_frac_internal frac;
> struct ccu_mult_internal mult;
> struct ccu_mux_internal mux;
> struct ccu_common common;
> --
> git-series 0.8.11
^ permalink raw reply
* [PATCH] ASoC: sun4i-codec: fix semicolon.cocci warnings
From: Chen-Yu Tsai @ 2016-11-10 6:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109163518.GA42508@lkp-nex06.lkp.intel.com>
On Thu, Nov 10, 2016 at 12:35 AM, kbuild test robot
<fengguang.wu@intel.com> wrote:
> sound/soc/sunxi/sun4i-codec.c:1339:2-3: Unneeded semicolon
>
>
> Remove unneeded semicolon.
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
> CC: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Sorry about the screw up.
> ---
>
> sun4i-codec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -1336,7 +1336,7 @@ static int sun4i_codec_probe(struct plat
> dev_err(&pdev->dev, "Failed to get reset control\n");
> return PTR_ERR(scodec->rst);
> }
> - };
> + }
>
> scodec->gpio_pa = devm_gpiod_get_optional(&pdev->dev, "allwinner,pa",
> GPIOD_OUT_LOW);
^ permalink raw reply
* [PATCH v4] regulator: lp873x: Add support for populating input supply
From: Lokesh Vutla @ 2016-11-10 5:29 UTC (permalink / raw)
To: linux-arm-kernel
In order to have a proper topology of regulators for a platform, each
registering regulator needs to populate supply_name field for identifying
its supply's name. Add supply_name field for lp873x regulators.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
Changes since v3:
- Applied Rob's ack.
- Sending this patch separately so that this can be merged via Regulator tree.
- Link to v3: https://patchwork.kernel.org/patch/9408545/
Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
drivers/regulator/lp873x-regulator.c | 1 +
2 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt b/Documentation/devicetree/bindings/mfd/lp873x.txt
index 52766c2..ae9cf39 100644
--- a/Documentation/devicetree/bindings/mfd/lp873x.txt
+++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
@@ -7,6 +7,9 @@ Required properties:
- #gpio-cells: Should be two. The first cell is the pin number and
the second cell is used to specify flags.
See ../gpio/gpio.txt for more information.
+ - xxx-in-supply: Phandle to parent supply node of each regulator
+ populated under regulators node. xxx can be
+ buck0, buck1, ldo0 or ldo1.
- regulators: List of child nodes that specify the regulator
initialization data.
Example:
@@ -17,6 +20,11 @@ pmic: lp8733 at 60 {
gpio-controller;
#gpio-cells = <2>;
+ buck0-in-supply = <&vsys_3v3>;
+ buck1-in-supply = <&vsys_3v3>;
+ ldo0-in-supply = <&vsys_3v3>;
+ ldo1-in-supply = <&vsys_3v3>;
+
regulators {
lp8733_buck0: buck0 {
regulator-name = "lp8733-buck0";
diff --git a/drivers/regulator/lp873x-regulator.c b/drivers/regulator/lp873x-regulator.c
index e504b91..70e3df6 100644
--- a/drivers/regulator/lp873x-regulator.c
+++ b/drivers/regulator/lp873x-regulator.c
@@ -24,6 +24,7 @@
[_id] = { \
.desc = { \
.name = _name, \
+ .supply_name = _of "-in", \
.id = _id, \
.of_match = of_match_ptr(_of), \
.regulators_node = of_match_ptr("regulators"),\
--
2.10.1
^ permalink raw reply related
* [PATCH v1] mtk-vcodec: add index check in decoder vidioc_qbuf.
From: Wu-Cheng Li @ 2016-11-10 5:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478755445-23494-1-git-send-email-wuchengli@chromium.org>
From: Wu-Cheng Li <wuchengli@google.com>
vb2_qbuf will check the buffer index. If a driver overrides
vidioc_qbuf and use the buffer index, the driver needs to check
the index.
Signed-off-by: Wu-Cheng Li <wuchengli@chromium.org>
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 0520919..0746592 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -533,6 +533,10 @@ static int vidioc_vdec_qbuf(struct file *file, void *priv,
}
vq = v4l2_m2m_get_vq(ctx->m2m_ctx, buf->type);
+ if (buf->index >= vq->num_buffers) {
+ mtk_v4l2_debug(1, "buffer index %d out of range", buf->index);
+ return -EINVAL;
+ }
vb = vq->bufs[buf->index];
vb2_v4l2 = container_of(vb, struct vb2_v4l2_buffer, vb2_buf);
mtkbuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, vb);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v1] mtk-vcodec: add index check in decoder vidioc_qbuf
From: Wu-Cheng Li @ 2016-11-10 5:24 UTC (permalink / raw)
To: linux-arm-kernel
From: Wu-Cheng Li <wuchengli@google.com>
This patch adds a buffer index check in decoder vidioc_qbuf.
Wu-Cheng Li (1):
mtk-vcodec: add index check in decoder vidioc_qbuf.
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 ++++
1 file changed, 4 insertions(+)
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply
* [v16, 0/7] Fix eSDHC host version register bug
From: Scott Wood @ 2016-11-10 5:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB6PR0401MB25369DEFDDDED2A96851259EF8B80@DB6PR0401MB2536.eurprd04.prod.outlook.com>
On Thu, 2016-11-10 at 04:11 +0000, Y.B. Lu wrote:
> >
> > -----Original Message-----
> > From: Y.B. Lu
> > Sent: Thursday, November 10, 2016 12:06 PM
> > To: 'Scott Wood'; Ulf Hansson
> > Cc: linux-mmc; Arnd Bergmann; linuxppc-dev at lists.ozlabs.org;
> > devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> > kernel at vger.kernel.org; linux-clk; iommu at lists.linux-foundation.org;
> > netdev at vger.kernel.org; Greg Kroah-Hartman; Mark Rutland; Rob Herring;
> > Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> > Sharma; Qiang Zhao; Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> > Subject: RE: [v16, 0/7] Fix eSDHC host version register bug
> >
> > >
> > > -----Original Message-----
> > > From: linux-mmc-owner at vger.kernel.org [mailto:linux-mmc-
> > > owner at vger.kernel.org] On Behalf Of Scott Wood
> > > Sent: Thursday, November 10, 2016 11:55 AM
> > > To: Ulf Hansson; Y.B. Lu
> > > Cc: linux-mmc; Arnd Bergmann; linuxppc-dev at lists.ozlabs.org;
> > > devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> > > linux- kernel at vger.kernel.org; linux-clk;
> > > iommu at lists.linux-foundation.org; netdev at vger.kernel.org; Greg
> > > Kroah-Hartman; Mark Rutland; Rob Herring; Russell King; Jochen
> > > Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh Sharma; Qiang Zhao;
> > > Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> > > Subject: Re: [v16, 0/7] Fix eSDHC host version register bug
> > >
> > > On Wed, 2016-11-09 at 19:27 +0100, Ulf Hansson wrote:
> > > >
> > > > - i2c-list
> > > >
> > > > On 9 November 2016 at 04:14, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> > > > >
> > > > >
> > > > > This patchset is used to fix a host version register bug in the
> > > > > T4240-
> > > > > R1.0-R2.0
> > > > > eSDHC controller. To match the SoC version and revision, 15
> > > > > previous version patchsets had tried many methods but all of them
> > > > > were rejected by reviewers.
> > > > > Such as
> > > > > ????????- dts compatible method
> > > > > ????????- syscon method
> > > > > ????????- ifdef PPC method
> > > > > ????????- GUTS driver getting SVR method Anrd suggested a
> > > > > soc_device_match method in v10, and this is the only available
> > > > > method left now. This v11 patchset introduces the soc_device_match
> > > > > interface in soc driver.
> > > > >
> > > > > The first four patches of Yangbo are to add the GUTS driver. This
> > > > > is used to register a soc device which contain soc version and
> > > > > revision information.
> > > > > The other three patches introduce the soc_device_match method in
> > > > > soc driver and apply it on esdhc driver to fix this bug.
> > > > >
> > > > > ---
> > > > > Changes for v15:
> > > > > ????????- Dropped patch 'dt: bindings: update Freescale DCFG
> > > compatible'
> > > >
> > > > >
> > > > > ??????????since the work had been done by below patch on
> > > > > ShawnGuo's linux tree.
> > > > > ??????????'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A
> > > > > compatible for SCFG
> > > > > ???????????and DCFG'
> > > > > ????????- Fixed error code issue in guts driver Changes for v16:
> > > > > ????????- Dropped patch 'powerpc/fsl: move mpc85xx.h to
> > > include/linux/fsl'
> > > >
> > > > >
> > > > > ????????- Added a bug-fix patch from Geert
> > > > > ---
> > > > >
> > > > > Arnd Bergmann (1):
> > > > > ? base: soc: introduce soc_device_match() interface
> > > > >
> > > > > Geert Uytterhoeven (1):
> > > > > ? base: soc: Check for NULL SoC device attributes
> > > > >
> > > > > Yangbo Lu (5):
> > > > > ? ARM64: dts: ls2080a: add device configuration node
> > > > > ? dt: bindings: move guts devicetree doc out of powerpc directory
> > > > > ? soc: fsl: add GUTS driver for QorIQ platforms
> > > > > ? MAINTAINERS: add entry for Freescale SoC drivers
> > > > > ? mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> > > > >
> > > > > ?.../bindings/{powerpc => soc}/fsl/guts.txt?????????|???3 +
> > > > > ?MAINTAINERS????????????????????????????????????????|??11 +-
> > > > > ?arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi?????|???6 +
> > > > > ?drivers/base/Kconfig???????????????????????????????|???1 +
> > > > > ?drivers/base/soc.c?????????????????????????????????|??70 ++++++
> > > > > ?drivers/mmc/host/Kconfig???????????????????????????|???1 +
> > > > > ?drivers/mmc/host/sdhci-of-esdhc.c??????????????????|??20 ++
> > > > > ?drivers/soc/Kconfig????????????????????????????????|???3 +-
> > > > > ?drivers/soc/fsl/Kconfig????????????????????????????|??18 ++
> > > > > ?drivers/soc/fsl/Makefile???????????????????????????|???1 +
> > > > > ?drivers/soc/fsl/guts.c?????????????????????????????| 236
> > > > > +++++++++++++++++++++
> > > > > ?include/linux/fsl/guts.h???????????????????????????| 125
> > > > > ++++++-----
> > > > > ?include/linux/sys_soc.h????????????????????????????|???3 +
> > > > > ?13 files changed, 447 insertions(+), 51 deletions(-)
> > > > > ?rename Documentation/devicetree/bindings/{powerpc =>
> > > > > soc}/fsl/guts.txt
> > > > > (91%)
> > > > > ?create mode 100644 drivers/soc/fsl/Kconfig
> > > > > ?create mode 100644 drivers/soc/fsl/guts.c
> > > > >
> > > > > --
> > > > > 2.1.0.27.g96db324
> > > > >
> > > > Thanks, applied on my mmc tree for next!
> > > >
> > > > I noticed that some DT compatibles weren't documented, according to
> > > > checkpatch. Please fix that asap!
> > > They are documented, in fsl/guts.txt (the file moved in patch 2/7):
> > > >
> > > > ?- compatible : Should define the compatible device type for
> > > > ???global-utilities.
> > > > ???Possible compatibles:
> > > > ????????"fsl,qoriq-device-config-1.0"
> > > > ????????"fsl,qoriq-device-config-2.0"
> > > > ????????"fsl,<chip>-device-config"
> > > > ????????"fsl,<chip>-guts"
> > > Checkpatch doesn't understand compatibles defined in such a way.
> > [Lu Yangbo-B47093] You're right, Scott. I dropped DT patch 'dt: bindings:
> > update Freescale DCFG compatible '
> > which fixed un-doc issue since Shaohui had done this on Shawn Guo's tree.
> > https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h
> > =imx/dt64&id=981034a2bfcaff5c95dafde24d7abfe7f9025c19
> >
> > Thanks.
> [Lu Yangbo-B47093] Both 'fsl,<chip>-guts' and 'fsl,<chip>-dcfg' would have
> no un-doc issue after Shaohui's patch are pulled :)
I don't follow. ?The link above points to a patch that addresses -dcfg and
-scfg, not -device-config or -guts -- and it also doesn't do it in a manner
that checkpatch will understand.
In any case, I wouldn't call this an "un-doc issue" -- it is documented -- but
rather a checkpatch-friendliness issue.
-Scott
^ permalink raw reply
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: Vignesh R @ 2016-11-10 5:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <D0AA78D0-9562-4E4D-A949-A771289D7570@gmail.com>
Hi,
On Thursday 10 November 2016 05:23 AM, John Syne wrote:
> OK, then back to my original question. Given that these DT properties are supported in the driver
>
Below properties are supported by only by ti_am3335x_adc driver and not
ti_am335x_tsc driver. As author of this patch pointed out in another
reply, there is no need to change step-opendelay for tsc. AFAIK, I don't
see a use case where these values needs to be tweaked for tsc channels,
therefore it does not make sense to be DT properties.
> shouldn?t the following be added to am33xx.dtsi and am4372.dtsi?
Its totally upto board dts files to allocate channels for tsc and adc.
So, how could these be added to dtsi files?
> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
>
> Regards,
> John
>>
>> --
>> Regards
>> Vignesh
>
--
Regards
Vignesh
^ permalink raw reply
* [PATCH fpga 2/9] fpga zynq: Check the bitstream for validity
From: Jason Gunthorpe @ 2016-11-10 4:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <17912798-e55d-253f-42fc-c7287d067e00@gmail.com>
On Wed, Nov 09, 2016 at 04:04:07PM -0800, Joshua Clayton wrote:
> > + if (!zynq_fpga_has_sync(buf, count)) {
> > + dev_err(priv->dev,
> > + "Invalid bitstream, could not find a sync word. Bitstream must be a byte swaped .bin file\n");
> Nitpick: byte swaped is a misspelling...
oops, sure.
> and I'm not sure I like the second half of this message. Maybe
> something like "Bitstream must be lsb first" (if that is what is
> meant).
I intended it to be a recipe to follow, not a specification. It
literally means take the .bin file and dword byte swap it to make it
work with the driver.
Describing it as LSB first would be consistent with UG470, but I doubt
many people know Xilinx tools emit the bitstream in 32 bit MSB format
and probably even fewer people know that the relavent difference
between .bit and .bin boils down to the alignment of the sync word -
which is why I prefered the recipe style..
Jason
^ permalink raw reply
* [PATCH v3 0/3] modversions: Fix CRC mangling under CONFIG_RELOCATABLE=y
From: Michael Ellerman @ 2016-11-10 4:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8Yc9rUacE70mvZSR92g1OY6LYyN6zrd--omwZVqwg3TA@mail.gmail.com>
Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
> On 27 October 2016 at 17:27, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> This series is a followup to the single patch 'modversions: treat symbol
>> CRCs as 32 bit quantities on 64 bit archs', of which two versions have
>> been sent out so far [0][1]
>>
>> As pointed out by Michael, GNU ld behaves a bit differently between arm64
>> and PowerPC64, and where the former gets rid of all runtime relocations
>> related to CRCs, the latter is not as easily convinced.
>>
>> Patch #1 fixes the issue where CRCs are corrupted by the runtime relocation
>> routines for 32-bit PowerPC, for which the original fix was effectively
>> reverted by commit 0e0ed6406e61 ("powerpc/modules: Module CRC relocation fix
>> causes perf issues")
>>
>> Patch #2 adds handling of R_PPC64_ADDR32 relocations against the NULL .dynsym
>> symbol entry to the PPC64 runtime relocation routines, so it is prepared to
>> deal with CRCs being emitted as 32-bit quantities.
>>
>> Patch #3 is the original patch from the v1 and v2 submissions.
>>
>> Changes since v2:
>> - added #1 and #2
>> - updated #3 to deal with CRC entries being emitted from assembler
>> - added Rusty's ack (#3)
>>
>> Branch can be found here:
>> https://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git/log/?h=kcrctab-reloc
>>
>> [0] http://marc.info/?l=linux-kernel&m=147652300207369&w=2
>> [1] http://marc.info/?l=linux-kernel&m=147695629614409&w=2
>
> Ping?
Sorry, you didn't cc linuxppc-dev, so it's not in my patchwork list
which tends to mean I miss it.
Will try and test and get back to you.
cheers
^ permalink raw reply
* [v16, 0/7] Fix eSDHC host version register bug
From: Y.B. Lu @ 2016-11-10 4:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478750114.21746.4.camel@buserror.net>
> -----Original Message-----
> From: Y.B. Lu
> Sent: Thursday, November 10, 2016 12:06 PM
> To: 'Scott Wood'; Ulf Hansson
> Cc: linux-mmc; Arnd Bergmann; linuxppc-dev at lists.ozlabs.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; linux-clk; iommu at lists.linux-foundation.org;
> netdev at vger.kernel.org; Greg Kroah-Hartman; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> Subject: RE: [v16, 0/7] Fix eSDHC host version register bug
>
> > -----Original Message-----
> > From: linux-mmc-owner at vger.kernel.org [mailto:linux-mmc-
> > owner at vger.kernel.org] On Behalf Of Scott Wood
> > Sent: Thursday, November 10, 2016 11:55 AM
> > To: Ulf Hansson; Y.B. Lu
> > Cc: linux-mmc; Arnd Bergmann; linuxppc-dev at lists.ozlabs.org;
> > devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> > linux- kernel at vger.kernel.org; linux-clk;
> > iommu at lists.linux-foundation.org; netdev at vger.kernel.org; Greg
> > Kroah-Hartman; Mark Rutland; Rob Herring; Russell King; Jochen
> > Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh Sharma; Qiang Zhao;
> > Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> > Subject: Re: [v16, 0/7] Fix eSDHC host version register bug
> >
> > On Wed, 2016-11-09 at 19:27 +0100, Ulf Hansson wrote:
> > > - i2c-list
> > >
> > > On 9 November 2016 at 04:14, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> > > >
> > > > This patchset is used to fix a host version register bug in the
> > > > T4240-
> > > > R1.0-R2.0
> > > > eSDHC controller. To match the SoC version and revision, 15
> > > > previous version patchsets had tried many methods but all of them
> > > > were rejected by reviewers.
> > > > Such as
> > > > ????????- dts compatible method
> > > > ????????- syscon method
> > > > ????????- ifdef PPC method
> > > > ????????- GUTS driver getting SVR method Anrd suggested a
> > > > soc_device_match method in v10, and this is the only available
> > > > method left now. This v11 patchset introduces the soc_device_match
> > > > interface in soc driver.
> > > >
> > > > The first four patches of Yangbo are to add the GUTS driver. This
> > > > is used to register a soc device which contain soc version and
> > > > revision information.
> > > > The other three patches introduce the soc_device_match method in
> > > > soc driver and apply it on esdhc driver to fix this bug.
> > > >
> > > > ---
> > > > Changes for v15:
> > > > ????????- Dropped patch 'dt: bindings: update Freescale DCFG
> > compatible'
> > > > ??????????since the work had been done by below patch on
> > > > ShawnGuo's linux tree.
> > > > ??????????'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A
> > > > compatible for SCFG
> > > > ???????????and DCFG'
> > > > ????????- Fixed error code issue in guts driver Changes for v16:
> > > > ????????- Dropped patch 'powerpc/fsl: move mpc85xx.h to
> > include/linux/fsl'
> > > > ????????- Added a bug-fix patch from Geert
> > > > ---
> > > >
> > > > Arnd Bergmann (1):
> > > > ? base: soc: introduce soc_device_match() interface
> > > >
> > > > Geert Uytterhoeven (1):
> > > > ? base: soc: Check for NULL SoC device attributes
> > > >
> > > > Yangbo Lu (5):
> > > > ? ARM64: dts: ls2080a: add device configuration node
> > > > ? dt: bindings: move guts devicetree doc out of powerpc directory
> > > > ? soc: fsl: add GUTS driver for QorIQ platforms
> > > > ? MAINTAINERS: add entry for Freescale SoC drivers
> > > > ? mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> > > >
> > > > ?.../bindings/{powerpc => soc}/fsl/guts.txt?????????|???3 +
> > > > ?MAINTAINERS????????????????????????????????????????|??11 +-
> > > > ?arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi?????|???6 +
> > > > ?drivers/base/Kconfig???????????????????????????????|???1 +
> > > > ?drivers/base/soc.c?????????????????????????????????|??70 ++++++
> > > > ?drivers/mmc/host/Kconfig???????????????????????????|???1 +
> > > > ?drivers/mmc/host/sdhci-of-esdhc.c??????????????????|??20 ++
> > > > ?drivers/soc/Kconfig????????????????????????????????|???3 +-
> > > > ?drivers/soc/fsl/Kconfig????????????????????????????|??18 ++
> > > > ?drivers/soc/fsl/Makefile???????????????????????????|???1 +
> > > > ?drivers/soc/fsl/guts.c?????????????????????????????| 236
> > > > +++++++++++++++++++++
> > > > ?include/linux/fsl/guts.h???????????????????????????| 125
> > > > ++++++-----
> > > > ?include/linux/sys_soc.h????????????????????????????|???3 +
> > > > ?13 files changed, 447 insertions(+), 51 deletions(-)
> > > > ?rename Documentation/devicetree/bindings/{powerpc =>
> > > > soc}/fsl/guts.txt
> > > > (91%)
> > > > ?create mode 100644 drivers/soc/fsl/Kconfig
> > > > ?create mode 100644 drivers/soc/fsl/guts.c
> > > >
> > > > --
> > > > 2.1.0.27.g96db324
> > > >
> > > Thanks, applied on my mmc tree for next!
> > >
> > > I noticed that some DT compatibles weren't documented, according to
> > > checkpatch. Please fix that asap!
> >
> > They are documented, in fsl/guts.txt (the file moved in patch 2/7):
> > > ?- compatible : Should define the compatible device type for
> > > ???global-utilities.
> > > ???Possible compatibles:
> > > ????????"fsl,qoriq-device-config-1.0"
> > > ????????"fsl,qoriq-device-config-2.0"
> > > ????????"fsl,<chip>-device-config"
> > > ????????"fsl,<chip>-guts"
> >
> > Checkpatch doesn't understand compatibles defined in such a way.
>
> [Lu Yangbo-B47093] You're right, Scott. I dropped DT patch 'dt: bindings:
> update Freescale DCFG compatible '
> which fixed un-doc issue since Shaohui had done this on Shawn Guo's tree.
> https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h
> =imx/dt64&id=981034a2bfcaff5c95dafde24d7abfe7f9025c19
>
> Thanks.
[Lu Yangbo-B47093] Both 'fsl,<chip>-guts' and 'fsl,<chip>-dcfg' would have no un-doc issue after Shaohui's patch are pulled :)
>
> >
> > -Scott
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-mmc"
> > in the body of a message to majordomo at vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [v16, 0/7] Fix eSDHC host version register bug
From: Y.B. Lu @ 2016-11-10 4:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478750114.21746.4.camel@buserror.net>
> -----Original Message-----
> From: linux-mmc-owner at vger.kernel.org [mailto:linux-mmc-
> owner at vger.kernel.org] On Behalf Of Scott Wood
> Sent: Thursday, November 10, 2016 11:55 AM
> To: Ulf Hansson; Y.B. Lu
> Cc: linux-mmc; Arnd Bergmann; linuxppc-dev at lists.ozlabs.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; linux-clk; iommu at lists.linux-foundation.org;
> netdev at vger.kernel.org; Greg Kroah-Hartman; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Leo Li; X.B. Xie; M.H. Lian
> Subject: Re: [v16, 0/7] Fix eSDHC host version register bug
>
> On Wed, 2016-11-09 at 19:27 +0100, Ulf Hansson wrote:
> > - i2c-list
> >
> > On 9 November 2016 at 04:14, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> > >
> > > This patchset is used to fix a host version register bug in the
> > > T4240-
> > > R1.0-R2.0
> > > eSDHC controller. To match the SoC version and revision, 15 previous
> > > version patchsets had tried many methods but all of them were
> > > rejected by reviewers.
> > > Such as
> > > ????????- dts compatible method
> > > ????????- syscon method
> > > ????????- ifdef PPC method
> > > ????????- GUTS driver getting SVR method Anrd suggested a
> > > soc_device_match method in v10, and this is the only available
> > > method left now. This v11 patchset introduces the soc_device_match
> > > interface in soc driver.
> > >
> > > The first four patches of Yangbo are to add the GUTS driver. This is
> > > used to register a soc device which contain soc version and revision
> > > information.
> > > The other three patches introduce the soc_device_match method in soc
> > > driver and apply it on esdhc driver to fix this bug.
> > >
> > > ---
> > > Changes for v15:
> > > ????????- Dropped patch 'dt: bindings: update Freescale DCFG
> compatible'
> > > ??????????since the work had been done by below patch on ShawnGuo's
> > > linux tree.
> > > ??????????'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A compatible
> > > for SCFG
> > > ???????????and DCFG'
> > > ????????- Fixed error code issue in guts driver Changes for v16:
> > > ????????- Dropped patch 'powerpc/fsl: move mpc85xx.h to
> include/linux/fsl'
> > > ????????- Added a bug-fix patch from Geert
> > > ---
> > >
> > > Arnd Bergmann (1):
> > > ? base: soc: introduce soc_device_match() interface
> > >
> > > Geert Uytterhoeven (1):
> > > ? base: soc: Check for NULL SoC device attributes
> > >
> > > Yangbo Lu (5):
> > > ? ARM64: dts: ls2080a: add device configuration node
> > > ? dt: bindings: move guts devicetree doc out of powerpc directory
> > > ? soc: fsl: add GUTS driver for QorIQ platforms
> > > ? MAINTAINERS: add entry for Freescale SoC drivers
> > > ? mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> > >
> > > ?.../bindings/{powerpc => soc}/fsl/guts.txt?????????|???3 +
> > > ?MAINTAINERS????????????????????????????????????????|??11 +-
> > > ?arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi?????|???6 +
> > > ?drivers/base/Kconfig???????????????????????????????|???1 +
> > > ?drivers/base/soc.c?????????????????????????????????|??70 ++++++
> > > ?drivers/mmc/host/Kconfig???????????????????????????|???1 +
> > > ?drivers/mmc/host/sdhci-of-esdhc.c??????????????????|??20 ++
> > > ?drivers/soc/Kconfig????????????????????????????????|???3 +-
> > > ?drivers/soc/fsl/Kconfig????????????????????????????|??18 ++
> > > ?drivers/soc/fsl/Makefile???????????????????????????|???1 +
> > > ?drivers/soc/fsl/guts.c?????????????????????????????| 236
> > > +++++++++++++++++++++
> > > ?include/linux/fsl/guts.h???????????????????????????| 125
> > > ++++++-----
> > > ?include/linux/sys_soc.h????????????????????????????|???3 +
> > > ?13 files changed, 447 insertions(+), 51 deletions(-)
> > > ?rename Documentation/devicetree/bindings/{powerpc =>
> > > soc}/fsl/guts.txt
> > > (91%)
> > > ?create mode 100644 drivers/soc/fsl/Kconfig
> > > ?create mode 100644 drivers/soc/fsl/guts.c
> > >
> > > --
> > > 2.1.0.27.g96db324
> > >
> > Thanks, applied on my mmc tree for next!
> >
> > I noticed that some DT compatibles weren't documented, according to
> > checkpatch. Please fix that asap!
>
> They are documented, in fsl/guts.txt (the file moved in patch 2/7):
> > ?- compatible : Should define the compatible device type for
> > ???global-utilities.
> > ???Possible compatibles:
> > ????????"fsl,qoriq-device-config-1.0"
> > ????????"fsl,qoriq-device-config-2.0"
> > ????????"fsl,<chip>-device-config"
> > ????????"fsl,<chip>-guts"
>
> Checkpatch doesn't understand compatibles defined in such a way.
[Lu Yangbo-B47093] You're right, Scott. I dropped DT patch 'dt: bindings: update Freescale DCFG compatible '
which fixed un-doc issue since Shaohui had done this on Shawn Guo's tree.
https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h=imx/dt64&id=981034a2bfcaff5c95dafde24d7abfe7f9025c19
Thanks.
>
> -Scott
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox