All of lore.kernel.org
 help / color / mirror / Atom feed
From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH dtc] C-based DT schema checker integrated into dtc
Date: Tue, 5 Nov 2013 13:36:59 -0700	[thread overview]
Message-ID: <20131105203659.GA26576@obsidianresearch.com> (raw)
In-Reply-To: <201311052117.33443.arnd@arndb.de>

On Tue, Nov 05, 2013 at 09:17:32PM +0100, Arnd Bergmann wrote:
> Creating a platform_device (or a plain device, for that matter)
> from a proper probe() function would have a similar effect from
> the perspective of the TPM subsystem (or other subsystems using

I'd rather see the core get fixed than more muck in the drivers,
especially since things are going in that direction :)

> Yes. Note that the use of new 'class'es is not recommended any more,
> nowadays we are supposed to use 'bus_type' for this, which is
> traditionally something slightly different, but technically almost
> the same implementation-wise.

Thanks, I will look into that!
 
> That depends: the requirement is that no user space breaks after
> a change. I assume that there is a fairly limited set of packages
> accessing the tpm sysfs files. If all of them are written properly,
> they should be able to deal with looking at the files in a different
> place in sysfs.

The other issue is that none of the sysfs files are even close to
following the one value per file rule, they are all wrong. I actually
think that nothing in userspace ever uses them and they were only ever
done for debugfs-like purposes.

My dark hope is to move them all to debugfs and entirely out of
sysfs.. But I think it will be through a CONFIG_TPM_SYSFS_COMPAT=y +
printk_once("Stop using these sysfs attributes!") kind of scheme.
 
> Another option is to change the TPM core sysfs attributes not to
> look at drvdata, but to use devres_find() to find the data they
> need.

Ooh, that looks like it could work well, I will keep that in mind!

So there is a path forward, it is just long :)

BTW, in the final form TPM will require a 2 stage init much like net,
the sequence will be:
 - Allocate the core and driver memory and resources
 - Setup the driver fully
 - Perform TPM commands on the fully active driver to setup the
   TPM itself
 - Register the TPM with the system

Just remarking,I don't see a problem with this and your devm_probe
plan.

Thanks
Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Jon Loeliger <jdl-CYoMK+44s/E@public.gmane.org>,
	khilman-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
	pawel.moll-5wv7dgnIgG8@public.gmane.org,
	Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
	Tomasz Figa <t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	Tomasz Figa <tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org,
	Grant Likely
	<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>,
	fparent-rdvid1DuHRBWk0Htik3J/w@public.gmane.org,
	a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
	Benoit Cousson <bcousson-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
	galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org,
	Alison_Chaiken-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	David Gibson
	<david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
Subject: Re: [RFC PATCH dtc] C-based DT schema checker integrated into dtc
Date: Tue, 5 Nov 2013 13:36:59 -0700	[thread overview]
Message-ID: <20131105203659.GA26576@obsidianresearch.com> (raw)
In-Reply-To: <201311052117.33443.arnd-r2nGTMty4D4@public.gmane.org>

On Tue, Nov 05, 2013 at 09:17:32PM +0100, Arnd Bergmann wrote:
> Creating a platform_device (or a plain device, for that matter)
> from a proper probe() function would have a similar effect from
> the perspective of the TPM subsystem (or other subsystems using

I'd rather see the core get fixed than more muck in the drivers,
especially since things are going in that direction :)

> Yes. Note that the use of new 'class'es is not recommended any more,
> nowadays we are supposed to use 'bus_type' for this, which is
> traditionally something slightly different, but technically almost
> the same implementation-wise.

Thanks, I will look into that!
 
> That depends: the requirement is that no user space breaks after
> a change. I assume that there is a fairly limited set of packages
> accessing the tpm sysfs files. If all of them are written properly,
> they should be able to deal with looking at the files in a different
> place in sysfs.

The other issue is that none of the sysfs files are even close to
following the one value per file rule, they are all wrong. I actually
think that nothing in userspace ever uses them and they were only ever
done for debugfs-like purposes.

My dark hope is to move them all to debugfs and entirely out of
sysfs.. But I think it will be through a CONFIG_TPM_SYSFS_COMPAT=y +
printk_once("Stop using these sysfs attributes!") kind of scheme.
 
> Another option is to change the TPM core sysfs attributes not to
> look at drvdata, but to use devres_find() to find the data they
> need.

Ooh, that looks like it could work well, I will keep that in mind!

So there is a path forward, it is just long :)

BTW, in the final form TPM will require a 2 stage init much like net,
the sequence will be:
 - Allocate the core and driver memory and resources
 - Setup the driver fully
 - Perform TPM commands on the fully active driver to setup the
   TPM itself
 - Register the TPM with the system

Just remarking,I don't see a problem with this and your devm_probe
plan.

Thanks
Jason
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2013-11-05 20:36 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-24 21:51 [RFC PATCH dtc] C-based DT schema checker integrated into dtc Stephen Warren
2013-10-24 21:51 ` Stephen Warren
2013-10-24 23:43 ` Grant Likely
2013-10-24 23:43   ` Grant Likely
2013-10-25  4:00   ` Kumar Gala
2013-10-25  4:00     ` Kumar Gala
2013-10-25 14:44   ` Stephen Warren
2013-10-25 14:44     ` Stephen Warren
2013-10-25 15:21     ` Jon Loeliger
2013-10-25 15:21       ` Jon Loeliger
2013-10-25 17:38       ` Rob Herring
2013-10-25 17:38         ` Rob Herring
2013-10-25 23:11       ` David Gibson
2013-10-25 23:11         ` David Gibson
2013-11-03 23:15         ` Tomasz Figa
2013-11-03 23:15           ` Tomasz Figa
2013-11-03 23:26           ` Tomasz Figa
2013-11-03 23:26             ` Tomasz Figa
2013-11-04  9:28             ` Arnd Bergmann
2013-11-04  9:28               ` Arnd Bergmann
2013-11-04 12:31               ` Tomasz Figa
2013-11-04 12:31                 ` Tomasz Figa
2013-11-04 16:37               ` Stephen Warren
2013-11-04 16:37                 ` Stephen Warren
2013-11-04 18:57                 ` Olof Johansson
2013-11-04 18:57                   ` Olof Johansson
2013-11-04 20:43                 ` Arnd Bergmann
2013-11-04 20:43                   ` Arnd Bergmann
2013-11-04 21:29                   ` Jason Gunthorpe
2013-11-04 21:29                     ` Jason Gunthorpe
2013-11-04 21:43                     ` Stephen Warren
2013-11-04 21:43                       ` Stephen Warren
2013-11-04 22:21                       ` Jason Gunthorpe
2013-11-04 22:21                         ` Jason Gunthorpe
2013-11-05 12:14                         ` Arnd Bergmann
2013-11-05 12:14                           ` Arnd Bergmann
2013-11-05  8:39                     ` Arnd Bergmann
2013-11-05  8:39                       ` Arnd Bergmann
2013-11-05 18:03                       ` Jason Gunthorpe
2013-11-05 18:03                         ` Jason Gunthorpe
2013-11-05 18:48                         ` Arnd Bergmann
2013-11-05 18:48                           ` Arnd Bergmann
2013-11-05 19:12                           ` Jason Gunthorpe
2013-11-05 19:12                             ` Jason Gunthorpe
2013-11-05 19:34                             ` Arnd Bergmann
2013-11-05 19:34                               ` Arnd Bergmann
2013-11-05 19:58                               ` Jason Gunthorpe
2013-11-05 19:58                                 ` Jason Gunthorpe
2013-11-05 20:17                                 ` Arnd Bergmann
2013-11-05 20:17                                   ` Arnd Bergmann
2013-11-05 20:36                                   ` Jason Gunthorpe [this message]
2013-11-05 20:36                                     ` Jason Gunthorpe
2013-11-04 21:50                   ` Stephen Warren
2013-11-04 21:50                     ` Stephen Warren
2013-11-05  8:22                     ` Arnd Bergmann
2013-11-05  8:22                       ` Arnd Bergmann
2013-11-06 12:17                   ` Thierry Reding
2013-11-06 12:17                     ` Thierry Reding
2013-11-04 14:28           ` David Gibson
2013-11-04 14:28             ` David Gibson
2013-11-04 16:42           ` Stephen Warren
2013-11-04 16:42             ` Stephen Warren
2013-10-28 10:17     ` David Gibson
2013-10-28 10:17       ` David Gibson
2013-10-31 21:13       ` Stephen Warren
2013-10-31 21:13         ` Stephen Warren
2013-11-01 13:24         ` David Gibson
2013-11-01 13:24           ` David Gibson
2013-10-25 23:29 ` David Gibson
2013-10-25 23:29   ` David Gibson
2013-10-31 21:11   ` Stephen Warren
2013-10-31 21:11     ` Stephen Warren
2013-11-10 11:00     ` David Gibson
2013-11-10 11:00       ` David Gibson
2013-11-12 22:06       ` Stephen Warren
2013-11-12 22:06         ` Stephen Warren
2013-11-13  0:33         ` David Gibson
2013-11-13  0:33           ` David Gibson

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=20131105203659.GA26576@obsidianresearch.com \
    --to=jgunthorpe@obsidianresearch.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.