Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp85991pxb; Fri, 29 Oct 2021 06:16:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwYzqk3U45OybLSDoK7yTnELEIZ8i26OzswqVeGBLijjTDXQuCc7H3VIy9Ex5BsxwfjWnGV X-Received: by 2002:a92:d64d:: with SMTP id x13mr1099402ilp.42.1635513399585; Fri, 29 Oct 2021 06:16:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635513399; cv=none; d=google.com; s=arc-20160816; b=SXkGKKXA6+5pAvcN1LDYu5MJBTJZQTTsM+oOvf055BcTaNWJ+KvaMB5QMaVcstsQKv BN3I/EtyY3VuolWyhiUvmDZVwAnII4p4JwtpuhaM67ub9p2htO+WjHEoLaVQKJkBaNHo L8r7hmdSubG8HV87AGMzldYCIFua5dE5I26TUoV1yr62P8JkNlcVtR45yyILsDbZK8mD UHcVHRJkJx53liC/SyTvrkCktEPrGXRdIfz7L6M4bJWeiQV4i6A7vpPPLDOyss0cnwX7 ddiIHNA05RxrEklt9IDn5e+5zfJ0jHVB5GYTMDhBeaAuGInjt+/IfmyvZGjWKfd5HQh2 OeXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:in-reply-to:date:subject :cc:to:from:user-agent:references:dkim-signature; bh=8rWNKH5hYRCjifkvw0dL0ZFBh932onsnm/dQ96+dW0o=; b=ANxjHoRNWk8BH1HlLQxua/DMpZZik38IWWXcOCbqpnwEKW1vFfPoL6trbyx3m8q3kJ Ylx3QGd0Be7HFGB8eIcGkxdRz31Yn4vCFAIi6UzjX7IAoHFtwmIeLyQRSLHO7YuWf9tn RptwRC9kZanH0eDibh0K79go3/do1zrlCyrb2nZf3ld2iR6KCAXzBD2oiw3Zwafai22f LO2ZkRNKNyeqKf6+KKnu2fQhhImkUKDwRbxEwOQgYhyiJA4c0B3JAYB//0xvaJDFeh2v nz88t/7Ndlo+rp2bPBynZqF6xklzGexx3BTC66YqhzO2Zsxa7UQdPmCpAi3v/pJG3DZP OetQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Z4fNmufr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u9si959816ill.20.2021.10.29.06.16.03; Fri, 29 Oct 2021 06:16:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Z4fNmufr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231572AbhJ2NQr (ORCPT + 99 others); Fri, 29 Oct 2021 09:16:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:38338 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230213AbhJ2NQq (ORCPT ); Fri, 29 Oct 2021 09:16:46 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id CEDA661167; Fri, 29 Oct 2021 13:14:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1635513258; bh=P1ON3/62L0Dv3I0JOEX4dWv6/iBLDiTdyLMkn72flOE=; h=References:From:To:Cc:Subject:Date:In-reply-to:From; b=Z4fNmufrUQYNBmCrjdme6gGW2Xge2pyny+vN2reRjsWoNza44nM3RQ6+hS/PX5DEY scP+rqH8lgWcJyUrZJSEFsuqjQmnCjiFRwG9nIDIxsp75FSd8w2TWJs3yHMAK3lZ0K eYJQB2rmKAtw8vH2GoaczSKOEaeNDnF8NP8gw5zvMTFMW2RhIM8U2jQ/wOeOuvElAO RcDxnAccPUuIqvwcdCAoMac2dv1WPLvei+QVgl07Wmewf0P2RfsGUPxLYkhf9AXZkH NBk7h0YEkNbxUlSG0HDoom8igk35aQR00aOFAr819AIbeCKjrJEcW5ZyJuiLdMN9UC qfz0e7QKgy/lQ== References: <20211028211753.573480-1-jaschultzMS@gmail.com> <20211028211753.573480-3-jaschultzMS@gmail.com> <87fsskqvvc.fsf@kernel.org> <877ddwqaas.fsf@kernel.org> User-agent: mu4e 1.6.6; emacs 28.0.60 From: Felipe Balbi To: Andy Shevchenko Cc: Jarrett Schultz , Rob Herring , Andy Gross , Bjorn Andersson , Hans de Goede , Mark Gross , Maximilian Luz , "linux-arm-msm@vger.kernel.org" , "platform-driver-x86@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Jarrett Schultz Subject: Re: [PATCH 2/3] platform: surface: Add surface xbl Date: Fri, 29 Oct 2021 16:12:08 +0300 In-reply-to: Message-ID: <875ytgt1lm.fsf@kernel.org> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Andy Shevchenko writes: >> >> > Capital L will be better to read and understand the >> >> > abbreviation. Actually usually we do something like this: >> >> > >> >> > Extensible Boot Loader (EBL) >> >> >> >> nah, this is silly Andy. It's just capitalized as eXtensible Boot >> >> Loader, very much akin to eXtensible Host Controller Interface. >> > >> > My point here is to have a full name followed by the abbreviation. and >> > n(O)t in (F)ancy st(Y)le. >> >> too bad my patch removing acronyms from the kernel got rejects :-p >> >> Seriously, this is pretty pointless. You're vouching for something that >> will just cause confusion. Every piece of internal documentation refers >> to xbl and you want this to be renamed to ebl because it looks nicer for >> you. Thanks, but no thanks. > > Maybe I was too unclear. I'm not pushing for EBL, I'm pushing for the form os > > "Foo bAr BullSh*t (FABS)" vs. "(F)oo b(a)r (B)ull(s)h*t". > > If you have x there to be capitalized, do it like "eXtensible Boot > Loader (XBL)". Is it too hard? Take a breather Andy, you need it. Winter sure is coming >> >> > +static const struct attribute_group inputs_attr_group = { >> >> > + .attrs = inputs_attrs, >> >> > +}; >> >> > + >> >> > +static u8 surface_xbl_readb(void __iomem *base, u32 offset) >> >> > +{ >> >> > + return readb(base + offset); >> >> > +} >> >> > + >> >> > +static u16 surface_xbl_readw(void __iomem *base, u32 offset) >> >> > +{ >> >> > + return readw(base + offset); >> >> > +} >> >> > >> >> > Either use corresponding io accessors in-line, or make first parameter >> >> > to be sirface_xbl pointer. Otherwise these helpers useless. >> >> >> >> I agree with passing surface_xbl point as first parameter, but calling >> >> the accessors pointless is a bit much. At a minimum, they make it easier >> >> to ftrace the entire driver by simply ftracing surface_xbl_* >> > >> > My point is that the above seems half-baked. It's pointless to have a >> > func(a,b) { return readl(a + b); }. It doesn't add value. >> >> sure it does. echo surface_xbl_* > ftrace_filter_function (or whatever >> the filename was) it reason enough IMHO. Not to mention that these >> little accessors will likely be optimized by the compiler. > > readl() will appear in the traces, no? But yeah I also was thinking > about the weakness in your argument that the compiler can silently > inline them anyway. In non-debug builds, when tracers are enabled a thunk will be added for runtime patching ;-) (IIRC) -- balbi