ta_update_affinity, this commit updates the remaining code that
> either did not modify the cpumask or immediately passed the modified
> mask to irq_set_affinity.
When we refer to functions, we use parentheses, e.g. func().
--
With Best Regards,
Andy Shevchenko
_
flag for all serial drivers that at DT based. This way,
> fw_devlink will know not to delay the probing of the consoles past
> kernel boot.
Same question, do you think only serial drivers need that?
--
With Best Regards,
Andy Shevchenko
___
iommu
ole
> probe times back to how they were before the deferred_probe_timeout
> clean up series[2].
Are you sure it's only limited to the serial drivers?
(just asking, I don't know myself the answer)
--
With Best Regards,
Andy Shevchenko
___
of dependencies and then simply follow it. But actually it should
be more than 1 graph, because there are resources and there are power, clock and
resets that may be orthogonal to the higher dependencies (like driver X provides
a resource to driver Y).
--
With Best
ic hardware property for all operating
> systems so it could be a DT property such as dma-weak-dependency?
> Or maybe compromize and add a linux,dma-weak-dependency;
> property?
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
redesigning this to be more robust.
> but is not broken and it's more efficient
> than looking for pinctrl-%d or adding more pinctrl-xx entries. So,
> let's fix it if it actually breaks? Not going to oppose a patch if
> anyone wants to make it more complete.
>
> > > where driver_deferred_probe_check_state() is called before the supplier
> > > has probed successfully or before deferred probe timeout has expired.
> > >
> > > So, delete the call and replace it with -ENODEV.
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
sup);
> void fwnode_links_purge(struct fwnode_handle *fwnode);
> void fw_devlink_purge_absent_suppliers(struct fwnode_handle *fwnode);
> +void __init fw_devlink_unblock_may_probe(void);
I don't think you need init.h and __init here. Important is that you
have it in the C-file. Am I wrong?
--
With Best Regard
On Tue, Feb 15, 2022 at 09:31:37AM +0800, Lu Baolu wrote:
> On 2/14/22 9:27 PM, Joerg Roedel wrote:
> > On Mon, Feb 07, 2022 at 04:12:40PM +0200, Andy Shevchenko wrote:
...
> > > +extern const struct iommu_ops intel_iommu_ops;
> > The intel_iommu_ops symbol is only use
d use.
Fixes: 6ee1b77ba3ac ("iommu/vt-d: Add svm/sva invalidate function")
Signed-off-by: Andy Shevchenko
---
drivers/iommu/intel/iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 92fea3fbbb1
On Mon, Feb 07, 2022 at 04:12:40PM +0200, Andy Shevchenko wrote:
> Compiler is not happy about hidden declaration of intel_iommu_ops.
>
> .../iommu.c:414:24: warning: symbol 'intel_iommu_ops' was not declared.
> Should it be static?
>
> Move declaration to header
On Tue, Feb 08, 2022 at 11:06:56PM -0800, Christoph Hellwig wrote:
> On Mon, Feb 07, 2022 at 03:55:32PM +, Robin Murphy wrote:
> > On 2022-02-07 14:13, Andy Shevchenko wrote:
> > > Use DMA ops setter instead of direct assignment. Even we know that
> > > this modul
Use DMA ops setter instead of direct assignment. Even we know that
this module doesn't perform access to the dma_ops member of struct device,
it's better to use setter to avoid potential problems in the future.
Signed-off-by: Andy Shevchenko
---
v2: rebased on top of the latest codebas
Compiler is not happy about hidden declaration of intel_iommu_ops.
.../iommu.c:414:24: warning: symbol 'intel_iommu_ops' was not declared. Should
it be static?
Move declaration to header file to make compiler happy.
Signed-off-by: Andy Shevchenko
---
v2: made sure it compiles with I
On Fri, Jul 30, 2021 at 10:20:08AM +0800, Lu Baolu wrote:
> Hi Andy,
>
> On 7/30/21 12:35 AM, Andy Shevchenko wrote:
> > Compiler is not happy about hidden declaration of intel_iommu_ops.
> >
> > .../drivers/iommu/intel/iommu.c:414:24: warning: symbol 'intel_
urn -EINVAL;
> + }
> +
> + rmem->ops = &rmem_swiotlb_ops;
> + pr_info("Reserved memory: created restricted DMA pool at %pa, size
> %ld MiB\n",
> + &rmem->base, (unsigned long)rmem->size / SZ_1M);
Oh là là, besides explici
On Wed, Aug 11, 2021 at 10:02:48PM +0800, Lu Baolu wrote:
> On 2021/8/11 21:49, Andy Shevchenko wrote:
> > On Fri, Jul 30, 2021 at 09:01:41PM +0800, Lu Baolu wrote:
> > > On 2021/7/30 16:05, Andy Shevchenko wrote:
> > > > On Fri, Jul 30, 2021 at 10:20:08AM +0800, Lu
On Fri, Jul 30, 2021 at 09:01:41PM +0800, Lu Baolu wrote:
> On 2021/7/30 16:05, Andy Shevchenko wrote:
> > On Fri, Jul 30, 2021 at 10:20:08AM +0800, Lu Baolu wrote:
> > > On 7/30/21 12:35 AM, Andy Shevchenko wrote:
> > > > Compiler is not happy about hidden
On Fri, Jul 30, 2021 at 10:20:08AM +0800, Lu Baolu wrote:
> On 7/30/21 12:35 AM, Andy Shevchenko wrote:
> > Compiler is not happy about hidden declaration of intel_iommu_ops.
> >
> > .../drivers/iommu/intel/iommu.c:414:24: warning: symbol 'intel_iommu_ops'
>
Compiler is not happy about hidden declaration of intel_iommu_ops.
.../drivers/iommu/intel/iommu.c:414:24: warning: symbol 'intel_iommu_ops' was
not declared. Should it be static?
Move declaration to header file to make compiler happy.
Signed-off-by: Andy Shevchenko
---
drivers/i
annotation since the top comment is not in the required format.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/intel/perf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel/perf.c b/drivers/iommu/intel/perf.c
index 73b7ec705552..0e8e03252d92 100644
--- a
On Tue, Apr 20, 2021 at 05:37:27PM +0300, Sakari Ailus wrote:
> On Tue, Apr 20, 2021 at 02:55:33PM +0300, Andy Shevchenko wrote:
> > On Tue, Apr 20, 2021 at 01:56:40PM +0300, Sakari Ailus wrote:
> > > On Tue, Apr 20, 2021 at 06:34:26PM +0800, Bingbu Cao wrote:
> > >
On Tue, Apr 20, 2021 at 01:56:40PM +0300, Sakari Ailus wrote:
> On Tue, Apr 20, 2021 at 06:34:26PM +0800, Bingbu Cao wrote:
> > On 4/20/21 6:20 PM, Andy Shevchenko wrote:
> > > On Tue, Apr 20, 2021 at 10:48:33AM +0800, Bingbu Cao wrote:
...
> > > This misses the change
'm wondering if IPU MMU should be described properly in the DMAR table.
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
>
> Fixes: 26f5689592e2 ("media: staging/intel-ipu3: mmu: Implement driver")
> Signed-off-by: Bingbu Cao
> ---
> drivers/iommu/intel/iommu.c | 29 +
This misses the changelog from v1 followed by the expla
\n");
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
ev_warn(dev->dev, "dma_set_min_align_mask failed to reset
> offset\n");
> + goto out_free_sg;
> + }
Seems like rebasing effect which makes empty line goes in the middle of some
other group of code lines.
> if (!nr_mapped)
>
(size) {
> + size = ALIGN(size, 1 << IO_TLB_SHIFT);
> + io_tlb_nslabs = size >> IO_TLB_SHIFT;
> + io_tlb_nslabs = ALIGN(io_tlb_nslabs,
> IO_TLB_SEGSIZE);
> +
> + pr_info("architecture adjusted SWIOTLB slabs =
> %lu\n",
> + io_tlb_nslabs);
> + }
> + }
> +}
> +
> void swiotlb_print_info(void)
> {
> unsigned long bytes = io_tlb_nslabs << IO_TLB_SHIFT;
> --
> 2.17.1
>
>
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Wed, Sep 02, 2020 at 11:02:46PM -0300, Fabio Estevam wrote:
> On Wed, Sep 2, 2020 at 2:31 PM Andy Shevchenko
> wrote:
> >
> > There is an extension to a %p to print phys_addr_t type of variables.
> > Use it here.
> >
> > Signed-off-by: Andy Shevchenko
>
Sparse is not happy about max_segment declaration:
CHECK kernel/dma/swiotlb.c
kernel/dma/swiotlb.c:96:14: warning: symbol 'max_segment' was not declared.
Should it be static?
Mark it static as suggested.
Signed-off-by: Andy Shevchenko
---
v2: no change
kernel/dma/swiotlb.c
There is an extension to a %p to print phys_addr_t type of variables.
Use it here.
Signed-off-by: Andy Shevchenko
---
v2: dropped bytes replacement (Fabio)
kernel/dma/swiotlb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
)
| ^~~
Since it's used outside of the module, move its declaration to the header
from the user.
Signed-off-by: Andy Shevchenko
---
v2: no change
arch/x86/pci/sta2x11-fixup.c | 1 -
include/linux/swiotlb.h | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --
On Sat, Aug 29, 2020 at 07:58:46AM +0100, Christoph Hellwig wrote:
> On Fri, Aug 28, 2020 at 07:05:02PM +0300, Andy Shevchenko wrote:
> > Compiler is not happy about hidden declaration of intel_iommu_ops.
> >
> > .../drivers/iommu/intel/iommu.c:414:24: warning: symbol '
Static analyzer is not happy about intel_iommu_gfx_mapped declaration:
.../drivers/iommu/intel/iommu.c:364:5: warning: symbol 'intel_iommu_gfx_mapped'
was not declared. Should it be static?
Move its declaration to Intel IOMMU header file.
Signed-off-by: Andy Shevchenko
---
include
Compiler is not happy about hidden declaration of intel_iommu_ops.
.../drivers/iommu/intel/iommu.c:414:24: warning: symbol 'intel_iommu_ops' was
not declared. Should it be static?
Move declaration to header file to make compiler happy.
Signed-off-by: Andy Shevchenko
---
drivers/i
Use DMA ops setter instead of direct assignment. Even we know that
this module doesn't perform access to the dma_ops member of struct device,
it's better to use setter to avoid potential problems in the future.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/dma-iommu.c | 2 +-
1 fi
> + }
Wouldn't be better to do an assignment of offset here?
> + if (!offset)
> + return 0;
> +
> + map = kcalloc(2, sizeof(*map), GFP_KERNEL);
> + if (!map)
> + return -ENOMEM;
> + map[0].cpu_start = cpu_start;
> + m
On Thu, Aug 20, 2020 at 09:37:12AM -0400, Jim Quinlan wrote:
> On Tue, Aug 18, 2020 at 4:14 AM Andy Shevchenko
> wrote:
> > On Mon, Aug 17, 2020 at 05:53:09PM -0400, Jim Quinlan wrote:
...
> > > +static inline u64 dma_offset_from_dma_addr(struct device *dev,
>
On Wed, Aug 19, 2020 at 02:24:10PM -0300, Fabio Estevam wrote:
> On Wed, Aug 19, 2020 at 2:16 PM Andy Shevchenko
> wrote:
>
> > - unsigned long bytes = io_tlb_nslabs << IO_TLB_SHIFT;
> > + unsigned long mb = (io_tlb_nslabs << IO_TLB_SHIFT) >>
Sparse is not happy about max_segment declaration:
CHECK kernel/dma/swiotlb.c
kernel/dma/swiotlb.c:96:14: warning: symbol 'max_segment' was not declared.
Should it be static?
Mark it static as suggested.
Signed-off-by: Andy Shevchenko
---
kernel/dma/swiotlb.c | 2 +-
1 file
)
| ^~~
Since it's used outside of the module, move its declaration to the header
from the user.
Signed-off-by: Andy Shevchenko
---
arch/x86/pci/sta2x11-fixup.c | 3 ++-
include/linux/swiotlb.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x8
There is an extension to a %p to print phys_addr_t type of variables.
Use it here.
Signed-off-by: Andy Shevchenko
---
kernel/dma/swiotlb.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index c19379fabd20..676ccf0e49d3
ap)
> +{
> + int num_ranges;
> + struct bus_dma_region *new_map;
> + const struct bus_dma_region *r = map;
> +
> + for (num_ranges = 0; r->size; num_ranges++)
> + r++;
> + new_map = kcalloc(num_ranges + 1, sizeof(*map), GFP_KERNEL);
> + if (new_map)
> + memcpy(new_map, map, sizeof(*map) * num_ranges);
Looks like krealloc() on the first glance...
> +
> + return new_map;
> +}
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
ap) : 0;
PTR_ERR_OR_ZERO()
...
> + = dma_offset_from_phys_addr(dev,
> PFN_PHYS(mem->pfn_base));
> +
> + return (dma_addr_t)PFN_PHYS(mem->pfn_base) - dma_offset;
Looking at this more, I think you need to introduce in the same header (pfn.h)
s
On Thu, Jun 18, 2020 at 6:04 PM Rajat Jain wrote:
> On Thu, Jun 18, 2020 at 2:14 AM Andy Shevchenko
> wrote:
...
> To clarify, the attribute exposed by the firmware today is
> "ExternalFacingPort" and "external-facing" respectively:
>
> 617654aae50e ("
On Thu, Jun 18, 2020 at 11:36 AM Greg Kroah-Hartman
wrote:
>
> On Thu, Jun 18, 2020 at 11:12:56AM +0300, Andy Shevchenko wrote:
> > On Wed, Jun 17, 2020 at 10:56 PM Rajat Jain wrote:
> > > On Wed, Jun 17, 2020 at 12:31 AM Christoph Hellwig
> > > wrote:
> >
&
hosen by the meaning of it.
What external does mean for M.2. WWAN card in my laptop? It's in ACPI
tables, but I can replace it.
This is only one example. Or if firmware of some device is altered,
and it's internal (whatever it means) is it trusted or not?
So, please leave it as i
On Mon, Jun 08, 2020 at 11:48:51AM -0400, Jim Quinlan wrote:
> On Sun, Jun 7, 2020 at 12:500f9bfe0fb8840b268af1bbcc51f1cd440514e PM
> Andy Shevchenko wrote:
> > On Fri, Jun 05, 2020 at 05:26:48PM -0400, Jim Quinlan wrote:
...
> > > + *map_size = (num_range
u_addr)
> + - PFN_DOWN(range.bus_addr);
Ditto (indentation).
...
> + unsigned long dma_pfn_offset
> + = dma_pfn_offset_from_phys_addr(dev, paddr);
Ditto.
...
> + unsigned long dma_pfn_offset
> +
in the kernel.
For example, above line is like
pfn = PFN_DOWN(phys);
...
> > > + if (!WARN_ON(!dev) && dev->dma_pfn_offset_map)
> > > + *dma_handle -= PFN_PHYS(
> > > + dma_pfn_offset_from_phys_addr(dev, phys
device *dev,
> + dma_addr_t dma_addr)
> +{
> + return 0;
> +}
> +
> +static inline unsigned long dma_pfn_offset_from_phys_addr(struct device *dev,
> + phys_add
is buffer will be
> zeroed. If we pass in a null string, acpi_dev_hid_uid_match will return
acpi_dev_hid_uid_match()
> false because it will try and match an empty string to the ACPI UID of
> the device.
Thank you for testing and producing a patch! My comments below, after addressing
Re
Unify format of the printed messages, i.e. replace printk(LEVEL ... )
with pr_level(...).
Signed-off-by: Andy Shevchenko
---
drivers/iommu/amd_iommu_types.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/amd_iommu_types.h b/drivers/iommu
Unify format of the printed messages, i.e. replace printk(LEVEL ... )
with pr_level(...).
Signed-off-by: Andy Shevchenko
---
drivers/iommu/iova.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 0e6a9536eca62
Unify format of the printed messages, i.e. replace printk(LEVEL ... )
with pr_level(...).
Signed-off-by: Andy Shevchenko
---
drivers/iommu/intel-iommu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index
On Mon, Oct 07, 2019 at 05:28:48PM +0200, Joerg Roedel wrote:
> On Tue, Sep 24, 2019 at 10:37:39PM +0300, Andy Shevchenko wrote:
> > Since we have a generic helper, drop custom implementation in the driver.
> >
> > Signed-off-by: Andy Shevchenko
> > ---
> >
On Thu, Oct 03, 2019 at 12:00:29PM +0200, Ulf Hansson wrote:
> On Tue, 1 Oct 2019 at 16:27, Andy Shevchenko
> wrote:
> >
> > There are few users outside of ACPI realm that re-introduce a custom
> > solution to match ACPI device against HID/UID. Add a generic helper f
Since we have a generic helper, drop custom implementation in the driver.
Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
---
drivers/mmc/host/sdhci-acpi.c | 49 ---
1 file changed, 16 insertions(+), 33 deletions(-)
diff --git a/drivers/mmc/host
There are users outside of ACPI realm which reimplementing the comparator
function to check if the given device matches to given HID and UID.
For better utilization, introduce a helper for everyone to use.
Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
---
drivers/acpi/utils.c
Since we have a generic helper, drop custom implementation in the driver.
Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
---
drivers/iommu/amd_iommu.c | 30 +-
1 file changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b
oduce acpi_dev_get_first_match_dev() helper")
Reported-by: kbuild test robot
Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
---
include/acpi/acpi_bus.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_b
acpi/utils.c:513: warning: Function parameter or member 'fmt' not
described in '__acpi_handle_debug'
Describe function parameters where it's appropriate.
Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
---
drivers/acpi/utils.c | 7 +++
1 file changed, 7
Since we have a generic helper, drop custom implementation in the driver.
Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
---
drivers/acpi/acpi_lpss.c | 21 +++--
1 file changed, 3 insertions(+), 18 deletions(-)
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi
tch 2 due to latent issue in the header (lkp)
- get rid of match_hid_uid() completely in patch 6
Andy Shevchenko (6):
ACPI / utils: Describe function parameters in kernel-doc
ACPI / utils: Move acpi_dev_get_first_match_dev() under CONFIG_ACPI
ACPI / utils: Introduce acpi_dev_hid_uid_match() h
On Tue, Oct 01, 2019 at 03:37:08PM +0300, Adrian Hunter wrote:
> On 24/09/19 10:37 PM, Andy Shevchenko wrote:
> > Since we have a generic helper, drop custom implementation in the driver.
> > - if (strcmp(hid, "QCOM8051"))
> > + if (acpi_dev_hid_uid_match(adev
On Tue, Oct 01, 2019 at 12:38:54PM +0300, Mika Westerberg wrote:
> On Tue, Sep 24, 2019 at 10:37:36PM +0300, Andy Shevchenko wrote:
> > There are users outside of ACPI realm which reimplementing the comparator
> > function to check if the given device matches to given HID and UI
oduce acpi_dev_get_first_match_dev() helper")
Reported-by: kbuild test robot
Signed-off-by: Andy Shevchenko
---
include/acpi/acpi_bus.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 175f7b40c585..3f6fddeb7519 10
There are users outside of ACPI realm which reimplementing the comparator
function to check if the given device matches to given HID and UID.
For better utilization, introduce a helper for everyone to use.
Signed-off-by: Andy Shevchenko
---
drivers/acpi/utils.c| 25
Since we have a generic helper, drop custom implementation in the driver.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/amd_iommu.c | 30 +-
1 file changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index
Since we have a generic helper, drop custom implementation in the driver.
Signed-off-by: Andy Shevchenko
---
drivers/mmc/host/sdhci-acpi.c | 49 ---
1 file changed, 16 insertions(+), 33 deletions(-)
diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host
acpi/utils.c:513: warning: Function parameter or member 'fmt' not
described in '__acpi_handle_debug'
Describe function parameters where it's appropriate.
Signed-off-by: Andy Shevchenko
---
drivers/acpi/utils.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/dr
in patch 6
Andy Shevchenko (6):
ACPI / utils: Describe function parameters in kernel-doc
ACPI / utils: Move acpi_dev_get_first_match_dev() under CONFIG_ACPI
ACPI / utils: Introduce acpi_dev_hid_uid_match() helper
ACPI / LPSS: Switch to use acpi_dev_hid_uid_match()
mmc: sdhci-acpi: Switch
Since we have a generic helper, drop custom implementation in the driver.
Signed-off-by: Andy Shevchenko
---
drivers/acpi/acpi_lpss.c | 21 +++--
1 file changed, 3 insertions(+), 18 deletions(-)
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index d696f165a50e
On Tue, Sep 24, 2019 at 03:01:53PM +0300, Andy Shevchenko wrote:
> Since we have a generic helper, drop custom implementation in the driver.
Actually we may get rid of match_hid_uid() completely and thus slightly speed
up get_acpihid_device_id().
I'll wait for other comments and then
There are users outside of ACPI realm which reimplementing the comparator
function to check if the given device matches to given HID and UID.
For better utilization, introduce a helper for everyone to use.
Signed-off-by: Andy Shevchenko
---
drivers/acpi/utils.c| 25
acpi/utils.c:513: warning: Function parameter or member 'fmt' not
described in '__acpi_handle_debug'
Describe function parameters where it's appropriate.
Signed-off-by: Andy Shevchenko
---
drivers/acpi/utils.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/dr
Since we have a generic helper, drop custom implementation in the driver.
Signed-off-by: Andy Shevchenko
---
drivers/acpi/acpi_lpss.c | 21 +++--
1 file changed, 3 insertions(+), 18 deletions(-)
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index d696f165a50e
Since we have a generic helper, drop custom implementation in the driver.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/amd_iommu.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 61de81965c44
Since we have a generic helper, drop custom implementation in the driver.
Signed-off-by: Andy Shevchenko
---
drivers/mmc/host/sdhci-acpi.c | 49 ---
1 file changed, 16 insertions(+), 33 deletions(-)
diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host
On Thu, Aug 15, 2019 at 11:52 PM Jacob Pan
wrote:
>
> Use combined macros for_each_svm_dev() to simplify SVM device iteration
> and error checking.
>
> Suggested-by: Andy Shevchenko
> Signed-off-by: Jacob Pan
> Reviewed-by: Eric Auger
> ---
> dri
e second patch introduces macros that are used during PASID
> table walk and the third patch actually adds support to dump scalable mode
> DMAR
> table.
FWIW,
Reviewed-by: Andy Shevchenko
Since it's debugfs the format is not carved in stone.
>
> Sai Praneeth (3):
> i
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/intel_irq_remapping.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers
Christoph Hellwig
Signed-off-by: Andy Shevchenko
---
v2: Move to kernel/dma/Kconfig directly
kernel/dma/Kconfig | 36
lib/Kconfig.debug | 36
2 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/kernel/dma
On Mon, Feb 11, 2019 at 04:54:50PM +0100, Christoph Hellwig wrote:
> On Mon, Feb 11, 2019 at 05:54:09PM +0200, Andy Shevchenko wrote:
> > This is a follow up to the commit cf65a0f6f6ff
> >
> > ("dma-mapping: move all DMA mapping code to kernel/dma")
> >
&
Christoph Hellwig
Signed-off-by: Andy Shevchenko
---
kernel/dma/Kconfig | 2 ++
kernel/dma/Kconfig.debug | 36
lib/Kconfig.debug| 36
3 files changed, 38 insertions(+), 36 deletions(-)
create mode 100644
generic arch
> implementation and could cause issues. What do you think?
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
the above code using it too first, followed by this change in dcdbas.
Wait... It sounds to me like a part of arch code where we define
arch_setup_pdev_archdata() and use this dummy domain.
Though dummy domain definition should come from IOMMU framework.
--
With Best Regards,
Andy Shevchenko
__
On Tue, Dec 4, 2018 at 11:26 PM Tony Battersby wrote:
>
> On 12/4/18 3:30 PM, Andy Shevchenko wrote:
> > On Tue, Dec 4, 2018 at 10:18 PM Matthew Wilcox wrote:
> >> On Tue, Dec 04, 2018 at 12:14:43PM -0800, Andrew Morton wrote:
> >>> Also, Andy had issues with the
me ago.
If I _was_ in Cc list and didn't comment, I'm fine with it.
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
boundary) / size;
If boundary is guaranteed to be power of 2, this can avoid cost
divisions (though it's a slow path anyway).
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
ize_t' when counting all
> the blocks in the entire pool.
> else if ((boundary < size) || (boundary & (boundary - 1)))
> return NULL;
Just a side note: in above it's is_power_of_2() opencoded.
--
With Best Regards,
Andy Shevchenko
__
On Fri, Aug 3, 2018 at 8:03 PM, Tony Battersby wrote:
> On 08/03/2018 12:22 PM, Matthew Wilcox wrote:
>> On Fri, Aug 03, 2018 at 06:59:20PM +0300, Andy Shevchenko wrote:
>>>>>> I'm pretty sure this was created in an order to avoid bad looking (and
>>>&g
On Fri, Aug 3, 2018 at 6:59 PM, Andy Shevchenko
wrote:
> On Fri, Aug 3, 2018 at 6:17 PM, Tony Battersby wrote:
>> But then I decided to simplify it to just use dev_err(). I still have
>> the old version. When I submit v3 of the patchset, which would you prefer?
>
> JFYI
On Fri, Aug 3, 2018 at 6:17 PM, Tony Battersby wrote:
> On 08/03/2018 09:41 AM, Tony Battersby wrote:
>> On 08/03/2018 04:56 AM, Andy Shevchenko wrote:
>>> On Thu, Aug 2, 2018 at 10:57 PM, Tony Battersby
>>> wrote:
>>>> Remove code duplication in error
st_head page_list[POOL_N_LISTS];
To be consistent with naming scheme and common practice I would rather
name the last one as
POOL_MAX_IDX 2
> + INIT_LIST_HEAD(&retval->page_list[0]);
> + INIT_LIST_HEAD(&retval->page_list[1]);
You introduced defines and don&#
rval) busy
Have you checked a history of this?
I'm pretty sure this was created in an order to avoid bad looking (and
in some cases frightening) "NULL device *" part.
If it it's the case, I would rather leave it as is, and even not the
case, I'm slightly more
make the lists singly-linked instead of doubly-linked
>> to save space.
>>
>
> I managed to redo my dma_pool_alloc() patch to make avail_page_list
> singly-linked instead of doubly-linked.
Are you relying on llist.h implementation?
Btw, did you see quicklist.h
Use proper %p extensions for the DMA addresses:
https://elixir.bootlin.com/linux/latest/source/Documentation/core-api/printk-formats.rst#L150
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
one?
It seems you are relying on the fact that in the list should be either
0 or 1 page. In that case what's the point to have a list?
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
we might switch to
def_bool y
instead of two lines.
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
> see:
> https://elixir.bootlin.com/linux/v4.14.2/source/drivers/usb/host/xhci-
> mem.c#L52
>
> prints above are custom traces added right after dma_pool_zalloc()
For better understanding it would be good to have dma_pool_free() calls
debugged as well.
Is it possi
1 - 100 of 151 matches
Mail list logo
