In ring_work(), the first while loop is used to collect all completed
frames from the ring buffer. In each iteration of this loop, the flag of
the frame, i.e., 'ring->descriptors[ring->tail].flags' is firstly check to
see whether the frame is completed. If yes, the descriptor of the frame,
In ring_work(), the first while loop is used to collect all completed
frames from the ring buffer. In each iteration of this loop, the flag of
the frame, i.e., 'ring->descriptors[ring->tail].flags' is firstly check to
see whether the frame is completed. If yes, the descriptor of the frame,
We are one image studio who is able to process 300+ photos a day.
If you need any image editing, please let us know. We can do it for you
such as:
Image cut out for photos and clipping path, masking for your photos,
They are mostly used for ecommerce photos, jewelry photos retouching,
beauty
We are one image studio who is able to process 300+ photos a day.
If you need any image editing, please let us know. We can do it for you
such as:
Image cut out for photos and clipping path, masking for your photos,
They are mostly used for ecommerce photos, jewelry photos retouching,
beauty
> -Original Message-
> From: Alan Cox
>
> > +to the circumstances. The Code of Conduct Committee is obligated to
> > +maintain confidentiality with regard to the reporter of an incident.
> > +Further details of specific enforcement policies may be posted
> > +separately.
>
>
> -Original Message-
> From: Alan Cox
>
> > +to the circumstances. The Code of Conduct Committee is obligated to
> > +maintain confidentiality with regard to the reporter of an incident.
> > +Further details of specific enforcement policies may be posted
> > +separately.
>
>
On Sat, Oct 20, 2018 at 04:42:07PM +0200, Miguel Ojeda wrote:
> +On Wed, Oct 17, 2018 at 8:25 AM Dan Carpenter
> wrote:
> >
> > It's not common at all. It should be wrapped in a macro and put into
> > compiler.h.
> >
> > But I hope it does become adopted. It's better than randomly grepping
> >
On Sat, Oct 20, 2018 at 04:42:07PM +0200, Miguel Ojeda wrote:
> +On Wed, Oct 17, 2018 at 8:25 AM Dan Carpenter
> wrote:
> >
> > It's not common at all. It should be wrapped in a macro and put into
> > compiler.h.
> >
> > But I hope it does become adopted. It's better than randomly grepping
> >
On Sat, Oct 20, 2018 at 2:47 PM Trond Myklebust wrote:
>
> On Sat, 2018-10-20 at 19:28 +0100, Alan Cox wrote:
> > > +to the circumstances. The Code of Conduct Committee is obligated
> > > to
> > > +maintain confidentiality with regard to the reporter of an
> > > incident.
> > > +Further details
On Sat, Oct 20, 2018 at 2:47 PM Trond Myklebust wrote:
>
> On Sat, 2018-10-20 at 19:28 +0100, Alan Cox wrote:
> > > +to the circumstances. The Code of Conduct Committee is obligated
> > > to
> > > +maintain confidentiality with regard to the reporter of an
> > > incident.
> > > +Further details
Hi Greg,
On Sat, Oct 20, 2018 at 3:53 PM Greg Kroah-Hartman
wrote:
> There was a blank reference for how to find the Code of Conduct
> Committee. Fix that up by pointing it to the correct kernel.org website
> page location.
>
> Acked-by: Chris Mason
> Acked-by: Olof Johansson
> Acked-by:
Hi Greg,
On Sat, Oct 20, 2018 at 3:53 PM Greg Kroah-Hartman
wrote:
> There was a blank reference for how to find the Code of Conduct
> Committee. Fix that up by pointing it to the correct kernel.org website
> page location.
>
> Acked-by: Chris Mason
> Acked-by: Olof Johansson
> Acked-by:
On Sat, Oct 20, 2018 at 12:25 AM Wenwen Wang wrote:
>
> On Thu, Oct 18, 2018 at 4:13 AM Mika Westerberg
> wrote:
> >
> > Hi Wenwen,
> >
> > On Wed, Oct 17, 2018 at 09:00:29AM -0500, Wenwen Wang wrote:
> > > In tb_cfg_copy(), the header of the received control package, which is in
> > > the
On Sat, Oct 20, 2018 at 12:25 AM Wenwen Wang wrote:
>
> On Thu, Oct 18, 2018 at 4:13 AM Mika Westerberg
> wrote:
> >
> > Hi Wenwen,
> >
> > On Wed, Oct 17, 2018 at 09:00:29AM -0500, Wenwen Wang wrote:
> > > In tb_cfg_copy(), the header of the received control package, which is in
> > > the
On Sat, 2018-10-20 at 19:28 +0100, Alan Cox wrote:
> > +to the circumstances. The Code of Conduct Committee is obligated
> > to
> > +maintain confidentiality with regard to the reporter of an
> > incident.
> > +Further details of specific enforcement policies may be posted
> > +separately.
>
>
On Sat, 2018-10-20 at 19:28 +0100, Alan Cox wrote:
> > +to the circumstances. The Code of Conduct Committee is obligated
> > to
> > +maintain confidentiality with regard to the reporter of an
> > incident.
> > +Further details of specific enforcement policies may be posted
> > +separately.
>
>
In icm_copy(), the packet id 'hdr->packet_id' is firstly compared against
'req->npackets'. If it is less than 'req->npackets', the received packet.
i.e., 'pkg->buffer', is then copied to 'req->response + offset' through
memcpy(). It is worth noting that 'offset' is also calculated based on
In icm_copy(), the packet id 'hdr->packet_id' is firstly compared against
'req->npackets'. If it is less than 'req->npackets', the received packet.
i.e., 'pkg->buffer', is then copied to 'req->response + offset' through
memcpy(). It is worth noting that 'offset' is also calculated based on
> +to the circumstances. The Code of Conduct Committee is obligated to
> +maintain confidentiality with regard to the reporter of an incident.
> +Further details of specific enforcement policies may be posted
> +separately.
Unfortunately by ignoring the other suggestions on this you've left
> +to the circumstances. The Code of Conduct Committee is obligated to
> +maintain confidentiality with regard to the reporter of an incident.
> +Further details of specific enforcement policies may be posted
> +separately.
Unfortunately by ignoring the other suggestions on this you've left
In tb_ctl_rx_callback(), the checksum of the received control packet is
calculated on 'pkg->buffer' through tb_crc() and saved to 'crc32', Then,
'crc32' is compared with the received checksum to confirm the integrity of
the received packet. If the checksum does not match, the packet will be
In tb_ctl_rx_callback(), the checksum of the received control packet is
calculated on 'pkg->buffer' through tb_crc() and saved to 'crc32', Then,
'crc32' is compared with the received checksum to confirm the integrity of
the received packet. If the checksum does not match, the packet will be
I wrote you about late Engr M.M. and the deposit he made at the bank
here.I sent you an email earlier and been expecting to hear from you.
Please try and get back to me.
Steven
I wrote you about late Engr M.M. and the deposit he made at the bank
here.I sent you an email earlier and been expecting to hear from you.
Please try and get back to me.
Steven
On Fri, 2018-10-19 at 22:48 +0200, Miklos Szeredi wrote:
> On Fri, Oct 19, 2018 at 8:14 PM, Trond Myklebust
> wrote:
> > On Fri, 2018-10-19 at 19:46 +0200, Miklos Szeredi wrote:
> > > How is it then that only STATX_ATIME is cleared and not the other
> > > fields?
> >
> > It isn't just the atime.
On Fri, 2018-10-19 at 22:48 +0200, Miklos Szeredi wrote:
> On Fri, Oct 19, 2018 at 8:14 PM, Trond Myklebust
> wrote:
> > On Fri, 2018-10-19 at 19:46 +0200, Miklos Szeredi wrote:
> > > How is it then that only STATX_ATIME is cleared and not the other
> > > fields?
> >
> > It isn't just the atime.
Dropping stable.
On Sat, Oct 20, 2018 at 07:41:58AM -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> The Intel microcode revision space is unsigned. Inside Intel there are special
> microcodes that have the highest bit set, and they are considered to have
> a higher revision than any microcodes
Dropping stable.
On Sat, Oct 20, 2018 at 07:41:58AM -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> The Intel microcode revision space is unsigned. Inside Intel there are special
> microcodes that have the highest bit set, and they are considered to have
> a higher revision than any microcodes
On Sat, Oct 20, 2018 at 08:37:28AM -0700, Randy Dunlap wrote:
> [add linux-mm mailing list + people]
>
>
> On 10/20/18 4:41 AM, Spock wrote:
> > Hello,
> >
> > I have a workload, which creates lots of cache pages. Before 4.18.15,
> > the behavior was very stable: pagecache is constantly growing
On Sat, Oct 20, 2018 at 08:37:28AM -0700, Randy Dunlap wrote:
> [add linux-mm mailing list + people]
>
>
> On 10/20/18 4:41 AM, Spock wrote:
> > Hello,
> >
> > I have a workload, which creates lots of cache pages. Before 4.18.15,
> > the behavior was very stable: pagecache is constantly growing
Hi Rick,
On 19 October 2018 at 22:47, Rick Edgecombe wrote:
> If BPF JIT is on, there is no effective limit to prevent filling the entire
> module space with JITed e/BPF filters.
Why do BPF filters use the module space, and does this reason apply to
all architectures?
On arm64, we already
Hi Rick,
On 19 October 2018 at 22:47, Rick Edgecombe wrote:
> If BPF JIT is on, there is no effective limit to prevent filling the entire
> module space with JITed e/BPF filters.
Why do BPF filters use the module space, and does this reason apply to
all architectures?
On arm64, we already
Hello,
syzbot found the following crash on:
HEAD commit:91b15613ce7f Merge git://git.kernel.org/pub/scm/linux/kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1011410940
kernel config: https://syzkaller.appspot.com/x/.config?x=b3f55cb3dfcc6c33
Hello,
syzbot found the following crash on:
HEAD commit:8c60c36d0b8c Add linux-next specific files for 20181019
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12d808b540
kernel config: https://syzkaller.appspot.com/x/.config?x=8b6d7c4c81535e89
Hello,
syzbot found the following crash on:
HEAD commit:8c60c36d0b8c Add linux-next specific files for 20181019
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12d808b540
kernel config: https://syzkaller.appspot.com/x/.config?x=8b6d7c4c81535e89
Hello,
syzbot found the following crash on:
HEAD commit:91b15613ce7f Merge git://git.kernel.org/pub/scm/linux/kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1011410940
kernel config: https://syzkaller.appspot.com/x/.config?x=b3f55cb3dfcc6c33
On 18-10-18, 17:29, Baolin Wang wrote:
> Hi Vinod,
>
> On 29 September 2018 at 13:48, Baolin Wang wrote:
> > This patchset removes the direction usage from struct dma_slave_config,
> > and add one new field to save the direction. It also fixes some issues
> > for link-list transfer. Moreover
On 18-10-18, 17:29, Baolin Wang wrote:
> Hi Vinod,
>
> On 29 September 2018 at 13:48, Baolin Wang wrote:
> > This patchset removes the direction usage from struct dma_slave_config,
> > and add one new field to save the direction. It also fixes some issues
> > for link-list transfer. Moreover
On Sat, Oct 20, 2018 at 12:02:37PM +0530, Sai Prakash Ranjan wrote:
> On 10/20/2018 10:55 AM, Joel Fernandes wrote:
> > On Sun, Sep 09, 2018 at 01:57:01AM +0530, Sai Prakash Ranjan wrote:
> > > Hi,
> > >
> > > This patch series adds Event tracing support to pstore and is continuation
> > > to the
On Sat, Oct 20, 2018 at 12:02:37PM +0530, Sai Prakash Ranjan wrote:
> On 10/20/2018 10:55 AM, Joel Fernandes wrote:
> > On Sun, Sep 09, 2018 at 01:57:01AM +0530, Sai Prakash Ranjan wrote:
> > > Hi,
> > >
> > > This patch series adds Event tracing support to pstore and is continuation
> > > to the
On 19-10-18, 12:41, sudheer.v wrote:
> On Fri, Oct 19, 2018 at 10:32:24AM +1100, Benjamin Herrenschmidt wrote:
> > On Thu, 2018-10-18 at 15:25 +0530, Vinod wrote:
> > >
> > > > It's not a dmaengine driver. It's a serial UART driver that happens to
> > > > use a dedicated DMA engine.
> > >
> > >
On 19-10-18, 12:41, sudheer.v wrote:
> On Fri, Oct 19, 2018 at 10:32:24AM +1100, Benjamin Herrenschmidt wrote:
> > On Thu, 2018-10-18 at 15:25 +0530, Vinod wrote:
> > >
> > > > It's not a dmaengine driver. It's a serial UART driver that happens to
> > > > use a dedicated DMA engine.
> > >
> > >
syzbot has found a reproducer for the following crash on:
HEAD commit:270b77a0f30e Merge tag 'drm-fixes-2018-10-20-1' of git://a..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=146f4ad940
kernel config:
syzbot has found a reproducer for the following crash on:
HEAD commit:270b77a0f30e Merge tag 'drm-fixes-2018-10-20-1' of git://a..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=146f4ad940
kernel config:
Hello!
David Goldblatt (CCed) came up with an interesting pair of C++ litmus
tests involving POSIX signals that have Linux-kernel counterparts
involving interrupts. These litmus tests can (in paranoid theory, anyway)
produce counter-intuitive results on architectures that use explicit
fences to
Hello!
David Goldblatt (CCed) came up with an interesting pair of C++ litmus
tests involving POSIX signals that have Linux-kernel counterparts
involving interrupts. These litmus tests can (in paranoid theory, anyway)
produce counter-intuitive results on architectures that use explicit
fences to
[add linux-mm mailing list + people]
On 10/20/18 4:41 AM, Spock wrote:
> Hello,
>
> I have a workload, which creates lots of cache pages. Before 4.18.15,
> the behavior was very stable: pagecache is constantly growing until it
> consumes all the free memory, and then kswapd is balancing it
[add linux-mm mailing list + people]
On 10/20/18 4:41 AM, Spock wrote:
> Hello,
>
> I have a workload, which creates lots of cache pages. Before 4.18.15,
> the behavior was very stable: pagecache is constantly growing until it
> consumes all the free memory, and then kswapd is balancing it
+On Wed, Oct 17, 2018 at 8:25 AM Dan Carpenter wrote:
>
> It's not common at all. It should be wrapped in a macro and put into
> compiler.h.
>
> But I hope it does become adopted. It's better than randomly grepping
> for non-standard comments.
Using an attribute is indeed better whenever
From: Andi Kleen
The Intel microcode revision space is unsigned. Inside Intel there are special
microcodes that have the highest bit set, and they are considered to have
a higher revision than any microcodes that don't have this bit set.
The function comparing the microcode revision in the
+On Wed, Oct 17, 2018 at 8:25 AM Dan Carpenter wrote:
>
> It's not common at all. It should be wrapped in a macro and put into
> compiler.h.
>
> But I hope it does become adopted. It's better than randomly grepping
> for non-standard comments.
Using an attribute is indeed better whenever
From: Andi Kleen
The Intel microcode revision space is unsigned. Inside Intel there are special
microcodes that have the highest bit set, and they are considered to have
a higher revision than any microcodes that don't have this bit set.
The function comparing the microcode revision in the
On Sat, Oct 20, 2018 at 10:19:37AM +0200, Thomas Gleixner wrote:
> On Fri, 19 Oct 2018, Andi Kleen wrote:
>
> > > > + u32 min_ucode;
> > > > +};
> > > > +
> > > > +const struct x86_ucode_id *x86_match_ucode(const struct x86_ucode_id
> > > > *match)
> > >
> > > What's the point of
On Sat, Oct 20, 2018 at 10:19:37AM +0200, Thomas Gleixner wrote:
> On Fri, 19 Oct 2018, Andi Kleen wrote:
>
> > > > + u32 min_ucode;
> > > > +};
> > > > +
> > > > +const struct x86_ucode_id *x86_match_ucode(const struct x86_ucode_id
> > > > *match)
> > >
> > > What's the point of
On Fri, Oct 19, 2018 at 5:06 PM Paul Walmsley wrote:
>
>
> On 10/19/18 1:45 PM, Rob Herring wrote:
> > On Fri, Oct 19, 2018 at 1:48 PM Paul Walmsley
> > wrote:
> >> Add DT binding documentation for the Linux driver for the SiFive
> >> asynchronous serial IP block. Nothing too exotic.
> >>
> >>
On Fri, Oct 19, 2018 at 5:06 PM Paul Walmsley wrote:
>
>
> On 10/19/18 1:45 PM, Rob Herring wrote:
> > On Fri, Oct 19, 2018 at 1:48 PM Paul Walmsley
> > wrote:
> >> Add DT binding documentation for the Linux driver for the SiFive
> >> asynchronous serial IP block. Nothing too exotic.
> >>
> >>
Hi Paul.
> modpost: skip section mismatch warnings on ELF local symbols by default
>
> modpost, by default, reports section mismatch warnings on ELF local
> symbols. This caused false positive warnings to be reported for a
> local symbol name that would otherwise be elided by matching against a
Hi Paul.
> modpost: skip section mismatch warnings on ELF local symbols by default
>
> modpost, by default, reports section mismatch warnings on ELF local
> symbols. This caused false positive warnings to be reported for a
> local symbol name that would otherwise be elided by matching against a
On Sat, Oct 20, 2018 at 03:42:05PM +0200, Thomas Gleixner wrote:
> Andi,
>
> On Fri, 19 Oct 2018, Andi Kleen wrote:
> > Change the comparison to unsigned. With that the loading works
> > as expected.
> >
>
> I assume that wants a fixes tag and needs to be backported to stable,
> right?
I think
On Sat, Oct 20, 2018 at 03:42:05PM +0200, Thomas Gleixner wrote:
> Andi,
>
> On Fri, 19 Oct 2018, Andi Kleen wrote:
> > Change the comparison to unsigned. With that the loading works
> > as expected.
> >
>
> I assume that wants a fixes tag and needs to be backported to stable,
> right?
I think
On 19 October 2018 at 23:21, Miroslav Benes wrote:
>
>> >> Ad relocations. I checked that everything in struct mod_arch_specific
>> >> stays after the module is load. Both core and init get SHF_ALLOC set
>> >> (mod->arch.core.plt->sh_flags in module_frob_arch_sections(). It is
>> >> important
On 19 October 2018 at 23:21, Miroslav Benes wrote:
>
>> >> Ad relocations. I checked that everything in struct mod_arch_specific
>> >> stays after the module is load. Both core and init get SHF_ALLOC set
>> >> (mod->arch.core.plt->sh_flags in module_frob_arch_sections(). It is
>> >> important
Create a link between the Code of Conduct and the Code of Conduct
Interpretation so that people can see that they are related.
Acked-by: Chris Mason
Acked-by: Olof Johansson
Acked-by: Theodore Ts'o
Acked-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
The contact point for the kernel's Code of Conduct should now be the
Code of Conduct Committee, not the full TAB. Change the email address
in the file to properly reflect this.
Acked-by: Chris Mason
Acked-by: Olof Johansson
Acked-by: Theodore Ts'o
Acked-by: Thomas Gleixner
Signed-off-by:
Create a link between the Code of Conduct and the Code of Conduct
Interpretation so that people can see that they are related.
Acked-by: Chris Mason
Acked-by: Olof Johansson
Acked-by: Theodore Ts'o
Acked-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
The contact point for the kernel's Code of Conduct should now be the
Code of Conduct Committee, not the full TAB. Change the email address
in the file to properly reflect this.
Acked-by: Chris Mason
Acked-by: Olof Johansson
Acked-by: Theodore Ts'o
Acked-by: Thomas Gleixner
Signed-off-by:
As I introduced these files, I'm willing to be the maintainer of them as
well.
Acked-by: Chris Mason
Acked-by: Olof Johansson
Acked-by: Steven Rostedt (VMware)
Acked-by: Theodore Ts'o
Acked-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
MAINTAINERS | 6 ++
1 file changed, 6
The Contributor Covenant Code of Conduct is a general document meant to
provide a set of rules for almost any open source community. Every
open-source community is unique and the Linux kernel is no exception.
Because of this, this document describes how we in the Linux kernel
community will
We use the term "TAB" before defining it later in the document. Fix
that up by defining it at the first location.
Reported-by: Kuninori Morimoto
Acked-by: Chris Mason
Acked-by: Olof Johansson
Acked-by: Theodore Ts'o
Acked-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
There was a blank reference for how to find the Code of Conduct
Committee. Fix that up by pointing it to the correct kernel.org website
page location.
Acked-by: Chris Mason
Acked-by: Olof Johansson
Acked-by: Theodore Ts'o
Acked-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
As I introduced these files, I'm willing to be the maintainer of them as
well.
Acked-by: Chris Mason
Acked-by: Olof Johansson
Acked-by: Steven Rostedt (VMware)
Acked-by: Theodore Ts'o
Acked-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
MAINTAINERS | 6 ++
1 file changed, 6
The Contributor Covenant Code of Conduct is a general document meant to
provide a set of rules for almost any open source community. Every
open-source community is unique and the Linux kernel is no exception.
Because of this, this document describes how we in the Linux kernel
community will
We use the term "TAB" before defining it later in the document. Fix
that up by defining it at the first location.
Reported-by: Kuninori Morimoto
Acked-by: Chris Mason
Acked-by: Olof Johansson
Acked-by: Theodore Ts'o
Acked-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
There was a blank reference for how to find the Code of Conduct
Committee. Fix that up by pointing it to the correct kernel.org website
page location.
Acked-by: Chris Mason
Acked-by: Olof Johansson
Acked-by: Theodore Ts'o
Acked-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
From: Chris Mason
As it was originally worded, this paragraph requires maintainers to
enforce the code of conduct, or face potential repercussions. It sends
the wrong message, when really we just want maintainers to be part of
the solution and not violate the code of conduct themselves.
Hi all,
As everyone knows by now, we added a new Code of Conduct to the kernel
tree a few weeks ago.
When we did this, it raised a number of questions as to how this would
affect the kernel community. To help address these issues, I, and a few
other kernel developers including the TAB, have
From: Chris Mason
As it was originally worded, this paragraph requires maintainers to
enforce the code of conduct, or face potential repercussions. It sends
the wrong message, when really we just want maintainers to be part of
the solution and not violate the code of conduct themselves.
Hi all,
As everyone knows by now, we added a new Code of Conduct to the kernel
tree a few weeks ago.
When we did this, it raised a number of questions as to how this would
affect the kernel community. To help address these issues, I, and a few
other kernel developers including the TAB, have
Add DT binding documentation for the Linux driver for the SiFive
PRCI clock & reset control IP block, as found on the SiFive
FU540 chip.
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: Rob Herring
Cc: Mark Rutland
Cc: Palmer Dabbelt
Cc: Megan Wachs
Cc: linux-...@vger.kernel.org
Cc:
Add driver code for the SiFive FU540 PRCI IP block. This IP block
handles reset and clock control for the SiFive FU540 device and
implements SoC-level clock tree controls and dividers.
Based on code written by Wesley Terpstra :
Add a driver for the SiFive FU540 PRCI IP block, which handles clock and
some device reset control for the SiFive FU540 chip. Also add a driver-
independent library for the Analog Bits Wide-Range PLL (WRPLL), used by
the PRCI driver to monitor and control the WRPLL instances on the FU540
chip.
Add common library code for the Analog Bits Wide-Range PLL (WRPLL) as
implemented in TSMC CLN28HPC.
There is no bus interface or register target associated with this PLL.
This library is intended to be used by drivers for IP blocks that
expose registers connected to the PLL configuration and
Add DT binding documentation for the Linux driver for the SiFive
PRCI clock & reset control IP block, as found on the SiFive
FU540 chip.
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: Rob Herring
Cc: Mark Rutland
Cc: Palmer Dabbelt
Cc: Megan Wachs
Cc: linux-...@vger.kernel.org
Cc:
Add driver code for the SiFive FU540 PRCI IP block. This IP block
handles reset and clock control for the SiFive FU540 device and
implements SoC-level clock tree controls and dividers.
Based on code written by Wesley Terpstra :
Add a driver for the SiFive FU540 PRCI IP block, which handles clock and
some device reset control for the SiFive FU540 chip. Also add a driver-
independent library for the Analog Bits Wide-Range PLL (WRPLL), used by
the PRCI driver to monitor and control the WRPLL instances on the FU540
chip.
Add common library code for the Analog Bits Wide-Range PLL (WRPLL) as
implemented in TSMC CLN28HPC.
There is no bus interface or register target associated with this PLL.
This library is intended to be used by drivers for IP blocks that
expose registers connected to the PLL configuration and
Andi,
On Fri, 19 Oct 2018, Andi Kleen wrote:
> Change the comparison to unsigned. With that the loading works
> as expected.
>
I assume that wants a fixes tag and needs to be backported to stable,
right?
Thanks,
tglx
Andi,
On Fri, 19 Oct 2018, Andi Kleen wrote:
> Change the comparison to unsigned. With that the loading works
> as expected.
>
I assume that wants a fixes tag and needs to be backported to stable,
right?
Thanks,
tglx
Add common library code for the Analog Bits Wide-Range PLL (WRPLL) as
implemented in TSMC CLN28HPC.
There is no bus interface or register target associated with this PLL.
This library is intended to be used by drivers for IP blocks that
expose registers connected to the PLL configuration and
Add common library code for the Analog Bits Wide-Range PLL (WRPLL) as
implemented in TSMC CLN28HPC.
There is no bus interface or register target associated with this PLL.
This library is intended to be used by drivers for IP blocks that
expose registers connected to the PLL configuration and
Add DT binding documentation for the Linux driver for the SiFive
PRCI clock & reset control IP block, as found on the SiFive
FU540 chip.
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: Rob Herring
Cc: Mark Rutland
Cc: Palmer Dabbelt
Cc: Megan Wachs
Add driver code for the SiFive FU540 PRCI IP block. This IP block
handles reset and clock control for the SiFive FU540 device and
implements SoC-level clock tree controls and dividers.
Based on code written by Wesley Terpstra :
Add a driver for the SiFive FU540 PRCI IP block, which handles clock and
some device reset control for the SiFive FU540 chip. Also add a driver-
independent library for the Analog Bits Wide-Range PLL (WRPLL), used by
the PRCI driver to monitor and control the WRPLL instances on the FU540
chip.
Add DT binding documentation for the Linux driver for the SiFive
PRCI clock & reset control IP block, as found on the SiFive
FU540 chip.
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: Rob Herring
Cc: Mark Rutland
Cc: Palmer Dabbelt
Cc: Megan Wachs
Add driver code for the SiFive FU540 PRCI IP block. This IP block
handles reset and clock control for the SiFive FU540 device and
implements SoC-level clock tree controls and dividers.
Based on code written by Wesley Terpstra :
Add a driver for the SiFive FU540 PRCI IP block, which handles clock and
some device reset control for the SiFive FU540 chip. Also add a driver-
independent library for the Analog Bits Wide-Range PLL (WRPLL), used by
the PRCI driver to monitor and control the WRPLL instances on the FU540
chip.
On Sat, Oct 20, 2018 at 10:45:16AM +0200, Ingo Molnar wrote:
> Greg,
>
> Please pull the latest sched-urgent-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> sched-urgent-for-linus
Now merged, thanks.
greg k-h
On Sat, Oct 20, 2018 at 10:10:39AM +0200, Ingo Molnar wrote:
> Greg,
>
> Please pull the latest perf-urgent-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> perf-urgent-for-linus
Now merged, thanks.
greg k-h
On Sat, Oct 20, 2018 at 10:54:25AM +0200, Ingo Molnar wrote:
> Greg,
>
> Please pull the latest x86-urgent-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> x86-urgent-for-linus
Now merged, thanks.
greg k-h
On Sat, Oct 20, 2018 at 10:45:16AM +0200, Ingo Molnar wrote:
> Greg,
>
> Please pull the latest sched-urgent-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> sched-urgent-for-linus
Now merged, thanks.
greg k-h
101 - 200 of 294 matches
Mail list logo
