On Tue, Apr 20, 2021 at 11:14 PM Vineet Gupta
wrote:
> On 4/20/21 12:07 AM, Arnd Bergmann wrote:
> >
> > which means that half the 32-bit architectures do this. This may
> > cause more problems when arc and/or microblaze want to support
> > 64-bit kernels and compat
On Tue, Apr 20, 2021 at 1:44 AM Dominique MARTINET
wrote:
> Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200:
> > For built-in drivers, load order depends on the initcall level and
> > link order (how things are lined listed in the Makefile hierarchy).
> >
>
On Tue, Apr 20, 2021 at 1:44 AM Dominique MARTINET
wrote:
> Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200:
> > For built-in drivers, load order depends on the initcall level and
> > link order (how things are lined listed in the Makefile hierarchy).
> >
>
On Tue, Apr 20, 2021 at 5:10 AM Matthew Wilcox wrote:
>
> On Tue, Apr 20, 2021 at 02:48:17AM +, Vineet Gupta wrote:
> > > 32-bit architectures which expect 8-byte alignment for 8-byte integers
> > > and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
> > > page inadvertently e
setting the buffer size to be
> the number of bytes left in the buffer, namely sizeof(buf) - pos.
>
> Addresses-Coverity: ("Out-of-bounds access")
> Fixes: 7b0e2c4f6be3 ("wlcore: fix overlapping snprintf arguments in debugfs")
> Signed-off-by: Colin Ian King
Acked-by: Arnd Bergmann
On Mon, Apr 19, 2021 at 11:33 AM Dominique MARTINET
wrote:
> Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200:
>
> > soc_device_match() should only be used as a last resort, to identify
> > systems that cannot be identified otherwise. Typically this is used for
> > quirks, which
On Sat, Apr 17, 2021 at 3:58 PM Matthew Wilcox wrote:
> I wouldn't like to make that assumption. I've come across IOMMUs (maybe
> on parisc? powerpc?) that like to encode fun information in the top
> few bits. So we could get it down to 52 bits, but I don't think we can
> get all the way down t
On Fri, Apr 16, 2021 at 5:27 PM Matthew Wilcox wrote:
> diff --git a/include/net/page_pool.h b/include/net/page_pool.h
> index b5b195305346..db7c7020746a 100644
> --- a/include/net/page_pool.h
> +++ b/include/net/page_pool.h
> @@ -198,7 +198,17 @@ static inline void page_pool_recycle_direct(struct
On Fri, Apr 16, 2021 at 11:27 AM 'Grygorii Strashko' via Clang Built
Linux wrote:
> On 10/04/2021 11:52, Ilias Apalodimas wrote:
> > +CC Grygorii for the cpsw part as Ivan's email is not valid anymore
> The TI platforms am3/4/5 (cpsw) and Keystone 2 (netcp) can do only 32bit DMA
> even in case of
On Wed, Apr 14, 2021, 00:42 Stephen Hemminger
wrote:
>
> On Tue, 13 Apr 2021 16:16:17 +0200 Arnd Bergmann wrote:
>
> > */
> > static struct devprobe2 isa_probes[] __initdata = {
> > -#if defined(CONFIG_HP100) && defined(CONFIG_ISA) /* ISA, EISA */
>
From: Arnd Bergmann
The driver was removed last year, but the static initialization got left
behind by accident.
Fixes: a10079c66290 ("staging: remove hp100 driver")
Signed-off-by: Arnd Bergmann
---
drivers/net/Space.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/n
On Wed, Apr 7, 2021 at 2:24 AM Marek Behún wrote:
>
> The -Wextra flag enables -Woverride-init in newer versions of GCC.
>
> This causes the compiler to warn when a value is written twice in a
> designated initializer, for example:
> int x[1] = {
> [0] = 3,
> [0] = 3,
> };
>
> Note tha
On Tue, Mar 30, 2021 at 10:41 AM Michal Koutný wrote:
>
> On Mon, Mar 22, 2021 at 05:02:44PM +0100, Arnd Bergmann
> wrote:
> > I'm not sure what is expected to happen for such a configuration,
> > presumably these functions are never calls in that case.
> Yes, th
On Fri, Mar 26, 2021 at 3:53 AM Saeed Mahameed wrote:
>
> From: Saeed Mahameed
>
> The cited patch allocated the wrong size for the indirection_rqt table,
> fix that.
>
> Fixes: 2119bda642c4 ("net/mlx5e: allocate 'indirection_rqt' buffer
> dynamically
SIZE - 2],
int lane_count);
bool drm_dp_clock_recovery_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
int lane_count);
This obviously needs a good explanation in the code and the changelog text,
which I don't have, but if the above is what you had in mind, please take that
and add Reported-by/Tested-by: Arnd Bergmann .
Arnd
On Mon, Mar 22, 2021 at 11:43 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> There are a few warnings about empty debug macros in this driver:
>
> drivers/net/ethernet/neterion/vxge/vxge-main.c: In function 'vxge_probe':
> drivers/net/ethernet/neterion/
On Wed, Mar 24, 2021 at 2:29 PM Rasmus Villemoes
wrote:
> On 24/03/2021 14.07, Arnd Bergmann wrote:
>
> > if (set_settings & HILINK_LINK_SET_SPEED) {
> > speed_level = hinic_ethtool_to_hw_speed_level(speed);
> > err = snprintf(set_li
From: Arnd Bergmann
With extra warnings enabled, gcc complains that snprintf should not
take the same buffer as source and destination:
drivers/net/ethernet/huawei/hinic/hinic_ethtool.c: In function
'hinic_set_settings_to_hw':
drivers/net/ethernet/huawei/hinic/hinic_ethtool.c:48
From: Arnd Bergmann
gcc points out an incorrect enum assignment:
drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c: In function
'chcr_ktls_cpl_set_tcb_rpl':
drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c:684:22: warning:
implicit conversion from '
On Tue, Mar 23, 2021 at 3:42 PM Willem de Bruijn
wrote:
>
> On Tue, Mar 23, 2021 at 8:52 AM Arnd Bergmann wrote:
> >>
> A similar fix already landed in 5.12-rc3: commit b228c9b05876 ("net:
> expand textsearch ts_state to fit skb_seq_state"). That fix landed in
>
From: Arnd Bergmann
gcc-11 with KASAN on 32-bit arm produces a warning about a function
that needs a lot of stack space:
drivers/net/wireless/cisco/airo.c: In function 'setup_card.constprop':
drivers/net/wireless/cisco/airo.c:3960:1: error: the frame size of 1512 bytes
is larger
From: Arnd Bergmann
sprintf() is declared with a restrict keyword to not allow input and
output to point to the same buffer:
lib/test_rhashtable.c: In function 'print_ht':
lib/test_rhashtable.c:504:4: error: 'sprintf' argument 3 overlaps destination
object 'buff&
From: Arnd Bergmann
gcc complains about undefined behavior in calling snprintf()
with the same buffer as input and output:
drivers/net/wireless/ti/wl18xx/debugfs.c: In function
'diversity_num_of_packets_per_ant_read':
drivers/net/wireless/ti/wl18xx/../wlcore/debugfs.h:86:3: error:
From: Arnd Bergmann
With extra warnings enabled, gcc complains that snprintf should not
take the same buffer as source and destination:
drivers/net/ethernet/huawei/hinic/hinic_ethtool.c: In function
'hinic_set_settings_to_hw':
drivers/net/ethernet/huawei/hinic/hinic_ethtool.c:48
From: Arnd Bergmann
When compile testing this driver on a platform on which probe() is
known to fail at compile time, gcc warns about the cgx_lmactype_string[]
array being uninitialized:
In function 'strncpy',
inlined from 'link_status_user_format' at
/git/arm-soc/
From: Arnd Bergmann
gcc-11 warns that the TS_SKB_CB(&state)) cast in skb_find_text()
leads to an out-of-bounds access in skb_prepare_seq_read() after
the addition of a new struct member made skb_seq_state longer
than ts_state:
net/core/skbuff.c: In function ‘skb_find_text’:
net/core/skbu
On Mon, Mar 22, 2021 at 11:09 PM Martin Sebor wrote:
> On 3/22/21 2:29 PM, Ingo Molnar wrote:
> > * Arnd Bergmann wrote:
> >
> > I.e. the real workaround might be to turn off the
> > -Wstringop-overread-warning,
> > until GCC-11 gets fixed?
>
> In GC
From: Arnd Bergmann
gcc -Wextra wants type modifiers in the normal order:
kernel/bpf/bpf_lsm.c:70:1: error: 'static' is not at beginning of declaration
[-Werror=old-style-declaration]
70 | const static struct bpf_func_proto bpf_bprm_opts_set_proto = {
| ^
kernel/bpf/bpf_
From: Arnd Bergmann
The correct order is 'static const', not 'const static', as seen from
make W=1:
drivers/net/wireless/intel/iwlwifi/mvm/rfi.c:14:1: error: 'static' is not at
beginning of declaration [-Werror=old-style-declaration]
Fixes: 21254908cbe9 (&q
On Mon, Mar 22, 2021 at 9:29 PM Ingo Molnar wrote:
> * Arnd Bergmann wrote:
> > From: Arnd Bergmann
> This is indeed rather ugly - and the other patch that removes a debug
> check seems counterproductive as well.
>
> Do we know how many genuine bugs -Wstringop-overread-wa
From: Arnd Bergmann
gcc-11 points out that the declaration does not match the definition:
net/bluetooth/ecdh_helper.c:122:55: error: argument 2 of type ‘const u8[32]’
{aka ‘const unsigned char[32]’} with mismatched bound [-Werror=array-parameter=]
122 | int set_ecdh_privkey(struct crypto_kpp
From: Arnd Bergmann
gcc-11 complains about a prototype declaration that is different
from the function definition:
drivers/isdn/capi/kcapi.c:724:44: error: argument 2 of type ‘u8 *’ {aka
‘unsigned char *’} declared as a pointer [-Werror=array-parameter=]
724 | u16 capi20_get_manufacturer(u32
From: Arnd Bergmann
gcc-11 warns about an strnlen with a length larger than the size of the
passed buffer:
drivers/scsi/lpfc/lpfc_attr.c: In function 'lpfc_nvme_info_show':
drivers/scsi/lpfc/lpfc_attr.c:518:25: error: 'strnlen' specified bound 4095
exceeds source size
From: Arnd Bergmann
gcc-11 warns that intel_dp_check_mst_status() has a local array of
fourteen bytes and passes the last four bytes into a function that
expects a six-byte array:
drivers/gpu/drm/i915/display/intel_dp.c: In function
‘intel_dp_check_mst_status’:
drivers/gpu/drm/i915/display
From: Arnd Bergmann
gcc-11 warns about using string operations on pointers that are
defined at compile time as offsets from a NULL pointer. Unfortunately
that also happens on the result of fix_to_virt(), which is a
compile-time constant for a constantn input:
arch/x86/kernel/tboot.c: In
From: Arnd Bergmann
gcc-11 warns about what appears to be an out-of-range array access:
In function ‘snb_wm_latency_quirk’,
inlined from ‘ilk_setup_wm_latency’ at
drivers/gpu/drm/i915/intel_pm.c:3108:3:
drivers/gpu/drm/i915/intel_pm.c:3057:9: error: ‘intel_print_wm_latency’ reading
16
From: Arnd Bergmann
gcc-11 notices that the fields as defined in the ass_req_format
structure do not match the actual use of that structure:
cc1: error: writing 4 bytes into a region of size between 18446744073709551613
and 2 [-Werror=stringop-overflow=]
drivers/net/wireless/atmel/atmel.c:2884
From: Arnd Bergmann
gcc-11 introdces a harmless warning for cap_inode_getsecurity:
security/commoncap.c: In function ‘cap_inode_getsecurity’:
security/commoncap.c:440:33: error: ‘memcpy’ reading 16 bytes from a region of
size 0 [-Werror=stringop-overread]
440
From: Arnd Bergmann
When cgroups are enabled, but every single subsystem is turned off,
CGROUP_SUBSYS_COUNT is zero, and the cgrp->subsys[] array has no
members.
gcc-11 points out that this leads to an invalid access in any function
that might access this array:
kernel/cgroup/cgroup.c:
From: Arnd Bergmann
gcc warns that accessing a pointer based on a numeric constant may
be an offset into a NULL pointer, and would therefore has zero
accessible bytes:
arch/arm/common/sharpsl_param.c: In function ‘sharpsl_save_param’:
arch/arm/common/sharpsl_param.c:43:9: error: ‘memcpy
From: Arnd Bergmann
gcc-11 warns that the size of the link name is longer than the di_fname
field:
fs/qnx4/dir.c: In function ‘qnx4_readdir’:
fs/qnx4/dir.c:51:32: error: ‘strnlen’ specified bound 48 exceeds source size 16
[-Werror=stringop-overread]
51 | size
From: Arnd Bergmann
gcc-11 with the kernel address sanitizer prints a warning for this
driver:
In function 'ath11k_peer_assoc_h_vht',
inlined from 'ath11k_peer_assoc_prepare' at
drivers/net/wireless/ath/ath11k/mac.c:1632:2:
drivers/net/wireless/ath/ath11k/
From: Arnd Bergmann
gcc gets confused by the comparison of a pointer to an integer listeral,
with the assumption that this is an offset from a NULL pointer and that
dereferencing it is invalid:
In file included from arch/x86/boot/compressed/misc.c:18:
In function ‘parse_elf’,
inlined from
From: Arnd Bergmann
The coming gcc release introduces a new warning for string operations
reading beyond the end of a fixed-length object. After testing
randconfig kernels for a while, think I have patches for any such
warnings that came up on x86, arm and arm64.
Most of these warnings are
On Mon, Mar 22, 2021 at 2:58 PM Leon Romanovsky wrote:
>
> Thanks, interesting when we will delete whole drivers/isdn :)
>
> Reviewed-by: Leon Romanovsky
Not any time soon I think, Harald Welte mentioned that Osmocom
still relies on mISDN.
The CAPI stuff only remains because of net/bluetooth/cm
On Mon, Mar 22, 2021 at 1:08 PM Leon Romanovsky wrote:
> On Mon, Mar 22, 2021 at 12:24:20PM +0100, Arnd Bergmann wrote:
> > On Mon, Mar 22, 2021 at 11:55 AM Leon Romanovsky wrote:
> >
> > I don't care either way, I only kept it because it was apparently left there
>
From: Arnd Bergmann
gcc warns about a pointless condition:
drivers/isdn/hardware/mISDN/hfcmulti.c: In function 'hfcmulti_interrupt':
drivers/isdn/hardware/mISDN/hfcmulti.c:2752:17: error: suggest braces around
empty body in an 'if' statement [-Werr
From: Arnd Bergmann
When building with 'make W=1', clang warns about a mismatched
format string:
net/ipv6/ah6.c:710:4: error: format specifies type 'unsigned short' but the
argument has type 'int' [-Werror,-Wformat]
aalg_d
On Mon, Mar 22, 2021 at 11:55 AM Leon Romanovsky wrote:
> On Mon, Mar 22, 2021 at 11:43:31AM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > gcc warns about a pointless condition:
> >
> > drivers/isdn/hardware/mISDN/hfcmulti.c: In function '
From: Arnd Bergmann
There are a few warnings about empty debug macros in this driver:
drivers/net/ethernet/neterion/vxge/vxge-main.c: In function 'vxge_probe':
drivers/net/ethernet/neterion/vxge/vxge-main.c:4480:76: error: suggest braces
around empty body in an 'if' stat
From: Arnd Bergmann
Building without mesh supports shows a couple of warnings with
'make W=1':
drivers/net/wireless/marvell/libertas/main.c: In function 'lbs_start_card':
drivers/net/wireless/marvell/libertas/main.c:1068:37: error: suggest braces
around empty body in an &#x
From: Arnd Bergmann
There are a couple of warnings in this driver when building with W=1:
drivers/net/wireless/intel/iwlegacy/common.c: In function 'il_power_set_mode':
drivers/net/wireless/intel/iwlegacy/common.c:1195:60: error: suggest braces
around empty body in an 'if'
From: Arnd Bergmann
There are a couple of warnings in this driver when building with W=1:
net/dccp/output.c: In function 'dccp_xmit_packet':
net/dccp/output.c:283:71: error: suggest braces around empty body in an 'if'
statement [-Werror=empty-body]
283 |
From: Arnd Bergmann
gcc warns about a pointless condition:
drivers/isdn/hardware/mISDN/hfcmulti.c: In function 'hfcmulti_interrupt':
drivers/isdn/hardware/mISDN/hfcmulti.c:2752:17: error: suggest braces around
empty body in an 'if' statement [-Werr
On Sat, Mar 20, 2021 at 12:56 PM Linus Walleij wrote:
>
> Hi Dipen,
>
> thanks for your mail!
>
> I involved some other kernel people to get some discussion.
> I think Kent Gibson can be of great help because he is using
> GPIOs with high precision.
>
> We actually discussed this a bit when adding
On Thu, Mar 11, 2021 at 8:08 AM Krzysztof Kozlowski
wrote:
> On 10/03/2021 17:42, Arnd Bergmann wrote:
> > On Wed, Mar 10, 2021 at 4:54 PM Krzysztof Kozlowski
> > wrote:
> >> On 10/03/2021 16:47, Krzysztof Kozlowski wrote:
> >>> This edac Altera driv
On Wed, Mar 10, 2021 at 9:38 AM Krzysztof Kozlowski
wrote:
> --- a/drivers/clk/socfpga/Kconfig
> +++ b/drivers/clk/socfpga/Kconfig
> @@ -1,6 +1,17 @@
> # SPDX-License-Identifier: GPL-2.0
> +config COMMON_CLK_SOCFPGA
> + bool "Intel SoCFPGA family clock support" if COMPILE_TEST &&
> !ARCH_S
On Wed, Mar 10, 2021 at 4:54 PM Krzysztof Kozlowski
wrote:
> On 10/03/2021 16:47, Krzysztof Kozlowski wrote:
> > This edac Altera driver is very weird... it uses the same compatible
> > differently depending whether this is 32-bit or 64-bit (e.g. Stratix
> > 10)! On ARMv7 the compatible means for
On Wed, Mar 10, 2021 at 4:06 PM Krzysztof Kozlowski
wrote:
> On 10/03/2021 15:45, Tom Rix wrote:
> > On 3/10/21 1:45 AM, Lee Jones wrote:
>
> Many other architectures do not have vendor prefix (TEGRA, EXYNOS,
> ZYNQMP etc). I would call it the same as in ARMv7 - ARCH_SOCFPGA - but
> the Altera EDA
From: Arnd Bergmann
Increasing the size of the indirection_rqt array from 128 to 256 bytes
pushed the stack usage of the mlx5e_hairpin_fill_rqt_rqns() function
over the warning limit when building with clang and CONFIG_KASAN:
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:970:1: error: stack
From: Arnd Bergmann
drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:1510:12: error:
implicit declaration of function 'fib_info_nh'
[-Werror,-Wimplicit-function-declaration]
fib_dev = fib_info_nh(fen_info->fi, 0)->fib_nh_dev;
^
drivers/net/e
On Tue, Mar 2, 2021 at 1:52 AM Saeed Mahameed wrote:
> On Sat, 2021-02-27 at 13:14 +0100, Arnd Bergmann wrote:
> > On Fri, Feb 12, 2021 at 3:59 AM Saeed Mahameed
> > wrote:
> > >
> > > From: Parav Pandit
> > >
> > > rate_bytes
On Fri, Feb 12, 2021 at 3:59 AM Saeed Mahameed wrote:
>
> From: Parav Pandit
>
> rate_bytes_ps is a 64-bit field. It passed as 32-bit field to
> apply_police_params(). Due to this when police rate is higher
> than 4Gbps, 32-bit calculation ignores the carry. This results
> in incorrect rate confi
On Thu, Feb 25, 2021 at 4:52 PM DENG Qingfang wrote:
>
> Hi Arnd,
>
> On Thu, Feb 25, 2021 at 10:40 PM Arnd Bergmann wrote:
> >
> > From: Arnd Bergmann
> >
> > The new gpio support may be optional at runtime, but it requires
> > buildi
On Thu, Feb 25, 2021 at 4:07 PM Vladimir Oltean wrote:
> On Thu, Feb 25, 2021 at 03:49:08PM +0100, Arnd Bergmann wrote:
> > On Thu, Feb 25, 2021 at 3:47 PM Arnd Bergmann wrote:
> > > On Thu, Feb 25, 2021 at 3:43 PM Vladimir Oltean wrote:
> > > > On Thu, Feb 25,
From: Arnd Bergmann
Clang points out a mistake in the error handling in
mt7921_mcu_tx_rate_report(), which tries to dereference a pointer that
cannot be initialized because of the error that is being handled:
drivers/net/wireless/mediatek/mt76/mt7921/mcu.c:409:3: warning: variable
'stat
From: Arnd Bergmann
clang points out a possible corner case in the mt7915_tm_set_tx_cont()
function if called with invalid arguments:
drivers/net/wireless/mediatek/mt76/mt7915/testmode.c:593:2: warning: variable
'mode' is used uninitialized whenever switch default is taken
[-
From: Arnd Bergmann
When CONFIG_PM_SLEEP is disabled, the compiler warns about unused
functions:
drivers/net/phy/phy_device.c:273:12: error: unused function
'mdio_bus_phy_suspend' [-Werror,-Wunused-function]
static int mdio_bus_phy_suspend(struct device *dev)
drivers/net/phy/phy_de
On Thu, Feb 25, 2021 at 3:47 PM Arnd Bergmann wrote:
> On Thu, Feb 25, 2021 at 3:43 PM Vladimir Oltean wrote:
> > On Thu, Feb 25, 2021 at 03:38:32PM +0100, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > When the ocelot driver code is in a library
On Thu, Feb 25, 2021 at 3:43 PM Vladimir Oltean wrote:
>
> On Thu, Feb 25, 2021 at 03:38:32PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > When the ocelot driver code is in a library, the dsa tag
> > code cannot be built-in:
> >
From: Arnd Bergmann
The new gpio support may be optional at runtime, but it requires
building against gpiolib:
ERROR: modpost: "gpiochip_get_data" [drivers/net/dsa/mt7530.ko] undefined!
ERROR: modpost: "devm_gpiochip_add_data_with_key" [drivers/net/dsa/mt7530.ko]
undef
From: Arnd Bergmann
Without this option, the driver fails to link:
ld.lld: error: undefined symbol: devlink_sb_register
>>> referenced by ocelot_devlink.c
>>>
>>> net/ethernet/mscc/ocelot_devlink.o:(ocelot_devlink_sb_register) in archive
>>>
From: Arnd Bergmann
When the ocelot driver code is in a library, the dsa tag
code cannot be built-in:
ld.lld: error: undefined symbol: ocelot_can_inject
>>> referenced by tag_ocelot_8021q.c
>>> dsa/tag_ocelot_8021q.o:(ocelot_xmit) in archive net/built-i
From: Arnd Bergmann
A runtime check that was introduced recently failed to
check for the matching Kconfig symbol:
ld.lld: error: undefined symbol: iwl_so_trans_cfg
>>> referenced by drv.c
>>> net/wireless/intel/iwlwifi/pcie/drv.o:(iwl_pci_probe)
Fixes: 930be4e76
On Thu, Feb 25, 2021 at 12:52 PM Michael Ellerman wrote:
>
> Uwe Kleine-König writes:
> > The driver core ignores the return value of struct bus_type::remove()
> > because there is only little that can be done. To simplify the quest to
> > make this function return void, let struct vio_driver::re
From: Arnd Bergmann
The alternative implementation of this function in a header file
is declared as a global symbol, and gets added to every .c file
that includes it, which leads to a link error:
arm-linux-gnueabi-ld: drivers/net/ethernet/mellanox/mlx5/core/en_rx.o: in
function
On Thu, Feb 18, 2021 at 4:28 AM Min Li wrote:
> > If the driver can use the same algorithm that is in your user space software
> > today, that would seem to be a nicer way to handle it than requiring a
> > separate application.
> >
>
> Hi Arnd
>
>
> What is the device driver that you are referring
On Wed, Feb 17, 2021 at 9:20 PM Min Li wrote:
>
> I attached the G.8273.2 document, where chapter 6 is about supporting
> physical layer
> frequency. And combo mode is Renesas way to support this requirement. Other
> companies
> may come up with different ways to support it.
>
> When EEC quality
On Tue, Feb 16, 2021 at 11:14 PM Min Li wrote:
> > I can't help but think you are evading my question I asked. If there is no
> > specific action that this pcm4l tool needs to perform, then I'd think we
> > should better not provide any interface for it at all.
> >
> > I also found a reference to
On Tue, Feb 16, 2021 at 6:10 PM Min Li wrote:
> > > If I come up with a new file and move all the abstraction code there,
> > > does that work?
> >
> > I think so, but it's more important to figure out a good user space
> > interface
> > first. The ioctl interfaces should be written on a higher-l
On Tue, Feb 16, 2021 at 3:20 AM wrote:
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You
On Mon, Feb 15, 2021 at 10:23 AM Leon Romanovsky wrote:
> On Mon, Feb 15, 2021 at 04:28:09PM +0900, Nobuhiro Iwamatsu wrote:
> >
> > Sorry, I sent the wrong patchset that didn't fix this point out.
> >
> > > I asked it before, but never received an answer.
> >
> > I have received your point out an
On Fri, Feb 12, 2021 at 5:19 PM Min Li wrote:
>
> >
> > Ah, so if this is for a PTP related driver, it should probably be
> > integrated into
> > the PTP subsystem rather than being a separate class.
> >
>
> I was trying to add these functions to PHC subsystem but was not accepted
> because the
On Fri, Feb 12, 2021 at 4:03 AM Nobuhiro Iwamatsu
wrote:
> @@ -384,6 +398,16 @@ spi6: spi@28146000 {
> #size-cells = <0>;
> status = "disabled";
> };
> +
> + piether: ethernet@2800 {
> + compati
On Fri, Feb 12, 2021 at 2:40 AM Min Li wrote:
> > There should probably be a description of the purpose of the hardware both
> > here and in the patch description.
> >
> > In particular, please explain how it relates to the existing clockmatrix
> > driver.
>
> I just uploaded v2 patch to provide
From: Arnd Bergmann
Multiple structures in the carl9170 driver have alignment
impossible alignment constraints that gcc warns about when
building with 'make W=1':
drivers/net/wireless/ath/carl9170/fwcmd.h:243:2: warning: alignment 1 of 'union
' is less than 4 [-Wpacked-not-
From: Arnd Bergmann
sturct mwl8k_dma_data contains a ieee80211_hdr structure, which is required to
have at least two byte alignment, and this conflicts with the __packed
attribute:
vers/net/wireless/marvell/mwl8k.c:811:1: warning: alignment 1 of 'struct
mwl8k_dma_data' is less than 2
From: Arnd Bergmann
sturct d11txh contains a ieee80211_rts structure, which is required to
have at least two byte alignment, and this conflicts with the __packed
attribute:
drivers/net/wireless/broadcom/brcm80211/brcmsmac/d11.h:786:1: warning:
alignment 1 of 'struct d11txh' is l
From: Arnd Bergmann
struct wl3501_80211_tx_hdr contains a ieee80211_hdr structure, which is
required to have at least two byte alignment, and this conflicts with
the __packed attribute:
wireless/wl3501.h:553:1: warning: alignment 1 of 'struct wl3501_80211_tx_hdr'
is less than 2 [-W
From: Arnd Bergmann
struct ucan_message_in contains member with 4-byte alignment
but is itself marked as unaligned, which triggers a warning:
drivers/net/can/usb/ucan.c:249:1: warning: alignment 1 of 'struct
ucan_message_in' is less than 4 [-Wpacked-not-aligned]
Mark the outer st
From: Arnd Bergmann
clang points out a redundant sanity check:
drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c:497:28: error: address of
array 'filp->f_path.dentry->d_iname' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
This can never fail
ivers/net/dsa/hirschmann/hellcreek_sw.ko] undefined!
> > |ERROR: modpost: "taprio_offload_free"
> > [drivers/net/dsa/hirschmann/hellcreek_sw.ko] undefined!
> >
> > Fixes: 24dfc6eb39b2 ("net: dsa: hellcreek: Add TAPRIO offloading support")
> > Reported-by: Ra
From: Arnd Bergmann
When CONFIG_ATH9K is built-in but LED support is in a loadable
module, both ath9k drivers fails to link:
x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function
`ath_deinit_leds':
gpio.c:(.text+0x36): undefined reference to `led_classdev_unregister'
x8
From: Arnd Bergmann
Compile-testing without CONFIG_REMOTEPROC results in a build failure:
>>> referenced by ipa_main.c
>>> net/ipa/ipa_main.o:(ipa_probe) in archive drivers/built-in.a
ld.lld: error: undefined symbol: rproc_put
>>> referenced by ipa_main.
From: Arnd Bergmann
When TLS is a module, the built-in bonding driver may cause a
link error:
x86_64-linux-ld: drivers/net/bonding/bond_main.o: in function `bond_start_xmit':
bond_main.c:(.text+0xc451): undefined reference to `tls_validate_xmit_skb'
Add a dependency to avoid t
On Mon, Jan 25, 2021 at 12:40 PM Krzysztof Kozlowski wrote:
> On Mon, 25 Jan 2021 at 12:36, Arnd Bergmann wrote:
> >
> > From: Arnd Bergmann
> >
> > When CONFIG_ATH9K is built-in but LED support is in a loadable
> > module, both ath9k drivers fails to link:
>
On Mon, Jan 25, 2021 at 4:23 PM Bjorn Andersson
wrote:
>
> On Mon 25 Jan 05:35 CST 2021, Arnd Bergmann wrote:
>
> > From: Arnd Bergmann
> >
> > Compile-testing without CONFIG_REMOTEPROC results in a build failure:
> >
> > >>> referenced by ipa
On Mon, Jan 25, 2021 at 4:04 PM Krzysztof Kozlowski wrote:
> On Mon, 25 Jan 2021 at 15:38, Arnd Bergmann wrote:
> > On Mon, Jan 25, 2021 at 2:27 PM Krzysztof Kozlowski wrote:
>
> I meant that having MAC80211_LEDS selected causes the ath9k driver to
> toggle on/off the WiFi
On Mon, Jan 25, 2021 at 2:27 PM Krzysztof Kozlowski wrote:
> On Mon, 25 Jan 2021 at 14:09, Arnd Bergmann wrote:
> > On Mon, Jan 25, 2021 at 12:40 PM Krzysztof Kozlowski
> > wrote:
> > > On Mon, 25 Jan 2021 at 12:36, Arnd Bergmann wrote:
> > > But we do
From: Arnd Bergmann
An object file cannot be built for both loadable module and built-in
use at the same time:
arm-linux-gnueabi-ld: drivers/net/ethernet/micrel/ks8851_common.o: in function
`ks8851_probe_common':
ks8851_common.c:(.text+0xf80): undefined reference to `__this_module'
1 - 100 of 1869 matches
Mail list logo
