Current code always set pmic->rinfo[id] = _regs_info[id];
It should set to either max77620_regs_info or max20024_regs_info
depends on the chip_id.
Signed-off-by: Axel Lin
---
This was sent on https://lkml.org/lkml/2019/2/23/482
drivers/regulator/max77620-regulator.c | 2 +-
1 file changed, 1
Hi, Bibby:
On Mon, 2019-04-15 at 20:58 +0800, Bibby Hsieh wrote:
> Implement a function can encode the GCE instructions
>
> Signed-off-by: Bibby Hsieh
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 125 ---
> include/linux/mailbox/mtk-cmdq-mailbox.h | 2 +
>
This patch selects CONFIG_IMX8_SOC by default to support
i.MX8 SoC driver.
Signed-off-by: Anson Huang
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 2d9c390..c8ab62e 100644
---
Add i.MX8QXP SoC driver support, introduce driver dependency
into Kconfig as CONFIG_IMX_SCU must be selected to support
i.MX8QXP, also need to use platform driver model to make sure
IMX_SCU driver is probed before i.MX8 SoC driver.
With this patch, SoC info can be read from sysfs:
i.mx8qxp-mek#
Commit a939bb57cd47 ("pinctrl: intel: implement gpio_irq_enable") was
added because clearing interrupt status bit is required to avoid
unexpected behavior.
Turns out the unmask callback also needs the fix, which can solve weird
IRQ triggering issues on I2C touchpad ELAN1200.
Signed-off-by:
On Mon, Apr 22, 2019 at 03:30:26AM +, S.j. Wang wrote:
> > > SAI has 4 clock sources, which can be selected using MSEL bit of SAI
> > > TCR2 register.
> >
> > I have a doubt at this statement. As far as I can understand, this MSEL is
> > probably used by its internal clock MUX, so it's not
Hi, Bibby:
On Mon, 2019-04-15 at 20:58 +0800, Bibby Hsieh wrote:
> GCE hardware stored event information in own internal sysram,
> if the initial value in those sysram is not zero value
> it will cause a situation that gce can wait the event immediately
> after client ask gce to wait event but
Hi, Bibby:
On Mon, 2019-04-15 at 20:58 +0800, Bibby Hsieh wrote:
> add mt8183 compatible name for supporting gce function
Reviewed-by: CK Hu
>
> Signed-off-by: Bibby Hsieh
> ---
> drivers/mailbox/mtk-cmdq-mailbox.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
Hi, Bibby:
On Mon, 2019-04-15 at 20:58 +0800, Bibby Hsieh wrote:
> The interrupt mask and thread number has positive correlation,
> so we move the CMDQ_IRQ_MASK into cmdq driver data and calculate
> it by thread number.
Reviewed-by: CK Hu
>
> Signed-off-by: Bibby Hsieh
> ---
>
Hi
>
>
> On Sat, Apr 20, 2019 at 09:12:52AM +, Daniel Baluta wrote:
> > From: Shengjiu Wang
> >
> > SAI has 4 clock sources, which can be selected using MSEL bit of SAI
> > TCR2 register.
>
> I have a doubt at this statement. As far as I can understand, this MSEL is
> probably used by its
On 04/22/19 at 11:19am, Dave Young wrote:
> crashkernel=xM tries to reserve crashkernel memory under 4G, which
> is enough for usual cases. But this could fail sometimes, for example
> one tries to reserve a big chunk like 2G, it is possible to fail.
>
> So let the crashkernel=xM just fall back
crashkernel=xM tries to reserve crashkernel memory under 4G, which
is enough for usual cases. But this could fail sometimes, for example
one tries to reserve a big chunk like 2G, it is possible to fail.
So let the crashkernel=xM just fall back to use high memory in case it
fails to find a
The iBridge device provides access to several devices, including:
- the Touch Bar
- the iSight webcam
- the light sensor
- the fingerprint sensor
This driver provides the core support for managing the iBridge device
and the access to the underlying devices. In particular, since the
functionality
On 2016/2017 MacBook Pro's with a Touch Bar the ALS is attached to,
and exposed via the iBridge device. This provides the driver for that
sensor.
Signed-off-by: Ronald Tschalär
---
drivers/iio/light/Kconfig| 12 +
drivers/iio/light/Makefile | 1 +
2016 and 2017 MacBook Pro's have a T1 chip that drives the Touch Bar,
ambient light sensor, webcam, and fingerprint sensor; this shows up
as an iBridge USB device in the system. These patches provide initial
support for the Touch Bar and ALS - the webcam is already handled by
existing drivers, and
This driver enables basic touch bar functionality: enabling it, switching
between modes on FN key press, and dimming and turning the display
off/on when idle/active.
Signed-off-by: Ronald Tschalär
---
drivers/hid/Kconfig | 10 +
drivers/hid/Makefile |1 +
On 04/21/19 at 08:26pm, Ingo Molnar wrote:
>
> * Dave Young wrote:
>
> > crashkernel=xM tries to reserve crashkernel memory under 4G, which
> > is enough for usual cases. But this could fail sometimes, for example
> > one tries to reserve a big chunk like 2G, it is possible to fail.
> >
> >
INVALIDATE_TLB_VECTOR_START has been removed by commit,
52aec3308db8("x86/tlb: replace INVALIDATE_TLB_VECTOR by
CALL_FUNCTION_VECTOR")
And VSYSCALL_EMU_VECTO(204) has also been remove by commit,
3ae36655b97a("x86-64: Rework vsyscall emulation and add vsyscall=
parameter")
but the comments here are
On Fri, Apr 19, 2019 at 08:20:39PM +, Daniel Baluta wrote:
> i.MX8MM has 5 SAI instances with the following base
> addresses according to RM.
>
> SAI1 base address: 3001_h
> SAI2 base address: 3002_h
> SAI3 base address: 3003_h
> SAI5 base address: 3005_h
> SAI6 base address:
On Thu, Apr 18, 2019 at 03:42:25AM +, Ran Wang wrote:
> lx2160a supports pw20 which could help save more power during cpu is
> dile. It needs system firmware support via PSCI.
>
> Signed-off-by: Ran Wang
Applied, thanks.
On 04/20, Oleg Nesterov wrote:
>On 04/20, Zhenliang Wei wrote:
>>
>> --- a/kernel/signal.c
>> +++ b/kernel/signal.c
>> @@ -2441,6 +2441,8 @@ bool get_signal(struct ksignal *ksig)
>> if (signal_group_exit(signal)) {
>> ksig->info.si_signo = signr = SIGKILL;
>>
Hi Mark,
On Fri, 19 Apr 2019 at 22:50, Mark Brown wrote:
>
> On Fri, Apr 19, 2019 at 06:54:32PM +0800, Baolin Wang wrote:
> > On Spreadtrum platform, the audio subsystem will use the multi-channel
> > data transfer controller to transfer sound stream between audio subsystem
> > and other AP/CP
numa balancer is a module which will try to automatically adjust numa
balancing stuff to gain numa bonus as much as possible.
For each memory cgroup, we process the work in two steps:
On stage 1 we check cgroup's exectime and memory topology to see
if there could be a candidate for settled down,
Now we have the way to estimate and adjust numa preferred node for each
memcg, next problem is how to use them.
Usually one will bind workloads with cpuset.cpus, combined with cpuset.mems
or maybe better the memory policy to achieve numa bonus, however in complicated
scenery like combined type of
This patch add a new entry 'numa_preferred' for each memory cgroup,
by which we can now override the memory policy of the tasks inside
a particular cgroup, combined with numa balancing, we now be able to
migrate the workloads of a cgroup to the specified numa node, in gentle
way.
The load
This patch introduced numa execution information, to imply the numa
efficiency.
By doing 'cat /sys/fs/cgroup/memory/CGROUP_PATH/memory.numa_stat', we
see new output line heading with 'exectime', like:
exectime 24399843 27865444
which means the tasks of this cgroup executed 24399843 ticks on
This patch introduced numa locality statistic, which try to imply
the numa balancing efficiency per memory cgroup.
By doing 'cat /sys/fs/cgroup/memory/CGROUP_PATH/memory.numa_stat', we
see new output line heading with 'locality', the format is:
locality 0~9% 10%~19% 20%~29% 30%~39% 40%~49%
We have NUMA Balancing feature which always trying to move pages
of a task to the node it executed more, while still got issues:
* page cache can't be handled
* no cgroup level balancing
Suppose we have a box with 4 cpu, two cgroup A & B each running 4 tasks,
below scenery could be easily
The architecture specific information of the running processes
could be useful to the userland. Add /proc//arch_status
interface support to examine process architecture specific
information externally.
Signed-off-by: Aubrey Li
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
AVX-512 components use could cause core turbo frequency drop. So
it's useful to expose AVX-512 usage elapsed time as a heuristic hint
for the user space job scheduler to cluster the AVX-512 using tasks
together.
Tensorflow example:
$ while [ 1 ]; do cat /proc/tid/arch_status | grep AVX512; sleep
Added /proc//arch_status file, and added AVX512_elapsed_ms in
/proc//arch_status. Report it in Documentation/filesystems/proc.txt
Signed-off-by: Aubrey Li
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
Cc: Alexey Dobriyan
Cc: Andrew
On Sun, Apr 14, 2019 at 11:35:57AM -0700, Andrey Smirnov wrote:
> Mark i2c0 SCL as GPIO_OPEN_DRAIN to fix the following warning:
>
> gpio-36 (scl): enforced open drain please flag it properly in DT/ACPI
> DSDT/board file
>
> Signed-off-by: Andrey Smirnov
> Cc: Shawn Guo
> Cc: Chris Healy
>
Hi all,
Anyone notice this issue?
--Hongzhi
On 4/19/19 10:24 AM, Hongzhi, Song wrote:
1. Issue description:
Boot kernel( >= linux-rt-devel-v5.0.3 ) with qemu.
Then qemu will print following disorderly messages.
At the beginning, the messages are disorderly. But then it becomes
normally
On Sun, Apr 14, 2019 at 11:34:03AM -0700, Andrey Smirnov wrote:
> Add support for ZII's i.MX7 based Remote Peripheral Unit 2 (RPU2)
> board.
>
> Signed-off-by: Andrey Smirnov
> Reviewed-by: Fabio Estevam
> Cc: Shawn Guo
> Cc: Chris Healy
> Cc: Andrew Lunn
> Cc: Fabio Estevam
> Cc: Rob
On Sun, Apr 14, 2019 at 11:34:02AM -0700, Andrey Smirnov wrote:
> Add support for ZII i.MX7 RPU2 board.
>
> Signed-off-by: Andrey Smirnov
> Reviewed-by: Rob Herring
> Cc: Shawn Guo
> Cc: Chris Healy
> Cc: Andrew Lunn
> Cc: Fabio Estevam
> Cc: Rob Herring
> Cc: linux-kernel@vger.kernel.org
Hi, Shawn
Best Regards!
Anson Huang
> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: Sunday, April 21, 2019 3:42 PM
> To: Anson Huang
> Cc: stefan.wah...@i2se.com; enric.balle...@collabora.com; linux-
> ker...@vger.kernel.org; he...@sntech.de;
FYI, we noticed the following commit (built with gcc-7):
commit: 21471c203eb7f02124c15127f806f1b145e8d663 ("locking/rwsem: Disable
reader optimistic spinning adaptively")
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git WIP.locking/core
in testcase: boot
on test machine:
Good day Beautiful, i hope this mail meets you well? I know this may seem
inappropriate so i ask for your forgiveness but i wish to get to know you
better, if I may be so bold. I consider myself an easy-going man, adventurous,
honest and fun loving person but I am currently looking for a
TASK_SIZE macro is quite deceptive: it looks like a constant but in fact
compiles to 50+ bytes.
Space savings on x86_64 defconfig:
add/remove: 1/0 grow/shrink: 3/24 up/down: 77/-2247 (-2170)
Function old new delta
_task_size
On Sun, Apr 21, 2019 at 06:26:07AM -0700, Matthew Wilcox wrote:
> On Sun, Apr 21, 2019 at 09:38:59AM +0300, Mike Rapoport wrote:
> > On Fri, Apr 19, 2019 at 07:05:21AM -0700, Matthew Wilcox wrote:
> > > On Fri, Apr 19, 2019 at 10:43:35AM +0100, Mel Gorman wrote:
> > > > DISCONTIG is essentially
On Sun, Apr 21, 2019 at 01:07:08PM -0700, h...@zytor.com wrote:
> On April 21, 2019 11:28:42 AM PDT, Ingo Molnar wrote:
> >
> >* Alexey Dobriyan wrote:
> >
> >> TASK_SIZE macro is quite deceptive: it looks like a constant but in
> >fact
> >> compiles to 50+ bytes.
> >>
> >> Space savings on
On 4/19/19 3:39 PM, Waiman Long wrote:
> On 04/19/2019 09:15 AM, Peter Zijlstra wrote:
>> On Fri, Apr 19, 2019 at 03:03:04PM +0200, Peter Zijlstra wrote:
>>> On Fri, Apr 19, 2019 at 02:02:07PM +0200, Peter Zijlstra wrote:
On Fri, Apr 19, 2019 at 12:26:47PM +0200, Peter Zijlstra wrote:
> I
On April 21, 2019 11:28:42 AM PDT, Ingo Molnar wrote:
>
>* Alexey Dobriyan wrote:
>
>> TASK_SIZE macro is quite deceptive: it looks like a constant but in
>fact
>> compiles to 50+ bytes.
>>
>> Space savings on x86_64 defconfig:
>>
>> add/remove: 1/0 grow/shrink: 3/24 up/down: 77/-2247 (-2170)
On Sat, Apr 20, 2019 at 11:50:14PM +0900, Akira Yokosawa wrote:
> On Fri, 19 Apr 2019 11:06:41 -0700, Paul E. McKenney wrote:
> > On Sat, Apr 20, 2019 at 12:06:58AM +0900, Akira Yokosawa wrote:
> >> Hi Paul,
> >>
> [...]
> >
> >>> + (1) The compiler can reorder the load from a to precede the
This patch adds missing fields of start address 0 and 1 in the bmon
parameter structure that is received from the user in the debug IOCTL.
Without these fields, the functionality of the bmon trace is broken,
because there is no configuration of the base address of the filter of the
bus monitor.
This patch re-factors goya_parse_cb_no_ext_queue() to make it more
readable by inverting the check inside the first if statement so the bulk
of the function won't be inside an if statement.
The patch also fixes a spelling error in the name of the function.
Signed-off-by: Oded Gabbay
---
Hi Yauhen,
On 12-02-19 21:58, Yauhen Kharuzhy wrote:
This patch series introduces new driver for controlling LEDs connected
to Intel Cherry Trail Whiskey Cove PMIC (general-purpose LED and charger
status led). Only simple 'always on' and blinking modes are supported
for now, no breathing.
Add the device tree bindings document for the NVMEM based reboot-mode
driver.
Signed-off-by: Nandor Han
---
.../power/reset/nvmem-reboot-mode.txt | 32 +++
1 file changed, 32 insertions(+)
create mode 100644
Description
---
Extend the reboot mode driver to use a NVMEM cell as writing interface.
Testing
---
The testing is done by configuring DT from a custom board.
The NVMEM cell is configured in an RTC non-volatile memory.
Kernel: 4.14.60 (the patchset was rebased on kernel master)
DT
Add a new reboot mode write interface that is using an NVMEM cell
to store the reboot mode magic.
Signed-off-by: Nandor Han
---
drivers/power/reset/Kconfig | 9 +++
drivers/power/reset/Makefile| 1 +
drivers/power/reset/nvmem-reboot-mode.c | 76
Commit-ID: ea2f8d60603efbd1cb4e193a593945a2fe24d264
Gitweb: https://git.kernel.org/tip/ea2f8d60603efbd1cb4e193a593945a2fe24d264
Author: Borislav Petkov
AuthorDate: Sun, 21 Apr 2019 20:35:24 +0200
Committer: Ingo Molnar
CommitDate: Sun, 21 Apr 2019 20:48:51 +0200
x86/fault: Make fault
On Fri, Apr 19, 2019 at 11:35:51AM -0700, tip-bot for Sean Christopherson wrote:
> BUG: kernel NULL pointer dereference, address = 0008
> #PF: supervisor-privileged instruction fetch from kernel code
> #PF: error_code(0x0010) - not-present page
>
> BUG: unable to
* Alexey Dobriyan wrote:
> TASK_SIZE macro is quite deceptive: it looks like a constant but in fact
> compiles to 50+ bytes.
>
> Space savings on x86_64 defconfig:
>
> add/remove: 1/0 grow/shrink: 3/24 up/down: 77/-2247 (-2170)
> Function old new
* Dave Young wrote:
> crashkernel=xM tries to reserve crashkernel memory under 4G, which
> is enough for usual cases. But this could fail sometimes, for example
> one tries to reserve a big chunk like 2G, it is possible to fail.
>
> So let the crashkernel=xM just fall back to use high memory
* Dave Young wrote:
> The kdump crashkernel low reservation is limited to under 896M even for
> X86_64. This obscure and miserable limitation exists for old kexec-tools
> compatibility, but the reason is not documented anywhere.
>
> Some more tests/investigations about the background:
> a)
From: Corentin Labbe
Date: Sat, 20 Apr 2019 16:43:01 +
> CONFIG_DECNET_ROUTE_FWMARK was removed in commit 47dcf0cb1005 ("[NET]:
> Rethink mark field in struct flowi")
> Since nothing replace it (and nothindg need to replace it, simply remove
> it from documentation.
>
> Signed-off-by:
* Linus Torvalds wrote:
> On Sat, Apr 20, 2019 at 12:30 AM Ingo Molnar wrote:
> >
> > A lockdep warning fix and a script execution fix when atomics are
> > generated.
>
> Hmm. I've pulled this, but looking at it, I think it's worth noting
> something...
>
> > diff --git
It's Easter Sunday here, but I don't let little things like random
major religious holidays interrupt my kernel development workflow. The
occasional scuba trip? Sure. But everybody sitting around eating
traditional foods? No. You have to have priorities. There's only so
much memma you can eat even
On 2019-01-04 19:06, Wolfram Sang wrote:
>
>> Instead of leaving these open-coded and prone to type mistakes, we can
>> now use the new struct_size() helper:
>
> I am okay with this patch in general. However, I think the name of the
> helper 'struct_size' is a bit unfortunate. I really wondered
For some unknown reason the driver for Max77620 doesn't wire up the
device-tree support properly and nothing in kernel creates I2C device
for the driver (and never did), moreover device-tree files for NVIDIA
Tegra210/186/194 boards already have nodes for Max77620. Hence add the
missing
Add support for Maxim 77663 using the Max77620 driver. The hardware
is very similar to Max77663/20024, although there are couple minor
differences.
Signed-off-by: Dmitry Osipenko
---
drivers/mfd/max77620.c | 68 +++-
include/linux/mfd/max77620.h | 1 +
2
Maxim 77663 has a few minor differences in regards to hardware interface
and available capabilities by comparing it with 77620 and 20024 models,
hence re-use 77620 device-tree binding for the 77663.
Signed-off-by: Dmitry Osipenko
---
Documentation/devicetree/bindings/mfd/max77620.txt | 4 +++-
The FPS_PERIOD_MAX_US definitions are swapped for MAX20024 and MAX77620,
fix it.
Cc: stable
Signed-off-by: Dmitry Osipenko
---
include/linux/mfd/max77620.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/mfd/max77620.h b/include/linux/mfd/max77620.h
index
Hello,
This series adds support for the Maxim 77663 chip that provides PMIC, RTC,
GPIO and watchdog timer functionality. The hardware is very similar to the
Maxim 77620/20024 hardware units that are already supported by the kernel,
hence we will reuse the existing drivers for 77663. The GPIO,
Add support for Maxim 77663.
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/max77620-regulator.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/max77620-regulator.c
b/drivers/regulator/max77620-regulator.c
index
Below is the list of build error/warning regressions/improvements in
v5.1-rc5[1] compared to v5.0[2].
Summarized:
- build errors: +1/-1
- build warnings: +139/-107
JFYI, when comparing v5.1-rc5[1] to v5.1-rc4[3], the summaries are:
- build errors: +0/-0
- build warnings: +86/-62
Happy
On Sun, Apr 21, 2019 at 7:15 PM Geert Uytterhoeven wrote:
> JFYI, when comparing v5.1-rc4[1] to v5.1-rc3[3], the summaries are:
> - build errors: +1/-0
+ error: arch/sh/kernel/cpu/sh2/clock-sh7619.o: undefined reference
to `followparent_recalc': => .data+0x70)
sh4/sh-all{mod,yes}config
Hi Chris,
> On 20/02/19 4:14 AM, Gregory CLEMENT wrote:
>> Hi Chris,
>>
>> On lun., févr. 18 2019, Chris Packham
>> wrote:
>>
>>> Kirkwood has always had the ability to retrieve the local-mac-address
>>> from the hardware (usually this was configured by the bootloader). This
>>> is
Hi Wen Yang,
> The call to of_get_next_child returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
>
> Detected by coccinelle with the following warnings:
> ./arch/arm/mach-mvebu/pm-board.c:135:2-8: ERROR: missing of_node_put;
>
Hi Chris,
> The first interrupt is for the regular watchdog timeout. Normally the
> RSTOUT line will trigger a reset before this interrupt fires but on
> systems with a non-standard reset it may still trigger.
>
> The second interrupt is for a timer1 which is used as a pre-timeout for
> the
Hi Stefan,
> In every other instance where mrc is used the coprocessor operand
> is prefix with p (e.g. p15). Use the p prefix in this case too.
> This fixes a build issue when using LLVM's integrated assembler:
> arch/arm/mach-mvebu/coherency_ll.S:69:6: error: invalid operand for
>
Hi Nicholas,
> The return statement is unnecessary here - so drop it.
>
> Signed-off-by: Nicholas Mc Guire
Applied on mvebu/arm
Thanks,
Gregory
> ---
>
> Problem reported by checkpatch
>
> WARNING: void function return statements are not generally useful
> #141: FILE:
Below is the list of build error/warning regressions/improvements in
v5.1-rc4[1] compared to v5.0[2].
Summarized:
- build errors: +1/-1
- build warnings: +117/-109
JFYI, when comparing v5.1-rc4[1] to v5.1-rc3[3], the summaries are:
- build errors: +1/-0
- build warnings: +60/-85
Happy
On Thu, Apr 18, 2019 at 03:50:19PM -0700, Andrew Morton wrote:
> On Wed, 17 Apr 2019 17:22:00 +0530 Bharath Vedartham
> wrote:
>
> > This patch fixes the sparse warning:
> >
> > fs/reiserfs//xattr.c:453:28: warning: incorrect type in return
> > expression (different base types)
> >
Cleanup indenting issue reported by checkpatch.
WARNING: suspect code indent for conditional statements (8, 17)
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/hal/odm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/hal/odm.c
On Thu, Apr 18, 2019 at 09:02:47AM +1000, Stephen Rothwell wrote:
> Hi Kees,
>
> On Wed, 17 Apr 2019 17:28:39 -0500 Kees Cook wrote:
> >
> > On Wed, Apr 17, 2019 at 5:22 PM Kees Cook wrote:
> > >
> > > On Wed, Apr 17, 2019 at 1:53 AM Stephen Rothwell
> > > wrote:
> > > >
> > > > Hi Andrew,
struct linux_binprm::buf is the first field and it is exactly 128 bytes
in size. It means that on x86_64 all accesses to other fields will go
though [r64 + disp32] addressing mode which is 3 bytes bloatier than
[r64 + disp8] addressing mode. Given that accesses to other fields
outnumber accesses
On 2019-04-21 17:55, Randy Dunlap wrote:
> When using 'make menuconfig', enter /usb_storage and it says:
> ...
> │ Depends on: USB_SUPPORT [=y] && USB [=m] && SCSI [=m]
>
> HTH. There is nothing quite as explicit as your example output.
Hmm OK.
The menuconfig approach is what I've used so
TASK_SIZE macro is quite deceptive: it looks like a constant but in fact
compiles to 50+ bytes.
Space savings on x86_64 defconfig:
add/remove: 1/0 grow/shrink: 3/24 up/down: 77/-2247 (-2170)
Function old new delta
_task_size
On 4/21/19 8:11 AM, Niklas Hambüchen wrote:
> When you set an option to `=y` but one of its dependencies is set to `=m`,
> then `make oldconfig` will reset it back to `=m` as well.
>
> That makes sense, but does there exist a feature somewhere that can tell me
> explicitly when this happens,
From: Mao Han
This patch add support for DWARF register mappings and libdw registers
initialization, which is used by perf callchain analyzing when
--call-graph=dwarf is given.
Here is elfutils csky backend patch set:
https://sourceware.org/ml/elfutils-devel/2019-q2/msg7.html
On 4/21/19 6:52 AM, Yoshinori Sato wrote:
> On Sun, 21 Apr 2019 04:34:36 +0900,
> Randy Dunlap wrote:
>>
>> On 4/20/19 12:40 AM, kbuild test robot wrote:
>>> Hi Randy,
>>>
>>> It's probably a bug fix that unveils the link errors.
>>>
>>> tree:
When you set an option to `=y` but one of its dependencies is set to `=m`, then
`make oldconfig` will reset it back to `=m` as well.
That makes sense, but does there exist a feature somewhere that can tell me
explicitly when this happens, ideally with a reason like:
Resetting
Hey Dmitry,
On 2019-02-17 23:15, Dmitry V. Levin wrote:
>> A tracee first needs to be attached to the tracer.
>> -Attachment and subsequent commands are per thread:
>> -in a multithreaded process,
>> +Attachment and subsequent commands are per thread,
>> +on both the tracer and tracee side.
>>
Hey Michael,
On 2019-02-25 16:51, Michael Kerrisk (man-pages) wrote:
> Do you plan to revise this patch in the light of Dmitry's comments?
sorry for the delay, I do intend to finish it and just replied.
Niklas
From: Mohan Kumar
Replace the obsolte simple_strtoul function with kstrtoul.
Signed-off-by: Mohan Kumar
---
drivers/cpufreq/elanfreq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/elanfreq.c b/drivers/cpufreq/elanfreq.c
index 03419f064752..6d861c2364e2
unsubscribe
On Sun, 21 Apr 2019 04:34:36 +0900,
Randy Dunlap wrote:
>
> On 4/20/19 12:40 AM, kbuild test robot wrote:
> > Hi Randy,
> >
> > It's probably a bug fix that unveils the link errors.
> >
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > master
> > head:
On Sun, Apr 21, 2019 at 09:38:59AM +0300, Mike Rapoport wrote:
> On Fri, Apr 19, 2019 at 07:05:21AM -0700, Matthew Wilcox wrote:
> > On Fri, Apr 19, 2019 at 10:43:35AM +0100, Mel Gorman wrote:
> > > DISCONTIG is essentially deprecated and even parisc plans to move to
> > > SPARSEMEM so there is no
On Sat, Apr 20, 2019 at 10:00:35PM +0800, Wanglai Shi wrote:
> This patch adds DT bindings for the CoreSight trace components
> on hi3660, which is used by 96boards Hikey960.
>
> Signed-off-by: Wanglai Shi
Reviewed this patch and tested on my Hikey960 board, FWIW:
Reviewed-and-tested-by: Leo
Commit d901b2760dc6 ("lib/scatterlist: Provide a DMA page iterator")
added the sg DMA iterator but a leftover remained in the sg_page_iter
documentation as you cannot get the page dma address (only the page
itself), fix it.
Cc: Jason Gunthorpe
Signed-off-by: Gal Pressman
Reviewed-by: Mukesh
Pointers should be printed with %p or %px rather than
cast to long type and printed with %lx.
Change %lx to %p to print the pointer.
Signed-off-by: Fuqian Huang
---
sound/isa/gus/gus_mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/isa/gus/gus_mem.c
The pointer should be printed with %p or %px rather than
cast to long long type and printed with %016llx.
Change %x to %p to print the pointer.
Signed-off-by: Fuqian Huang
---
drivers/misc/genwqe/card_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Pointers should be printed with %p or %px rather than
cast to unsigned long type and printed with %lx.
Change %lx to %p to print the pointers.
Signed-off-by: Fuqian Huang
---
kernel/cgroup/debug.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/cgroup/debug.c
/commits/Mohan-Kumar/drivers-cpufreq-use-kstrtoul-instead-of-obsolete-simple_strtoul/20190421-044216
base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
linux-next
config: i386-randconfig-c0-04211526 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce
On Sat, Apr 20, 2019 at 12:15:26PM -0700, Cong Wang wrote:
> Yes, one is V1 and the other is V2. Is it hard to understand V2 is to
> replace V1?
Well, looking at these two very different fixes, it made me think that
you don't really know what you're doing. So I went and did the Knuth's
version
On Sat, Apr 20, 2019 at 09:12:52AM +, Daniel Baluta wrote:
> From: Shengjiu Wang
>
> SAI has 4 clock sources, which can be selected using MSEL
> bit of SAI TCR2 register.
I have a doubt at this statement. As far as I can understand,
this MSEL is probably used by its internal clock MUX, so
- Mensagem original -
De: Andre Moreti
Para: andre moreti
Enviadas: Sat, 20 Apr 2019 12:00:23 -0300 (BRT)
Assunto: Goed nieuws
Ik ben Andre Moreti door ONU, je hebt een donatie, neem contact op voor meer
informatie: onuespfoundat...@gmail.com voor claim
oprecht
Andre Moreti
contact:
On Sun, Apr 21, 2019 at 03:40:00PM +0800, Shawn Guo wrote:
> On Thu, Apr 11, 2019 at 06:49:12AM +, Anson Huang wrote:
> > i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
> > inside, the system controller is in charge of controlling power,
> > clock and fuse etc..
> >
> > This
On Thu, Apr 11, 2019 at 06:49:12AM +, Anson Huang wrote:
> i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
> inside, the system controller is in charge of controlling power,
> clock and fuse etc..
>
> This patch adds i.MX system controller soc driver support,
> Linux kernel
1 - 100 of 102 matches
Mail list logo
