On Tue, Jul 08, 2014 at 02:11:36AM +0100, Bjorn Helgaas wrote:
> On Fri, Jul 4, 2014 at 8:57 AM, Liviu Dudau wrote:
> > On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn Helgaas wrote:
> >> On Mon, Apr 7, 2014 at 4:07 AM, Liviu Dudau wrote:
> >> > On Mon, Apr 07, 2014 at 10:14:18AM +0100, Benjamin
On Tue, Jul 08, 2014 at 02:11:36AM +0100, Bjorn Helgaas wrote:
On Fri, Jul 4, 2014 at 8:57 AM, Liviu Dudau liviu.du...@arm.com wrote:
On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn Helgaas wrote:
On Mon, Apr 7, 2014 at 4:07 AM, Liviu Dudau liviu.du...@arm.com wrote:
On Mon, Apr 07, 2014
On Fri, Jul 4, 2014 at 8:57 AM, Liviu Dudau wrote:
> On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn Helgaas wrote:
>> On Mon, Apr 7, 2014 at 4:07 AM, Liviu Dudau wrote:
>> > On Mon, Apr 07, 2014 at 10:14:18AM +0100, Benjamin Herrenschmidt wrote:
>> >> On Mon, 2014-04-07 at 09:46 +0100, Liviu
On Fri, Jul 4, 2014 at 8:57 AM, Liviu Dudau liviu.du...@arm.com wrote:
On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn Helgaas wrote:
On Mon, Apr 7, 2014 at 4:07 AM, Liviu Dudau liviu.du...@arm.com wrote:
On Mon, Apr 07, 2014 at 10:14:18AM +0100, Benjamin Herrenschmidt wrote:
On Mon,
On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn Helgaas wrote:
> On Mon, Apr 7, 2014 at 4:07 AM, Liviu Dudau wrote:
> > On Mon, Apr 07, 2014 at 10:14:18AM +0100, Benjamin Herrenschmidt wrote:
> >> On Mon, 2014-04-07 at 09:46 +0100, Liviu Dudau wrote:
> >> >
> >> > *My* strategy is to get rid of
On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn Helgaas wrote:
On Mon, Apr 7, 2014 at 4:07 AM, Liviu Dudau liviu.du...@arm.com wrote:
On Mon, Apr 07, 2014 at 10:14:18AM +0100, Benjamin Herrenschmidt wrote:
On Mon, 2014-04-07 at 09:46 +0100, Liviu Dudau wrote:
*My* strategy is to get rid
On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn Helgaas wrote:
> On Mon, Apr 7, 2014 at 4:07 AM, Liviu Dudau wrote:
> > On Mon, Apr 07, 2014 at 10:14:18AM +0100, Benjamin Herrenschmidt wrote:
> >> On Mon, 2014-04-07 at 09:46 +0100, Liviu Dudau wrote:
> >> >
> >> > *My* strategy is to get rid of
On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn Helgaas wrote:
On Mon, Apr 7, 2014 at 4:07 AM, Liviu Dudau liviu.du...@arm.com wrote:
On Mon, Apr 07, 2014 at 10:14:18AM +0100, Benjamin Herrenschmidt wrote:
On Mon, 2014-04-07 at 09:46 +0100, Liviu Dudau wrote:
*My* strategy is to get rid
On Friday 11 April 2014 10:22:25 Liviu Dudau wrote:
> On Thu, Apr 10, 2014 at 09:46:36PM +0100, Arnd Bergmann wrote:
> > On Thursday 10 April 2014 15:53:04 Liviu Dudau wrote:
> > > So Arnd seems to agree with me: we should try to get out of architecture
> > > specific
> > > pci_sys_data and link
On Thu, Apr 10, 2014 at 09:46:36PM +0100, Arnd Bergmann wrote:
> On Thursday 10 April 2014 15:53:04 Liviu Dudau wrote:
> > On Thu, Apr 10, 2014 at 03:07:44PM +0100, Arnd Bergmann wrote:
>
> > > This mirrors how we treat devices: a pci_device has an embedded device,
> > > and so on, in other
On Fri, 2014-04-11 at 10:36 +0200, Arnd Bergmann wrote:
> > EEH is one big nasty example on powerpc.
> >
> > Another random one that happens to be hot in my brain right now because
> > we just finished debugging it: On powernv, we are just fixing a series
> > of bugs caused by the generic code
On Friday 11 April 2014 15:01:09 Benjamin Herrenschmidt wrote:
> On Thu, 2014-04-10 at 22:46 +0200, Arnd Bergmann wrote:
>
> > Half of it ;-)
> >
> > I think it would be better to not have an architecture specific data
> > structure, just like it would be better not to have architecture specific
On Friday 11 April 2014 15:01:09 Benjamin Herrenschmidt wrote:
On Thu, 2014-04-10 at 22:46 +0200, Arnd Bergmann wrote:
Half of it ;-)
I think it would be better to not have an architecture specific data
structure, just like it would be better not to have architecture specific
On Fri, 2014-04-11 at 10:36 +0200, Arnd Bergmann wrote:
EEH is one big nasty example on powerpc.
Another random one that happens to be hot in my brain right now because
we just finished debugging it: On powernv, we are just fixing a series
of bugs caused by the generic code trying to
On Thu, Apr 10, 2014 at 09:46:36PM +0100, Arnd Bergmann wrote:
On Thursday 10 April 2014 15:53:04 Liviu Dudau wrote:
On Thu, Apr 10, 2014 at 03:07:44PM +0100, Arnd Bergmann wrote:
This mirrors how we treat devices: a pci_device has an embedded device,
and so on, in other subsystems we
On Friday 11 April 2014 10:22:25 Liviu Dudau wrote:
On Thu, Apr 10, 2014 at 09:46:36PM +0100, Arnd Bergmann wrote:
On Thursday 10 April 2014 15:53:04 Liviu Dudau wrote:
So Arnd seems to agree with me: we should try to get out of architecture
specific
pci_sys_data and link the host
On Thu, 2014-04-10 at 22:46 +0200, Arnd Bergmann wrote:
> Half of it ;-)
>
> I think it would be better to not have an architecture specific data
> structure, just like it would be better not to have architecture specific
> pcibios_* functions that get called by the PCI core. Note that the
>
On Thursday 10 April 2014 15:53:04 Liviu Dudau wrote:
> On Thu, Apr 10, 2014 at 03:07:44PM +0100, Arnd Bergmann wrote:
> > This mirrors how we treat devices: a pci_device has an embedded device,
> > and so on, in other subsystems we can have multiple layers.
> >
> > In this example, the tegra
On Thu, Apr 10, 2014 at 03:07:44PM +0100, Arnd Bergmann wrote:
> On Thursday 10 April 2014 07:50:52 Bjorn Helgaas wrote:
> > On Thu, Apr 10, 2014 at 2:00 AM, Arnd Bergmann wrote:
> > > On Wednesday 09 April 2014 21:48:14 Bjorn Helgaas wrote:
> > >> On Wed, Apr 9, 2014 at 7:27 PM, Liviu Dudau
On Thursday 10 April 2014 07:50:52 Bjorn Helgaas wrote:
> On Thu, Apr 10, 2014 at 2:00 AM, Arnd Bergmann wrote:
> > On Wednesday 09 April 2014 21:48:14 Bjorn Helgaas wrote:
> >> On Wed, Apr 9, 2014 at 7:27 PM, Liviu Dudau wrote:
> >> > On Wed, Apr 09, 2014 at 08:02:41AM -0600, Bjorn Helgaas
On Thu, Apr 10, 2014 at 2:00 AM, Arnd Bergmann wrote:
> On Wednesday 09 April 2014 21:48:14 Bjorn Helgaas wrote:
>> On Wed, Apr 9, 2014 at 7:27 PM, Liviu Dudau wrote:
>> > On Wed, Apr 09, 2014 at 08:02:41AM -0600, Bjorn Helgaas wrote:
>> >> >> struct pci_host_bridge {
>> >> >> int domain;
On Wednesday 09 April 2014 21:48:14 Bjorn Helgaas wrote:
> On Wed, Apr 9, 2014 at 7:27 PM, Liviu Dudau wrote:
> > On Wed, Apr 09, 2014 at 08:02:41AM -0600, Bjorn Helgaas wrote:
> >> >> struct pci_host_bridge {
> >> >> int domain;
> >> >> int node;
> >> >> struct device *dev;
> >> >>
On Wednesday 09 April 2014 21:48:14 Bjorn Helgaas wrote:
On Wed, Apr 9, 2014 at 7:27 PM, Liviu Dudau li...@dudau.co.uk wrote:
On Wed, Apr 09, 2014 at 08:02:41AM -0600, Bjorn Helgaas wrote:
struct pci_host_bridge {
int domain;
int node;
struct device *dev;
struct
On Thu, Apr 10, 2014 at 2:00 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 09 April 2014 21:48:14 Bjorn Helgaas wrote:
On Wed, Apr 9, 2014 at 7:27 PM, Liviu Dudau li...@dudau.co.uk wrote:
On Wed, Apr 09, 2014 at 08:02:41AM -0600, Bjorn Helgaas wrote:
struct pci_host_bridge {
On Thursday 10 April 2014 07:50:52 Bjorn Helgaas wrote:
On Thu, Apr 10, 2014 at 2:00 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 09 April 2014 21:48:14 Bjorn Helgaas wrote:
On Wed, Apr 9, 2014 at 7:27 PM, Liviu Dudau li...@dudau.co.uk wrote:
On Wed, Apr 09, 2014 at 08:02:41AM
On Thu, Apr 10, 2014 at 03:07:44PM +0100, Arnd Bergmann wrote:
On Thursday 10 April 2014 07:50:52 Bjorn Helgaas wrote:
On Thu, Apr 10, 2014 at 2:00 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 09 April 2014 21:48:14 Bjorn Helgaas wrote:
On Wed, Apr 9, 2014 at 7:27 PM, Liviu Dudau
On Thursday 10 April 2014 15:53:04 Liviu Dudau wrote:
On Thu, Apr 10, 2014 at 03:07:44PM +0100, Arnd Bergmann wrote:
This mirrors how we treat devices: a pci_device has an embedded device,
and so on, in other subsystems we can have multiple layers.
In this example, the tegra pcie driver
On Thu, 2014-04-10 at 22:46 +0200, Arnd Bergmann wrote:
Half of it ;-)
I think it would be better to not have an architecture specific data
structure, just like it would be better not to have architecture specific
pcibios_* functions that get called by the PCI core. Note that the
On Wed, Apr 9, 2014 at 7:27 PM, Liviu Dudau wrote:
> On Wed, Apr 09, 2014 at 08:02:41AM -0600, Bjorn Helgaas wrote:
>> On Wed, Apr 9, 2014 at 6:07 AM, Liviu Dudau wrote:
>> > On Tue, Apr 08, 2014 at 05:28:39PM +0100, Bjorn Helgaas wrote:
>> >> On Tue, Apr 8, 2014 at 4:20 AM, Liviu Dudau wrote:
On Wed, Apr 09, 2014 at 08:02:41AM -0600, Bjorn Helgaas wrote:
> On Wed, Apr 9, 2014 at 6:07 AM, Liviu Dudau wrote:
> > On Tue, Apr 08, 2014 at 05:28:39PM +0100, Bjorn Helgaas wrote:
> >> On Tue, Apr 8, 2014 at 4:20 AM, Liviu Dudau wrote:
> >> > On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn
On Wed, 2014-04-09 at 08:02 -0600, Bjorn Helgaas wrote:
> It's possible we could manage domain numbers in the core. On ACPI
> systems, we currently we use the ACPI _SEG value as the domain. In
> some cases, e.g., on ia64, config space access is done via firmware
> interfaces, and those
On Wednesday 09 April 2014 08:02:41 Bjorn Helgaas wrote:
>
> It's possible we could manage domain numbers in the core. On ACPI
> systems, we currently we use the ACPI _SEG value as the domain. In
> some cases, e.g., on ia64, config space access is done via firmware
> interfaces, and those
On Wed, Apr 9, 2014 at 6:07 AM, Liviu Dudau wrote:
> On Tue, Apr 08, 2014 at 05:28:39PM +0100, Bjorn Helgaas wrote:
>> On Tue, Apr 8, 2014 at 4:20 AM, Liviu Dudau wrote:
>> > On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn Helgaas wrote:
>>
>> >> Let me try to explain my concern about the
>> >>
On Tue, Apr 08, 2014 at 05:28:39PM +0100, Bjorn Helgaas wrote:
> On Tue, Apr 8, 2014 at 4:20 AM, Liviu Dudau wrote:
> > On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn Helgaas wrote:
>
> >> Let me try to explain my concern about the
> >> pci_create_root_bus_in_domain() interface. We currently
On Tue, Apr 08, 2014 at 05:28:39PM +0100, Bjorn Helgaas wrote:
On Tue, Apr 8, 2014 at 4:20 AM, Liviu Dudau liviu.du...@arm.com wrote:
On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn Helgaas wrote:
Let me try to explain my concern about the
pci_create_root_bus_in_domain() interface. We
On Wed, Apr 9, 2014 at 6:07 AM, Liviu Dudau liviu.du...@arm.com wrote:
On Tue, Apr 08, 2014 at 05:28:39PM +0100, Bjorn Helgaas wrote:
On Tue, Apr 8, 2014 at 4:20 AM, Liviu Dudau liviu.du...@arm.com wrote:
On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn Helgaas wrote:
Let me try to explain
On Wednesday 09 April 2014 08:02:41 Bjorn Helgaas wrote:
It's possible we could manage domain numbers in the core. On ACPI
systems, we currently we use the ACPI _SEG value as the domain. In
some cases, e.g., on ia64, config space access is done via firmware
interfaces, and those interfaces
On Wed, 2014-04-09 at 08:02 -0600, Bjorn Helgaas wrote:
It's possible we could manage domain numbers in the core. On ACPI
systems, we currently we use the ACPI _SEG value as the domain. In
some cases, e.g., on ia64, config space access is done via firmware
interfaces, and those interfaces
On Wed, Apr 09, 2014 at 08:02:41AM -0600, Bjorn Helgaas wrote:
On Wed, Apr 9, 2014 at 6:07 AM, Liviu Dudau liviu.du...@arm.com wrote:
On Tue, Apr 08, 2014 at 05:28:39PM +0100, Bjorn Helgaas wrote:
On Tue, Apr 8, 2014 at 4:20 AM, Liviu Dudau liviu.du...@arm.com wrote:
On Mon, Apr 07, 2014
On Wed, Apr 9, 2014 at 7:27 PM, Liviu Dudau li...@dudau.co.uk wrote:
On Wed, Apr 09, 2014 at 08:02:41AM -0600, Bjorn Helgaas wrote:
On Wed, Apr 9, 2014 at 6:07 AM, Liviu Dudau liviu.du...@arm.com wrote:
On Tue, Apr 08, 2014 at 05:28:39PM +0100, Bjorn Helgaas wrote:
On Tue, Apr 8, 2014 at
On Tue, Apr 8, 2014 at 4:20 AM, Liviu Dudau wrote:
> On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn Helgaas wrote:
>> Let me try to explain my concern about the
>> pci_create_root_bus_in_domain() interface. We currently have these
>> interfaces:
>>
>> pci_scan_root_bus()
>> pci_scan_bus()
On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn Helgaas wrote:
> On Mon, Apr 7, 2014 at 4:07 AM, Liviu Dudau wrote:
> > On Mon, Apr 07, 2014 at 10:14:18AM +0100, Benjamin Herrenschmidt wrote:
> >> On Mon, 2014-04-07 at 09:46 +0100, Liviu Dudau wrote:
> >> >
> >> > *My* strategy is to get rid of
On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn Helgaas wrote:
On Mon, Apr 7, 2014 at 4:07 AM, Liviu Dudau liviu.du...@arm.com wrote:
On Mon, Apr 07, 2014 at 10:14:18AM +0100, Benjamin Herrenschmidt wrote:
On Mon, 2014-04-07 at 09:46 +0100, Liviu Dudau wrote:
*My* strategy is to get rid
On Tue, Apr 8, 2014 at 4:20 AM, Liviu Dudau liviu.du...@arm.com wrote:
On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn Helgaas wrote:
Let me try to explain my concern about the
pci_create_root_bus_in_domain() interface. We currently have these
interfaces:
pci_scan_root_bus()
On Mon, Apr 7, 2014 at 4:07 AM, Liviu Dudau wrote:
> On Mon, Apr 07, 2014 at 10:14:18AM +0100, Benjamin Herrenschmidt wrote:
>> On Mon, 2014-04-07 at 09:46 +0100, Liviu Dudau wrote:
>> >
>> > *My* strategy is to get rid of pci_domain_nr(). I don't see why we need
>> > to have arch specific way of
On Mon, Apr 07, 2014 at 10:14:18AM +0100, Benjamin Herrenschmidt wrote:
> On Mon, 2014-04-07 at 09:46 +0100, Liviu Dudau wrote:
> >
> > *My* strategy is to get rid of pci_domain_nr(). I don't see why we need
> > to have arch specific way of providing the number, specially after looking
> > at the
On Mon, 2014-04-07 at 09:46 +0100, Liviu Dudau wrote:
>
> *My* strategy is to get rid of pci_domain_nr(). I don't see why we need
> to have arch specific way of providing the number, specially after looking
> at the existing implementations that return a value from a variable that
> is never
On Sat, Apr 05, 2014 at 01:00:07AM +0100, Bjorn Helgaas wrote:
> On Fri, Mar 14, 2014 at 03:34:30PM +, Liviu Dudau wrote:
> > Make it easier to discover the domain number of a bus by storing
> > the number in pci_host_bridge for the root bus. Several architectures
> > have their own way of
On Sat, Apr 05, 2014 at 01:00:07AM +0100, Bjorn Helgaas wrote:
On Fri, Mar 14, 2014 at 03:34:30PM +, Liviu Dudau wrote:
Make it easier to discover the domain number of a bus by storing
the number in pci_host_bridge for the root bus. Several architectures
have their own way of storing
On Mon, 2014-04-07 at 09:46 +0100, Liviu Dudau wrote:
*My* strategy is to get rid of pci_domain_nr(). I don't see why we need
to have arch specific way of providing the number, specially after looking
at the existing implementations that return a value from a variable that
is never touched
On Mon, Apr 07, 2014 at 10:14:18AM +0100, Benjamin Herrenschmidt wrote:
On Mon, 2014-04-07 at 09:46 +0100, Liviu Dudau wrote:
*My* strategy is to get rid of pci_domain_nr(). I don't see why we need
to have arch specific way of providing the number, specially after looking
at the existing
On Mon, Apr 7, 2014 at 4:07 AM, Liviu Dudau liviu.du...@arm.com wrote:
On Mon, Apr 07, 2014 at 10:14:18AM +0100, Benjamin Herrenschmidt wrote:
On Mon, 2014-04-07 at 09:46 +0100, Liviu Dudau wrote:
*My* strategy is to get rid of pci_domain_nr(). I don't see why we need
to have arch specific
On Fri, Mar 14, 2014 at 03:34:30PM +, Liviu Dudau wrote:
> Make it easier to discover the domain number of a bus by storing
> the number in pci_host_bridge for the root bus. Several architectures
> have their own way of storing this information, so it makes sense
> to try to unify the code.
On Fri, Mar 14, 2014 at 03:34:30PM +, Liviu Dudau wrote:
Make it easier to discover the domain number of a bus by storing
the number in pci_host_bridge for the root bus. Several architectures
have their own way of storing this information, so it makes sense
to try to unify the code.
I
Make it easier to discover the domain number of a bus by storing
the number in pci_host_bridge for the root bus. Several architectures
have their own way of storing this information, so it makes sense
to try to unify the code. While at this, add a new function that
creates a root bus in a given
Make it easier to discover the domain number of a bus by storing
the number in pci_host_bridge for the root bus. Several architectures
have their own way of storing this information, so it makes sense
to try to unify the code. While at this, add a new function that
creates a root bus in a given
56 matches
Mail list logo
