Hi Stephen,
I dropped the patch from my tree.
Thanks
-- Daniel
On 03/06/2019 04:13, Stephen Rothwell wrote:
> Hi Daniel,
>
> After merging the clockevents tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/clocksource/timer-atmel-tcb.c: In function
Hi Edubezval, Rui,
Any further comments?
BR,
Andy
> -Original Message-
> From: Yuantian Tang
> Sent: 2019年5月15日 17:37
> To: rui.zh...@intel.com; edubez...@gmail.com
> Cc: robh...@kernel.org; daniel.lezc...@linaro.org; mark.rutl...@arm.com;
> linux...@vger.kernel.org;
On Mon, Jun 03, 2019 at 10:17:28AM -0700, Guenter Roeck wrote:
> On Mon, Jun 03, 2019 at 11:08:53AM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.1.7 release.
> > There are 40 patches in this series, all will be posted as a response
> > to this one.
Hi Anders,
thanks for your patch. As mentioned by Mark I already applied this fix
from Julien Thierry.
-- Daniel
On 03/06/2019 11:23, Marc Zyngier wrote:
> Hi Anders,
>
>
> On 03/06/2019 10:12, Anders Roxell wrote:
>> When CONFIG_FUNCTION_GRAPH_TRACER is enabled we end up in this circular
On Tue, Jun 04, 2019 at 01:03:21AM +0530, Naresh Kamboju wrote:
> On Mon, 3 Jun 2019 at 14:44, Greg Kroah-Hartman
> wrote:
> >
> > This is the start of the stable review cycle for the 5.1.7 release.
> > There are 40 patches in this series, all will be posted as a response
> > to this one. If
On Mon, Jun 03, 2019 at 07:34:09PM +0100, Jon Hunter wrote:
>
> On 03/06/2019 10:08, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.1.7 release.
> > There are 40 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Mon, Jun 03, 2019 at 05:31:48PM -0600, shuah wrote:
> On 6/3/19 3:08 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.1.7 release.
> > There are 40 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with
On Mon, Jun 03, 2019 at 11:28:23AM -0700, Kevin Hilman wrote:
> "kernelci.org bot" writes:
>
> > stable-rc/linux-5.1.y boot: 132 boots: 1 failed, 131 passed
> > (v5.1.6-41-ge674455b9242)
> >
> > Full Boot Summary:
> >
Hello Mao,
On Tue, Jun 4, 2019 at 10:25 AM Mao Han wrote:
>
> This patch change the csky pmu initialization from arch init to
> device init. The pmu can be configued with information from
> device tree(pmu device name, irq number and etc.).
>
> Signed-off-by: Mao Han
> Cc: Guo Ren
> ---
>
On Mon, 3 Jun 2019 13:56:58 -0500
Parav Pandit wrote:
> In following sequences, child devices created while removing mdev parent
> device can be left out, or it may lead to race of removing half
> initialized child mdev devices.
>
> issue-1:
>
>cpu-0
On Mon, 03 Jun 2019, Mark Brown wrote:
> On Mon, Jun 03, 2019 at 11:33:31AM -0700, Gwendal Grignou wrote:
> > The interface between CrosEC embedded controller and the host,
> > described by cros_ec_commands.h, as diverged from what the embedded
> > controller really support.
>
> I'm not clear
On Mon, Jun 03, 2019 at 09:29:44PM +0800, Peter Xu wrote:
> get_target_base() in the timer code is not using the "base" parameter
> at all. My gut feeling is that instead of removing that extra
> parameter, what we really want to do is "return the old base if it
> does not suite for a new one".
Reviewed-by: Guo Ren
On Tue, Jun 4, 2019 at 10:25 AM Mao Han wrote:
>
> This patch adds the documentation to describe that how to add pmu node in
> dts.
>
> Signed-off-by: Mao Han
> Cc: Rob Herring
> Cc: Guo Ren
> ---
> Documentation/devicetree/bindings/csky/pmu.txt | 38
>
Command
# perf test -Fv 6
fails with error
running test 100 'kvm-s390:kvm_s390_create_vm' failed to parse
event 'kvm-s390:kvm_s390_create_vm', err -1, str 'unknown tracepoint'
event syntax error: 'kvm-s390:kvm_s390_create_vm'
\___ unknown tracepoint
when
Hi Mao,
On Tue, Jun 4, 2019 at 10:25 AM Mao Han wrote:
>
> The csky pmu counter may have different io width. When the counter is
> smaller then 64 bits and counter value is smaller than the old value, it
> will result to a extremely large delta value. So the sampled value should
> be extend to
On Tue, Jun 04, 2019 at 12:15:46PM +0800, Kefeng Wang wrote:
> If driver_sysfs_add() fails, kernel shows following message,
>
> really_probe: driver_sysfs_add(portman.0) failed
> ppdev: probe of portman.0 failed with error 0
>
> It's better to show the error number like other probe_failed
On Tue, 2019-06-04 at 10:45 +0800, Aaron Ma wrote:
> Hi Christopher:
>
> Have got time to review these 2 patches?
> Users reported it works fine since I sent out this patch.
Hi Aaron,
I've been poking around with this off and on. Unfortunately, more off
than on :-( but here's my current take:
Hello,
syzbot found the following crash on:
HEAD commit:c1e9e01d Merge git://git.kernel.org/pub/scm/linux/kernel/g..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1319e05aa0
kernel config: https://syzkaller.appspot.com/x/.config?x=b7b54c66298f8420
Hello,
syzbot found the following crash on:
HEAD commit:9221dced Merge tag 'for-linus-20190601' of git://git.kerne..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=114cdc0ea0
kernel config: https://syzkaller.appspot.com/x/.config?x=1fa7e451a5cac069
Hello,
syzbot found the following crash on:
HEAD commit:b33bc2b8 nexthop: Add entry to MAINTAINERS
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1383c9baa0
kernel config: https://syzkaller.appspot.com/x/.config?x=1004db091673bbaf
dashboard link:
Hello,
syzbot found the following crash on:
HEAD commit:58e8b370 Merge branch 'net-phy-dp83867-add-some-fixes'
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=17bb8b9aa0
kernel config: https://syzkaller.appspot.com/x/.config?x=fc045131472947d7
dashboard
Hello,
syzbot found the following crash on:
HEAD commit:0462eaac Merge git://git.kernel.org/pub/scm/linux/kernel/g..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12c82772a0
kernel config: https://syzkaller.appspot.com/x/.config?x=b7b54c66298f8420
Hi Hillf,
On Tue, Jun 04, 2019 at 12:20:47PM +0800, Hillf Danton wrote:
>
> Hi Minchan
>
> On Mon, 3 Jun 2019 13:37:27 +0800 Minchan Kim wrote:
> > @@ -1181,10 +1179,17 @@ static ICE_noinline int unmap_and_move(new_page_t
> > get_new_page,
> > return -ENOMEM;
> >
> > if
On Mon, May 13, 2019 at 6:55 AM Oscar Salvador wrote:
>
> On Mon, May 06, 2019 at 04:40:14PM -0700, Dan Williams wrote:
> >
> > +void subsection_mask_set(unsigned long *map, unsigned long pfn,
> > + unsigned long nr_pages)
> > +{
> > + int idx = subsection_map_index(pfn);
> > +
On 06/04/2019 01:30 AM, Eric Hankland wrote:
On Sat, Jun 1, 2019 at 3:50 AM Wei Wang wrote:
My question is that have we proved that this indirect info leakage
indeed happens?
The spec states that the counter will count the related events generated by
the logical CPU with AnyThread=0. I would
perf_event_open() limits the sample_period to 63 bits. See
commit 0819b2e30ccb ("perf: Limit perf_event_attr::sample_period
to 63 bits"). Make ioctl() consistent with it.
Also on powerpc, negative sample_period could cause a recursive
PMIs leading to a hang (reported when running perf-fuzzer).
On Mon, Jun 03, 2019 at 09:16:07AM +0200, Michal Hocko wrote:
> On Fri 31-05-19 23:34:07, Minchan Kim wrote:
> > On Fri, May 31, 2019 at 04:03:32PM +0200, Michal Hocko wrote:
> > > On Fri 31-05-19 22:39:04, Minchan Kim wrote:
> > > > On Fri, May 31, 2019 at 10:47:52AM +0200, Michal Hocko wrote:
>
From: Chen-Yu Tsai
Hi everyone,
While bringing up my Pine H64, I encountered an interrupt storm from the
pcf8563 RTC. The RTC chip's interrupt line is shared with the PMIC, and
was not properly added to the device tree. Also, the driver was using an
trigger method incompatible with the PMIC,
From: Chen-Yu Tsai
The PCF8563 datasheet says the interrupt line is active low and stays
active until the events are cleared, i.e. a level trigger interrupt.
Fix the flags used to request the interrupt.
Fixes: ede3e9d47cca ("drivers/rtc/rtc-pcf8563.c: add alarm support")
Signed-off-by: Chen-Yu
From: Chen-Yu Tsai
The external PCF8563 RTC chip's interrupt line is connected to the NMI
line on the SoC.
Add the interrupt line to the device tree.
Fixes: 17ebc33afc35 ("arm64: allwinner: h6: add PCF8563 RTC on Pine H64 board")
Signed-off-by: Chen-Yu Tsai
---
From: Chen-Yu Tsai
Besides the alarm, the PCF8563 also has a timer triggered interrupt.
In cases where the previous system left the timer and interrupts on,
or somehow the bits got enabled, the interrupt would keep triggering
as the kernel doesn't know about it.
Clear both the alarm and timer
This patch removed following unused variables from struct _adapter
IsrContent, xmitThread, evtThread, recvThread
Signed-off-by: Deepak Mishra
---
drivers/staging/rtl8712/drv_types.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/rtl8712/drv_types.h
In process of cleaning up rtl8712 struct _adapter in drv_types.h I have
tried to remove some unused variables and redundant lines of code
associated with those variables. I have also fixed some CamelCase
reported by checkpatch.pl
There are some other code like spinning on a random variable
This patch renames CamelCase EepromAddressSizefrom to eeprom_address_size in
struct _adapter and in related files drv_types.h, rtl871x_eeprom.c, usb_intf.c
CHECK: Avoid CamelCase:
This patch removed unused variable ImrContent from struct _adapter and
struct pwrctrl_priv and redundant lines from
This patch renames CamelCase variable wkFilterRxFF0 to wk_filter_rx_ff0
in drv_types.h and related files rtl871x_xmit.c and xmit_linux.c as
reported by checkpatch.pl
This patch renames CamelCase variable lockRxFF0Filter to lock_rx_ff0_filter
in drv_types.h and related files usb_intf.c and
This patch renames CamelCase cmdThread to cmd_thread in struct _adapter and
related
files drv_types.h,os_intfs.c
CHECK: Avoid CamelCase:
Signed-off-by: Deepak Mishra
---
drivers/staging/rtl8712/drv_types.h | 2 +-
drivers/staging/rtl8712/os_intfs.c | 6 +++---
2 files changed, 4
On 02/06/19 10:44 PM, Greg KH wrote:
On Sun, Jun 02, 2019 at 03:55:37PM +0530, Deepak Mishra wrote:
This patch fixes CamelCase blnEnableRxFF0Filter by renaming it
to enable_rx_ff0_filter in drv_types.h and related files rtl871x_cmd.c
xmit_linux.c
It was reported by checkpatch.pl
This fix
On Fri, May 3, 2019 at 5:56 AM Oscar Salvador wrote:
>
> On Wed, May 01, 2019 at 10:56:10PM -0700, Dan Williams wrote:
> > The libnvdimm sub-system has suffered a series of hacks and broken
> > workarounds for the memory-hotplug implementation's awkward
> > section-aligned (128MB) granularity.
If driver_sysfs_add() fails, kernel shows following message,
really_probe: driver_sysfs_add(portman.0) failed
ppdev: probe of portman.0 failed with error 0
It's better to show the error number like other probe_failed path.
Signed-off-by: Kefeng Wang
---
drivers/base/dd.c | 3 ++-
1 file
Hi Rong Chen,
Thanks for your test & report!
On Tue, Jun 04, 2019 at 10:09:56AM +0800, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 47cdee29ef9d94e485eb08f962c74943023a5271 ("block: move blk_exit_queue
> into __blk_release_queue")
>
On 03-06-19, 12:55, Markus Mayer wrote:
> On Wed, 29 May 2019 at 10:02, Florian Fainelli wrote:
> >
> > On 5/27/19 3:51 AM, Rafael J. Wysocki wrote:
> > > On Wednesday, May 22, 2019 8:45:45 PM CEST Florian Fainelli wrote:
> > >> Hi Rafael, Viresh,
> > >>
> > >> These patch series contains two
There's some NICs, such as hinic, with NETIF_F_IP_CSUM and NETIF_F_TSO
on but NETIF_F_HW_CSUM off. And ipvlan device features will be
NETIF_F_TSO on with NETIF_F_IP_CSUM and NETIF_F_IP_CSUM both off as
IPVLAN_FEATURES only care about NETIF_F_HW_CSUM. So TSO will be
disabled in netdev_fix_features.
On Mon, Jun 03, 2019 at 04:39:11PM -0400, Johannes Weiner wrote:
> On Mon, Jun 03, 2019 at 02:36:55PM +0900, Minchan Kim wrote:
> > When a process expects no accesses to a certain memory range
> > for a long time, it could hint kernel that the pages can be
> > reclaimed instantly but data should
On Mon, Jun 3, 2019 at 9:43 PM David Laight wrote:
>
> From: Masahiro Yamada
> > Sent: 03 June 2019 12:45
> > On Mon, Jun 3, 2019 at 8:16 PM David Laight wrote:
> > >
> > > From: Masahiro Yamada
> > > > Sent: 03 June 2019 11:49
> > > >
> > > > To print the pathname that will be used by shell in
On Mon, Jun 3, 2019 at 10:09 PM David Laight wrote:
>
> From: Masahiro Yamada
> > Sent: 03 June 2019 12:38
> > Hi David,
> >
> > On Mon, Jun 3, 2019 at 8:14 PM David Laight wrote:
> > >
> > > From: Masahiro Yamada
> > > > Sent: 03 June 2019 11:49
> > > >
> > > > To print the pathname that will
On Tue, 4 Jun 2019 at 11:03, Yuyang Du wrote:
>
> Hi Waiman,
>
> On Tue, 21 May 2019 at 05:01, Waiman Long wrote:
> >
> > Because of writer lock stealing, it is possible that a constant
> > stream of incoming writers will cause a waiting writer or reader to
> > wait indefinitely leading to lock
On 2019/5/29 上午 12:11, Arend Van Spriel wrote:
> On May 28, 2019 6:09:21 PM Arend Van Spriel
> wrote:
>
>> On May 28, 2019 5:52:10 PM Doug Anderson wrote:
>>
>>> Hi,
>>>
>>> On Tue, May 28, 2019 at 5:18 AM Kalle Valo wrote:
Douglas Anderson wrote:
> In commit
On Tue, 2019-06-04 at 02:43 +0200, Daniel Borkmann wrote:
> On 06/04/2019 01:54 AM, Alexei Starovoitov wrote:
> > On Mon, Jun 3, 2019 at 4:48 PM Daniel Borkmann wrote:
> > > On 06/04/2019 01:27 AM, Alexei Starovoitov wrote:
> > > > On Mon, Jun 3, 2019 at 3:59 PM Matt Mullins wrote:
> > > > >
>
Hi all,
On Tue, 4 Jun 2019 10:13:56 +0800 kernel test robot wrote:
>
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 728e0fbf263e3ed359c10cb13623390564102881 ("mm/vmalloc.c: get rid of
> one single unlink_va() when merge")
>
Hi Brian,
> >netif_rx_ni+0xe8/0x120
> >mwifiex_recv_packet+0xfc/0x10c [mwifiex]
> >mwifiex_process_rx_packet+0x1d4/0x238 [mwifiex]
> >mwifiex_11n_dispatch_pkt+0x190/0x1ac [mwifiex]
> >mwifiex_11n_rx_reorder_pkt+0x28c/0x354 [mwifiex]
>
> TL;DR: the problem was right here ^^^
>
Hi Waiman,
On Tue, 21 May 2019 at 05:01, Waiman Long wrote:
>
> Because of writer lock stealing, it is possible that a constant
> stream of incoming writers will cause a waiting writer or reader to
> wait indefinitely leading to lock starvation.
>
> This patch implements a lock handoff mechanism
Thermal Monitor Unit v2 is introduced on new Layscape SoC.
Compared to v1, TMUv2 has a little different register layout
and digital output is fairly linear.
Signed-off-by: Yuantian Tang
---
drivers/thermal/qoriq_thermal.c | 122 +---
1 file changed, 98 insertions(+),
On 25-04-19, 15:07, Viresh Kumar wrote:
> We target for an idle CPU in select_idle_sibling() to run the next task,
> but in case we don't find idle CPUs it is better to pick a CPU which
> will run the task the soonest, for performance reason. A CPU which isn't
> idle but has only SCHED_IDLE
Hi Christopher:
Have got time to review these 2 patches?
Users reported it works fine since I sent out this patch.
Thanks,
Aaron
On 4/3/19 9:58 PM, Aaron Ma wrote:
> Sure, take your time, if you have any questions let me know please.
>
> Thanks,
> Aaron
Hi Ulf,
On Mon, 3 Jun 2019 at 21:34, Ulf Hansson wrote:
>
> On Mon, 20 May 2019 at 12:12, Baolin Wang wrote:
> >
> > For some Spreadtrum platforms like SC9860 platform, we should enable another
> > gate clock '2x_enable' to make the SD host controller work well. Thus add
> > documentation for
On Mon, 2019-06-03 at 11:40 +, Jose Abreu wrote:
> From: Biao Huang
>
> > the default value of tx-frames is 25, it's too late when
> > passing tstamp to stack, then the ptp4l will fail:
> >
> > ptp4l -i eth0 -f gPTP.cfg -m
> > ptp4l: selected /dev/ptp0 as PTP clock
> > ptp4l: port 1:
From: Guo Ren
CK810 pmu only support event with index 0-8 and 0xd; CK860 only
support event 1~4, 0xa~0x1b. So do not register unsupport event
to hardware cache event, which may leader to unknown behavior.
Signed-off-by: Guo Ren
Signed-off-by: Mao Han
Cc: Guo Ren
Cc:
csky_pmu_event_init is called several times during the perf record
initialzation. After configure the event counter in either kernel
space or user space, csky_pmu_event_init is called twice with no
attr specified. Configuration will be overwritten with sampling in
both kernel space and user space.
The csky pmu counter may have different io width. When the counter is
smaller then 64 bits and counter value is smaller than the old value, it
will result to a extremely large delta value. So the sampled value should
be extend to 64 bits to avoid this, the extension bits base on the
count-width
This patch adds the documentation to describe that how to add pmu node in
dts.
Signed-off-by: Mao Han
Cc: Rob Herring
Cc: Guo Ren
---
Documentation/devicetree/bindings/csky/pmu.txt | 38 ++
1 file changed, 38 insertions(+)
create mode 100644
This patch add interrupt request and handler for csky pmu.
perf can record on hardware event with this patch applied.
Signed-off-by: Mao Han
Cc: Guo Ren
---
arch/csky/kernel/perf_event.c | 292 +++---
1 file changed, 276 insertions(+), 16 deletions(-)
diff
This patch set add hardware sampling support for csky-pmu, and
also add some properties to pmu node definition. perf can record
on hardware event with this patch applied.
Cc: Guo Ren
Changes since v3:
- change reg-io-width to count-width
- use macro sign_extend64
- update commit log
This patch change the csky pmu initialization from arch init to
device init. The pmu can be configued with information from
device tree(pmu device name, irq number and etc.).
Signed-off-by: Mao Han
Cc: Guo Ren
---
arch/csky/kernel/perf_event.c | 58 ++-
--
Dear Beneficiary,
The is to bring to your notice that the Department of Treasury Office
in Nigeria in affiliation with the Federal Government of Nigeria,and
the Office of Foreign Assets Control here in Nigeria has been
authorized in their sanction programs to compensate 1,000 scam victims
who
Hi Adrian,
On Mon, 3 Jun 2019 at 21:03, Adrian Hunter wrote:
>
> On 20/05/19 1:12 PM, Baolin Wang wrote:
> > Set the PHY DLL delay for each timing mode, which is used to sample the
> > clock
> > accurately and make the clock more stable.
> >
> > Signed-off-by: Baolin Wang
>
> One comment,
On 2019/6/4 2:45, Krzysztof Kozlowski wrote:
> On Sun, 12 May 2019 at 13:51, YueHaibing wrote:
>>
>> Fix gcc warnings:
>>
>> arch/arm/mm/init.c: In function 'mem_init':
>> arch/arm/mm/init.c:456:13: warning: unused variable 'itcm_end'
>> [-Wunused-variable]
>> extern u32 itcm_end;
>>
From: Anson Huang
This patch adds i.MX8MN clock driver support.
Signed-off-by: Anson Huang
---
Changes since V2:
- use platform driver model for this clock driver;
- add "const" to clock mux arrays.
---
drivers/clk/imx/Kconfig | 6 +
drivers/clk/imx/Makefile | 1 +
From: Anson Huang
Add the clock binding doc for i.MX8MN.
Signed-off-by: Anson Huang
---
No changes.
---
.../devicetree/bindings/clock/imx8mn-clock.txt | 29 +++
include/dt-bindings/clock/imx8mn-clock.h | 215 +
2 files changed, 244 insertions(+)
create mode
From: Anson Huang
1416X/1443X PLL are used on i.MX8MM and i.MX8MN and maybe
other i.MX8M series SoC later, the macro definitions of
these PLLs' initialization should be common for usage.
Signed-off-by: Anson Huang
---
New patch.
---
drivers/clk/imx/clk-imx8mm.c | 17 -
From: Anson Huang
Enable CONFIG_CLK_IMX8MN to support i.MX8MN clock driver.
Signed-off-by: Anson Huang
---
Changes since V2:
- follow alphabet sequence.
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig
On Mon, Jun 03, 2019 at 11:30:54AM -0700, Xing, Cedric wrote:
> > From: Christopherson, Sean J
> > Sent: Monday, June 03, 2019 10:16 AM
> >
> > On Sun, Jun 02, 2019 at 12:29:35AM -0700, Xing, Cedric wrote:
> > > Hi Sean,
> > >
> > > Generally I agree with your direction but think ALLOW_* flags
Hi Linus,
On 19. 5. 31. 오전 3:39, Linus Walleij wrote:
> The only thing that makes sense is to request a falling edge interrupt
> if the line is active low and a rising edge interrupt if the line is
> active high, so just do that and get rid of the assignment from
> platform data. The GPIO
On 6/3/19 9:02 AM, Suwan Kim wrote:
vhci_send_cmd_unlink() declears kvec array of size 3 but it actually
uses just one element of the array. So, remove kvec array and replace
it with single kvec variable.
Signed-off-by: Suwan Kim
---
drivers/usb/usbip/vhci_tx.c | 12 +---
1 file
On Mon, Jun 3, 2019 at 4:01 PM Chuanjia Liu wrote:
>
> On Fri, 2019-05-31 at 10:17 -0700, Evan Green wrote:
> > On Fri, May 31, 2019 at 1:06 AM Chuanjia Liu
> > wrote:
> > >
> > > On Thu, 2019-05-30 at 10:12 -0700, Evan Green wrote:
> > > > On Wed, May 15, 2019 at 1:05 AM Nicolas Boichat
> >
On Mon, Jun 3, 2019 at 5:44 PM Daniel Borkmann wrote:
>
> On 06/04/2019 01:54 AM, Alexei Starovoitov wrote:
> > On Mon, Jun 3, 2019 at 4:48 PM Daniel Borkmann wrote:
> >> On 06/04/2019 01:27 AM, Alexei Starovoitov wrote:
> >>> On Mon, Jun 3, 2019 at 3:59 PM Matt Mullins wrote:
>
> If
On Mon, Jun 03, 2019 at 04:48:47PM -0700, Xing, Cedric wrote:
> > How about this for the intermediate patch:
> >
> > struct sgx_enclave_add_region {
> > __u64 addr;
> > __u64 src;
> > __u64 size;
> > __u64 secinfo;
> > __u16
Hi all,
Today's linux-next merge of the nand tree got a conflict in:
Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
between commit:
a5f2246fb913 ("dt: bindings: mtd: replace references to nand.txt with
nand-controller.yaml")
from Linus' tree and commit:
33cc5bd0b87a
On Mon, Jun 03, 2019 at 04:45:45PM -0700, Xing, Cedric wrote:
> > From: Christopherson, Sean J
> > Sent: Monday, June 03, 2019 1:40 PM
> >
> > On Mon, Jun 03, 2019 at 01:08:04PM -0700, Sean Christopherson wrote:
> > > On Sun, Jun 02, 2019 at 11:26:09PM -0700, Xing, Cedric wrote:
> > > > > From:
Hi Jones,
> > +static int rpc_mfd_probe(struct platform_device *pdev)
>
> Remove the "mfd" from the nomenclature.
okay, will fix.
>
> > + struct device_node *flash;
> > + const struct mfd_cell *cell;
> > + struct resource *res;
> > + struct rpc_mfd *rpc;
> > + void __iomem *base;
On 19. 6. 4. 오전 1:52, Dmitry Osipenko wrote:
> 03.05.2019 3:52, Dmitry Osipenko пишет:
>> 03.05.2019 3:31, Chanwoo Choi пишет:
>>> Hi Dmitry,
>>>
>>> On 19. 5. 2. 오전 8:37, Dmitry Osipenko wrote:
Changelog:
v4: Addressed all review comments that were made by Chanwoo Choi to v3:
On 06/04/2019 01:54 AM, Alexei Starovoitov wrote:
> On Mon, Jun 3, 2019 at 4:48 PM Daniel Borkmann wrote:
>> On 06/04/2019 01:27 AM, Alexei Starovoitov wrote:
>>> On Mon, Jun 3, 2019 at 3:59 PM Matt Mullins wrote:
If these are invariably non-nested, I can easily keep bpf_misc_sd when
On Tue, Jun 04, 2019 at 03:29:32AM +0800, Alex Williamson wrote:
> On Thu, 30 May 2019 20:44:38 -0400
> Yan Zhao wrote:
>
> > This patchset introduces a migration_version attribute under sysfs of VFIO
> > Mediated devices.
> >
> > This migration_version attribute is used to check migration
On Tue, Jun 4, 2019 at 1:27 AM Vineet Gupta wrote:
>
> On 6/2/19 11:31 PM, Alexey Brodkin wrote:
> > For a long time we used to hard-code CROSS_COMPILE prefix
> > for ARC until it started to cause problems, so we decided to
> > solely rely on CROSS_COMPILE externally set by a user:
> > commit
When consumer devices are added, they might not have a supplier device
to link to despite needing mandatory resources/functionality from one
or more suppliers. Add a waiting_for_suppliers list to track such
consumers and add helper functions to manage the list.
Marking/unmarking a consumer device
This sync_state driver/bus callback is called once all the consumers
of a supplier have probed successfully.
This allows the supplier device's driver/bus to sync the supplier
device's state to the software state with the guarantee that all the
consumers are actively managing the resources
The depends-on property is used to list the mandatory functional
dependencies of a consumer device on zero or more supplier devices.
Signed-off-by: Saravana Kannan
---
.../devicetree/bindings/depends-on.txt| 26 +++
1 file changed, 26 insertions(+)
create mode 100644
Add device-links after the devices are created (but before they are
probed) by looking at the "depends-on" DT property that allows
specifying mandatory functional dependencies between devices.
This property is used instead of existing DT properties that specify
phandles of other devices (Eg:
Add a generic "depends-on" property that allows specifying mandatory
functional dependencies between devices. Add device-links after the
devices are created (but before they are probed) by looking at this
"depends-on" property.
This property is used instead of existing DT properties that specify
Add a pointer from device tree node to the device created from it.
This allows us to find the device corresponding to a device tree node
without having to loop through all the platform devices.
However, fallback to looping through the platform devices to handle
any devices that might set their
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/isdn/hisax/hfc_usb.c
between commit:
de6cc6515a44 ("treewide: Replace GPLv2 boilerplate/reference with SPDX - rule
153")
from Linus' tree and commit:
85993b8c9786 ("isdn: remove hisax driver")
from the
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/isdn/gigaset/i4l.c
between commit:
2874c5fd2842 ("treewide: Replace GPLv2 boilerplate/reference with SPDX - rule
152")
from Linus' tree and commit:
8e6c8aa3b52e ("isdn: gigaset: remove i4l support")
from
On Mon, Jun 3, 2019 at 11:31 PM George G. Davis wrote:
>
> The following error occurs for the `make ARCH=arm64 checkstack` case:
>
> aarch64-linux-gnu-objdump -d vmlinux $(find . -name '*.ko') | \
> perl ./scripts/checkstack.pl arm64
> wrong or unknown architecture "arm64"
>
> As suggested by
On Tue, 4 Jun 2019, Michael Schmitz wrote:
> Hi Finn,
>
> On 3/06/19 7:40 PM, Finn Thain wrote:
> >
> > > There are several other drivers that contain pieces of assembler code.
> > >
> > Does any driver contain assembler code for multiple architectures? I was
> > trying to avoid that -- though
On 06/03/2019 03:11 PM, Nathan Chancellor wrote:
> When building with -Wsometimes-uninitialized, clang warns:
>
> drivers/pci/hotplug/rpaphp_core.c:243:14: warning: variable 'fndit' is
> used uninitialized whenever 'for' loop exits because its condition is
> false [-Wsometimes-uninitialized]
>
Parse and validate max-spread value per regulator couple. Now regulator
core can take multiple regulator couples, although balancing is still
limited to a single couple.
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/core.c | 13
drivers/regulator/of_regulator.c | 49
Today generic coupler can't handle regulators coupling that is specific to
NVIDIA Tegra SoC's, hence don't allow generic coupler to attach to those
regulators. Later on it should be possible to switch at least Tegra20 to a
generic coupler, once all prerequisite bits will get resolved in upstream
Expose some of internal functions that are required for implementation of
customized regulator couplers.
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/core.c | 58 +++-
include/linux/regulator/driver.h | 11 ++
2 files changed, 38 insertions(+), 31
There is voltage coupling between three regulators on Tegra20 boards and
between two on Tegra30. The voltage coupling is a SoC-level feature and
thus it is mandatory and common for all of the Tegra boards.
Signed-off-by: Dmitry Osipenko
---
.../nvidia,tegra-regulators-coupling.txt | 65
Add regulators coupler for Tegra20 SoC's that performs voltage balancing
of a coupled regulators and thus provides voltage scaling functionality.
There are 3 coupled regulators on all Tegra20 SoC's: CORE, RTC and CPU.
The CORE and RTC voltages shall be in range of 170mV from each other and
they
Add regulators coupler for Tegra30 SoC's that performs voltage balancing
of a coupled regulators and thus provides voltage scaling functionality.
There are 2 coupled regulators on all Tegra30 SoC's: CORE and CPU. The
coupled regulator voltages shall be in a range of 300mV from each other
and CORE
1 - 100 of 1209 matches
Mail list logo
