lkml.org 
[lkml]   [2011]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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.

    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


    \
     
     \ /
      Last update: 2011-08-29 21:21    [from the cache]
    ©2003-2011 Jasper Spaans