On 21-02-2019 10:42, Mark Brown wrote:
> On Thu, Feb 21, 2019 at 08:22:53AM +0800, Axel Lin wrote:
>> Olliver Schinagl 於 2019年2月21日 週四 上午6:57寫道：
>>> On February 20, 2019 5:50:13 PM GMT+01:00, Axel Lin
>>> wrote:
The AXP20X_xxx_START/END/STEPS defines make the code hard to read and
From: Bo Yu
Compiling the kernel with W=1 results in the following warning:
drivers/staging/ks7010/ks_hostif.c:465:6: warning: variable ‘mib_val_type’
set but not used [-Wunused-but-set-variable]
u16 mib_val_type;
drivers/staging/ks7010/ks_hostif.c:464:6: warning: variable ‘mib_val_size’
set
-but-set-variable]
> u16 result_code;
>
> Remove these variables.
>
> Rebase on next-20190222
>
> Cc: Greg Kroah-Hartman
> Cc: Sergio Paracuellos
> Cc: Quytelda Kahja
>
> Signed-off-by: Bo Yu
> ---
> drivers/staging/ks7010/ks_hostif.c | 6 --
> 1 fi
variable]
> u16 result_code;
>
> Remove these variables.
>
> Rebase on next-20190222
> V2: fix patch format
As Dan has just said, this two rebase and v2 stuff is not needed in
the changelog.
Please, put it under the --- cut off line.
>
> Cc: Greg Kroah-Hartman
>
on next-20190222
V2: fix patch format
Please drop it, will send V3
Thanks
Cc: Greg Kroah-Hartman
Cc: Sergio Paracuellos
Cc: Quytelda Kahja
Signed-off-by: Bo Yu
---
drivers/staging/ks7010/ks_hostif.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/staging/ks7010/ks_hostif.c
b
but not used [-Wunused-but-set-variable]
u16 mib_val_size;
drivers/staging/ks7010/ks_hostif.c:786:6: warning: variable ‘result_code’
set but not used [-Wunused-but-set-variable]
u16 result_code;
Remove these variables.
Rebase on next-20190222
V2: fix patch format
Cc: Greg Kroah
-but-set-variable]
> u16 result_code;
>
> Remove these variables.
>
> Rebase on next-20190222
^^^
Is this a v2 patch or something? Don't include this in the changelog.
Put it under the --- cut off line.
>
> Cc: Greg Kroah-Hartman
> Cc: S
Remove duplicate headers which are included twice.
Signed-off-by: Sabyasachi Gupta
Signed-off-by: Souptick Joarder
---
tools/testing/selftests/gpio/gpio-mockup-chardev.c | 1 -
tools/testing/selftests/net/udpgso.c| 1 -
On Fri, Feb 22, 2019 at 07:56:28PM +, alex_gagn...@dellteam.com wrote:
> On 2/21/19 1:36 AM, Lukas Wunner wrote:
> > On Tue, Feb 19, 2019 at 07:20:28PM -0600, Alexandru Gagniuc wrote:
> >>mutex_lock(>state_lock);
> >> + present = pciehp_card_present(ctrl);
> >> + link_active =
The protection attributes are only kept in last level tlb, so
protection changing only need invalidate last level tlb, exclude
the PWC entries.
Signed-off-by: Xuefeng Wang
---
mm/mprotect.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/mprotect.c b/mm/mprotect.c
index
variable]
> u16 result_code;
>
> Remove these variables.
>
> Rebase on next-20190222
>
> Cc: Greg Kroah-Hartman
> Cc: Sergio Paracuellos
> Cc: Quytelda Kahja
>
> Signed-off-by: Bo Yu
> ---
> drivers/staging/ks7010/ks_hostif.c | 6 --
> 1 file c
Hi Ulf,
this is just a ping, do you have any comments of this series of
patches ?
Thx!
On Fri, 2019-02-15 at 13:59 +0800, Chaotian Jing wrote:
> Change vs v1:
> do not retry CMD6 in __mmc_switch()
> do not move the reduce clock operation after switch HS
>
> Chaotian Jing (2):
> mmc:
but not used [-Wunused-but-set-variable]
u16 mib_val_size;
drivers/staging/ks7010/ks_hostif.c:786:6: warning: variable ‘result_code’
set but not used [-Wunused-but-set-variable]
u16 result_code;
Remove these variables.
Rebase on next-20190222
Cc: Greg Kroah-Hartman
Cc: Sergio
From: "Darrick J. Wong"
When we made the shmem_reserve_inode call in shmem_link conditional, we
forgot to update the declaration for ret so that it always has a known
value. Dan Carpenter pointed out this deficiency in the original patch.
Fixes: 1062af920c07 ("tmpfs: fix link accounting when a
Recently I added an RCU annotation check to rcu_assign_pointer(). All
pointers assigned to RCU protected data are to be annotated with __rcu
inorder to be able to use rcu_assign_pointer() similar to checks in
other RCU APIs.
This resulted in a sparse error: kernel//sched/cpufreq.c:41:9: sparse:
The scheduler uses RCU API in various places to access sched_domain
pointers. These cause sparse errors as below.
Many new errors show up because of an annotation check I added to
rcu_assign_pointer(). Let us annotate the pointers correctly which also
will help sparse catch any potential future
This suppresses sparse error generated due to the recently added
rcu_assign_pointer sparse check.
percpu-rwsem.c:162:9: sparse: error: incompatible types in comparison expression
exit.c:316:16: sparse: error: incompatible types in comparison expression
Signed-off-by: Joel Fernandes (Google)
---
This fixes the following sparse errors in sched/fair.c:
fair.c:6506:14: error: incompatible types in comparison expression
fair.c:8642:21: error: incompatible types in comparison expression
Using __rcu will also help sparse catch any future bugs.
Signed-off-by: Joel Fernandes (Google)
---
rtnl_register_internal() and rtnl_unregister_all tries to directly
dereference an RCU protected pointed outside RCU read side section.
While this is Ok to do since a lock is held, let us use the correct
API to avoid programmer bugs in the future.
This also fixes sparse warnings arising from not
Recently, I added an RCU annotation check in rcu_assign_pointer. This
caused a sparse error to be reported by the ixgbe driver.
Further looking, it seems the adapter->xdp_prog pointer is not annotated
with __rcu. Annonating it fixed the error, but caused a bunch of other
warnings.
This patch
These patches fix various sparse errors found as a result of the recent check
to add rcu_check_sparse() to rcu_assign_pointer(). The errors in some cases
seem to either missing API usage, or missing annotations. The annotations added
in the series can also help avoid future incorrect usages and
Regards,
Parshuram Thombare
>-Original Message-
>From: Andrew Lunn
>Sent: Saturday, February 23, 2019 3:12 AM
>To: Parshuram Raju Thombare
>Cc: nicolas.fe...@microchip.com; da...@davemloft.net;
>net...@vger.kernel.org; f.faine...@gmail.com; hkallwe...@gmail.com; linux-
>> if (macb_is_gem(bp)) {
>> -linkmode_copy(phydev->supported, PHY_GBIT_FEATURES);
>> -if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED)
>> -
> linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
>> - phydev->supported);
>> +
>> /* mask with MAC supported features */
>> -if (macb_is_gem(bp) && bp->caps &
>MACB_CAPS_GIGABIT_MODE_AVAILABLE)
>> -phy_set_max_speed(phydev, SPEED_1000);
>> -else
>> -phy_set_max_speed(phydev, SPEED_100);
>> +if (macb_is_gem(bp)) {
>> +
On 22/02/19 8:06 PM, Andrew Lunn wrote:
On Fri, Feb 22, 2019 at 04:48:18PM +0530, Himadri Pandya wrote:
Decrement the reference count on port while returning out of the
loop. Issue identified by Coccinelle.
You and Wen Yang are both fixing the same issue. Maybe you can
coordinate?
Sure.
-
On Thu, Feb 21, 2019 at 6:42 PM Jiri Olsa wrote:
>
> Adding perf_data__create_dir to create nr files inside
> struct perf_data path directory:
> int perf_data__create_dir(struct perf_data *data, int nr);
>
> and function to close that data:
> void perf_data__close_dir(struct perf_data *data);
On Fri, Feb 22, 2019 at 1:07 AM Jonas Rabenstein
wrote:
>
> Hi,
> This patchset supersedes my previous attempt to add inline symbols to
> callchain of perf-script [1] by a more generic attempt to not hook in
> the output stage but directly into the callchain generation. By a matter
> of fact this
On Fri, 22 Feb 2019 15:56:20 -0800
Alexei Starovoitov wrote:
> 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
There are callers which print many lines in
$header_text_line
$body_text_lines
$trailer_text_line
format, and some of them print $body_text_lines part from atomic context
(or context where spending too much time can result in a lockup). SysRq-t
(which might call printk() on all threads
Hello,
On Fri, Feb 22, 2019 at 1:07 AM Jonas Rabenstein
wrote:
>
> Use map__inlines to resolve inlined functions for every entry with
> an symbol that should be added to a callchain.
>
> Signed-off-by: Jonas Rabenstein
> ---
> tools/perf/util/machine.c | 115
task A:task B:
hci_uart_set_proto flush_to_ldisc
- p->open(hu) -> h5_open //alloc h5 - receive_buf
- set_bit HCI_UART_PROTO_READY - tty_port_default_receive_buf
- hci_uart_register_dev - tty_ldisc_receive_buf
Hi João,
On 2/13/19 7:46 PM, Marcos Paulo de Souza wrote:
Hello João,
On 2/12/19 2:30 PM, João Paulo Rechi Vita wrote:
On Mon, Feb 11, 2019 at 6:31 PM Marcos Paulo de Souza
wrote:
Hello João,
On 2/11/19 5:14 PM, João Paulo Rechi Vita wrote:
Hello Marcos,
On Sun, Feb 10, 2019 at 5:05 PM
On Fri, 22 Feb 2019 09:43:14 -0800
Linus Torvalds wrote:
> On Fri, Feb 22, 2019 at 12:35 AM Masami Hiramatsu wrote:
> >
> > Or, can we do this?
> >
> > long __probe_user_read(void *dst, const void *src, size_t size)
> > {
>
> Add a
>
> if (!access_ok(src, size))
> ret
Add new resources as below according to latest system
controller firmware for new features:
IMX_SC_R_PERF
IMX_SC_R_OCRAM
IMX_SC_R_DMA_5_CH0
IMX_SC_R_DMA_5_CH1
IMX_SC_R_DMA_5_CH2
IMX_SC_R_DMA_5_CH3
IMX_SC_R_ATTESTATION
Signed-off-by: Anson
i.MX8MQ has clock gate for each GPIO bank, add clock info
to GPIO node for clock management.
Signed-off-by: Anson Huang
---
No change since V1, just drop 1 patch from V1 patch series.
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git
i.MX8MQ has clock gate for each GPIO bank, add them
into clock tree for GPIO driver to manage.
Signed-off-by: Anson Huang
---
No change since V1, just drop 1 patch from V1 patch series.
---
drivers/clk/imx/clk-imx8mq.c | 5 +
include/dt-bindings/clock/imx8mq-clock.h | 8 +++-
Removes below resources which were defined during
pre-silicon phase and the real silicons do NOT have
them, they have never been used, latest system
controller firmware also removed them:
IMX_SC_R_DC_0_CAPTURE0
IMX_SC_R_DC_0_CAPTURE1
IMX_SC_R_DC_0_INTEGRAL0
On i.MX8MQ platform, clock driver uses platform driver
model and it is probed after GPIO driver, so when GPIO
driver fails to get clock, it should check the error type
to decide whether to return defer probe or just ignore
the clock operation.
Fixes: 2808801aab8a ("gpio: mxc: add clock
Hi,
On Fri, Feb 22, 2019 at 1:29 AM Jiri Olsa wrote:
>
> On Thu, Feb 21, 2019 at 02:53:20PM +0100, Jonas Rabenstein wrote:
> > On Thu, Feb 21, 2019 at 01:39:09PM +0100, Jiri Olsa wrote:
> > > On Thu, Feb 21, 2019 at 01:23:06PM +0100, Jonas Rabenstein wrote:
> > > > In __hists__add_entry the
Hi,
Le jeu. 24 janv. 2019 à 19:53, Paul Cercueil a
écrit :
Le jeu. 24 janv. 2019 à 19:46, Stephen Boyd a
écrit :
Quoting Paul Cercueil (2019-01-24 12:46:28)
Le jeu. 24 janv. 2019 à 16:28, Stephen Boyd a
écrit :
> Quoting Guenter Roeck (2019-01-23 10:01:55)
>> On Wed, Jan 23,
Best Regards!
Anson Huang
> -Original Message-
> From: Anson Huang
> Sent: 2019年2月23日 11:04
> To: Lucas Stach ; robh...@kernel.org;
> mark.rutl...@arm.com; shawn...@kernel.org; s.ha...@pengutronix.de;
> ker...@pengutronix.de; feste...@gmail.com; mturque...@baylibre.com;
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
The following changes since commit 8834f5600cf3c8db365e18a3d5cac2c2780c81e5:
Linux 5.0-rc5 (2019-02-03 13:48:04 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git
I'm also worried about the other two versions, though:
memory-barriers.txt#1724:
1724 (*) The compiler is within its rights to invent stores to a variable,
i.e. the compiler is free to decide __bio_chain_endio looks like this:
static struct bio *__bio_chain_endio(struct bio *bio)
{
struct
Four small fixes: three in drivers and one in the core. The core fix
is also minor in scope since the bug it fixes is only known to affect
systems using SCSI reservations. Of the driver bugs, the libsas one is
the most major because it can lead to multiple disks on the same
expander not being
Hi, Lucas
Best Regards!
Anson Huang
> -Original Message-
> From: Lucas Stach [mailto:l.st...@pengutronix.de]
> Sent: 2019年2月22日 18:55
> To: Anson Huang ; robh...@kernel.org;
> mark.rutl...@arm.com; shawn...@kernel.org; s.ha...@pengutronix.de;
> ker...@pengutronix.de; feste...@gmail.com;
On Fri, 22 Feb 2019 18:28:53 -0800
Alexei Starovoitov wrote:
> First we introduce bpf_probe_kernel_read and bpf_probe_user_read and
> introduce clang/gcc tooling to catch the mistakes.
> Going over this 400+ places and manually grepping kernel sources
> for __user keyword is not a great proposal
On Fri, Feb 22 2019 at 9:02pm -0500,
John Dorminy wrote:
> I am perhaps not understanding the intricacies here, or not seeing a
> barrier protecting it, so forgive me if I'm off base. I think reading
> parent->bi_status here is unsafe.
> Consider the following sequence of events on two threads.
On Fri, Feb 22, 2019 at 6:29 PM Alexei Starovoitov
wrote:
>
> imo this kernel release should finish as-is and in the next cycle we can
> change probe_kernel_read() to reject user address [..]
Absolutely. Nothing is going to change right now for 5.0, which is imminent.
It's really a "long-term
Hi, Stehpen
Best Regards!
Anson Huang
> -Original Message-
> From: Stephen Boyd [mailto:sb...@kernel.org]
> Sent: 2019年2月23日 3:08
> To: devicet...@vger.kernel.org; feste...@gmail.com;
> ker...@pengutronix.de; linux-arm-ker...@lists.infradead.org; linux-
> c...@vger.kernel.org;
On Fri, Feb 22, 2019 at 04:08:59PM -0800, Linus Torvalds wrote:
> 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
Documentation/devicetree/bindings/usb/usb-device.txt describes the
'usbVID,...' compatible format, where VID is lower-case hexadecimal,
with leading zeroes suppressed. Allow it here without complaining about
lack of documentation (we don't need a new entry for every ID).
PCI has a similar format
The pull request you sent on Fri, 22 Feb 2019 10:42:40 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-5.0
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ef4edb3ed830cbbb443de9906b8cf16dc0653a74
Thank you!
--
Deet-doot-dot, I am a bot.
I am perhaps not understanding the intricacies here, or not seeing a
barrier protecting it, so forgive me if I'm off base. I think reading
parent->bi_status here is unsafe.
Consider the following sequence of events on two threads.
Thread 0 Thread 1
In
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) +
The pull request you sent on Fri, 22 Feb 2019 23:23:33 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/armsoc-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9053d2db8b04a468ce1ab92693b940b046ea392c
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Fri, 22 Feb 2019 09:42:38 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/
> tags/arc-5.0-final
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2cc63b39003913fdf564cde5c646ac8f174e3ac7
Thank you!
--
Deet-doot-dot,
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!
--
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!
--
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
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
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
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
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 *
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
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
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 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(+)
>
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 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
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.
>
>
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
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 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
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
__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(+),
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
> ---
>
> 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,
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
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(-)
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
> >
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 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.
>
>
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
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,
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
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.
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.
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
---
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
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
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
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
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 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.
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 --
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 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
>
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
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':
1 - 100 of 856 matches
Mail list logo
