From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 33354C2BB55 for ; Thu, 16 Apr 2020 19:59:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1783421744 for ; Thu, 16 Apr 2020 19:59:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730551AbgDPT7n (ORCPT ); Thu, 16 Apr 2020 15:59:43 -0400 Received: from baldur.buserror.net ([165.227.176.147]:38602 "EHLO baldur.buserror.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727827AbgDPT7m (ORCPT ); Thu, 16 Apr 2020 15:59:42 -0400 Received: from [2601:449:8480:af0:12bf:48ff:fe84:c9a0] by baldur.buserror.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jPAfj-0007F3-PU; Thu, 16 Apr 2020 14:59:40 -0500 Message-ID: <16f8fa2d26d88f22ed05e9870709c2fd5c3960cf.camel@buserror.net> From: Scott Wood To: Wang Wenhu , gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, christophe.leroy@c-s.fr, linuxppc-dev@lists.ozlabs.org Cc: kernel@vivo.com, Michael Ellerman Date: Thu, 16 Apr 2020 14:59:36 -0500 In-Reply-To: <20200416153537.23736-5-wenhu.wang@vivo.com> References: <20200416153537.23736-1-wenhu.wang@vivo.com> <20200416153537.23736-5-wenhu.wang@vivo.com> Organization: Red Hat Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2601:449:8480:af0:12bf:48ff:fe84:c9a0 X-SA-Exim-Rcpt-To: wenhu.wang@vivo.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, christophe.leroy@c-s.fr, linuxppc-dev@lists.ozlabs.org, kernel@vivo.com, mpe@ellerman.id.au X-SA-Exim-Mail-From: oss@buserror.net Subject: Re: [PATCH v4,4/4] drivers: uio: new driver for fsl_85xx_cache_sram X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000) X-SA-Exim-Scanned: Yes (on baldur.buserror.net) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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