Re: [PATCH] MIPS: Select PINCTRL_RT2880 when RALINK is enabled
Hi Nishad, On Tue, Jan 29, 2019 at 08:55:27PM +0530, Nishad Kamdar wrote: > This patch selects config PINCTRL_RT2880 when config RALINK is > enabled as per drivers/staging/mt7621-pinctrl/TODO list. PINCTRL > is also selected when RALINK is enabled to avoid config dependency > warnings. > > Signed-off-by: Nishad Kamdar > --- > arch/mips/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > index e2fc88da0223..cea529cf6284 100644 > --- a/arch/mips/Kconfig > +++ b/arch/mips/Kconfig > @@ -623,6 +623,8 @@ config RALINK > select CLKDEV_LOOKUP > select ARCH_HAS_RESET_CONTROLLER > select RESET_CONTROLLER > + select PINCTRL > + select PINCTRL_RT2880 > > config SGI_IP22 > bool "SGI IP22 (Indy/Indigo2)" Wouldn't this also require selecting STAGING? Perhaps that's why it wasn't done in the first place? Thanks, Paul ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging/octeon: Use stubs for MIPS && !CAVIUM_OCTEON_SOC
When building for a non-Cavium MIPS system with COMPILE_TEST=y, the
Octeon ethernet driver hits a number of issues due to use of macros
provided only for CONFIG_CAVIUM_OCTEON_SOC=y configurations. For
example:
drivers/staging/octeon/ethernet-rx.c:190:6: error:
'CONFIG_CAVIUM_OCTEON_CVMSEG_SIZE' undeclared (first use in this function)
drivers/staging/octeon/ethernet-rx.c:472:25: error:
'OCTEON_IRQ_WORKQ0' undeclared (first use in this function)
These come from various asm/ headers that a non-Octeon build will be
using a non-Octeon version of.
Fix this by using the octeon-stubs.h header for non-Cavium MIPS builds,
and only using the real asm/octeon/ headers when building a Cavium
Octeon kernel configuration.
This requires that octeon-stubs.h doesn't redefine XKPHYS_TO_PHYS, which
is defined for MIPS by asm/addrspace.h which is pulled in by many other
common asm/ headers.
Signed-off-by: Paul Burton
Reported-by: Geert Uytterhoeven
URL:
https://lore.kernel.org/linux-mips/CAMuHMdXvu+BppwzsU9imNWVKea_hoLcRt9N+a29Q-QsjW=i...@mail.gmail.com/
Fixes: 171a9bae68c7 ("staging/octeon: Allow test build on !MIPS")
Cc: Matthew Wilcox (Oracle)
Cc: Greg Kroah-Hartman
Cc: David S. Miller
---
drivers/staging/octeon/octeon-ethernet.h | 2 +-
drivers/staging/octeon/octeon-stubs.h| 5 -
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/octeon/octeon-ethernet.h
b/drivers/staging/octeon/octeon-ethernet.h
index a8a864b40913..042220d86d33 100644
--- a/drivers/staging/octeon/octeon-ethernet.h
+++ b/drivers/staging/octeon/octeon-ethernet.h
@@ -14,7 +14,7 @@
#include
#include
-#ifdef CONFIG_MIPS
+#ifdef CONFIG_CAVIUM_OCTEON_SOC
#include
diff --git a/drivers/staging/octeon/octeon-stubs.h
b/drivers/staging/octeon/octeon-stubs.h
index a4ac3bfb62a8..c7ff90207f8a 100644
--- a/drivers/staging/octeon/octeon-stubs.h
+++ b/drivers/staging/octeon/octeon-stubs.h
@@ -1,5 +1,8 @@
#define CONFIG_CAVIUM_OCTEON_CVMSEG_SIZE 512
-#define XKPHYS_TO_PHYS(p) (p)
+
+#ifndef XKPHYS_TO_PHYS
+# define XKPHYS_TO_PHYS(p) (p)
+#endif
#define OCTEON_IRQ_WORKQ0 0
#define OCTEON_IRQ_RML 0
--
2.23.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/5] staging: octeon: remove typedef declaration for cvmx_wqe
Hi Wambui, Greg,
On Sat, Oct 12, 2019 at 09:04:31PM +0300, Wambui Karuga wrote:
> Remove typedef declaration from struct cvmx_wqe.
> Also replace its previous uses with new struct declaration.
> Issue found by checkpatch.pl
This may work for x86 builds using COMPILE_TEST that will never actually
run this driver, but it completely breaks the build for the systems that
actually do use the driver...
kernelci.org shows build failures resulting from this patch in
linux-next, and I won't be surprised if other patches in this series
result in similar build breakage too:
https://storage.kernelci.org/next/master/next-20191023/mips/cavium_octeon_defconfig/gcc-8/build.log
If you're making significant changes to this driver, please test them
using the MIPS cavium_octeon_defconfig which is where this driver is
actually used.
This driver has broken builds a few times recently which makes me very
tempted to ask that we stop allowing it to be built with COMPILE_TEST.
The whole octeon-stubs.h thing is a horrible hack anyway...
Thanks,
Paul
>
> Signed-off-by: Wambui Karuga
> ---
> drivers/staging/octeon/ethernet-rx.c | 6 +++---
> drivers/staging/octeon/ethernet-tx.c | 2 +-
> drivers/staging/octeon/ethernet.c | 2 +-
> drivers/staging/octeon/octeon-stubs.h | 22 +++---
> 4 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/staging/octeon/ethernet-rx.c
> b/drivers/staging/octeon/ethernet-rx.c
> index 0e65955c746b..2c16230f993c 100644
> --- a/drivers/staging/octeon/ethernet-rx.c
> +++ b/drivers/staging/octeon/ethernet-rx.c
> @@ -60,7 +60,7 @@ static irqreturn_t cvm_oct_do_interrupt(int irq, void
> *napi_id)
> *
> * Returns Non-zero if the packet can be dropped, zero otherwise.
> */
> -static inline int cvm_oct_check_rcv_error(cvmx_wqe_t *work)
> +static inline int cvm_oct_check_rcv_error(struct cvmx_wqe *work)
> {
> int port;
>
> @@ -135,7 +135,7 @@ static inline int cvm_oct_check_rcv_error(cvmx_wqe_t
> *work)
> return 0;
> }
>
> -static void copy_segments_to_skb(cvmx_wqe_t *work, struct sk_buff *skb)
> +static void copy_segments_to_skb(struct cvmx_wqe *work, struct sk_buff *skb)
> {
> int segments = work->word2.s.bufs;
> union cvmx_buf_ptr segment_ptr = work->packet_ptr;
> @@ -215,7 +215,7 @@ static int cvm_oct_poll(struct oct_rx_group *rx_group,
> int budget)
> struct sk_buff *skb = NULL;
> struct sk_buff **pskb = NULL;
> int skb_in_hw;
> - cvmx_wqe_t *work;
> + struct cvmx_wqe *work;
> int port;
>
> if (USE_ASYNC_IOBDMA && did_work_request)
> diff --git a/drivers/staging/octeon/ethernet-tx.c
> b/drivers/staging/octeon/ethernet-tx.c
> index c64728fc21f2..a039882e4f70 100644
> --- a/drivers/staging/octeon/ethernet-tx.c
> +++ b/drivers/staging/octeon/ethernet-tx.c
> @@ -515,7 +515,7 @@ int cvm_oct_xmit_pow(struct sk_buff *skb, struct
> net_device *dev)
> void *copy_location;
>
> /* Get a work queue entry */
> - cvmx_wqe_t *work = cvmx_fpa_alloc(CVMX_FPA_WQE_POOL);
> + struct cvmx_wqe *work = cvmx_fpa_alloc(CVMX_FPA_WQE_POOL);
>
> if (unlikely(!work)) {
> printk_ratelimited("%s: Failed to allocate a work queue
> entry\n",
> diff --git a/drivers/staging/octeon/ethernet.c
> b/drivers/staging/octeon/ethernet.c
> index cf8e9a23ebf9..f892f1ad4638 100644
> --- a/drivers/staging/octeon/ethernet.c
> +++ b/drivers/staging/octeon/ethernet.c
> @@ -172,7 +172,7 @@ static void cvm_oct_configure_common_hw(void)
> */
> int cvm_oct_free_work(void *work_queue_entry)
> {
> - cvmx_wqe_t *work = work_queue_entry;
> + struct cvmx_wqe *work = work_queue_entry;
>
> int segments = work->word2.s.bufs;
> union cvmx_buf_ptr segment_ptr = work->packet_ptr;
> diff --git a/drivers/staging/octeon/octeon-stubs.h
> b/drivers/staging/octeon/octeon-stubs.h
> index b2e3c72205dd..7c29cfbd55d1 100644
> --- a/drivers/staging/octeon/octeon-stubs.h
> +++ b/drivers/staging/octeon/octeon-stubs.h
> @@ -183,13 +183,13 @@ union cvmx_buf_ptr {
> } s;
> };
>
> -typedef struct {
> +struct cvmx_wqe {
> union cvmx_wqe_word0 word0;
> union cvmx_wqe_word1 word1;
> union cvmx_pip_wqe_word2 word2;
> union cvmx_buf_ptr packet_ptr;
> uint8_t packet_data[96];
> -} cvmx_wqe_t;
> +};
>
> typedef union {
> uint64_t u64;
> @@ -1198,7 +1198,7 @@ static inline uint64_t cvmx_scratch_read64(uint64_t
> address)
> static inline void cvmx_scratch_write64(uint64_t address, uint64_t value)
> { }
>
> -static inline int cvmx_wqe_get_grp(cvmx_wqe_t *work)
> +static inline int cvmx_wqe_get_grp(struct cvmx_wqe *work)
> {
> return 0;
> }
> @@ -1345,14 +1345,14 @@ static inline void cvmx_pow_work_request_async(int
> scr_addr,
> cvmx_pow_wait_t wait)
> { }
>
> -static inline cvmx_wqe_t *cvmx_pow_work_response_asyn
Re: [Outreachy kernel] Re: [PATCH v2 1/5] staging: octeon: remove typedef declaration for cvmx_wqe
Hi Wambui, Julia, Side-note: Wambui, your mail client seems to have added this header: Reply-To: alpine.DEB.2.21.1910240722070.2771@hadrien This is the ID of the message you replied to (ie. this is the same value that the In-Reply-To: header has). You should probably figure out how that happened, or you're going to miss responses when people reply without noticing the bogus email address. On Thu, Oct 24, 2019 at 01:00:20PM +0300, Wambui Karuga wrote: > On Thu, Oct 24, 2019 at 07:26:59AM +0200, Julia Lawall wrote: > > > If you're making significant changes to this driver, please test them > > > using the MIPS cavium_octeon_defconfig which is where this driver is > > > actually used. > > > > > > This driver has broken builds a few times recently which makes me very > > > tempted to ask that we stop allowing it to be built with COMPILE_TEST. > > > The whole octeon-stubs.h thing is a horrible hack anyway... > > > > Wambui, > > > > Please figure out what went wrong here. Are there two sets of typedefs > > that should have been updated? > > > I managed to reproduce these build errors and finally noticed that the > "octeon-stubs.h" header is only included when CONFIG_CAVIUM_OCTEON_SOC > is not defined, therefore compiling properly for COMPILE_TEST but will > actually fail when compiled with CONFIG_CAVIUM_OCTEON_SOC is set since > the functions will try to use the definitions in > arch/mips/include/asm/octeon/ that don't have the changes. > > Paul, please tell me if this is correct? Yes, that's correct. The driver was written to use the headers in arch/mips/include/asm/octeon, and then recently the octeon-stubs.h header was added which duplicates lots of the MIPS & Octeon-specific header content in one huge monstrous file. I'm all for improving compile test coverage, but I think octeon-stubs.h in its short life has already proven itself to be a bad way to achieve that goal[1][2][3]. > > Others, > > > > Would it be reasonable to put the information about how the driver should > > be compied in the TODO file? git grep cavium_octeon_defconfig in the > > octeon directory turns up nothing. It wouldn't hurt. I'd argue that Kconfig already provides enough information to figure this out easily though - OCTEON_ETHERNET depends on CAVIUM_OCTEON_SOC || COMPILE_TEST, which ought to tell people that its real use is when CAVIUM_OCTEON_SOC=y. That doesn't necessarily point you to cavium_octeon_defconfig (though grepping for CAVIUM_OCTEON_SOC=y would), but that's not strictly needed anyway - any old config with CAVIUM_OCTEON_SOC=y would do. Thanks, Paul [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0228ecf6128c92b47eadd2ac270c5574d9150c09 [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/staging/octeon?id=17a29fea086ba18b000d28439bd5cb4f2b0a527b [3] https://storage.kernelci.org/next/master/next-20191024/mips/cavium_octeon_defconfig/gcc-8/build.log ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 4/6] dt: bindings: add mt7621-pll dt binding documentation
Hi Chuanhong,
On Wed, Jul 24, 2019 at 10:23:08AM +0800, Chuanhong Guo wrote:
> This commit adds device tree binding documentation for MT7621
> PLL controller.
>
> Signed-off-by: Chuanhong Guo
> ---
>
> Change since v1:
> drop useless syscon in compatible string
>
> .../bindings/clock/mediatek,mt7621-pll.txt | 18 ++
> 1 file changed, 18 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
This binding needs review from DT maintainers before I apply it, but as
a general note it's typical to add the binding *before* its use in the
series. That is, this patch should come before patch 3.
Personally I'd squash it with patch 1 so the binding & the header file
needed to use the binding are added in one patch, then a later patch
actually makes use of them.
Thanks,
Paul
> diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
> b/Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
> new file mode 100644
> index ..7dcfbd5283e3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
> @@ -0,0 +1,18 @@
> +Binding for Mediatek MT7621 PLL controller
> +
> +The PLL controller provides the 2 main clocks of the SoC: CPU and BUS.
> +
> +Required Properties:
> +- compatible: has to be "mediatek,mt7621-pll"
> +- #clock-cells: has to be one
> +
> +Optional properties:
> +- clock-output-names: should be "cpu", "bus"
> +
> +Example:
> + pll {
> + compatible = "mediatek,mt7621-pll";
> +
> + #clock-cells = <1>;
> + clock-output-names = "cpu", "bus";
> + };
> --
> 2.21.0
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 01/23] mtd: rawnand: plat_nand: Pass a nand_chip object to all platform_nand_ctrl hooks
Hi Boris, On Thu, Sep 06, 2018 at 02:05:13PM +0200, Boris Brezillon wrote: > Let's make the raw NAND API consistent by patching all helpers and > hooks to take a nand_chip object instead of an mtd_info one or > remove the mtd_info object when both are passed. > > In order to do that, we first need to update the platform_nand_ctrl > hooks to take a nand_chip object instead of an mtd_info. > > We add temporary plat_nand_xxx() wrappers to the do the mtd -> chip > conversion, but those will be dropped when patching nand_chip hooks to > take a nand_chip object. > > Signed-off-by: Boris Brezillon > Reviewed-by: Alexander Sverdlin > Acked-by: Alexander Sverdlin > Acked-by: Robert Jarzmik > Acked-by: Krzysztof Halasa Acked-by: Paul Burton # MIPS parts Thanks, Paul ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
