> From: Johan Jonker
> Date: Thu, 1 Apr 2021 23:36:48 +0200
>
> The conversion of rockchip,dwc3.txt to yaml was added to linux-next,
> but the necessary changes for rk3399 are still pending.
>
> For rk3399 dwc3 usb the wrapper node for only clocks makes no sense,
> so that was removed in the YA
> From: Arnd Bergmann
> Date: Fri, 26 Mar 2021 20:59:58 +0100
>
> On Fri, Mar 26, 2021 at 6:51 PM Sven Peter wrote:
> > On Fri, Mar 26, 2021, at 18:34, Robin Murphy wrote:
> > > On 2021-03-26 17:26, Mark Kettenis wrote:
> > > >
> > > > Anyway,
> From: Arnd Bergmann
> Date: Fri, 26 Mar 2021 21:03:32 +0100
>
> On Fri, Mar 26, 2021 at 6:28 PM Mark Kettenis wrote:
>
> > I haven't figured out how the bypass stuff really works. Corellium
> > added support for it in their codebase when they added support
> From: Arnd Bergmann
> Date: Fri, 26 Mar 2021 17:38:24 +0100
>
> On Fri, Mar 26, 2021 at 5:10 PM Sven Peter wrote:
> > On Fri, Mar 26, 2021, at 16:59, Mark Kettenis wrote:
> > > Some of the DARTs provide a bypass facility. That code make using the
> > > s
> From: Arnd Bergmann
> Date: Thu, 25 Mar 2021 22:41:09 +0100
>
> On Thu, Mar 25, 2021 at 8:53 AM Sven Peter wrote:
> > On Tue, Mar 23, 2021, at 21:53, Rob Herring wrote:
> >
> > I'm probably just confused or maybe the documentation is outdated but I
> > don't
> > see how I could specify "this
> Date: Tue, 23 Mar 2021 14:53:46 -0600
> From: Rob Herring
>
> On Sun, Mar 21, 2021 at 05:00:50PM +0100, Mark Kettenis wrote:
> > > Date: Sat, 20 Mar 2021 15:19:33 +
> > > From: Sven Peter
> > >
> > > Hi,
> > >
> > > Af
> Date: Mon, 22 Mar 2021 23:17:31 +0100
> From: "Sven Peter"
>
> Hi Mark,
>
> On Sun, Mar 21, 2021, at 19:35, Mark Kettenis wrote:
> >
> > Guess we do need to understand a little bit better how the USB DART
> > actually works. My hypothesis (base
> Date: Sun, 21 Mar 2021 18:22:15 +0100
> From: "Sven Peter"
>
> Hi Mark,
>
> On 21. Mar 2021, at 17:00, Mark Kettenis
> wrote:
>
> I don't think the first option is going to work for PCIe. PCIe
> devices will have to use "iommu-map&qu
> Date: Sat, 20 Mar 2021 15:19:33 +
> From: Sven Peter
>
> Hi,
>
> After Hector's initial work [1] to bring up Linux on Apple's M1 it's time to
> bring up more devices. Most peripherals connected to the SoC are behind a
> iommu
> which Apple calls "Device Address Resolution Table", or DART
> From: Hector Martin
> Date: Fri, 5 Mar 2021 20:14:10 +0900
>
> On 05/03/2021 20.03, Krzysztof Kozlowski wrote:
> >> + memory@8 {
> >> + device_type = "memory";
> >> + reg = <0x8 0 0x2 0>; /* To be filled by loader */
> >
> > Shouldn't this be 0x8 with ~0x8000
> From: Arnd Bergmann
> Date: Tue, 16 Feb 2021 10:41:11 +0100
>
> On Mon, Feb 15, 2021 at 1:17 PM Hector Martin wrote:
> > +
> > + The 2nd cell contains the interrupt number.
> > +- HW IRQs: interrupt number
> > +- FIQs:
> > + - 0: physical HV timer
> > + -
> From: Hector Martin
> Date: Wed, 10 Feb 2021 21:24:15 +0900
Hi Hector,
Since device tree bindings are widely used outside the Linux tree,
here are some thoughts from a U-Boot and OpenBSD perspective.
> Hi Will, I'm pulling you in at Marc's suggestion. Do you have an opinion
> on what the bet
> From: Arnd Bergmann
> Date: Tue, 9 Feb 2021 10:15:31 +0100
>
> On Tue, Feb 9, 2021 at 1:25 AM Hector Martin wrote:
> > On 09/02/2021 08.20, Mark Kettenis wrote:
> > I probed writing to i<<28 for i = [0..255], using nGnRE. This reveals
> > that nGnRE writes
> From: Arnd Bergmann
> Date: Mon, 8 Feb 2021 23:57:20 +0100
>
> On Thu, Feb 4, 2021 at 9:39 PM Hector Martin wrote:
>
> > (3) Do it at a lower level, in ioremap() itself. This requires that
> > ioremap() somehow discriminates based on address range to pick what
> > kind of mapping to m
> From: Nicolas Saenz Julienne
> Date: Thu, 30 Apr 2020 15:04:32 +0200
>
> On the Raspberry Pi 4, after a PCI reset, VL805's (a xHCI chip) firmware
> may either be loaded directly from an EEPROM or, if not present, by the
> SoC's VideoCore (the SoC's co-processor). Introduce the function that
> i
On Thu, Jul 17, 2014, Theodore Ts'o wrote:
>
> The getrandom(2) system call is a superset of getentropy(2). When we
> add the support for this into glibc, it won't be terribly difficult
> nor annoying to drop the following in alongside the standard support
> needed for any new system call:
>
> i
> Date: Tue, 29 Apr 2014 22:10:15 -0700
> From: "H. Peter Anvin"
>
> On 04/29/2014 10:08 PM, Andrew Pinski wrote:
> >
> > restoring the values is hard since even the ptrace interface does not
> > allow for that.
> >
>
> So that begs the ultimate question, which is: given the fact that there
>
The behaviour of CLONE_PTRACE in Linux 2.4.x is different from the
behaviour in 2.2.x. Linus is describing the 2.4.x. behaviour, where
the program that's doing the tracing will get the events instead of
the "real" parent. I believe the 2.2.x behaviour was pretty much
useless, and IIRC that was t
Peter Berger <[EMAIL PROTECTED]> writes:
> > > The zombie problem is a kernel bug. AFAIK there is no kernel that
> > > doesn't have this bug. Unfortunately getting the bugfix in isn't very
> > > easy. I'll try poking Linus again when I can find the time.
>
> *sob*
>
> Alan Cox says it is a g
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: 2000-09-13 6:35:16
[EMAIL PROTECTED] writes:
> I didn't realize things had changed that broke the old threading model.
> Did Linus do more than add support for the new thread groups? I didn't
> think any that had changed that woul
Date: Sat, 2 Sep 2000 11:56:05 -0700 (PDT)
From: Linus Torvalds <[EMAIL PROTECTED]>
> * SIGCONT isn't handled correctly:
>
> "[W]hen SIGCONT is generated for a process all pending stop signals
>for that process shall be discarded."
A lot of these issues should be fixe
DT)
From: Linus Torvalds <[EMAIL PROTECTED]>
To: Mark Kettenis <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: thread group comments
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 2 Sep 2000, Mark Kettenis wrote:
>&
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: 2000-09-01 22:06:52
On 1 Sep 2000, Ulrich Drepper wrote:
> 2nd Problem: Fatal signal handling
>
> kernel/signal.c contains:
>
> * Send a thread-group-wide signal.
> *
> * Rule: SIGSTOP and SIGKILL get delivered to _
23 matches
Mail list logo
