On Tue, May 29, 2012 at 09:51:09AM +0200, Jan Kiszka wrote: > On 2012-05-28 15:39, Michael S. Tsirkin wrote: > > On Mon, May 28, 2012 at 03:29:58PM +0200, Jan Kiszka wrote: > >> On 2012-05-28 15:21, Michael S. Tsirkin wrote: > >>> On Mon, May 28, 2012 at 02:51:25PM +0200, Jan Kiszka wrote: > >>>> On 2012-05-28 14:39, Michael S. Tsirkin wrote: > >>>>> On Fri, May 25, 2012 at 11:02:13AM -0300, Jan Kiszka wrote: > >>>>>> According to Alexey, the T310 does not properly support INTx masking as > >>>>>> it fails to keep the PCI_STATUS_INTERRUPT bit updated once the interrupt > >>>>>> is masked. Mark this adapter as broken so that pci_intx_mask_supported > >>>>>> won't report it as compatible. > >>>>>> > >>>>>> Reported-by: Alexey Kardashevskiy <aik@xxxxxxxxx> > >>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@xxxxxx> > >>>>> > >>>>> > >>>>> Just a thought: would be nice to have a way to discover > >>>>> the quirk was activated. Add an attribute so that > >>>>> userspace can detect and report this properly to users? > >>>>> Or just log a warning message ... > >>>> > >>>> pr_notice_once? > >>> > >>> OK IMO. > >>> > >>>> A flag for userspace would be significantly more > >>>> complicated (and not PCI layer hands). > >>> > >>> Why not? I meant e.g. an attribute in pci-sysfs. > >> > >> Possible. But what is the preferred way of doing this? Are there any > >> precedences? > >> > >> Jan > >> > > > > E.g. a reset attribute is there only if device reset is supported. > > I don't insist on this - merely asking how does userspace report > > an attempt to share IRQs and whether the reason is > > discoverable in some way. > > Well, so far there is no attribute associated with INTx masking that we > could hide to express this. > > Jan Thinking about it some more, userspace using this functionality is pretty recent. So if we just teach it to report 'intx mask or status bit unsupported' on failure, plus add pr_notice as you suggested, then that's probably enough. > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
