On Wed, Nov 14, 2018 at 4:35 AM, William Kucharski
wrote:
>
>
>> On Nov 13, 2018, at 5:51 PM, Isaac J. Manjarres
>> wrote:
>>
>> diff --git a/mm/usercopy.c b/mm/usercopy.c
>> index 852eb4e..0293645 100644
>> --- a/mm/usercopy.c
>> +++ b/mm/usercopy.c
>> @@ -151,7 +151,7 @@ static inline void
On Wed, Nov 14, 2018 at 4:35 AM, William Kucharski
wrote:
>
>
>> On Nov 13, 2018, at 5:51 PM, Isaac J. Manjarres
>> wrote:
>>
>> diff --git a/mm/usercopy.c b/mm/usercopy.c
>> index 852eb4e..0293645 100644
>> --- a/mm/usercopy.c
>> +++ b/mm/usercopy.c
>> @@ -151,7 +151,7 @@ static inline void
On 11/11/2018 19:26, Rob Herring wrote:
> On Sun, Nov 11, 2018 at 7:04 AM Andy Shevchenko
> wrote:
>>
>> I seems Grant's mail delivery bounces messages. I delibirately reduced
>> the Cc list for sake of ping Grant in case it would pass.
>
> That would be because he is not at Linaro anymore.
On 11/11/2018 19:26, Rob Herring wrote:
> On Sun, Nov 11, 2018 at 7:04 AM Andy Shevchenko
> wrote:
>>
>> I seems Grant's mail delivery bounces messages. I delibirately reduced
>> the Cc list for sake of ping Grant in case it would pass.
>
> That would be because he is not at Linaro anymore.
Christian Hewitt writes:
> This enables Bluetooth support for the following models:
>
> - Khadas VIM basic (AP6212) using firmware BCM43438A1.hcd
> - Khadas VIM pro (AP6255) using firmware BCM4345C0.hcd
>
> The AP6212 module used on the VIM basic has an ID clash with another
> device. To get
Christian Hewitt writes:
> This enables Bluetooth support for the following models:
>
> - Khadas VIM basic (AP6212) using firmware BCM43438A1.hcd
> - Khadas VIM pro (AP6255) using firmware BCM4345C0.hcd
>
> The AP6212 module used on the VIM basic has an ID clash with another
> device. To get
Quoting Shawn Guo (2018-11-13 06:25:36)
> On Sat, Nov 10, 2018 at 04:05:44PM +, A.s. Dong wrote:
> > Hi Stephen,
> >
> > [...]
> > > > I already sent the 12th version of this current patch series and I
> > > > would really like to get this in ASAP so that the booting up of imx8mq
> > > >
Quoting Shawn Guo (2018-11-13 06:25:36)
> On Sat, Nov 10, 2018 at 04:05:44PM +, A.s. Dong wrote:
> > Hi Stephen,
> >
> > [...]
> > > > I already sent the 12th version of this current patch series and I
> > > > would really like to get this in ASAP so that the booting up of imx8mq
> > > >
The pull request you sent on Wed, 14 Nov 2018 14:35:54 -0800 (PST):
> git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git
> tags/riscv-for-linus-4.20-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5929a1f0ff30d04ccf4b0f9c648e7aa8bc816bbd
Thank
On Wed, Nov 14, 2018 at 3:00 PM Eric Biggers wrote:
>
> Hi Dmitry,
>
> On Wed, Nov 14, 2018 at 02:28:56PM -0800, 'Dmitry Torokhov' via
> syzkaller-bugs wrote:
> > On Wed, Nov 14, 2018 at 2:05 PM Jann Horn wrote:
> > >
> > > On Wed, Nov 14, 2018 at 10:55 PM Eric Biggers wrote:
> > > >
> > > >
On Wed, Nov 14, 2018 at 3:00 PM Eric Biggers wrote:
>
> Hi Dmitry,
>
> On Wed, Nov 14, 2018 at 02:28:56PM -0800, 'Dmitry Torokhov' via
> syzkaller-bugs wrote:
> > On Wed, Nov 14, 2018 at 2:05 PM Jann Horn wrote:
> > >
> > > On Wed, Nov 14, 2018 at 10:55 PM Eric Biggers wrote:
> > > >
> > > >
The pull request you sent on Wed, 14 Nov 2018 14:35:54 -0800 (PST):
> git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git
> tags/riscv-for-linus-4.20-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5929a1f0ff30d04ccf4b0f9c648e7aa8bc816bbd
Thank
The pull request you sent on Tue, 13 Nov 2018 21:32:42 +:
> https://git.linaro.org/people/daniel.thompson/linux.git
> tags/kgdb-fixes-4.20-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9746e46737a143631a301be9a09fafdae3349138
Thank you!
--
Deet-doot-dot,
The pull request you sent on Wed, 14 Nov 2018 08:17:19 +1100 (AEDT):
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
> fixes-v4.20-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e4c4b0e45dfd1212831ad5bd129c6781d55e162a
Thank you!
--
The pull request you sent on Tue, 13 Nov 2018 21:32:42 +:
> https://git.linaro.org/people/daniel.thompson/linux.git
> tags/kgdb-fixes-4.20-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9746e46737a143631a301be9a09fafdae3349138
Thank you!
--
Deet-doot-dot,
The pull request you sent on Wed, 14 Nov 2018 08:17:19 +1100 (AEDT):
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
> fixes-v4.20-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e4c4b0e45dfd1212831ad5bd129c6781d55e162a
Thank you!
--
On Wed, 14 Nov 2018 08:14:42 +0100 Michal Hocko wrote:
> It seems there were no objections here. So can we have it in linux-next
> for a wider testing a possibly target the next merge window?
>
top-posting sucks!
I already have this queued for 4.21-rc1.
On Wed, 14 Nov 2018 08:14:42 +0100 Michal Hocko wrote:
> It seems there were no objections here. So can we have it in linux-next
> for a wider testing a possibly target the next merge window?
>
top-posting sucks!
I already have this queued for 4.21-rc1.
On 11/10/2018 08:44 AM, Andrea Arcangeli wrote:
> On Sat, Nov 10, 2018 at 01:22:49PM +, Mel Gorman wrote:
>> On Fri, Nov 09, 2018 at 02:51:50PM -0500, Andrea Arcangeli wrote:
>>> And if you're in the camp that is concerned about the use of more RAM
>>> or/and about the higher latency of COW
On 11/10/2018 08:44 AM, Andrea Arcangeli wrote:
> On Sat, Nov 10, 2018 at 01:22:49PM +, Mel Gorman wrote:
>> On Fri, Nov 09, 2018 at 02:51:50PM -0500, Andrea Arcangeli wrote:
>>> And if you're in the camp that is concerned about the use of more RAM
>>> or/and about the higher latency of COW
On Wed, Nov 14, 2018 at 9:40 AM, Laura Abbott wrote:
> On 11/14/18 5:16 AM, David Herrmann wrote:
>>
>> This reverts commit 336fd4f5f25157e9e8bd50e898a1bbcd99eaea46.
>>
>> Please note that `strlcpy()` does *NOT* do what you think it does.
>> strlcpy() *ALWAYS* reads the full input string,
On Wed, Nov 14, 2018 at 9:40 AM, Laura Abbott wrote:
> On 11/14/18 5:16 AM, David Herrmann wrote:
>>
>> This reverts commit 336fd4f5f25157e9e8bd50e898a1bbcd99eaea46.
>>
>> Please note that `strlcpy()` does *NOT* do what you think it does.
>> strlcpy() *ALWAYS* reads the full input string,
The third operand of mtspr instruction must be a constant. To guarantee
this condition, function cache_loop() which uses macro mtspr() must be
inlined. So let's force it as 'inline'. This is to fix compiling error with
new option CONFIG_NO_AUTO_INLINE.
In file included from
The third operand of mtspr instruction must be a constant. To guarantee
this condition, function cache_loop() which uses macro mtspr() must be
inlined. So let's force it as 'inline'. This is to fix compiling error with
new option CONFIG_NO_AUTO_INLINE.
In file included from
Some Meson8b boards (Odroid-C1, EC-100) use a PWM regulator which is the
voltage supply of the CPU cores (this regulator is typically called
"VCCK").
Now that we are preparing support for CPU frequency scaling on Meson8,
Meson8b and Meson8m2 we should build the pwm-meson driver into the
kernel so
Some Meson8b boards (Odroid-C1, EC-100) use a PWM regulator which is the
voltage supply of the CPU cores (this regulator is typically called
"VCCK").
Now that we are preparing support for CPU frequency scaling on Meson8,
Meson8b and Meson8m2 we should build the pwm-meson driver into the
kernel so
On Wed, Nov 14, 2018 at 02:57:18PM -0800, Matthias Kaehlcke wrote:
> On Thu, Sep 20, 2018 at 10:12:53AM -0700, Matthias Kaehlcke wrote:
> > sysrq_handle_crash() currently forces a crash by dereferencing a
> > NULL pointer, which is undefined behavior in C. Just call panic()
> > instead, which is
On Wed, Nov 14, 2018 at 02:57:18PM -0800, Matthias Kaehlcke wrote:
> On Thu, Sep 20, 2018 at 10:12:53AM -0700, Matthias Kaehlcke wrote:
> > sysrq_handle_crash() currently forces a crash by dereferencing a
> > NULL pointer, which is undefined behavior in C. Just call panic()
> > instead, which is
Hi Dmitry,
On Wed, Nov 14, 2018 at 02:28:56PM -0800, 'Dmitry Torokhov' via syzkaller-bugs
wrote:
> On Wed, Nov 14, 2018 at 2:05 PM Jann Horn wrote:
> >
> > On Wed, Nov 14, 2018 at 10:55 PM Eric Biggers wrote:
> > >
> > > From: Eric Biggers
> > >
> > > When a UHID_CREATE command is written to
Hi Dmitry,
On Wed, Nov 14, 2018 at 02:28:56PM -0800, 'Dmitry Torokhov' via syzkaller-bugs
wrote:
> On Wed, Nov 14, 2018 at 2:05 PM Jann Horn wrote:
> >
> > On Wed, Nov 14, 2018 at 10:55 PM Eric Biggers wrote:
> > >
> > > From: Eric Biggers
> > >
> > > When a UHID_CREATE command is written to
On Wed, 14 Nov 2018 16:17:37 +0100 Michal Hocko wrote:
> On Tue 13-11-18 14:10:46, Andrew Morton wrote:
> [...]
> > > +static int vmalloc_test_init(void)
> > > +{
> > > + __my_vmalloc_node_range =
> > > + (void *) kallsyms_lookup_name("__vmalloc_node_range");
> > > +
> > > + if
On Wed, 14 Nov 2018 16:17:37 +0100 Michal Hocko wrote:
> On Tue 13-11-18 14:10:46, Andrew Morton wrote:
> [...]
> > > +static int vmalloc_test_init(void)
> > > +{
> > > + __my_vmalloc_node_range =
> > > + (void *) kallsyms_lookup_name("__vmalloc_node_range");
> > > +
> > > + if
On Wed, Nov 14, 2018 at 08:51:44PM +0100, Johan Hovold wrote:
> Hi Greg,
>
> Please ignore my previous pull request for GNSS fixes and consider this one
> instead.
>
> I've now asked Stephen to include the GNSS tree in linux-next, and he
> immediately spotted the missing Sign-offs. I was too
On Wed, Nov 14, 2018 at 08:51:44PM +0100, Johan Hovold wrote:
> Hi Greg,
>
> Please ignore my previous pull request for GNSS fixes and consider this one
> instead.
>
> I've now asked Stephen to include the GNSS tree in linux-next, and he
> immediately spotted the missing Sign-offs. I was too
The cpu_div3 clock (cpu_in divided by 3) generates a signal with a duty
cycle of 33%. The CPU clock however requires a clock signal with a duty
cycle of 50% to run stable.
cpu_div3 was observed to be problematic when cycling through all
available CPU frequencies (with additional patches on top of
We don't want the common clock framework to disable the "cpu_clk" if
it's not used by any device. The cpufreq-dt driver does not enable the
CPU clocks. However, even if it would we would still want the CPU clock
to be enabled at all times because the CPU clock is also required even
if we disable
The sys_pll on the EC-100 board is configured to 1584MHz at boot
(either by u-boot, firmware or chip defaults). This is achieved by using
M = 66, N = 1 (24MHz * 66 / 1).
At boot the CPU clock is running off sys_pll divided by 2 which results
in 792MHz. Thus M = 66 is considered to be a "safe"
Now that we have a utility function to check whether the PLL is enabled
we can also pass that to our clk_ops to let the common clock framework
know about the status of the hardware clock.
For now this is of limited use since the only common clock framework's
internal "disabled unused clocks"
The cpu_div3 clock (cpu_in divided by 3) generates a signal with a duty
cycle of 33%. The CPU clock however requires a clock signal with a duty
cycle of 50% to run stable.
cpu_div3 was observed to be problematic when cycling through all
available CPU frequencies (with additional patches on top of
We don't want the common clock framework to disable the "cpu_clk" if
it's not used by any device. The cpufreq-dt driver does not enable the
CPU clocks. However, even if it would we would still want the CPU clock
to be enabled at all times because the CPU clock is also required even
if we disable
The sys_pll on the EC-100 board is configured to 1584MHz at boot
(either by u-boot, firmware or chip defaults). This is achieved by using
M = 66, N = 1 (24MHz * 66 / 1).
At boot the CPU clock is running off sys_pll divided by 2 which results
in 792MHz. Thus M = 66 is considered to be a "safe"
Now that we have a utility function to check whether the PLL is enabled
we can also pass that to our clk_ops to let the common clock framework
know about the status of the hardware clock.
For now this is of limited use since the only common clock framework's
internal "disabled unused clocks"
Since commit 6f888e7bc7bd58 ("clk: meson: clk-pll: add enable bit") our
PLLs also support the "enable" bit. Currently meson_clk_pll_enable
unconditionally resets the PLL, enables it, takes it out of reset and
waits until it is locked.
This works fine for our current clock trees. However, there
This allows changing the CPU clock on the 32-bit Amlogic Meson SoCs
(Meson8, Meson8b and Meson8m2).
CPU frequency scaling will be enabled with a separate series by adding
the CPU clock and the OPP tables to meson8.dtsi and meson8b.dtsi.
While changing the CPU frequency (sys_pll or any of it's
This allows changing the CPU clock on the 32-bit Amlogic Meson SoCs
(Meson8, Meson8b and Meson8m2).
CPU frequency scaling will be enabled with a separate series by adding
the CPU clock and the OPP tables to meson8.dtsi and meson8b.dtsi.
While changing the CPU frequency (sys_pll or any of it's
Since commit 6f888e7bc7bd58 ("clk: meson: clk-pll: add enable bit") our
PLLs also support the "enable" bit. Currently meson_clk_pll_enable
unconditionally resets the PLL, enables it, takes it out of reset and
waits until it is locked.
This works fine for our current clock trees. However, there
Changing the CPU clock requires changing various clocks including the
SYS PLL. The existing meson clk-pll and clk-regmap drivers can change
all of the relevant clocks already.
However, changing for exampe the SYS PLL is problematic because as long
as the CPU is running off a clock derived from SYS
Changing the CPU clock requires changing various clocks including the
SYS PLL. The existing meson clk-pll and clk-regmap drivers can change
all of the relevant clocks already.
However, changing for exampe the SYS PLL is problematic because as long
as the CPU is running off a clock derived from SYS
Currently all clocks in the CPU clock tree are marked as read-only
(using the corresponding _ro_ clk_ops). This was correct since changing
the clock tree could cause the system to lock up.
Switch all clocks to their corresponding clk_ops variant which is not
read-only to allow changing the CPU
Currently all clocks in the CPU clock tree are marked as read-only
(using the corresponding _ro_ clk_ops). This was correct since changing
the clock tree could cause the system to lock up.
Switch all clocks to their corresponding clk_ops variant which is not
read-only to allow changing the CPU
On Thu, Sep 20, 2018 at 10:12:53AM -0700, Matthias Kaehlcke wrote:
> sysrq_handle_crash() currently forces a crash by dereferencing a
> NULL pointer, which is undefined behavior in C. Just call panic()
> instead, which is simpler and doesn't depend on compiler specific
> handling of the undefined
On Thu, Sep 20, 2018 at 10:12:53AM -0700, Matthias Kaehlcke wrote:
> sysrq_handle_crash() currently forces a crash by dereferencing a
> NULL pointer, which is undefined behavior in C. Just call panic()
> instead, which is simpler and doesn't depend on compiler specific
> handling of the undefined
The pull request you sent on Tue, 13 Nov 2018 16:06:35 -0500:
> git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.20-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4e4490d438a1c84411e3ebd0b850b46dd2e752cf
Thank you!
--
Deet-doot-dot, I am a bot.
The pull request you sent on Wed, 14 Nov 2018 21:16:14 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-4.20-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/dbb3c26034fa5336de45e667e2faf80a78531cd0
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Tue, 13 Nov 2018 16:06:35 -0500:
> git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.20-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4e4490d438a1c84411e3ebd0b850b46dd2e752cf
Thank you!
--
Deet-doot-dot, I am a bot.
The pull request you sent on Wed, 14 Nov 2018 21:16:14 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-4.20-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/dbb3c26034fa5336de45e667e2faf80a78531cd0
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Wed, 14 Nov 2018 21:17:37 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
> acpi-4.20-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3472f66013d1972f0baf1631ea1e02479b902579
Thank you!
--
Deet-doot-dot, I
The pull request you sent on Wed, 14 Nov 2018 21:17:37 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
> acpi-4.20-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3472f66013d1972f0baf1631ea1e02479b902579
Thank you!
--
Deet-doot-dot, I
This is a note to let you know that I've just added the patch titled
tools: Add 'firmware' category and add ihex2fw tool
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-next branch.
The patch will show
This is a note to let you know that I've just added the patch titled
tools: Add 'firmware' category and add ihex2fw tool
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-next branch.
The patch will show
Heterogeneous memory systems provide memory nodes with latency
and bandwidth performance attributes that are different from other
nodes. Create an interface for the kernel to register these attributes
under the node that provides the memory. If the system provides this
information, applications
The ACPI Heterogeneous Memory Attribute Table (HMAT) table added in ACPI 6.2
provides a way for platforms to express different memory address range
characteristics.
Parse these tables provided by the platform and register the local
initiator performance access and caching attributes with the
System memory may have side caches to help improve access speed. While
the system provided cache is transparent to the software accessing
these memory ranges, applications can optimize their own access based
on cache attributes.
In preparation for such systems, provide a new API for the kernel to
Memory-only nodes will often have affinity to a compute node, and
platforms have ways to express that locality relationship.
A node containing CPUs or other DMA devices that can initiate memory
access are referred to as "memory iniators". A "memory target" is a
node that provides at least one
Heterogeneous memory systems provide memory nodes with latency
and bandwidth performance attributes that are different from other
nodes. Create an interface for the kernel to register these attributes
under the node that provides the memory. If the system provides this
information, applications
The ACPI Heterogeneous Memory Attribute Table (HMAT) table added in ACPI 6.2
provides a way for platforms to express different memory address range
characteristics.
Parse these tables provided by the platform and register the local
initiator performance access and caching attributes with the
System memory may have side caches to help improve access speed. While
the system provided cache is transparent to the software accessing
these memory ranges, applications can optimize their own access based
on cache attributes.
In preparation for such systems, provide a new API for the kernel to
Memory-only nodes will often have affinity to a compute node, and
platforms have ways to express that locality relationship.
A node containing CPUs or other DMA devices that can initiate memory
access are referred to as "memory iniators". A "memory target" is a
node that provides at least one
Platforms may provide system memory where some physical address ranges
perform differently than others. These heterogeneous memory attributes are
common to the node that provides the memory and exported by the kernel.
Add new documentation providing a brief overview of such systems and
the
Platforms may provide system memory that contains side caches to help
spped up access. These memory caches are part of a memory node and
the cache attributes are exported by the kernel.
Add new documentation providing a brief overview of system memory side
caches and the kernel provided
Platforms may provide system memory where some physical address ranges
perform differently than others. These heterogeneous memory attributes are
common to the node that provides the memory and exported by the kernel.
Add new documentation providing a brief overview of such systems and
the
Platforms may provide system memory that contains side caches to help
spped up access. These memory caches are part of a memory node and
the cache attributes are exported by the kernel.
Add new documentation providing a brief overview of system memory side
caches and the kernel provided
Parsing entries in an ACPI table had assumed a generic header structure
that is most common. There is no standard ACPI header, though, so less
common types would need custom parsers if they want go walk their
subtable entry list.
Create the infrastructure for adding different table types so
Parsing entries in an ACPI table had assumed a generic header structure
that is most common. There is no standard ACPI header, though, so less
common types would need custom parsers if they want go walk their
subtable entry list.
Create the infrastructure for adding different table types so
This series provides a new sysfs representation for heterogeneous
system memory.
The previous series that was specific to HMAT that this series was based
on was last posted here: https://lkml.org/lkml/2017/12/13/968
Platforms may provide multiple types of cpu attached system memory. The
memory
This series provides a new sysfs representation for heterogeneous
system memory.
The previous series that was specific to HMAT that this series was based
on was last posted here: https://lkml.org/lkml/2017/12/13/968
Platforms may provide multiple types of cpu attached system memory. The
memory
On Wed, 14 Nov 2018 10:25:32 -0800 Davidlohr Bueso wrote:
> There is no reason why we rearm the waitiqueue upon every
> fetch_events retry (for when events are found yet send_events()
> fails). If nothing else, this saves four lock operations per
> retry, and furthermore reduces the scope of the
On Wed, 14 Nov 2018 10:25:32 -0800 Davidlohr Bueso wrote:
> There is no reason why we rearm the waitiqueue upon every
> fetch_events retry (for when events are found yet send_events()
> fails). If nothing else, this saves four lock operations per
> retry, and furthermore reduces the scope of the
> On Nov 14, 2018, at 10:32 AM, isa...@codeaurora.org wrote:
>
> Thank you and David for your feedback. The check_bogus_address() routine is
> only invoked from one place in the kernel, which is __check_object_size().
> Before invoking check_bogus_address, __check_object_size ensures that n
On Tue, Oct 30, 2018 at 06:07:56PM +0800, Tony Xie wrote:
> if there are lots of irqs for a device and the register addresses for these
> irqs is continuous, we can use this macro to initialize regmap_irq value.
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux
> On Nov 14, 2018, at 10:32 AM, isa...@codeaurora.org wrote:
>
> Thank you and David for your feedback. The check_bogus_address() routine is
> only invoked from one place in the kernel, which is __check_object_size().
> Before invoking check_bogus_address, __check_object_size ensures that n
On Tue, Oct 30, 2018 at 06:07:56PM +0800, Tony Xie wrote:
> if there are lots of irqs for a device and the register addresses for these
> irqs is continuous, we can use this macro to initialize regmap_irq value.
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux
The patch
spi: npcm: fix u32 csgpio being checked for less than zero
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
The patch
regmap: add a new macro:REGMAP_IRQ_REG_LINE(_id, _reg_bits)
has been applied to the regmap tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
spi: npcm: fix u32 csgpio being checked for less than zero
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours)
The patch
regmap: add a new macro:REGMAP_IRQ_REG_LINE(_id, _reg_bits)
has been applied to the regmap tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
On Wed, Nov 14, 2018 at 05:21:54PM -0500, Konstantin Ryabitsev wrote:
> For the record, there's nothing wrong with that, it's just a condition
> that I didn't expect. I have a fix in place that should avoid this in
> the future.
Actually, I meant the pull request URL.
Here's some background
On Wed, Nov 14, 2018 at 05:21:54PM -0500, Konstantin Ryabitsev wrote:
> For the record, there's nothing wrong with that, it's just a condition
> that I didn't expect. I have a fix in place that should avoid this in
> the future.
Actually, I meant the pull request URL.
Here's some background
On Wed, Nov 7, 2018 at 5:57 AM Leonard Crestez wrote:
>
> Enable PCI suspend/resume support on imx6sx socs. This is similar to
> imx7d with a few differences:
>
> * The PM_Turn_Off bit is exposed through an IOMUX GPR, like all other
> pcie control bits on 6sx.
> * The pcie_inbound_axi clk needs
This patch series depends on dax pages not being PageReserved. Once
that is in place, these changes will let KVM use huge pages with
dax-backed files. Without the PageReserved change, KVM and DAX still
work with these patches, simply without huge pages - which is the
current situation.
On Wed, Nov 7, 2018 at 5:57 AM Leonard Crestez wrote:
>
> Enable PCI suspend/resume support on imx6sx socs. This is similar to
> imx7d with a few differences:
>
> * The PM_Turn_Off bit is exposed through an IOMUX GPR, like all other
> pcie control bits on 6sx.
> * The pcie_inbound_axi clk needs
This patch series depends on dax pages not being PageReserved. Once
that is in place, these changes will let KVM use huge pages with
dax-backed files. Without the PageReserved change, KVM and DAX still
work with these patches, simply without huge pages - which is the
current situation.
From: Vasily Gorbik
[ Upstream commit ef5febae1543f35a45f01614123e829d77326d0f ]
According to Documentation/kbuild/makefiles.txt all build targets
using if_changed should use FORCE as well. Add missing FORCE to make
sure vmlinux decompressor targets are rebuild properly when not just
immediate
From: Jiri Slaby
[ Upstream commit 5a8de47b3c250521dd632cdedaac6db88367defa ]
With 4.19, programs like ebtables fail to build when they include
"linux/netfilter_bridge.h". It is caused by commit 94276fa8a2a4 which
added a use of INT_MIN and INT_MAX to the header:
: In file included from
On Wed, Nov 14, 2018 at 2:38 PM Jann Horn wrote:
>
> On Wed, Nov 14, 2018 at 11:29 PM Dmitry Torokhov wrote:
> > On Wed, Nov 14, 2018 at 2:05 PM Jann Horn wrote:
> > > On Wed, Nov 14, 2018 at 10:55 PM Eric Biggers wrote:
> > > > When a UHID_CREATE command is written to the uhid char device, a
From: Vasily Gorbik
[ Upstream commit b44b136a3773d8a9c7853f8df716bd1483613cbb ]
According to Documentation/kbuild/makefiles.txt all build targets using
if_changed should use FORCE as well. Add missing FORCE to make sure
vdso targets are rebuild properly when not just immediate prerequisites
From: Vasily Gorbik
[ Upstream commit ef5febae1543f35a45f01614123e829d77326d0f ]
According to Documentation/kbuild/makefiles.txt all build targets
using if_changed should use FORCE as well. Add missing FORCE to make
sure vmlinux decompressor targets are rebuild properly when not just
immediate
From: Jiri Slaby
[ Upstream commit 5a8de47b3c250521dd632cdedaac6db88367defa ]
With 4.19, programs like ebtables fail to build when they include
"linux/netfilter_bridge.h". It is caused by commit 94276fa8a2a4 which
added a use of INT_MIN and INT_MAX to the header:
: In file included from
On Wed, Nov 14, 2018 at 2:38 PM Jann Horn wrote:
>
> On Wed, Nov 14, 2018 at 11:29 PM Dmitry Torokhov wrote:
> > On Wed, Nov 14, 2018 at 2:05 PM Jann Horn wrote:
> > > On Wed, Nov 14, 2018 at 10:55 PM Eric Biggers wrote:
> > > > When a UHID_CREATE command is written to the uhid char device, a
From: Vasily Gorbik
[ Upstream commit b44b136a3773d8a9c7853f8df716bd1483613cbb ]
According to Documentation/kbuild/makefiles.txt all build targets using
if_changed should use FORCE as well. Add missing FORCE to make sure
vdso targets are rebuild properly when not just immediate prerequisites
201 - 300 of 1344 matches
Mail list logo
