lkml.org 
[lkml]   [2020]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()
    From
    Date
    Hi Marc,

    >> Right, I did consider this.
    >
    > FWIW, I've pushed my hack branch[1]

    Did you miss that reference?

    > out with a couple of patches
    > for you to try (the top 3 patches). They allow platform-MSI domains
    > created by devices (mbigen, ICU) to be advertised as shared between
    > devices, so that the low-level driver can handle that in an appropriate
    > way.
    >
    > I gave it a go on my D05 and nothing blew up, but I can't really remove
    > the kernel module, as that's where my disks are... :-/

    You still should be able to enable my favorite
    CONFIG_DEBUG_TEST_DRIVER_REMOVE=y, while the distro still boot. But I'll
    just test if you want.

    > Please let me know if that helps.
    >
    >>> It is just that passing that information down isn't a simple affair,
    >>> as msi_alloc_info_t isn't a generic type... Let me have a think.
    >>
    >> I think that there is a way to circumvent the problem, which you might
    >> call hacky, but OTOH, not sure if there's much point changing mbigen
    >> or related infrastructure at this stage.
    >
    > Bah, it's a simple change, and there is now more than the mbigen using
    > the same API...
    >
    >>
    >> Anyway, so we have 128 irqs in total for the mbigen domain, but the
    >> driver only is interesting in something like irq indexes 1,2,72-81,
    >> and 96-112. So we can just dispose the mappings for irq index 0-112 at
    >> removal stage, thereby keeping the its device around. We do still call
    >> platform_irq_count(), which sets up all 128 mappings, so maybe we
    >> should be unmapping all of these - this would be the contentious part.
    >> But maybe not, as the device driver is only interested in that subset,
    >> and has no business unmapping the rest.
    >
    > I don't think the driver should mess with interrupts it doesn't own.

    I would tend to agree. But all 128 lines here are for the SAS
    controller. It's quite strange, as only about ~20 are useful.

    > And while the mbigen port that is connected to the SAS controller
    > doesn't seem to be shared between endpoints, some other ports definitely
    > are:
    >
    > # cat /sys/kernel/debug/irq/domains/\\_SB.MBI1
    > name:   \_SB.MBI1
    >  size:   409
    >  mapped: 192
    >  flags:  0x00000003
    >
    > [...]
    >
    > I guess that the other 217 lines are connected somewhere.
    >

    I think that is not the right one. See
    https://github.com/tianocore/edk2-platforms/blob/master/Silicon/Hisilicon/Hi1616/D05AcpiTables/Dsdt/D05Sas.asl#L101


    Thanks,
    John

    \
     
     \ /
      Last update: 2020-11-26 11:49    [W:2.438 / U:0.584 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site