Jason Gunthorpe <[email protected]> wrote on 01/25/2016
01:10:46 PM:
>
> On Fri, Jan 22, 2016 at 10:09:16AM -0500, Stefan Berger wrote:
> >
> > Thanks for all feedback. I will eventually post v2. For now it's to be
found
> > here:
> >
> > https://github.com/stefanberger/linux
> >
> > The branch is easy to find.
>
> That looks much nicer, yes.
>
> I'd also merge the tpm-vtpm.h into the .c file
Ok, I can do that.
>
> However, I'm still not sure this is right:
>
> + vtpm_dev->chip = tpmm_chip_alloc(&vtpm_dev->dev, &vtpm_tpm_ops);
>
> The only issue is error unwind, the tpmm version assumes devm works
> for that, but the vtpm_dev will not be destroyed if the tpm attach
> fails, do devm is not appropriate.
>
> As I said before the tpmm stuff was a hack I did to make it easier to
> migrate the large number of drivers, core code should not be relying
> on devm like that... One good option here would be unwind that a bit
> and create a tpm_chip_alloc/tpm_chip_register flow that did not use
> devm at all. That could be fairly straight forward..
>
> Also, what is up with the _vtpm prefix on some functions? That doesn't
> seem aligned with the kernel style..
Renamed them.
>
> And confused why there is a miscdev and a alloc_chrdev_region ?
miscdev = /dev/vtpmx - that should be ok, no ?
So, I just removed alloc_chrdev_region and with that the assignment of a
major+minor to the virtual device. This works fine on device creation but
on device destruction something odd happens in sysfs.
With two 'vtpmctrl' test programs running sysfs looks like this:
# find /sys/devices/virtual/vtpm/
/sys/devices/virtual/vtpm/
/sys/devices/virtual/vtpm/vtpms0
/sys/devices/virtual/vtpm/vtpms0/dev
/sys/devices/virtual/vtpm/vtpms0/durations
...
/sys/devices/virtual/vtpm/vtpms0/tpm0
/sys/devices/virtual/vtpm/vtpms0/tpm0/dev
...
/sys/devices/virtual/vtpm/vtpms1
/sys/devices/virtual/vtpm/vtpms1/dev
/sys/devices/virtual/vtpm/vtpms1/durations
...
/sys/devices/virtual/vtpm/vtpms1/tpm1
/sys/devices/virtual/vtpm/vtpms1/tpm1/dev
...
/sys/devices/virtual/vtpm/vtpms1/tpm1/power
/sys/devices/virtual/vtpm/vtpms1/tpm1/power/control
Now one of the test process 'vtpmctrl' terminates:
/sys/devices/virtual/vtpm/
/sys/devices/virtual/vtpm/vtpms1
/sys/devices/virtual/vtpm/vtpms1/power
/sys/devices/virtual/vtpm/vtpms1/power/control
/sys/devices/virtual/vtpm/vtpms1/power/async
/sys/devices/virtual/vtpm/vtpms1/power/runtime_enabled
/sys/devices/virtual/vtpm/vtpms1/power/runtime_active_kids
/sys/devices/virtual/vtpm/vtpms1/power/runtime_active_time
/sys/devices/virtual/vtpm/vtpms1/power/autosuspend_delay_ms
/sys/devices/virtual/vtpm/vtpms1/power/runtime_status
/sys/devices/virtual/vtpm/vtpms1/power/runtime_usage
/sys/devices/virtual/vtpm/vtpms1/power/runtime_suspended_time
/sys/devices/virtual/vtpm/vtpms1/subsystem
/sys/devices/virtual/vtpm/vtpms1/uevent
That's all that is left now. .../vtpms1/tpm1/ has also already
disappeared. Needless to say, the kernel is very unhappy once the other
vtpmctrl terminates.
The virtual device needs a major/minor as well. Are there any other
possible solutions?
Stefan
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
tpmdd-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
