On 06/11/2014 10:19 AM, Peter De Schrijver wrote:

On Wed, Jun 11, 2014 at 05:58:28PM +0200, Stephen Warren wrote:

quoted

On 06/11/2014 09:25 AM, Peter De Schrijver wrote:

quoted

On Wed, Jun 11, 2014 at 02:47:31PM +0200, Mikko Perttunen wrote:

quoted

On 05/06/14 16:09, Peter De Schrijver wrote:
...

quoted

+int tegra_fuse_readl(u32 offset, u32 *val)
+{
+       if (!fuse_readl)
+               return -ENXIO;
+
+       *val = fuse_readl(offset);
+
+       return 0;
+}
+

-EPROBE_DEFER would be a better error value, so that drivers can work 

Ok.

quoted

even if they are initially probed before the fuse driver. Of course, if 
the fuse initialization is moved into machine init then this is a non-issue.

The exported function will always be initialized later because on Tegra20 it
requires APB DMA to be available. If you read the fuses directly, the system
sometimes hangs.

That's not true in the current code. IIRC, the bug was that *if* an APB
DMA access to anything and a CPU access to the fuses happen at the same
time, then there can be a hang. As such, the current fuse code accesses
the fuses directly (without potential for a hang) if the APB DMA driver
is not available, but once the driver becomes available, it reads the
fuses through DMA instead. Does the new code not do that?

I'm not so sure about that. I have seen the hang when dumping all fuses using
sysfs in an otherwise idle system booted from initrd. I don't think there
should be any APB DMA activity going on then?

Hmm. Perhaps I'm misremembering the trigger for the bug then. Still, the
existing code works as I described. Perhaps that's dangerous and it
shouldn't though. Either way, I think we should have a standalone commit
that removes tegra_apb_readl_using_dma()'s fallback to
tegra_apb_readl_direct(), so any behaviour change that causes a problem
can be bisected easily.