On Mon, Jul 16, 2012 at 6:09 PM, Jiang Liu wrote:
> On 07/17/2012 01:29 AM, Bjorn Helgaas wrote:
>> On Sun, Jul 15, 2012 at 10:47 AM, Jiang Liu wrote:
>>> On 07/13/2012 04:49 AM, Bjorn Helgaas wrote:
> Hi Bjorn,
> It's a little risk to change these PCIe capabilities access
>
On 07/17/2012 01:29 AM, Bjorn Helgaas wrote:
> On Sun, Jul 15, 2012 at 10:47 AM, Jiang Liu wrote:
>> On 07/13/2012 04:49 AM, Bjorn Helgaas wrote:
Hi Bjorn,
It's a little risk to change these PCIe capabilities access
functions as void. On some platform with hardware error
On 07/16/2012 01:29 PM, Bjorn Helgaas wrote:
On Sun, Jul 15, 2012 at 10:47 AM, Jiang Liu wrote:
On 07/13/2012 04:49 AM, Bjorn Helgaas wrote:
Hi Bjorn,
It's a little risk to change these PCIe capabilities access
functions as void. On some platform with hardware error
On Sun, Jul 15, 2012 at 10:47 AM, Jiang Liu wrote:
> On 07/13/2012 04:49 AM, Bjorn Helgaas wrote:
>>> Hi Bjorn,
>>> It's a little risk to change these PCIe capabilities access
>>> functions as void. On some platform with hardware error detecting/correcting
>>> capabilities, such as EEH on
On Sun, Jul 15, 2012 at 10:47 AM, Jiang Liu liu...@gmail.com wrote:
On 07/13/2012 04:49 AM, Bjorn Helgaas wrote:
Hi Bjorn,
It's a little risk to change these PCIe capabilities access
functions as void. On some platform with hardware error detecting/correcting
capabilities, such as EEH
On 07/16/2012 01:29 PM, Bjorn Helgaas wrote:
On Sun, Jul 15, 2012 at 10:47 AM, Jiang Liuliu...@gmail.com wrote:
On 07/13/2012 04:49 AM, Bjorn Helgaas wrote:
Hi Bjorn,
It's a little risk to change these PCIe capabilities access
functions as void. On some platform with hardware error
On 07/17/2012 01:29 AM, Bjorn Helgaas wrote:
On Sun, Jul 15, 2012 at 10:47 AM, Jiang Liu liu...@gmail.com wrote:
On 07/13/2012 04:49 AM, Bjorn Helgaas wrote:
Hi Bjorn,
It's a little risk to change these PCIe capabilities access
functions as void. On some platform with hardware error
On Mon, Jul 16, 2012 at 6:09 PM, Jiang Liu liu...@gmail.com wrote:
On 07/17/2012 01:29 AM, Bjorn Helgaas wrote:
On Sun, Jul 15, 2012 at 10:47 AM, Jiang Liu liu...@gmail.com wrote:
On 07/13/2012 04:49 AM, Bjorn Helgaas wrote:
Hi Bjorn,
It's a little risk to change these PCIe
On 07/13/2012 04:49 AM, Bjorn Helgaas wrote:
>> Hi Bjorn,
>> It's a little risk to change these PCIe capabilities access
>> functions as void. On some platform with hardware error detecting/correcting
>> capabilities, such as EEH on Power, it would be better to return
>> error code if
On 07/13/2012 04:49 AM, Bjorn Helgaas wrote:
Hi Bjorn,
It's a little risk to change these PCIe capabilities access
functions as void. On some platform with hardware error detecting/correcting
capabilities, such as EEH on Power, it would be better to return
error code if hardware error
On Wed, Jul 11, 2012 at 8:56 PM, Jiang Liu wrote:
> On 2012-7-12 1:52, Bjorn Helgaas wrote:
>>> Hi Bjorn,
>>> Seems it would be better to return error code for unimplemented
>>> registers, otherwise following code will becomes more complex. A special
>>> error code for unimplemented
On Wed, Jul 11, 2012 at 8:56 PM, Jiang Liu jiang@huawei.com wrote:
On 2012-7-12 1:52, Bjorn Helgaas wrote:
Hi Bjorn,
Seems it would be better to return error code for unimplemented
registers, otherwise following code will becomes more complex. A special
error code for
On 2012-7-12 1:52, Bjorn Helgaas wrote:
>> Hi Bjorn,
>> Seems it would be better to return error code for unimplemented
>> registers, otherwise following code will becomes more complex. A special
>> error code for unimplemented registers, such as -EIO?
>
> I think you're asking about
On Wed, Jul 11, 2012 at 12:40 AM, Jiang Liu wrote:
> On 2012-7-11 11:40, Bjorn Helgaas wrote:
>
>>> Good point. Return success when reading unimplemented registeres, that
>>> may simplify code. For we still should return -EINVAL when writing
>>> unimplemented registers, right?
>>
>> Yeah, I guess
On 2012-7-11 11:40, Bjorn Helgaas wrote:
>> Good point. Return success when reading unimplemented registeres, that
>> may simplify code. For we still should return -EINVAL when writing
>> unimplemented registers, right?
>
> Yeah, I guess it's OK to return -EINVAL when *writing* to an
>
On 2012-7-11 11:40, Bjorn Helgaas wrote:
Good point. Return success when reading unimplemented registeres, that
may simplify code. For we still should return -EINVAL when writing
unimplemented registers, right?
Yeah, I guess it's OK to return -EINVAL when *writing* to an
unimplemented
On Wed, Jul 11, 2012 at 12:40 AM, Jiang Liu jiang@huawei.com wrote:
On 2012-7-11 11:40, Bjorn Helgaas wrote:
Good point. Return success when reading unimplemented registeres, that
may simplify code. For we still should return -EINVAL when writing
unimplemented registers, right?
Yeah, I
On 2012-7-12 1:52, Bjorn Helgaas wrote:
Hi Bjorn,
Seems it would be better to return error code for unimplemented
registers, otherwise following code will becomes more complex. A special
error code for unimplemented registers, such as -EIO?
I think you're asking about returning
On Tue, Jul 10, 2012 at 9:07 PM, Jiang Liu wrote:
> On 2012-7-11 2:35, Bjorn Helgaas wrote:
>>> diff --git a/drivers/pci/access.c b/drivers/pci/access.c
>>> index ba91a7e..80ae022 100644
>>> --- a/drivers/pci/access.c
>>> +++ b/drivers/pci/access.c
>>> @@ -469,3 +469,91 @@ void
On 2012-7-11 2:35, Bjorn Helgaas wrote:
>> diff --git a/drivers/pci/access.c b/drivers/pci/access.c
>> index ba91a7e..80ae022 100644
>> --- a/drivers/pci/access.c
>> +++ b/drivers/pci/access.c
>> @@ -469,3 +469,91 @@ void pci_cfg_access_unlock(struct pci_dev *dev)
>>
On Tue, Jul 10, 2012 at 9:54 AM, Jiang Liu wrote:
> From: Jiang Liu
>
> Introduce four configuration access functions for PCIe capabilities to
> hide difference among PCIe Base Spec versions. With these functions,
> we can remove callers responsible for using pci_pcie_cap_has_*().
>
>
From: Jiang Liu
Introduce four configuration access functions for PCIe capabilities to
hide difference among PCIe Base Spec versions. With these functions,
we can remove callers responsible for using pci_pcie_cap_has_*().
pci_pcie_cap_read_word/dword() functions will store the pcie cap register
From: Jiang Liu jiang@huawei.com
Introduce four configuration access functions for PCIe capabilities to
hide difference among PCIe Base Spec versions. With these functions,
we can remove callers responsible for using pci_pcie_cap_has_*().
pci_pcie_cap_read_word/dword() functions will store
On Tue, Jul 10, 2012 at 9:54 AM, Jiang Liu liu...@gmail.com wrote:
From: Jiang Liu jiang@huawei.com
Introduce four configuration access functions for PCIe capabilities to
hide difference among PCIe Base Spec versions. With these functions,
we can remove callers responsible for using
On 2012-7-11 2:35, Bjorn Helgaas wrote:
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index ba91a7e..80ae022 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -469,3 +469,91 @@ void pci_cfg_access_unlock(struct pci_dev *dev)
On Tue, Jul 10, 2012 at 9:07 PM, Jiang Liu jiang@huawei.com wrote:
On 2012-7-11 2:35, Bjorn Helgaas wrote:
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index ba91a7e..80ae022 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -469,3 +469,91 @@ void
26 matches
Mail list logo
