https://bugs.kde.org/show_bug.cgi?id=364321
Hector Martin changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
This is required to make loading this as a module work.
Signed-off-by: Hector Martin
---
drivers/iommu/apple-dart.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/apple-dart.c b/drivers/iommu/apple-dart.c
index decafb07ad08..a10a73282014 100644
--- a/drivers/iommu/apple
o.c
> F: drivers/i2c/busses/i2c-pasemi-core.c
> F: drivers/i2c/busses/i2c-pasemi-platform.c
> +F: drivers/iommu/apple-dart.c
> F: drivers/irqchip/irq-apple-aic.c
> F: drivers/mailbox/apple-mailbox.c
> F: drivers/pinctrl/pinctrl-apple-gpio.c
Acked-by: Hector Martin
t no devices relied on the old behavior.)
>
> Fixes: d88ae2932df0 ("i2c: pasemi: Add Apple platform driver")
> Signed-off-by: Martin PoviĊĦer
Acked-by: Hector Martin
Heh, so that's where this was... I remember running into this and
wondering if there was a way to turn it off.
t (M1 Macs)...
>
> Su Yue kindly helped me testing 16K page size, and it's pretty OK there.
>
> So I'm not that concerned.
>
> It's 128K page size that I'm a little concerned, and I have not machine
> supporting that large page size to do the test.
>
> Thanks,
> Qu
I'm happy to test things on 16K in the future if you need me to :-)
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
On 13/12/2021 20.30, Javier Martinez Canillas wrote:
On Mon, Dec 13, 2021 at 11:46 AM Hector Martin wrote:
On 13/12/2021 17.44, Javier Martinez Canillas wrote:
Hello Hector,
On Sun, Dec 12, 2021 at 7:24 AM Hector Martin wrote:
This code is required for both simplefb and simpledrm, so
On 13/12/2021 17.44, Javier Martinez Canillas wrote:
Hello Hector,
On Sun, Dec 12, 2021 at 7:24 AM Hector Martin wrote:
This code is required for both simplefb and simpledrm, so let's move it
into the OF core instead of having it as an ad-hoc initcall in the
drivers.
Acked-by: T
This is the format used by the bootloader framebuffer on Apple ARM64
platforms.
Reviewed-by: Thomas Zimmermann
Signed-off-by: Hector Martin
---
drivers/gpu/drm/tiny/simpledrm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers
Add XRGB emulation support for devices that can only do XRGB2101010.
This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit.
Signed-off-by: Hector Martin
---
drivers/gpu/drm/drm_format_helper.c | 64 +
include
This code is required for both simplefb and simpledrm, so let's move it
into the OF core instead of having it as an ad-hoc initcall in the
drivers.
Acked-by: Thomas Zimmermann
Signed-off-by: Hector Martin
---
drivers/of/platform.c | 4
drivers/video/fbdev/simplefb.c
when
simpledrm is selected to replace simplefb, as these FBs always seem to
be 10-bit (at least when a real screen is attached).
Changes since v2:
- Made 10-bit conversion code fill the LSBs
- Added ARGB2101010 to supported formats list
- Simplified OF core code per review feedback
Hector Martin (3
Hi, thanks for the review!
On 07/12/2021 18.40, Thomas Zimmermann wrote:
Hi
Am 07.12.21 um 08:29 schrieb Hector Martin:
Add XRGB emulation support for devices that can only do XRGB2101010.
This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is
This is the format used by the bootloader framebuffer on Apple ARM64
platforms.
Reviewed-by: Thomas Zimmermann
Signed-off-by: Hector Martin
---
drivers/gpu/drm/tiny/simpledrm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu
Add XRGB emulation support for devices that can only do XRGB2101010.
This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit.
Signed-off-by: Hector Martin
---
drivers/gpu/drm/drm_format_helper.c | 62 +
include
This code is required for both simplefb and simpledrm, so let's move it
into the OF core instead of having it as an ad-hoc initcall in the
drivers.
Signed-off-by: Hector Martin
---
drivers/of/platform.c | 5 +
drivers/video/fbdev/simplefb.c | 21 +
2
when
simpledrm is selected to replace simplefb, as these FBs always seem to
be 10-bit (at least when a real screen is attached).
Changes since v1:
- Moved the OF platform device setup code from simplefb into common
code, instead of duplicating it in simpledrm
- Rebased on drm-tip
Hector Martin (3
On 22/11/2021 18.52, Pekka Paalanen wrote:
On Wed, 17 Nov 2021 23:58:28 +0900
Hector Martin wrote:
Add XRGB emulation support for devices that can only do XRGB2101010.
This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit, which already
On 18/11/2021 18.19, Thomas Zimmermann wrote:
Hi
Am 17.11.21 um 15:58 schrieb Hector Martin:
@@ -897,5 +898,21 @@ static struct platform_driver simpledrm_platform_driver = {
module_platform_driver(simpledrm_platform_driver);
+static int __init simpledrm_init(void)
+{
+ struct
urphy
Signed-off-by: Hector Martin
---
drivers/iommu/io-pgtable-arm.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index dd9e47189d0d..94ff319ae8ac 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/dri
require a new pte format
(different shift); adding support for that to
paddr_to_iopte/iopte_to_paddr caused it to break badly, as even <48-bit
addresses would end up incorrect in that case.
Signed-off-by: Hector Martin
---
drivers/iommu/io-pgtable-arm.c | 14 +++---
1 file changed
On 17/11/2021 23.56, Thomas Zimmermann wrote:
Hi
Am 17.11.21 um 15:22 schrieb Hector Martin:
The dst pointer was being advanced by the clip width, not the full line
stride, resulting in corruption. The clip offset was also calculated
incorrectly.
Cc: sta...@vger.kernel.org
Signed-off-by
This is the format used by the bootloader framebuffer on Apple ARM64
platforms, and is already supported by simplefb. This avoids regressing
on these platforms when simpledrm is enabled and replaces simplefb.
Signed-off-by: Hector Martin
---
drivers/gpu/drm/tiny/simpledrm.c | 2 +-
1 file
Add XRGB emulation support for devices that can only do XRGB2101010.
This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit, which already works fine with
simplefb. This is required to make simpledrm support this too.
Signed-off-by: Hector
This matches the simplefb behavior; these nodes are not matched by the
standard OF machinery. This fixes a regression when simpledrm replaces
simeplefb.
Signed-off-by: Hector Martin
---
drivers/gpu/drm/tiny/simpledrm.c | 17 +
1 file changed, 17 insertions(+)
diff --git a
when
simpledrm is selected to replace simplefb, as these FBs always seem to
be 10-bit (at least when a real screen is attached).
Hector Martin (3):
drm/simpledrm: Bind to OF framebuffers in /chosen
drm/format-helper: Add drm_fb_xrgb_to_xrgb2101010_dstclip()
drm/simpledrm: Enable
The dst pointer was being advanced by the clip width, not the full line
stride, resulting in corruption. The clip offset was also calculated
incorrectly.
Cc: sta...@vger.kernel.org
Signed-off-by: Hector Martin
---
drivers/gpu/drm/drm_format_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2
rol isolation */
+ writel(DART_STREAM_ALL, dart->regs + DART_STREAMS_ENABLE);
+
/* clear any pending errors before the interrupt is unmasked */
writel(readl(dart->regs + DART_ERROR), dart->regs + DART_ERROR);
Reviewed-by: Hector Martin
--
Hector Martin (mar...@marcan
I suggest I drop the
MAINTAINER additions for now and we add them later. Then, you can add
the pasemi-core as well. D'accord?
We can just split the MAINTAINERS changes into a separate patch and I
can push that one through the SoC tree, along with other MAINTAINERS
updates. Does that work
https://bugs.kde.org/show_bug.cgi?id=364321
--- Comment #14 from Hector Martin ---
Of course JEDEC would use the binary definition; their entire business is
basically RAM and Flash specifications. They are basically the only
organization with a reason to prefer binary powers of 2, as they define
-controller/apple,aic.yaml
This isn't a freedesktop.org project, so either needs to be dropped
from the patch or the patch needs an ack from Hector Martin (+cc).
Heh, I totally forgot we had the IRC info in MAINTAINERS too when I did
the move. Thanks :)
Acked-By: Hector Martin
--
Hector Martin
https://bugs.kde.org/show_bug.cgi?id=364321
Hector Martin changed:
What|Removed |Added
CC||hec...@marcansoft.com
--- Comment #12 from
897f739d7b ("of/address: Add infrastructure to declare MMIO as non-posted")
(and maybe some others)
I have reverted 86332e9e3477..7d2d16ccf15d for today.
This is fixed in ea9629283839 in the soc tree, which went in a few hours
ago. Sorry for the noise.
--
Hector Martin (mar...@marcan.st)
Pu
ebsite for more information on the project:
https://asahilinux.org/
Signed-off-by: Hector Martin
Arnd Bergmann (1):
docs: driver-api: device-io: Document I/O access functions
Hector Martin (17):
dt-bindings: vendor-prefixes: A
On 08/04/2021 06.09, Will Deacon wrote:
Couple of stale comment nits:
[...]
But with that:
Acked-by: Will Deacon
Fixed those for the PR, thanks!
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
:
return ioremap_np(offset, size) ?: ioremap(offset, size);
Today I learned that this one is kosher in kernel code. Handy! Let's go
with that.
Acked-by: Will Deacon
Thanks!
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
On 07/04/2021 03.16, Marc Zyngier wrote:
Hi Hector,
On Fri, 02 Apr 2021 10:05:39 +0100,
Hector Martin wrote:
+ /*
+* In EL1 the non-redirected registers are the guest's,
+* not EL2's, so remap the hwirq
Thanks for pointing it out.
With that,
Reviewed-by: Rob Herring
Thanks!
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
This currently supports:
* SMP (via spin-tables)
* AIC IRQs
* Serial (with earlycon)
* Framebuffer
A number of properties are dynamic, and based on system firmware
decisions that vary from version to version. These are expected
to be filled in by the loader.
Signed-off-by: Hector Martin
Apple SoCs run firmware that sets up a simplefb-compatible framebuffer
for us. Add a compatible for it, and two missing supported formats.
Reviewed-by: Rob Herring
Reviewed-by: Linus Walleij
Signed-off-by: Hector Martin
---
.../devicetree/bindings/display/simple-framebuffer.yaml | 5
This adds a Kconfig option to toggle support for Apple ARM SoCs.
At this time this targets the M1 and later "Apple Silicon" Mac SoCs.
Signed-off-by: Hector Martin
---
arch/arm64/Kconfig.platforms | 7 +++
arch/arm64/configs/defconfig | 1 +
2 files changed, 8 insertions(+)
di
).
* Implements a virtual IPI multiplexer to funnel multiple Linux IPIs
into a single hardware IPI
Signed-off-by: Hector Martin
---
MAINTAINERS | 2 +
drivers/irqchip/Kconfig | 8 +
drivers/irqchip/Makefile| 1 +
drivers/irqchip/irq-apple-aic.c | 837
AIC is the Apple Interrupt Controller found on Apple ARM SoCs, such as
the M1.
Reviewed-by: Linus Walleij
Reviewed-by: Rob Herring
Signed-off-by: Hector Martin
---
.../interrupt-controller/apple,aic.yaml | 88 +++
MAINTAINERS | 1
These definitions are in arm-gic-v3.h for historical reasons which no
longer apply. Move them to sysreg.h so the AIC driver can use them, as
it needs to peek into vGIC registers to deal with the GIC maintentance
interrupt.
Acked-by: Marc Zyngier
Acked-by: Will Deacon
Signed-off-by: Hector
uilds that support Apple ARM
platforms, as an optimization.
Reviewed-by: Linus Walleij
Signed-off-by: Hector Martin
---
drivers/of/address.c | 43 --
include/linux/of_address.h | 1 +
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/drivers/of
generic pci_remap_cfgspace() unconditional.
Signed-off-by: Hector Martin
---
arch/arm64/include/asm/io.h | 10 --
include/linux/io.h | 21 +
2 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm
This is used on Apple ARM platforms, which require most MMIO
(except PCI devices) to be mapped as nGnRnE.
Acked-by: Marc Zyngier
Acked-by: Will Deacon
Signed-off-by: Hector Martin
---
arch/arm64/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/include/asm/io.h b
This documents the newly introduced ioremap_np() along with all the
other common ioremap() variants, and some higher-level abstractions
available.
Reviewed-by: Linus Walleij
Signed-off-by: Hector Martin
---
Documentation/driver-api/device-io.rst | 218 +
1 file changed
From: Arnd Bergmann
This adds more detailed descriptions of the various read/write
primitives available for use with I/O memory/ports.
Reviewed-by: Linus Walleij
Signed-off-by: Arnd Bergmann
Signed-off-by: Hector Martin
---
Documentation/driver-api/device-io.rst | 138
Signed-off-by: Hector Martin
---
.../driver-api/driver-model/devres.rst| 1 +
arch/sparc/include/asm/io_64.h| 4
include/asm-generic/io.h | 22 ++-
include/asm-generic/iomap.h | 9
include/linux/io.h
Reviewed-by: Linus Walleij
Reviewed-by: Marc Zyngier
Signed-off-by: Hector Martin
---
drivers/clocksource/arm_arch_timer.c | 24 +---
include/clocksource/arm_arch_timer.h | 1 +
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/clocksource
code can pick the right one.
This also adds the hyp-virt timer/interrupt, which was previously not
expressed in the fixed 4-interrupt form.
Reviewed-by: Linus Walleij
Acked-by: Marc Zyngier
Reviewed-by: Tony Lindgren
Signed-off-by: Hector Martin
---
.../bindings/timer/arm,arch_timer.yaml
The implementor will be used to condition the FIQ support quirk.
The specific CPU types are not used at the moment, but let's add them
for documentation purposes.
Acked-by: Will Deacon
Signed-off-by: Hector Martin
---
arch/arm64/include/asm/cputype.h | 6 ++
1 file changed, 6 inser
These are the CPU cores in the "Apple Silicon" M1 SoC.
Reviewed-by: Rob Herring
Signed-off-by: Hector Martin
---
Documentation/devicetree/bindings/arm/cpus.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml
b/Documentation/
This introduces bindings for all three 2020 Apple M1 devices:
* apple,j274 - Mac mini (M1, 2020)
* apple,j293 - MacBook Pro (13-inch, M1, 2020)
* apple,j313 - MacBook Air (M1, 2020)
Reviewed-by: Linus Walleij
Reviewed-by: Rob Herring
Signed-off-by: Hector Martin
---
.../devicetree/bindings
This is different from the legacy AAPL prefix used on PPC, but
consensus is that we prefer `apple` for these new platforms.
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Linus Walleij
Reviewed-by: Rob Herring
Signed-off-by: Hector Martin
---
Documentation/devicetree/bindings/vendor
terms of ioremap_np()
and removed arch-specific pci_remap_cfgspace override for arm64
(arm32 can come later)
* Replaced license in AIC bindings header with GPL-2.0+ OR MIT
* Other minor typo/style fixes
Arnd Bergmann (1):
docs: driver-api: device-io: Document I/O access functions
Hector Martin
of this being something that can happen, and it shouldn't in
sane hardware, and hope for the best :-)
Thanks,
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
p *ic = irq_data_get_irq_chip_data(d);
+ int cpu;
+
+ if (hwirq > ic->nr_hw)
>= ?
Good catch, but this is actually obsolete. Higher IRQs go into the FIQ
irqchip, so this should never happen (it's a leftover from when they
were a single one). I'll remove it.
Ack on th
. atomic_fetch_andnot() is *supposed* to be
fully ordered and that should include against the writel_relaxed() on
AIC_IPI_FLAG. On ARM it turns out it's not quite fully ordered, but the
acquire semantics of the read half are sufficient for this case, as they
guarantee the flags are always read after the FIQ has been ACKed.
Cheeers,
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
have to do its own masking
behind the scenes anyway
Since you're using the masking in KVM after all, I'm tracking the mask
state in a percpu variable now. Also folded in your two minor bugfixes
from the KVM series. Cheers!
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
the ugly WARN.
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
p being messy in the future it
shouldn't be a big deal to refactor it all into one file again.
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
() on 32-bit as well, and I would keep
that separate from this series.
Sounds good; I'm adding a patch to adjust the generic implementation and
remove the arm64 one in v4, and we can then complete the cleanup for
other arches later.
--
Hector Martin (mar...@marcan.st)
Public Key: https://mr
gh to be getting into building your own secure system with
anti-rollback for retry counters, you should be heading in that directly
anyway.
And now Linux's RPMB code is useless because you're running the stack in
the secure monitor instead :-)
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
being aware. Since any security
benefit from RPMB must come from integration with user policy, it
doesn't make sense to "well, just do something else with RPMB because
it's better than nothing"; just doing "something" doesn't make systems
more secure. There needs to be a specific, practical use case that we'd
be trying to solve with RPMB here.
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
On 11/03/2021 18.12, Arnd Bergmann wrote:
On Wed, Mar 10, 2021 at 6:01 PM Rob Herring wrote:
On Wed, Mar 10, 2021 at 1:27 AM Hector Martin wrote:
On 10/03/2021 07.06, Rob Herring wrote:
My main concern here is that this creates an inconsistency in the device
tree representation that only
get anything from it. And its provisioning model assumes a
typical OEM device production pipeline and integration with CPU fusing;
it isn't friendly to Linux hackers messing around with securing LUKS
unlock attempt counters.
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
and other
evil hardware trying to brute force their way past screen
locks and passwords. Such devices exist, sadly.
If you're trying to protect against a "dumb" attack with a keyboard
emulator that doesn't consider access to physical storage, then you
don't need RPMB eithe
https://bugs.kde.org/show_bug.cgi?id=320327
--- Comment #3 from Hector Martin ---
I haven't used Kopete in many years, so feel free to close this bug (I don't
know what close reason is appropriate in these cases).
--
You are receiving this mail because:
You are watching all bug changes.
e RPMB is public and available to any attacker.
So unless the kernel grows a subsystem/feature to enforce complex key
policies (with things like use counts, retry times, etc), I don't think
there's a place to integrate RPMB kernel-side. You still need a trusted
userspace tool to glu
On 10/03/2021 14.14, Sumit Garg wrote:
On Wed, 10 Mar 2021 at 02:47, Hector Martin wrote:
On 09/03/2021 01.20, Linus Walleij wrote:
I suppose it would be a bit brutal if the kernel would just go in and
appropriate any empty RPMB it finds, but I suspect it is the right way
to make use of this
x27;s just make it non-recursive.
Do you think we can get rid of the Apple-only optimization if we do
this? It would mean only looking at the parent during address
resolution, not recursing all the way to the top, so presumably the
performance impact would be quite minimal.
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
rypto keys or such, but rather
a way to prevent these attacks.
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
On 10/03/2021 01.37, Linus Walleij wrote:
On Thu, Mar 4, 2021 at 10:42 PM Hector Martin wrote:
Apple SoCs run firmware that sets up a simplefb-compatible framebuffer
for us. Add a compatible for it, and two missing supported formats.
Signed-off-by: Hector Martin
Reviewed-by: Linus Walleij
On 09/03/2021 00.35, Marc Zyngier wrote:
On Thu, 04 Mar 2021 21:38:52 +,
Hector Martin wrote:
This adds a Kconfig option to toggle support for Apple ARM SoCs.
At this time this targets the M1 and later "Apple Silicon" Mac SoCs.
Signed-off-by: Hector Martin
---
On 06/03/2021 00.51, Arnd Bergmann wrote:
On Fri, Mar 5, 2021 at 4:09 PM Andy Shevchenko
wrote:
On Fri, Mar 5, 2021 at 12:25 PM Linus Walleij wrote:
On Thu, Mar 4, 2021 at 10:40 PM Hector Martin wrote:
This documents the newly introduced ioremap_np() along with all the
other common
On 10/03/2021 01.11, Rob Herring wrote:
On Mon, Mar 8, 2021 at 3:42 PM Marc Zyngier wrote:
On Mon, 08 Mar 2021 20:38:41 +,
Rob Herring wrote:
On Fri, Mar 05, 2021 at 06:38:41AM +0900, Hector Martin wrote:
Not all platforms provide the same set of timers/interrupts, and Linux
only
needs
nonposted nGnRnE mappings for PCIe (even though the actual PCIe ops will
end up posted at the bus anyway)... how do we represent that? Declare
that another "nonposted-mmio" on the PCIe bus means "no, really, use
nonposted mmio for this"?
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
orms, and now we're
coming full circle... :-)
If you prefer to handle it this way for now I can do it like this. I
think we should still have the DT bindings and properties though (even
if not used), as they do describe the hardware properly, and in the
future we might want to use them instead of having a quirk.
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
rs in the kernel use
plain ioremap variants that don't have any flags to look at.
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
;d even say
overlapping the bits and the macro name in the same columns makes it
less readable to my eyes.
+#define APPLE_S5L_UTRSTAT_RXTHRESH (1<<4)
+#define APPLE_S5L_UTRSTAT_TXTHRESH (1<<5)
+#define APPLE_S5L_UTRSTAT_RXTO (1<<9)
+#define APPLE_S5L_UTRSTAT_ALL_FLAGS(0x3f0)
BIT() ?
See above.
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
PU really can't be allowed to touch, e.g. the SEP carveout). It
also breaks simplefb mapping the framebuffer. I thought of the
reserved-memory approach, but then figured it wouldn't buy us anything
for this reason.
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
ck_irqsave -> spin_lock().
Krzysztof, is this something you want in this series? I was trying to
avoid logic changes to the non-Apple paths.
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
using a different locking function? I'm not
entirely sure what you're suggesting.
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
parents?
Keep in mind the logic here is that it stops on the first instance of
either property, and does not traverse non-translatable boundaries. Are
there helpers that can implement this kind of complex logic? It's not a
simple recursive property lookup.
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
On 05/03/2021 23.45, Andy Shevchenko wrote:
On Thu, Mar 4, 2021 at 11:40 PM Hector Martin wrote:
ARM64 currently defaults to posted MMIO (nGnRnE), but some devices
require the use of non-posted MMIO (nGnRE). Introduce a new ioremap()
variant to handle this case. ioremap_np() is aliased to
oesn't really make sense to use a more
specific example for the dts.
E.g. on my system, with my current firmware version, this ends up
getting patched to:
reg = <0x8 0x0134c000 0x1 0xda294000>
Thanks,
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
On 05/03/2021 06.38, Hector Martin wrote:
== Merge notes ==
This patchset depends on both the nVHE changes that are already in
5.12-rc1, as well as the FIQ support work currently being reviewed
at [1]. A tree containing this patchset on top of the required
dependencies is available at [2][3
that,
Tested-by: Hector Martin
[1]
https://lore.kernel.org/lkml/CAHk-=wjnzdlsp3odxhf9emtyo7gf-qjanlbuh1zk3c4a7x7...@mail.gmail.com/
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
makes more
sense to do it here in the UART driver instead of introducing a
whole fdt nonposted-mmio resolver just for earlycon/fixmap.
Suggested-by: Arnd Bergmann
Signed-off-by: Hector Martin
---
drivers/tty/serial/samsung_tty.c | 17 +
1 file changed, 17 insertions(+)
diff
This currently supports:
* SMP (via spin-tables)
* AIC IRQs
* Serial (with earlycon)
* Framebuffer
A number of properties are dynamic, and based on system firmware
decisions that vary from version to version. These are expected
to be filled in by the loader.
Signed-off-by: Hector Martin
the
FIFO with data directly.
Signed-off-by: Hector Martin
---
drivers/tty/serial/Kconfig | 2 +-
drivers/tty/serial/samsung_tty.c | 238 +--
include/linux/serial_s3c.h | 16 +++
3 files changed, 247 insertions(+), 9 deletions(-)
diff --git a/drivers
Apple SoCs run firmware that sets up a simplefb-compatible framebuffer
for us. Add a compatible for it, and two missing supported formats.
Signed-off-by: Hector Martin
---
.../devicetree/bindings/display/simple-framebuffer.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git a
This decouples the TTY layer PORT_ types, which are exposed to
userspace, from the driver-internal flag of what kind of port this is.
This removes s3c24xx_serial_has_interrupt_mask, which was just checking
for a specific type anyway.
Signed-off-by: Hector Martin
---
drivers/tty/serial
held.
* Rename s3c24xx_serial_rx_chars to s3c24xx_serial_rx_irq for
consistency with the above. All it does now is call two other
functions anyway.
Signed-off-by: Hector Martin
---
drivers/tty/serial/samsung_tty.c | 34 +++-
1 file changed, 20 insertions(+), 14
This picks up the non-posted I/O mode needed for Apple platforms to
work properly.
This removes the request/release functions, which are no longer
necessary, since devm_ioremap_resource takes care of that already. Most
other drivers already do it this way, anyway.
Signed-off-by: Hector Martin
avoids excessive branching
control flow and mirrors s3c64xx_serial_startup. tx_claimed and
rx_claimed are only used in the S3C24XX functions.
Signed-off-by: Hector Martin
---
drivers/tty/serial/samsung_tty.c | 71
1 file changed, 54 insertions(+), 17 deletions
This simplifies the code by removing the only distinction between the
S3C2410 and S3C2440 codepaths.
Signed-off-by: Hector Martin
---
drivers/tty/serial/samsung_tty.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty
This adds a Kconfig option to toggle support for Apple ARM SoCs.
At this time this targets the M1 and later "Apple Silicon" Mac SoCs.
Signed-off-by: Hector Martin
---
arch/arm64/Kconfig.platforms | 8
arch/arm64/configs/defconfig | 1 +
2 files changed, 9 insertions(+)
di
Apple mobile devices originally used Samsung SoCs (starting with the
S5L8900), and their current in-house SoCs continue to use compatible
UART peripherals. We'll call this UART variant apple,s5l-uart.
Signed-off-by: Hector Martin
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Linus Wa
101 - 200 of 513 matches
Mail list logo
