Re: [PATCH] dma-mapping: add unlikely hint to error path in dma_mapping_error
On 26.03.2021 22:03, Heiner Kallweit wrote:
> Zillions of drivers use the unlikely() hint when checking the result of
> dma_mapping_error(). This is an inline function anyway, so we can move
> the hint into the function and remove it from drivers over time.
>
> Signed-off-by: Heiner Kallweit
> ---
> This is a resend of a patch from Dec 2020 when I tried to do it
> tree-wide. Now start with the actual change, drivers can be changed
> afterwards, maybe per subsystem.
> ---
> include/linux/dma-mapping.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index e9d19b974..183e7103a 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -95,7 +95,7 @@ static inline int dma_mapping_error(struct device *dev,
> dma_addr_t dma_addr)
> {
> debug_dma_mapping_error(dev, dma_addr);
>
> - if (dma_addr == DMA_MAPPING_ERROR)
> + if (unlikely(dma_addr == DMA_MAPPING_ERROR))
> return -ENOMEM;
> return 0;
> }
>
Reviewed-by: Robin Murphy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dma-mapping: add unlikely hint to error path in dma_mapping_error
On 30.03.2021 12:21, Robin Murphy wrote:
> On 2021-03-26 21:03, Heiner Kallweit wrote:
>> Zillions of drivers use the unlikely() hint when checking the result of
>> dma_mapping_error(). This is an inline function anyway, so we can move
>> the hint into the function and remove it from drivers over time.
>
> I'm pretty sure I reviewed this last time - please remember to pick up tags
> from previous versions when reposting.
>
Right, you did. My bad.
> Thanks,
> Robin.
>
>> Signed-off-by: Heiner Kallweit
>> ---
>> This is a resend of a patch from Dec 2020 when I tried to do it
>> tree-wide. Now start with the actual change, drivers can be changed
>> afterwards, maybe per subsystem.
>> ---
>> include/linux/dma-mapping.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
>> index e9d19b974..183e7103a 100644
>> --- a/include/linux/dma-mapping.h
>> +++ b/include/linux/dma-mapping.h
>> @@ -95,7 +95,7 @@ static inline int dma_mapping_error(struct device *dev,
>> dma_addr_t dma_addr)
>> {
>> debug_dma_mapping_error(dev, dma_addr);
>> - if (dma_addr == DMA_MAPPING_ERROR)
>> + if (unlikely(dma_addr == DMA_MAPPING_ERROR))
>> return -ENOMEM;
>> return 0;
>> }
>>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] dma-mapping: add unlikely hint to error path in dma_mapping_error
Zillions of drivers use the unlikely() hint when checking the result of
dma_mapping_error(). This is an inline function anyway, so we can move
the hint into the function and remove it from drivers over time.
Signed-off-by: Heiner Kallweit
---
This is a resend of a patch from Dec 2020 when I tried to do it
tree-wide. Now start with the actual change, drivers can be changed
afterwards, maybe per subsystem.
---
include/linux/dma-mapping.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index e9d19b974..183e7103a 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -95,7 +95,7 @@ static inline int dma_mapping_error(struct device *dev,
dma_addr_t dma_addr)
{
debug_dma_mapping_error(dev, dma_addr);
- if (dma_addr == DMA_MAPPING_ERROR)
+ if (unlikely(dma_addr == DMA_MAPPING_ERROR))
return -ENOMEM;
return 0;
}
--
2.31.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] dma-mapping: add unlikely hint for error path in dma_mapping_error
On 14.12.2020 14:01, Robin Murphy wrote:
> On 2020-12-13 16:32, Heiner Kallweit wrote:
>> Zillions of drivers use the unlikely() hint when checking the result of
>> dma_mapping_error(). This is an inline function anyway, so we can move
>> the hint into this function and remove it from drivers.
>
> Reviewed-by: Robin Murphy
>
> FWIW I consider this case similar to the same hint in WARN_ON() and friends -
> it's a pretty severe condition that should never be expected to be hit in
> normal operation, so it's entirely logical for it to be implicitly unlikely.
> I struggle to imagine any case that would specifically *not* want that (or
> worse, want to hint it as likely). Some DMA API backends may spend
> considerable time trying as hard as possible to make a mapping work before
> eventually admitting defeat, so the idea of ever trying to optimise at the
> driver level for failure in hot paths just makes no sense.
>
> Thanks,
> Robin.
>
>> Signed-off-by: Heiner Kallweit
>> ---
>> v2:
>> Split the big patch into the change for dma-mapping.h and follow-up
>> patches per subsystem that will go through the trees of the respective
>> maintainers.
>> ---
>> include/linux/dma-mapping.h | 2 +-
>> kernel/dma/map_benchmark.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
>> index 2e49996a8..6177e20b5 100644
>> --- a/include/linux/dma-mapping.h
>> +++ b/include/linux/dma-mapping.h
>> @@ -95,7 +95,7 @@ static inline int dma_mapping_error(struct device *dev,
>> dma_addr_t dma_addr)
>> {
>> debug_dma_mapping_error(dev, dma_addr);
>> - if (dma_addr == DMA_MAPPING_ERROR)
>> + if (unlikely(dma_addr == DMA_MAPPING_ERROR))
>> return -ENOMEM;
>> return 0;
>> }
>> diff --git a/kernel/dma/map_benchmark.c b/kernel/dma/map_benchmark.c
>> index b1496e744..901420a5d 100644
>> --- a/kernel/dma/map_benchmark.c
>> +++ b/kernel/dma/map_benchmark.c
>> @@ -78,7 +78,7 @@ static int map_benchmark_thread(void *data)
>> map_stime = ktime_get();
>> dma_addr = dma_map_single(map->dev, buf, PAGE_SIZE, map->dir);
>> - if (unlikely(dma_mapping_error(map->dev, dma_addr))) {
>> + if (dma_mapping_error(map->dev, dma_addr)) {
>> pr_err("dma_map_single failed on %s\n",
>> dev_name(map->dev));
>> ret = -ENOMEM;
>>
Is this patch going to make it to linux-next?
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] dma-mapping: add unlikely hint for error path in dma_mapping_error
Am 13.12.2020 um 22:27 schrieb Song Bao Hua (Barry Song):
>
>
>> -Original Message-----
>> From: Heiner Kallweit [mailto:hkallwe...@gmail.com]
>> Sent: Monday, December 14, 2020 5:33 AM
>> To: Christoph Hellwig ; Marek Szyprowski
>> ; Robin Murphy ; Song Bao Hua
>> (Barry Song)
>> Cc: open list:AMD IOMMU (AMD-VI) ; Linux
>> Kernel Mailing List
>> Subject: [PATCH v2] dma-mapping: add unlikely hint for error path in
>> dma_mapping_error
>>
>> Zillions of drivers use the unlikely() hint when checking the result of
>> dma_mapping_error(). This is an inline function anyway, so we can move
>> the hint into this function and remove it from drivers.
>>
>> Signed-off-by: Heiner Kallweit
>
> not sure if this is really necessary. It seems the original code
> is more readable. Readers can more easily understand we are
> predicting the branch based on the return value of
> dma_mapping_error().
>
I basically see two points promoting the proposed change:
1. Driver authors shouldn't have to think (as far as possible) about
whether a branch prediction hint could make sense for a standard
core API call. I saw quite some past discussions about when
something is unlikely enough so that an unlikely() makes sense.
If the core can hide some more complexity from drivers, then
I think it's a good thing.
2. If we ever want or have to change the use of unlikely with
dma_mapping_error(), then we have to do it in just one place.
> Anyway, I don't object to this one. if other people like it, I am
> also ok with it.
>
>> ---
>> v2:
>> Split the big patch into the change for dma-mapping.h and follow-up
>> patches per subsystem that will go through the trees of the respective
>> maintainers.
>> ---
>> include/linux/dma-mapping.h | 2 +-
>> kernel/dma/map_benchmark.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
>> index 2e49996a8..6177e20b5 100644
>> --- a/include/linux/dma-mapping.h
>> +++ b/include/linux/dma-mapping.h
>> @@ -95,7 +95,7 @@ static inline int dma_mapping_error(struct device *dev,
>> dma_addr_t dma_addr)
>> {
>> debug_dma_mapping_error(dev, dma_addr);
>>
>> -if (dma_addr == DMA_MAPPING_ERROR)
>> +if (unlikely(dma_addr == DMA_MAPPING_ERROR))
>> return -ENOMEM;
>> return 0;
>> }
>> diff --git a/kernel/dma/map_benchmark.c b/kernel/dma/map_benchmark.c
>> index b1496e744..901420a5d 100644
>> --- a/kernel/dma/map_benchmark.c
>> +++ b/kernel/dma/map_benchmark.c
>> @@ -78,7 +78,7 @@ static int map_benchmark_thread(void *data)
>>
>> map_stime = ktime_get();
>> dma_addr = dma_map_single(map->dev, buf, PAGE_SIZE, map->dir);
>> -if (unlikely(dma_mapping_error(map->dev, dma_addr))) {
>> +if (dma_mapping_error(map->dev, dma_addr)) {
>> pr_err("dma_map_single failed on %s\n",
>> dev_name(map->dev));
>> ret = -ENOMEM;
>> --
>> 2.29.2
>
> Thanks
> Barry
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2] dma-mapping: add unlikely hint for error path in dma_mapping_error
Zillions of drivers use the unlikely() hint when checking the result of
dma_mapping_error(). This is an inline function anyway, so we can move
the hint into this function and remove it from drivers.
Signed-off-by: Heiner Kallweit
---
v2:
Split the big patch into the change for dma-mapping.h and follow-up
patches per subsystem that will go through the trees of the respective
maintainers.
---
include/linux/dma-mapping.h | 2 +-
kernel/dma/map_benchmark.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 2e49996a8..6177e20b5 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -95,7 +95,7 @@ static inline int dma_mapping_error(struct device *dev,
dma_addr_t dma_addr)
{
debug_dma_mapping_error(dev, dma_addr);
- if (dma_addr == DMA_MAPPING_ERROR)
+ if (unlikely(dma_addr == DMA_MAPPING_ERROR))
return -ENOMEM;
return 0;
}
diff --git a/kernel/dma/map_benchmark.c b/kernel/dma/map_benchmark.c
index b1496e744..901420a5d 100644
--- a/kernel/dma/map_benchmark.c
+++ b/kernel/dma/map_benchmark.c
@@ -78,7 +78,7 @@ static int map_benchmark_thread(void *data)
map_stime = ktime_get();
dma_addr = dma_map_single(map->dev, buf, PAGE_SIZE, map->dir);
- if (unlikely(dma_mapping_error(map->dev, dma_addr))) {
+ if (dma_mapping_error(map->dev, dma_addr)) {
pr_err("dma_map_single failed on %s\n",
dev_name(map->dev));
ret = -ENOMEM;
--
2.29.2
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] dma-mapping: move hint unlikely for dma_mapping_error from drivers to core
Zillions of drivers use the unlikely() hint when checking the result of dma_mapping_error(). This is an inline function anyway, so we can move the hint into the function and remove it from drivers. >From time to time discussions pop up how effective unlikely() is, and that it should be used only if something is really very unlikely. I think that's the case here. Patch was created with some help from coccinelle. @@ expression dev, dma_addr; @@ - unlikely(dma_mapping_error(dev, dma_addr)) + dma_mapping_error(dev, dma_addr) Signed-off-by: Heiner Kallweit --- If ok, then tbd through which tree this is supposed to go. Patch is based on linux-next-20201210. --- drivers/crypto/cavium/cpt/cptvf_reqmanager.c | 3 +-- drivers/crypto/hisilicon/hpre/hpre_crypto.c | 2 +- .../marvell/octeontx/otx_cptvf_reqmgr.c | 5 ++-- drivers/crypto/mediatek/mtk-aes.c | 2 +- drivers/crypto/mediatek/mtk-sha.c | 6 ++--- drivers/crypto/qat/qat_common/qat_algs.c | 8 +++--- drivers/crypto/qat/qat_common/qat_asym_algs.c | 25 +-- drivers/i2c/busses/i2c-amd-mp2-plat.c | 2 +- drivers/infiniband/hw/hfi1/sdma.c | 2 +- drivers/net/ethernet/aeroflex/greth.c | 4 +-- drivers/net/ethernet/amazon/ena/ena_netdev.c | 8 +++--- .../net/ethernet/apm/xgene/xgene_enet_main.c | 2 +- .../net/ethernet/aquantia/atlantic/aq_nic.c | 5 ++-- .../net/ethernet/aquantia/atlantic/aq_ring.c | 2 +- drivers/net/ethernet/arc/emac_main.c | 2 +- .../net/ethernet/atheros/atl1c/atl1c_main.c | 6 ++--- drivers/net/ethernet/broadcom/bgmac.c | 4 +-- .../net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 10 .../ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 2 +- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 4 +-- drivers/net/ethernet/chelsio/cxgb4/sge.c | 4 +-- drivers/net/ethernet/chelsio/cxgb4vf/sge.c| 4 +-- drivers/net/ethernet/faraday/ftgmac100.c | 2 +- drivers/net/ethernet/faraday/ftmac100.c | 4 +-- .../net/ethernet/freescale/dpaa/dpaa_eth.c| 13 +- .../net/ethernet/freescale/dpaa2/dpaa2-eth.c | 12 - drivers/net/ethernet/freescale/enetc/enetc.c | 4 +-- drivers/net/ethernet/freescale/gianfar.c | 6 ++--- drivers/net/ethernet/google/gve/gve_tx.c | 4 +-- drivers/net/ethernet/hisilicon/hisi_femac.c | 2 +- drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 4 +-- .../net/ethernet/hisilicon/hns3/hns3_enet.c | 4 +-- drivers/net/ethernet/lantiq_xrx200.c | 5 ++-- drivers/net/ethernet/marvell/mv643xx_eth.c| 3 +-- drivers/net/ethernet/marvell/mvneta.c | 9 +++ drivers/net/ethernet/marvell/mvneta_bm.c | 2 +- .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 8 +++--- .../marvell/octeontx2/nic/otx2_common.c | 2 +- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 10 drivers/net/ethernet/mellanox/mlx4/en_rx.c| 2 +- .../mellanox/mlx5/core/diag/rsc_dump.c| 2 +- .../net/ethernet/mellanox/mlx5/core/en/xdp.c | 2 +- .../mellanox/mlx5/core/en_accel/ktls_rx.c | 2 +- .../mellanox/mlx5/core/en_accel/ktls_tx.c | 2 +- .../net/ethernet/mellanox/mlx5/core/en_rx.c | 2 +- .../net/ethernet/mellanox/mlx5/core/en_tx.c | 6 ++--- .../net/ethernet/neterion/vxge/vxge-config.c | 6 ++--- .../net/ethernet/neterion/vxge/vxge-main.c| 6 ++--- drivers/net/ethernet/nvidia/forcedeth.c | 21 ++-- .../net/ethernet/pensando/ionic/ionic_txrx.c | 2 +- drivers/net/ethernet/qlogic/qed/qed_ll2.c | 4 +-- .../net/ethernet/qlogic/qede/qede_ethtool.c | 2 +- drivers/net/ethernet/qlogic/qede/qede_fp.c| 8 +++--- drivers/net/ethernet/realtek/r8169_main.c | 2 +- drivers/net/ethernet/rocker/rocker_main.c | 2 +- drivers/net/ethernet/sfc/falcon/rx.c | 3 +-- drivers/net/ethernet/sfc/falcon/tx.c | 4 +-- drivers/net/ethernet/sfc/rx_common.c | 3 +-- drivers/net/ethernet/sfc/tx_common.c | 4 +-- drivers/net/ethernet/sfc/tx_tso.c | 2 +- drivers/net/ethernet/sis/sis900.c | 24 -- drivers/net/ethernet/socionext/sni_ave.c | 2 +- drivers/net/ethernet/sun/sunhme.c | 8 +++--- drivers/net/ethernet/ti/am65-cpsw-nuss.c | 6 ++--- drivers/net/ethernet/ti/netcp_core.c | 4 +-- drivers/net/ethernet/via/via-rhine.c | 2 +- .../net/ethernet/xilinx/xilinx_axienet_main.c | 6 ++--- drivers/net/wireless/ath/ath10k/htt_rx.c | 2 +- drivers/net/wireless/ath/ath10k/pci.c | 2 +- drivers/net/wireless/ath/ath10k/snoc.c| 2 +- drivers/net/wireless/ath/ath11k/ce.c | 2 +- drivers/net/wireless/ath/ath11k/dp_rx.c | 2 +- drivers/net/wireless/ath/ath5k/base.c | 2 +- drivers/net/wireless/ath/ath9k/beacon.c | 2 +- drivers/net/wireless/ath/ath9k/recv.c | 21 +++- drivers/net/wireless/ath/ath9k/xmi
dma-mapping: use bit macros
Not necessarily a big leap for mankind, but using bit macros makes
the code better readable, especially the definition of DMA_BIT_MASK
is more intuitive.
Signed-off-by: Heiner Kallweit
---
include/linux/dma-mapping.h | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index a4930310d..a39a6a8d5 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -2,6 +2,7 @@
#ifndef _LINUX_DMA_MAPPING_H
#define _LINUX_DMA_MAPPING_H
+#include
#include
#include
#include
@@ -21,51 +22,51 @@
* DMA_ATTR_WEAK_ORDERING: Specifies that reads and writes to the mapping
* may be weakly ordered, that is that reads and writes may pass each other.
*/
-#define DMA_ATTR_WEAK_ORDERING (1UL << 1)
+#define DMA_ATTR_WEAK_ORDERING BIT(1)
/*
* DMA_ATTR_WRITE_COMBINE: Specifies that writes to the mapping may be
* buffered to improve performance.
*/
-#define DMA_ATTR_WRITE_COMBINE (1UL << 2)
+#define DMA_ATTR_WRITE_COMBINE BIT(2)
/*
* DMA_ATTR_NON_CONSISTENT: Lets the platform to choose to return either
* consistent or non-consistent memory as it sees fit.
*/
-#define DMA_ATTR_NON_CONSISTENT(1UL << 3)
+#define DMA_ATTR_NON_CONSISTENTBIT(3)
/*
* DMA_ATTR_NO_KERNEL_MAPPING: Lets the platform to avoid creating a kernel
* virtual mapping for the allocated buffer.
*/
-#define DMA_ATTR_NO_KERNEL_MAPPING (1UL << 4)
+#define DMA_ATTR_NO_KERNEL_MAPPING BIT(4)
/*
* DMA_ATTR_SKIP_CPU_SYNC: Allows platform code to skip synchronization of
* the CPU cache for the given buffer assuming that it has been already
* transferred to 'device' domain.
*/
-#define DMA_ATTR_SKIP_CPU_SYNC (1UL << 5)
+#define DMA_ATTR_SKIP_CPU_SYNC BIT(5)
/*
* DMA_ATTR_FORCE_CONTIGUOUS: Forces contiguous allocation of the buffer
* in physical memory.
*/
-#define DMA_ATTR_FORCE_CONTIGUOUS (1UL << 6)
+#define DMA_ATTR_FORCE_CONTIGUOUS BIT(6)
/*
* DMA_ATTR_ALLOC_SINGLE_PAGES: This is a hint to the DMA-mapping subsystem
* that it's probably not worth the time to try to allocate memory to in a way
* that gives better TLB efficiency.
*/
-#define DMA_ATTR_ALLOC_SINGLE_PAGES(1UL << 7)
+#define DMA_ATTR_ALLOC_SINGLE_PAGESBIT(7)
/*
* DMA_ATTR_NO_WARN: This tells the DMA-mapping subsystem to suppress
* allocation failure reports (similarly to __GFP_NOWARN).
*/
-#define DMA_ATTR_NO_WARN (1UL << 8)
+#define DMA_ATTR_NO_WARN BIT(8)
/*
* DMA_ATTR_PRIVILEGED: used to indicate that the buffer is fully
* accessible at an elevated privilege level (and ideally inaccessible or
* at least read-only at lesser-privileged levels).
*/
-#define DMA_ATTR_PRIVILEGED(1UL << 9)
+#define DMA_ATTR_PRIVILEGEDBIT(9)
/*
* A dma_addr_t can hold any valid DMA or bus address for the platform.
@@ -136,7 +137,7 @@ struct dma_map_ops {
extern const struct dma_map_ops dma_virt_ops;
extern const struct dma_map_ops dma_dummy_ops;
-#define DMA_BIT_MASK(n)(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
+#define DMA_BIT_MASK(n)GENMASK_ULL(n - 1, 0)
#define DMA_MASK_NONE 0x0ULL
--
2.24.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 9/9] platform/chrome: chromeos_laptop: use helper pci_dev_id
Use new helper pci_dev_id() to simplify the code. Signed-off-by: Heiner Kallweit --- drivers/platform/chrome/chromeos_laptop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/chrome/chromeos_laptop.c b/drivers/platform/chrome/chromeos_laptop.c index 24326eecd..7abbb6167 100644 --- a/drivers/platform/chrome/chromeos_laptop.c +++ b/drivers/platform/chrome/chromeos_laptop.c @@ -125,7 +125,7 @@ static bool chromeos_laptop_match_adapter_devid(struct device *dev, u32 devid) return false; pdev = to_pci_dev(dev); - return devid == PCI_DEVID(pdev->bus->number, pdev->devfn); + return devid == pci_dev_id(pdev); } static void chromeos_laptop_check_adapter(struct i2c_adapter *adapter) -- 2.21.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 8/9] stmmac: pci: use helper pci_dev_id
Use new helper pci_dev_id() to simplify the code. Signed-off-by: Heiner Kallweit --- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c index cc1e887e4..0e87a9596 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c @@ -208,7 +208,7 @@ static int quark_default_data(struct pci_dev *pdev, ret = 1; } - plat->bus_id = PCI_DEVID(pdev->bus->number, pdev->devfn); + plat->bus_id = pci_dev_id(pdev); plat->phy_addr = ret; plat->interface = PHY_INTERFACE_MODE_RMII; -- 2.21.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 7/9] iommu/vt-d: use helper pci_dev_id
Use new helper pci_dev_id() to simplify the code. Signed-off-by: Heiner Kallweit --- drivers/iommu/intel-iommu.c | 2 +- drivers/iommu/intel_irq_remapping.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index d93c4bd7d..3f475a23a 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -1391,7 +1391,7 @@ static void iommu_enable_dev_iotlb(struct device_domain_info *info) /* pdev will be returned if device is not a vf */ pf_pdev = pci_physfn(pdev); - info->pfsid = PCI_DEVID(pf_pdev->bus->number, pf_pdev->devfn); + info->pfsid = pci_dev_id(pf_pdev); } #ifdef CONFIG_INTEL_IOMMU_SVM diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu/intel_irq_remapping.c index 634d8f059..4160aa9f3 100644 --- a/drivers/iommu/intel_irq_remapping.c +++ b/drivers/iommu/intel_irq_remapping.c @@ -424,7 +424,7 @@ static int set_msi_sid(struct irte *irte, struct pci_dev *dev) set_irte_sid(irte, SVT_VERIFY_SID_SQ, SQ_ALL_16, data.alias); else set_irte_sid(irte, SVT_VERIFY_SID_SQ, SQ_ALL_16, -PCI_DEVID(dev->bus->number, dev->devfn)); +pci_dev_id(dev)); return 0; } -- 2.21.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 6/9] iommu/amd: use helper pci_dev_id
Use new helper pci_dev_id() to simplify the code.
Signed-off-by: Heiner Kallweit
---
drivers/iommu/amd_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index f467cc4b4..5cb201422 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -165,7 +165,7 @@ static inline u16 get_pci_device_id(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
- return PCI_DEVID(pdev->bus->number, pdev->devfn);
+ return pci_dev_id(pdev);
}
static inline int get_acpihid_device_id(struct device *dev,
--
2.21.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 5/9] drm/amdkfd: use helper pci_dev_id
Use new helper pci_dev_id() to simplify the code. Signed-off-by: Heiner Kallweit --- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c index 2cb09e088..769dbc7be 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c @@ -1272,8 +1272,7 @@ int kfd_topology_add_device(struct kfd_dev *gpu) dev->node_props.vendor_id = gpu->pdev->vendor; dev->node_props.device_id = gpu->pdev->device; - dev->node_props.location_id = PCI_DEVID(gpu->pdev->bus->number, - gpu->pdev->devfn); + dev->node_props.location_id = pci_dev_id(gpu->pdev); dev->node_props.max_engine_clk_fcompute = amdgpu_amdkfd_get_max_engine_clock_in_mhz(dev->gpu->kgd); dev->node_props.max_engine_clk_ccompute = -- 2.21.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 4/9] powerpc/powernv/npu: use helper pci_dev_id
Use new helper pci_dev_id() to simplify the code.
Signed-off-by: Heiner Kallweit
---
arch/powerpc/platforms/powernv/npu-dma.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
b/arch/powerpc/platforms/powernv/npu-dma.c
index dc23d9d2a..495550432 100644
--- a/arch/powerpc/platforms/powernv/npu-dma.c
+++ b/arch/powerpc/platforms/powernv/npu-dma.c
@@ -1213,9 +1213,8 @@ int pnv_npu2_map_lpar_dev(struct pci_dev *gpdev, unsigned
int lparid,
* Currently we only support radix and non-zero LPCR only makes sense
* for hash tables so skiboot expects the LPCR parameter to be a zero.
*/
- ret = opal_npu_map_lpar(nphb->opal_id,
- PCI_DEVID(gpdev->bus->number, gpdev->devfn), lparid,
- 0 /* LPCR bits */);
+ ret = opal_npu_map_lpar(nphb->opal_id, pci_dev_id(gpdev), lparid,
+ 0 /* LPCR bits */);
if (ret) {
dev_err(>dev, "Error %d mapping device to LPAR\n", ret);
return ret;
@@ -1224,7 +1223,7 @@ int pnv_npu2_map_lpar_dev(struct pci_dev *gpdev, unsigned
int lparid,
dev_dbg(>dev, "init context opalid=%llu msr=%lx\n",
nphb->opal_id, msr);
ret = opal_npu_init_context(nphb->opal_id, 0/*__unused*/, msr,
- PCI_DEVID(gpdev->bus->number, gpdev->devfn));
+ pci_dev_id(gpdev));
if (ret < 0)
dev_err(>dev, "Failed to init context: %d\n", ret);
else
@@ -1258,7 +1257,7 @@ int pnv_npu2_unmap_lpar_dev(struct pci_dev *gpdev)
dev_dbg(>dev, "destroy context opalid=%llu\n",
nphb->opal_id);
ret = opal_npu_destroy_context(nphb->opal_id, 0/*__unused*/,
- PCI_DEVID(gpdev->bus->number, gpdev->devfn));
+ pci_dev_id(gpdev));
if (ret < 0) {
dev_err(>dev, "Failed to destroy context: %d\n", ret);
return ret;
@@ -1266,9 +1265,8 @@ int pnv_npu2_unmap_lpar_dev(struct pci_dev *gpdev)
/* Set LPID to 0 anyway, just to be safe */
dev_dbg(>dev, "Map LPAR opalid=%llu lparid=0\n", nphb->opal_id);
- ret = opal_npu_map_lpar(nphb->opal_id,
- PCI_DEVID(gpdev->bus->number, gpdev->devfn), 0 /*LPID*/,
- 0 /* LPCR bits */);
+ ret = opal_npu_map_lpar(nphb->opal_id, pci_dev_id(gpdev), 0 /*LPID*/,
+ 0 /* LPCR bits */);
if (ret)
dev_err(>dev, "Error %d mapping device to LPAR\n", ret);
--
2.21.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 0/9] PCI: add help pci_dev_id
In several places in the kernel we find PCI_DEVID used like this: PCI_DEVID(dev->bus->number, dev->devfn) Therefore create a helper for it. v2: - apply the change to all affected places in the kernel Heiner Kallweit (9): PCI: add helper pci_dev_id PCI: use helper pci_dev_id r8169: use new helper pci_dev_id powerpc/powernv/npu: use helper pci_dev_id drm/amdkfd: use helper pci_dev_id iommu/amd: use helper pci_dev_id iommu/vt-d: use helper pci_dev_id stmmac: pci: use helper pci_dev_id platform/chrome: chromeos_laptop: use helper pci_dev_id arch/powerpc/platforms/powernv/npu-dma.c | 14 ++ drivers/gpu/drm/amd/amdkfd/kfd_topology.c| 3 +-- drivers/iommu/amd_iommu.c| 2 +- drivers/iommu/intel-iommu.c | 2 +- drivers/iommu/intel_irq_remapping.c | 2 +- drivers/net/ethernet/realtek/r8169.c | 3 +-- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 2 +- drivers/pci/msi.c| 6 +++--- drivers/pci/search.c | 10 +++--- drivers/platform/chrome/chromeos_laptop.c| 2 +- include/linux/pci.h | 5 + 11 files changed, 24 insertions(+), 27 deletions(-) -- 2.21.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 3/9] r8169: use new helper pci_dev_id
Use new helper pci_dev_id() to simplify the code. Signed-off-by: Heiner Kallweit --- drivers/net/ethernet/realtek/r8169.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index efaea1a0a..ae476fe8d 100644 --- a/drivers/net/ethernet/realtek/r8169.c +++ b/drivers/net/ethernet/realtek/r8169.c @@ -7020,8 +7020,7 @@ static int r8169_mdio_register(struct rtl8169_private *tp) new_bus->priv = tp; new_bus->parent = >dev; new_bus->irq[0] = PHY_IGNORE_INTERRUPT; - snprintf(new_bus->id, MII_BUS_ID_SIZE, "r8169-%x", -PCI_DEVID(pdev->bus->number, pdev->devfn)); + snprintf(new_bus->id, MII_BUS_ID_SIZE, "r8169-%x", pci_dev_id(pdev)); new_bus->read = r8169_mdio_read_reg; new_bus->write = r8169_mdio_write_reg; -- 2.21.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 2/9] PCI: use helper pci_dev_id
Use new helper pci_dev_id() to simplify the code.
Signed-off-by: Heiner Kallweit
---
drivers/pci/msi.c| 6 +++---
drivers/pci/search.c | 10 +++---
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 73986825d..e039b740f 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1338,7 +1338,7 @@ irq_hw_number_t pci_msi_domain_calc_hwirq(struct pci_dev
*dev,
struct msi_desc *desc)
{
return (irq_hw_number_t)desc->msi_attrib.entry_nr |
- PCI_DEVID(dev->bus->number, dev->devfn) << 11 |
+ pci_dev_id(dev) << 11 |
(pci_domain_nr(dev->bus) & 0x) << 27;
}
@@ -1508,7 +1508,7 @@ static int get_msi_id_cb(struct pci_dev *pdev, u16 alias,
void *data)
u32 pci_msi_domain_get_msi_rid(struct irq_domain *domain, struct pci_dev *pdev)
{
struct device_node *of_node;
- u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn);
+ u32 rid = pci_dev_id(pdev);
pci_for_each_dma_alias(pdev, get_msi_id_cb, );
@@ -1531,7 +1531,7 @@ u32 pci_msi_domain_get_msi_rid(struct irq_domain *domain,
struct pci_dev *pdev)
struct irq_domain *pci_msi_get_device_domain(struct pci_dev *pdev)
{
struct irq_domain *dom;
- u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn);
+ u32 rid = pci_dev_id(pdev);
pci_for_each_dma_alias(pdev, get_msi_id_cb, );
dom = of_msi_map_get_device_domain(>dev, rid);
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index 2b5f72086..5c7922612 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -33,7 +33,7 @@ int pci_for_each_dma_alias(struct pci_dev *pdev,
struct pci_bus *bus;
int ret;
- ret = fn(pdev, PCI_DEVID(pdev->bus->number, pdev->devfn), data);
+ ret = fn(pdev, pci_dev_id(pdev), data);
if (ret)
return ret;
@@ -88,9 +88,7 @@ int pci_for_each_dma_alias(struct pci_dev *pdev,
return ret;
continue;
case PCI_EXP_TYPE_PCIE_BRIDGE:
- ret = fn(tmp,
-PCI_DEVID(tmp->bus->number,
- tmp->devfn), data);
+ ret = fn(tmp, pci_dev_id(tmp), data);
if (ret)
return ret;
continue;
@@ -101,9 +99,7 @@ int pci_for_each_dma_alias(struct pci_dev *pdev,
PCI_DEVID(tmp->subordinate->number,
PCI_DEVFN(0, 0)), data);
else
- ret = fn(tmp,
-PCI_DEVID(tmp->bus->number,
- tmp->devfn), data);
+ ret = fn(tmp, pci_dev_id(tmp), data);
if (ret)
return ret;
}
--
2.21.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 1/9] PCI: add helper pci_dev_id
In several places in the kernel we find PCI_DEVID used like this:
PCI_DEVID(dev->bus->number, dev->devfn) Therefore create a helper
for it.
Signed-off-by: Heiner Kallweit
---
include/linux/pci.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2c056a7a7..28d0313a3 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -598,6 +598,11 @@ struct pci_bus {
#define to_pci_bus(n) container_of(n, struct pci_bus, dev)
+static inline u16 pci_dev_id(struct pci_dev *dev)
+{
+ return PCI_DEVID(dev->bus->number, dev->devfn);
+}
+
/*
* Returns true if the PCI bus is root (behind host-PCI bridge),
* false otherwise
--
2.21.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu: simplify and fix ida handling
Am 04.07.2016 um 13:46 schrieb Joerg Roedel: > On Wed, Jun 29, 2016 at 09:13:59PM +0200, Heiner Kallweit wrote: >> Ida handling can be much simplified by using the ida_simple_.. functions. >> >> This change also fixes the bug that previously checking for errors >> returned by ida_get_new() was incomplete. >> ida_get_new() can return errors other than EAGAIN, e.g. ENOSPC. >> This case wasn't handled. >> >> Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> >> --- >> drivers/iommu/iommu.c | 24 ++-- >> 1 file changed, 6 insertions(+), 18 deletions(-) > > The patch does not apply. Please rebase it against the latest upstream > kernel and resend. > This patch applies on top of patch "[PATCH 1/3] iommu: simplify init function" I submitted on June 28th. Do you have an opinion on that patch? Regards, Heiner ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu: simplify and fix ida handling
Ida handling can be much simplified by using the ida_simple_.. functions.
This change also fixes the bug that previously checking for errors
returned by ida_get_new() was incomplete.
ida_get_new() can return errors other than EAGAIN, e.g. ENOSPC.
This case wasn't handled.
Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com>
---
drivers/iommu/iommu.c | 24 ++--
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index debce45..4d3c4a8 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -35,7 +35,6 @@
static struct kset *iommu_group_kset;
static DEFINE_IDA(iommu_group_ida);
-static DEFINE_MUTEX(iommu_group_mutex);
struct iommu_callback_data {
const struct iommu_ops *ops;
@@ -144,9 +143,7 @@ static void iommu_group_release(struct kobject *kobj)
if (group->iommu_data_release)
group->iommu_data_release(group->iommu_data);
- mutex_lock(_group_mutex);
- ida_remove(_group_ida, group->id);
- mutex_unlock(_group_mutex);
+ ida_simple_remove(_group_ida, group->id);
if (group->default_domain)
iommu_domain_free(group->default_domain);
@@ -186,26 +183,17 @@ struct iommu_group *iommu_group_alloc(void)
INIT_LIST_HEAD(>devices);
BLOCKING_INIT_NOTIFIER_HEAD(>notifier);
- mutex_lock(_group_mutex);
-
-again:
- if (unlikely(0 == ida_pre_get(_group_ida, GFP_KERNEL))) {
+ ret = ida_simple_get(_group_ida, 0, 0, GFP_KERNEL);
+ if (ret < 0) {
kfree(group);
- mutex_unlock(_group_mutex);
- return ERR_PTR(-ENOMEM);
+ return ERR_PTR(ret);
}
-
- if (-EAGAIN == ida_get_new(_group_ida, >id))
- goto again;
-
- mutex_unlock(_group_mutex);
+ group->id = ret;
ret = kobject_init_and_add(>kobj, _group_ktype,
NULL, "%d", group->id);
if (ret) {
- mutex_lock(_group_mutex);
- ida_remove(_group_ida, group->id);
- mutex_unlock(_group_mutex);
+ ida_simple_remove(_group_ida, group->id);
kfree(group);
return ERR_PTR(ret);
}
--
2.9.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/3] iommu: remove unneeded check
Am 29.06.2016 um 00:07 schrieb Alex Williamson: > On Tue, 28 Jun 2016 23:37:06 +0200 > Heiner Kallweit <hkallwe...@gmail.com> wrote: > >> Am 28.06.2016 um 22:09 schrieb Alex Williamson: >>> On Tue, 28 Jun 2016 20:40:37 +0200 >>> Heiner Kallweit <hkallwe...@gmail.com> wrote: >>> >>>> The init function ensures that iommu_group_kset can't be NULL. >>>> Therefore this check isn't needed. >>> >>> Have you seen your previous patch? Wasn't this claim that the init >>> function ensures iommu_group_kset more true when iommu_init() called >>> BUG_ON(!iommu_group_kset) than it is when we can get by with just >>> returning -ENOMEM? Thanks, >>> >> Uh, you're right. I was in "module mode" where initcall retvals are >> assessed. Here the initcall retval is ignored. >> If we leave the BUG_ON in however then the check is actually unneeded >> as the system is halted after the BUG_ON. >> So please disregard patch 2 of the series. >> By the way: >> This check is in iommu_group_get_by_id() and this function doesn't seem >> to have any user in the kernel. It was added about three years ago. >> Is the original intention of this function obsolete meanwhile? > > > Alexey, this is a question for you. Did the user of this function > never materialize: > > commit aa16bea929aed6ea854b55d2be8306a9fb40e694 > Author: Alexey Kardashevskiy <a...@ozlabs.ru> > Date: Mon Mar 25 10:23:49 2013 +1100 > > iommu: Add a function to find an iommu group by id > > As IOMMU groups are exposed to the user space by their numbers, > the user space can use them in various kernel APIs so the kernel > might need an API to find a group by its ID. > > As an example, QEMU VFIO on PPC64 platform needs it to associate > a logical bus number (LIOBN) with a specific IOMMU group in order > to support in-kernel handling of DMA map/unmap requests. > > The patch adds the iommu_group_get_by_id(id) function which performs > such search. > > If not, let's remove it. Dead code is broken code. Thanks, > > Alex > And also disregard patch 3 of the series until we have a decision how to go on with iommu_group_get_by_id(id). >>>> Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> >>>> --- >>>> drivers/iommu/iommu.c | 3 --- >>>> 1 file changed, 3 deletions(-) >>>> >>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c >>>> index b36ec9c..b36e24d 100644 >>>> --- a/drivers/iommu/iommu.c >>>> +++ b/drivers/iommu/iommu.c >>>> @@ -235,9 +235,6 @@ struct iommu_group *iommu_group_get_by_id(int id) >>>>struct iommu_group *group; >>>>const char *name; >>>> >>>> - if (!iommu_group_kset) >>>> - return NULL; >>>> - >>>>name = kasprintf(GFP_KERNEL, "%d", id); >>>>if (!name) >>>>return NULL; >>> >>> >> > > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/3] iommu: remove unneeded check
Am 28.06.2016 um 22:09 schrieb Alex Williamson: > On Tue, 28 Jun 2016 20:40:37 +0200 > Heiner Kallweit <hkallwe...@gmail.com> wrote: > >> The init function ensures that iommu_group_kset can't be NULL. >> Therefore this check isn't needed. > > Have you seen your previous patch? Wasn't this claim that the init > function ensures iommu_group_kset more true when iommu_init() called > BUG_ON(!iommu_group_kset) than it is when we can get by with just > returning -ENOMEM? Thanks, > Uh, you're right. I was in "module mode" where initcall retvals are assessed. Here the initcall retval is ignored. If we leave the BUG_ON in however then the check is actually unneeded as the system is halted after the BUG_ON. By the way: This check is in iommu_group_get_by_id() and this function doesn't seem to have any user in the kernel. It was added about three years ago. Is the original intention of this function obsolete meanwhile? Thanks, Heiner > Alex > >> Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> >> --- >> drivers/iommu/iommu.c | 3 --- >> 1 file changed, 3 deletions(-) >> >> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c >> index b36ec9c..b36e24d 100644 >> --- a/drivers/iommu/iommu.c >> +++ b/drivers/iommu/iommu.c >> @@ -235,9 +235,6 @@ struct iommu_group *iommu_group_get_by_id(int id) >> struct iommu_group *group; >> const char *name; >> >> -if (!iommu_group_kset) >> -return NULL; >> - >> name = kasprintf(GFP_KERNEL, "%d", id); >> if (!name) >> return NULL; > > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 3/3] iommu: remove unneeded check
The init function ensures that iommu_group_kset can't be NULL. Therefore this check isn't needed. Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com> --- drivers/iommu/iommu.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index b36ec9c..b36e24d 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -235,9 +235,6 @@ struct iommu_group *iommu_group_get_by_id(int id) struct iommu_group *group; const char *name; - if (!iommu_group_kset) - return NULL; - name = kasprintf(GFP_KERNEL, "%d", id); if (!name) return NULL; -- 2.9.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 2/3] iommu: improve handling of failed call to kset_create_and_add
If kset_create_and_add fails then most likely due to out-of-memory.
There's not necessarily a bug somewhere.
Therefore I think we shouldn't use BUG_ON and simply return -ENOMEM.
That's also what other callers of kset_create_and_add do.
Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com>
---
drivers/iommu/iommu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index debce45..b36ec9c 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1483,9 +1483,7 @@ static int __init iommu_init(void)
{
iommu_group_kset = kset_create_and_add("iommu_groups",
NULL, kernel_kobj);
- BUG_ON(!iommu_group_kset);
-
- return 0;
+ return iommu_group_kset ? 0 : -ENOMEM;
}
core_initcall(iommu_init);
--
2.9.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
