Hi,
On Mon, May 20, 2019 at 3:01 PM Matthias Kaehlcke wrote:
>
> The NPLL is the only safe way to generate 500 MHz for the GPU. The
> downstream Chrome OS 3.14 kernel ('official' kernel for veyron
> devices) re-purposes NPLL to HDMI and hence disables the OPP for
> the GPU (see
On Mon, May 20, 2019 at 4:20 PM Thomas Garnier wrote:
>
> From: Thomas Garnier
>
> Replace the %c constraint with %P. The %c is incompatible with PIE
> because it implies an immediate value whereas %P reference a symbol.
> Change the _ASM_PTR reference to .long for expected relocation size and
>
From: Thomas Garnier
if PIE is enabled, switch the paravirt assembly constraints to be
compatible. The %c/i constrains generate smaller code so is kept by
default.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization range below 0x8000.
From: Thomas Garnier
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible. Use the new _ASM_MOVABS macro instead of
the 'mov $symbol, %dst' construct.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization
From: Thomas Garnier
Change the assembly options to work with pointers instead of integers.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization range below 0x8000.
Signed-off-by: Thomas Garnier
---
arch/x86/include/asm/alternative.h | 6
From: Thomas Garnier
Add a new _ASM_MOVABS macro to fetch a symbol address. It will be used
to replace "_ASM_MOV $, %dst" code construct that are not
compatible with PIE.
Signed-off-by: Thomas Garnier
---
arch/x86/include/asm/asm.h | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Thomas Garnier
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization range below 0x8000.
Signed-off-by: Thomas Garnier
Acked-by:
From: Thomas Garnier
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.
Early at boot, the kernel is mapped at a temporary address while preparing
the page table. To know the changes needed for the page table with KASLR,
the boot code
From: Thomas Garnier
Replace the %c constraint with %P. The %c is incompatible with PIE
because it implies an immediate value whereas %P reference a symbol.
Change the _ASM_PTR reference to .long for expected relocation size and
add a long padding to ensure entry alignment.
Position Independent
From: Thomas Garnier
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization range below 0x8000.
Signed-off-by: Thomas Garnier
Acked-by:
From: Thomas Garnier
Change assembly to use the new _ASM_MOVABS macro instead of _ASM_MOV for
the assembly to be PIE compatible.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization range below 0x8000.
Signed-off-by: Thomas Garnier
---
Splitting the previous serie in two. This part contains assembly code
changes required for PIE but without any direct dependencies with the
rest of the patchset.
Changes:
- patch v7 (assembly):
- Split patchset and reorder changes.
- patch v6:
- Rebase on latest changes in jump tables and
From: Thomas Garnier
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization range below 0x8000.
Signed-off-by: Thomas Garnier
---
Daniel, what you are talking about is totally wrong.
1) AFAIK, only one zero-size array can be in the end of a struct.
2) two struct_size will add up struct itself twice. the sum is wrong then.
No offense. I can't help feeling lucky that you are in intel.
发件人: Daniel Vetter 代表 Daniel Vetter
Hi all,
Today's linux-next merge of the sunxi tree got a conflict in:
arch/arm64/configs/defconfig
between commit:
4aaa1c7a05db ("arm64: defconfig: NVMEM_IMX_OCOTP=y for imx8m")
from the imx-mxs tree and commit:
296bcfa05640 ("arm64: defconfig: add allwinner sid support")
from the
From: Thomas Garnier
Change the assembly code to use only absolute references of symbols for the
kernel to be PIE compatible.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization range below 0x8000.
Signed-off-by: Thomas Garnier
---
On 5/17/19 7:41 AM, Ken Goldman wrote:
Hi Ken,
Apologize for the delay in responding.
Since a platform typically uses only a few signing keys, 4 bytes makes
the chance of a collision quite small. The collision would have to be
within the same log, not global.
In that worst case, the
Hi!
> > emacs segfaults... when I attempt to exit it. And that did not use to
> > be the case. Nothing suspect in the dmesg. Rest of the machine seems
> > to work ok.
> …
> > Ideas welcome...
>
> I assume that this happens with -rc1, too. Could you please check if
> emacs still segfaults with
On Mon, May 20, 2019 at 9:23 AM Angus Ainslie (Purism) wrote:
>
> Add an entry for Purism, SPC
>
> Signed-off-by: Angus Ainslie (Purism)
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Rob Herring
On Mon, May 20, 2019 at 11:14 AM Mauro Carvalho Chehab
wrote:
>
> Em Mon, 20 May 2019 10:57:47 -0500
> Rob Herring escreveu:
>
> > On Mon, May 20, 2019 at 9:48 AM Mauro Carvalho Chehab
> > wrote:
> > >
> > > This file was converted to json, but the references weren't
> >
> > Technically,
On Mon, May 20, 2019 at 10:27:03AM +0200, Michal Hocko wrote:
> [Cc linux-api]
>
> On Mon 20-05-19 12:52:50, 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
syzbot has found a reproducer for the following crash on:
HEAD commit:f49aa1de Merge tag 'for-5.2-rc1-tag' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1492b482a0
kernel config:
On Mon, May 20, 2019 at 12:50:13PM -0400, Johannes Weiner wrote:
> On Mon, May 20, 2019 at 12:52:49PM +0900, Minchan Kim wrote:
> > The local variable references in shrink_page_list is PAGEREF_RECLAIM_CLEAN
> > as default. It is for preventing to reclaim dirty pages when CMA try to
> > migrate
On Mon, May 20, 2019 at 10:19:43AM +0200, Michal Hocko wrote:
> On Mon 20-05-19 10:16:21, Michal Hocko wrote:
> > [CC linux-api]
> >
> > On Mon 20-05-19 12:52:48, Minchan Kim wrote:
> > > When a process expects no accesses to a certain memory range
> > > it could hint kernel that the pages can be
On Mon, May 20, 2019 at 10:16:21AM +0200, Michal Hocko wrote:
> [CC linux-api]
Thanks, Michal. I forgot to add it.
>
> On Mon 20-05-19 12:52:48, Minchan Kim wrote:
> > When a process expects no accesses to a certain memory range
> > it could hint kernel that the pages can be reclaimed
> > when
Commit da298c6d98d5 ("[media] v4l2: replace video op g_mbus_fmt by pad
op get_fmt") converted a former ov6650_g_fmt() video operation callback
to an ov6650_get_fmt() pad operation callback. However, the converted
function disregards a format->which flag that pad operations should
obey and always
Since commit afd9690c72c3 ("[media] ov6650: convert to the control
framework"), if an error occurs during initialization of a control
handler, resources possibly allocated to the handler are not freed
before device initialiaton is aborted. Fix it.
Fixes: afd9690c72c3 ("[media] ov6650: convert to
Since its initial submission, the driver selects V4L2_COLORSPACE_JPEG
for supported formats other than V4L2_MBUS_FMT_SBGGR8_1X8. According
to v4l2-compliance test program, V4L2_COLORSPACE_JPEG applies
exclusively to V4L2_PIX_FMT_JPEG. Since the sensor does not support
JPEG format, fix it to
The driver stores crop rectangle settings supposed to be in line with
hardware state in a device private structure. Since the driver initial
submission, crop rectangle width and height settings are not updated
correctly when rectangle offset settings are applied on hardware. If
an error occurs
Commit 23a52386fabe ("media: ov6650: convert to standalone v4l2
subdevice") converted the driver from a soc_camera sensor to a
standalone V4L subdevice driver. Unfortunately, module description was
not updated to reflect the change. Fix it.
While being at it, update email address of the module
It is not clear what pixel format is actually configured in hardware on
reset. MEDIA_BUS_FMT_YUYV8_2X8, assumed on device probe since the
driver was intiially submitted, is for sure not the one.
Fix it by explicitly applying a known, driver default frame format just
after initial device reset.
Commit 4f996594ceaf ("[media] v4l2: make vidioc_s_crop const")
introduced a writable copy of constified user requested crop rectangle
in order to be able to perform hardware alignments on it. Later
on, commit 10d5509c8d50 ("[media] v4l2: remove g/s_crop from video
ops") replaced s_crop() video
Janusz Krzysztofik (9):
media: ov6650: Fix MODDULE_DESCRIPTION
media: ov6650: Fix control handler not freed on init error
media: ov6650: Fix crop rectangle alignment not passed back
media: ov6650: Fix incorrect use of JPEG colorspace
media: ov6650: Fix some format attributes not under
The driver stores frame format settings supposed to be in line with
hardware state in a device private structure. Since the driver initial
submission, those settings are updated before they are actually applied
on hardware. If an error occurs on device update, the stored settings
my not reflect
User arguments passed to .get/set_fmt() pad operation callbacks may
contain unsupported values. The driver takes control over frame size
and pixel code as well as colorspace and field attributes but has never
cared for remainig format attributes, i.e., ycbcr_enc, quantization
and xfer_func,
On 5/10/19 10:31 AM, Florian Fainelli wrote:
> Hi Herbert,
>
> This patch series adds support for BCM7211 to the iproc-rng200 driver,
> nothing special besides matching the compatibile string and updating the
> binding document.
Herbert, can you apply those patches?
>
> Florian Fainelli (2):
>
From: "Edgecombe, Rick P"
Date: Mon, 20 May 2019 22:17:49 +
> Thanks for testing. So I guess that suggests it's the TLB flush causing
> the problem on sparc and not any lazy purge deadlock. I had sent Meelis
> another test patch that just flushed the entire 0 to ULONG_MAX range to
> try to
The 5.1 mount system rework changed the smackfsdef mount option
to smackfsdefault. This fixes the regression by making smackfsdef
treated the same way as smackfsdefault. The change was made in
commit c3300aaf95fb4 from Al Viro.
Reported-by: Jose Bollo
Signed-off-by: Casey Schaufler
---
On Mon, May 20, 2019 at 9:44 AM Michal Kubecek wrote:
>
> Recently introduced functions kvm_vcpu_map() and kvm_vcpu_unmap() call
> memremap() and memunmap() which are only available if HAS_IOMEM is enabled
> but this dependency is not explicit, so that the build fails with HAS_IOMEM
> disabled.
>
When a switch event, such as tablet mode/laptop mode or docked/undocked,
wakes a device make sure that the value of the swich is reported.
Without when a device is put in tablet mode from laptop mode when it is
suspended or vice versa the device will wake up but mode will be
incorrect.
Tested by
, ccm_base + CCM_CCDR);
^~
xchg_relaxed
Caused by commit
0dc6b492b6e0 ("clk: imx: Add common API for masking MMDC handshake")
I have used the imx-mxs tree from next-20190520 for today.
--
Cheers,
Stephen Rothwell
pgptuGEo7R_5g.pgp
Description: OpenPGP digital signature
This should fix test regressions seen when running under unbuffered
output. Additionally, fixes are added for the missing flushed output
in the timers test which become obvious without unbuffered output.
-Kees
Kees Cook (2):
selftests: Remove forced unbuffering for test running
When running under a pipe, some timer tests would not report output in
real-time because stdout flushes were missing after printf()s that lacked
a newline. This adds them to restore real-time status output that humans
can enjoy.
Signed-off-by: Kees Cook
---
As it turns out, the "stdbuf" command will actually force all
subprocesses into unbuffered output, and some implementations of "echo"
turn into single-character writes, which utterly wrecks writes to /sys
and /proc files.
Instead, drop the "stdbuf" usage, and for any tests that want explicit
On Mon, May 20, 2019 at 02:13:06PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.45 release.
> There are 105 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
On Tue, 2019-05-21 at 00:36 +0300, Meelis Roos wrote:
> > Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
> > vm_unmap_aliases() and fix calculation of the direct map for the
> > CONFIG_ARCH_HAS_SET_DIRECT_MAP case.
> >
> > Meelis Roos reported issues with the new
On Mon, 20 May 2019 19:15:15 +
Parav Pandit wrote:
> > -Original Message-
> > From: Cornelia Huck
> > Sent: Monday, May 20, 2019 6:29 AM
> > To: Parav Pandit
> > Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > kwankh...@nvidia.com; alex.william...@redhat.com;
mickey crams a lot of hardware into a tiny package, which requires
more aggressive thermal throttling than for devices with a larger
footprint. Configure the GPU thermal zone to throttle the GPU
progressively at temperatures >= 60°C. Heat dissipated by the
CPUs also affects the GPU temperature,
The NPLL is the only safe way to generate 500 MHz for the GPU. The
downstream Chrome OS 3.14 kernel ('official' kernel for veyron
devices) re-purposes NPLL to HDMI and hence disables the OPP for
the GPU (see https://crrev.com/c/1574579). Disable it here as well
to keep in sync and avoid problems
On rk3288 the CPU and GPU temperatures are correlated. Limit the GPU
frequency on veyron mickey to 400 MHz for CPU temperatures >= 65°C
and to 300 MHz for CPU temperatures >= 85°C.
This matches the configuration of the downstream Chrome OS 3.14 kernel,
the 'official' kernel for mickey.
From: Kim Phillips
Fill in the L3 performance event select register ThreadMask
bitfield, to enable per hardware thread accounting.
Signed-off-by: Kim Phillips
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Thomas
From: Kim Phillips
Commit d7cbbe49a930 ("perf/x86/amd/uncore: Set ThreadMask and SliceMask
for L3 Cache perf events") enables L3 PMC events for all threads and
slices by writing 1s in ChL3PmcCfg (L3 PMC PERF_CTL) register fields.
Those bitfields overlap with high order event select bits in the
On Tue, 21 May 2019 07:44:35 +1000
Stephen Rothwell wrote:
> In commit
>
> 9eaa65e8aad5 ("scripts/spdxcheck.py: Add dual license subdirectory")
>
> Fixes tag
>
> Fixes: 99871f2f9a4d ("scripts/spdxcheck.py: Fix path to deprecated
> licenses")
>
> has these problem(s):
>
> - Target
Hello,
On Mon, May 20, 2019 at 02:35:34PM +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -25.9% regression of will-it-scale.per_process_ops due to
> commit:
>
>
> commit: 42a300353577ccc17ecc627b8570a89fa1678bec ("mm: memcontrol: fix
> recursive statistics correctness &
One question that comes to my mind is this: Does the USB
transmission stall (e.g. endpoint stall) or not? In other words, is
adb connection broken because USB stops transmitting anything, or
because the data is transmitted but its integrity is broken during
On 2019-05-20 12:05 p.m., Martin K. Petersen wrote:
James,
Please. What I'm interested in is whether this is simply a bug in the
array firmware, in which case the fix is sufficient, or whether
there's some problem with the parser, like mismatched expectations
over added trailing nulls or
On Mon, 2019-05-20 at 21:05 +0200, Andrew Lunn wrote:
> > > + int_mdio: mdio@1 {
> > > + reg = <1>;
> > > + #address-cells = <1>;
> > > + #size-cells =
On Mon, May 20, 2019 at 08:59:14PM +0200, Takashi Iwai wrote:
> So the problem is obvious: the commit above adjusts the stdout to be
> unbuffered via stdbuf, hence each invocation like
> echo -n abc > /sys/
>
> would become writes of "a", "b" and "c", instead of "abc".
>
> Although we can
GCC 9 fails to calculate the size of local constant strings and produces a
false positive:
samples/bpf/task_fd_query_user.c: In function ‘test_debug_fs_uprobe’:
samples/bpf/task_fd_query_user.c:242:67: warning: ‘%s’ directive output may be
truncated writing up to 255 bytes into a region of size
On Mon, May 20, 2019, Josh Poimboeuf wrote:
> I think you must have been looking at an old version.
>
> [(v5.2-rc1)] ~/git/linux $ grep jeyu MAINTAINERS
> M:Jessica Yu
Operator error on my part. I was looking at a different directory with
an old branch checked out. Sorry!
> Can you try
On Mon, 2019-05-20 at 14:25 -0700, Andy Lutomirski wrote:
>
>
> > On May 20, 2019, at 1:07 PM, Rick Edgecombe <
> > rick.p.edgeco...@intel.com> wrote:
> >
> > Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
> > vm_unmap_aliases() and fix calculation of the direct map for the
>
When failslab was originally written, the intention of the
"ignore-gfp-wait" flag default value ("N") was to fail
GFP_ATOMIC allocations. Those were defined as (__GFP_HIGH),
and the code would test for __GFP_WAIT (0x10u).
However, since then, __GFP_WAIT was replaced by __GFP_RECLAIM
The first patch is just removing some code duplicated in raid1 and raid10, and
the other three patches are just cleanups.
These patches were based in "drivers: md: Unify common definitions of raid1 and
raid10", sent a few weeks ago. Let me know if these patches can be improved.
Thanks
Marcos
Avoiding duplicated code, since they just execute a kfree.
Signed-off-by: Marcos Paulo de Souza
---
drivers/md/raid1-10.c | 5 +
drivers/md/raid1.c| 13 -
drivers/md/raid10.c | 11 +++
3 files changed, 12 insertions(+), 17 deletions(-)
diff --git
This return statement was introduced in commit
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ("Linux-2.6.12-rc2") and can be
safely removed.
Signed-off-by: Marcos Paulo de Souza
---
drivers/md/raid0.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c
index
Commit 0c35bd4723e4a39ba2da4c13a22cb97986ee10c8
("md: fix problems with freeing private data after ->run failure")
removed the check for the result of md_integrity_register, so we don't
need to store it anymore, so return it directly.
Signed-off-by: Marcos Paulo de Souza
---
drivers/md/raid0.c
ret variable is only used in a specific situation, so make it local
instead of global.
Signed-off-by: Marcos Paulo de Souza
---
drivers/md/raid0.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c
index e72255464c09..b28dbb797f76
Hi all,
In commit
9eaa65e8aad5 ("scripts/spdxcheck.py: Add dual license subdirectory")
Fixes tag
Fixes: 99871f2f9a4d ("scripts/spdxcheck.py: Fix path to deprecated licenses")
has these problem(s):
- Target SHA1 does not exist
Did you mean
Fixes: e6d319f68d4d ("scripts/spdxcheck.py:
On Tue, May 21, 2019 at 12:29 AM Akinobu Mita wrote:
>
> 2019年5月20日(月) 13:49 Nicolas Boichat :
> >
> > When failslab was originally written, the intention of the
> > "ignore-gfp-wait" flag default value ("N") was to fail
> > GFP_ATOMIC allocations. Those were defined as (__GFP_HIGH),
> > and the
On Mon, 20 May 2019 16:19:31 -0500
Josh Poimboeuf wrote:
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index a12aff849c04..8259d4ba8b00 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
stmmac_init_chan() needs to be called before stmmac_init_rx_chan() and
stmmac_init_tx_chan(). This is because if PBLx8 is to be used,
"DMA_CH(#i)_Control.PBLx8" needs to be set before programming
"DMA_CH(#i)_TX_Control.TxPBL" and "DMA_CH(#i)_RX_Control.RxPBL".
Fixes: 47f2a9ce527a ("net: stmmac:
Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
vm_unmap_aliases() and fix calculation of the direct map for the
CONFIG_ARCH_HAS_SET_DIRECT_MAP case.
Meelis Roos reported issues with the new VM_FLUSH_RESET_PERMS flag on a
sparc machine. On investigation some issues were noticed:
Correctness of format type (try or active) and pad ID parameters passed
to subdevice operation callbacks is now verified only for IOCTL calls.
However, those callbacks are also used by drivers, e.g., V4L2 host
interfaces.
Since both subdev_do_ioctl() and drivers are using v4l2_subdev_call()
macro
Parameters passed to check helpers are now obtained by dereferencing
unverified pointer arguments. Check validity of those pointers first.
Signed-off-by: Janusz Krzysztofik
---
drivers/media/v4l2-core/v4l2-subdev.c | 27 +++
1 file changed, 27 insertions(+)
diff --git
Correctness of format type (try or active) and pad number parameters
passed to subdevice operation callbacks is now verified only for IOCTL
calls. However, those callbacks are also used by drivers, e.g., V4L2
host interfaces.
Since both subdev_do_ioctl() and drivers are using v4l2_subdev_call()
Extend parameter checks performed by v4l2_subdev_call() with a check for
a non-NULL pad config pointer if V4L2_SUBDEV_FORMAT_TRY format type is
requested so drivers don't need to care.
Signed-off-by: Janusz Krzysztofik
---
drivers/media/v4l2-core/v4l2-subdev.c | 27 +--
> On May 20, 2019, at 1:07 PM, Rick Edgecombe
> wrote:
>
> Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of
> vm_unmap_aliases() and fix calculation of the direct map for the
> CONFIG_ARCH_HAS_SET_DIRECT_MAP case.
>
> Meelis Roos reported issues with the new
On Mon, May 20, 2019 at 11:35 AM Rob Herring wrote:
>
> On Mon, May 20, 2019 at 8:18 AM Maxime Ripard
> wrote:
> >
> > Hi Rob,
> >
> > On Fri, May 10, 2019 at 02:40:18PM -0500, Rob Herring wrote:
> > > Convert the vendor prefix registry to a schema. This will enable checking
> > > that new
On 5/20/19 3:11 PM, Subash Abhinov Kasiviswanathan wrote:
> On 2019-05-20 07:53, Alex Elder wrote:
>> The C bit-fields in the first byte of the rmnet_map_header structure
>> are defined in the wrong order. The first byte should be formatted
>> this way:
>> +--- reserved_bit
On 21/05/19 6:54 AM, Kees Cook wrote:
> [Adding Chris and Ard, who might have more compiler versions that me...]
Late to the thread but ...
>
> On Mon, May 20, 2019 at 07:08:39PM +0200, H. Nikolaus Schaller wrote:
>>> Am 20.05.2019 um 17:59 schrieb Kees Cook :
>>>
>>> On Mon, May 20, 2019 at
On Tue, May 21, 2019 at 12:55:42PM +0800, Weifeng Voon wrote:
> From: "Tan, Tee Min"
>
> Currently ethtool was not able to get/set the flow control due to a
> missing "!". It will always return -EOPNOTSUPP even the device is
> flow control supported.
>
> This patch fixes the condition check for
On Mon, May 20, 2019 at 01:21:33PM -0700, Doug Anderson wrote:
> Hi,
>
> On Mon, May 20, 2019 at 10:01 AM Matthias Kaehlcke wrote:
> >
> > mickey crams a lot of hardware into a tiny package, which requires
> > more aggressive thermal throttling than for devices with a larger
> > footprint.
Correctness of format type (try or active) and pad ID parameters passed
to subdevice operation callbacks is now verified only for IOCTL calls.
However, those callbacks are also used by drivers, e.g., V4L2 host
interfaces.
Since both subdev_do_ioctl() and drivers are using v4l2_subdev_call()
On Thu, 2019-05-16 at 18:12 +0200, Roberto Sassu wrote:
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index 52e6fbb042cc..80e1c233656b 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++
On Mon, May 20, 2019 at 02:09:05PM -0700, Johannes Erdfelt wrote:
> On Mon, May 20, 2019, Joe Lawrence wrote:
> > [ fixed jeyu's email address ]
>
> Thank you, the bounce message made it seem like my mail server was
> blocked and not that the address didn't exist.
>
> I think MAINTAINERS needs
On Thu, 2019-05-16 at 18:12 +0200, Roberto Sassu wrote:
> This patch prevents memory access beyond the evm_tfm array by checking the
> validity of the index (hash algorithm) passed to init_desc(). The hash
> algorithm can be arbitrarily set if the security.ima xattr type is not
> EVM_XATTR_HMAC.
>
On 5/20/19 5:09 PM, Johannes Erdfelt wrote:
On Mon, May 20, 2019, Joe Lawrence wrote:
[ fixed jeyu's email address ]
Thank you, the bounce message made it seem like my mail server was
blocked and not that the address didn't exist.
I think MAINTAINERS needs an update since it still has the
Jacek
On 5/20/19 2:54 PM, Jacek Anaszewski wrote:
> Hi Dan,
>
> On 5/7/19 10:11 PM, Dan Murphy wrote:
>> Introduce the LM36274 LED driver. This driver uses the ti-lmu
>> MFD driver to probe this LED driver. The driver configures only the
>> LED registers and enables the outputs according to
Jerome Brunet writes:
> Add the hdmitx glue device linking the SoC audio interfaces to the
> embedded Synopsys hdmi controller.
>
> Signed-off-by: Jerome Brunet
Queued for v5.3,
> Hi Kevin,
>
> The related device driver and dt-binding have been merged in the ASoC
> tree, for-5.3 branch [0]
Jerome Brunet writes:
> Add bluetooth vbat and vddio power supplies
>
> Signed-off-by: Jerome Brunet
Queued for v5.3,
Kevin
Jerome Brunet writes:
> This patchset adds audio related devices to g12a SoC family.
> It adds the clock controller as well as the memory, tdm, spdif
> and pdm interfaces.
>
> At this stage, the HDMI and internal audio DAC are still missing.
>
> Notice the use of the pinconf DT property
Jerome Brunet writes:
> Add the i2c controllers and pinctrl definitions to the g12a DT then
> the busses present on the u200 and sei510.
>
> Notice the use of the pinconf DT property 'drive-strength-microamp'.
> Support for this property is not yet merged in meson pinctrl driver but
> the DT
On Mon, May 20, 2019 at 01:16:46PM -0700, Doug Anderson wrote:
> Hi,
>
> On Mon, May 20, 2019 at 10:01 AM Matthias Kaehlcke wrote:
> >
> > On rk3288 the CPU and GPU temperatures are correlated. Limit the GPU
> > frequency on veyron mickey to 300 MHz for CPU temperatures >= 85°C.
> >
> > This
On Mon, May 20, 2019, Joe Lawrence wrote:
> [ fixed jeyu's email address ]
Thank you, the bounce message made it seem like my mail server was
blocked and not that the address didn't exist.
I think MAINTAINERS needs an update since it still has the @redhat.com
address.
> On 5/20/19 3:49 PM,
Now we only have one implementation of rwsem. Even though we still use
xadd to handle reader locking, we use cmpxchg for writer instead. So
the filename rwsem-xadd.c is not strictly correct. Also no one outside
of the rwsem code need to know the internal implementation other than
function
After merging all the relevant rwsem code into one single file, there
are a number of optimizations and cleanups that can be done:
1) Remove all the EXPORT_SYMBOL() calls for functions that are not
accessed elsewhere.
2) Remove all the __visible tags as none of the functions will be
On Mon 2019-05-20 09:26:45, Gustavo A. R. Silva wrote:
>
>
> On 5/20/19 9:00 AM, Greg KH wrote:
> > On Mon, May 20, 2019 at 02:40:14PM +0200, Pavel Machek wrote:
> >>
> >> In lecd_attach, if arg is < 0, it was treated as 0. Spectre v1 fix
> >> changed that. Bug does not exist in mainline AFAICT.
The upper bits of the count field is used as reader count. When
sufficient number of active readers are present, the most significant
bit will be set and the count becomes negative. If the number of active
readers keep on piling up, we may eventually overflow the reader counts.
This is not likely
It is very unlikely that successive preemption at the middle of
down_read's inc-check-dec sequence will cause the reader count to
overflow, For absolute correctness, however, we still need to prevent
that possibility from happening. So preemption will be disabled during
the down_read*() call.
For
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 to disable lock stealing
and force lock handoff to the first waiter or
201 - 300 of 1647 matches
Mail list logo
