lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221013173703.th54drzlafvj74oo@offworld>
Date:   Thu, 13 Oct 2022 10:37:03 -0700
From:   Davidlohr Bueso <dave@...olabs.net>
To:     Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc:     dan.j.williams@...el.com, ira.weiny@...el.com,
        alison.schofield@...el.com, vishal.l.verma@...el.com,
        bwidawsk@...nel.org, a.manzanares@...sung.com,
        linux-kernel@...r.kernel.org, linux-cxl@...r.kernel.org
Subject: Re: [PATCH] cxl: Add generic MSI/MSI-X interrupt support

Thanks for having a look.

On Thu, 13 Oct 2022, Jonathan Cameron wrote:

>> +struct cxl_irq_cap {
>> +	const char *name;
>> +	int (*get_max_msgnum)(struct cxl_dev_state *cxlds);
>
>For the CPMU case I need to walk the register locator dvsec block so need
>the callback to take the pci_dev not the cxl_dev_state.

Hmm ok, however maybe I'm missing something, but given a pdev, do we have a
way to get back to the cxlds?

...

>>  static int cxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>>  {
>>  	struct cxl_register_map map;
>> @@ -498,6 +558,9 @@ static int cxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>>  	if (IS_ERR(cxlmd))
>>  		return PTR_ERR(cxlmd);
>>
>> +	/* TODO: When there are users, this return value must be checked */
>> +	cxl_pci_alloc_irq_vectors(cxlds);
>> +
>
>Gut feeling is this will end up moving ahead of any of the sub device creation
>because many of them end up needing interrupts.
>
>Also check response from the start - can't see a reason to not do so as we
>won't be registering any at all if no callbacks provided.
>
>So I'd move it above the devm_cxl_add_memdev() call.

Will do. In addition, are you ok with grouping the irq setup for each cxl
feature/component, ie:

if (cxl_pci_alloc_irq_vectors(cxlds) > 0) {
    cxl_setup_mbox_irq();
    cxl_setup_events_irq();
    cxl_setup_pmu_irq();
}

I ask mostly from the mailbox perspective, in that we already have
a mbox setup call and can certainly understand if people would prefer
it there, but I tend to prefer the above (logically wrt irqs).

Thanks,
Davidlohr

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ