strtobool() does check for NULL parameter already. No need to repeat.
While here, switch to kstrtobool() and unshadow actual error code
(which is still -EINVAL).
No functional change intended.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/iommu.c | 6 --
1 file changed, 4 insertions
ze_t size,
> void *kvaddr;
> int need_coh = 1, need_kvaddr = 0;
>
> - page = alloc_pages(gfp, order);
> + page = alloc_pages(gfp | __GFP_ZERO, order);
>
> if (!page)
> return NULL;
> ->8-
>
> Bes
On Wed, Mar 14, 2018 at 5:24 PM, Gary R Hook wrote:
> On 03/13/2018 03:23 PM, Andy Shevchenko wrote:
>>>>> +#include
>>>>> +#include
>>>>> +#include
>>>> Keep in order?
>>> What order would that be? These few needed files
On Tue, Mar 13, 2018 at 8:54 PM, Gary R Hook wrote:
> On 03/13/2018 12:20 PM, Andy Shevchenko wrote:
>>> + } else if (obuf[0] == '0' && obuf[1] == 'x') {
>>> + n = sscanf(obuf, "%x", &amd_iommu_devid)
On Tue, Mar 13, 2018 at 8:54 PM, Gary R Hook wrote:
> On 03/13/2018 12:16 PM, Andy Shevchenko wrote:
>> On Fri, Mar 9, 2018 at 2:50 AM, Gary R Hook wrote:
>>> +#include
>>> +#include
>>> +#include
>>
>>
>> Keep in order?
> What orde
buf[1] == 'x') {
> + n = sscanf(obuf, "%x", &amd_iommu_devid);
> + } else {
> + n = sscanf(obuf, "%d", &amd_iommu_devid);
> + }
kstrtoint() ?
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
amd_iommu_count_valid_dtes(0, 0x);
> + oboff += OSCNPRINTF("%d\n", n);
> + return ret;
> +}
> @@ -89,6 +89,7 @@
> #define ACPI_DEVFLAG_ATSDIS 0x1000
>
> #define LOOP_TIMEOUT 100000
> +
> /*
> * ACPI table definitions
>
ing in that
> order. The
> information can be accessed in sysfs at
> '/sys/kernel/debug/intel_iommu/'.
>
>
Nice and clean in comparison to v1.
Reviewed-by: Andy Shevchenko
Joerg, note, that macro, which patch 2 defines privately, likely will
make v4.16-rc1, thus pa
context and extended context patch into
> one
> - Remove redundant IOMMU null check under for_each_active_iommu
> - Update the commit title to be consistent
>
> Changes since v2:
> - Added a macro for seq file operations based on recommendation by
> Andy
>Shevchenko. Th
of first one, it would be slightly better for my opinion.
> + seq_printf(m, "Posted Interrupt supported on IOMMU:
> %s\n"
> + " IR table address:%p\n", iommu->name,
> +iommu->ir_table);
Ditto.
el_iommu_get_pts(iommu);
> +
> + }
> +}
> +#else /* CONFIG_INTEL_IOMMU_SVM */
> +static void pasid_tbl_entry_show(struct seq_file *m, struct
> intel_iommu *iommu)
> +{
> +}
I think is not a big deal if you put all in one line like
static ... {}
> +#endif /* CONFIG
x\n",
> iommu->name,
> +base);
Can we get rid of leading '\n'?
--
Andy Shevchenko
Intel Finland Oy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
you want to export these
> internals.
> +
> + Say Y if you need this.
Also I lost a track how this option is being used here. It looks like
this part is not related to the patch itself.
--
Andy Shevchenko
Intel Finland Oy
___
On Thu, 2017-12-21 at 16:32 -0800, Sohil Mehta wrote:
> + seq_puts(m, "\n");
seq_putc()
> + seq_puts(m, "\n");
Ditto.
--
Andy Shevchenko
Intel Finland Oy
___
iommu mailing list
iommu@lists.
ordered alphabetically.
> +static void root_tbl_entry_show(struct seq_file *m, struct
> intel_iommu *iommu,
> + u64 rtaddr_reg, bool ext, bool
> new_ext)
> +{
> + int bus;
> +
> + seq_printf(m, "\nIOMMU %s: %2s Root Table Addr:%ll
; "\n\t\t\t\t\t\t\t\n");
Leading \n.
> + seq_printf(m, "\nPosted Interrupt supported on IOMMU:
> %s\n"
Ditto.
> +" IR table address:%p\n", iommu->name,
> + iommu-
the show context and extended context patch into
> one
> - Remove redundant IOMMU null check under for_each_active_iommu
> - Update the commit title to be consistent
>
> Changes since v2:
> - Added a macro for seq file operations based on recommendation by
> Andy
>S
ily consolidate them in one patch then against
seq_file.h.
> > [1]: https://marc.info/?l=linux-bluetooth&m=151138535801354&w=2
--
Andy Shevchenko
Intel Finland Oy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Tue, 2017-11-28 at 00:02 +, Mehta, Sohil wrote:
> On Mon, 2017-11-27 at 20:52 +, Kammela, Gayatri wrote:
> >
> > >
> > > From: Andy Shevchenko [mailto:andriy.shevche...@linux.intel.com]
> > > Sent: Wednesday, November 22, 2017 1:19 PM
> > >
(!debugfs_create_file("intel_iommu_regset", S_IRUGO,
> + iommu_debug_root, NULL,
> &intel_iommu_regs_fops
[1]: https://marc.info/?l=linux-bluetooth&m=151138535801354&w=2
--
Andy Shevchenko
Intel Finland Oy
__
lease= single_release,
> + .owner = THIS_MODULE,
> +};
>
Same comments as per patch 4.
--
Andy Shevchenko
Intel Finland Oy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
gt; but without that they simply are churn.
>
> NAK for both patches.
While patch 1 might have some sense, second one is matter of taste which
is dependent to maintainer/trends/weather on Mars.
So, +1 to Christoph's opinion.
--
Andy Shevchenko
Intel Finland Oy
__
On Thu, 2017-05-04 at 12:21 +0300, Andy Shevchenko wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time
> we
> convert current users.
>
> acpi_str_to_uuid() becomes useless after
On Fri, 2017-05-05 at 10:06 +0300, Amir Goldstein wrote:
> On Fri, May 5, 2017 at 9:20 AM, Dan Williams > wrote:
> > On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko
> > wrote:
> > > for (i = 0; i < NFIT_UUID_MAX; i++)
> > > - if (
Yisen Zhuang
Cc: Bjorn Helgaas
Cc: Zhang Rui
Cc: Felipe Balbi
Cc: Mathias Nyman
Cc: Heikki Krogerus
Cc: Liam Girdwood
Cc: Mark Brown
Signed-off-by: Andy Shevchenko
---
drivers/acpi/acpi_extlog.c | 10 +++---
drivers/acpi/bus.c
There is inconsistency in return codes across the functions called from
detect_intel_iommu().
Make it consistent and propagate return code to the caller.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/dmar.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a
Usual pattern when we check for return code, which might be negative
errno, is either (ret) or (!ret).
Remove extra ' != 0' from condition.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/dmar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/dmar.c
There is no need to assign ret to 0 in some cases. Moreover it might
shadow some errors in the future.
Remove such assignments.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/dmar.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu
There is already helper functions to do 64-bit I/O on 32-bit machines or
buses, thus we don't need to reinvent the wheel.
Signed-off-by: Andy Shevchenko
---
include/linux/intel-iommu.h | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/include/linux/
There is no need to have a temporary variable.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/dmar.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index edcf7410f736..71d774f1d406 100644
--- a/drivers/iommu
On Wed, 2017-02-22 at 12:26 +0100, Joerg Roedel wrote:
> Hi Andy,
>
> On Wed, Feb 15, 2017 at 04:42:21PM +0200, Andy Shevchenko wrote:
> > By default CONFIG_INTEL_IOMMU_DEFAULT_ON is not set and thus
> > dmar_disabled variable is set.
> >
> > Intel IOMMU
On Wed, 2017-02-15 at 16:42 +0200, Andy Shevchenko wrote:
> By default CONFIG_INTEL_IOMMU_DEFAULT_ON is not set and thus
> dmar_disabled variable is set.
>
> Intel IOMMU driver based on above doesn't set intel_iommu_enabled
> variable.
>
> The commit b0119e870837 (&qu
On Wed, 2017-02-15 at 16:42 +0200, Andy Shevchenko wrote:
> There is inconsistency in return codes across the functions called
> from
> detect_intel_iommu().
>
> Make it consistent and propagate return code to the caller.
> @@ -911,10 +911,9 @@ int __init detec
There is inconsistency in return codes across the functions called from
detect_intel_iommu().
Make it consistent and propagate return code to the caller.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/dmar.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a
There is no need to assign ret to 0 in some cases. Moreover it might
shadow some errors in the future.
Remove such assignments.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/dmar.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu
There is no need to have a temporary variable.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/dmar.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 322765a0a210..24bb0fcca860 100644
--- a/drivers/iommu
Usual patter when we check for return code, which might be negative
errno, is either ret or !ret.
Remove extra ' != 0' from condition.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/dmar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/dmar.c
870837 ("iommu: Introduce new 'struct iommu_device'")
Cc: Joerg Roedel
Signed-off-by: Andy Shevchenko
---
drivers/iommu/dmar.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index d9c0decfc91a..36e3f43
There is already helper functions to do 64-bit I/O on 32-bit machines or
buses, thus we don't need to reinvent the wheel.
Signed-off-by: Andy Shevchenko
---
include/linux/intel-iommu.h | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/include/linux/
cpi_put_table() which doesn't check against that and
> attempts to handle it regardless.
>
> For this reason, check the pointer passed to acpi_put_table()
> before invoking it.
>
Reviewed-by: Andy Shevchenko
> Reported-by: Linus Torvalds
> Fixes: 6b11d1d67713 ("ACPI / osl:
e, ACPI_IORT_NODE_SMMU);
> +
Redundant.
> + if (!parent)
> + return NULL;
> +
> + iommu_node = iort_iommu_get_node(parent);
> + ops = iommu_node->ops;
> +
> + fwspec.fwnode = iommu_node->fwnode;
> + fwspec.
On Thu, 2015-11-19 at 18:22 +0200, Andy Shevchenko wrote:
> There is already helper functions to do 64-bit I/O on 32-bit machines
> or buses,
> thus we don't need to reinvent the wheel.
>
Any comment on this?
> Signed-off-by: Andy Shevchenko
> ---
> Cahngelog v2:
&
gt; 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
0x04 /* Enable receiver line status interrupt
> */
> #define UART_IER_THRI 0x02 /* Enable Transmitter holding register
> int. */
> #define UART_IER_RDI 0x01 /* Enable receiver data interrupt */
> +/* Enable Programmable Transmitter holding register int. */
> +#define UART_IER_PTIME 0x80
Move this to be first in the list. Put comment at the end of the line
> /*
> * Sleep mode for ST16650 and TI16750. For the ST16650, EFR[4]=1
> */
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
> + acpi_dma_pl330_xlate,
> pl330);
So, someone has either to provide CSRT (which is mostly foreign to
ACPI tables), or to provide those resources somehow else (request line
base and number). In
;> Physically DMA share ACPI device with UART, however, BIOS believes DMA and
>> UART is one device.
>> We can't get irq share info from ACPI. And we don't use DT.
>>
> That should be then a MFD device
And for me seems like acpi_amba and drivers sha
There is already helper functions to do 64-bit I/O on 32-bit machines or buses,
thus we don't need to reinvent the wheel.
Signed-off-by: Andy Shevchenko
---
Cahngelog v2:
- rebase on top of recent linux-next
include/linux/intel-iommu.h | 18 ++
1 file changed, 2 inser
atch_tbl,
> + },
> + .probe = hi655x_regulator_probe,
> +};
> +module_platform_driver(hi655x_regulator_driver);
> +
> +MODULE_AUTHOR("Chen Feng ");
> +MODULE_DESCRIPTION("Hisi hi655x regulator driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/regulator/hi655x-regulator.h
> b/include/linux/regulator/hi655x-regulator.h
> new file mode 100644
> index 000..4a32095
> --- /dev/null
> +++ b/include/linux/regulator/hi655x-regulator.h
> @@ -0,0 +1,63 @@
> +/*
> + * Device driver for regulators in HI6553 IC
> + *
> + * Copyright (c) 2015 Hisilicon.
> + *
> + * Fei Wang
> + * Chen Feng
> + *
> + * this regulator's probe function will be called lots of times,,
> + * because of there are lots of regulator nodes in dtb.
> + * so,that's say, the driver must be inited before the regulator nodes
> + * registor to system.
Something with spelling is broken here.
> + *
> + * Makefile have proved my guess, please refor to the makefile.
> + * when the code is rebuild i hope we can build pmu sub_system.
> + * init order can not base on compile
And here.
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
*/
> +
> +#ifndef __HI655X_PMIC_H
> +#define __HI655X_PMIC_H
> +
> +/* Hi655x registers are mapped to memory bus in 4 bytes stride */
> +#define HI655X_REG_TO_BUS_ADDR(x)((x) << 2)
> +
> +#define HI655X_BITS (8)
> +
> +/*numb of sub-interrupt*/
> +#define HI655X_NR_IRQ(32)
> +
> +#define HI655X_IRQ_STAT_BASE (0x003)
> +#define HI655X_IRQ_MASK_BASE (0x007)
> +#define HI655X_IRQ_ARRAY (4)
> +#define HI655X_IRQ_MASK (0x0ff)
> +#define HI655X_IRQ_CLR (0x0ff)
> +#define HI655X_VER_REG (0x000)
> +#define HI655X_VER_REG (0x000)
> +#define HI655X_REG_MAX (0x000)
> +
> +#define PMU_VER_START(0x010)
> +#define PMU_VER_END (0x038)
> +#define ANA_IRQM_REG0(0x1b5)
> +
> +struct hi655x_pmic {
> + struct resource *res;
> + struct device *dev;
> + struct regmap *regmap;
> + spinlock_t ssi_hw_lock;
Just lock as a name.
> + struct clk *clk;
> + struct irq_domain *domain;
> + int irq;
> + int gpio;
> + unsigned int irqs[HI655X_NR_IRQ];
> + unsigned int ver;
> +};
> +#endif
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
With Best Regards,
Andy Shevchenko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Mon, 2015-08-17 at 17:04 +0300, Andy Shevchenko wrote:
> There is already helper functions to do 64-bit I/O on 32-bit machines
> or buses,
> thus we don't need to reinvent the wheel.
>
Any comment on this one?
> Signed-off-by: Andy Shevchenko
> ---
> includ
There is already helper functions to do 64-bit I/O on 32-bit machines or buses,
thus we don't need to reinvent the wheel.
Signed-off-by: Andy Shevchenko
---
include/linux/intel-iommu.h | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/include/linux/
101 - 151 of 151 matches
Mail list logo
