- 08 Jan, 2020 1 commit
-
-
YueHaibing authored
drivers/soc/fsl/qe/gpio.c: In function qe_pin_request: drivers/soc/fsl/qe/gpio.c:163:26: warning: variable mm_gc set but not used [-Wunused-but-set-variable] commit 1e714e54 ("powerpc: qe_lib-gpio: use gpiochip data pointer") left behind this unused variable. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Chen Zhou <chenzhou10@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Li Yang <leoyang.li@nxp.com>
-
- 09 Dec, 2019 39 commits
-
-
Rasmus Villemoes authored
There are also PPC64, ARM and ARM64 based SOCs with a QUICC Engine, and the core QE code as well as net/wan/fsl_ucc_hdlc and tty/serial/ucc_uart has now been modified to not rely on ppcisms. So extend the architectures that can select QUICC_ENGINE, and add the rather modest requirements of OF && HAS_IOMEM. The core code as well as the ucc_uart driver has been tested on an LS1021A (arm), and it has also been tested that the QE code still works on an mpc8309 (ppc). Qiang Zhao has tested that the QE-HDLC code that gets enabled with this works on ARM64. Reviewed-by:
Timur Tabi <timur@kernel.org> Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
-
Rasmus Villemoes authored
When allowing this driver to be built for ARM, the build fails (for CONFIG_SMP=y) since ARM's asm/irq.h header is not self-contained: In file included from drivers/soc/fsl/qe/ucc.c:18:0: >> arch/arm/include/asm/irq.h:34:50: error: unknown type name 'cpumask_t' extern void arch_trigger_cpumask_backtrace(const cpumask_t *mask, But nothing in this file actually uses anything from asm/irq.h - removing this #include generates identical object code, both on PPC32 and on ARM (the latter with a patch added to asm/irq.h to make the build work in the first place). Reported-by:kbuild test robot <lkp@intel.com> Signed-off-by:
-
Rasmus Villemoes authored
Currently, QUICC_ENGINE depends on PPC32, so this in itself does not change anything. In order to allow removing the PPC32 dependency from QUICC_ENGINE and avoid allmodconfig build failures, add this explicit dependency. Also, the QE Ethernet has never been integrated on any non-PowerPC SoC and most likely will not be in the future. Reviewed-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Rasmus Villemoes authored
Qiang Zhao points out that these offsets get written to 16-bit registers, and there are some QE platforms with more than 64K muram. So it is possible that qe_muram_alloc() gives us an allocation that can't actually be used by the hardware, so detect and reject that. Reported-by:
Qiang Zhao <qiang.zhao@nxp.com> Reviewed-by:
-
Rasmus Villemoes authored
When releasing the allocated muram resource, we rely on reading back the offsets from the riptr/tiptr registers. But those registers are __be16 (and we indeed write them using iowrite16be), so we can't just read them back with a normal C dereference. This is not currently a real problem, since for now the driver is PPC32-only. But it will soon be allowed to be used on arm and arm64 as well. Reviewed-by:
-
Rasmus Villemoes authored
When building this on a 64-bit platform gcc rightly warns that the error checking is broken (-ENOMEM stored in an u32 does not compare greater than (unsigned long)-MAX_ERRNO). Instead, now that qe_muram_alloc() returns s32, use that type to store the return value and use standard kernel style "ret < 0". Reviewed-by:
-
Rasmus Villemoes authored
When building this on a 64-bit platform gcc rightly warns that the error checking is broken (-ENOMEM stored in an u32 does not compare greater than (unsigned long)-MAX_ERRNO). Instead, change the ucc_fast_[tr]x_virtual_fifo_base_offset members to s32 and use an ordinary check-for-negative. Also, this avoids treating 0 as "this cannot have been returned from qe_muram_alloc() so don't free it". Reviewed-by:
-
Rasmus Villemoes authored
The sdma member of struct qe_immap is not at offset zero, so even if qe_immr wasn't initialized yet (i.e. NULL), &qe_immr->sdma would not be NULL. Reviewed-by:
-
Rasmus Villemoes authored
Now that qe_muram_alloc() returns s32, adapt qe_sdma_init() and avoid another few IS_ERR_VALUE() uses. Reviewed-by:
-
Rasmus Villemoes authored
When trying to build this for a 64-bit platform, one gets warnings from using IS_ERR_VALUE on something which is not sizeof(long). Instead, change the various *_offset fields to store a signed integer, and simply check for a negative return from qe_muram_alloc(). Since qe_muram_free() now accepts and ignores a negative argument, we only need to make sure these fields are initialized with -1, and we can just unconditionally call qe_muram_free() in ucc_slow_free(). Note that the error case for us_pram_offset failed to set that field to 0 (which, as noted earlier, is anyway a bogus sentinel value). Reviewed-by:
-
Rasmus Villemoes authored
If the kmalloc() fails, we try to undo the gen_pool allocation we've just done. Unfortunately, start has already been modified to subtract the GENPOOL_OFFSET bias, so we're freeing something that very likely doesn't exist in the gen_pool, meaning we hit the kernel BUG at lib/genalloc.c:399! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM ... [<803fd0e8>] (gen_pool_free) from [<80426bc8>] (cpm_muram_alloc_common+0xb0/0xc8) [<80426bc8>] (cpm_muram_alloc_common) from [<80426c28>] (cpm_muram_alloc+0x48/0x80) [<80426c28>] (cpm_muram_alloc) from [<80428214>] (ucc_slow_init+0x110/0x4f0) [<80428214>] (ucc_slow_init) from [<8044a718>] (qe_uart_request_port+0x3c/0x1d8) (this was tested by just injecting a random failure by adding "|| (get_random_int()&7) == 0" to the "if (!entry)" condition). Refactor the code so we do the kmalloc() first, meaning that's the thing that needs undoing in case gen_pool_alloc_algo() then fails. This allows a later cleanup to move the locking from the callers into the _common function, keeping the kmalloc() out of the critical region and then, hopefully (if all the muram_alloc callers allow) change it to a GFP_KERNEL allocation. Reviewed-by:
-
Rasmus Villemoes authored
cpm_muram_alloc_common() tries to support a kind of lazy initialization - if the muram_pool has not been created yet, it calls cpm_muram_init(). Now, cpm_muram_alloc_common() is always called under spin_lock_irqsave(&cpm_muram_lock, flags); and cpm_muram_init() does gen_pool_create() (which implies a GFP_KERNEL allocation) and ioremap(), not to mention the fun that ensues from cpm_muram_init() doing spin_lock_init(&cpm_muram_lock); In other words, this has never worked, so nobody can have been relying on it. cpm_muram_init() is called from a subsys_initcall (either from cpm_init() in arch/powerpc/sysdev/cpm_common.c or, via qe_reset(), from qe_init() in drivers/soc/fsl/qe/qe.c). Reviewed-by:
-
Rasmus Villemoes authored
This allows one to simplify callers since they can store a negative value as a sentinel to indicate "this was never allocated" (or store the -ENOMEM from an allocation failure) and then call cpm_muram_free() unconditionally. Reviewed-by:
-
Rasmus Villemoes authored
Nobody uses the return value from cpm_muram_free, and functions that free resources usually return void. One could imagine a use for a "how much have I allocated" a la ksize(), but knowing how much one had access to after the fact is useless. Reviewed-by:
-
Rasmus Villemoes authored
There are a number of problems with cpm_muram_alloc() and its callers. Most callers assign the return value to some variable and then use IS_ERR_VALUE to check for allocation failure. However, when that variable is not sizeof(long), this leads to warnings - and it is indeed broken to do e.g. u32 foo = cpm_muram_alloc(); if (IS_ERR_VALUE(foo)) on a 64-bit platform, since the condition foo >= (unsigned long)-ENOMEM is tautologically false. There are also callers that ignore the possibility of error, and then there are those that check for error by comparing the return value to 0... One could fix that by changing all callers to store the return value temporarily in an "unsigned long" and test that. However, use of IS_ERR_VALUE() is error-prone and should be restricted to things which are inherently long-sized (stuff in pt_regs etc.). Instead, let's aim for changing to the standard kernel style int foo = cpm_muram_alloc(); if (foo < 0) deal_with_it() some->where = foo; Changing the return type from unsigned long to s32 (aka signed int) doesn't change the value that gets stored into any of the callers' variables except if the caller was storing the result in a u64 _and_ the allocation failed, so in itself this patch should be a no-op. Another problem with cpm_muram_alloc() is that it can certainly validly return 0 - and except if some cpm_muram_alloc_fixed() call interferes, the very first cpm_muram_alloc() call will return just that. But that shows that both ucc_slow_free() and ucc_fast_free() are buggy, since they assume that a value of 0 means "that field was never allocated". We'll later change cpm_muram_free() to accept (and ignore) a negative offset, so callers can use a sentinel of -1 instead of 0 and just unconditionally call cpm_muram_free(). Reviewed-by: -
Rasmus Villemoes authored
The buf member of struct qe_bd is a __be32, so to make this work on little-endian hosts, use be32_to_cpu when reading it. Reviewed-by:
-
Rasmus Villemoes authored
According to Timur Tabi This bug in older U-Boots is definitely PowerPC-specific So before allowing this driver to be built for platforms other than PPC32, make sure that we don't accept malformed device trees on those other platforms. Suggested-by: -
Rasmus Villemoes authored
For this to work correctly on little-endian hosts, don't access the device-tree properties directly in native endianness, but use the of_property_read_u32() helper. Reviewed-by:
-
Rasmus Villemoes authored
The Soft UART hack is only needed for some PPC-based SOCs. To allow building this driver for non-PPC, guard soft_uart_init() and its helpers by CONFIG_PPC32, and use a no-op soft_uart_init() otherwise. Reviewed-by:
-
Rasmus Villemoes authored
The "soft uart" mechanism is a workaround for a silicon bug which (as far as I know) only affects some PPC-based SOCs. The code that determines which microcode blob to request relies on some powerpc-specific bits (e.g. the mfspr(SPRN_SVR) and hence also the asm/reg.h header). This makes it a little awkward to allow this driver to be built for non-PPC based SOCs with a QE, even if they are not affected by that silicon bug and thus don't need any of the Soft UART logic. There's no way around guarding those bits with some ifdeffery, so to keep that isolated, factor out the do-we-need-soft-uart-and-if-so-handle-the-firmware to a separate function, which we can then easily stub out for non-PPC. Reviewed-by:
-
Rasmus Villemoes authored
Some ARM-based SOCs (e.g. LS1021A) also have a QUICC engine. As preparation for allowing this driver to build on ARM, replace the ppc-specific in_be16() etc. by the qe_io* helpers. Done via coccinelle. Reviewed-by:
-
Rasmus Villemoes authored
This driver uses #defines from soc/fsl/cpm.h, so instead of relying on some other header pulling that in, do that explicitly. This is preparation for allowing this driver to build on ARM. Reviewed-by:
-
Rasmus Villemoes authored
asm/cpm.h under arch/powerpc is now just a wrapper for including soc/fsl/cpm.h. In order to make the qe.h header usable on other architectures, use the latter path directly. Reviewed-by:
-
Rasmus Villemoes authored
Some drivers, e.g. ucc_uart, need definitions from cpm.h. In order to allow building those drivers for non-ppc based SOCs, move the header to include/soc/fsl. For now, leave a trivial wrapper at the old location so drivers can be updated one by one. Reviewed-by:
-
Rasmus Villemoes authored
This is necessary for this to work on little-endian hosts. Reviewed-by:
-
Rasmus Villemoes authored
We need to apply be32_to_cpu to make this work correctly on little-endian hosts. Reviewed-by:
-
Rasmus Villemoes authored
Reviewed-by:
-
Rasmus Villemoes authored
Instead of manually doing of_get_property/of_find_property and reading the value by assigning to a u32* or u64* and dereferencing, use the of_property_read_* functions. This make the code more readable, and more importantly, is required for this to work correctly on little-endian platforms. Reviewed-by:
-
Rasmus Villemoes authored
The public qe_ic.h header is no longer included by anything but qe_ic.c. Merge both headers into qe_ic.c, and drop the unused constants. Reviewed-by:
-
Rasmus Villemoes authored
qe_ic_init() takes a flags parameter, but all callers (including the sole remaining one) have always passed 0. So remove that parameter and simplify the body accordingly. We still explicitly initialize the Interrupt Configuration Register (CICR) to its reset value of all-zeroes, just in case the bootloader has played funny games. Reviewed-by:
-
Rasmus Villemoes authored
These are only called from within qe_ic.c, so make them static. Reviewed-by:
-
Rasmus Villemoes authored
This driver is currently PPC-only, and on powerpc, NO_IRQ is 0, so this doesn't change functionality. However, not every architecture defines NO_IRQ, and some define it as -1, so the detection of a failed irq_of_parse_and_map() (which returns 0 on failure) would be wrong on those. So to prepare for allowing this driver to build on other architectures, drop all references to NO_IRQ. Reviewed-by:
-
Rasmus Villemoes authored
There are no current callers of these functions, and they use the ppc-specific virq_to_hw(). So removing them gets us one step closer to building QE support for ARM. If the functionality is ever actually needed, the code can be dug out of git and then adapted to work on all architectures, but for future reference please note that I believe qe_ic_set_priority is buggy: The "priority < 4" should be "priority <= 4", and in the else branch 24 should be replaced by 28, at least if I'm reading the data sheet right. Reviewed-by:
-
Rasmus Villemoes authored
The qe_ic_cascade_{low,high}_mpic functions are now used as handlers both when the interrupt parent is mpic as well as ipic, so remove the _mpic suffix. Reviewed-by: -
Rasmus Villemoes authored
These functions are only ever called through a function pointer, and therefore it makes no sense for them to be "static inline" - gcc has no choice but to emit a copy in each translation unit that takes the address of one of these. Since they are now only referenced from qe_ic.c, just make them local to that file. Reviewed-by:
-
Rasmus Villemoes authored
This is now exactly the same as mpc83xx_ipic_init_IRQ, so just use that directly. Acked-by:
Scott Wood <oss@buserror.net> Reviewed-by:
-
Rasmus Villemoes authored
Having to call qe_ic_init() from platform-specific code makes it awkward to allow building the QE drivers for ARM. It's also a needless duplication of code, and slightly error-prone: Instead of the caller needing to know the details of whether the QUICC Engine High and QUICC Engine Low are actually the same interrupt (see e.g. the machine_is() in mpc85xx_mds_qeic_init), just let the init function choose the appropriate handlers after it has parsed the DT and figured it out. If the two interrupts are distinct, use separate handlers, otherwise use the handler which first checks the CHIVEC register (for the high priority interrupts), then the CIVEC. All existing callers pass 0 for flags, so continue to do that from the new single caller. Later cleanups will remove that argument from qe_ic_init and simplify the body, as well as make qe_ic_init into a proper init function for an IRQCHIP_DECLARE, eliminating the need to manually look up the fsl,qe-ic node. Reviewed-by:
-
Rasmus Villemoes authored
The *_ipic and *_mpic handlers are almost identical - the only difference is that the latter end with an unconditional chip->irq_eoi() call. Since IPIC does not have ->irq_eoi, we can reduce some code duplication by calling irq_eoi conditionally. This is similar to what is already done in mpc8xxx_gpio_irq_cascade(). This leaves the functions slightly misnamed, but that will be fixed in a subsequent patch. Reviewed-by:
-
Rasmus Villemoes authored
There's no point in registering with sysfs when that doesn't actually allow any interaction with the device or driver (no uevents, no sysfs files that provide information or allow configuration, no nothing). Reviewed-by:
-
