Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1918365pxp; Mon, 21 Mar 2022 07:39:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx8hjC1k4GwCcU4qpnwfCCEhQSRi1+n20bPjegMQkh9zmt77jj+n0TH3XEvjwwkMmlqQLru X-Received: by 2002:aa7:8256:0:b0:4e0:78ad:eb81 with SMTP id e22-20020aa78256000000b004e078adeb81mr24574464pfn.30.1647873587300; Mon, 21 Mar 2022 07:39:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647873587; cv=none; d=google.com; s=arc-20160816; b=b8Kp3XjeOr7dNUS6t0s+ctjAnyqSynCqJgyx/cfDRwlyJaky7K8oFOs2WRxuW2cQf0 8l6MZG3zqZ2amcQqQ4yNTSgqfPFq96kSLeo6eZYPPa2l3wS+uiespFAZ14Fyanuh95K2 jlLhANmmnbH7KCo/iYspLj3NL0v40flyfdxjhS9xos0KM+MxShTXepvjwLdSddHLW7bt xDQR+sYE62rBo4/yow+8wMJVNkZyrQ3x5A2Vj0Z1eLmEZdNXRxcZBdge8IR+YiEtIniG ydxQZ485A/MSeb8BbdPqhBvJQ9KGlQE27lu6C1P6yHM4Isi5hFx6b6ldCjyCYkz2phhw RMqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=5fVM9GxpYrKL0vDGShMfVI5LEzMqL6jtRV6TGvb20BM=; b=vlXFu9ReY3R5H/RNeWaZCaMxsh3i9zmXyS5GJ5o4bsEPPODhORpQBkGlb0uR3ZCtps /uU6s3E5Zv9wNEDiBFGHd3PELJMq9rvOPcN7/ldPVdoAOXwCR8Tw5NG4XchfoJz6qj35 wY+8ua0cqkPdpjzgVVfWNDZlq/04uY3G89vQnHyjOJshyPZR1RxrmPk9TCSl+N+sR6N3 uQ5WZFDMG8r/ugO2xVpEwBvv2Mof075I1NLJjiCrCRgpejOFtWxmbEdM/2Cxb+7l3aKD XpQNnXZAY3FCamYXwW5H84e0jXokpFSCTQs6J7MmcAbbr3yo45XLkDP7zkeiBMfTHrGw G/Qg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=U2GqGKuz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 20-20020a631954000000b003816043eee4si13522594pgz.217.2022.03.21.07.39.33; Mon, 21 Mar 2022 07:39:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=U2GqGKuz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241309AbiCRWc0 (ORCPT + 99 others); Fri, 18 Mar 2022 18:32:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37100 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241298AbiCRWcX (ORCPT ); Fri, 18 Mar 2022 18:32:23 -0400 Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B73E12EB54E for ; Fri, 18 Mar 2022 15:30:59 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id v35so18199643ybi.10 for ; Fri, 18 Mar 2022 15:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5fVM9GxpYrKL0vDGShMfVI5LEzMqL6jtRV6TGvb20BM=; b=U2GqGKuzbJHZ37d58mvNR42j7vtzFiu5+ShjP+SnBIBUSTEpoSS+4LPWNJW7gZ0Q8l fUmxc/Los26bhN33axqlj/Eb5KyKZcw3JA32xC459u9s6qiFUzv4h156LaeiOG3gV2+q y+SJOensPKHwrY2YKVQSbR9cm8yqeretLrLPis/lnv+yxT3XXIESat+/6IWVCIJFetJe vh1Zn1Hn9TZIY+fTl3I3hELf0BUZXaszXLNCmpazoFvGdy7r0qv8U00udaLnPa2jNb0F c1J3W+tuy3Q0nVWMxBBZenffBsyUjXRZiwIPI7oPCGSIn+Jz4LXnvPdCLyKNAfp6fKcF A6cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5fVM9GxpYrKL0vDGShMfVI5LEzMqL6jtRV6TGvb20BM=; b=sgHjIJtIa1svP4Qynve7aoRmc5z05hzzXxxlY5W45jues35tuuhGBwmN/SYR5cbZN8 nn3Df2qUGtQ2WAUh76J1/9GCKE5xSjdVeAJcb+/tGa3mGkTV0HDId35JNBbIYYjZhovj aF4QS25eXPUjIP91pVH6PnuegdcUWKkTiRrR0hd0tO3b61Jkqm5DHa9LdUmDeYrzdObY SpMzGw6oymONFVxYGTChOWfxSNYNUqJMub5T2KHnDPZedM0P7QYDQ2XU2xxbZR8RFQd1 0CAgOjr08KeBfkjak0r5Mwg6XI2Qq0HrPQcsXcdoZVKbc/zJlx9iEy0FRMBJB/g8a6Es jmPQ== X-Gm-Message-State: AOAM530aHmFbYiAV+waeBnBuRwq+i2LKtXAyc4Jxfq6SuzcLltNzSoW5 DrZfdxvqknxFrAMTjlMAardr+UsIpAYdSM59q5GbXE5w X-Received: by 2002:a25:344b:0:b0:633:b905:46ff with SMTP id b72-20020a25344b000000b00633b90546ffmr5701314yba.330.1647642656484; Fri, 18 Mar 2022 15:30:56 -0700 (PDT) MIME-Version: 1.0 References: <2d97ae92b9c06214be0e088a72cf303eb591bf01.1646414295.git.christophe.leroy@csgroup.eu> <47e09d6010852db928c0de29b89450ea7eee74d8.camel@redhat.com> <672043db-5290-293c-fde4-440989c78d09@csgroup.eu> <9aebcbbf-aaba-f7e8-7397-18284e74ab0d@csgroup.eu> In-Reply-To: From: Ben Skeggs Date: Sat, 19 Mar 2022 08:30:45 +1000 Message-ID: Subject: Re: [PATCH] drm/nouveau/bios: Rename prom_init() and friends functions To: Lyude Paul Cc: Christophe Leroy , Ben Skeggs , Karol Herbst , David Airlie , Daniel Vetter , ML nouveau , LKML , ML dri-devel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 19 Mar 2022 at 04:11, Lyude Paul wrote: > > Whoops, sorry! I was unsure of the preference in name we should go with s= o I > poked Ben on the side to ask them, but I can see they haven't yet respond= ed. > I'll poke thme again and see if I can get a response. Yeah, please keep _prom as opposed to _rom. It's a reference to the NV_PROM device. Ben. > > On Fri, 2022-03-18 at 10:55 +0100, Christophe Leroy wrote: > > Hi Paul, > > > > Le 05/03/2022 =C3=A0 10:51, Christophe Leroy a =C3=A9crit : > > > > > > > > > Le 05/03/2022 =C3=A0 08:38, Christophe Leroy a =C3=A9crit : > > > > > > > > > > > > Le 04/03/2022 =C3=A0 21:24, Lyude Paul a =C3=A9crit : > > > > > This mostly looks good to me. Just one question (and one comment = down > > > > > below > > > > > that needs addressing). Is this with ppc32? (I ask because ppc64l= e > > > > > doesn't > > > > > seem to hit this compilation error). > > > > > > > > That's with PPC64, see > > > > http://kisskb.ellerman.id.au/kisskb/branch/chleroy/head/252ba609bea= 83234d2e35841c19ae84c67b43ec7/ > > > > > > > > > > > > > > > > But that's not (yet) with the mainline tree. That's work I'm doing = to > > > > cleanup our asm/asm-protoypes.h header. > > > > > > > > Since commit 4efca4ed05cb ("kbuild: modversions for EXPORT_SYMBOL() > > > > for asm") that file is dedicated to prototypes of functions defined= in > > > > assembly. Therefore I'm trying to dispatch C functions prototypes i= n > > > > other headers. I wanted to move prom_init() prototype into asm/prom= .h > > > > and then I hit the problem. > > > > > > > > In the beginning I was thinking about just changing the name of the > > > > function in powerpc, but as I see that M68K, MIPS and SPARC also ha= ve > > > > a prom_init() function, I thought it would be better to change the > > > > name in shadowrom.c to avoid any future conflict like the one I got > > > > while reworking the headers. > > > > > > > > > > > > > > @@ -57,8 +57,8 @@ prom_init(struct nvkm_bios *bios, const char > > > > > > *name) > > > > > > const struct nvbios_source > > > > > > nvbios_rom =3D { > > > > > > .name =3D "PROM", > > > > > > - .init =3D prom_init, > > > > > > - .fini =3D prom_fini, > > > > > > - .read =3D prom_read, > > > > > > + .init =3D nvbios_rom_init, > > > > > > + .fini =3D nvbios_rom_fini, > > > > > > + .read =3D nvbios_rom_read, > > > > > > > > > > Seeing as the source name is prom, I think using the naming conve= ntion > > > > > nvbios_prom_* would be better then nvbios_rom_*. > > > > > > > > > > > > > Yes I wasn't sure about the best naming as the file name is > > > > shadowrom.c and not shadowprom.c. > > > > > > > > I will send v2 using nvbios_prom_* as a name. > > > > > > While preparing v2 I remembered that in fact, I called the functions > > > nvbios_rom_* because the name of the nvbios_source struct is nvbios_r= om, > > > so for me it made sense to use the name of the struct as a prefix for > > > the functions. > > > > > > So I'm OK to change it to nvbios_prom_* but it looks less logical to = me. > > > > > > Please confirm you still prefer nvbios_prom as prefix to the function > > > names. > > > > > > > Are you still expecting a v2 for this patch ? > > > > As the name of the structure is nvbios_rom, do you really prefer the > > functions to be called nvbios_prom_* as you mentionned in your comment = ? > > > > In that case, do you also expect the structure name to be changed to > > nvbios_prom ? > > > > Thanks > > Christophe > > > > -- > Cheers, > Lyude Paul (she/her) > Software Engineer at Red Hat >