On 8/1/20 4:36 AM, Pavel Begunkov wrote:
> Use a local var to collect flags in kiocb_set_rw_flags(). That spares
> some memory writes and allows to replace most of the jumps with MOVEcc.
I've picked this one up.
--
Jens Axboe
On 8/1/20 9:37 AM, Matthew Wilcox wrote:
> On Sat, Aug 01, 2020 at 01:36:33PM +0300, Pavel Begunkov wrote:
>> Use a local var to collect flags in kiocb_set_rw_flags(). That spares
>> some memory writes and allows to replace most of the jumps with MOVEcc.
>>
>> Signed-off-by: Pavel Begunkov
>
>
On Fri, Jul 31, 2020 at 10:35:14PM -0700, Kees Cook wrote:
> On Fri, Jul 31, 2020 at 09:47:55PM -0400, Arvind Sankar wrote:
> > On Fri, Jul 31, 2020 at 04:08:16PM -0700, Kees Cook wrote:
> > > For readability, move the zero-sized sections to the end after DISCARDS
> > > and mark them NOLOAD for
The last else branch of current code may have not io waited in iocg,
in which case we should not inc nr_shortages, or the device vrate
will speed up even this iocg is not shortage of vtime.
Signed-off-by: Chengming Zhou
---
block/blk-iocost.c | 2 +-
1 file changed, 1 insertion(+), 1
On 7/31/20 9:57 PM, Brian Vazquez wrote:
While running some experiments it was observed that map_lookup_batch was much
slower than get_next_key + lookup when the syscall overhead is minimal.
This was because the map_lookup_batch implementation was more expensive
traversing empty buckets, this
The function guarantees type checking of arguments and return value.
Result of rtw_netdev_priv macro can be assigned to pointer
with incompatible type without warning. The function allow compiler
to perform this check.
Signed-off-by: Ivan Safonov
---
Changes in v2:
- add blank line after
On Tue, 2020-07-28 at 17:09 +0200, Rafael J. Wysocki wrote:
> Hi All,
>
> On Monday, July 27, 2020 5:13:40 PM CEST Rafael J. Wysocki wrote:
> > On Thursday, July 16, 2020 7:37:04 PM CEST Rafael J. Wysocki wrote:
> > > This really is a v2 of this patch:
> > >
> > >
On Fri, Jul 31, 2020 at 8:51 PM Randy Dunlap wrote:
>
> On 7/31/20 8:25 PM, Dan Williams wrote:
> > Disable parsing of the HMAT for debug, to workaround broken platform
> > instances, or cases where it is otherwise not wanted.
> >
> > ---
> > arch/x86/mm/numa.c |2 ++
> >
On Sun, 26 Jul 2020 19:40:26 +0530
Nishant Malpani wrote:
> Add devicetree binding document for ADXRS290, a dual-axis MEMS gyroscope.
>
> Reviewed-by: Rob Herring
> Signed-off-by: Nishant Malpani
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play
On Sun, 26 Jul 2020 19:40:16 +0530
Nishant Malpani wrote:
> ADXRS290 is a high performance MEMS pitch and roll (dual-axis in-plane)
> angular rate sensor (gyroscope) designed for use in stabilization
> applications. It also features an internal temperature sensor and
> programmable high-pass and
syzbot has bisected this issue to:
commit 43ff7f53de2294a83dcf84b35de6ffa1ffafae9d
Author: Bhumika Goyal
Date: Thu Oct 6 18:10:01 2016 +
Staging: vc04_services: vchiq_arm: Remove unused function
remote_event_destroy
bisection log:
On Sat, Aug 01, 2020 at 09:21:30AM +0200, Uwe Kleine-König wrote:
> On Sun, Jul 26, 2020 at 03:00:59PM -0700, Guenter Roeck wrote:
> > Since commit c5cd2b47b203 ("platform/chrome: cros_ec_proto: Report command
> > not supported") we can no longer assume that cros_ec_cmd_xfer_status()
> > reports
If hci_uart_tty_close() or hci_uart_unregister_device() is called while
hu->init_ready is scheduled, hci_register_dev() could be called after
the hci_uart is torn down. Avoid this by ensuring the work is complete
or canceled before checking the HCI_UART_REGISTERED flag.
Fixes: 9f2aee848fe6
Since commit cba736465e5c ("Bluetooth: hci_serdev: Remove setting of
HCI_QUIRK_RESET_ON_CLOSE."), this flag is ignored for hci_serdev users,
so let's remove setting it.
Signed-off-by: Samuel Holland
---
drivers/bluetooth/hci_h5.c | 2 --
1 file changed, 2 deletions(-)
diff --git
Hi!
> > There's something very wrong with /dev/ttyUSB4 in recent kernels:
> > unsolicited incoming data from the modem are getting lost; I believe
> > it means also SMS notifications, but it is very easy to reproduce with
> > incoming call notifications.
> >
> > They just don't come.
> >
> >
On 8/1/20 10:43 AM, Samuel Holland wrote:
> This code attempts to set the HCI_UART_RESET_ON_INIT flag. However,
> it sets the bit in the wrong flag word: HCI_UART_RESET_ON_INIT goes in
> hu->hdev_flags, not hu->flags. So it is actually setting
> HCI_UART_REGISTERED, which is bit 1 in hu->flags.
>
On Sat, Aug 01, 2020 at 11:20:44AM -0400, Peilin Ye wrote:
> ptrace_get_syscall_info() is potentially copying uninitialized stack
> memory to userspace, since the compiler may leave a 3-byte hole near the
> beginning of `info`. Fix it by adding a padding field to `struct
> ptrace_syscall_info`.
>
On Fri, Jul 31, 2020 at 08:33:25PM +0200, Daniel Vetter wrote:
> On Fri, Jul 31, 2020 at 6:47 PM Melissa Wen wrote:
> >
> > On 07/31, Sidong Yang wrote:
> > > On Fri, Jul 31, 2020 at 11:08:34AM +0200, dan...@ffwll.ch wrote:
> > > > On Thu, Jul 30, 2020 at 07:09:25AM -0300, Melissa Wen wrote:
> >
On Tue, 28 Jul 2020 06:24:03 +
"Berghe, Darius" wrote:
> Hi Jonathan,
>
> Thanks for review, comments inline.
>
> > -Original Message-
> > From: Jonathan Cameron
> > Sent: Monday, July 27, 2020 8:27 PM
> > To: Berghe, Darius
> > Cc: linux-...@vger.kernel.org;
This test doesn't work well and newer compilers are much better
at emitting this warning.
Signed-off-by: Joe Perches
---
> 在 2020年8月1日，02:05，Joe Perches 写道：
> > On Wed, 2020-07-29 at 20:59 +0800, Cambda Zhu wrote:
> > > The checkpatch.pl only searches 3 previous lines when finding missing
> >
On Mon, 27 Jul 2020 16:57:13 +0200
Christian Eggers wrote:
> iio_trigger_poll() calls generic_handle_irq(). This function expects to
> be run with local IRQs disabled.
Was there an error or warning that lead to this patch?
Or can you point to what call in generic_handle_irq is making the
Add initial dts support for Xiaomi Poco F1 (Beryllium).
This initial support is based on upstream Dragonboard 845c
(sdm845) device. With this dts, Beryllium boots AOSP up to
ADB shell over USB-C.
Supported functionality includes UFS, USB-C (peripheral),
microSD card and Vol+/Vol-/power keys.
On Thu, 30 Jul 2020 12:18:56 +0200
Christian Eggers wrote:
> Hi Jonathan.
>
> got your review nearly simultaneous with Andy's. There are many overlaps
> between both. Most is already integrated, below I left only the open points.
>
> On Tuesday, 28 July 2020, 20:01:14 CEST, Jonathan Cameron
Link status is emitted on multiple lines as it does not use
KERN_CONT.
Coalesce the multi-part logging into a single line output and
add missing KERN_ to a couple logging calls.
This also reduces object size.
Signed-off-by: Joe Perches
---
drivers/net/ethernet/via/via-velocity.c | 46
This patchset is fine.
Please add.
Reviewed-by: Tom Rix
Thanks
Tom
On 7/23/20 7:09 PM, Xu Yilun wrote:
> A new bus type "dfl" is introduced for private features which are not
> initialized by DFL feature drivers (dfl-fme & dfl-afu drivers). So these
> private features could be handled by
Should change my Signed-off-by to
Reviewed-by: Tom Rix
On 7/23/20 7:09 PM, Xu Yilun wrote:
> This patch makes preparation for modularization of DFL sub feature
> drivers.
>
> Currently, if we need to support a new DFL sub feature, an entry should
> be added to fme/port_feature_drvs[] in
This code attempts to set the HCI_UART_RESET_ON_INIT flag. However,
it sets the bit in the wrong flag word: HCI_UART_RESET_ON_INIT goes in
hu->hdev_flags, not hu->flags. So it is actually setting
HCI_UART_REGISTERED, which is bit 1 in hu->flags.
Since commit cba736465e5c ("Bluetooth: hci_serdev:
When using HCI_UART_INIT_PENDING, hci_register_dev is not called from
hci_uart_register_device. Instead, it is called by hci_uart_init_work,
which is enqueued by hci_uart_init_ready (as hu->init_ready). In the
case of the hci_h5 proto, hci_uart_init_ready is called only after
handshaking with the
On 7/31/20 12:48 AM, Xu Yilun wrote:
> On Sat, Jul 25, 2020 at 06:29:53AM -0700, Tom Rix wrote:
>> It would be good if the variable or element for the feature id had a
>> consistent name.
>>
>>
>>> @@ -197,7 +197,7 @@ int dfl_fpga_check_port_id(struct platform_device
>>> *pdev, void
On Wed, 29 Jul 2020 13:38:28 +0300
Andy Shevchenko wrote:
> On Wed, Jul 29, 2020 at 11:12 AM Ankit Baluni
> wrote:
> >
> > Added a missing comma and changed 'it it useful' to 'it is useful'.
>
> Reviewed-by: Andy Shevchenko
Gah. I had kind of forgotten these docs existed and they have
On Sat, Aug 01, 2020 at 01:36:33PM +0300, Pavel Begunkov wrote:
> Use a local var to collect flags in kiocb_set_rw_flags(). That spares
> some memory writes and allows to replace most of the jumps with MOVEcc.
>
> Signed-off-by: Pavel Begunkov
Reviewed-by: Matthew Wilcox (Oracle)
If you want
See below.
On 7/31/20 1:56 AM, Xu Yilun wrote:
> On Sat, Jul 25, 2020 at 07:53:59AM -0700, Tom Rix wrote:
>> Mostly little stuff.
>>
>> The polling on the int in ns_bus_poll_stat_timeout should be refactored.
>>
>> Tom
>>
>> On 7/23/20 7:09 PM, Xu Yilun wrote:
>>> This patch adds support for the
Waiting for response at
https://lkml.kernel.org/r/45a9b2c8-d0b7-8f00-5b30-0cfe3e028...@i-love.sakura.ne.jp
.
#syz dup: INFO: task hung in pipe_write (4)
On Fri, 31 Jul 2020 09:01:14 +0200
Christian Eggers wrote:
> Support for AMS AS73211 JENCOLOR(R) Digital XYZ Sensor.
>
> This driver has no built-in trigger. In order for making triggered
> measurements, an external (software) trigger driver like
> iio-trig-hrtimer or iio-trig-sysfs is
Hi Song,
I love your patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url:
https://github.com/0day-ci/linux/commits/Song-Liu/introduce-BPF_PROG_TYPE_USER/20200801-165208
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: i386
ptrace_get_syscall_info() is potentially copying uninitialized stack
memory to userspace, since the compiler may leave a 3-byte hole near the
beginning of `info`. Fix it by adding a padding field to `struct
ptrace_syscall_info`.
Cc: sta...@vger.kernel.org
Fixes: 201766a20e30 ("ptrace: add
From: Tom Rix
Clang static analysis reports this error
cdc-acm.c:409:3: warning: Use of memory after it is freed
acm_process_notification(acm, (unsigned char *)dr);
There are three problems, the first one is that dr is not reset
The variable dr is set with
if (acm->nb_index)
On Sat, Aug 01, 2020 at 02:06:46PM +0300, Dmitry V. Levin wrote:
> On Fri, Jul 31, 2020 at 10:08:41PM -0400, Peilin Ye wrote:
> > ptrace_get_syscall_info() is potentially copying uninitialized stack
> > memory to userspace, since the compiler may leave a 3-byte hole near the
> > beginning of
On Fri, 31 Jul 2020 10:48:38 -0600
Daniel Campello wrote:
> Adds device tree bandings for sx9310 sensor.
>
> Signed-off-by: Daniel Campello
> Cc: Hartmut Knaack
> Cc: Lars-Peter Clausen
> Cc: Peter Meerwald-Stadler
> Cc: Rob Herring
> Reviewed-by: Douglas Anderson
> [swb...@chromium.org:
On Fri, 31 Jul 2020 22:46:55 +0300
Andy Shevchenko wrote:
> On Fri, Jul 31, 2020 at 7:49 PM Daniel Campello wrote:
> >
> > From: Stephen Boyd
> >
> > We shouldn't need to set default irq trigger flags here as the firmware
> > should have properly indicated the trigger type, i.e. level low, in
Currently, the top Makefile includes all of scripts/Makefile.
even if the associated CONFIG option is disabled.
Do not include unneeded Makefiles in order to slightly optimize the
parse stage.
Include $(include-y), and ignore $(include-).
Signed-off-by: Masahiro Yamada
---
Makefile
Commit d26e94149276 ("kbuild: no gcc-plugins during cc-option tests")
was neeeded because scripts/Makefile.gcc-plugins was too early.
This is unneeded by including scripts/Makefile.gcc-plugins last,
and being careful to not add cc-option tests after it.
Signed-off-by: Masahiro Yamada
---
On Fri, 31 Jul 2020 22:24:47 +0300
Andy Shevchenko wrote:
> On Fri, Jul 31, 2020 at 7:49 PM Daniel Campello wrote:
> >
> > Makes use __aligned(8) to ensure that the timestamp is correctly aligned
> > when we call io_push_to_buffers_with_timestamp().
> > Also makes use of sizeof() for
merged into cifs-2.6.git for-next
On Fri, Jul 31, 2020 at 12:15 PM Colin King wrote:
>
> From: Colin Ian King
>
> Currently if the call dfs_cache_get_tgt_share fails we cannot
> fully guarantee that share and prefix are set to NULL and the
> next iteration of the loop can end up potentially
On Fri, 31 Jul 2020 10:48:39 -0600
Daniel Campello wrote:
> Follows spec sheet for macro declarations.
>
> Signed-off-by: Daniel Campello
> Reviewed-by: Stephen Boyd
I'm fairly sure this patch breaks bisection as you've renamed
one macro without changing everywhere it's used.
The driver has
Hi,
On Fri, Jun 26, 2020 at 04:06:41PM +0300, Cristian Ciocaltea wrote:
> On Fri, Jun 26, 2020 at 12:50:46PM +0530, Manivannan Sadhasivam wrote:
> >
> >
> > On 26 June 2020 1:46:18 AM IST, Cristian Ciocaltea
> > wrote:
> > >Add pinctrl and gpio bindings for Actions Semi S500 SoC.
> > >
> >
On Sat, Aug 01, 2020 at 11:00:26AM +0300, Dan Carpenter wrote:
> > Without an actual example where this doesn't work right it is hard to
> > say anything more..
>
> Here is the example that set off the recent patches:
>
> https://lkml.org/lkml/2020/7/27/199
Oh, that is something completely
On Sat, Aug 1, 2020 at 2:02 PM Bernard Zhao wrote:
> The function "int drm_panel_add(struct drm_panel *panel)"
> always returns 0, this return value is meaningless.
> Also, there is no need to check return value which calls
> "drm_panel_add and", error branch code will never run.
>
>
Hi Linus,
a last minute pin control fix to the Qualcomm driver.
Please pull it in!
Yours,
Linus Walleij
The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:
Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)
are available in the Git repository at:
Hi Song,
I love your patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url:
https://github.com/0day-ci/linux/commits/Song-Liu/introduce-BPF_PROG_TYPE_USER/20200801-165208
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: riscv
Remove cxgbi_alloc_big_mem(), cxgbi_free_big_mem() functions
and use kvzalloc/kvfree instead. __GFP_NOWARN added to kvzalloc()
call because we already print a warning in case of allocation fail.
Signed-off-by: Denis Efremov
---
drivers/scsi/cxgbi/libcxgbi.c | 8
On Sat, Aug 1, 2020 at 8:46 AM Xie He wrote:
>
> On Fri, Jul 31, 2020 at 7:33 PM Willem de Bruijn
> wrote:
> >
> > I quickly scanned the main x.25 datapath code. Specifically
> > x25_establish_link, x25_terminate_link and x25_send_frame. These all
> > write this 1 byte header. It appears to be
On 8/1/20 11:10 AM, Joe Perches wrote:
> On Sat, 2020-08-01 at 10:51 +0300, Denis Efremov wrote:
>> On 8/1/20 1:24 AM, Joe Perches wrote:
>>> On Sat, 2020-08-01 at 01:10 +0300, Denis Efremov wrote:
On 8/1/20 12:58 AM, Joe Perches wrote:
> On Sat, 2020-08-01 at 00:55 +0300, Denis
On Sat, Aug 01, 2020 at 04:11:38PM +0300, Ivan Safonov wrote:
> On 8/1/20 12:51 PM, Greg Kroah-Hartman wrote:
> > On Sat, Aug 01, 2020 at 12:47:07PM +0300, Ivan Safonov wrote:
> > > The function guarantees type checking of arguments and return value.
> > >
> > > Signed-off-by: Ivan Safonov
> > >
On 8/1/20 12:51 PM, Greg Kroah-Hartman wrote:
On Sat, Aug 01, 2020 at 12:47:07PM +0300, Ivan Safonov wrote:
The function guarantees type checking of arguments and return value.
Signed-off-by: Ivan Safonov
---
drivers/staging/rtl8188eu/include/osdep_service.h | 6 --
1 file changed, 4
When reserving crashkernel in high memory, some low memory is reserved
for crash dump kernel devices and never mapped by the first kernel.
This memory range is advertised to crash dump kernel via DT property
under /chosen,
linux,usable-memory-range =
We reused the DT property
Expose variable arm64_dma32_phys_limit for followup, and add macro
CRASH_ALIGN for alignment, macro CRASH_ADDR_LOW_MAX for upper bound
of low crash memory. Use macros instead.
Signed-off-by: Chen Zhou
---
arch/arm64/include/asm/kexec.h | 5 +
arch/arm64/include/asm/processor.h | 1 +
Now the behavior of crashkernel=X has been changed, which tries low
allocation in ZONE_DMA, and fall back to high allocation if it fails.
If requized size X is too large and leads to very little free memory
in ZONE_DMA after low allocation, the system may not work well.
So add a threshold and go
In preparation for supporting reserve_crashkernel_low in arm64 as
x86_64 does, move reserve_crashkernel_low() into kernel/crash_core.c.
BTW, move x86_64 CRASH_ALIGN to 2M suggested by Dave. CONFIG_PHYSICAL_ALIGN
can be selected from 2M to 16M, move to the same as arm64.
Signed-off-by: Chen Zhou
There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel below 4G, which
will fail when there is no enough low memory.
2. If reserving crashkernel above 4G, in this case, crash dump
kernel will boot failure because there is no low memory available
for allocation.
There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel below 4G, which
will fail when there is no enough low memory.
2. If reserving crashkernel above 4G, in this case, crash dump
kernel will boot failure because there is no low memory available
for allocation.
On Sat, Aug 01, 2020 at 01:24:29PM +0200, Saheed O. Bolarinwa wrote:
> The return value of pci_read_config_*() may not indicate a device error.
> However, the value read by these functions is more likely to indicate
> this kind of error. This presents two overlapping ways of reporting
> errors and
On Sat, Aug 1, 2020 at 2:28 PM Masahiro Yamada wrote:
>
> samples/auxdisplay/Makefile | 3 +--
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Sat, Aug 01, 2020 at 08:47:24AM +0200, Corentin Labbe wrote:
>
> This is fixed in my v4 serie and the current driver is unaffected, only
> hashes/rng could hit a problem and v4 bring them along with the fix.
OK. Please resubmit it once you've rebased it against cryptodev.
Thanks,
--
Email:
On Fri, Jul 31, 2020 at 7:33 PM Willem de Bruijn
wrote:
>
> I quickly scanned the main x.25 datapath code. Specifically
> x25_establish_link, x25_terminate_link and x25_send_frame. These all
> write this 1 byte header. It appears to be an in-band communication
> means between the network and data
On Mon, Jul 20, 2020 at 4:46 AM Alexander A. Klimov
wrote:
>
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't
Lay the groundwork for adding Epoch Subsystem (EPSS) L3 support on
SM8250.
Signed-off-by: Sibi Sankar
---
drivers/interconnect/qcom/osm-l3.c | 37 +-
1 file changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/interconnect/qcom/osm-l3.c
Add Epoch Subsystem (EPSS) L3 interconnect provider node on SM8250
SoCs.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index
Add Operation State Manager (OSM) L3 interconnect provider node on
SM8150 SoCs.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index
Add Operation State Manager (OSM) L3 interconnect provider binding on
SM8150 SoCs.
Signed-off-by: Sibi Sankar
---
Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml
Add Epoch Subsystem (EPSS) L3 interconnect provider support on
SM8250 SoCs.
Signed-off-by: Sibi Sankar
---
drivers/interconnect/qcom/osm-l3.c | 23 +++
drivers/interconnect/qcom/sm8250.h | 2 ++
2 files changed, 25 insertions(+)
diff --git
Add Operation State Manager (OSM) L3 provider support on SM8150 and Epoch
Subsystem (EPSS) L3 provider support on SM8250 SoCs.
Depends on: https://patchwork.kernel.org/cover/11687925/
Sibi Sankar (7):
dt-bindings: interconnect: Add OSM L3 DT binding on SM8150
interconnect: qcom: Add OSM L3
Add Operation State Manager (OSM) L3 interconnect provider support on
SM8150 SoCs.
Signed-off-by: Sibi Sankar
---
drivers/interconnect/qcom/osm-l3.c | 15 +++
drivers/interconnect/qcom/sm8150.h | 2 ++
2 files changed, 17 insertions(+)
diff --git
Add Epoch Subsystem (EPSS) L3 interconnect provider binding on SM8250
SoCs.
Signed-off-by: Sibi Sankar
---
.../devicetree/bindings/interconnect/qcom,osm-l3.yaml | 1 +
include/dt-bindings/interconnect/qcom,osm-l3.h | 3 +++
2 files changed, 4 insertions(+)
diff --git
To build host programs, you need to add the program names to 'hostprogs'
to use the necessary build rule, but it is not enough to build them
because there is no dependency.
There are two types of host programs: built as the prerequisite of
another (e.g. gen_crc32table in lib/Makefile), or always
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of
On Thu, Jul 30, 2020 at 04:26:17PM +, Alexander Lobakin wrote:
> From: Andy Shevchenko
> Date: Thu, 30 Jul 2020 18:59:20 +0300
>
> > Convert to %pM instead of using custom code.
> Thanks!
>
> Acked-by: Alexander Lobakin
Thanks, but no-one sees this properly (seems broken message-id ->
ERROR: modpost: "__cpu_logical_map" [drivers/cpufreq/tegra194-cpufreq.ko]
undefined!
ARM64 tegra194-cpufreq driver use cpu_logical_map, export
__cpu_logical_map to fix build issue.
I wonder why like other instances in the drivers, the mpidr is not get
directly from the cpu. The
Please, skip this patch. I missed that kvmalloc checks (flags & GFP_KERNEL) ==
GFP_KERNEL
before calling vmalloc.
P.S.: previous mail was filtered because of html tags.
Thanks,
Denis
On 8/1/20 12:28 AM, Denis Efremov wrote:
> Use kvmalloc instead of opencoded kmalloc/vmalloc condition.
>
>
The function "int drm_panel_add(struct drm_panel *panel)"
always returns 0, this return value is meaningless.
Also, there is no need to check return value which calls
"drm_panel_add and", error branch code will never run.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/drm_panel.c
On Fri, Jul 31, 2020 at 3:40 PM Ahmad Fatoum wrote:
>
> Commit 959bc7b22bd2 ("gpio: Automatically add lockdep keys") documents
> in its commits message its intention to "create a unique class key for
> each driver".
>
> It does so by having gpiochip_add_data add in-place the definition of
> two
On Wed, May 27, 2020 at 3:53 PM Arnd Bergmann wrote:
>
> When using the clang integrated assembler, we get a reference
> to __force_order that should normally get ignored in a few
> rare cases:
>
> ERROR: modpost: "__force_order" [drivers/cpufreq/powernow-k6.ko] undefined!
>
> Add a 'static'
On Sat, Aug 1, 2020 at 11:38 AM kernel test robot wrote:
Thanks and sorry folks, Hulk robot was faster, and TBH their patch
looks much better (proper commit message applied). Perhaps something
LKP should work on?
> Fixes: e33929537b76 ("platform/x86: thinkpad_acpi: use standard charge
>
101 - 200 of 279 matches
Mail list logo
