alue 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
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
__
ase 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
son-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
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 detaile
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
__
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 XPS
m 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
m 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
#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
_
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 m
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
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,
> +unsig
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
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 "vend
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:
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
efined, 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
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 tr
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 res
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
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
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:
> >
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 se
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
> >
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 the
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
_
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
> li
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
29 matches
Mail list logo
