nc_single_for_device(dev, dev_addr, size, dir);
if (!is_device_dma_coherent(dev))
- __dma_map_area(phys_to_virt(swiotlb_dma_to_phys(dev, dev_addr)),
- size, dir);
+ __dma_map_area(swiotlb_to_virt(dev_addr), size, dir);
}
--
Si
swiotlb_dma_to_phys.
Signed-off-by: Sinan Kaya
---
arch/arm/include/asm/dma-mapping.h | 8 ++-
arch/arm64/include/asm/dma-mapping.h | 9 ++-
arch/arm64/mm/dma-mapping.c| 75 ++
arch/ia64/include/asm/dma-mapping.h| 8
rcise later. I'll undo this change for the moment.
Let's focus on the API rename.
I don't want this general purpose dma_to_phys API returning phys=dma value.
This is
not correct.
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm I
On 11/15/2018 3:16 PM, Alexandru Gagniuc wrote:
I've asked around a few people at Dell and they unanimously agree that
_OSC is the correct way to determine ownership of AER. In linux, we
use the result of _OSC to enable AER services, but we use HEST to
determine AER ownership. That's inconsistent
On 11/19/2018 11:53 AM, Keith Busch wrote:
On Mon, Nov 19, 2018 at 11:53:05AM -0500, Tyler Baicar wrote:
On Thu, Nov 15, 2018 at 8:49 PM Sinan Kaya wrote:
On 11/15/2018 3:16 PM, Alexandru Gagniuc wrote:
I've asked around a few people at Dell and they unanimously agree that
_OSC i
On 11/19/2018 12:32 PM, Sinan Kaya wrote:
But we're not using HEST as a fine grain control. We disable native AER
handling if *any* device has FF set in HEST, and that just forces people
to use pcie_ports=native to get around that.
I don't see *any* in the code. aer_hest_parse(
On 11/19/2018 12:41 PM, Keith Busch wrote:
Still, breaking existing systems that rely on HEST table is not cool.
I'd rather have users specify "pcie_ports=native" to skip FF rather than
having broken systems by default to be honest.
The pcie_ports=native work-around ignores FF to potentially unk
On 11/19/2018 1:10 PM, Keith Busch wrote:
We can't really turn off firmware first in the kernel without asking help
from the firmware.
The _OSC method this patch utilizes is the ACPI spec defined way for
the kernel to wrest control from firmware. BIOS specific menu settings
shouldn't be our only
UEFI HEST table specification also claims that it should be the ultimate
table for when PCI firmware-first should be disabled/enabled.
IIRC, EFI absorbed ACPI before FFS was a thing. Could you point me to the UEFI
chapter that says HEST is authoritative?
(not being a smartie, just that my free
On 11/19/2018 3:16 PM, alex_gagn...@dellteam.com wrote:
On 11/19/2018 01:32 PM, Sinan Kaya wrote:
ACPI 6.2:
18.3.2.4 PCI Express Root Port AER Structure
Flags:
Bit [0] - FIRMWARE_FIRST: If set, this bit indicates to the OSPM that system
firmware will handle errors from this source first.
Bit
On 11/19/2018 6:49 PM, alex_gagn...@dellteam.com wrote:
On 11/19/2018 02:33 PM, Sinan Kaya wrote:
However; table assumes governance about for which entities firmware first
should be enabled. There is no cross reference to _OSC or permission
negotiation like _OST.
Well, from an OSPM
On 11/20/2018 3:44 PM, alex_gagn...@dellteam.com wrote:
I'd prefer "sure" instead of "think". "I think it breaks some system I'm
not telling you about" doesn't help much in figuring out how not to
break said system(s).:)
Sorry, I thought I mentioned why it would break but let me repeat.
The sy
On 11/20/2018 4:46 PM, alex_gagn...@dellteam.com wrote:
Now, let's assume, for the sake of argument, that the firmware on those
system's is broken, and it didn't intend to give the OS control of AER.
OSPM checking HEST instead of _OSC is still wrong, according to the
spec. Two wrongs don't make a
On 11/20/2018 4:42 PM, Keith Busch wrote:
How does that work? If the OS takes control, it sets up MSIs that FW don't
react to, and disables system errors through PCIe Root Control. Aren't
those sys errs the mechanism FW knows it has something to do, which
means the OS can effectively fence it off
On 11/27/2018 1:22 PM, alex_gagn...@dellteam.com wrote:
On 11/20/2018 04:08 PM, Sinan Kaya wrote:
I followed the ASWG thread yesterday. There will be a meeting next week to
discuss this.
Any updates on the meeting?
Tyler should be able to get an update.
, use the actual domain number from
the device.
Signed-off-by: Sinan Kaya
---
arch/powerpc/kernel/pci_32.c | 3 ++-
arch/powerpc/platforms/powermac/feature.c | 2 +-
arch/powerpc/sysdev/mv64x60_pci.c | 4 ++--
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a
, use the actual domain number from
the device.
Signed-off-by: Sinan Kaya
---
drivers/macintosh/via-pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index c4c2b3b..3e8b3b6 100644
--- a/drivers/macintosh/via-pmu.c
pci_get_domain_bus_and_slot() with a domain number of 0 as the code
is not ready to consume multiple domains and existing code used domain
number 0.
Signed-off-by: Sinan Kaya
---
arch/powerpc/kernel/pci_32.c | 3 ++-
arch/powerpc/platforms/powermac/feature.c | 2 +-
arch/powerpc/sysdev/mv64x60_pci.c
number as 0 to match the previous behavior.
Signed-off-by: Sinan Kaya
---
drivers/macintosh/via-pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index c4c2b3b..3e8b3b6 100644
--- a/drivers/macintosh/via-pmu.c
+++ b
pci_get_domain_bus_and_slot() with a domain number of 0 as the code
is not ready to consume multiple domains and existing code used domain
number 0.
Signed-off-by: Sinan Kaya
---
arch/powerpc/kernel/pci_32.c | 3 ++-
arch/powerpc/platforms/powermac/feature.c | 2 +-
arch/powerpc/sysdev/mv64x60_pci.c
number as 0 to match the previous behavior.
Signed-off-by: Sinan Kaya
---
drivers/macintosh/via-pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index c4c2b3b..3e8b3b6 100644
--- a/drivers/macintosh/via-pmu.c
+++ b
pci_get_domain_bus_and_slot() with a domain number of 0 as the code
is not ready to consume multiple domains and existing code used domain
number 0.
Signed-off-by: Sinan Kaya
---
arch/powerpc/kernel/pci_32.c | 3 ++-
arch/powerpc/platforms/powermac/feature.c | 2 +-
arch/powerpc/sysdev/mv64x60_pci.c
number as 0 to match the previous behavior.
Signed-off-by: Sinan Kaya
---
drivers/macintosh/via-pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index e8b29fc..08849e3 100644
--- a/drivers/macintosh/via-pmu.c
+++ b
On 12/19/2017 5:29 AM, Michael Ellerman wrote:
> Sinan Kaya writes:
>
>> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
>> where a PCI device is present. This restricts the device drivers to be
>> reused for other domain numbers.
>&
+linuxppc-dev@lists.ozlabs.org
On 3/17/2018 11:05 AM, Jason Gunthorpe wrote:
> On Sat, Mar 17, 2018 at 12:25:14AM -0400, Sinan Kaya wrote:
>> On 3/17/2018 12:03 AM, Sinan Kaya wrote:
>>> On 3/16/2018 11:40 PM, Sinan Kaya wrote:
>>>> I'll change writel_relaxed(
SPARC since the semantics of __raw_writel() seems to be system dependent.
This is putting drivers into a tight position and they cannot achieve true
multi-arch enablement and are forced into calling __raw APIs flavors
directly with #ifdef BIG_ENDIAN ugliness.
Sinan
--
Sinan Kaya
Qualcomm
et/lists/netdev/msg490480.html
[2] https://www.spinics.net/lists/arm-kernel/msg642341.html
[3] https://www.spinics.net/lists/arm-kernel/msg642336.html
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of th
On 3/21/2018 8:53 AM, Sinan Kaya wrote:
> BTW, I have no idea what compiler barrier does on PPC and if
>
> wrltel() == compiler barrier() + wrltel_relaxed()
>
> can be said.
this should have been
writel_relaxed() == compiler barrier() + __raw_writel()
--
Sinan Kaya
Qual
can only be done for known code and known hardware. I don't believe
this applies to multi-arch drivers.
>
> David
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
odel, where an actual memory
> barrier instruction needs to be emited.
Surprisingly, ARM64 GCC compiler generates a write barrier as
opposed to preventing code reordering.
I was curious if this is an ARM only thing or not.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate
On 3/22/2018 8:16 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2018-03-22 at 12:51 -0500, Sinan Kaya wrote:
>> On 3/22/2018 8:52 AM, Benjamin Herrenschmidt wrote:
>>>>> No, it's not sufficient.
>>>
>>> Just to clarify ... barrier() is just a compiler b
.
What got me confused was this sequence:
wmb()
barrier()
writel()
I thought that the second barrier instruction was coming from barrier() but
it was actually coming from writel().
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm T
architectures.
5. We decided to go back to PPC and ask to implement writel_relaxed()
instead of coming up with writel_realy_relaxed() API.
>
>> On Fri, Mar 23, 2018 at 11:16:08AM +1100, Benjamin Herrenschmidt wrote:
>>> On Thu, 2018-03-22 at 12:51 -0500, Sinan Kaya wrote:
>&g
On 3/26/2018 9:43 AM, Arnd Bergmann wrote:
> On Wed, Mar 21, 2018 at 2:58 PM, Sinan Kaya wrote:
>> On 3/21/2018 8:53 AM, Sinan Kaya wrote:
>>> BTW, I have no idea what compiler barrier does on PPC and if
>>>
>>> wrltel() == compiler barrier() + wrltel_relax
y with not including wmb() in their code and use
writel() to observe memory writes due to implicit barriers.
However, same code will not work on Intel.
writel() has a compiler barrier in it for x86.
wmb() has a sync operation in it for x86.
Unless wmb() is called, PCIe device won't observe
On 3/26/2018 6:01 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2018-03-26 at 17:46 -0400, Sinan Kaya wrote:
>> On 3/26/2018 5:30 PM, Arnd Bergmann wrote:
>>>> But that was never a requirement of writel(),
>>>> Documentation/memory-barriers.txt gives an explic
; + have completed before writing to the MMIO region. The cheaper
> + writel_relaxed() does not provide this guarantee and must not be used
> + here.
Can we say the same thing for iowrite32() and iowrite32be(). I also see wmb()
in front of these.
--
Sinan Kaya
Qualcomm Datacenter Tec
now that for x86 you have to have a
wmb() before the writel().
Based on the comment in
(https://www.spinics.net/lists/linux-rdma/msg62666.html):
Replacing wmb() + writel() with wmb() + writel_relaxed() will work on
PPC, it will just not give you a benefit today.
I say the patch set stays. This gives benefit on ARM, and has no
effect on x86 and PowerPC. If you want to look at trying to optimize
things further on PowerPC and such then go for it in terms of trying
to implement the writel_relaxed(). Otherwise I say we call the ARM
goodness a win and don't get ourselves too wrapped up in trying to fix
this for all architectures."
>
> Cheers,
> Ben.
>
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
to remove wmb() and throw in smp barriers there
like you mentioned.
I'll leave the changes in the Intel drivers alone.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a L
sion started to move around the need for relaxed API on PPC and then
why wmb() question came up.
Sinan
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
stion sent
tilequestion sent
unicore32 question sent
x86 no issues
xtensa question sent
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
On 3/29/2018 12:29 PM, Arnd Bergmann wrote:
> On Thu, Mar 29, 2018 at 3:56 PM, Sinan Kaya wrote:
>> On 3/28/2018 11:55 AM, David Miller wrote:
>>> From: Benjamin Herrenschmidt
>>> Date: Thu, 29 Mar 2018 02:13:16 +1100
>>>
>>>> Let's fix all ar
On 3/29/2018 9:40 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2018-03-29 at 09:56 -0400, Sinan Kaya wrote:
>> On 3/28/2018 11:55 AM, David Miller wrote:
>>> From: Benjamin Herrenschmidt
>>> Date: Thu, 29 Mar 2018 02:13:16 +1100
>>>
>>>> Let's f
CONFIG_DEBUG_KERNEL should not impact code generation. Use the newly
defined CONFIG_DEBUG_MISC instead to keep the current code.
Signed-off-by: Sinan Kaya
---
arch/powerpc/kernel/sysfs.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/sysfs.c b
CONFIG_DEBUG_KERNEL should not impact code generation. Use the newly
defined CONFIG_DEBUG_MISC instead to keep the current code.
Signed-off-by: Sinan Kaya
Reviewed-by: Josh Triplett
---
arch/powerpc/kernel/sysfs.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch
On 6/18/2020 11:55 AM, Matt Jolly wrote:
> + pci_warn(dev, " device [%04x:%04x] error
> status/mask=%08x/%08x\n",
> + dev->vendor, dev->device,
> + info->status, info->mask);
> + } else {
> + pci_err(dev, " device [%04x:%04x
46 matches
Mail list logo
