From: Greg KH <greg@kroah.com>
To: Tomek The Messenger <tomekthemessenger@gmail.com>
Cc: Ahmad Fatoum <a.fatoum@pengutronix.de>, kernelnewbies@kernelnewbies.org
Subject: Re: the cost of EXPORT_SYMBOL_GPL
Date: Wed, 17 Jun 2020 17:08:04 +0200 [thread overview]
Message-ID: <20200617150804.GA2699137@kroah.com> (raw)
In-Reply-To: <CAA4NGyuy4OiQK5azJ6VyLxA8Anv248g_mHGV_HoJECoay+JNrw@mail.gmail.com>
On Wed, Jun 17, 2020 at 04:26:49PM +0200, Tomek The Messenger wrote:
> > If we have one unique sysfs interface then it is easier for
> > everyone: tester, developer to proceed with such device, testing or
> > debugging.
>
> >>No - not really. Because if you're mapping 3 or 4 SOC resets reasons to
> >>one thing, you then have to write code that says "If it's SoC 1, then
> >>a bit 12 being set was a memory error, but if it's SOC 2 bit 12 means a
> >>PCI bus reset and a memory parity error is bit 17, but a memory ECC
> >>error is bit 4."
>
> >>And if the meaning of the reset register is different, a lot of *other*
> things
> >>are probably different too, which is an argument for just having separate
> >>drivers for each SoC.
>
> Yes separate drivers but the actions do by them is to create the same files
> in sysfs. So if somebody use intel, texas instrument or xilinx soc then in
> order to read reset reason or other stuff he will use sysfs. So this will
> look likes:
> /sys/resetreg - 3 separate drivers plus one core driver where there is
> common part
> /sys/otherfunctionality- as Above
> Apart from above 3 drivers where there is api to access registers from
> ti, Intel, xilinx. This was original question if place here all api
> reads/writes or only common between sysfs kernel modules.
> ...
> /sys/functionalityN -> separate driver for intel, TI, Xilinx
Again, use the specific subsystem for these values, don't try to expose
your own mess in sysfs, especially with "raw" kobjects. You will run
into loads of problems that way.
greg k-h
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next prev parent reply other threads:[~2020-06-17 15:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-16 13:18 the cost of EXPORT_SYMBOL_GPL Tomek The Messenger
2020-06-16 13:27 ` Greg KH
2020-06-17 7:58 ` Tomek The Messenger
2020-06-17 8:55 ` Greg KH
2020-06-17 9:17 ` Tomek The Messenger
2020-06-17 9:28 ` Tomek The Messenger
2020-06-17 9:41 ` Greg KH
2020-06-17 10:39 ` Tomek The Messenger
2020-06-17 12:24 ` Valdis Klētnieks
2020-06-17 12:31 ` Greg KH
2020-06-17 12:35 ` Martin Kaiser
2020-06-17 12:48 ` Tomek The Messenger
2020-06-17 13:20 ` Valdis Klētnieks
2020-06-17 13:34 ` Ahmad Fatoum
2020-06-17 14:26 ` Tomek The Messenger
2020-06-17 15:08 ` Greg KH [this message]
2020-06-17 18:33 ` Valdis Klētnieks
2020-06-17 13:31 ` Greg KH
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=20200617150804.GA2699137@kroah.com \
--to=greg@kroah.com \
--cc=a.fatoum@pengutronix.de \
--cc=kernelnewbies@kernelnewbies.org \
--cc=tomekthemessenger@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).