From: Scott Wood <oss@buserror.net> To: Wang Wenhu <wenhu.wang@vivo.com>, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, christophe.leroy@c-s.fr, linuxppc-dev@lists.ozlabs.org Cc: kernel@vivo.com, Michael Ellerman <mpe@ellerman.id.au> Subject: Re: [PATCH v4,4/4] drivers: uio: new driver for fsl_85xx_cache_sram Date: Thu, 16 Apr 2020 14:59:36 -0500 [thread overview] Message-ID: <16f8fa2d26d88f22ed05e9870709c2fd5c3960cf.camel@buserror.net> (raw) In-Reply-To: <20200416153537.23736-5-wenhu.wang@vivo.com> On Thu, 2020-04-16 at 08:35 -0700, Wang Wenhu wrote: > +#define UIO_INFO_VER "devicetree,pseudo" What does this mean? Changing a number into a non-obvious string (Why "pseudo"? Why does the UIO user care that the config came from the device tree?) just to avoid setting off Greg's version number autoresponse isn't really helping anything. > +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = { > + { .compatible = "uio,mpc85xx-cache-sram", }, > + {}, > +}; > + > +static struct platform_driver uio_fsl_85xx_cache_sram = { > + .probe = uio_fsl_85xx_cache_sram_probe, > + .remove = uio_fsl_85xx_cache_sram_remove, > + .driver = { > + .name = DRIVER_NAME, > + .owner = THIS_MODULE, > + .of_match_table = uio_mpc85xx_l2ctlr_of_match, > + }, > +}; Greg's comment notwithstanding, I really don't think this belongs in the device tree (and if I do get overruled on that point, it at least needs a binding document). Let me try to come up with a patch for dynamic allocation. -Scott
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <oss@buserror.net> To: Wang Wenhu <wenhu.wang@vivo.com>, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, christophe.leroy@c-s.fr, linuxppc-dev@lists.ozlabs.org Cc: kernel@vivo.com Subject: Re: [PATCH v4,4/4] drivers: uio: new driver for fsl_85xx_cache_sram Date: Thu, 16 Apr 2020 14:59:36 -0500 [thread overview] Message-ID: <16f8fa2d26d88f22ed05e9870709c2fd5c3960cf.camel@buserror.net> (raw) In-Reply-To: <20200416153537.23736-5-wenhu.wang@vivo.com> On Thu, 2020-04-16 at 08:35 -0700, Wang Wenhu wrote: > +#define UIO_INFO_VER "devicetree,pseudo" What does this mean? Changing a number into a non-obvious string (Why "pseudo"? Why does the UIO user care that the config came from the device tree?) just to avoid setting off Greg's version number autoresponse isn't really helping anything. > +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = { > + { .compatible = "uio,mpc85xx-cache-sram", }, > + {}, > +}; > + > +static struct platform_driver uio_fsl_85xx_cache_sram = { > + .probe = uio_fsl_85xx_cache_sram_probe, > + .remove = uio_fsl_85xx_cache_sram_remove, > + .driver = { > + .name = DRIVER_NAME, > + .owner = THIS_MODULE, > + .of_match_table = uio_mpc85xx_l2ctlr_of_match, > + }, > +}; Greg's comment notwithstanding, I really don't think this belongs in the device tree (and if I do get overruled on that point, it at least needs a binding document). Let me try to come up with a patch for dynamic allocation. -Scott
next prev parent reply other threads:[~2020-04-16 19:59 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-16 15:35 [PATCH v4,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram Wang Wenhu 2020-04-16 15:35 ` [PATCH v4,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr Wang Wenhu 2020-04-16 15:35 ` [PATCH v4, 1/4] " Wang Wenhu 2020-04-16 15:45 ` [PATCH v4,1/4] " Christophe Leroy 2020-04-16 15:45 ` Christophe Leroy 2020-04-16 15:35 ` [PATCH v4,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram Wang Wenhu 2020-04-16 15:35 ` [PATCH v4, 2/4] " Wang Wenhu 2020-04-16 15:45 ` [PATCH v4,2/4] " Christophe Leroy 2020-04-16 15:45 ` Christophe Leroy 2020-04-16 15:35 ` [PATCH v4,3/4] powerpc: sysdev: fix compile warning " Wang Wenhu 2020-04-16 15:35 ` [PATCH v4, 3/4] " Wang Wenhu 2020-04-16 15:46 ` [PATCH v4,3/4] " Christophe Leroy 2020-04-16 15:46 ` Christophe Leroy 2020-04-16 15:35 ` [PATCH v4,4/4] drivers: uio: new driver " Wang Wenhu 2020-04-16 15:35 ` Wang Wenhu 2020-04-16 15:43 ` Christophe Leroy 2020-04-16 15:43 ` Christophe Leroy 2020-04-16 19:59 ` Scott Wood [this message] 2020-04-16 19:59 ` Scott Wood 2020-04-16 21:35 ` Rob Herring 2020-04-16 21:35 ` Rob Herring 2020-04-17 2:31 ` 王文虎 2020-04-17 2:31 ` 王文虎 2020-04-17 4:58 ` Scott Wood 2020-04-17 4:58 ` Scott Wood 2020-04-17 7:04 ` 王文虎 2020-04-17 7:04 ` 王文虎 2020-04-17 7:42 ` Greg KH 2020-04-17 7:42 ` Greg KH 2020-04-17 9:17 ` Scott Wood 2020-04-17 9:17 ` Scott Wood 2020-04-17 14:16 ` 王文虎 2020-04-17 14:16 ` 王文虎 2020-04-17 22:50 ` Scott Wood 2020-04-17 22:50 ` Scott Wood
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=16f8fa2d26d88f22ed05e9870709c2fd5c3960cf.camel@buserror.net \ --to=oss@buserror.net \ --cc=christophe.leroy@c-s.fr \ --cc=gregkh@linuxfoundation.org \ --cc=kernel@vivo.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=mpe@ellerman.id.au \ --cc=wenhu.wang@vivo.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.