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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 22 Mar 2017 17:39:16 +0100
From:   Anatolij Gustschin <agust@...x.de>
To:     matthew.gerlach@...ux.intel.com
Cc:     atull@...nel.org, moritz.fischer@...us.com,
        linux-fpga@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, robh+dt@...nel.org,
        mark.rutland@....com
Subject: Re: [PATCH v5 2/4] fpga pr ip: Core driver support for Altera
 Partial Reconfiguration IP.

Hi Matthew,

On Wed, 22 Mar 2017 09:08:18 -0700 (PDT)
matthew.gerlach@...ux.intel.com matthew.gerlach@...ux.intel.com wrote:
...
>> Can we also add a function for registering a PCIe device with
>> PR IP here? Something like:  
>
>If we have an alt_pr_pcie_register function, we will need the 
>corresponding alt_pr_pcie_unregister function.  Both of these functions 
>should go into their own file like alt_pr_platform_probe() and 
>alt_pr_platform_remove().

Okay, thanks.

>> /**
>> * alt_pr_pcie_register - register PCIe device with PR-IP core
>> * @pci_dev:    PCI device with PR-IP
>> * @bar:        PR-IP BAR number
>> * @pr_offset:  offset of the PR-IP core registers
>> *
>> * Return: 0 on success, negative error code otherwise.
>> *
>> * To unregister the PCIe device, use alt_pr_unregister(&pdev->dev).
>> */
>> int alt_pr_pcie_register(struct pci_dev *pdev, int bar, int pr_offset)
>> {
>>        void __iomem *base;
>>        int ret;
>>
>>        if (!pci_is_enabled(pdev)) {
>>                ret = pci_enable_device(pdev);
>>                if (ret < 0) {
>>                        dev_err(&pdev->dev, "can't enable device: %d\n", ret);
>>                        return ret;
>>                }
>>        }
>>
>>        base = devm_ioremap_resource(&pdev->dev, &pdev->resource[bar]);  
>
>Does this remap the whole bar?  If it does, what happens if other 
>components are also connected to the bar?  How do those corresponding 
>drivers get access to the mapped memory?

yes, it remaps the whole bar. I do not know the details of the PR IP,
my assumption was that PR IP it is only one component in the bar.
Then I could use devm_ioremap() instead. Thanks for the hint!

Anatolij

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ