On Wed, Nov 07, 2018 at 11:08:56AM -0600, Josh Poimboeuf wrote:
> On Wed, Nov 07, 2018 at 03:05:59PM +0100, Artem Savkov wrote:
> > The way it is currently done it is possible for read_symbols() to find the
> > same symbol as parent for ".cold" functions.
>
> I seem to remember having this
On Wed, Nov 07, 2018 at 11:08:56AM -0600, Josh Poimboeuf wrote:
> On Wed, Nov 07, 2018 at 03:05:59PM +0100, Artem Savkov wrote:
> > The way it is currently done it is possible for read_symbols() to find the
> > same symbol as parent for ".cold" functions.
>
> I seem to remember having this
On 02/11/2018 12:19, Peter Zijlstra wrote:
On Fri, Nov 02, 2018 at 12:08:53PM +, John Garry wrote:
@@ -1337,7 +1353,7 @@ void sched_init_numa(void)
int level = 0;
int i, j, k;
- sched_domains_numa_distance = kzalloc(sizeof(int) * nr_node_ids,
GFP_KERNEL);
+
On 02/11/2018 12:19, Peter Zijlstra wrote:
On Fri, Nov 02, 2018 at 12:08:53PM +, John Garry wrote:
@@ -1337,7 +1353,7 @@ void sched_init_numa(void)
int level = 0;
int i, j, k;
- sched_domains_numa_distance = kzalloc(sizeof(int) * nr_node_ids,
GFP_KERNEL);
+
From: tip tree robot Sent: Tuesday, November 6, 2018 2:28 PM
>
> Committer: Thomas Gleixner
> CommitDate: Tue, 6 Nov 2018 23:20:13 +0100
>
> 2) Managed interrupts:
>
> Managed interrupts guarantee vector reservation when the MSI/MSI-X
> functionality of a device is enabled, which is
From: tip tree robot Sent: Tuesday, November 6, 2018 2:28 PM
>
> Committer: Thomas Gleixner
> CommitDate: Tue, 6 Nov 2018 23:20:13 +0100
>
> 2) Managed interrupts:
>
> Managed interrupts guarantee vector reservation when the MSI/MSI-X
> functionality of a device is enabled, which is
On Wed, 2018-11-07 at 17:58 +, David Woodhouse wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> > On Wed, Nov 07, 2018 at 04:12:14PM -, David
On Wed, 2018-11-07 at 17:58 +, David Woodhouse wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> > On Wed, Nov 07, 2018 at 04:12:14PM -, David
The 1-socket machine is different to the one used in v1 so some of the
results are changed on that basis. The baseline has changed to 4.20-rc1 so
the __GFP_THISNODE removal for THP is in effect which alters the behaviour
on 2-socket in particular. The biggest changes are in the fourth patch,
both
This is a preparation patch only, no functional change.
Signed-off-by: Mel Gorman
---
include/linux/mmzone.h | 9 +
mm/compaction.c| 2 +-
mm/page_alloc.c| 12 ++--
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/include/linux/mmzone.h
Despite the earlier patches, external fragmentation events are still
inevitable as not all callers can stall or are appropriate to stall. In the
event the result is a mixed pageblock, it is desirable to move all movable
pages from that block so that unmovable/unreclaimable allocations do not
An external fragmentation event was previously described as
When the page allocator fragments memory, it records the event using
the mm_page_alloc_extfrag event. If the fallback_order is smaller
than a pageblock order (order-9 on 64-bit x86) then it's considered
an event that will
The page allocator zone lists are iterated based on the watermarks
of each zone which does not take anti-fragmentation into account. On
x86, node 0 may have multiple zones while other nodes have one zone. A
consequence is that tasks running on node 0 may fragment ZONE_NORMAL even
though ZONE_DMA32
An event that potentially causes external fragmentation problems has
already been described but there are degrees of severity. A "serious"
event is defined as one that steals a contiguous range of pages of an order
lower than fragment_stall_order (PAGE_ALLOC_COSTLY_ORDER by default). If a
movable
The 1-socket machine is different to the one used in v1 so some of the
results are changed on that basis. The baseline has changed to 4.20-rc1 so
the __GFP_THISNODE removal for THP is in effect which alters the behaviour
on 2-socket in particular. The biggest changes are in the fourth patch,
both
This is a preparation patch only, no functional change.
Signed-off-by: Mel Gorman
---
include/linux/mmzone.h | 9 +
mm/compaction.c| 2 +-
mm/page_alloc.c| 12 ++--
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/include/linux/mmzone.h
Despite the earlier patches, external fragmentation events are still
inevitable as not all callers can stall or are appropriate to stall. In the
event the result is a mixed pageblock, it is desirable to move all movable
pages from that block so that unmovable/unreclaimable allocations do not
An external fragmentation event was previously described as
When the page allocator fragments memory, it records the event using
the mm_page_alloc_extfrag event. If the fallback_order is smaller
than a pageblock order (order-9 on 64-bit x86) then it's considered
an event that will
The page allocator zone lists are iterated based on the watermarks
of each zone which does not take anti-fragmentation into account. On
x86, node 0 may have multiple zones while other nodes have one zone. A
consequence is that tasks running on node 0 may fragment ZONE_NORMAL even
though ZONE_DMA32
An event that potentially causes external fragmentation problems has
already been described but there are degrees of severity. A "serious"
event is defined as one that steals a contiguous range of pages of an order
lower than fragment_stall_order (PAGE_ALLOC_COSTLY_ORDER by default). If a
movable
Quoting Rob Herring (2018-11-06 12:44:52)
> On Tue, Nov 6, 2018 at 12:36 PM Stephen Boyd wrote:
> >
> > We have a handful of clk drivers that have a collection of slightly
> > variant device support keyed off of the compatible string. In each of
> > these drivers, we demux the variant and then
Quoting Rob Herring (2018-11-06 12:44:52)
> On Tue, Nov 6, 2018 at 12:36 PM Stephen Boyd wrote:
> >
> > We have a handful of clk drivers that have a collection of slightly
> > variant device support keyed off of the compatible string. In each of
> > these drivers, we demux the variant and then
On 11/06/2018 07:18 PM, Tim Chen wrote:
> Thomas,
>
2) Add _TIF_UPDATE_SPEC_CTRL to the SYSCALL_EXIT_WORK_FLAGS and handle it
in the slow work path.
>>> There can be tasks that don't do any syscalls, and it seems like we can
>>> have MSRs getting out of sync?
>> Setting the TIF flag
On 11/06/2018 07:18 PM, Tim Chen wrote:
> Thomas,
>
2) Add _TIF_UPDATE_SPEC_CTRL to the SYSCALL_EXIT_WORK_FLAGS and handle it
in the slow work path.
>>> There can be tasks that don't do any syscalls, and it seems like we can
>>> have MSRs getting out of sync?
>> Setting the TIF flag
On Wed, Nov 7, 2018 at 1:08 AM Palmer Dabbelt wrote:
>
> On Mon, 05 Nov 2018 12:56:15 PST (-0800), Arnd Bergmann wrote:
> > On 11/5/18, David Abdurachmanov wrote:
> >> Marcin Juszkiewicz reported issues while generating syscall table for riscv
> >> using 4.20-rc1. The patch refactors our
On Wed, Nov 7, 2018 at 1:08 AM Palmer Dabbelt wrote:
>
> On Mon, 05 Nov 2018 12:56:15 PST (-0800), Arnd Bergmann wrote:
> > On 11/5/18, David Abdurachmanov wrote:
> >> Marcin Juszkiewicz reported issues while generating syscall table for riscv
> >> using 4.20-rc1. The patch refactors our
On Wed, Nov 7, 2018 at 7:05 PM Nikunj Kela (nkela) wrote:
> I had tried to use configs to start with via the following patch however I
> was advised to have a mount option:
> http://lists.infradead.org/pipermail/linux-mtd/2018-November/085126.html
Just show performance numbers on how your
On Wed, Nov 7, 2018 at 7:05 PM Nikunj Kela (nkela) wrote:
> I had tried to use configs to start with via the following patch however I
> was advised to have a mount option:
> http://lists.infradead.org/pipermail/linux-mtd/2018-November/085126.html
Just show performance numbers on how your
On Wed, Nov 07, 2018 at 10:15:52AM +0100, Miklos Szeredi wrote:
> This makes it possible to use utimensat on an O_PATH file (including
> symlinks).
>
> It supersedes the nonstandard utimensat(fd, NULL, ...) form.
>
> Signed-off-by: Miklos Szeredi
Thanks for fixing this Miklos. It seems to work
On Wed, Nov 07, 2018 at 10:15:52AM +0100, Miklos Szeredi wrote:
> This makes it possible to use utimensat on an O_PATH file (including
> symlinks).
>
> It supersedes the nonstandard utimensat(fd, NULL, ...) form.
>
> Signed-off-by: Miklos Szeredi
Thanks for fixing this Miklos. It seems to work
On 11/7/18, 1:05 AM, "David Woodhouse" wrote:
On Tue, 2018-11-06 at 13:49 -0800, Nikunj Kela wrote:
>> This patch allows the endianness of the JFSS2 filesystem to be
>> specified by mount option 'force_endian=big|little|native'. If
>> endianness is not specified, it defaults to
On 11/7/18, 1:05 AM, "David Woodhouse" wrote:
On Tue, 2018-11-06 at 13:49 -0800, Nikunj Kela wrote:
>> This patch allows the endianness of the JFSS2 filesystem to be
>> specified by mount option 'force_endian=big|little|native'. If
>> endianness is not specified, it defaults to
On Wed, 7 Nov 2018 at 18:02, Quentin Perret wrote:
>
> Hi Vincent,
>
> On Wednesday 07 Nov 2018 at 17:32:32 (+0100), Vincent Guittot wrote:
> > Hi Quentin,
> >
> > On Tue, 16 Oct 2018 at 12:15, Quentin Perret wrote:
> > >
> >
> > > +
> > > +/**
> > > + * em_pd_energy() - Estimates the energy
On Wed, 7 Nov 2018 at 18:02, Quentin Perret wrote:
>
> Hi Vincent,
>
> On Wednesday 07 Nov 2018 at 17:32:32 (+0100), Vincent Guittot wrote:
> > Hi Quentin,
> >
> > On Tue, 16 Oct 2018 at 12:15, Quentin Perret wrote:
> > >
> >
> > > +
> > > +/**
> > > + * em_pd_energy() - Estimates the energy
From: Logan Gunthorpe
Sent: November 6, 2018 at 8:01:31 PM GMT
> To: Nadav Amit , Ingo Molnar
> Cc: LKML , X86 ML , Sam
> Ravnborg , Michal Marek , Thomas
> Gleixner , H. Peter Anvin , Linux Kbuild
> mailing list , Stephen Bates
>
> Subject: Re: [PATCH v9 02/10] Makefile: Prepare for using
From: Logan Gunthorpe
Sent: November 6, 2018 at 8:01:31 PM GMT
> To: Nadav Amit , Ingo Molnar
> Cc: LKML , X86 ML , Sam
> Ravnborg , Michal Marek , Thomas
> Gleixner , H. Peter Anvin , Linux Kbuild
> mailing list , Stephen Bates
>
> Subject: Re: [PATCH v9 02/10] Makefile: Prepare for using
On Wed, Nov 07, 2018 at 06:37:57PM +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 06, 2018 at 08:40:00AM -0800, Sean Christopherson wrote:
> > On Tue, 2018-11-06 at 15:45 +0200, Jarkko Sakkinen wrote:
> > > Intel Software Guard eXtensions (SGX) is a set of CPU instructions that
> > > can be used by
On Wed, Nov 07, 2018 at 06:37:57PM +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 06, 2018 at 08:40:00AM -0800, Sean Christopherson wrote:
> > On Tue, 2018-11-06 at 15:45 +0200, Jarkko Sakkinen wrote:
> > > Intel Software Guard eXtensions (SGX) is a set of CPU instructions that
> > > can be used by
> On Wed, Nov 07, 2018 at 04:12:14PM -, David Woodhouse wrote:
>>
>> > Yes, this may slow things down. I am not sure I agree with the impl.
>> > either.
>> > Could one not make cpu_to_je_X/jeX_to_cpu a function ptr which is set
>> to
>> > a func. with the correct endian?
>>
>> On x86
> On Wed, Nov 07, 2018 at 04:12:14PM -, David Woodhouse wrote:
>>
>> > Yes, this may slow things down. I am not sure I agree with the impl.
>> > either.
>> > Could one not make cpu_to_je_X/jeX_to_cpu a function ptr which is set
>> to
>> > a func. with the correct endian?
>>
>> On x86
From: YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/fpga/dfl-fme-pr.c: In function 'pr_mgmt_uinit':
drivers/fpga/dfl-fme-pr.c:447:18: warning:
variable 'priv' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing
Acked-by: Moritz Fischer
Acked-by: Wu Hao
From: YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/fpga/dfl-fme-pr.c: In function 'pr_mgmt_uinit':
drivers/fpga/dfl-fme-pr.c:447:18: warning:
variable 'priv' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing
Acked-by: Moritz Fischer
Acked-by: Wu Hao
From: Mike Looijmans
The Xilinx Zynq FPGA driver takes ownership of the PR interface, making
it impossible to use the ICAP interface for partial reconfiguration.
This patch changes the driver to only activate PR over PCAP while the
device is actively being accessed by the driver for
Add initial pinctrl driver for Mediatek MT6797 SoC supporting only
GPIO and pinmux configurations.
Tested-by: Matthias Brugger
Acked-by: Sean Wang
Signed-off-by: Manivannan Sadhasivam
---
drivers/pinctrl/mediatek/Kconfig |7 +
drivers/pinctrl/mediatek/Makefile |
From: Mike Looijmans
The Xilinx Zynq FPGA driver takes ownership of the PR interface, making
it impossible to use the ICAP interface for partial reconfiguration.
This patch changes the driver to only activate PR over PCAP while the
device is actively being accessed by the driver for
Add initial pinctrl driver for Mediatek MT6797 SoC supporting only
GPIO and pinmux configurations.
Tested-by: Matthias Brugger
Acked-by: Sean Wang
Signed-off-by: Manivannan Sadhasivam
---
drivers/pinctrl/mediatek/Kconfig |7 +
drivers/pinctrl/mediatek/Makefile |
From: Anatolij Gustschin
If mapping the CvP BAR fails, we still can configure the FPGA via
PCI config space access. In this case the iomap pointer is NULL.
On x86_64, passing NULL address to pci_iounmap() generates
"Bad IO access at port 0x0" output with stack call trace. Fix it.
Signed-off-by:
Hi Greg,
Please take these four small fpga fixes patches. They
have been reviewed on the mailing list and apply
cleanly on current linux-next and char-misc-testing.
Thanks,
Alan
Anatolij Gustschin (1):
fpga: altera-cvp: fix 'bad IO access' on x86_64
Andreas Puhm (1):
fpga: altera-cvp: Fix
From: Andreas Puhm
The probe function needs to verify the CvP enable bit in order to
properly determine if FPGA Manager functionality can be safely
enabled.
Fixes: 34d1dc17ce97 ("fpga manager: Add Altera CvP driver")
Signed-off-by: Andreas Puhm
Signed-off-by: Anatolij Gustschin
Reviewed-by:
From: Anatolij Gustschin
If mapping the CvP BAR fails, we still can configure the FPGA via
PCI config space access. In this case the iomap pointer is NULL.
On x86_64, passing NULL address to pci_iounmap() generates
"Bad IO access at port 0x0" output with stack call trace. Fix it.
Signed-off-by:
Hi Greg,
Please take these four small fpga fixes patches. They
have been reviewed on the mailing list and apply
cleanly on current linux-next and char-misc-testing.
Thanks,
Alan
Anatolij Gustschin (1):
fpga: altera-cvp: fix 'bad IO access' on x86_64
Andreas Puhm (1):
fpga: altera-cvp: Fix
From: Andreas Puhm
The probe function needs to verify the CvP enable bit in order to
properly determine if FPGA Manager functionality can be safely
enabled.
Fixes: 34d1dc17ce97 ("fpga manager: Add Altera CvP driver")
Signed-off-by: Andreas Puhm
Signed-off-by: Anatolij Gustschin
Reviewed-by:
Add devicetree bindings for Mediatek MT6797 SoC Pin Controller.
Signed-off-by: Manivannan Sadhasivam
---
.../bindings/pinctrl/pinctrl-mt6797.txt | 83 +
include/dt-bindings/pinctrl/mt6797-pinfunc.h | 1368 +
2 files changed, 1451 insertions(+)
create mode 100644
Add devicetree bindings for Mediatek MT6797 SoC Pin Controller.
Signed-off-by: Manivannan Sadhasivam
---
.../bindings/pinctrl/pinctrl-mt6797.txt | 83 +
include/dt-bindings/pinctrl/mt6797-pinfunc.h | 1368 +
2 files changed, 1451 insertions(+)
create mode 100644
Add pinmux support for UART1 on MediatekX20 Development board based
on Mediatek MT6797 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts | 2 ++
arch/arm64/boot/dts/mediatek/mt6797.dtsi| 7 +++
2 files changed, 9 insertions(+)
diff --git
Add pinmux support for UART1 on MediatekX20 Development board based
on Mediatek MT6797 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts | 2 ++
arch/arm64/boot/dts/mediatek/mt6797.dtsi| 7 +++
2 files changed, 9 insertions(+)
diff --git
Add pinctrl support for Mediatek MT6797 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/mediatek/mt6797.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt6797.dtsi
b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
index
Add pinctrl support for Mediatek MT6797 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/mediatek/mt6797.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt6797.dtsi
b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
index
On Wed, Nov 7, 2018 at 1:01 AM Michal Simek wrote:
>
> On 07. 11. 18 9:55, Nathan Chancellor wrote:
> > On Wed, Nov 07, 2018 at 09:46:12AM +0100, Michal Simek wrote:
> >> On 01. 11. 18 1:57, Nathan Chancellor wrote:
> >>> Clang warns when one enumerated type is implicitly converted to another:
>
On Wed, Nov 7, 2018 at 1:01 AM Michal Simek wrote:
>
> On 07. 11. 18 9:55, Nathan Chancellor wrote:
> > On Wed, Nov 07, 2018 at 09:46:12AM +0100, Michal Simek wrote:
> >> On 01. 11. 18 1:57, Nathan Chancellor wrote:
> >>> Clang warns when one enumerated type is implicitly converted to another:
>
This patchset adds initial pinctrl support for Mediatek MT6797 SoC.
The pinctrl driver is based on the vendor binding as like MT6765 and
implements only GPIO and pinmux functionalities.
The devicetree binding document consists of pinmux, pinconf and
interrupt functionalities documented since the
This patchset adds initial pinctrl support for Mediatek MT6797 SoC.
The pinctrl driver is based on the vendor binding as like MT6765 and
implements only GPIO and pinmux functionalities.
The devicetree binding document consists of pinmux, pinconf and
interrupt functionalities documented since the
On Wed, 7 Nov 2018, Thomas Gleixner wrote:
> Add a document to the subsystem/maintainer handbook section, which explains
> what the tip tree is, how it operates and what rules and expectations it
> has.
Peter asked me to add a section about locking comments. I added it and
forgot to refresh the
On Wed, 7 Nov 2018, Thomas Gleixner wrote:
> Add a document to the subsystem/maintainer handbook section, which explains
> what the tip tree is, how it operates and what rules and expectations it
> has.
Peter asked me to add a section about locking comments. I added it and
forgot to refresh the
On 11/06/2018 10:23 AM, Aubrey Li wrote:
> +static inline void update_avx_state(struct avx_state *avx)
> +{
> + /*
> + * Check if XGETBV with ECX = 1 supported. XGETBV with ECX = 1
> + * returns the logical-AND of XCR0 and XINUSE. XINUSE is a bitmap
> + * by which the processor
On 11/06/2018 10:23 AM, Aubrey Li wrote:
> +static inline void update_avx_state(struct avx_state *avx)
> +{
> + /*
> + * Check if XGETBV with ECX = 1 supported. XGETBV with ECX = 1
> + * returns the logical-AND of XCR0 and XINUSE. XINUSE is a bitmap
> + * by which the processor
Presently the arches arm64, arm and sh have a function which loops through
each memblock and calls memory present. riscv will require a similar
function.
Introduce a common memblocks_present() function that can be used by
all the arches. Subsequent patches will cleanup the arches that
make use of
This define is used by arm64 to calculate the size of the vmemmap
region. It is defined as the log2 of the upper bound on the size
of a struct page.
We move it into mm_types.h so it can be defined properly instead of
set and checked with a build bug. This also allows us to use the same
define for
This define is used by arm64 to calculate the size of the vmemmap
region. It is defined as the log2 of the upper bound on the size
of a struct page.
We move it into mm_types.h so it can be defined properly instead of
set and checked with a build bug. This also allows us to use the same
define for
Presently the arches arm64, arm and sh have a function which loops through
each memblock and calls memory present. riscv will require a similar
function.
Introduce a common memblocks_present() function that can be used by
all the arches. Subsequent patches will cleanup the arches that
make use of
These are the first two common patches in my series to introduce
sparsemem support to RISC-V. The full series was posted last cycle
here [1] and the latest version can be found here [2].
As recommended by Palmer, I'd like to get the changes to common code
merged and then I will pursue the
These are the first two common patches in my series to introduce
sparsemem support to RISC-V. The full series was posted last cycle
here [1] and the latest version can be found here [2].
As recommended by Palmer, I'd like to get the changes to common code
merged and then I will pursue the
On Tue, Nov 6, 2018 at 3:32 PM Laurent Pinchart
wrote:
>
> Hi Olof,
>
> On Wednesday, 7 November 2018 00:16:27 EET Olof Johansson wrote:
> > Hi KS organizers (and others),
> >
> > This is a late topic proposal, hopefully there is still time on the agenda.
> >
> > We’ve recently been discussing
On Tue, Nov 6, 2018 at 3:32 PM Laurent Pinchart
wrote:
>
> Hi Olof,
>
> On Wednesday, 7 November 2018 00:16:27 EET Olof Johansson wrote:
> > Hi KS organizers (and others),
> >
> > This is a late topic proposal, hopefully there is still time on the agenda.
> >
> > We’ve recently been discussing
On Wed, Nov 7, 2018 at 9:17 AM Theodore Y. Ts'o wrote:
>
> On Tue, Nov 06, 2018 at 02:16:27PM -0800, Olof Johansson wrote:
> >
> > Olof Johansson (arm-soc)
> > Arnd Bergmann (arm-soc)
> > Kevin Hilman (arm-soc)
> > Mike Turquette (clk)
> > Stephen Boyd (clk)
> > Linus Walleij (pinctrl + more)
> >
On Wed, Nov 7, 2018 at 9:17 AM Theodore Y. Ts'o wrote:
>
> On Tue, Nov 06, 2018 at 02:16:27PM -0800, Olof Johansson wrote:
> >
> > Olof Johansson (arm-soc)
> > Arnd Bergmann (arm-soc)
> > Kevin Hilman (arm-soc)
> > Mike Turquette (clk)
> > Stephen Boyd (clk)
> > Linus Walleij (pinctrl + more)
> >
On Wed, Nov 07, 2018 at 04:12:14PM -, David Woodhouse wrote:
>
> > Yes, this may slow things down. I am not sure I agree with the impl.
> > either.
> > Could one not make cpu_to_je_X/jeX_to_cpu a function ptr which is set to
> > a func. with the correct endian?
>
> On x86 retpoline would
On Wed, Nov 07, 2018 at 04:12:14PM -, David Woodhouse wrote:
>
> > Yes, this may slow things down. I am not sure I agree with the impl.
> > either.
> > Could one not make cpu_to_je_X/jeX_to_cpu a function ptr which is set to
> > a func. with the correct endian?
>
> On x86 retpoline would
On Thu, Nov 08, 2018 at 12:15:05AM +0800, Muchun Song wrote:
> We use a value to represent the priority of the RT task. But a smaller
> value corresponds to a higher priority. If there are two RT task A and B,
> their priorities are prio_a and prio_b, respectively. If prio_a is larger
> than
On Thu, Nov 08, 2018 at 12:15:05AM +0800, Muchun Song wrote:
> We use a value to represent the priority of the RT task. But a smaller
> value corresponds to a higher priority. If there are two RT task A and B,
> their priorities are prio_a and prio_b, respectively. If prio_a is larger
> than
Fixes dc6982ff4db1 ("ext4: refactor code to read directory blocks ...")
Cc: sta...@kernel.org # 3.9
Signed-off-by: Vasily Averin
---
fs/ext4/namei.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index d388cce72db2..6a6b90363ef1 100644
---
Fixes dc6982ff4db1 ("ext4: refactor code to read directory blocks ...")
Cc: sta...@kernel.org # 3.9
Signed-off-by: Vasily Averin
---
fs/ext4/namei.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index d388cce72db2..6a6b90363ef1 100644
---
On Wed, Nov 7, 2018 at 9:17 AM Linus Torvalds
wrote:
>
> On Wed, Nov 7, 2018 at 9:10 AM Olof Johansson wrote:
> >
> > ARM: SoC fixes
>
> Pulled.
>
> > I was a bit too trigger happy to enable PREEMPT on multi_v7_defconfig,
> > and it ended up regressing at least BeagleBone XM boards.
>
> Odd. Did
On Wed, Nov 7, 2018 at 9:17 AM Linus Torvalds
wrote:
>
> On Wed, Nov 7, 2018 at 9:10 AM Olof Johansson wrote:
> >
> > ARM: SoC fixes
>
> Pulled.
>
> > I was a bit too trigger happy to enable PREEMPT on multi_v7_defconfig,
> > and it ended up regressing at least BeagleBone XM boards.
>
> Odd. Did
Add a document to the subsystem/maintainer handbook section, which explains
what the tip tree is, how it operates and what rules and expectations it
has.
Signed-off-by: Thomas Gleixner
---
Documentation/process/maintainer-handbooks.rst |2
Documentation/process/maintainer-tip.rst |
General rules for patch submission, coding style and related details are
available, but most subsystems have their sub-system specific extra rules
which differ or go beyond the common rules.
Mark suggested to add a subsystem/maintainer handbook section, where
subsystem maintainers can explain
Add a document to the subsystem/maintainer handbook section, which explains
what the tip tree is, how it operates and what rules and expectations it
has.
Signed-off-by: Thomas Gleixner
---
Documentation/process/maintainer-handbooks.rst |2
Documentation/process/maintainer-tip.rst |
General rules for patch submission, coding style and related details are
available, but most subsystems have their sub-system specific extra rules
which differ or go beyond the common rules.
Mark suggested to add a subsystem/maintainer handbook section, where
subsystem maintainers can explain
Mark recently suggested in one of the ksummit discussions to add subsystem
or tree specific maintainer handbooks to document subsystem/tree specific
development process information.
The following series adds the general section and the tip tree specific
handbook.
Thanks,
tglx
Mark recently suggested in one of the ksummit discussions to add subsystem
or tree specific maintainer handbooks to document subsystem/tree specific
development process information.
The following series adds the general section and the tip tree specific
handbook.
Thanks,
tglx
On 07/11/2018 14:54:17+, claudiu.bez...@microchip.com wrote:
> Hi Alexandre,
>
> On 06.11.2018 23:09, Alexandre Belloni wrote:
> > Hi Claudiu,
> >
> > On 05/11/2018 11:14:26+, claudiu.bez...@microchip.com wrote:
> >> static int __init at91_poweroff_probe(struct platform_device *pdev)
>
On Tue, Nov 06, 2018 at 06:30:24PM +0100, Andrey Konovalov wrote:
> This commit adds a few helper functions, that are meant to be used to
> work with tags embedded in the top byte of kernel pointers: to set, to
> get or to reset (set to 0xff) the top byte.
>
> Reviewed-by: Andrey Ryabinin
>
On 07/11/2018 14:54:17+, claudiu.bez...@microchip.com wrote:
> Hi Alexandre,
>
> On 06.11.2018 23:09, Alexandre Belloni wrote:
> > Hi Claudiu,
> >
> > On 05/11/2018 11:14:26+, claudiu.bez...@microchip.com wrote:
> >> static int __init at91_poweroff_probe(struct platform_device *pdev)
>
On Tue, Nov 06, 2018 at 06:30:24PM +0100, Andrey Konovalov wrote:
> This commit adds a few helper functions, that are meant to be used to
> work with tags embedded in the top byte of kernel pointers: to set, to
> get or to reset (set to 0xff) the top byte.
>
> Reviewed-by: Andrey Ryabinin
>
I was wrong here, but brelse is lost in next error in this function.
I'll resend new patch.
On 11/7/18 6:25 PM, Theodore Y. Ts'o wrote:
> On Wed, Oct 31, 2018 at 10:12:18PM +0300, Vasily Averin wrote:
>> Fixes dc6982ff4db1 ("ext4: refactor code to read directory blocks ...") # 3.9
>>
>>
I was wrong here, but brelse is lost in next error in this function.
I'll resend new patch.
On 11/7/18 6:25 PM, Theodore Y. Ts'o wrote:
> On Wed, Oct 31, 2018 at 10:12:18PM +0300, Vasily Averin wrote:
>> Fixes dc6982ff4db1 ("ext4: refactor code to read directory blocks ...") # 3.9
>>
>>
On Wed, Nov 7, 2018 at 9:10 AM Olof Johansson wrote:
>
> ARM: SoC fixes
Pulled.
> I was a bit too trigger happy to enable PREEMPT on multi_v7_defconfig,
> and it ended up regressing at least BeagleBone XM boards.
Odd. Did it hit some "may_sleep()" test in a driver that is hidden by
preempt
On Wed, Nov 7, 2018 at 9:10 AM Olof Johansson wrote:
>
> ARM: SoC fixes
Pulled.
> I was a bit too trigger happy to enable PREEMPT on multi_v7_defconfig,
> and it ended up regressing at least BeagleBone XM boards.
Odd. Did it hit some "may_sleep()" test in a driver that is hidden by
preempt
On Tue, Nov 06, 2018 at 02:16:27PM -0800, Olof Johansson wrote:
>
> Olof Johansson (arm-soc)
> Arnd Bergmann (arm-soc)
> Kevin Hilman (arm-soc)
> Mike Turquette (clk)
> Stephen Boyd (clk)
> Linus Walleij (pinctrl + more)
> Mike Brown (gpio/regmap + more)
Could the poeple listed on this list
On Tue, Nov 06, 2018 at 02:16:27PM -0800, Olof Johansson wrote:
>
> Olof Johansson (arm-soc)
> Arnd Bergmann (arm-soc)
> Kevin Hilman (arm-soc)
> Mike Turquette (clk)
> Stephen Boyd (clk)
> Linus Walleij (pinctrl + more)
> Mike Brown (gpio/regmap + more)
Could the poeple listed on this list
701 - 800 of 1460 matches
Mail list logo
