Re: Broken pci_block_user_cfg_access interface

[Michael S. Tsirkin]

On Mon, Aug 29, 2011 at 08:47:07PM +0200, Jan Kiszka wrote:
> On 2011-08-29 17:42, Jan Kiszka wrote:
> > I still don't get what prevents converting ipr to allow plain mutex
> > synchronization. My vision is:
> >  - push reset-on-error of ipr into workqueue (or threaded IRQ?)
> 
> I'm starting to like your proposal: I had a look at ipr, but it turned
> out to be anything but trivial to convert that driver. It runs its
> complete state machine under spin_lock_irq, and the functions calling
> pci_block/unblock_user_cfg_access are deep inside this thing. I have no
> hardware to test whatever change, and I feel a bit uncomfortable asking
> Brian to redesign his driver that massively.
> 
> So back to your idea: I would generalize pci_block_user_cfg_access to
> pci_block_cfg_access. It should fail when some other site already holds
> the access lock, but it should remain non-blocking - for the sake of ipr.

It would be easy to have blocking and non-blocking variants.

But
- I have no idea whether supporting sysfs config/reset access
  while ipr is active makes any sense - I know we need it for uio.
- reset while uio handles interrupt needs to block, not fail I think


> We should still provide generic pci-2.3 IRQ masking services, but that
> could be done in a second step. I could have a look at this.
> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/