On (01/09/19 08:16), Helge Deller wrote:
> I prefer that change.
> In my role as admin of the parisc-linux.org domain I plan to retire
> all @parisc-linux.org email addresses soon anyway.
I see. Well, I can send a formal patch, but I think James
would know better which one of his email addresses
Hi Mason,
On Tue, Jan 8, 2019 at 5:17 AM Mason Yang wrote:
> Document the bindings used by the Renesas R-Car Gen3 RPC-IF controller.
>
> Signed-off-by: Mason Yang
Thanks for your patch!
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
> @@ -0,0 +1,37 @@
>
Hi, Vinod,
Thanks for your information. I will check with our IT.
Shunyong.
Thanks.
On 2019/1/9 15:00, Vinod Koul wrote:
> On 09-01-19, 01:35, Yang, Shunyong wrote:
>> Hi, Vinod and All,
>> I found, somtimes, I cannot received some mails from this mailing
>> list. For example, I sent my v2
"uattr->size" is copied in from user space and checked. However, it is
copied in again after the security check. A malicious user may race to
change it. The fix sets uattr->size to be the checked size.
Signed-off-by: Kangjie Lu
---
kernel/sched/core.c | 3 +++
1 file changed, 3 insertions(+)
On Wed, 9 Jan 2019 11:53:27 +0800
Zhao Yuanyuan wrote:
Hi Zhao,
> Its device will be removed after all events be freed.
> Undisarded events can lead to unpredictable behaviar.
>
> Signed-off-by: Zhao Yuanyuan
> ---
> drivers/irqchip/irq-gic-v3-its.c | 4
> 1 file changed, 4
On Wed, 2019-01-09 at 15:53 +1100, Alexey Kardashevskiy wrote:
> "A PCI completion timeout occurred for an outstanding PCI-E transaction"
> it is.
>
> This is how I bind the device to vfio:
>
> echo vfio-pci > '/sys/bus/pci/devices/:01:00.0/driver_override'
> echo vfio-pci >
Hi Jagan,
On Sat, Dec 15, 2018 at 08:48:00PM +0530, Jagan Teki wrote:
> Goodix CTP controllers have AVDD28 pin connected to voltage
> regulator which may not be turned on by default, like for GT5663.
>
> Add support for such ctp used boards by adding voltage regulator
> handling code to goodix
On Sat, Dec 15, 2018 at 08:47:59PM +0530, Jagan Teki wrote:
> Most of the Goodix CTP controllers are supply with AVDD28 pin.
> which need to supply for controllers like GT5663 on some boards
> to trigger the power.
>
> So, document the supply property so-that the require boards
> that used on
On Fri, Dec 21, 2018 at 02:46:33PM +0100, Philippe Schenker wrote:
> From: Philippe Schenker
>
> This patch removes common ADC settings in favor to use
> stmpe811_adc_common_init that is present in MFD. This is necessary in
> preparation for the stmpe-adc driver, because those two drivers have
>
From: Eric Biggers
kset_get_ownership() is only used in lib/kobject.c, so make it 'static'.
Signed-off-by: Eric Biggers
---
lib/kobject.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/kobject.c b/lib/kobject.c
index b72e00fd7d09e..aa89edcd2b63a 100644
---
On Wed 09-01-19 11:28:52, Arun KS wrote:
> On 2019-01-08 23:43, Michal Hocko wrote:
> > On Tue 08-01-19 09:56:09, Alexander Duyck wrote:
> > > On Fri, 2019-01-04 at 10:31 +0530, Arun KS wrote:
> > [...]
> > > > static int online_pages_range(unsigned long start_pfn, unsigned long
> > > >
On Thu 20-12-18 13:50:31, Qian Cai wrote:
> When booting a system with "page_owner=on",
>
> start_kernel
> page_ext_init
> invoke_init_callbacks
> init_section_page_ext
> init_page_owner
> init_early_allocated_pages
> init_zones_in_node
>
If set adapter->retries to minus value from user space via ioctl,
will make __i2c_transfer and __i2c_smbus_xfer jump the calling to
adapter->algo->master_xfer and adapter->algo->smbus_xfer that
registered by the underlying bus drivers, and return value 0 to
all the callers. The bus driver will
Vhost dirty page logging API is designed to sync through GPA. But we
try to log GIOVA when device IOTLB is enabled. This is wrong and may
lead to missing data after migration.
To solve this issue, when logging with device IOTLB enabled, we will:
1) reuse the device IOTLB translation result of
What we need is only "pack_id", so do not create a heap object or copy
the whole object in. The fix efficiently copies "pack_id" only and
also avoids double-fetch.
Signed-off-by: Kangjie Lu
---
drivers/scsi/sg.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git
On Tue, 08 Jan 2019, Enric Balletbo Serra wrote:
> Missatge de Lee Jones del dia dv., 21 de des.
> 2018 a les 16:39:
> >
> > On Wed, 12 Dec 2018, Enric Balletbo i Serra wrote:
> >
> > > Hi,
> > >
> > > This is another patchset to try to cleanup a bit more the crossed
> > > references for cros-ec
On Wed, 2019-01-09 at 17:32 +1100, Alexey Kardashevskiy wrote:
> I have just moved the "Mellanox Technologies MT27700 Family
> [ConnectX-4]" from garrison to firestone machine and there it does not
> produce an EEH, with the same kernel and skiboot (both upstream + my
> debug). Hm. I cannot really
On Tue, 2019-01-08 at 23:31 +, Russell King - ARM Linux wrote:
> On Tue, Jan 08, 2019 at 06:58:04PM +0100, Lubomir Rintel wrote:
> > The OLPC XO 1.75 laptop is rebooted with a command to the Embedded
> > Controller. The EC driver should be a module, since most people don't need
> > it to be
Good morning Linus,
Please accept my apologies for the lateness.
Christmas holidays, yada yada yada! :)
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the Git repository at:
From: Heiner Kallweit
linux 5.0-rc1 shows following warning on bpi-r2/mt7623 bootup:
[ 5.170597] WARNING: CPU: 3 PID: 1 at drivers/net/phy/phy.c:548
phy_start_aneg+0x110/0x144
[ 5.178826] called from state READY
[ 5.264111] [] (phy_start_aneg) from []
(mtk_init+0x414/0x47c)
[ 5.271630]
Good morning Linus,
Please accept my apologies for the lateness.
Christmas holidays, yada yada yada! :)
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the Git repository at:
Commit-ID: ee412f14693a3fe2645b3528603dfd37dd05118a
Gitweb: https://git.kernel.org/tip/ee412f14693a3fe2645b3528603dfd37dd05118a
Author: Arnaldo Carvalho de Melo
AuthorDate: Tue, 8 Jan 2019 13:53:23 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 8 Jan 2019 14:09:33 -0300
Commit-ID: fdc42ca190c7d8976f4f9240752f0bd008270b72
Gitweb: https://git.kernel.org/tip/fdc42ca190c7d8976f4f9240752f0bd008270b72
Author: Arnaldo Carvalho de Melo
AuthorDate: Tue, 8 Jan 2019 13:48:14 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 8 Jan 2019 14:09:33 -0300
Commit-ID: 1c23397d2a6a077ab32f01c01406c2fe61b7b3a4
Gitweb: https://git.kernel.org/tip/1c23397d2a6a077ab32f01c01406c2fe61b7b3a4
Author: Arnaldo Carvalho de Melo
AuthorDate: Tue, 8 Jan 2019 13:46:43 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 8 Jan 2019 14:09:33 -0300
On 09.01.19 06:39, Sergey Senozhatsky wrote:
> On (01/08/19 08:44), Helge Deller wrote:
>> Date: Tue, 8 Jan 2019 08:44:19 +0100
>> From: Helge Deller
>> To: Sergey Senozhatsky , "James E . J .
>> Bottomley"
>> Cc: linux-par...@vger.kernel.org, linux-kernel@vger.kernel.org, Sergey
>>
Commit-ID: f2e14cd2c93699aa0aeaa8240457ab359f1258ff
Gitweb: https://git.kernel.org/tip/f2e14cd2c93699aa0aeaa8240457ab359f1258ff
Author: Arnaldo Carvalho de Melo
AuthorDate: Tue, 8 Jan 2019 10:56:59 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 8 Jan 2019 13:28:13 -0300
Commit-ID: 250bfc87ddc427fa001bbc8bc1468ce5fc06645b
Gitweb: https://git.kernel.org/tip/250bfc87ddc427fa001bbc8bc1468ce5fc06645b
Author: Arnaldo Carvalho de Melo
AuthorDate: Tue, 8 Jan 2019 13:42:37 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 8 Jan 2019 14:09:28 -0300
Commit-ID: 9231967e2f515fce9e19687c0c40dfda416b3512
Gitweb: https://git.kernel.org/tip/9231967e2f515fce9e19687c0c40dfda416b3512
Author: Tzvetomir Stoyanov
AuthorDate: Fri, 30 Nov 2018 23:08:13 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 8 Jan 2019 13:28:13 -0300
tools
Commit-ID: 4104e604277016b3e6a7d120368054f9d2716953
Gitweb: https://git.kernel.org/tip/4104e604277016b3e6a7d120368054f9d2716953
Author: Tzvetomir Stoyanov
AuthorDate: Fri, 30 Nov 2018 23:08:12 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 8 Jan 2019 13:28:13 -0300
tools
Commit-ID: f87ce7c43f36d4abff91b19edadd23939f99ff98
Gitweb: https://git.kernel.org/tip/f87ce7c43f36d4abff91b19edadd23939f99ff98
Author: Tzvetomir Stoyanov
AuthorDate: Fri, 30 Nov 2018 23:08:11 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 8 Jan 2019 13:28:13 -0300
tools
Commit-ID: 6d2d6fd7e3ee0daf0d8308741792b3ec41aafd0c
Gitweb: https://git.kernel.org/tip/6d2d6fd7e3ee0daf0d8308741792b3ec41aafd0c
Author: Tzvetomir Stoyanov
AuthorDate: Fri, 30 Nov 2018 23:08:10 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 8 Jan 2019 13:28:13 -0300
tools
Commit-ID: eed14f4b075ec594ac09921b998bf3dd61f5886b
Gitweb: https://git.kernel.org/tip/eed14f4b075ec594ac09921b998bf3dd61f5886b
Author: Tzvetomir Stoyanov
AuthorDate: Fri, 30 Nov 2018 23:08:08 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 8 Jan 2019 13:28:13 -0300
tools
Commit-ID: 2e4318a287bdf815140462257ab8697f5289a12f
Gitweb: https://git.kernel.org/tip/2e4318a287bdf815140462257ab8697f5289a12f
Author: Tzvetomir Stoyanov
AuthorDate: Fri, 30 Nov 2018 23:08:09 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 8 Jan 2019 13:28:13 -0300
tools
Commit-ID: 21327c7843e9169d5e2e527713e60e6c9842a56c
Gitweb: https://git.kernel.org/tip/21327c7843e9169d5e2e527713e60e6c9842a56c
Author: Florian Fainelli
AuthorDate: Thu, 20 Dec 2018 19:43:37 -0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 8 Jan 2019 13:28:13 -0300
perf
Commit-ID: ca3958b1c0968a6f3105e211355f128ce871e796
Gitweb: https://git.kernel.org/tip/ca3958b1c0968a6f3105e211355f128ce871e796
Author: Tzvetomir Stoyanov
AuthorDate: Fri, 30 Nov 2018 10:44:11 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 8 Jan 2019 13:28:13 -0300
tools
Commit-ID: 011532379b7c2de6757e129037bdfc8d704bce23
Gitweb: https://git.kernel.org/tip/011532379b7c2de6757e129037bdfc8d704bce23
Author: Florian Fainelli
AuthorDate: Thu, 20 Dec 2018 19:43:36 -0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 8 Jan 2019 13:28:13 -0300
perf
If the streamon ioctl is issued while the stream is already on, then the
kernel BUGs. This happens at the BUG_ON in uvc_video_alloc_requests
within the call stack from the ioctl handler for VIDIOC_STREAMON.
This could happen when uvc_function_set_alt 0 races and wins against
uvc_v4l2_streamon, or
Commit-ID: ac6e022cbfdce215ad545e91d9827060855da3d7
Gitweb: https://git.kernel.org/tip/ac6e022cbfdce215ad545e91d9827060855da3d7
Author: Arnaldo Carvalho de Melo
AuthorDate: Mon, 7 Jan 2019 16:54:38 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 8 Jan 2019 13:28:12 -0300
If the streamon ioctl is issued while the stream is already on, then the
kernel BUGs. This happens at the BUG_ON in uvc_video_alloc_requests
within the call stack from the ioctl handler for VIDIOC_STREAMON.
This can also be triggered by starting the stream and then physically
disconnecting usb.
Reception of a SET_INTERFACE request with a non-zero alternate setting
signals the start of the video stream. The gadget has to enable the
video streaming endpoint and to signal stream start to userspace, in
order to start receiving video frames to transmit over USB. As userspace
can be slow to
Hi Pavel,
On 09/01/2019 0.59, Pavel Machek wrote:
Hi!
Grab yourself an RGB LED and play with it; you'll see what the
problems are. It is hard to explain colors over email...
Video [0] gives some overview of lp5024 capabilities.
I don't see any problems in exposing separate red,green,blue
Down the call stack from the ioctl handler for VIDIOC_STREAMON,
uvc_video_alloc_requests contains a BUG_ON, which in the high level,
triggers when VIDIOC_STREAMON ioctl is issued without VIDIOC_STREAMOFF
being issued previously.
This can happen in a few ways, such as if the userspace uvc gadget
Defined in uvc.h, uvc_endpoint_stream doesn't exist, and
uvc_function_connect, uvc_function_disconnect, and
uvc_function_setup_continue have duplicates in f_uvc.h.
Remove these four function prototypes from uvc.h
Signed-off-by: Paul Elder
---
drivers/usb/gadget/function/uvc.h | 10 --
1
Handling short packets (length < max packet size) in the Inventra DMA
engine in the MUSB driver causes the MUSB DMA controller to hang. An
example of a problem that is caused by this problem is when streaming
video out of a UVC gadget, only the first video frame is transferred.
For short packets
Implement the mechanism for optional explicit status stage for the MUSB
driver. This allows a function driver to specify what to reply for the
status stage. The functionality for an implicit status stage is
retained.
Signed-off-by: Paul Elder
v1 Reviewed-by: Laurent Pinchart
v1 Acked-by: Bin
A usb gadget function driver may or may not want to delay the status
stage of a control OUT request. An instance where it might want to is to
asynchronously validate the data of a class-specific request.
A function driver that wants an explicit status stage should set the
newly added
Currently, for uvc class-specific control IN and OUT requests, in the
setup handler a UVC_EVENT_SETUP with the setup control is enqueued to
userspace. In response to this, the uvc function driver expects
userspace to call ioctl UVCIOC_SEND_RESPONSE containing uvc request
data.
In the case of
V4L2_EVENT_PRIVATE_START is used in g_uvc.h but is defined in
videodev2.h, which is not included and causes a compiler warning:
linux/usb/g_uvc.h:15:28: error: ‘V4L2_EVENT_PRIVATE_START’ undeclared here (not
in a function)
#define UVC_EVENT_FIRST (V4L2_EVENT_PRIVATE_START + 0)
Include
We now have a mechanism to signal the UDC driver to reply to a control
OUT request with STALL or ACK, and we have packaged the setup stage data
and the data stage data of a control OUT request into a single
UVC_EVENT_DATA for userspace to consume. The ioctl UVCIOC_SEND_RESPONSE
in the case of a
This patch series adds a mechanism to allow asynchronously validating
the data stage of a control OUT request, and for stalling or suceeding
the request accordingly. This mechanism is implemented for MUSB, and is
used by UVC. At the same time, UVC packages the setup stage and data
stage data
Commit-ID: 172bf02d564bdb6df8410f64720fa2c68e755d1a
Gitweb: https://git.kernel.org/tip/172bf02d564bdb6df8410f64720fa2c68e755d1a
Author: Arnaldo Carvalho de Melo
AuthorDate: Mon, 7 Jan 2019 16:24:27 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 8 Jan 2019 13:28:12 -0300
Since "usb: gadget: uvc: enqueue uvc_request_data in setup handler
for control OUT requests" it is no longer necessary for userspace to
call ioctl UVCIOC_SEND_RESPONSE in response to receiving a
UVC_EVENT_SETUP from the uvc function driver for a control OUT request.
This change means that for
On Tue, Jan 08, 2019 at 04:48:02PM -0800, Roman Kiryanov wrote:
> > Also, why is this driver needed at all? Why can't you use the "normal"
> > drm sync api interface? Why write a custom ioctl driver just for this
> > one kernel interface?
>
> This driver allows us to talk to host's sync api.
Am Mittwoch, 9. Januar 2019, 07:58:28 CET schrieb James Bottomley:
Hi James,
> On Wed, 2019-01-09 at 07:45 +0100, Stephan Mueller wrote:
> > Am Mittwoch, 9. Januar 2019, 01:44:31 CET schrieb James Bottomley:
> >
> > Hi James,
> >
> > > Actually, it would be enormously helpful if we could reuse
perf-core-for-mingo-4.21-20190104' of
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent
> (2019-01-08 16:31:19 +0100)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> tags/perf-core-f
On 09-01-19, 01:35, Yang, Shunyong wrote:
> Hi, Vinod and All,
> I found, somtimes, I cannot received some mails from this mailing
> list. For example, I sent my v2 series on 7th, Jan,
>
> https://patchwork.kernel.org/project/linux-dmaengine/list/?series=62713
>
> It appeared on
Move mipi_dsi_dcs_set_display_off() from innolux_panel_disable()
to innolux_panel_unprepare(), so they are consistent with
innolux_panel_enable() and innolux_panel_prepare().
This also fixes some mode check and irq timeout issue in MTK dsi code.
Since some dsi code (e.g. mtk_dsi) have following
* Kees Cook wrote:
> This was already picked up by x86-urgent...
>
> -Kees
I'm fine with both routes - if Linus pulls this I'll zap the x86/urgent
one.
Thanks,
Ingo
On Wed, 2019-01-09 at 07:45 +0100, Stephan Mueller wrote:
> Am Mittwoch, 9. Januar 2019, 01:44:31 CET schrieb James Bottomley:
>
> Hi James,
>
> > Actually, it would be enormously helpful if we could reuse these
> > pieces for the TPM as well.
>
> Could you please help me understand whether
CCing more people
On Wed, Jan 9, 2019 at 2:45 PM Kairui Song wrote:
>
> Currenly with "efi=noruntime" in kernel command line, calling
> kexec_file_load will raise below problem:
>
> [ 97.967067] BUG: unable to handle kernel NULL pointer dereference at
>
> [ 97.967894] #PF
CCing more people
On Wed, Jan 9, 2019 at 2:47 PM Kairui Song wrote:
>
> When efi=noruntime or efi=oldmap is used, EFI services won't be available
> in the second kernel, therefore the second kernel will not be able to get
> the ACPI RSDP address from firmware by calling EFI services and won't
>
On Tue, Jan 8, 2019 at 10:11 PM Sasha Levin wrote:
>
> From: Matthew Bobrowski
>
> [ Upstream commit 2d10b23082a7eb8be508b3789f2e7250a88a5ddb ]
>
> Modify fanotify_should_send_event() so that it now returns a mask for
> an event that contains ONLY flags for the event types that have been
>
On Tue, 2019-01-08 at 17:43 -0800, Andy Lutomirski wrote:
> [Adding Jarkko because this stuff relates to the TPM.]
>
> On Tue, Jan 8, 2019 at 4:44 PM James Bottomley
> wrote:
> >
> > On Tue, 2019-01-08 at 15:54 -0800, Andy Lutomirski wrote:
> > > > On Jan 7, 2019, at 11:09 PM, Stephan Mueller
When efi=noruntime or efi=oldmap is used, EFI services won't be available
in the second kernel, therefore the second kernel will not be able to get
the ACPI RSDP address from firmware by calling EFI services and won't
boot. Previously we are expecting the user to set the acpi_rsdp=
on kernel
Hi Jacek,
On 07/01/2019 23.13, Jacek Anaszewski wrote:
Hi Vesa,
On 1/5/19 1:39 AM, Vesa Jääskeläinen wrote:
Hi Jacek,
On 04/01/2019 23.37, Jacek Anaszewski wrote:
But, aside from that hypothetic issue, we need a solution for
LEDn_BRIGHTNESS feature of lp5024, i.e. setting color intensity
Am Mittwoch, 9. Januar 2019, 01:44:31 CET schrieb James Bottomley:
Hi James,
> Actually, it would be enormously helpful if we could reuse these pieces
> for the TPM as well.
Could you please help me understand whether the KDFs in TPM are directly
usable as a standalone cipher primitive or
Currenly with "efi=noruntime" in kernel command line, calling
kexec_file_load will raise below problem:
[ 97.967067] BUG: unable to handle kernel NULL pointer dereference at
[ 97.967894] #PF error: [normal kernel read fault]
...
[ 97.980456] Call Trace:
[ 97.980724]
On 09/01/2019 16:30, David Gibson wrote:
> On Wed, Jan 09, 2019 at 04:09:02PM +1100, Benjamin Herrenschmidt wrote:
>> On Mon, 2019-01-07 at 21:01 -0700, Jason Gunthorpe wrote:
>>>
In a very cryptic way that requires manual parsing using non-public
docs sadly but yes. From the look of
Le 09/01/2019 à 02:14, Kees Cook a écrit :
On Fri, Dec 14, 2018 at 7:26 AM Christophe Leroy
wrote:
Introduce lkdtm tests for NULL pointer dereference: check
access or exec at NULL address.
Why is this not already covered by the existing tests? (Is there
something special about NULL that
On 2019/1/8 21:24, Sidong Yang wrote:
> Add identifier for function definition arguments in xattr_iter_handlers,
> this change clears the checkpatch.pl issue and make code more explicit.
>
> Signed-off-by: Sidong Yang
Reviewed-by: Chao Yu
Thanks,
Am Mittwoch, 9. Januar 2019, 00:54:22 CET schrieb Andy Lutomirski:
Hi Andy,
>
> I think that, if the crypto API is going to grow a KDF facility, it should
> be done right. Have a key type or flag or whatever that says “this key may
> *only* be used to derive keys using such-and-such algorithm”,
On Sun, Jan 6, 2019 at 6:33 PM Xiaochun Lee wrote:
>
> From: Xiaochun Lee
>
> The header file "intel.h" is repeated here, So delete one.
>
> Signed-off-by: Xiaochun Lee
Thanks, applied.
By the way, no need for a cover letter if it's only one patch.
On Sat, Jan 5, 2019 at 12:09 AM Xiaochun Lee wrote:
>
> From: Xiaochun Lee
>
> The function to_acpi_nfit_desc and function to_acpi_desc
> do the same things,delete the function to_acpi_nfit_desc,
> and keep the inline function to_acpi_desc.
>
> Signed-off-by: Xiaochun Lee
Good catch, thanks,
On Tue, Jan 8, 2019 at 9:03 PM Nathan Chancellor
wrote:
>
> On arm64 little endian allyesconfig:
>
> drivers/acpi/nfit/intel.c:149:12: warning: unused function
> 'intel_security_unlock' [-Wunused-function]
> static int intel_security_unlock(struct nvdimm *nvdimm,
>^
>
On 2019-01-09 03:47, Alexander Duyck wrote:
On Fri, 2019-01-04 at 10:31 +0530, Arun KS wrote:
When freeing pages are done with higher order, time spent on
coalescing
pages by buddy allocator can be reduced. With section size of 256MB,
hot
add latency of a single section shows improvement from
Hi Dan,
On 07/01/2019 21.34, Dan Murphy wrote:
Vesa
On 1/4/19 6:39 PM, Vesa Jääskeläinen wrote:
Hi Jacek,
On 04/01/2019 23.37, Jacek Anaszewski wrote:
But, aside from that hypothetic issue, we need a solution for
LEDn_BRIGHTNESS feature of lp5024, i.e. setting color intensity
via a single
My Bad, Onwards I will submit a new version of the RFC patch to address the
reviewer comments on previous RFC patch and for query or suggestions, I will
definitely cc Linux-wireless in my mail without any external link or attachment.
Thanks,
Prasanna
-Original Message-
From: Kalle Valo
On 2019/1/9 12:38, Jaegeuk Kim wrote:
> On 01/07, Chao Yu wrote:
>> On 2019/1/5 4:33, Jaegeuk Kim wrote:
>>> On 01/04, Sahitya Tummala wrote:
On Mon, Nov 26, 2018 at 10:17:20AM +0530, Sahitya Tummala wrote:
> When there is a failure in f2fs_fill_super() after/during
> the recovery of
On Mon, 2019-01-07 at 21:01 -0700, Jason Gunthorpe wrote:
>
> > In a very cryptic way that requires manual parsing using non-public
> > docs sadly but yes. From the look of it, it's a completion timeout.
> >
> > Looks to me like we don't get a response to a config space access
> > during the
Hello Thiago,
Wish you a happy 2019!
On Sat, Dec 08, 2018 at 12:40:52AM -0200, Thiago Jung Bauermann wrote:
>
> Gautham R Shenoy writes:
> > On Fri, Dec 07, 2018 at 04:13:11PM +0530, Gautham R Shenoy wrote:
> >> Sure. I will test the patch and report back.
> >
> > I added the following debug
On Tue, Jan 08, 2019 at 07:39:44PM +, Dmitrii Tcvetkov wrote:
> Hello,
>
> Don't have anything against listed patches, just curious: doesn't upstream
> commit
> 574823bfab82d9d8fa47f422778043fbb4b4f50e
> (Change mincore() to count "mapped" pages rather than "cached" pages)
> need to be
On 2019-01-08 23:43, Michal Hocko wrote:
On Tue 08-01-19 09:56:09, Alexander Duyck wrote:
On Fri, 2019-01-04 at 10:31 +0530, Arun KS wrote:
[...]
> static int online_pages_range(unsigned long start_pfn, unsigned long
nr_pages,
>void *arg)
> {
> - unsigned long i;
>
The mtk_thermal struct contains a 'struct mtk_thermal_bank banks[];',
but the allocation only allocates sizeof(struct mtk_thermal) bytes,
which cause out of bound access with the ->banks[] member. Change it to
a fixed size array instead.
Signed-off-by: Pi-Hsun Shih
---
I didn't pay enough attention. Seems to be a temp problem
on parisc-linux.org side:
: There was a temporary problem delivering your message to jejb at
parisc-linux.org.
:
: The response was:
:
: The recipient server did not accept our requests to connect.
: [mail.parisc-linux.org. 140.ZZZ.X.YY:
Because of just only one set of rcu_state, the declaration of
rcu_sched_state/rcu_bh_state/rcu_preempt_state is unnecessary.
Signed-off-by: Peng Hao
---
kernel/rcu/tree.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index 703e19f..9ea704c
On Tue, Jan 8, 2019 at 9:36 PM Shakeel Butt wrote:
>
> On Tue, Jan 8, 2019 at 8:01 PM Rik van Riel wrote:
> >
> > There is an imbalance between when slab_pre_alloc_hook calls
> > memcg_kmem_get_cache and when slab_post_alloc_hook calls
> > memcg_kmem_put_cache.
> >
>
> Can you explain how there
On Wed, Jan 09, 2019 at 04:09:02PM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2019-01-07 at 21:01 -0700, Jason Gunthorpe wrote:
> >
> > > In a very cryptic way that requires manual parsing using non-public
> > > docs sadly but yes. From the look of it, it's a completion timeout.
> > >
> > >
On (01/08/19 08:44), Helge Deller wrote:
> Date: Tue, 8 Jan 2019 08:44:19 +0100
> From: Helge Deller
> To: Sergey Senozhatsky , "James E . J .
> Bottomley"
> Cc: linux-par...@vger.kernel.org, linux-kernel@vger.kernel.org, Sergey
> Senozhatsky
> Subject: Re: [PATCH] parisc: replace
Greetings,
KVM seems to be busted in master ATM. All I have to do to have host
start screaming and maybe exploding (if the guest doesn't do so first)
is to try to install a (obese in this case) kernel over nfs mount of
the host in a guest.
Kernel producing the spew below is 3bd6e94, config
On Tue, Jan 8, 2019 at 8:01 PM Rik van Riel wrote:
>
> There is an imbalance between when slab_pre_alloc_hook calls
> memcg_kmem_get_cache and when slab_post_alloc_hook calls
> memcg_kmem_put_cache.
>
Can you explain how there is an imbalance? If the returned kmem cache
from
On Wed, Jan 9, 2019 at 1:36 AM Anatol Pomozov wrote:
>
> Hello
>
> On Tue, Jan 8, 2019 at 4:02 PM Andrea Parri
> wrote:
> >
> > Hi Anatol,
> >
> > On Tue, Jan 08, 2019 at 11:33:39AM -0800, Anatol Pomozov wrote:
> > > Hello folks,
> > >
> > > A bit of context what I am doing. I am trying to port
On 1/7/2019 9:47 PM, Raju P L S S S N wrote:
On 1/4/2019 2:49 AM, Stephen Boyd wrote:
Quoting Raju P L S S S N (2019-01-03 04:22:58)
On 12/29/2018 3:08 AM, Stephen Boyd wrote:
Quoting Raju P L S S S N (2018-12-26 01:44:43)
There are two RSC devices in SoC one for application processor
From: Huaisheng Ye
Add intro and usage guide for reinit.
Signed-off-by: Huaisheng Ye
---
Documentation/device-mapper/writecache.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/device-mapper/writecache.txt
b/Documentation/device-mapper/writecache.txt
index
From: Huaisheng Ye
writecache_flush_region doesn't use size to calculate flush region.
That uses _set_bits to mark the region in dirty_bitmap directly.
Signed-off-by: Huaisheng Ye
---
drivers/md/dm-writecache.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
From: Huaisheng Ye
writecache_flush_region only works when SSD mode.
If wc->pmem_mode sets, writecache_flush_region doesn't need to be called in
writecache_flush_entry.
Signed-off-by: Huaisheng Ye
---
drivers/md/dm-writecache.c | 2 --
1 file changed, 2 deletions(-)
diff --git
From: Huaisheng Ye
When use persistent memory as cache data device, sometimes
the super block of pmem has messy data stored in it. That would
have risk to lead fn ctr failed to work due to invalid magic or
version.
Here we expand pmem_reinit to optional parameters in order to solve
this issue.
From: Huaisheng Ye
This patch set could be used for dm-writecache when use persistent
memory as cache data device.
Patch 1 and 2 go towards removing unused parameter and codes which
actually doesn't really work.
Patch 3 and 4 are targeted at solving problem fn ctr failed to work
due to invalid
> On Tue, Jan 08, 2019 at 11:27:11AM -0800, Huang, Kai wrote:
> > > >
> > > > Can one of you explain why SGX_ENCLAVE_CREATE is better than just
> > > > opening a new instance of /dev/sgx for each encalve?
> > >
> > > Directly associating /dev/sgx with an enclave means /dev/sgx can't
> > > be used
Hi Jens,
May I ask whether this patch is acceptable?
Thanks,
On 12/18, Jaegeuk Kim wrote:
> If we don't drop caches used in old offset or block_size, we can get old data
> from new offset/block_size, which gives unexpected data to user.
>
> For example, Martijn found a loopback bug in the
On Tue, Jan 8, 2019 at 8:31 PM Michael S. Tsirkin wrote:
>
> Linus, given that you just changed all users of access_ok anyway, do
> you still think that the access_ok() conversion to return a speculation
> sanitized pointer or NULL is too big a conversion?
I didn't actually change a single
1 - 100 of 1482 matches
Mail list logo