Re: [PATCH v2 2/3] tpm_tis: Use devm_ioremap_resource

2015-12-01 Thread Jason Gunthorpe
On Tue, Dec 01, 2015 at 08:52:17PM +0100, Uwe Kleine-König wrote: > The issue I saw is: There are three(?) ways the tpm could be bound. If > one of the succeeds, the other two are expected to fail. But in this > case an error message, that the tpm failed to be bound is at least > misleading. My

Re: [PATCH v2 2/3] tpm_tis: Use devm_ioremap_resource

2015-12-01 Thread Uwe Kleine-König
Hello Jason, On Tue, Dec 01, 2015 at 12:44:19PM -0700, Jason Gunthorpe wrote: > On Tue, Dec 01, 2015 at 08:22:40PM +0100, Uwe Kleine-König wrote: > > > + if (resource_size(_info.res) == 0) > > > + return -ENODEV; > > > + > > > > Does this result in an error message from the upper layers?

Re: [PATCH v2 2/3] tpm_tis: Use devm_ioremap_resource

2015-12-01 Thread Jason Gunthorpe
On Tue, Dec 01, 2015 at 08:22:40PM +0100, Uwe Kleine-König wrote: > here, which IMHO reads nicer and maybe is even more efficient (I don't > know much about x86). Sure > > + if (resource_size(_info.res) == 0) > > + return -ENODEV; > > + > > Does this result in an error message from

Re: [PATCH v2 2/3] tpm_tis: Use devm_ioremap_resource

2015-12-01 Thread Uwe Kleine-König
Hello, On Tue, Dec 01, 2015 at 11:58:28AM -0700, Jason Gunthorpe wrote: > This does a request_resource under the covers which means tis holds a > lock on the memory range it is using so other drivers cannot grab it. > When doing probing it is important to ensure that other drivers are > not using

[PATCH v2 2/3] tpm_tis: Use devm_ioremap_resource

2015-12-01 Thread Jason Gunthorpe
This does a request_resource under the covers which means tis holds a lock on the memory range it is using so other drivers cannot grab it. When doing probing it is important to ensure that other drivers are not using the same range before tis starts touching it. To do this flow the actual struct

Re: [PATCH v2 2/3] tpm_tis: Use devm_ioremap_resource

2015-12-01 Thread Jason Gunthorpe
On Tue, Dec 01, 2015 at 08:52:17PM +0100, Uwe Kleine-König wrote: > The issue I saw is: There are three(?) ways the tpm could be bound. If > one of the succeeds, the other two are expected to fail. But in this > case an error message, that the tpm failed to be bound is at least > misleading. My

[PATCH v2 2/3] tpm_tis: Use devm_ioremap_resource

2015-12-01 Thread Jason Gunthorpe
This does a request_resource under the covers which means tis holds a lock on the memory range it is using so other drivers cannot grab it. When doing probing it is important to ensure that other drivers are not using the same range before tis starts touching it. To do this flow the actual struct

Re: [PATCH v2 2/3] tpm_tis: Use devm_ioremap_resource

2015-12-01 Thread Uwe Kleine-König
Hello, On Tue, Dec 01, 2015 at 11:58:28AM -0700, Jason Gunthorpe wrote: > This does a request_resource under the covers which means tis holds a > lock on the memory range it is using so other drivers cannot grab it. > When doing probing it is important to ensure that other drivers are > not using

Re: [PATCH v2 2/3] tpm_tis: Use devm_ioremap_resource

2015-12-01 Thread Jason Gunthorpe
On Tue, Dec 01, 2015 at 08:22:40PM +0100, Uwe Kleine-König wrote: > here, which IMHO reads nicer and maybe is even more efficient (I don't > know much about x86). Sure > > + if (resource_size(_info.res) == 0) > > + return -ENODEV; > > + > > Does this result in an error message from

Re: [PATCH v2 2/3] tpm_tis: Use devm_ioremap_resource

2015-12-01 Thread Uwe Kleine-König
Hello Jason, On Tue, Dec 01, 2015 at 12:44:19PM -0700, Jason Gunthorpe wrote: > On Tue, Dec 01, 2015 at 08:22:40PM +0100, Uwe Kleine-König wrote: > > > + if (resource_size(_info.res) == 0) > > > + return -ENODEV; > > > + > > > > Does this result in an error message from the upper layers?