On Fri, Feb 22, 2019 at 11:39 PM Nadav Amit wrote:
> > On Feb 22, 2019, at 2:21 PM, Nadav Amit wrote:
> >
> >> On Feb 22, 2019, at 2:17 PM, Jann Horn wrote:
> >>
> >> On Fri, Feb 22, 2019 at 11:08 PM Nadav Amit wrote:
> On Feb 22, 2019, at 1:43 PM, Jann Horn wrote:
>
> (adding s
On 2/22/19 4:53 AM, Andrey Konovalov wrote:
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -2730,7 +2730,7 @@ void *copy_mount_options(const void __user * data)
>* the remainder of the page.
>*/
> /* copy_from_user cannot cross TASK_SIZE ! */
> - size = TASK_SIZE - (un
On 2/21/19 7:35 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.160 release.
There are 20 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
Support both Python2 and Python3 in the syscall-counts.py script
There may be differences in the ordering of output lines due to
differences in dictionary ordering etc. However the format within lines
should be unchanged.
The use of 'from __future__' implies the minimum supported Python2 version
Support both Python2 and Python3 in the event_analyzing_sample.py script
There may be differences in the ordering of output lines due to
differences in dictionary ordering etc. However the format within lines
should be unchanged.
The use of 'from __future__' implies the minimum supported Python2
Support both Python2 and Python3 in the stat-cpi.py script
There may be differences in the ordering of output lines due to
differences in dictionary ordering etc. However the format within lines
should be unchanged.
The use of 'from __future__' implies the minimum supported Python2 version
is no
Support both Python2 and Python3 in the futex-contention.py script
There may be differences in the ordering of output lines due to
differences in dictionary ordering etc. However the format within lines
should be unchanged.
The use of 'from __future__' implies the minimum supported Python2 versi
Support both Python2 and Python3 in the mem-phys-addr.py script
There may be differences in the ordering of output lines due to
differences in dictionary ordering etc. However the format within lines
should be unchanged.
The use of 'from __future__' implies the minimum supported Python2 version
Support both Python2 and Python3 in the intel-pt-events.py script
There may be differences in the ordering of output lines due to
differences in dictionary ordering etc. However the format within lines
should be unchanged.
Fix space/tab inconsistency as python3 enforces consistency.
The use of
The following patches add Python3 support to the remainder of
the scripts under scripts/python.
Minimum supported Python version is now v2.6
I tested everything against v2.7 (no patch), v2.7 (patch) and
v3.7 (patch). Seeteena also tested a subset (no SQL, no IPT)
against v2.6
There are chang
Support both Python2 and Python3 in the netdev-times.py script
There may be differences in the ordering of output lines due to
differences in dictionary ordering etc. However the format within lines
should be unchanged.
The use of 'from __future__' implies the minimum supported Python2 version
i
On 2/22/19 4:53 AM, Andrey Konovalov wrote:
> userfaultfd_register() and userfaultfd_unregister() use provided user
> pointers for vma lookups, which can only by done with untagged pointers.
So, we have to patch all these sites before the tagged values get to the
point of hitting the vma lookup fu
Support both Python2 and Python3 in the stackcollapse.py script
There may be differences in the ordering of output lines due to
differences in dictionary ordering etc. However the format within lines
should be unchanged.
The use of 'from __future__' implies the minimum supported Python2 version
Support both Python2 and Python3 in the failed-syscalls-by-pid.py script
There may be differences in the ordering of output lines due to
differences in dictionary ordering etc. However the format within lines
should be unchanged.
The use of 'from __future__' implies the minimum supported Python2
Support both Python 2 and Python 3 in the check-perf-trace.py script.
There may be differences in the ordering of output lines due to
differences in dictionary ordering etc. However the format within lines
should be unchanged.
Also correct inconsistent indentation which was being flagged by Pyth
Support both Python2 and Python3 in the sctop.py script
There may be differences in the ordering of output lines due to
differences in dictionary ordering etc. However the format within lines
should be unchanged.
The use of 'from __future__' implies the minimum supported Python2 version
is now v
Support both Python2 and Python3 in the exported-sql-viewer.py,
export-to-postgresql.py and export-to-sqlite.py scripts
There may be differences in the ordering of output lines due to
differences in dictionary ordering etc. However the format within lines
should be unchanged.
The use of 'from __
Support both Python2 and Python3 in the syscall-counts-by-pid.py script
There may be differences in the ordering of output lines due to
differences in dictionary ordering etc. However the format within lines
should be unchanged.
The use of 'from __future__' implies the minimum supported Python2
On 2/21/19 7:35 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.103 release.
There are 23 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
Support both Python2 and Python3 in the net_dropmonitor.py script
There may be differences in the ordering of output lines due to
differences in dictionary ordering etc. However the format within lines
should be unchanged.
The use of 'from __future__' implies the minimum supported Python2 versio
Support both Python2 and Python3 in the powerpc-hcalls.py script
There may be differences in the ordering of output lines due to
differences in dictionary ordering etc. However the format within lines
should be unchanged.
The use of 'from __future__' implies the minimum supported Python2 version
On 2/22/19 4:53 AM, Andrey Konovalov wrote:
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -578,6 +578,7 @@ static int do_mprotect_pkey(unsigned long start, size_t
> len,
> SYSCALL_DEFINE3(mprotect, unsigned long, start, size_t, len,
> unsigned long, prot)
> {
> + start = unt
On 2/21/19 7:35 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.25 release.
There are 30 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
Add several new standard properties to the power supply subsystem
and sysfs support for them. These policies are supported on several
kinds of devices, including Lenovo and Dell. I am adding this in
particular for a new Chrome OS device. All dates and times are expected
to be in local time. Thus, t
This is an example driver that uses the proposed Peak Shift and
Adv Batt Charging support in the main power supply subsystem.
At this point, there is no actual communication with the EC,
the point of this is to show the interface that usespace would see,
and to show the use case for the added prop
On Fri, Feb 22, 2019 at 11:51 PM Alexei Starovoitov
wrote:
>
> On Fri, Feb 22, 2019 at 01:59:10PM -0800, Linus Torvalds wrote:
> > On Fri, Feb 22, 2019 at 1:38 PM David Miller wrote:
> > >
> > > Don't be surprised if we see more separation like this in the future too.
> >
> > Yes, with the whole
From: Jann Horn
Date: Sat, 23 Feb 2019 00:11:58 +0100
> I think what Linus is saying is: There are some scenarios (like a
> system with the old 4G/4G X86 patch) where *the same* address can
> refer to two different pieces of memory, depending on whether you
> interpret it as a kernel pointer or a
8db66cea9a)
>
> Is there a reason this commit appeared in next-20190221 but did not seem to be
> in next-20190222 (confirmed via 'git tag --contains')?
>
> [/usr/src/linux-next] git tag -l next-20190222
> next-20190222
> [/usr/src/linux-next] git tag --contains
>
On 2/21/19 7:35 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.20.12 release.
There are 32 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
On Fri, Feb 22, 2019 at 10:27 AM Matthias Kaehlcke wrote:
>
> On Thu, Feb 21, 2019 at 04:34:03PM -0800, Brian Norris wrote:
> > Currently, we don't coordinate BT USB activity with our handling of the
> > BT out-of-band wake pin, and instead just use gpio-keys. That causes
> > problems because we h
On Fri, Feb 22, 2019 at 2:51 PM Alexei Starovoitov
wrote:
>
> That's all fine. I'm missing rationale for making probe_kernel_read()
> fail on user addresses.
Because it already WON'T WORK in general!
> What is fundamentally wrong with a function probe_any_address_read() ?
What part of "the same
> I'm also more familiar with device-tree (just came across this on my personal
> laptop) but happy to review and test at the risk of learning something.
:) Thanks!
signature.asc
Description: PGP signature
> On Feb 22, 2019, at 3:02 PM, Jann Horn wrote:
>
> On Fri, Feb 22, 2019 at 11:39 PM Nadav Amit wrote:
>>> On Feb 22, 2019, at 2:21 PM, Nadav Amit wrote:
>>>
On Feb 22, 2019, at 2:17 PM, Jann Horn wrote:
On Fri, Feb 22, 2019 at 11:08 PM Nadav Amit wrote:
>> On Feb 22, 201
From: Kalash Nainwal
Date: Wed, 20 Feb 2019 16:23:04 -0800
> Set rtm_table to RT_TABLE_COMPAT for ipv6 for tables > 255 to
> keep legacy software happy. This is similar to what was done for
> ipv4 in commit 709772e6e065 ("net: Fix routing tables with
> id > 255 for legacy software").
>
> Signed-
On Fri, Feb 22, 2019 at 3:22 PM David Miller wrote:
>
> From: Kalash Nainwal
> Date: Wed, 20 Feb 2019 16:23:04 -0800
>
> > Set rtm_table to RT_TABLE_COMPAT for ipv6 for tables > 255 to
> > keep legacy software happy. This is similar to what was done for
> > ipv4 in commit 709772e6e065 ("net: Fix
On Thu, Feb 21, 2019 at 03:35:31PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.136 release.
> There are 13 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me kno
On Thu, Feb 21, 2019 at 03:35:30PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.176 release.
> There are 20 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know
On Thu, Feb 21, 2019 at 03:35:38PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.160 release.
> There are 20 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know
On 1/29/19 8:54 AM, jgli...@redhat.com wrote:
From: Jérôme Glisse
This patchset improves the HMM driver API and add support for hugetlbfs
and DAX mirroring. The improvement motivation was to make the ODP to HMM
conversion easier [1]. Because we have nouveau bits schedule for 5.1 and
to avoid
On Thu, Feb 21, 2019 at 03:35:42PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.103 release.
> There are 23 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me kno
On Thu, Feb 21, 2019 at 03:35:42PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.25 release.
> There are 30 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know
On Thu, Feb 21, 2019 at 03:35:48PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.20.12 release.
> There are 32 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know
On 2/22/19 1:50 PM, David Miller wrote:
>>
>> This patch is part of the ongoing efforts to enable
>> -Wimplicit-fallthrough.
>>
>> Signed-off-by: Gustavo A. R. Silva
>
> Applied.
>
Thanks, Dave.
I wonder if you can take this one too:
https://lore.kernel.org/lkml/20190129180612.GA28650@emb
From: Yue Haibing
Date: Thu, 21 Feb 2019 22:42:01 +0800
> From: YueHaibing
>
> KASAN has found use-after-free in fixed_mdio_bus_init,
> commit 0c692d07842a ("drivers/net/phy/mdio_bus.c: call
> put_device on device_register() failure") call put_device()
> while device_register() fails,give up th
On Fri, Feb 22, 2019 at 05:04:19PM +0200, Claudiu Manoil wrote:
> Define connection bindings (external PHY connections and internal links)
> for the ENETC on-chip ethernet controllers.
>
> Signed-off-by: Claudiu Manoil
> ---
> v3 - added this patch to the set
>
> .../devicetree/bindings/net/fsl
Cosmetic patch making use of helpers dedicated to linkmodes handling.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/marvell10g.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 89920b10d75b..821ef1b2
This series adds the missing bits necessary to fully support 2.5GBaseT
in the Marvell Alaska PHYs.
The main points for that support are :
- Making use of the .get_features call, recently introduced by Heiner
and Andrew, that allows having a fully populated list of supported
modes, includin
The PHY ID corresponding to the 88X3310 is also used for other PHYs in
the same family, such as the 88E2010. Use a #define for the PHY id, that
ignores the last nibble.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/marvell10g.c | 4 ++--
include/linux/marvell_phy.h | 1 +
2 files changed
The Marvell Alaska family of PHYs supports 2.5GBaseT and 5GBaseT modes,
as defined in the 802.3bz specification.
Upon establishing a 2.5GBASET link, the PHY will reconfigure it's MII
interface to 2500BASEX.
At 5G, the PHY will reconfigure it's interface to 5GBASE-R, but this
mode isn't supported
As per 802.3bz, if bit 14 of (1.11) "PMA Extended Abilities" indicates
whether or not we should read register (1.21) "2.52/5G PMA Extended
Abilities", which contains information on the support of 2.5GBASET and
5GBASET.
After testing on several variants of PHYS of this family, it appears
that bit 1
The Alaska family of 10G PHYs has more abilities than the ones listed in
PHY_10GBIT_FULL_FEATURES, the exact list depending on the model.
Make use of the newly introduced .get_features call to build this list,
using genphy_c45_pma_read_abilities to build the list of supported
linkmodes, and adding
The PPv2 controller is able to support 2.5G speeds, allowing to use
2.5GBASET in conjunction with PHYs that use 2500BASEX as their MII
interface when using this mode.
Signed-off-by: Maxime Chevallier
Reviewed-by: Andrew Lunn
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 1 +
1 file chan
On Thu, 21 Feb 2019 13:45:56 +, wrote:
> From: Claudiu Beznea
>
> Add documentation for SAM9X60 shutdown controller.
>
> Signed-off-by: Claudiu Beznea
> ---
> Documentation/devicetree/bindings/arm/atmel-sysregs.txt | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
Reviewed-b
On Thu, 21 Feb 2019 16:46:30 +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Extend the bindings to cover the set of features found in Tegra186. Note
> that, technically, there are four more supplies connected to the XUSB
> pad controller (DVDD_PEX, DVDD_PEX_PLL, HVDD_PEX and HVDD_PEX_PLL
This patch adds support for the 88x2110 PHY, which is similar to the
already supported 88x3310 PHY without the SFP interface.
It supports 10/100/1000BASET along with 2.5GBASET, 5GBASET and 10GBASET,
with the same interface modes that are used by the 3310.
This PHY don't have the same issue as the
On February 22, 2019 2:26:35 PM PST, Peter Zijlstra
wrote:
>On Fri, Feb 22, 2019 at 07:10:34PM +0100, Thomas Gleixner wrote:
>
>> But correct :)
>
>> I agree, that a function which is doing the actual copy should be
>callable,
>> but random other functions? NO!
>
>So find the below patch -- which
On Fri, Feb 22, 2019 at 2:26 PM Peter Zijlstra wrote:
>
> So find the below patch -- which spotted fail in ptrace.c
>
> It has an AC_SAFE(func) annotation which allows marking specific
> functions as safe to call. The patch includes 2 instances which were
> required to make arch/x86 'build':
Look
On Thu, 21 Feb 2019 18:02:47 +0100, "H. Nikolaus Schaller" wrote:
> From: Linus Walleij
>
> The mounting matrix for sensors was introduced in
> commit dfc57732ad38 ("iio:core: mounting matrix support")
>
> However the device tree bindings are very terse and since this is
> a widely applicable pr
On Thu, Feb 21, 2019 at 06:17:52PM +0100, Martin Kepplinger wrote:
> struct serial_rs485 now optionally holds the rts delay values in
> microseconds. Users can set these delays in their devicetree descriptions,
> so this adds the microseconds-option with the "rs485-rts-delay-us" boolean
> property.
On Fri, Feb 22 2019 at 5:46pm -0500,
Jens Axboe wrote:
> On 2/22/19 2:10 PM, Mike Snitzer wrote:
> > On Thu, Feb 15 2018 at 4:09am -0500,
> > NeilBrown wrote:
> >
> >>
> >> If two bios are chained under the one parent (with bio_chain())
> >> it is possible that one will succeed and the other
On Fri, Feb 22, 2019 at 2:26 PM Peter Zijlstra wrote:
>
> On Fri, Feb 22, 2019 at 07:10:34PM +0100, Thomas Gleixner wrote:
>
> > But correct :)
>
> > I agree, that a function which is doing the actual copy should be callable,
> > but random other functions? NO!
>
> So find the below patch -- which
On Fri, Feb 22, 2019 at 03:16:35PM -0800, Linus Torvalds wrote:
>
> So a kernel pointer value of 0x12345678 could be a value kernel
> pointer pointing to some random kmalloc'ed kernel memory, and a user
> pointer value of 0x12345678 could be a valid _user_ pointer pointing
> to some user mapping.
Quoting Sugaya Taichi (2019-02-08 04:27:17)
> diff --git a/drivers/clk/clk-milbeaut.c b/drivers/clk/clk-milbeaut.c
> new file mode 100644
> index 000..f798939
> --- /dev/null
> +++ b/drivers/clk/clk-milbeaut.c
> @@ -0,0 +1,626 @@
[]
> +struct m10v_clk_div_fixed_data {
> + const char
On Fri, Feb 22, 2019 at 3:02 PM Jann Horn wrote:
>
> On Fri, Feb 22, 2019 at 11:39 PM Nadav Amit wrote:
> > > On Feb 22, 2019, at 2:21 PM, Nadav Amit wrote:
> > >
> > >> On Feb 22, 2019, at 2:17 PM, Jann Horn wrote:
> > >>
> > >> On Fri, Feb 22, 2019 at 11:08 PM Nadav Amit wrote:
> > On F
Following patches will change the way we communicate setting a port's
attribute and use notifiers towards that goal.
Prepare DSA to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_SET from both atomic and process context and use a
small helper to translate the event notifier into s
Following patches will change the way we communicate setting a port's
attribute and use notifiers towards that goal.
Prepare rocker to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_SET from both atomic and process context and use a
small helper to translate the event notifier int
In preparation for allowing switchdev enabled drivers to veto specific
attribute settings from within the context of the caller, introduce a
new switchdev notifier type for port attributes.
Suggested-by: Ido Schimmel
Signed-off-by: Florian Fainelli
---
include/net/switchdev.h | 27 +++
Now that we have converted all possible callers to using a switchdev
notifier for attributes we do not have a need for implementing
switchdev_ops anymore, and this can be removed from all drivers the
net_device structure.
Signed-off-by: Florian Fainelli
---
.../net/ethernet/mellanox/mlxsw/spectr
Drop switchdev_ops.switchdev_port_attr_set. Drop the uses of this field
from all clients, which were migrated to use switchdev notification in
the previous patches.
Add a new function switchdev_port_attr_notify() that sends the switchdev
notifications SWITCHDEV_PORT_ATTR_SET and takes care, depend
Following patches will change the way we communicate setting a port's
attribute and use notifiers to perform those tasks.
Ocelot does not currently have an atomic notifier registered for
switchdev events, so we need to register one in order to deal with
atomic context SWITCHDEV_PORT_ATTR_SET event
Following patches will change the way we communicate setting a port's
attribute and use a notifier to perform those tasks.
Prepare mlxsw to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_SET and utilize the switchdev_handle_port_attr_set()
to handle stacking of devices.
Signed-of
Following patches will change the way we communicate setting a port's
attribute and use a blocking notifier to perform those tasks.
Prepare ethsw to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_SET and simply translate that into the existing
swdev_port_attr_set() call.
Signed-o
In preparation for allowing switchdev enabled drivers to veto specific
attribute settings from within the context of the caller, introduce a
new switchdev notifier type for port attributes.
Suggested-by: Ido Schimmel
Signed-off-by: Florian Fainelli
---
include/net/switchdev.h | 27 +++
Hi all,
This patch series completes the removal of the switchdev_ops by
converting switchdev_port_attr_set() to use either the blocking
(process) or non-blocking (atomic) notifier since we typically need to
deal with both depending on where in the bridge code we get called from.
This was tested w
On Mon, Feb 4, 2019 at 1:47 PM Nitesh Narayan Lal wrote:
>
> The following patch-set proposes an efficient mechanism for handing freed
> memory between the guest and the host. It enables the guests with no page
> cache to rapidly free and reclaims memory to and from the host respectively.
>
> Be
On Sat, 23 Feb 2019 00:15:38 +0100, Jann Horn said:
> On Fri, Feb 22, 2019 at 11:42 PM wrote:
> > Is there a reason this commit appeared in next-20190221 but did not seem to
> > be
> > in next-20190222 (confirmed via 'git tag --contains')?y ast@, he wanted to
On Fri, Feb 22, 2019 at 03:59:30PM -0800, Andy Lutomirski wrote:
> >
> > A relatively simple approach might be to teach BPF not to run kprobe
> > programs and such in contexts where current->mm isn't the active mm?
> > Maybe using nmi_uaccess_okay(), or something like that? It looks like
> > perf_c
From: Nicolas Ferre
This register read is a leftover of a previous read/modify/write. We now use
regmap_update_bits(), so we don't need it anymore.
Signed-off-by: Nicolas Ferre
Signed-off-by: Alexandre Belloni
---
drivers/clk/at91/clk-programmable.c | 3 ---
1 file changed, 3 deletions(-)
di
On Fri, Feb 22, 2019 at 3:56 PM Alexei Starovoitov
wrote:
>
> It will preserve existing bpf_probe_read() behavior on x86.
... but that's the worst possible situation.
It appears that people haven't understood that kernel and user
addresses are distinct, and may have written programs that are
fun
> On Feb 22, 2019, at 3:59 PM, Andy Lutomirski wrote:
>
> On Fri, Feb 22, 2019 at 3:02 PM Jann Horn wrote:
>> On Fri, Feb 22, 2019 at 11:39 PM Nadav Amit wrote:
On Feb 22, 2019, at 2:21 PM, Nadav Amit wrote:
> On Feb 22, 2019, at 2:17 PM, Jann Horn wrote:
>
> On Fri, F
__media_pipeline_start() does WARN_ON() when active pipe doesn't
match the input arg entity's pipe.
Replace WARN_ON with a conditional and error message that includes
names of both entities.
Signed-off-by: Shuah Khan
---
drivers/media/media-entity.c | 5 -
1 file changed, 4 insertions(+), 1
On Fri, Feb 22, 2019 at 09:28:04AM +0100, Christophe Roullier wrote:
> Add properties to support all Phy config
> PHY_MODE (MII,GMII, RMII, RGMII) and in normal, PHY wo crystal (25Mhz),
> PHY wo crystal (50Mhz), No 125Mhz from PHY config.
>
> Signed-off-by: Christophe Roullier
> ---
> Docu
On Fri, 22 Feb 2019 09:28:07 +0100, Christophe Roullier wrote:
> Need syscfg clock for MCU family in case bootloader does not
> activate it.
>
> Signed-off-by: Christophe Roullier
> ---
> Documentation/devicetree/bindings/net/stm32-dwmac.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletio
On Fri, 22 Feb 2019 15:16:15 +0200, Peter Ujfalusi wrote:
> This adds the device-tree bindings for the OSD101T2045-53TS 10.1"
> 1920x1200 panel from One Stop Displays.
>
> Signed-off-by: Peter Ujfalusi
> ---
> .../bindings/display/panel/osd,osd101t2045-53ts.txt | 11 +++
> 1 file chang
On Fri, 22 Feb 2019 15:16:17 +0200, Peter Ujfalusi wrote:
> This adds the device-tree bindings for the OSD101T2587-53TS 10.1"
> 1920x1200 panel from One Stop Displays.
>
> Note: the panel is similar to OSD101T2045-53TS, but it needs additional
> MIPI_DSI_TURN_ON_PERIPHERAL message from the host.
>
On Wed, Jan 23, 2019 at 08:41:20PM +0200, Georgi Djakov wrote:
> Hi,
>
> On 1/23/19 19:07, Bjorn Andersson wrote:
> > On Mon 21 Jan 22:33 PST 2019, Alok Chauhan wrote:
> >
> >> Add documentation for the interconnect and interconnect-names bindings
> >> for the GENI QUP as detailed by bindings/int
On Tue, Jan 22, 2019 at 11:45:38AM +0200, Matti Vaittinen wrote:
> Document bindings for regulators (3 bucks, 3 LDOs and 2 LED
> drivers) and 4 GPIO pins which can be configured for I/O or
> as interrupt sources withe configurable trigger levels.
'dt-bindings: mfd: ...' for the subject.
>
> Sign
On Fri, 25 Jan 2019 12:30:08 +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Extend the bindings to cover the set of features found in Tegra186.
>
> Signed-off-by: Thierry Reding
> ---
> .../devicetree/bindings/usb/nvidia,tegra124-xusb.txt | 4
> 1 file changed, 4 inserti
On Mon, 28 Jan 2019 09:44:47 +0100, Martin Kepplinger wrote:
> From: Martin Kepplinger
>
> The st1232 driver gains support for the ST1633 controller too; update
> the bindings doc accordingly.
>
> Signed-off-by: Martin Kepplinger
> ---
> .../bindings/input/touchscreen/sitronix-st1232.txt
On Mon, 28 Jan 2019 12:45:02 +0100, Jorge Ramirez-Ortiz wrote:
> The PMS405 supports 5 SMPS and 13 LDO regulators.
>
> Signed-off-by: Jorge Ramirez-Ortiz
> ---
> .../bindings/regulator/qcom,spmi-regulator.txt | 24
> ++
> 1 file changed, 24 insertions(+)
>
Reviewed-by:
On 02/22/2019 10:45 PM, Jakub Kicinski wrote:
> On Fri, 22 Feb 2019 12:14:57 -0800, Joe Perches wrote:
>> On Fri, 2019-02-22 at 12:01 -0800, Jakub Kicinski wrote:
>>> Hi!
>>>
>>> Seems like something funny is going on with get_maintainer.pl since XDP
>>> entry got added. We seem to have been CCed
On Fri, 2019-02-22 at 14:55 -0800, Brian Norris wrote:
> Documentation/devicetree/bindings/usb/usb-device.txt describes the
> 'usbVID,...' compatible format, where VID is hexadecimal, with leading
> zeroes suppressed. Allow it here without complaining.
[]
> diff --git a/scripts/checkpatch.pl b/scri
On Fri, Feb 22, 2019 at 4:52 PM Joe Perches wrote:
>
> On Fri, 2019-02-22 at 14:55 -0800, Brian Norris wrote:
> > Documentation/devicetree/bindings/usb/usb-device.txt describes the
> > 'usbVID,...' compatible format, where VID is hexadecimal, with leading
> > zeroes suppressed. Allow it here witho
This is 5.0-rc7 on an old Toshiba Portege laptop.
[ 51.898454] UBSAN: Undefined behaviour in
../drivers/cpuidle/governors/menu.c:229:21
[ 51.898467] signed integer overflow:
[ 51.898478] 3758096350 * 375809635
Hi,
Le jeu. 10 janv. 2019 à 11:04, Paul Cercueil a
écrit :
Adding Stephen to the discussion.
Adding Stephen to the discussion.
On Sat, Jan 5, 2019 at 6:27 PM, Uwe Kleine-König
wrote:
Hello Paul,
On Sat, Jan 05, 2019 at 06:05:38PM -0300, Paul Cercueil wrote:
On Sat, Jan 5, 2019 at 4:57 P
On 2/22/19 5:29 PM, Arnd Bergmann wrote:
> Building an arm64 allmodconfig kernel with clang results in over 140 warnings
> about overly large stack frames, the worst ones being:
>
> drivers/gpu/drm/panel/panel-sitronix-st7789v.c:196:12: error: stack frame
> size of 20224 bytes in function 'st7
User can change a node specific hugetlb count. i.e.
/sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages
the calculated value of count is a total number of huge pages. It could
be overflow when a user entering a crazy high value. If so, the total
number of huge pages could be a sm
Hi Shuah,
Thanks for your patch.
On 2019-02-22 10:45:59 -0700, Shuah Khan wrote:
> Fix misleading comment in _close()
>
> Signed-off-by: Shuah Khan
> ---
> drivers/media/usb/au0828/au0828-video.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/au0828
The pull request you sent on Fri, 22 Feb 2019 09:29:27 +0900:
> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
> tags/kbuild-fixes-v5.0-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/77dc1181d896c5c3f8e131e341993aef41e16505
Thank you!
--
The pull request you sent on Fri, 22 Feb 2019 09:17:25 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
> parisc-5.0-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8456e98e18f35f4d4376e8ff3110a3342f81ce9b
Thank you!
--
Deet-doot-dot,
701 - 800 of 856 matches
Mail list logo
