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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 4 Dec 2013 11:05:50 -0700
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Jagan Teki <jagannadh.teki@...il.com>
Cc:	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Need help on Linux PCIe

On Wed, Dec 4, 2013 at 10:00 AM, Jagan Teki <jagannadh.teki@...il.com> wrote:
> On Wed, Dec 4, 2013 at 8:41 PM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
>> On Tue, Dec 3, 2013 at 11:20 PM, Jagan Teki <jagannadh.teki@...il.com> wrote:
>>> Thanks for your quick response.
>>> Please find my comments below.
>>>
>>> On Tue, Dec 3, 2013 at 11:09 PM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
>>>> On Tue, Dec 3, 2013 at 4:24 AM, Jagan Teki <jagannadh.teki@...il.com> wrote:
>>>>> Hi,
>>>>>
>>>>> I have few question on Linux PCIe subsystem, I am trying to understand
>>>>> the PCIe on ARM platform.
>>>>> 1. Compared to PCI, PCIe have an extra port functionalists/services
>>>>> which is implemented drivers/pci/pcie/* is it true?
>>>>
>>>> Yes.
>>>>
>>>>> 2. PCIe root complex is same as Host controller drivers in linux drivers/host/*
>>>>
>>>> Yes.
>>>>
>>>>> 3. As individual endpoint drivers are registered to pci_core as
>>>>> pci_driver_register, then what is the common call for registering
>>>>> individual HC driver to pci-core?
>>>>
>>>> The host controller-PCI core interface is not as mature as the
>>>> pci_register_driver() interface.  The basic interface is
>>>> pci_scan_root_bus().  If you skim through the drivers in
>>>> drivers/pci/host/* and drivers/acpi/pci_root.c, the interface to the
>>>> PCI core will be fairly obvious.  And you'll learn what the existing
>>>> practices are in case you need to add or modify something.
>>>
>>> OK.
>>>
>>> I understand the flow as below - please correct if am wrong.
>>>
>>> From low level (hw) - HC driver has a platform registration using
>>> platform_driver_register() to lower layer
>>> and then pci_scan_root_bus() --> pci_common_init_dev() registration to
>>> upper layer as PCI - BIOS and then ends.
>>
>> Yes.  Sometime HC drivers use platform_driver_register(); other use
>> something else depending on how the HC device is enumerated.  For
>> example, drivers/acpi/pci_root.c uses something else to deal with host
>> bridges in the ACPI namespace.
>>
>>> From upper level (app) - each endpoint driver has
>>> pci_driver_register() call to PCI Core for lower level
>>
>> Yes.
>>
>>> and then the upper level registration is based on endpoint().
>>
>> I don't know what you mean here (I don't know of a function named
>> "endpoint()").  But the driver model matches drivers to PCI functions
>> based on vendor and device IDs.  A Linux "pci_dev" is what the PCI
>> specs refer to as a "function."
> Sorry it's typo - added ()
>
>>
>>> What is the connection here for PCI-BIOS and PCI-Core here, does these
>>> are two different entities means there is no common call for these?
>>> I see for ARM - "arch/arm/kernel/bios32.c" is PCI-BIOS is it correct?
>>> does we have separate BIOS codes for architectures?
>>
>> The "pcibios_*" functions are architecture-specific things called by
>> the generic PCI core.  Generally, things specified by the PCI specs
>> are architecture-independent and should be in the PCI core
>> (drivers/pci/*).
>
> I have some good information to discuss from this thread.
> Can you please verify this Linux PCIe subsystem stack - comment
> whether my understanding is correct/not.
> (I just draw this based on driver calls flow - to accommodate with in
> the Linux cores)
> http://jagannadhteki.blog.com/2013/12/04/linux-pcie-subsystem/

Yes, that makes sense.  I wouldn't label the PCIBIOS - PCI core link
as "pci_bus_add_device()"; pci_bus_add_device() is part of the PCI
core's generic enumeration code and shouldn't be called by
arch-specific code.  The link going from PCI core to PCIBIOS is the
set of "pcibios_*()" functions.  Going from PCIBIOS to the PCI core,
it's mostly just pci_scan_root_bus().

I also probably wouldn't put in links between VFS and AER, HP, PME,
and VC.  It's true that there are some sysfs files that influence the
operation of those PCIe features, but mostly for debugging and
administration.  They aren't something useful to ordinary user
programs.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ