* Re: [PATCH v2 2/4] arm64: vdso32: Detect binutils support for dmb ishld
From: Vincenzo Frascino @ 2019-09-26 21:17 UTC (permalink / raw)
To: Catalin Marinas
Cc: ard.biesheuvel, ndesaulniers, linux-kernel, tglx, will,
linux-arm-kernel
In-Reply-To: <20190926155938.GM9689@arrakis.emea.arm.com>
On 9/26/19 4:59 PM, Catalin Marinas wrote:
> On Thu, Sep 26, 2019 at 02:38:03PM +0100, Vincenzo Frascino wrote:
>> arch/arm64/kernel/vdso32/Makefile | 9 +++++++++
>
> Could you please also remove the unnecessary gcc-goto.sh check in this
> file? We don't use jump labels in the vdso (can't run-time patch them).
> I found it while forcing COMPATCC=clang with my additional diff and I
> get the warning on 'make clean'.
>
I will do it in a separate cleanup patch, I want to keep this only for the error
reported by Will.
> diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
> index 22f0d31ea528..038357a1e835 100644
> --- a/arch/arm64/kernel/vdso32/Makefile
> +++ b/arch/arm64/kernel/vdso32/Makefile
> @@ -40,9 +38,6 @@ VDSO_CAFLAGS += $(call cc32-option,-fno-PIE)
> ifdef CONFIG_DEBUG_INFO
> VDSO_CAFLAGS += -g
> endif
> -ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(COMPATCC)), y)
> -VDSO_CAFLAGS += -DCC_HAVE_ASM_GOTO
> -endif
>
> # From arm Makefile
> VDSO_CAFLAGS += $(call cc32-option,-fno-dwarf2-cfi-asm)
>
--
Regards,
Vincenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RESEND] drm/meson: vclk: use the correct G12A frac max value
From: Kevin Hilman @ 2019-09-26 21:08 UTC (permalink / raw)
To: Neil Armstrong, dri-devel
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190828132311.23881-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> When calculating the HDMI PLL settings for a DMT mode PHY frequency,
> use the correct max fractional PLL value for G12A VPU.
>
> With this fix, we can finally setup the 1024x768-60 mode.
>
> Fixes: 202b9808f8ed ("drm/meson: Add G12A Video Clock setup")
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 00/18] crypto: wireguard using the existing crypto API
From: Jason A. Donenfeld @ 2019-09-26 20:47 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Catalin Marinas, Herbert Xu, Arnd Bergmann, Eric Biggers, Greg KH,
Samuel Neves, Will Deacon, Linux Crypto Mailing List,
Andy Lutomirski, Marc Zyngier, Dan Carpenter, Linus Torvalds,
David Miller, linux-arm-kernel
In-Reply-To: <CAKv+Gu-RLRhwDahgvfvr2J9R+3GPM6vh4mjO73VcekusdzbuMA@mail.gmail.com>
Hi Ard,
On Thu, Sep 26, 2019 at 2:07 PM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> attitude goes counter to that, and this is why we have made so little
> progress over the past year.
I also just haven't submitted much in the past year, taking a bit of a
break to see how things would settle. Seemed like rushing things
wasn't prudent, so I slowed down.
> But I am happy with your willingness to collaborate and find common
> ground, which was also my motivation for spending a considerable
> amount of time to prepare this patch set.
Super.
> > If the process of doing that together will be fraught with difficulty,
> > I’m still open to the “7 patch series” with the ugly cryptoapi.c
> > approach, as described at the top.
>
> If your aim is to write ugly code and use that as a munition
No, this is not a matter of munition at all. Please take my words
seriously; I am entirely genuine here. Three people I greatly respect
made a very compelling argument to me, prompting the decision in [1].
The argument was that trying to fix the crypto layer AND trying to get
WireGuard merged at the same time was ambitious and crazy. Maybe
instead, they argued, I should just use the old crypto API, get
WireGuard in, and then begin the Zinc process after. I think
procedurally, that's probably good advice, and the people I was
talking to seemed to have a really firm grasp on what works and what
doesn't in the mainlining process. Now it's possible their judgement
is wrong, but I really am open, in earnest, to following it. And the
way that would look would be not trying to fix the crypto API now,
getting WireGuard in based on whatever we can cobble together based on
the current foundations with some intermediate file (cryptoapi.c in my
previous email) to prevent it from infecting WireGuard. This isn't
"munition"; it's a serious proposal.
The funny thing, though, is that all the while I was under the
impression somebody had figured out a great way to do this, it turns
out you were busy with basically Zinc-but-not. So we're back to square
one: you and I both want the crypto API to change, and now we have to
figure out a way forward together on how to do this, prompting my last
email to you, indicating that I was open to all sorts of compromises.
However, I still remain fully open to following the prior suggestion,
of not doing that at all right now, and instead basing this on the
existing crypto API as-is.
[1] https://lore.kernel.org/wireguard/CAHmME9pmfZAp5zd9BDLFc2fWUhtzZcjYZc2atTPTyNFFmEdHLg@mail.gmail.com/
> > reference, here’s what that kind of thing looks like: [2].
>
> This is one of the issues in the 'fix it for everyone else as well'
> category. If we can improve the crypto API to be less susceptible to
> these issues (e.g., using static calls), everybody benefits. I'd be
> happy to collaborate on that.
Good. I'm happy to learn that you're all for having fast
implementations that underlie the simple function calls.
> > Taken together, we simply can’t skimp on the implementations available
> > on the handshake layer, so we’ll need to add some form of
> > implementation selection, whether it’s the method Zinc uses ([2]), or
> > something else we cook up together.
>
> So are you saying that the handshake timing constraints in the
> WireGuard protocol are so stringent that we can't run it securely on,
> e.g., an ARM CPU that lacks a NEON unit? Or given that you are not
> providing accelerated implementations of blake2s or Curve25519 for
> arm64, we can't run it securely on arm64 at all?
Deployed at scale, the handshake must have a certain performance to
not be DoS'd. I've spent a long time benching these and attacking my
own code. I won't be comfortable with this going in without the fast
implementations for the handshake. And down the line, too, we can look
into how to even improve the DoS resistance. I think there's room for
improvement, and I hope at some point you'll join us in discussions on
WireGuard internals. But the bottom line is that we need those fast
primitives.
> Typically, I would prefer to only introduce different versions of the
> same algorithm if there is a clear performance benefit for an actual
> use case.
As I was saying, this is indeed the case.
> Framing this as a security issue rather than a performance issue is
> slightly disingenuous, since people are less likely to challenge it.
I'm not being disingenuous. DoS resistance is a real issue with
WireGuard. You might argue that FourQ and Siphash would have made
better choices, and that's an interesting discussion, but it is what
it is. The thing needs fast implementations. And we're going to have
to implement that code anyway for other things, so might as well get
it working well now.
> But the security of any VPN protocol worth its salt
You're not required to use WireGuard.
> Parsing the string and connecting the function pointers happens only
> once, and only when the transform needs to be instantiated from its
> constituent parts. Subsequent invocations will just grab the existing
> object.
That's good to know. It doesn't fully address the issue, though.
> My preference would be to address this by permitting per-request keys
> in the AEAD layer. That way, we can instantiate the transform only
> once, and just invoke it with the appropriate key on the hot path (and
> avoid any per-keypair allocations)
That'd be a major improvement to the async interface, yes.
> > So given the above, how would you like to proceed? My personal
> > preference would be to see you start with the Zinc patchset and rename
> > things and change the infrastructure to something that fits your
> > preferences, and we can see what that looks like. Less appealing would
> > be to do several iterations of you reworking Zinc from scratch and
> > going through the exercises all over again, but if you prefer that I
> > guess I could cope. Alternatively, maybe this is a lot to chew on, and
> > we should just throw caution into the wind, implement cryptoapi.c for
> > WireGuard (as described at the top), and add C functions to the crypto
> > API sometime later? This is what I had envisioned in [1].
> It all depends on whether we are interested in supporting async
> accelerators or not, and it is clear what my position is on this
> point.
For a first version of WireGuard, no, I'm really not interested in
that. Adding it in there is more ambitious than it looks to get it
right. Async means more buffers, which means the queuing system for
WireGuard needs to be changed. There's already ongoing research into
this, and I'm happy to consider that research with a light toward
maybe having async stuff in the future. But sticking into the code now
as-is simply does not work from a buffering/queueing perspective. So
again, let's take an iterative approach here: first we do stuff with
the simple synchronous API. After the dust has settled, hardware is
available for testing, Van Jacobson has been taken off the bookshelf
for a fresh reading, and we've all sat down for a few interesting
conversations at netdev on queueing and bufferbloat, then let's start
working this in. In otherwords, just because technically you can glue
those APIs together, sort of, doesn't mean that approach makes sense
for the system as a whole.
> I am not convinced that we need accelerated implementations of blake2s
> and curve25519, but if we do, I'd like those to be implemented as
> individual modules under arch/*/crypto, with some moduleloader fu for
> weak symbols or static calls thrown in if we have to. Exposing them as
> shashes seems unnecessary to me at this point.
We need the accelerated implementations. And we'll need it for chapoly
too, obviously. So let's work out a good way to hook that all into the
Zinc-style interface. [2] does it in a very effective way that's
overall quite good for performance and easy to follow. The
chacha20-x86_64-glue.c code itself gets called via the static symbol
chacha20_arch. This is implemented for each platform with a fall back
to one that returns false, so that the generic code is called. The
Zinc stuff here is obvious, simple, and I'm pretty sure you know
what's up with it.
I prefer each of these glue implementations to live in
lib/zinc/chacha20/chacha20-${ARCH}-glue.c. You don't like that and
want things in arch/${ARCH}/crypto/chacha20-glue.c. Okay, sure, fine,
let's do all the naming and organization and political stuff how you
like, and I'll leave aside my arguments about why I disagree. Let's
take stock of where that leaves us, in terms of files:
- lib/crypto/chacha20.c: this has a generic implementation, but at the
top of the generic implementation, it has some code like "if
(chacha20_arch(..., ..., ...)) return;"
- arch/crypto/x86_64/chacha20-glue.c: this has the chacha20_arch()
implementation, which branches out to the various SIMD implementations
depending on some booleans calculated at module load time.
- arch/crypto/arm/chacha20-glue.c: this has the chacha20_arch()
implementation, which branches out to the various SIMD implementations
depending on some booleans calculated at module load time.
- arch/crypto/mips/chacha20-glue.c: this has the chacha20_arch()
implementation, which contains an assembly version that's always run
unconditionally.
Our goals are that chacha20_arch() from each of these arch glues gets
included in the lib/crypto/chacha20.c compilation unit. The reason why
we want it in its own unit is so that the inliner can get rid of
unreached code and more tightly integrate the branches. For the MIPS
case, the advantage is clear. Here's how Zinc handles it: [3]. Some
simple ifdefs and includes. Easy and straightforward. Some people
might object, though, and it sounds like you might. So let's talk
about some alternative mechanisms with their pros and cons:
- The zinc method: straightforward, but not everybody likes ifdefs.
- Stick the filename to be included into a Kconfig variable and let
the configuration system do the logic: also straightforward. Not sure
it's kosher, but it would work.
- Weak symbols: we don't get inlining or the dead code elimination.
- Function pointers: ditto, plus spectre.
- Other ideas you might have? I'm open to suggestions here.
[2] https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/linux.git/tree/lib/zinc/chacha20/chacha20-x86_64-glue.c?h=jd/wireguard#n54
[3] https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/linux.git/tree/lib/zinc/chacha20/chacha20.c?h=jd/wireguard#n19
> What I *don't* want is to merge WireGuard with its own library based
> crypto now, and extend that later for async accelerators once people
> realize that we really do need that as well.
I wouldn't worry so much about that. Zinc/library-based-crypto is just
trying to fulfill the boring synchronous pure-code part of crypto
implementations. For the async stuff, we can work together on
improving the existing crypto API to be more appealing, in tandem with
some interesting research into packet queuing systems. From the other
thread, you might have seen that already Toke has cool ideas that I
hope we can all sit down and talk about. I'm certainly not interested
in "bolting" anything on to Zinc/library-based-crypto, and I'm happy
to work to improve the asynchronous API for doing asynchronous crypto.
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RFC 0/2] clk: meson: g12a: handle clock hw changes while in suspend
From: Kevin Hilman @ 2019-09-26 20:46 UTC (permalink / raw)
To: Neil Armstrong, sboyd, jbrunet, mturquette
Cc: linux-amlogic, Neil Armstrong, linux-kernel, linux-arm-kernel,
linux-clk
In-Reply-To: <20190919102518.25126-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> This serie aime to support when the suspend/resume firmware alters the
> clock tree, leading to an incorrect representation of the clock tree
> after a resume from suspend-to-mem.
>
> For the Amlogic G12A/G12B/SM1 case, the SCPI firmware handling suspend
> alters the CPU clock tree in various ways.
>
> Since we know which part of the tree is possibly altered, we introduce here
> the clk_invalidate_rate() function that will rebuild the tree from the
> hardware registers in case parents and dividers have changed.
>
> Finally we call clk_invalidate_rate() from a new resume callback to refresh
> the CPU clock tree after a resume.
>
> With the clock tree refreshed, CCF can now handle the new clock tree
> configuration and avoid crashing the system on further DVFS set_rates.
For clarification, does this series work without the other proposed
fixes[1]? or is this dependent on that?
Kevin
[1] https://lore.kernel.org/linux-amlogic/20190919093627.21245-1-narmstrong@baylibre.com/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/4] arm64: vdso32: Address various issues
From: Vincenzo Frascino @ 2019-09-26 20:29 UTC (permalink / raw)
To: Catalin Marinas
Cc: ard.biesheuvel, ndesaulniers, linux-kernel, tglx, will,
linux-arm-kernel
In-Reply-To: <20190926153123.GK9689@arrakis.emea.arm.com>
On 9/26/19 4:31 PM, Catalin Marinas wrote:
> On Thu, Sep 26, 2019 at 02:38:01PM +0100, Vincenzo Frascino wrote:
>> this patch series is meant to address the various compilation issues you
>> reported about arm64 vdso32. (This time for real I hope ;))
>>
>> Please let me know if there is still something missing.
>
> Apart from the diff I posted and some nitpicks, the series looks fine to
> me. If you post an update, I'll ack it (and a tested-by).
>
> In addition to this series I'd still prefer to have my Kconfig option to
> disable the compat vDSO if something else fails in the future (at least
> until we complete the headers clean-up). But I'm fine with a default y
> and removing EXPERT.
>
It is fine by me, but may I ask to state in the commit message that the patch
can be reverted once the we fix the headers issue? I would like to have symmetry
in enabling vDSOs in between arm64 and compat once everything is fixed.
> Thanks for the quick turnaround.
>
No problem, it is my responsibility to fix the vDSOs on arm64 and compat if
something breaks ;)
--
Regards,
Vincenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/4] arm64: vdso32: Detect binutils support for dmb ishld
From: Vincenzo Frascino @ 2019-09-26 20:19 UTC (permalink / raw)
To: Catalin Marinas
Cc: ard.biesheuvel, ndesaulniers, linux-kernel, tglx, will,
linux-arm-kernel
In-Reply-To: <20190926142642.GF9689@arrakis.emea.arm.com>
On 9/26/19 3:26 PM, Catalin Marinas wrote:
> On Thu, Sep 26, 2019 at 02:38:03PM +0100, Vincenzo Frascino wrote:
>> diff --git a/arch/arm64/Kbuild b/arch/arm64/Kbuild
>> index d6465823b281..75cf8c796d0e 100644
>> --- a/arch/arm64/Kbuild
>> +++ b/arch/arm64/Kbuild
>> @@ -4,3 +4,9 @@ obj-$(CONFIG_NET) += net/
>> obj-$(CONFIG_KVM) += kvm/
>> obj-$(CONFIG_XEN) += xen/
>> obj-$(CONFIG_CRYPTO) += crypto/
>> +
>> +# as-instr-compat
>> +# Usage: cflags-y += $(call as-instr-compat,instr,option1,option2)
>> +
>> +as-instr-compat = $(call try-run,\
>> + printf "%b\n" "$(1)" | $(COMPATCC) $(KBUILD_AFLAGS) -c -x assembler -o "$$TMP" -,$(2),$(3))
>
> This doesn't seem to be used anywhere. Was it meant to be replaced by
> cc32-as-instr?
>
Forgot to squash a stash here. Will fix in v3. This is not used anymore was just
an experiment.
--
Regards,
Vincenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] arm64: vdso32: Introduce COMPAT_CC_IS_GCC
From: Vincenzo Frascino @ 2019-09-26 20:17 UTC (permalink / raw)
To: Catalin Marinas
Cc: ard.biesheuvel, ndesaulniers, linux-kernel, tglx, will,
linux-arm-kernel
In-Reply-To: <20190926151704.GH9689@arrakis.emea.arm.com>
On 9/26/19 4:17 PM, Catalin Marinas wrote:
> On Thu, Sep 26, 2019 at 01:22:01PM +0100, Vincenzo Frascino wrote:
>> On 9/26/19 11:56 AM, Vincenzo Frascino wrote:
>>> On 9/26/19 9:06 AM, Catalin Marinas wrote:
>>>> Now, could we not generate a COMPATCC in the Makefile and use
>>>> $(COMPATCC) here instead of $(CROSS_COMPILE_COMPAT)gcc? It really
>>>> doesn't make sense to check that gcc is gcc.
>>>>
>>>
>>> All right, COMPATCC is already in the makefile, I will use it in here.
>>
>> What you are proposing seems not possible because Kconfig runs first and then
>> the arch Makefile, hence compatcc does not take effect on the Kconfig. I will
>> post v2 with what I proposed, please feel free to comment if you have a better idea.
>
> I think it works as long as you export COMPATCC from the
> arch/arm64/Makefile. The arch Makefile is used in the config step
> AFAICT. See the diff I posted in my reply to your v2.
>
All right I will retry and repost v3 if I can get it working.
--
Regards,
Vincenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: Add /soc dma-ranges
From: Marek Vasut @ 2019-09-26 20:02 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Geert Uytterhoeven, Wolfram Sang,
open list:MEDIA DRIVERS FOR RENESAS - FCP,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Marek Vasut
In-Reply-To: <CAL_JsqK+SwX8Lu+-4UgpLVxL05yTcs8Af9mPVHqzbf6+HF9v3A@mail.gmail.com>
On 9/24/19 12:33 AM, Rob Herring wrote:
> On Fri, Sep 13, 2019 at 10:14 AM Rob Herring <robh@kernel.org> wrote:
>>
>> On Sat, Sep 7, 2019 at 5:16 PM <marek.vasut@gmail.com> wrote:
>>>
>>> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>>>
>>> Add dma-ranges property into /soc node to describe the DMA capabilities
>>> of the bus. This is currently needed to translate PCI DMA ranges, which
>>> are limited to 32bit addresses.
>>
>> FYI, I've started working on this problem and issues around
>> dma-ranges/dma_mask. Hopefully I'll get some patches out next week.
>
> I've pushed out a branch here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git dma-masks
>
> Can you test it on Renesas. I don't have a real platform having the issue.
Due to ER/KR, I can only test it Monday-ish. I hope that's OK ?
--
Best regards,
Marek Vasut
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [EXT] [PATCH v3] serial: imx: adapt rx buffer and dma periods
From: Adam Ford @ 2019-09-26 19:44 UTC (permalink / raw)
To: Ardelean, Alexandru
Cc: fugang.duan@nxp.com, kernel@pengutronix.de,
linux-serial@vger.kernel.org, gregkh@linuxfoundation.org,
s.hauer@pengutronix.de, jslaby@suse.com,
linux-kernel@vger.kernel.org, linux-imx@nxp.com,
festevam@gmail.com, u.kleine-koenig@pengutronix.de,
philipp.puschmann@emlix.com, yibin.gong@nxp.com,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org,
l.stach@pengutronix.de
In-Reply-To: <15be848facd5e80222e5db30c61fe72f82a85713.camel@analog.com>
On Thu, Sep 26, 2019 at 1:37 AM Ardelean, Alexandru
<alexandru.Ardelean@analog.com> wrote:
>
> On Wed, 2019-09-25 at 10:14 -0500, Adam Ford wrote:
> > [External]
> >
> > On Fri, Sep 20, 2019 at 2:06 AM Philipp Puschmann
> > <philipp.puschmann@emlix.com> wrote:
> > > Hi Andy,
> > >
> > > Am 20.09.19 um 05:42 schrieb Andy Duan:
> > > > From: Philipp Puschmann <philipp.puschmann@emlix.com> Sent: Thursday,
> > > > September 19, 2019 10:51 PM
> > > > > Using only 4 DMA periods for UART RX is very few if we have a high
> > > > > frequency
> > > > > of small transfers - like in our case using Bluetooth with many
> > > > > small packets
> > > > > via UART - causing many dma transfers but in each only filling a
> > > > > fraction of a
> > > > > single buffer. Such a case may lead to the situation that DMA RX
> > > > > transfer is
> > > > > triggered but no free buffer is available. When this happens dma
> > > > > channel ist
> > > > > stopped - with the patch
> > > > > "dmaengine: imx-sdma: fix dma freezes" temporarily only - with the
> > > > > possible
> > > > > consequences that:
> >
> > I have an i.MX6Q with Wl1837MOD on UART 2 with flow control, and I am
> > getting Bluetooth transfer timeouts.
> > (see imx6-logicpd-som.dtsi)
> >
> > On top of 5.3.1, I have installed:
> >
> > dmaengine: imx-sdma: fix buffer ownership
> > dmaengine: imx-sdma: fix dma freezes
> > dmaengine: imx-sdma: drop redundant variable
> > dmaengine: imx-sdma: fix kernel hangs with SLUB slab allocator
> > serial: imx: adapt rx buffer and dma periods
> >
> > and I still get timeouts:
> >
> > [ 66.632006] Bluetooth: hci0: command 0xff36 tx timeout
> > [ 76.790499] Bluetooth: hci0: command 0x1001 tx timeout
> > [ 87.110488] Bluetooth: hci0: command 0xff36 tx timeout
> > [ 97.270507] Bluetooth: hci0: command 0x1001 tx timeout
> > [ 107.590457] Bluetooth: hci0: command 0xff36 tx timeout
> > [ 117.750477] Bluetooth: hci0: command 0x1001 tx timeout
> > [ 226.390499] Bluetooth: hci0: command 0xfe38 tx timeout
> > [ 231.590735] Bluetooth: hci0: command tx timeout
> >
> > I did a bisect and found the start of my problems came from
> >
> > 361deb7243d2 ("dmaengine: dmatest: wrap src & dst data into a struct")
>
> That commit only touches `drivers/dma/dmatest.c`
> Are you using that module?
>
> It's a "unit-test" module for testing DMAengine drivers.
> The only way that can break anything [from what I can tell], is if it is
> being run. It will probably put the DMA into a weird state (it is a test-
> module after-all), and it may require some DMAs to be reset.
> I admit it would be nice that the test-module would put the DMA back into a
> normal-working state, but that effort could be big for some cases.
I will bisect it again. I removed the CONFIG_DMATEST from the
omx_v6_v7_defconfig, and I still got the failure using Kernel 5.3.1,
so I'll work on this tomorrow and try to narrow it down better with
and without the test module installed.
adam
>
>
> >
> > This happened sometime between v5.0 and v5.1
> >
> > Is there a patch I missed somewhere? Do I need to change my device
> > tree configuration somehow to allocate the proper DMA memory?
> >
> >
> >
> > > > > with disabled hw flow control:
> > > > > If enough data is incoming on UART port the RX FIFO runs over and
> > > > > characters will be lost. What then happens depends on upper
> > > > > layer.
> > > > >
> > > > > with enabled hw flow control:
> > > > > If enough data is incoming on UART port the RX FIFO reaches a
> > > > > level
> > > > > where CTS is deasserted and remote device sending the data stops.
> > > > > If it fails to stop timely the i.MX' RX FIFO may run over and
> > > > > data
> > > > > get lost. Otherwise it's internal TX buffer may getting filled to
> > > > > a point where it runs over and data is again lost. It depends on
> > > > > the remote device how this case is handled and if it is
> > > > > recoverable.
> > > > >
> > > > > Obviously we want to avoid having no free buffers available. So we
> > > > > decrease
> > > > > the size of the buffers and increase their number and the total
> > > > > buffer size.
> > > > >
> > > > > Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
> > > > > Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> > > > > ---
> > > > >
> > > > > Changelog v3:
> > > > > - enhance description
> > > > >
> > > > > Changelog v2:
> > > > > - split this patch from series "Fix UART DMA freezes for iMX6"
> > > > > - add Reviewed-by tag
> > > > >
> > > > > drivers/tty/serial/imx.c | 5 ++---
> > > > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> > > > > index
> > > > > 87c58f9f6390..51dc19833eab 100644
> > > > > --- a/drivers/tty/serial/imx.c
> > > > > +++ b/drivers/tty/serial/imx.c
> > > > > @@ -1034,8 +1034,6 @@ static void imx_uart_timeout(struct
> > > > > timer_list *t)
> > > > > }
> > > > > }
> > > > >
> > > > > -#define RX_BUF_SIZE (PAGE_SIZE)
> > > > > -
> > > > > /*
> > > > > * There are two kinds of RX DMA interrupts(such as in the MX6Q):
> > > > > * [1] the RX DMA buffer is full.
> > > > > @@ -1118,7 +1116,8 @@ static void imx_uart_dma_rx_callback(void
> > > > > *data) }
> > > > >
> > > > > /* RX DMA buffer periods */
> > > > > -#define RX_DMA_PERIODS 4
> > > > > +#define RX_DMA_PERIODS 16
> > > > > +#define RX_BUF_SIZE (PAGE_SIZE / 4)
> > > > >
> > > > Why to decrease the DMA RX buffer size here ?
> > > >
> > > > The current DMA implementation support DMA cyclic mode, one SDMA BD
> > > > receive one Bluetooth frame can
> > > > bring better performance.
> > > > As you know, for L2CAP, a maximum transmission unit (MTU) associated
> > > > with the largest Baseband payload
> > > > is 341 bytes for DH5 packets.
> > > >
> > > > So I suggest to increase RX_BUF_SIZE along with RX_DMA_PERIODS to
> > > > feasible value.
> > >
> > > I debugged and developed this patches on a system with a 4.15 kernel.
> > > When prepared for upstream i have adapted
> > > some details and missed a important thing here. It should say:
> > >
> > > +#define RX_BUF_SIZE (RX_DMA_PERIODS * PAGE_SIZE / 4)
> > >
> > > Yes, i wanted to increase the total buffer size too, even wrote it in
> > > the description.
> > > I will prepare a version 4, thanks for the hint.
> > >
> > > Just for info: A single RX DMA period aka buffer can be filled with
> > > mutliple packets in regard of the upper layer, here BT.
> > >
> > >
> > > Regards,
> > > Philipp
> > > > Andy
> > > >
> > > > > static int imx_uart_start_rx_dma(struct imx_port *sport) {
> > > > > --
> > > > > 2.23.0
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] arm64: configs: unset CPU_BIG_ENDIAN
From: Anders Roxell @ 2019-09-26 19:30 UTC (permalink / raw)
To: catalin.marinas, will; +Cc: Anders Roxell, linux-kernel, linux-arm-kernel
In-Reply-To: <20190926193030.5843-1-anders.roxell@linaro.org>
When building allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig
CONFIG_CPU_BIG_ENDIAN gets enabled. Which tends not to be what most
people wants.
Rework so that we disable CONFIG_CPU_BIG_ENDIAN in the defcinfig file so
it doesn't get enabled when building allmodconfig kernels. When doing a
'make savedefconfig' CONFIG_CPU_BIG_ENDIAN will be dropped.
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 878f379d8d84..c9aa6b9ee996 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -855,3 +855,4 @@ CONFIG_DEBUG_KERNEL=y
# CONFIG_SCHED_DEBUG is not set
CONFIG_MEMTEST=y
# CONFIG_CMDLINE_FORCE is not set
+# CONFIG_CPU_BIG_ENDIAN is not set
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] arm64: configs: unset CMDLINE_FORCE
From: Anders Roxell @ 2019-09-26 19:30 UTC (permalink / raw)
To: catalin.marinas, will; +Cc: Anders Roxell, linux-kernel, linux-arm-kernel
In-Reply-To: <20190926193030.5843-1-anders.roxell@linaro.org>
When building allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig
CONFIG_CMDLINE_FORCE gets enabled. Which forces the user to pass the
full cmdline to CONFIG_CMDLINE="...".
Rework so that we disable CONFIG_CMDLINE_FORCE in the defconfig file so
we don't have to pass in the CONFIG_CMDLINE="..." when building an
allmodconfig kernel. Since CONFIG_CMDLINE_FORCE is unset default, so
when doing 'make savedefconfig' CONFIG_CMDLINE_FORCE will be dropped.
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 52a32b53b2ed..878f379d8d84 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -854,3 +854,4 @@ CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_SCHED_DEBUG is not set
CONFIG_MEMTEST=y
+# CONFIG_CMDLINE_FORCE is not set
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] arm64: configs: defconfig: remove unneeded fragments
From: Anders Roxell @ 2019-09-26 19:30 UTC (permalink / raw)
To: catalin.marinas, will; +Cc: Anders Roxell, linux-kernel, linux-arm-kernel
In-Reply-To: <20190926193030.5843-1-anders.roxell@linaro.org>
Commit 833c97254724 ("arm64: defconfig: Enable DRM DU and V4L2 FCP + VSP
modules") ment to enable the camera framework and drivers but enabled a
bit more.
Since we don't have any drivers for MEDIA_ANALOG_TV_SUPPORT or
MEDIA_DIGITAL_TV_SUPPORT theres no meaning to enable the framework to
the defconfig.
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
arch/arm64/configs/defconfig | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 8e05c39eab08..56dc7488ff36 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -501,11 +501,8 @@ CONFIG_IR_MESON=m
CONFIG_IR_SUNXI=m
CONFIG_MEDIA_SUPPORT=m
CONFIG_MEDIA_CAMERA_SUPPORT=y
-CONFIG_MEDIA_ANALOG_TV_SUPPORT=y
-CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y
CONFIG_MEDIA_CONTROLLER=y
CONFIG_VIDEO_V4L2_SUBDEV_API=y
-# CONFIG_DVB_NET is not set
CONFIG_MEDIA_USB_SUPPORT=y
CONFIG_USB_VIDEO_CLASS=m
CONFIG_V4L_PLATFORM_DRIVERS=y
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] arm64: defconfig: set/unset for allmodconfig
From: Anders Roxell @ 2019-09-26 19:30 UTC (permalink / raw)
To: catalin.marinas, will; +Cc: Anders Roxell, linux-kernel, linux-arm-kernel
Hi,
I'm trying to get an allmodconfig kernel to boot. The way I configure
the kernel is:
'make allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig'
allmodconfig will use the KCONFIG_ALLCONFIG file as the base and then
turn the rest into modules.
The idea behind using the defconfig as base and then configure the rest
as modules is to get a bootbable kernel that have as many features
turned on as possible. That will make it possible to run as wide a
range of testsuites as possible on a single kernel.
These patches makes it possible to boot a LE kernel.
Cheers,
Anders
Anders Roxell (3):
arm64: configs: defconfig: enable DEBUG_PREEMPT and FTRACE
arm64: configs: unset CMDLINE_FORCE
arm64: configs: unset CPU_BIG_ENDIAN
arch/arm64/configs/defconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] arm64: configs: defconfig: enable DEBUG_PREEMPT and FTRACE
From: Anders Roxell @ 2019-09-26 19:30 UTC (permalink / raw)
To: catalin.marinas, will; +Cc: Anders Roxell, linux-kernel, linux-arm-kernel
In-Reply-To: <20190926193030.5843-1-anders.roxell@linaro.org>
When building an allmodconfig KCONFIG_ALLCONFIG=$(pwd)/arch/arm64/configs/defconfig
kernel, CONFIG_DEBUG_PREEMPT and CONFIG_FTRACE will be turn off.
There is no benefit in disabling these fragments. By enabling these
nothing will happen without interaction from the user to enable it from
the cmd or boot line.
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
arch/arm64/configs/defconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 56dc7488ff36..52a32b53b2ed 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -853,6 +853,4 @@ CONFIG_DEBUG_FS=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_SCHED_DEBUG is not set
-# CONFIG_DEBUG_PREEMPT is not set
-# CONFIG_FTRACE is not set
CONFIG_MEMTEST=y
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/1] arm64/sve: Fix wrong free for task->thread.sve_state
From: Masayoshi Mizuma @ 2019-09-26 19:08 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, linux-arm-kernel
Cc: Masayoshi Mizuma, Masayoshi Mizuma, linux-kernel
In-Reply-To: <20190926190846.3072-1-msys.mizuma@gmail.com>
From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
The system which has SVE feature crashed because of
the memory pointed by task->thread.sve_state was destroyed
by someone.
That is because sve_state is freed while the forking the
child process. The child process has the pointer of sve_state
which is same as the parent's because the child's task_struct
is copied from the parent's one. If the copy_process()
fails as an error on somewhere, for example, copy_creds(),
then the sve_state is freed even if the parent is alive.
The flow is as follows.
copy_process
p = dup_task_struct
=> arch_dup_task_struct
*dst = *src; // copy the entire region.
:
retval = copy_creds
if (retval < 0)
goto bad_fork_free;
:
bad_fork_free:
...
delayed_free_task(p);
=> free_task
=> arch_release_task_struct
=> fpsimd_release_task
=> __sve_free
=> kfree(task->thread.sve_state);
// free the parent's sve_state
Add a flag in task->thread which shows the fork is in progress.
If the fork is in progress, that means the child has the pointer
to the parent's sve_state, doesn't free the sve_state.
Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Reported-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
---
arch/arm64/include/asm/processor.h | 1 +
arch/arm64/kernel/fpsimd.c | 6 ++++--
arch/arm64/kernel/process.c | 2 ++
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 5623685c7d13..3ca3e350145a 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -143,6 +143,7 @@ struct thread_struct {
unsigned long fault_address; /* fault info */
unsigned long fault_code; /* ESR_EL1 value */
struct debug_info debug; /* debugging */
+ unsigned int fork_in_progress;
#ifdef CONFIG_ARM64_PTR_AUTH
struct ptrauth_keys keys_user;
#endif
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 37d3912cfe06..8641db4cb062 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -202,8 +202,10 @@ static bool have_cpu_fpsimd_context(void)
*/
static void __sve_free(struct task_struct *task)
{
- kfree(task->thread.sve_state);
- task->thread.sve_state = NULL;
+ if (!task->thread.fork_in_progress) {
+ kfree(task->thread.sve_state);
+ task->thread.sve_state = NULL;
+ }
}
static void sve_free(struct task_struct *task)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index a47462def04b..8ac0ee4e5f76 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -347,6 +347,7 @@ int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
if (current->mm)
fpsimd_preserve_current_state();
*dst = *src;
+ dst->thread.fork_in_progress = 1;
return 0;
}
@@ -365,6 +366,7 @@ int copy_thread(unsigned long clone_flags, unsigned long stack_start,
* and disable discard SVE state for p:
*/
clear_tsk_thread_flag(p, TIF_SVE);
+ p->thread.fork_in_progress = 0;
p->thread.sve_state = NULL;
/*
--
2.18.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/1] arm64/sve: Fix wrong free for task->thread.sve_state
From: Masayoshi Mizuma @ 2019-09-26 19:08 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, linux-arm-kernel
Cc: Masayoshi Mizuma, Masayoshi Mizuma, linux-kernel
From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
The system which has SVE feature crashed by unknown
reason. According to the memory dump, the panic happened
because the memory data pointed by task->thread.sve_state was
destroyed by someone.
We tried to reproduce the crash, however, it's hard to do that.
But, we found a potential issue by reviewing the code.
In copy_process(), the child process has the pointer of sve_state
which is same as the parent's because the child's task_struct is
copied from the parent's one. If the copy_process() fails as an
error on somewhere, for example, copy_creds(), then the sve_state
is freed even if the parent is alive. The flow is as follows.
copy_process
p = dup_task_struct
=> arch_dup_task_struct
*dst = *src; // copy the entire region.
:
retval = copy_creds
if (retval < 0)
goto bad_fork_free;
:
bad_fork_free:
...
delayed_free_task(p);
=> free_task
=> arch_release_task_struct
=> fpsimd_release_task
=> __sve_free
=> kfree(task->thread.sve_state);
// free the parent's sve_state
To fix that, add a flag in task->thread which shows the fork
is in progress. If the fork is in progress, that means the
child has the pointer to the parent's sve_state, doesn't
free the sve_state.
Masayoshi Mizuma (1):
arm64/sve: Fix wrong free for task->thread.sve_state
arch/arm64/include/asm/processor.h | 1 +
arch/arm64/kernel/fpsimd.c | 6 ++++--
arch/arm64/kernel/process.c | 2 ++
3 files changed, 7 insertions(+), 2 deletions(-)
--
2.18.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] soc: amlogic: ee-pwrc: ensure driver state maches HW state
From: Kevin Hilman @ 2019-09-26 19:08 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, linux-amlogic; +Cc: linux-arm-kernel, linux-pm
In-Reply-To: <8936e777-8996-5c7b-ea9d-8e17c8d6c4b1@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> On 25/09/2019 23:35, Kevin Hilman wrote:
>> From: Kevin Hilman <khilman@baylibre.com>
>>
>> During init, ensure that the driver on/off state as well as clock and
>> reset state matches the hardware state. Do this by always calling the
>> drivers 'on' function, and then callling the 'off' function if the
>> HW state was initially detected as off.
[...]
> I don't see what you are trying to solve except simplifying the code.
Simplifying the code is a worthwhile goal on its own, but that's not the
only thing I'm tring to accomplish.
Part of the goal is make the init less VPU specific and thus make it
more understandable/maintainable. But the more important part is to
ensure that the driver state and HW state is consistent for all the
domains (not just VPU.) I've had to debug lots of power-domain issues,
and inconsistiences between HW state and driver state tend to be the
primary cause of problems.
Also I'm generally not a fan of the "don't mess with bootloader state"
approach as that leads to subtle dependencies on specific bootloader
versions that are also difficult to debug.
Antother equally important goal is to actually be able to power-down the
VPU when it's not used. Right now, we'll never power off the VPU if the
bootloader enabled it, and that seems a bit extreme so I'm looking to
improve that and be able to power off the VPU when not used.
> And the case is more that "matching the clock state" here, the
> pm_domain_always_on_gov was is a real case when booting from the Amlogic
> U-boot.
I'm not understanding what you mean about vendor uboot. I've done
testing with vendor uboot too:
I tried on g12a-u200, g12a-x96-max, and sm1-khadas-vim3l all of which
have vendor uboot, and I tried before and after $SUBJECT patch.
In all cases, I see the vendor uboot splash screen, and I see the
framebuffer console from linux after kernel boot. I see the same
behavior before and after my patch.
I also tried on g12b-odroid-n2 (vendor uboot), and there is _no_ uboot
spash screen, but I see the linux framebuffer console come up both
before and after my patch.
What's the specific case you're worried about with vendor uboot?
Also... note something interesting I noticed on sm1-khadas-vim3l:
before my patch, the framebuffer console appears, but the background is
a bluish/green color. After my patch, the background is black (as
expected.)
> The display power domain is complex and as been half solved by using
> "simple-framebuffer" on gx and is missing on g12a/g12b/sm1.
>
> For example, Debian installer runs without the modules, but will use
> the EFIfb set by U-Boot, but in this precise case :
> - the DRM driver isn't loaded
> - we can't hook this power domain with EFIfb
OK, so I agree that this case where we want the display to continue to
work but linux DRM drivers never loaded is a special case.
Is there a way to check if efifb is enabled? Is the the linux driver
(drivers/video/fbdev/efifb.c) or something else only done by uboot?
If we can detect efifb from the kernel (not just whether the domain is
already on), then a simple addition to my patch like this:
if (is_off)
meson_ee_pwrc_off(&dom->base);
+ else if (efifb_is_enabled)
+ dom->base.flags |= GENPD_FLAG_ALWAYS_ON;
would force the domain always-on in the case of efifb.
In fact, now that I think of it, simply adding:
if (is_off)
meson_ee_pwrc_off(&dom->base);
+ else
+ dom->base.flags |= GENPD_FLAG_ALWAYS_ON;
to my current patch would get back to the same behavior of the existing
driver. But I still don't like the idea that we can *never* power off
the VPU if the bootloader enables it. :( I'd rather see patches
conditionally adding that flag with detailed explanations as to why it's
needed.
> When *not* in EFIfb, we use simple-framebuffer on GX, using this
> power domain, but it hasn't been copied to G12A.
I don't quite understand what problem simple-framebuffer is
solving. Could you explain that in more detail.
Assuming it is solving something, why can't it be used on g12[ab]/sm1 ?
> Personally I'll leave this code until we really tested and checked all
> uses cases,
Right, I don't want to break anything on purpose, but I think the
current state of this driver is fragile and difficult to
understand/maintain, so I would be grateful for any help in
understanding the corner cases better, as well as testing them (or
explaining to me how to reproduce them.)
Generally, with long-term maintenance in mind, if I'm forced to choose
between understandable/maintainable code and "covers 100% of corner
cases" I will most often chose the former.
> not only on the sei510/sei610 using mainline u-boot.
See above about all the other boards with vendor uboots also tested.
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] dt-bindings: timer: Use defines instead of numbers in Exynos MCT examples
From: Krzysztof Kozlowski @ 2019-09-26 18:36 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Mark Rutland,
Kukjin Kim, Krzysztof Kozlowski, linux-kernel, devicetree,
linux-arm-kernel, linux-samsung-soc
Cc: Marek Szyprowski
Make the examples in Exynos Multi Core Timer bindings more readable and
bring them closer to real DTS by using defines for interrupt flags.
Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Rebased on top of:
https://patchwork.kernel.org/project/linux-samsung-soc/list/?series=177667&state=*
---
.../timer/samsung,exynos4210-mct.yaml | 37 ++++++++++++++-----
1 file changed, 27 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
index bff3f54a398f..c4d152009f76 100644
--- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
+++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
@@ -75,51 +75,68 @@ examples:
// In this example, the IP contains two local timers, using separate
// interrupts, so two local timer interrupts have been specified,
// in addition to four global timer interrupts.
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
timer@10050000 {
compatible = "samsung,exynos4210-mct";
reg = <0x10050000 0x800>;
- interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
- <0 42 0>, <0 48 0>;
+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
};
- |
// In this example, the timer interrupts are connected to two separate
// interrupt controllers. Hence, an interrupts-extended is needed.
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
timer@101c0000 {
compatible = "samsung,exynos4210-mct";
reg = <0x101C0000 0x800>;
- interrupts-extended = <&gic 0 57 0>,
- <&gic 0 69 0>,
+ interrupts-extended = <&gic GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
<&combiner 12 6>,
<&combiner 12 7>,
- <&gic 0 42 0>,
- <&gic 0 48 0>;
+ <&gic GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
};
- |
// In this example, the IP contains four local timers, but using
// a per-processor interrupt to handle them. Only one first local
// interrupt is specified.
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
timer@10050000 {
compatible = "samsung,exynos4412-mct";
reg = <0x10050000 0x800>;
- interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
- <0 42 0>;
+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
};
- |
// In this example, the IP contains four local timers, but using
// a per-processor interrupt to handle them. All the local timer
// interrupts are specified.
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
timer@10050000 {
compatible = "samsung,exynos4412-mct";
reg = <0x10050000 0x800>;
- interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
- <0 42 0>, <0 42 0>, <0 42 0>, <0 42 0>;
+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 0/5] provide the XTAL clock via OF on Meson8/8b/8m2
From: Martin Blumenstingl @ 2019-09-26 18:34 UTC (permalink / raw)
To: Kevin Hilman
Cc: mark.rutland, devicetree, Neil Armstrong, linux-kernel, robh+dt,
linux-amlogic, linux-clk, linux-arm-kernel, Jerome Brunet
In-Reply-To: <7h7e5wt2m1.fsf@baylibre.com>
Hi Kevin,
On Thu, Sep 26, 2019 at 12:47 AM Kevin Hilman <khilman@baylibre.com> wrote:
>
> Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
>
> > Hi Jerome,
> >
> > On Mon, Sep 23, 2019 at 11:29 AM Jerome Brunet <jbrunet@baylibre.com> wrote:
> >>
> >> On Sat 21 Sep 2019 at 17:12, Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
> >>
> >> > So far the HHI clock controller has been providing the XTAL clock on
> >> > Amlogic Meson8/Meson8b/Meson8m2 SoCs.
> >> > This is not correct because the XTAL is actually a crystal on the
> >> > boards and the SoC has a dedicated input for it.
> >> >
> >> > This updates the dt-bindings of the HHI clock controller and defines
> >> > a fixed-clock in meson.dtsi (along with switching everything over to
> >> > use this clock).
> >> > The clock driver needs three updates to use this:
> >> > - patch #2 uses clk_hw_set_parent in the CPU clock notifier. This drops
> >> > the explicit reference to CLKID_XTAL while at the same time making
> >> > the code much easier (thanks to Neil for providing this new method
> >> > as part of the G12A CPU clock bringup!)
> >> > - patch #3 ensures that the clock driver doesn't rely on it's internal
> >> > XTAL clock while not losing support for older .dtbs that don't have
> >> > the XTAL clock input yet
> >> > - with patch #4 the clock controller's own XTAL clock is not registered
> >> > anymore when a clock input is provided via OF
> >> >
> >> > This series is a functional no-op. It's main goal is to better represent
> >> > how the actual hardware looks like.
> >>
> >> I'm a bit unsure about this series.
> >>
> >> On one hand, I totally agree with you ... having the xtal in DT is the
> >> right way to do it ... when done from the start
> > yep
> >
> >> On the other hand, things have been this way for years, they are working
> >> and going for xtal in DT does not solve any pending issue. Doing this
> >> means adding complexity in the driver to support both methods. It is
> >> also quite a significant change in DT :/
> > my two main motivations were:
> > - keeping the 32-bit SoCs as similar as possible to the 64-bit ones in
> > terms of "how are the [clock] drivers implemented"
> > - with the DDR clock controller the .dts looked weird: &ddr_clkc took
> > CLKID_XTAL from &clkc as input and &clkc took DDR_CLKID_DDR_PLL as
> > input from &ddr_clkc
> >
> > RE complexity in the driver to support both:
> > I still have a cleanup of the meson8b.c init code on my TODO-list
> > because we're still supporting .dtbs without parent syscon
> > my plan is to drop that code-path along with the newly added fallback
> > for "skip CLKID_XTAL" (assuming this is accepted) together for v5.6 or
> > v5.7
>
> TBH, I'm big(ish) "functional no-op" changes like this are not things I
> get super exicted about, especially for SoCs that have been working well
> for awhile, and are do not have a large (upstream) userbase.
>
> OTOH, since Martin is doing most of the heavy lifting for keeping this
> platform working upstream, I'm happy to take the changes, as long as
> Martin is willing to deal with any fallout.
I agree: it has to work and if it doesn't then I will have to fix it so it is
so I will be taking care of any fallout
Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] clk: imx: disable i.mx7ulp composite clock during initialization
From: Fabio Estevam @ 2019-09-26 18:10 UTC (permalink / raw)
To: Anson Huang
Cc: Aisheng Dong, s.hauer@pengutronix.de, gustavo@embeddedor.com,
Stephen Boyd, mturquette@baylibre.com,
linux-kernel@vger.kernel.org, dl-linux-imx, kernel@pengutronix.de,
shawnguo@kernel.org, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <DB3PR0402MB3916F96CD6F3E874204E6972F5D50@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Hi Anson,
On Mon, Aug 5, 2019 at 11:25 PM Anson Huang <anson.huang@nxp.com> wrote:
>
> Hi, Stephen
> I think we should resume this thread, without this patch, mainline kernel boot up will cause mmc timeout all the time. If it is NOT good to disabling those peripheral devices' clock in i.MX7ULP's clock driver, then we have to change the core framework to disable clock explicitly if the CLK_SET_RATE_GATE/CLK_SET_PARENT_GATE is present, most likely it will impact other platforms I think, so the most safe way is just to do it inside our i.MX7ULP composite clock driver. What do you think?
Just tested your patch against 5.3 and mmc card can be detected with it.
Please note that I had to manually add:
#include <linux/io.h>
so that it can build.
I agree we need to come to a solution for this.
Stephen, please let us know your thoughts.
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 2/2] kselftest: exclude failed TARGETS from runlist
From: Cristian Marussi @ 2019-09-26 17:52 UTC (permalink / raw)
To: linux-kselftest, linux-arm-kernel, shuah; +Cc: Tim.Bird, dave.martin
In-Reply-To: <20190926175219.29805-1-cristian.marussi@arm.com>
A TARGET which failed to be built/installed should not be included in the
runlist generated inside the run_kselftest.sh script.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
As an example, here BPF failed to compile but was included in the runlist
and attempted to run anyway:
...
./KSFT_LAST_2/run_kselftest.sh: 37: cd: can't cd to bpf
TAP version 13
1..49
\# selftests: KSFT_LAST_2: test_verifier
\# Warning: file test_verifier is missing!
not ok 1 selftests: KSFT_LAST_2: test_verifier
\# selftests: KSFT_LAST_2: test_tag
\# Warning: file test_tag is missing!
---
tools/testing/selftests/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 9621b26ee433..d7a9df186837 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -205,8 +205,12 @@ ifdef INSTALL_PATH
echo " cat /dev/null > \$$logfile" >> $(ALL_SCRIPT)
echo "fi" >> $(ALL_SCRIPT)
+ @# While building run_kselftest.sh skip also non-existent TARGET dirs:
+ @# they could be the result of a build failure and should NOT be
+ @# included in the generated runlist.
for TARGET in $(TARGETS); do \
BUILD_TARGET=$$BUILD/$$TARGET; \
+ [ ! -d $$INSTALL_PATH/$$TARGET ] && echo "Skipping non-existent dir: $$TARGET" && continue; \
echo "[ -w /dev/kmsg ] && echo \"kselftest: Running tests in $$TARGET\" >> /dev/kmsg" >> $(ALL_SCRIPT); \
echo "cd $$TARGET" >> $(ALL_SCRIPT); \
echo -n "run_many" >> $(ALL_SCRIPT); \
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/2] kselftest: add capability to skip chosen TARGETS
From: Cristian Marussi @ 2019-09-26 17:52 UTC (permalink / raw)
To: linux-kselftest, linux-arm-kernel, shuah; +Cc: Tim.Bird, dave.martin
In-Reply-To: <20190926175219.29805-1-cristian.marussi@arm.com>
Let the user specify an optional TARGETS skiplist through the new optional
SKIP_TARGETS Makefile variable.
It is easier to skip at will using a reduced and well defined list of
possibly problematic targets with SKIP_TARGETS than to provide a partially
stripped down list of good targets using the usual TARGETS variable.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
v1 --> v2
- fixed commit msg
- added documentation fix
- added forced override to allow TARGETS= and SKIP_TARGETS
being both passed on the cmdline
---
Documentation/dev-tools/kselftest.rst | 16 ++++++++++++++++
tools/testing/selftests/Makefile | 7 +++++++
2 files changed, 23 insertions(+)
diff --git a/Documentation/dev-tools/kselftest.rst b/Documentation/dev-tools/kselftest.rst
index 25604904fa6e..ecdfdc9d4b03 100644
--- a/Documentation/dev-tools/kselftest.rst
+++ b/Documentation/dev-tools/kselftest.rst
@@ -89,6 +89,22 @@ To build, save output files in a separate directory with KBUILD_OUTPUT ::
$ export KBUILD_OUTPUT=/tmp/kselftest; make TARGETS="size timers" kselftest
+Additionally you can use the "SKIP_TARGETS" variable on the make command
+line to specify one or more targets to exclude from the TARGETS list.
+
+To run all tests but a single subsystem::
+
+ $ make -C tools/testing/selftests SKIP_TARGETS=ptrace run_tests
+
+You can specify multiple tests to skip::
+
+ $ make SKIP_TARGETS="size timers" kselftest
+
+You can also specify a restricted list of tests to run together with a
+dedicated skiplist::
+
+ $ make TARGETS="bpf breakpoints size timers" SKIP_TARGETS=bpf kselftest
+
See the top-level tools/testing/selftests/Makefile for the list of all
possible targets.
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 25b43a8c2b15..9621b26ee433 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -63,6 +63,13 @@ TARGETS += zram
TARGETS_HOTPLUG = cpu-hotplug
TARGETS_HOTPLUG += memory-hotplug
+# User can optionally provide a TARGETS skiplist.
+SKIP_TARGETS ?=
+ifneq ($(SKIP_TARGETS),)
+ TMP := $(filter-out $(SKIP_TARGETS), $(TARGETS))
+ override TARGETS := $(TMP)
+endif
+
# Clear LDFLAGS and MAKEFLAGS if called from main
# Makefile to avoid test build failures when test
# Makefile doesn't have explicit build rules.
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/2] Fix KSFT toplevel makefile behaviour
From: Cristian Marussi @ 2019-09-26 17:52 UTC (permalink / raw)
To: linux-kselftest, linux-arm-kernel, shuah; +Cc: Tim.Bird, dave.martin
Hi
so this series carries two small fixes to the toplevel KSelfTest makefile
which I found useful especially while attempting to run the suite in
automation.
[1/2]
While it is already possible to specify a limited list of TARGETS to run,
it is not instead easily possible to state a list of targets NOT to run
(say due to specific instability issues).
Moreover providing such a skip list through a stripped down list of TARGETS
it is cumbersome and fragile since this poses the risk to stick to an old
stale stripped TARGETS list once upstream decides to add more default
targets.
A new SKIP_TARGETS Makefile variable is provided by this patch to easily
specify a skiplist for target subsystems.
[2/2]
Currently when some target fails to build, KSFT Makefile just carries on
building as much subsystems as it can: unfortunately this is not properly
reflected also in the generation of the runlist inside run_kselftest.sh.
This patch rectifies this behaviour checking for the existence of a target
directory in the INSTALL_PATH before adding the related snippet to the
run_kselftest.sh script.
Thanks
Cristian
Changelog
v1 --> v2
- added Documentation
- various typos fixed
- added a proper override when filtering-out SKIP_TARGETS from TARGETS
to make it work also when TARGETS is provided too from the cmdline
Cristian Marussi (2):
kselftest: add capability to skip chosen TARGETS
kselftest: exclude failed TARGETS from runlist
Documentation/dev-tools/kselftest.rst | 11 +++++++++++
tools/testing/selftests/Makefile | 11 +++++++++++
2 files changed, 22 insertions(+)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] staging: media: imx: Use devm_platform_ioremap_resource().
From: Rui Miguel Silva @ 2019-09-26 17:24 UTC (permalink / raw)
To: Jeeeun Evans
Cc: devel, festevam, kernel, gregkh, s.hauer, linux-kernel, linux-imx,
p.zabel, slongerbeam, mchehab, shawnguo, linux-arm-kernel,
linux-media
In-Reply-To: <20190926155539.GA20744@sausagefarm>
Hi Jeeeun,
On Thu 26 Sep 2019 at 16:55, Jeeeun Evans wrote:
> This patch fixes a warning by coccicheck:
> drivers/staging/media/imx/imx7-mipi-csis.c:973:1-12: WARNING: Use devm_platform_ioremap_resource for state -> regs
>
> Use devm_platform_ioremap_resource helper which wraps platform_get_resource()
> and devm_ioremap_resource() together.
>
> Signed-off-by: Jeeeun Evans <jeeeunevans@gmail.com>
>
Thanks for the patch.
LGTM.
Reviewed-by: Rui Miguel Silva <rmfrfs@gmail.com>
---
Cheers,
Rui
> drivers/staging/media/imx/imx7-mipi-csis.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c b/drivers/staging/media/imx/imx7-mipi-csis.c
> index 73d8354e618c..bf21db38441f 100644
> --- a/drivers/staging/media/imx/imx7-mipi-csis.c
> +++ b/drivers/staging/media/imx/imx7-mipi-csis.c
> @@ -947,7 +947,6 @@ static void mipi_csis_debugfs_exit(struct csi_state *state)
> static int mipi_csis_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct resource *mem_res;
> struct csi_state *state;
> int ret;
>
> @@ -969,8 +968,7 @@ static int mipi_csis_probe(struct platform_device *pdev)
> mipi_csis_phy_init(state);
> mipi_csis_phy_reset(state);
>
> - mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - state->regs = devm_ioremap_resource(dev, mem_res);
> + state->regs = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(state->regs))
> return PTR_ERR(state->regs);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: Allow disabling of the compat vDSO
From: Nick Desaulniers @ 2019-09-26 16:40 UTC (permalink / raw)
To: Catalin Marinas
Cc: Ard Biesheuvel, LKML, Thomas Gleixner, Vincenzo Frascino,
Will Deacon, Linux ARM
In-Reply-To: <20190926155147.GL9689@arrakis.emea.arm.com>
On Thu, Sep 26, 2019 at 8:51 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> On Thu, Sep 26, 2019 at 08:47:18AM +0100, Catalin Marinas wrote:
> > On Thu, Sep 26, 2019 at 01:06:50AM +0100, Vincenzo Frascino wrote:
> > > On 9/25/19 6:08 PM, Catalin Marinas wrote:
> > > > On Wed, Sep 25, 2019 at 09:53:16AM -0700, Nick Desaulniers wrote:
> > > >> On Wed, Sep 25, 2019 at 6:09 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > >>> - clean up the headers includes; vDSO should not include kernel-only
> > > >>> headers that may even contain code patched at run-time
> > > >>
> > > >> This is a big one; Clang validates the inline asm constraints for
> > > >> extended inline assembly, GCC does not for dead code. So Clang chokes
> > > >> on the inclusion of arm64 headers using extended inline assembly when
> > > >> being compiled for arm-linux-gnueabi.
This case is very much real (not sure if Vincenzo was asking me or
Catalin), see report at the bottom of this comment:
https://github.com/ClangBuiltLinux/linux/issues/595#issuecomment-509874891
> > > >
> > > > Whether clang or gcc, I'd like this fixed anyway. At some point we may
> > > > inadvertently rely on some code which is patched at boot time for the
> > > > kernel code but not for the vDSO.
> > >
> > > Do we have any code of this kind in header files?
> > >
> > > The vDSO library uses only a subset of the headers (mainly Macros) hence all the
> > > unused symbols should be compiled out. Is your concern only theoretical or do
> > > you have an example on where this could be happening?
> >
> > At the moment it's rather theoretical.
>
> Actually, it's not. The moment the compat vdso Makefile needs the line
> below, we are doing it wrong:
>
> VDSO_CFLAGS += -D__uint128_t='void*'
*yikes*
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox