Re: [PATCH v1] driver core: Extend deferred probe timeout on driver registration
On Fri, Apr 29, 2022 at 03:09:32PM -0700, Saravana Kannan wrote: > The deferred probe timer that's used for this currently starts at > late_initcall and runs for driver_deferred_probe_timeout seconds. The > assumption being that all available drivers would be loaded and > registered before the timer expires. This means, the > driver_deferred_probe_timeout has to be pretty large for it to cover the > worst case. But if we set the default value for it to cover the worst > case, it would significantly slow down the average case. For this > reason, the default value is set to 0. This makes sense to me. Reviewed-by: Mark Brown signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 20/23] ASoC: codecs: wcd938x: Make use of the helper component_compare/release_of
On Mon, Feb 14, 2022 at 02:08:16PM +0800, Yong Wu wrote: > Use the common compare/release helpers from component. What's the story with dependencies here? I've just got this one patch with no cover letter... signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dt-bindings: Improve phandle-array schemas
On Tue, Jan 18, 2022 at 07:50:38PM -0600, Rob Herring wrote: > The 'phandle-array' type is a bit ambiguous. It can be either just an > array of phandles or an array of phandles plus args. Many schemas for > phandle-array properties aren't clear in the schema which case applies > though the description usually describes it. Acked-by: Mark Brown signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dt-bindings: Drop redundant minItems/maxItems
On Tue, Jun 15, 2021 at 01:15:43PM -0600, Rob Herring wrote: > If a property has an 'items' list, then a 'minItems' or 'maxItems' with the > same size as the list is redundant and can be dropped. Note that is DT > schema specific behavior and not standard json-schema behavior. The tooling > will fixup the final schema adding any unspecified minItems/maxItems. Acked-by: Mark Brown signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH] regulator: core: Move device_link_remove out from regulator_list_mutex
On Thu, Jul 18, 2019 at 02:42:26PM +0800, Yong Wu wrote:
> The MediaTek SMI adding device_link patch looks reveal a deadlock
> issue reported in [1], This patch is to fix this deadlock issue.
Can you please describe in words what this issue is and how the patch
addresses it?
> This is the detailed log:
>
> [4.664194] ==
> [4.670368] WARNING: possible circular locking dependency detected
> [4.676545] 5.2.0-rc2-next-20190528-44527-g6c94b6475c04 #20 Tainted: G S
> [4.684539] --
Please think hard before including complete backtraces in upstream
reports, they are very large and contain almost no useful information
relative to their size so often obscure the relevant content in your
message. If part of the backtrace is usefully illustrative then it's
usually better to pull out the relevant sections.
> index 955a0a1..3db9350 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -2048,7 +2048,9 @@ static void _regulator_put(struct regulator *regulator)
> debugfs_remove_recursive(regulator->debugfs);
>
> if (regulator->dev) {
> + mutex_unlock(®ulator_list_mutex);
> device_link_remove(regulator->dev, &rdev->dev);
> + mutex_lock(®ulator_list_mutex);
>
> /* remove any sysfs entries */
> sysfs_remove_link(&rdev->dev.kobj, regulator->supply_name);
> --
> 1.9.1
>
Just randomly dropping and reacquiring the lock in the middle of a
series of operations sounds potentially racy... What happens if the
list gets changed while the lock is dropped?
signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: of_dma_request_slave_channel() failed ?
On Tue, Sep 11, 2018 at 11:43:47AM +0200, Geert Uytterhoeven wrote: > So it seems the audio DMAC is deferred a second time, before the iommu driver > probed. Shouldn't there be at least one more round of deferred probe triggers after the IOMMU probes? signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: x86/dma conversion for v4.17-rc1 breaks sound / sst-acpi (commit 6e4bf5867783)
On Thu, Apr 05, 2018 at 10:56:57PM +0200, Dominik Brodowski wrote: > Christoph, > > unfortunately, commit 6e4bf5867783 breaks sound on my Dell XPS13, see the > dmesg diff between fec777c385b6 and 6e4bf5867783: Adding Vinod and Pierre from Intel in case they have any ideas here. Which model of XPS13 is this (2015?)? > -sst-acpi INT3438:00: DesignWare DMA Controller, 8 channels > -haswell-pcm-audio haswell-pcm-audio: Direct firmware load for > intel/IntcPP01.bin failed with error -2 > -haswell-pcm-audio haswell-pcm-audio: fw image intel/IntcPP01.bin not > available(-2) > -haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: > type 01, - version: 00.00, build 77, source commit id: > 876ac6906f31a43b6772b23c7c983ce9dcb18a19 > -broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> System Pin mapping ok > -broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Offload0 Pin mapping > ok > -broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Offload1 Pin mapping > ok > -broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Loopback Pin mapping > ok > -broadwell-audio broadwell-audio: rt286-aif1 <-> snd-soc-dummy-dai mapping ok > -input: broadwell-rt286 Headset as > /devices/pci:00/INT3438:00/broadwell-audio/sound/card1/input15 > +broadwell-audio broadwell-audio: ASoC: CPU DAI System Pin not registered > So it seems that sst-acpi is unhappy with this patch. Any ideas? > Thanks, > Dominik signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 01/21] ASoC: Remove depends on HAS_DMA in case of platform dependency
On Fri, Mar 16, 2018 at 02:51:34PM +0100, Geert Uytterhoeven wrote: > Remove dependencies on HAS_DMA where a Kconfig symbol depends on another > symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". > In most cases this other symbol is an architecture or platform specific > symbol, or PCI. Acked-by: Mark Brown Thanks again for doing this work, it's really good to see! signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 19/21] spi: Remove depends on HAS_DMA in case of platform dependency
On Fri, Mar 16, 2018 at 02:51:52PM +0100, Geert Uytterhoeven wrote: > Remove dependencies on HAS_DMA where a Kconfig symbol depends on another > symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". > In most cases this other symbol is an architecture or platform specific > symbol, or PCI. Acked-by: Mark Brown signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH/RFC 0/6] Allow compile-testing NO_DMA
On Tue, Feb 06, 2018 at 11:14:46AM +0100, Geert Uytterhoeven wrote: > The intention of this is twofold: > 1. To catch users of the DMA API on systems that do no support the DMA > mapping API, > 2. To avoid building drivers that cannot work on such systems anyway. > > However, the disadvantage is that we have to keep on adding dependencies > on HAS_DMA all over the place. > Thanks to the COMPILE_TEST symbol, lots of drivers now depend on one or > more platform dependencies (that imply HAS_DMA) || COMPILE_TEST, thus > already covering intention #2. Having to add an explicit dependency on > HAS_DMA here is cumbersome, and hinders compile-testing. Thanks for doing this, hopefully it'll make everyone's life easier! Reviwed-by: Mark Brown signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/4] spi: use sg_alloc_table_from_buf()
On Thu, Mar 31, 2016 at 02:29:43PM +0200, Boris Brezillon wrote: > Replace custom implementation of sg_alloc_table_from_buf() by a call to > sg_alloc_table_from_buf(). Acked-by: Mark Brown signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 6/7] regulator: hisilicon: Add hi655x pmic voltage regulator driver
On Thu, Nov 05, 2015 at 09:34:47PM +0800, Chen Feng wrote:
> +config REGULATOR_HI6220_MTCMOS
> +bool "Hisilicon Hi6220 mtcmos support"
> +depends on ARCH_HISI
> +help
> + This driver provides support for the mtcmos regulators of Hi6220
> Soc.
> +
The Kconfig and Makefile updates for MCTMOS should have been in the
patch adding the driver for that.
> +config REGULATOR_HI655X
> +bool "HiSilicon Hi655x PMIC voltage regulator support"
> +depends on ARCH_HISI
For both of these we should have an || COMPILE_TEST and there's no need
for either to be bool I can see, they should be tristate.
> +static int hi655x_is_enabled(struct regulator_dev *rdev)
> +{
> + unsigned int value = 0;
> +
> + struct hi655x_regulator *regulator = rdev_get_drvdata(rdev);
> + struct hi655x_regulator_ctrl_regs *ctrl_regs = ®ulator->ctrl_regs;
> +
> + regmap_read(rdev->regmap, ctrl_regs->status_reg, &value);
> + return (value & BIT(regulator->ctrl_mask));
> +}
Use the standard regmap helpers, don't open code them.
> +static int hi655x_set_voltage(struct regulator_dev *rdev,
> + int min_uV, int max_uV, unsigned *selector)
Use the standard helpers, including one of the map_voltage()s and
set_voltage_sel_regmap(), don't open code them.
> +static unsigned int hi655x_map_mode(unsigned int mode)
> +{
> + /* hi655x pmic on hi6220 SoC only support normal mode */
> + if (mode == REGULATOR_MODE_NORMAL)
> + return REGULATOR_MODE_NORMAL;
> + else
> + return -EINVAL;
> +}
If the device only has one mode it should not have any mode operations,
they're only meaningful if there are multiple modes to set and they are
optional.
signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/7] regulator: add driver for mtcmos voltage regulator on hi6220 SoC
On Thu, Nov 05, 2015 at 09:34:46PM +0800, Chen Feng wrote:
> Add driver to support mtcmos on hi6220
I just noticed that these patches are all being posted to the IOMMU list
- that seems a bit odd?
> +static int hi6220_mtcmos_is_on(struct hi6220_mtcmos *mtcmos,
> +unsigned int regs, unsigned int mask, int shift)
> +{
> + unsigned int ret;
> +
> + ret = readl(mtcmos->sc_on_regs + regs);
> + ret &= (mask << shift);
> +
> + return ret;
> +}
> +
> +static int hi6220_mtcmos_is_enabled(struct regulator_dev *rdev)
> +{
> + int ret;
> + struct hi6220_mtcmos_info *sreg = rdev_get_drvdata(rdev);
> + struct platform_device *pdev =
> + container_of(rdev->dev.parent, struct platform_device, dev);
> + struct hi6220_mtcmos *mtcmos = platform_get_drvdata(pdev);
> + struct hi6220_mtcmos_ctrl_regs *ctrl_regs = &sreg->ctrl_regs;
> + struct hi6220_mtcmos_ctrl_data *ctrl_data = &sreg->ctrl_data;
> +
> + ret = hi6220_mtcmos_is_on(mtcmos, ctrl_regs->status_reg,
> + ctrl_data->mask, ctrl_data->shift);
> + return ret;
> +}
That's a *lot* of code for checking if a single bit is set, the same
thinng applies to the rest of the driver. Unless this is for some
reason very performance critical I'd recommend just using regmap-mmio
and the regmap helpers, that will enable you to remove almost all the
code here. Even if you can't do that at least removing the extra level
of helper function would help.
> + sc_on_regs = of_get_property(np, "hisilicon,mtcmos-sc-on-base", NULL);
> + if (sc_on_regs) {
> + regs = ioremap(be32_to_cpu(*sc_on_regs), SZ_4K);
> + mtcmos->sc_on_regs = regs;
> + } else
> + return -ENODEV;
{ } on both sides of the if statement. You should also use normal
reg resource specifiers for register blocks the you need rather than
open coding some custom properties with absolute addresses.
> + for (i = 0; i < HI6220_RG_MAX; i++) {
> + init_data = hi6220_mtcmos_matches[i].init_data;
> + if (!init_data)
> + continue;
No, you should register all regulators on the device not just those with
init_data - you should just let the core do the DT parsing for you using
the standard of_match feature in the regulator_desc.
> + mtcmos->rdev[i] = regulator_register(&sreg->rdesc, &config);
> + if (IS_ERR(mtcmos->rdev[i])) {
devm_regulator_register().
> +static const struct of_device_id of_hi6220_mtcmos_match_tbl[] = {
> + { .compatible = "hisilicon,hi6220-mtcmos-driver", },
Why is -driver part of the compatible?
> + .driver = {
> + .name = "hisi_hi6220_mtcmos",
Linux generally uses - not _ in names.
> +static int __init hi6220_mtcmos_init(void)
> +{
> + return platform_driver_register(&mtcmos_driver);
> +}
> +
> +static void __exit hi6220_mtcmos_exit(void)
> +{
> + platform_driver_unregister(&mtcmos_driver);
> +}
> +
> +fs_initcall(hi6220_mtcmos_init);
Why is this at fs_initcall?!
signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 4/7] mfd: hi655x: Add hi665x pmic driver
On Thu, Nov 05, 2015 at 09:34:45PM +0800, Chen Feng wrote:
> +config MFD_HI655X_PMIC
> +bool "HiSilicon Hi655X series PMU/Codec IC"
Why is this bool and not tristate?
> +depends on ARCH_HISI
Can we have an || COMPILE_TEST here?
> +static irqreturn_t hi655x_pmic_irq_handler(int irq, void *data)
> +{
> + struct hi655x_pmic *pmic = (struct hi655x_pmic *)data;
> + u32 pending;
> + u32 ret = IRQ_NONE;
> + unsigned long offset;
> + int i;
This looks like you should be able to use regmap_irq?
> +static int hi655x_pmic_remove(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct hi655x_pmic *pmic = platform_get_drvdata(pdev);
> +
> + free_irq(pmic->irq, pmic);
> + gpio_free(pmic->gpio);
> + devm_release_mem_region(dev, pmic->res->start,
> + resource_size(pmic->res));
> + devm_kfree(dev, pmic);
> + platform_set_drvdata(pdev, NULL);
There is no point in using devm_ cleanup functions in the device removal
path unless there's some ordering issue with respect to other stuff
which doesn't seem to be the case here.
> +static struct platform_driver hi655x_pmic_driver = {
> + .driver = {
> + .name = "hisi,hi655x-pmic",
We don't normally use OF style names in the Linux driver names.
signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/7] doc:bindings:Document for hi655x pmic driver
On Thu, Nov 05, 2015 at 09:34:44PM +0800, Chen Feng wrote:
> +Required properties:
> +- compatible: Must be "hisilicon,hi655x-regulator-pmic";
If this is a subfunction of a MFD it shouldn't have a compatible string.
If it is instead a standalone device it should just have a name in the
form "vendor,chip" without any random suffixes.
> +- regulator-name: Regulator name in SoC.
> +- regulator-min-microvolt: Smallest voltage support.
> +- regulator-max-microvolt: Largest voltages support.
These should *never* be mandatory properties and the generic regulator
bindings should be reference rather than copied into the binding for a
specific device, that way the standard definitions for things are always
used and people know about any other properties that are available as
standard.
> +- regulator-off-on-delay: The time wait for power steady
> +- regulator-ctrl-regs: Registers offset of control register.
> + In turn with enable disable and status register offset.
> +- regulator-ctrl-mask: The control mask of the register.
> +- regulator-vset-regs: Voltage set register offset.
> +- regulator-vset-mask: voltage set control mask.
> +- regulator-n-vol: The num of support voltages.
> +- regulator-vset-table: The table of support voltages.
Why is this in the binding? This is a binding for a specific device,
there is no point in putting all these data tables in the DT - it just
bloats the DT and makes it harder for us to enhance our support for this
device in the future. Just
> +
> +Example:
> +pmic: pmic@f800 {
> +compatible = "hisilicon,hi655x-pmic-driver";
> + ...
> +ldo2: regulator@a21 {
> +compatible = "hisilicon,hi655x-regulator-pmic";
> +regulator-name = "ldo2";
> +regulator-min-microvolt = <250>;
> +regulator-max-microvolt = <320>;
> +regulator-valid-modes-mask = <0x02>;
> +regulator-initial-mode = <0x02>;
> +regulator-off-on-delay = <120>;
> +regulator-ctrl-regs = <0x029 0x02a 0x02b>;
> +regulator-ctrl-mask = <0x1>;
> +regulator-vset-regs = <0x072>;
> +regulator-vset-mask = <0x3>;
> +regulator-n-vol = <8>;
> +regulator-vset-table = <250>,<260>,
> +<270>,<280>,
> +<290>,<300>,
> +<310>,<320>;
> +};
> + ...
> + }
> --
> 1.9.1
>
>
signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/7] doc:bindings:Document for mtcmos regulator on hi6220 SoC
On Thu, Nov 05, 2015 at 09:34:43PM +0800, Chen Feng wrote: > +- hisilicon,mtcmos-steady-us: The time to wait for power steady > +- hisilicon,mtcmos-sc-on-base: address of mtcmos on hi6220 SoC > + > +Required child device properties: > +- regulator-name: The name of mtcmos > +- hisilicon,ctrl-regs: Offset of ctrl-regs > +- hisilicon,ctrl-data: The bit to ctrl the regulator This doesn't look like a regulator binding at all... for one thing there's no reference to the generic regulator bindings, and having a mandatory regulator-name seems like there's a problem somewhere. signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/7] doc:bindings:Add document for mfd hi665x PMIC
On Thu, Nov 05, 2015 at 09:34:42PM +0800, Chen Feng wrote:
Please use subject lines matching the style for the subsystem. This
makes it easier for people to identify relevant patches.
> +- #interrupt-cells: Should be 2, two cells are needed for irq.
> +- interrupt-controller: hi655x has internal IRQs (has own IRQ domain).
> +- pmu_irq_gpio: should be &gpio_pmu_irq_n, is the IRQ gpio of hi655x.
I'm not entirely sure what this is but it sounds worrying - why can you
not just use a normal interrupt specifier? It also doesn't correspond
to the example:
> +Example:
> + pmic: pmic@f800 {
> + compatible = "hisilicon,hi655x-pmic-driver";
> + reg = <0x0 0xf800 0x0 0x1000>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + pmic_gpios = <&gpio_pmu_irq_n>;
> + status = "okay";
> + }
> --
> 1.9.1
>
>
signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH V2] debugfs: don't assume sizeof(bool) to be 4 bytes
On Mon, Sep 14, 2015 at 09:21:54AM +0530, Viresh Kumar wrote: > Long back 'bool' type used to be a typecast to 'int', but that changed > in v2.6.19. And that is a typecast to _Bool now, which (mostly) takes > just a byte. Anyway, the bool type is implementation defined, and better > we don't assume its size to be 4 bytes or 1. Acked-by: Mark Brown signature.asc Description: Digital signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/exynos: Fix arm64 allmodconfig build
On Mon, Dec 15, 2014 at 03:38:04PM +, Will Deacon wrote: > On Mon, Dec 15, 2014 at 03:35:29PM +0000, Mark Brown wrote: > > I don't mind either way, it just seemed to be easier to report the bug > > with a patch. If Jeorg is busy perhaps it can go via the arm64 tree, > > the issue is triggered by the addition of the platform there? > Can I pass the buck to arm-soc, as they're handling arm64 platform code? > It seems sensible to merge the fix via the same tree that introduced the > breakage. Sure, just resending to them... signature.asc Description: Digital signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/exynos: Fix arm64 allmodconfig build
The Exynos IOMMU driver uses the ARM specific dmac_flush_range() and outer_flush_range() functions. This breaks the build on arm64 allmodconfig in -next since support has been merged for some Exynos ARMv8 SoCs. Add a dependency on ARM to keep things building until either the driver has the ARM dependencies removed or the ARMv8 architecture code implements these ARM specific APIs. Signed-off-by: Mark Brown --- Resending to the arm-soc people since the addition of the Exynos platform for ARMv8 went via them, Krzysztof also sent a fix for this earlier but it there's been no response. drivers/iommu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 01e8bfae569b..325188eef1c1 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -187,7 +187,7 @@ config TEGRA_IOMMU_SMMU config EXYNOS_IOMMU bool "Exynos IOMMU Support" - depends on ARCH_EXYNOS + depends on ARCH_EXYNOS && ARM select IOMMU_API select ARM_DMA_USE_IOMMU help -- 2.1.3 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/exynos: Fix arm64 allmodconfig build
On Mon, Dec 15, 2014 at 02:10:37PM +0100, Krzysztof Kozłowski wrote: > Hi Mark, > Few days ago I posted similar patch: > https://lkml.org/lkml/2014/12/5/268 > but no one have picked it up. > Anyway the fix of yours seems fine to me. I don't mind either way, it just seemed to be easier to report the bug with a patch. If Jeorg is busy perhaps it can go via the arm64 tree, the issue is triggered by the addition of the platform there? signature.asc Description: Digital signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/exynos: Fix arm64 allmodconfig build
The Exynos IOMMU driver uses the ARM specific dmac_flush_range() and outer_flush_range() functions. This breaks the build on arm64 allmodconfig in -next since support has been merged for some Exynos ARMv8 SoCs. Add a dependency on ARM to keep things building until either the driver has the ARM dependencies removed or the ARMv8 architecture code implements these ARM specific APIs. Signed-off-by: Mark Brown --- drivers/iommu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 01e8bfae569b..325188eef1c1 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -187,7 +187,7 @@ config TEGRA_IOMMU_SMMU config EXYNOS_IOMMU bool "Exynos IOMMU Support" - depends on ARCH_EXYNOS + depends on ARCH_EXYNOS && ARM select IOMMU_API select ARM_DMA_USE_IOMMU help -- 2.1.3 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3] iommu: shmobile: Enable the driver on all ARM platforms
On Thu, Oct 31, 2013 at 03:03:05PM +0900, Simon Horman wrote: > On Wed, Oct 30, 2013 at 09:28:54AM -0700, Mark Brown wrote: > > On Wed, Oct 30, 2013 at 12:40:12PM +0100, Laurent Pinchart wrote: > > > > For similar reasons as x86, can we please think about using: > > > > > > depends on ARM > > > > depends on ARCH_SHMOBILE || ARCH_SHMOBILE_MULTI || COMPILE_TEST > > I'd read the above as saying the code needs ARM to build at all and that > > the hardware will only ever appear on SHMOBILE. > I am curious to know the value of "depends ARM". > Is it to aid the reading that you spelt out? That's a function of the compile time dependencies, if ARM is required to build then it needs to be an unconditional dependency. signature.asc Description: Digital signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3] iommu: shmobile: Enable the driver on all ARM platforms
On Wed, Oct 30, 2013 at 12:40:12PM +0100, Laurent Pinchart wrote: > > For similar reasons as x86, can we please think about using: > > depends on ARM > > depends on ARCH_SHMOBILE || ARCH_SHMOBILE_MULTI || COMPILE_TEST > I'm fine with your proposed option. As I don't want to respin the series > dozens of time let's first agree on the course of action, I will then repost > the patches. Mark, you've pushed towards as few platform dependencies as > possible, what's your opinion on this ? In general I think we should have whatever the real depedencies are or COMPILE_TEST (to the extent that they will actually build cleanly on other targets). That way only people who explicitly go looking to compile test things for build coverage (eg, when doing global cleanups or API updates) need to be bothered by the extra compile test options. I'd read the above as saying the code needs ARM to build at all and that the hardware will only ever appear on SHMOBILE. signature.asc Description: Digital signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
On Tue, Oct 29, 2013 at 06:29:59PM +0100, Laurent Pinchart wrote: > On Tuesday 29 October 2013 10:23:31 Mark Brown wrote: > > On Tue, Oct 29, 2013 at 06:05:53PM +0100, Laurent Pinchart wrote: > > > The first one is that I can't compile-test all those drivers on all > > > architectures. The spi-sh-msiof driver, for instance, uses > > > io(read|write)(16| > > Which architectures are these and is there not a symbol we can depend on > > for them? > arch/cris for instance. We can use readl/writel instead (maybe it would be > time to rationalize and document the I/O accessors across all architectures, > but that's another topic). It'd certainly be sensible, or adding a config option to depend on if you rely on these functions. > My point is that there might be other issues that I won't be able to easily > catch. This would break compilation for everybody for no reason, as the > drivers are useless on non-SuperH, non-ARM platforms. That's why I believe > COMPILE_TEST would be a better option as a first step. Yes, it would - please do that. Note that it won't stop anyone running into build issues on other architectures though, it's just about stopping Kconfig noise. signature.asc Description: Digital signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
On Tue, Oct 29, 2013 at 06:05:53PM +0100, Laurent Pinchart wrote: > The first one is that I can't compile-test all those drivers on all > architectures. The spi-sh-msiof driver, for instance, uses io(read|write)(16| Which architectures are these and is there not a symbol we can depend on for them? > 32) which are not available on all architectures. There might be other > similar > problems that I can't catch, and I don't want to introduce build breakages in > the kernel. This is easy enough to handle if we do run into issues, it seems better to get things available than try to step through architecture by architecture. > The second reason is that, as the IP cores have never been used on anything > but SuperH and ARM, I don't like the idea of clobbering the config process > with drivers that are useless on the target architecture. Now that we have a > COMPILE_TEST Kconfig option, my preference would thus go to SUPERH || ARM || > COMPILE_TEST over no dependency at all. That's not what you did, though - you're not adding COMPILE_TEST. signature.asc Description: Digital signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
On Tue, Oct 29, 2013 at 03:04:27PM +0900, Simon Horman wrote: > I think this is a step in a good direction. > However, I think it would be even better if the architecture dependency was > removed completely. Yes, please. signature.asc Description: Digital signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC v2 2/5] tps6586x: Add device tree support
On Wed, Apr 25, 2012 at 12:41:47PM +0200, Thierry Reding wrote: > After taking a closer look I don't think Rhyland's patch is very useful for > this driver. I need to lookup the platform ID by regulator name anyway so > using the new code is actually more work and requires a second table that > lists the regulator names only. Why do you need the plaform ID, and if it is needed could we work out a way to make the generic code do that lookup for you (since presumably other drivers will have the same requirement)? If you can't use the generic code it seems like the fix is to enhance the generic code and I'd expect that something not requiring the platform ID would just be able to igore that information if the generic code could look it up. signature.asc Description: Digital signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC v2 2/5] tps6586x: Add device tree support
On Wed, Apr 25, 2012 at 11:44:59AM +0200, Thierry Reding wrote: > This commit adds device tree support for the TPS6586x regulator. > > Signed-off-by: Thierry Reding This looks basically good from a quick scan through but the pattern of looking up regulator nodes by name is very common so should be factored out - I made a similar comment in response to a recent patch from Rhyland Klein and earlier today he posted a patch "regulator: add generic of node parsing for regulators" which does just that. Can you please redo this on top of his code? I'll probably apply it later today, though I didn't properly read the code yet. I guess it should be possible to apply this patch independantly of the rest of the series? It shouldn't break bisection if it's missing as it's a new driver that's being added as the consumer. signature.asc Description: Digital signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
