From: Jiri Pirko <jiri@mellanox.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Oleksandr Shamray <oleksandrs@mellanox.com>,
gregkh@linuxfoundation.org, arnd@arndb.de,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
openbmc@lists.ozlabs.org, joel@jms.id.au, jiri@resnulli.us,
tklauser@distanz.ch, linux-serial@vger.kernel.org,
vadimp@mellanox.com, system-sw-low-level@mellanox.com,
robh+dt@kernel.org, openocd-devel-owner@lists.sourceforge.net,
linux-api@vger.kernel.org, davem@davemloft.net,
mchehab@kernel.org
Subject: Re: [patch v15 1/4] drivers: jtag: Add JTAG core driver
Date: Tue, 26 Dec 2017 09:47:13 +0100 [thread overview]
Message-ID: <20171226084713.GA2175@nanopsycho> (raw)
In-Reply-To: <13433849-cb7d-e2c0-4ce9-d91a6012d7d7@gmail.com>
Tue, Dec 26, 2017 at 12:09:08AM CET, f.fainelli@gmail.com wrote:
>Le 12/25/17 à 03:53, Oleksandr Shamray a écrit :
[...]
>[snip]
>
>> +
>> +void *jtag_priv(struct jtag *jtag)
>> +{
>> + return jtag->priv;
>> +}
>> +EXPORT_SYMBOL_GPL(jtag_priv);
>
>Can't you just create a static inline function in the public header for
>that? This is usually what subsystems do, I can understand why you would
>not want to expose struct jtag to other parts of the kernel, but still,
>this looks ugly, so maybe consider splitting the header between provider
>and consumer?
Other subsystems expose the struct. Here, it is intentional to don't
expose the struct, that's why we have this helper. What is ugly about
that? :)
WARNING: multiple messages have this Message-ID (diff)
From: Jiri Pirko <jiri-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
To: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Oleksandr Shamray
<oleksandrs-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
arnd-r2nGTMty4D4@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
openbmc-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org,
jiri-rHqAuBHg3fBzbRFIqnYvSA@public.gmane.org,
tklauser-93Khv+1bN0NyDzI6CaY1VQ@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
vadimp-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org,
system-sw-low-level-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
openocd-devel-owner-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Subject: Re: [patch v15 1/4] drivers: jtag: Add JTAG core driver
Date: Tue, 26 Dec 2017 09:47:13 +0100 [thread overview]
Message-ID: <20171226084713.GA2175@nanopsycho> (raw)
In-Reply-To: <13433849-cb7d-e2c0-4ce9-d91a6012d7d7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Tue, Dec 26, 2017 at 12:09:08AM CET, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
>Le 12/25/17 à 03:53, Oleksandr Shamray a écrit :
[...]
>[snip]
>
>> +
>> +void *jtag_priv(struct jtag *jtag)
>> +{
>> + return jtag->priv;
>> +}
>> +EXPORT_SYMBOL_GPL(jtag_priv);
>
>Can't you just create a static inline function in the public header for
>that? This is usually what subsystems do, I can understand why you would
>not want to expose struct jtag to other parts of the kernel, but still,
>this looks ugly, so maybe consider splitting the header between provider
>and consumer?
Other subsystems expose the struct. Here, it is intentional to don't
expose the struct, that's why we have this helper. What is ugly about
that? :)
WARNING: multiple messages have this Message-ID (diff)
From: jiri@mellanox.com (Jiri Pirko)
To: linux-arm-kernel@lists.infradead.org
Subject: [patch v15 1/4] drivers: jtag: Add JTAG core driver
Date: Tue, 26 Dec 2017 09:47:13 +0100 [thread overview]
Message-ID: <20171226084713.GA2175@nanopsycho> (raw)
In-Reply-To: <13433849-cb7d-e2c0-4ce9-d91a6012d7d7@gmail.com>
Tue, Dec 26, 2017 at 12:09:08AM CET, f.fainelli at gmail.com wrote:
>Le 12/25/17 ? 03:53, Oleksandr Shamray a ?crit?:
[...]
>[snip]
>
>> +
>> +void *jtag_priv(struct jtag *jtag)
>> +{
>> + return jtag->priv;
>> +}
>> +EXPORT_SYMBOL_GPL(jtag_priv);
>
>Can't you just create a static inline function in the public header for
>that? This is usually what subsystems do, I can understand why you would
>not want to expose struct jtag to other parts of the kernel, but still,
>this looks ugly, so maybe consider splitting the header between provider
>and consumer?
Other subsystems expose the struct. Here, it is intentional to don't
expose the struct, that's why we have this helper. What is ugly about
that? :)
next prev parent reply other threads:[~2017-12-26 8:47 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-25 11:53 [patch v15 0/4] JTAG driver introduction Oleksandr Shamray
2017-12-25 11:53 ` Oleksandr Shamray
2017-12-25 11:53 ` [patch v15 1/4] drivers: jtag: Add JTAG core driver Oleksandr Shamray
2017-12-25 11:53 ` Oleksandr Shamray
2017-12-25 23:09 ` Florian Fainelli
2017-12-25 23:09 ` Florian Fainelli
2017-12-25 23:09 ` Florian Fainelli
2017-12-26 8:47 ` Jiri Pirko [this message]
2017-12-26 8:47 ` Jiri Pirko
2017-12-26 8:47 ` Jiri Pirko
2018-01-12 16:42 ` Oleksandr Shamray
2018-01-12 16:42 ` Oleksandr Shamray
2018-01-12 16:42 ` Oleksandr Shamray
2018-01-12 16:42 ` Oleksandr Shamray
2017-12-25 11:53 ` [patch v15 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver Oleksandr Shamray
2017-12-25 11:53 ` Oleksandr Shamray
2018-01-11 17:45 ` Joel Stanley
2018-01-11 17:45 ` Joel Stanley
2017-12-25 11:53 ` [patch v15 3/4] Documentation: jtag: Add bindings for " Oleksandr Shamray
2017-12-25 11:53 ` Oleksandr Shamray
2017-12-25 11:53 ` Oleksandr Shamray
2018-01-11 17:50 ` Joel Stanley
2018-01-11 17:50 ` Joel Stanley
2018-01-11 23:54 ` Joel Stanley
2018-01-11 23:54 ` Joel Stanley
2018-01-11 23:54 ` Joel Stanley
2017-12-25 11:53 ` [patch v15 4/4] Documentation: jtag: Add ABI documentation Oleksandr Shamray
2017-12-25 11:53 ` Oleksandr Shamray
2017-12-25 11:53 ` Oleksandr Shamray
2018-01-18 21:27 ` Pavel Machek
2018-01-18 21:27 ` Pavel Machek
2018-01-18 21:27 ` Pavel Machek
2017-12-25 23:17 ` [patch v15 0/4] JTAG driver introduction Florian Fainelli
2017-12-25 23:17 ` Florian Fainelli
2017-12-25 23:17 ` Florian Fainelli
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=20171226084713.GA2175@nanopsycho \
--to=jiri@mellanox.com \
--cc=arnd@arndb.de \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jiri@resnulli.us \
--cc=joel@jms.id.au \
--cc=linux-api@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=oleksandrs@mellanox.com \
--cc=openbmc@lists.ozlabs.org \
--cc=openocd-devel-owner@lists.sourceforge.net \
--cc=robh+dt@kernel.org \
--cc=system-sw-low-level@mellanox.com \
--cc=tklauser@distanz.ch \
--cc=vadimp@mellanox.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: link
Be 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.