[lkml]   [2011]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Broken pci_block_user_cfg_access interface
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.

- 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

 \ /
  Last update: 2011-08-29 21:21    [W:0.088 / U:1.080 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site