Re: [PATCH RFC 00/11] staging: vc04_services: Improve driver load/unload
Hi Stefan,
> This patch series improves the load/unload of bcm2835 camera and audio
> drivers. It has been tested with Raspberry Pi 3 B and a camera module V1.
>
> This series based on current linux-next and Phil Elwell's series ("Improve
> VCHIQ
> cache line size handling"). After Nicolas' series ("staging: vc04_services:
> Some dead code removal") has been applied, i will rebase my series.
I tried testing this series applied to 4.20 with the camera module. I
tried with qv4l2 (from v4l-utils) and using cheese, which in turn uses
gstreamer. I basically get the same crash for both options. Desktop is
LXDE on 32 bit Fedora 29.
I've not yet tried with 5.0-rc1 but it looks like it has this patch
series and some other bits for the vchiq drivers in staging.
Peter
[ 231.121704] bcm2835-v4l2: Failed enabling camera, ret -2
[ 231.127168] bcm2835-v4l2: Failed to enable camera
[ 231.132030] [ cut here ]
[ 231.136852] WARNING: CPU: 2 PID: 1473 at
drivers/media/common/videobuf2/videobuf2-core.c:1468
vb2_start_streaming+0xb4/0x12c [videobuf2_common]
[ 231.149967] Modules linked in: fuse ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack ebtable_nat ip6table_nat nf_nat_ipv6
ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat_ipv4
nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack
nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink
ebtable_filter ebtables ip6table_filter ip6_tables cmac bnep sunrpc
vfat fat brcmfmac brcmutil vc4 cfg80211 snd_soc_core bcm2835_v4l2(C)
ac97_bus snd_bcm2835(C) videobuf2_vmalloc snd_pcm_dmaengine
videobuf2_memops snd_seq videobuf2_v4l2 videobuf2_common
snd_seq_device v4l2_common snd_pcm videodev media snd_timer snd
soundcore drm_kms_helper drm hci_uart btqca joydev btbcm btintel
fb_sys_fops syscopyarea bluetooth sysfillrect gpio_raspberrypi_exp
sysimgblt raspberrypi_hwmon bcm2835_thermal ecdh_generic vchiq(C)
rfkill bcm2835_wdt bcm2835_rng leds_gpio cpufreq_dt lz4 lz4_compress
zram hid_logitech_hidpp hid_logitech_dj smsc95xx usbnet mii mmc_block
dwc2 sdhci_iproc crc32_arm_ce
[ 231.150208] sdhci_pltfm udc_core sdhci bcm2835 pwm_bcm2835
i2c_bcm2835 bcm2835_dma phy_generic
[ 231.248013] CPU: 2 PID: 1473 Comm: qv4l2 Tainted: G C
4.20.0-1.fc30.armv7hl #1
[ 231.256663] Hardware name: BCM2835
[ 231.260144] [] (unwind_backtrace) from []
(show_stack+0x18/0x1c)
[ 231.268013] [] (show_stack) from []
(dump_stack+0x80/0xa0)
[ 231.275357] [] (dump_stack) from [] (__warn+0xdc/0xf8)
[ 231.282349] [] (__warn) from []
(warn_slowpath_null+0x40/0x4c)
[ 231.290067] [] (warn_slowpath_null) from []
(vb2_start_streaming+0xb4/0x12c [videobuf2_common])
[ 231.300747] [] (vb2_start_streaming [videobuf2_common])
from [] (vb2_core_streamon+0x110/0x138 [videobuf2_common])
[ 231.313166] [] (vb2_core_streamon [videobuf2_common])
from [] (__video_do_ioctl+0x35c/0x494 [videodev])
[ 231.324681] [] (__video_do_ioctl [videodev]) from
[] (video_usercopy+0x508/0x5d4 [videodev])
[ 231.335120] [] (video_usercopy [videodev]) from
[] (vfs_ioctl+0x28/0x3c)
[ 231.343697] [] (vfs_ioctl) from []
(do_vfs_ioctl+0x8c/0x838)
[ 231.351212] [] (do_vfs_ioctl) from []
(ksys_ioctl+0x58/0x74)
[ 231.358726] [] (ksys_ioctl) from []
(ret_fast_syscall+0x0/0x54)
[ 231.366493] Exception stack(0xd7d53fa8 to 0xd7d53ff0)
[ 231.371623] 3fa0: 4a1bf700 b5edd000 000c
40045612 be905378 0001
[ 231.379930] 3fc0: 4a1bf700 b5edd000 40045612 0036 b5e40e40
000c b6f00508
[ 231.388230] 3fe0: be905378 be905368 b5ec6804 b5b9a1f0
[ 231.393434] ---[ end trace c5943cec7bb25669 ]---
[ 237.695591] list_add corruption. prev->next should be next
(ea4493e0), but was efeb6638. (prev=e126fa78).
[ 237.705362] [ cut here ]
[ 237.710056] kernel BUG at lib/list_debug.c:28!
[ 237.714569] Internal error: Oops - BUG: 0 [#1] SMP ARM
[ 237.719785] Modules linked in: fuse ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack ebtable_nat ip6table_nat nf_nat_ipv6
ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat_ipv4
nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack
nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink
ebtable_filter ebtables ip6table_filter ip6_tables cmac bnep sunrpc
vfat fat brcmfmac brcmutil vc4 cfg80211 snd_soc_core bcm2835_v4l2(C)
ac97_bus snd_bcm2835(C) videobuf2_vmalloc snd_pcm_dmaengine
videobuf2_memops snd_seq videobuf2_v4l2 videobuf2_common
snd_seq_device v4l2_common snd_pcm videodev media snd_timer snd
soundcore drm_kms_helper drm hci_uart btqca joydev btbcm btintel
fb_sys_fops syscopyarea bluetooth sysfillrect gpio_raspberrypi_exp
sysimgblt raspberrypi_hwmon bcm2835_thermal ecdh_generic vchiq(C)
rfkill bcm2835_wdt bcm2835_rng leds_gpio cpufreq_dt lz4 lz4_compress
zram hid_logitech_hidpp hid_logitech_dj smsc95xx usbnet mii mmc_block
dwc2 sdhci_iproc crc32_arm_ce
[ 237.720008] sdhci_pltfm udc_core sdhci bcm2835 pwm_bcm2835
i2c_bcm2835 bcm2835_dma phy_generic
[
Re: [PATCH] hv_balloon: avoid touching uninitialized struct page during tail onlining
On Mon, Jan 07, 2019 at 07:38:20PM +0100, Vitaly Kuznetsov wrote: > (I remember Greg disliked when people were tagging patches for stable@ > themselves, he prefered maintainers deciding if the particular commit > deserves stable@ or not - but as you have a tree now we may as well have > different rules :-) I don't recall ever saying I disliked that, unless people were tagging stuff that were obviously not stable material. Which, given the history of this codebase, was probably the case :) greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] media: staging/intel-ipu3: Fix err handle of ipu3_css_find_binary
On 01/07/2019 07:00 PM, Sakari Ailus wrote: Hi Bingbu, On Mon, Jan 07, 2019 at 10:38:19AM +0800, Bingbu Cao wrote: Hi, Haibing Thanks for your patch, it looks fine for me. Reviewed-by: Bingbu Cao On 12/29/2018 10:45 AM, YueHaibing wrote: css->pipes[pipe].bindex = binary; I'm taking Colin's patch with equivalent content; it was there first. Sakari, good to know that, thanks! Thanks! ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] staging: wilc1000: fix registration frame size
On 1/7/2019 8:13 PM, Július Milan wrote:
> Fixes the following sparse warnings:
>
> drivers/staging/wilc1000/host_interface.c:2360:30: warning:
> incorrect type in assignment (different base types)
> expected restricted __le32 [addressable] [assigned] [usertype] frame_type
> got restricted __le16 [usertype]
>
> Fixes: 147ccfd451024 ("staging: wilc1000: handle mgmt_frame_register ops from
> cfg82011 context")
> Signed-off-by: Július Milan
Thanks, the change looks fine to me.
Reviewed-by: Ajay Singh
Regards,
Ajay
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/2] staging: erofs: fixed -Wmissing-prototype warnings.
Hi Jeremy, On 2019/1/8 2:25, Jeremy Sowden wrote: > Fixes for -Wmissing-prototype warnings in the erofs driver. One group of > functions have been made static; for the second, prototypes have been moved > to a > head Is -Wmissing-prototypes required for the current linux kernel? I cannot see this warning in my personal kernel compilation... Functions your fix have already been added proper erofs prefix, therefore it wouldn't pollute the global namespace: z_erofs_vle_work_release z_erofs_unzip_lz4 erofs_try_to_release_workgroup erofs_workgroup_free_rcu z_erofs_map_blocks_iter some thought? Thanks, Gao Xiang ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [linux-sunxi] [PATCH v2 1/2] media: v4l: Add definitions for the HEVC slice format and controls
Sent from my iPad
> On Jan 7, 2019, at 5:57 PM, Paul Kocialkowski
> wrote:
>
> Hi,
>
>> On Mon, 2019-01-07 at 11:49 +0800, Randy Li wrote:
>>> On 12/12/18 8:51 PM, Paul Kocialkowski wrote:
>>> Hi,
>>>
>>> On Wed, 2018-12-05 at 21:59 +0100, Jernej Škrabec wrote:
>>>
> +
> +#define V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_BEFORE0x01
> +#define V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_AFTER0x02
> +#define V4L2_HEVC_DPB_ENTRY_RPS_LT_CURR0x03
> +
> +#define V4L2_HEVC_DPB_ENTRIES_NUM_MAX16
> +
> +struct v4l2_hevc_dpb_entry {
> +__u32buffer_tag;
> +__u8rps;
> +__u8field_pic;
> +__u16pic_order_cnt[2];
> +};
>>
>> Please add a property for reference index, if that rps is not used for
>> this, some device would request that(not the rockchip one). And
>> Rockchip's VDPU1 and VDPU2 for AVC would request a similar property.
>
> What exactly is that reference index? Is it a bitstream element or
> something deduced from the bitstream?
>
picture order count(POC) for HEVC and frame_num in AVC. I think it is the
number used in list0(P slice and B slice) and list1(B slice).
>> Adding another buffer_tag for referring the memory of the motion vectors
>> for each frames. Or a better method is add a meta data to echo picture
>> buffer, since the picture output is just the same as the original,
>> display won't care whether the motion vectors are written the button of
>> picture or somewhere else.
>
> The motion vectors are passed as part of the raw bitstream data, in the
> slices. Is there a case where the motion vectors are coded differently?
No, it is an additional cache for decoder, even FFmpeg having such data, I
think allwinner must output it into somewhere.
>
> +
> +struct v4l2_hevc_pred_weight_table {
> +__u8luma_log2_weight_denom;
> +__s8delta_chroma_log2_weight_denom;
> +
> +__s8delta_luma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
> +__s8luma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
> +__s8delta_chroma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
> +__s8chroma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
> +
> +__s8delta_luma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
> +__s8luma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
> +__s8delta_chroma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
> +__s8chroma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
> +};
> +
>> Those properties I think are not necessary are applying for the
>> Rockchip's device, may not work for the others.
>
> Yes, it's possible that some of the elements are not necessary for some
> decoders. What we want is to cover all the elements that might be
> required for a decoder.
I wonder whether allwinner need that, those sao flag usually ignored by decoder
in design. But more is better than less, it is hard to extend a v4l2 structure
in the future, maybe a new HEVC profile would bring a new property, it is still
too early for HEVC.
>
> +struct v4l2_ctrl_hevc_slice_params {
> +__u32bit_size;
> +__u32data_bit_offset;
> +
> +/* ISO/IEC 23008-2, ITU-T Rec. H.265: NAL unit header */
> +__u8nal_unit_type;
> +__u8nuh_temporal_id_plus1;
> +
> +/* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header */
> +__u8slice_type;
> +__u8colour_plane_id;
>>
> +__u16slice_pic_order_cnt;
> +__u8slice_sao_luma_flag;
> +__u8slice_sao_chroma_flag;
> +__u8slice_temporal_mvp_enabled_flag;
> +__u8num_ref_idx_l0_active_minus1;
> +__u8num_ref_idx_l1_active_minus1;
>> Rockchip's decoder doesn't use this part.
> +__u8mvd_l1_zero_flag;
> +__u8cabac_init_flag;
> +__u8collocated_from_l0_flag;
> +__u8collocated_ref_idx;
> +__u8five_minus_max_num_merge_cand;
> +__u8use_integer_mv_flag;
> +__s8slice_qp_delta;
> +__s8slice_cb_qp_offset;
> +__s8slice_cr_qp_offset;
> +__s8slice_act_y_qp_offset;
> +__s8slice_act_cb_qp_offset;
> +__s8slice_act_cr_qp_offset;
> +__u8slice_deblocking_filter_disabled_flag;
> +__s8slice_beta_offset_div2;
> +__s8slice_tc_offset_div2;
> +__u8slice_loop_filter_across_slices_enabled_flag;
> +
> +/* ISO/IEC 23008-2, ITU-T Rec. H.265: Picture timing SEI message */
> +__u8pic_struct;
>> I think the decoder doesn't care about this, it is used for display.
>
> The purpose of this field is to indicate whether the current picture is
> a progressive frame or an interlaced field picture, which is useful for
> decoding.
>
> At least our decoder has a register
Re: drivers/staging/media/ipu3/ipu3-css.c:1831: bad compare ?
Hi David,
On Mon, Jan 07, 2019 at 10:30:55PM +, David Binderman wrote:
> Hello there,
>
> drivers/staging/media/ipu3/ipu3-css.c:1831:30: warning: comparison of
> unsigned expression < 0 is always false [-Wtype-limits]
>
> Source code is
> css->pipes[pipe].bindex =
> ipu3_css_find_binary(css, pipe, q, r);
> if (css->pipes[pipe].bindex < 0) {
> dev_err(css->dev, "failed to find suitable binary\n");
> return -EINVAL;
> }
>
> Suggest sanity check return value from function first, then if it is ok,
> assign it to an unsigned variable.
Thanks for reporting this. There have been a few patches to address it so
far, the one going in is here:
https://patchwork.linuxtv.org/patch/53633/>
--
Sakari Ailus
sakari.ai...@linux.intel.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8192e: fix various indentation issues
From: Colin Ian King
There are several statements that have indentation issues, fix these.
Signed-off-by: Colin Ian King
---
drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c | 8
drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 6 +++---
drivers/staging/rtl8192e/rtl8192e/rtl_dm.c | 2 +-
drivers/staging/rtl8192e/rtl8192e/rtl_wx.c | 2 +-
drivers/staging/rtl8192e/rtl819x_BAProc.c | 6 +++---
drivers/staging/rtl8192e/rtllib_crypt_tkip.c | 2 +-
drivers/staging/rtl8192e/rtllib_rx.c | 2 +-
7 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
index 1c6ed5b2a6f9..19bb04b3f097 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
@@ -660,9 +660,9 @@ static void _rtl92e_hwconfig(struct net_device *dev)
case WIRELESS_MODE_AUTO:
case WIRELESS_MODE_N_24G:
regBwOpMode = BW_OPMODE_20MHZ;
- regRATR = RATE_ALL_CCK | RATE_ALL_OFDM_AG |
- RATE_ALL_OFDM_1SS | RATE_ALL_OFDM_2SS;
- regRRSR = RATE_ALL_CCK | RATE_ALL_OFDM_AG;
+ regRATR = RATE_ALL_CCK | RATE_ALL_OFDM_AG |
+ RATE_ALL_OFDM_1SS | RATE_ALL_OFDM_2SS;
+ regRRSR = RATE_ALL_CCK | RATE_ALL_OFDM_AG;
break;
case WIRELESS_MODE_N_5G:
regBwOpMode = BW_OPMODE_5G;
@@ -961,7 +961,7 @@ static void _rtl92e_net_update(struct net_device *dev)
net = >rtllib->current_network;
rtl92e_config_rate(dev, _config);
priv->dot11CurrentPreambleMode = PREAMBLE_AUTO;
-priv->basic_rate = rate_config &= 0x15f;
+ priv->basic_rate = rate_config &= 0x15f;
rtl92e_writew(dev, BSSIDR, *(u16 *)net->bssid);
rtl92e_writel(dev, BSSIDR + 2, *(u32 *)(net->bssid + 2));
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
index 96f265eee007..7031f6833b8b 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -436,7 +436,7 @@ static int _rtl92e_qos_handle_probe_response(struct
r8192_priv *priv,
network->qos_data.param_count)) {
network->qos_data.old_param_count =
network->qos_data.param_count;
- priv->rtllib->wmm_acm = network->qos_data.wmm_acm;
+ priv->rtllib->wmm_acm = network->qos_data.wmm_acm;
schedule_work(>qos_activate);
RT_TRACE(COMP_QOS,
"QoS parameters change call qos_activate\n");
@@ -1573,7 +1573,7 @@ static void _rtl92e_free_rx_ring(struct net_device *dev)
pci_unmap_single(priv->pdev,
*((dma_addr_t *)skb->cb),
priv->rxbuffersize, PCI_DMA_FROMDEVICE);
- kfree_skb(skb);
+ kfree_skb(skb);
}
pci_free_consistent(priv->pdev,
@@ -2515,7 +2515,7 @@ static int _rtl92e_pci_probe(struct pci_dev *pdev,
if (dev_alloc_name(dev, ifname) < 0) {
RT_TRACE(COMP_INIT,
"Oops: devname already taken! Trying wlan%%d...\n");
- dev_alloc_name(dev, ifname);
+ dev_alloc_name(dev, ifname);
}
RT_TRACE(COMP_INIT, "Driver probe completed1\n");
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
index 9bf95bd0ad13..157bcee34067 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
@@ -996,7 +996,7 @@ static void _rtl92e_dm_check_tx_power_tracking_tssi(struct
net_device *dev)
tx_power_track_counter++;
-if (tx_power_track_counter >= 180) {
+ if (tx_power_track_counter >= 180) {
schedule_delayed_work(>txpower_tracking_wq, 0);
tx_power_track_counter = 0;
}
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_wx.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_wx.c
index 843e874b8a06..1899dbb2c957 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_wx.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_wx.c
@@ -738,7 +738,7 @@ static int _rtl92e_wx_set_enc(struct net_device *dev,
else if (wrqu->encoding.length == 0xd) {
ieee->pairwise_key_type = KEY_TYPE_WEP104;
- rtl92e_enable_hw_security_config(dev);
+ rtl92e_enable_hw_security_config(dev);
rtl92e_set_key(dev, key_idx, key_idx, KEY_TYPE_WEP104,
zero_addr[key_idx], 0, hwkey);
rtl92e_set_swcam(dev, key_idx, key_idx, KEY_TYPE_WEP104,
[PATCH] [v3] staging: rtl8723bs: Clean up dead code
rtw_wps_start() is part of dead code due to CONFIG_INTEL_WIDI.
The fix removes the deadcode and replaces the function with NULL
in rtw_private_handler. Identified as part of copy_from_user bug.
Changes from v1 & 2:
The return value of copy_from_user() is not checked appropriately.
However, maintainers identified the patch fixing the issue is not
required as function rts_wps_start() is dead code and can be removed.
Signed-off-by: Aditya Pakki
---
.../staging/rtl8723bs/os_dep/ioctl_linux.c| 34 +--
1 file changed, 1 insertion(+), 33 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
index 8fb03efd588b..2621c47f343f 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
@@ -2568,38 +2568,6 @@ static int rtw_set_pid(struct net_device *dev,
}
-static int rtw_wps_start(struct net_device *dev,
- struct iw_request_info *info,
- union iwreq_data *wrqu, char *extra)
-{
-
- int ret = 0;
- struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
- struct iw_point *pdata = >data;
- u32 u32wps_start = 0;
-unsigned int uintRet = 0;
-
- if ((true == padapter->bDriverStopped) ||(true
==padapter->bSurpriseRemoved) || (NULL == pdata)) {
- ret = -EINVAL;
- goto exit;
- }
-
- uintRet = copy_from_user((void*)_start, pdata->pointer, 4);
- if (u32wps_start == 0)
- u32wps_start = *extra;
-
- DBG_871X("[%s] wps_start = %d\n", __func__, u32wps_start);
-
-#ifdef CONFIG_INTEL_WIDI
- process_intel_widi_wps_status(padapter, u32wps_start);
-#endif /* CONFIG_INTEL_WIDI */
-
-exit:
-
- return ret;
-
-}
-
static int rtw_p2p_set(struct net_device *dev,
struct iw_request_info *info,
union iwreq_data *wrqu, char *extra)
@@ -4820,7 +4788,7 @@ static iw_handler rtw_private_handler[] = {
rtw_get_ap_info,/* 0x04 */
rtw_set_pid,/* 0x05 */
- rtw_wps_start, /* 0x06 */
+ NULL, /* 0x06 */
/* for PLATFORM_MT53XX */
rtw_wx_get_sensitivity, /* 0x07 */
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8712: clean up various indentation and coding style issues
From: Colin Ian King
There are several statements that are indented incorrectly so fix these.
Also remove unnecessary { } braces and clean up a comment.
Signed-off-by: Colin Ian King
---
drivers/staging/rtl8712/ieee80211.c | 2 +-
drivers/staging/rtl8712/rtl8712_led.c | 6 +++---
drivers/staging/rtl8712/rtl871x_mlme.c| 2 +-
drivers/staging/rtl8712/rtl871x_recv.c| 4 ++--
drivers/staging/rtl8712/rtl871x_sta_mgt.c | 2 +-
drivers/staging/rtl8712/rtl871x_xmit.c| 8
6 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/rtl8712/ieee80211.c
b/drivers/staging/rtl8712/ieee80211.c
index bb4f56a5fb01..2eae11dd6b42 100644
--- a/drivers/staging/rtl8712/ieee80211.c
+++ b/drivers/staging/rtl8712/ieee80211.c
@@ -408,7 +408,7 @@ int r8712_get_wps_ie(u8 *in_ie, uint in_len, u8 *wps_ie,
uint *wps_ielen)
match = true;
break;
}
- cnt += in_ie[cnt + 1] + 2; /* goto next */
+ cnt += in_ie[cnt + 1] + 2; /* goto next */
}
return match;
}
diff --git a/drivers/staging/rtl8712/rtl8712_led.c
b/drivers/staging/rtl8712/rtl8712_led.c
index 5b1004b2df47..07fcf9b9b811 100644
--- a/drivers/staging/rtl8712/rtl8712_led.c
+++ b/drivers/staging/rtl8712/rtl8712_led.c
@@ -939,7 +939,7 @@ static void SwLedControlMode1(struct _adapter *padapter,
}
if (pLed->bLedLinkBlinkInProgress) {
del_timer(>BlinkTimer);
-pLed->bLedLinkBlinkInProgress = false;
+ pLed->bLedLinkBlinkInProgress = false;
}
if (pLed->bLedBlinkInProgress) {
del_timer(>BlinkTimer);
@@ -991,7 +991,7 @@ static void SwLedControlMode1(struct _adapter *padapter,
}
if (pLed->bLedLinkBlinkInProgress) {
del_timer(>BlinkTimer);
-pLed->bLedLinkBlinkInProgress = false;
+ pLed->bLedLinkBlinkInProgress = false;
}
if (pLed->bLedBlinkInProgress) {
del_timer(>BlinkTimer);
@@ -1018,7 +1018,7 @@ static void SwLedControlMode1(struct _adapter *padapter,
}
if (pLed->bLedLinkBlinkInProgress) {
del_timer(>BlinkTimer);
-pLed->bLedLinkBlinkInProgress = false;
+ pLed->bLedLinkBlinkInProgress = false;
}
if (pLed->bLedBlinkInProgress) {
del_timer(>BlinkTimer);
diff --git a/drivers/staging/rtl8712/rtl871x_mlme.c
b/drivers/staging/rtl8712/rtl871x_mlme.c
index 986a1d526918..3f17ef6f7e39 100644
--- a/drivers/staging/rtl8712/rtl871x_mlme.c
+++ b/drivers/staging/rtl8712/rtl871x_mlme.c
@@ -259,7 +259,7 @@ int r8712_is_same_ibss(struct _adapter *adapter, struct
wlan_network *pnetwork)
static int is_same_network(struct wlan_bssid_ex *src,
struct wlan_bssid_ex *dst)
{
-u16 s_cap, d_cap;
+ u16 s_cap, d_cap;
memcpy((u8 *)_cap, r8712_get_capability_from_ie(src->IEs), 2);
memcpy((u8 *)_cap, r8712_get_capability_from_ie(dst->IEs), 2);
diff --git a/drivers/staging/rtl8712/rtl871x_recv.c
b/drivers/staging/rtl8712/rtl871x_recv.c
index f10896df094b..0271ccf25f25 100644
--- a/drivers/staging/rtl8712/rtl871x_recv.c
+++ b/drivers/staging/rtl8712/rtl871x_recv.c
@@ -54,7 +54,7 @@ sint _r8712_init_recv_priv(struct recv_priv *precvpriv,
sint i;
union recv_frame *precvframe;
-memset((unsigned char *)precvpriv, 0, sizeof(struct recv_priv));
+ memset((unsigned char *)precvpriv, 0, sizeof(struct recv_priv));
spin_lock_init(>lock);
_init_queue(>free_recv_queue);
_init_queue(>recv_pending_queue);
@@ -325,7 +325,7 @@ static sint sta2sta_data_frame(struct _adapter *adapter,
*/
if (memcmp(pattrib->bssid, pattrib->src, ETH_ALEN))
return _FAIL;
- sta_addr = pattrib->bssid;
+ sta_addr = pattrib->bssid;
} else if (check_fwstate(pmlmepriv, WIFI_AP_STATE)) {
if (bmcast) {
/* For AP mode, if DA == MCAST, then BSSID should
diff --git a/drivers/staging/rtl8712/rtl871x_sta_mgt.c
b/drivers/staging/rtl8712/rtl871x_sta_mgt.c
index 9648ee15b40e..7c30b9e68e70 100644
--- a/drivers/staging/rtl8712/rtl871x_sta_mgt.c
+++ b/drivers/staging/rtl8712/rtl871x_sta_mgt.c
@@ -25,7 +25,7 @@
static void _init_stainfo(struct sta_info *psta)
{
memset((u8 *)psta, 0, sizeof(struct sta_info));
-spin_lock_init(>lock);
+ spin_lock_init(>lock);
INIT_LIST_HEAD(>list);
INIT_LIST_HEAD(>hash_list);
drivers/staging/media/ipu3/ipu3-css.c:1831: bad compare ?
Hello there,
drivers/staging/media/ipu3/ipu3-css.c:1831:30: warning: comparison of unsigned
expression < 0 is always false [-Wtype-limits]
Source code is
css->pipes[pipe].bindex =
ipu3_css_find_binary(css, pipe, q, r);
if (css->pipes[pipe].bindex < 0) {
dev_err(css->dev, "failed to find suitable binary\n");
return -EINVAL;
}
Suggest sanity check return value from function first, then if it is ok,
assign it to an unsigned variable.
Regards
David Binderman
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RESEND PATCH] staging: mt7621-pci: use PCI definitions instead of hardcode values
Seting up ports to enable PCI_COMMAND_MASTER is using '0x4' as a
hardcore value and '0x4' also for PCI_COMMAND register instead
of use definitions from linux pci system headers. Replace both.
Signed-off-by: Sergio Paracuellos
---
Greg, I resend this PATCH because it has not been applied and I sent
it two weeks ago before other applyed PATCHes for the same driver,
so maybe it has been lost. If this is not the case, sorry for
inconvenience.
It was sent on December, 23th:
*
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130193.html
Best regards,
Sergio Paracuellos
drivers/staging/mt7621-pci/pci-mt7621.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 8db94fdbdd6d..507b8c68d20b 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -515,8 +515,9 @@ static void mt7621_pcie_enable_ports(struct mt7621_pcie
*pcie)
}
for (slot = 0; slot < num_slots_enabled; slot++) {
- val = read_config(pcie, slot, 0x4);
- write_config(pcie, slot, 0x4, val | 0x4);
+ val = read_config(pcie, slot, PCI_COMMAND);
+ val |= PCI_COMMAND_MASTER;
+ write_config(pcie, slot, PCI_COMMAND, val);
/* configure RC FTS number to 250 when it leaves L0s */
val = read_config(pcie, slot, PCIE_FTS_NUM);
val &= ~PCIE_FTS_NUM_MASK;
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8188eu: Add device code for D-Link DWA-121 rev B1
On 1/7/19 11:28 AM, Michael Straube wrote: This device was added to the stand-alone driver on github. Add it to the staging driver as well. Link: https://github.com/lwfinger/rtl8188eu/commit/a0619a07cd1e Signed-off-by: Michael Straube Acked-by: Larry Finger Thanks, Larry ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/2] staging: erofs: fixed -Wmissing-prototype warnings.
Fixes for -Wmissing-prototype warnings in the erofs driver. One group of functions have been made static; for the second, prototypes have been moved to a head Jeremy Sowden (2): staging: erofs: fixed -Wmissing-prototype warnings. staging: erofs: fixed -Wmissing-prototype warnings. drivers/staging/erofs/data.c | 6 -- drivers/staging/erofs/internal.h | 7 +++ drivers/staging/erofs/unzip_vle.c | 2 +- drivers/staging/erofs/unzip_vle_lz4.c | 2 +- drivers/staging/erofs/utils.c | 14 ++ 5 files changed, 15 insertions(+), 16 deletions(-) base-commit: c8c2702409430a6a2fd928e857f15773aaafcc99 -- 2.20.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] staging: erofs: fixed -Wmissing-prototype warnings.
Define three functions which are not used outside their own
translation-units as static in order to fix the following warnings:
drivers/staging/erofs/utils.c:134:6: warning: no previous prototype for
‘erofs_try_to_release_workgroup’ [-Wmissing-prototypes]
bool erofs_try_to_release_workgroup(struct erofs_sb_info *sbi,
^~
drivers/staging/erofs/unzip_vle.c:592:6: warning: no previous prototype for
‘z_erofs_vle_work_release’ [-Wmissing-prototypes]
void z_erofs_vle_work_release(struct z_erofs_vle_work *work)
^~~~
drivers/staging/erofs/unzip_vle_lz4.c:16:5: warning: no previous prototype
for ‘z_erofs_unzip_lz4’ [-Wmissing-prototypes]
int z_erofs_unzip_lz4(void *in, void *out, size_t inlen, size_t outlen)
^
Signed-off-by: Jeremy Sowden
---
drivers/staging/erofs/unzip_vle.c | 2 +-
drivers/staging/erofs/unzip_vle_lz4.c | 2 +-
drivers/staging/erofs/utils.c | 12 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/erofs/unzip_vle.c
b/drivers/staging/erofs/unzip_vle.c
index 4ac1099a39c6..584612b47369 100644
--- a/drivers/staging/erofs/unzip_vle.c
+++ b/drivers/staging/erofs/unzip_vle.c
@@ -589,7 +589,7 @@ static void __z_erofs_vle_work_release(struct
z_erofs_vle_workgroup *grp,
erofs_workgroup_put(>obj);
}
-void z_erofs_vle_work_release(struct z_erofs_vle_work *work)
+static void z_erofs_vle_work_release(struct z_erofs_vle_work *work)
{
struct z_erofs_vle_workgroup *grp =
z_erofs_vle_work_workgroup(work, true);
diff --git a/drivers/staging/erofs/unzip_vle_lz4.c
b/drivers/staging/erofs/unzip_vle_lz4.c
index 52797bd89da1..8e8d705a6861 100644
--- a/drivers/staging/erofs/unzip_vle_lz4.c
+++ b/drivers/staging/erofs/unzip_vle_lz4.c
@@ -13,7 +13,7 @@
#include "unzip_vle.h"
#include
-int z_erofs_unzip_lz4(void *in, void *out, size_t inlen, size_t outlen)
+static int z_erofs_unzip_lz4(void *in, void *out, size_t inlen, size_t outlen)
{
int ret = LZ4_decompress_safe_partial(in, out, inlen, outlen, outlen);
diff --git a/drivers/staging/erofs/utils.c b/drivers/staging/erofs/utils.c
index b535898ca753..fc30025ef101 100644
--- a/drivers/staging/erofs/utils.c
+++ b/drivers/staging/erofs/utils.c
@@ -131,9 +131,9 @@ static void erofs_workgroup_unfreeze_final(struct
erofs_workgroup *grp)
__erofs_workgroup_free(grp);
}
-bool erofs_try_to_release_workgroup(struct erofs_sb_info *sbi,
- struct erofs_workgroup *grp,
- bool cleanup)
+static bool erofs_try_to_release_workgroup(struct erofs_sb_info *sbi,
+ struct erofs_workgroup *grp,
+ bool cleanup)
{
/*
* for managed cache enabled, the refcount of workgroups
@@ -172,9 +172,9 @@ bool erofs_try_to_release_workgroup(struct erofs_sb_info
*sbi,
#else
/* for nocache case, no customized reclaim path at all */
-bool erofs_try_to_release_workgroup(struct erofs_sb_info *sbi,
- struct erofs_workgroup *grp,
- bool cleanup)
+static bool erofs_try_to_release_workgroup(struct erofs_sb_info *sbi,
+ struct erofs_workgroup *grp,
+ bool cleanup)
{
int cnt = atomic_read(>refcount);
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] staging: erofs: fixed -Wmissing-prototype warnings.
Moved prototypes for two functions to header file in order to fix the
following warnings:
drivers/staging/erofs/unzip_vle.c:577:6: warning: no previous prototype for
‘erofs_workgroup_free_rcu’ [-Wmissing-prototypes]
void erofs_workgroup_free_rcu(struct erofs_workgroup *grp)
^~~~
drivers/staging/erofs/unzip_vle.c:1702:5: warning: no previous prototype for
‘z_erofs_map_blocks_iter’ [-Wmissing-prototypes]
int z_erofs_map_blocks_iter(struct inode *inode,
^~~
Signed-off-by: Jeremy Sowden
---
drivers/staging/erofs/data.c | 6 --
drivers/staging/erofs/internal.h | 7 +++
drivers/staging/erofs/utils.c| 2 --
3 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/erofs/data.c b/drivers/staging/erofs/data.c
index 5a55f0bfdfbb..329fa4fa3e9c 100644
--- a/drivers/staging/erofs/data.c
+++ b/drivers/staging/erofs/data.c
@@ -165,12 +165,6 @@ static int erofs_map_blocks_flatmode(struct inode *inode,
return err;
}
-#ifdef CONFIG_EROFS_FS_ZIP
-extern int z_erofs_map_blocks_iter(struct inode *,
- struct erofs_map_blocks *,
- struct page **, int);
-#endif
-
int erofs_map_blocks_iter(struct inode *inode,
struct erofs_map_blocks *map,
struct page **mpage_ret, int flags)
diff --git a/drivers/staging/erofs/internal.h b/drivers/staging/erofs/internal.h
index 49c587383315..192f4028d85d 100644
--- a/drivers/staging/erofs/internal.h
+++ b/drivers/staging/erofs/internal.h
@@ -288,6 +288,8 @@ static inline void erofs_workstation_cleanup_all(struct
super_block *sb)
erofs_shrink_workstation(EROFS_SB(sb), ~0UL, true);
}
+extern void erofs_workgroup_free_rcu(struct erofs_workgroup *grp);
+
#ifdef EROFS_FS_HAS_MANAGED_CACHE
extern int erofs_try_to_free_all_cached_pages(struct erofs_sb_info *sbi,
struct erofs_workgroup *egrp);
@@ -530,6 +532,11 @@ struct erofs_map_blocks_iter {
struct page *mpage;
};
+#ifdef CONFIG_EROFS_FS_ZIP
+extern int z_erofs_map_blocks_iter(struct inode *,
+ struct erofs_map_blocks *,
+ struct page **, int);
+#endif
static inline struct page *
erofs_get_inline_page(struct inode *inode,
diff --git a/drivers/staging/erofs/utils.c b/drivers/staging/erofs/utils.c
index fc30025ef101..aed211cd5875 100644
--- a/drivers/staging/erofs/utils.c
+++ b/drivers/staging/erofs/utils.c
@@ -104,8 +104,6 @@ int erofs_register_workgroup(struct super_block *sb,
return err;
}
-extern void erofs_workgroup_free_rcu(struct erofs_workgroup *grp);
-
static void __erofs_workgroup_free(struct erofs_workgroup *grp)
{
atomic_long_dec(_global_shrink_cnt);
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hv_balloon: avoid touching uninitialized struct page during tail onlining
Sasha Levin writes: > On Mon, Jan 07, 2019 at 02:44:30PM +0100, Vitaly Kuznetsov wrote: >>P.S. I still think about bringing mem_hotplug_begin()/done() to >>hv_balloon but that's going to be a separate discussion, here I want to >>have a small fix backportable to stable. > > This should probably be marked for stable then :) > Yes, please :-) I didn't test old kernels but this seems to be an old issue, e.g. DEFERRED_STRUCT_PAGE_INIT appeared in 4.2 - not sure if memory hotplug code was using it back then but, oh well, it's all history now. (I remember Greg disliked when people were tagging patches for stable@ themselves, he prefered maintainers deciding if the particular commit deserves stable@ or not - but as you have a tree now we may as well have different rules :-) -- Vitaly ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 13/17] power: supply: olpc_battery: Use DT to get battery version
On Wed, 2018-12-05 at 21:54 +0100, Sebastian Reichel wrote:
> Hi,
>
> On Fri, Nov 16, 2018 at 05:23:59PM +0100, Lubomir Rintel wrote:
> > Avoid using the x86 OLPC platform specific call to get the board
> > version. It won't work on FDT-based ARM MMP2 platform.
> >
> > Signed-off-by: Lubomir Rintel
> > Reviewed-by: Andy Shevchenko
> > Acked-by: Pavel Machek
> >
> > ---
>
> Reviewed-by: Sebastian Reichel
>
> I assume this patch cannot be applied to power-supply without patch
> 12 having been merged to avoid breaking XO1.5 devices temporarily?
That is true. What's the correct way to deal with a situation like
this? Just hold the patch until the other changes get in, perhaps via
linux-platform-drivers-x86.git? Or maybe this can go in together via
that tree along with the other patches?
Thanks
Lubo
> -- Sebastian
>
> > Changes since v1:
> > - Sort the new include a bit higher
> >
> > drivers/power/supply/olpc_battery.c | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/power/supply/olpc_battery.c
> > b/drivers/power/supply/olpc_battery.c
> > index 5a97e42a3547..5323987d9284 100644
> > --- a/drivers/power/supply/olpc_battery.c
> > +++ b/drivers/power/supply/olpc_battery.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -622,11 +623,13 @@ static int olpc_battery_probe(struct
> > platform_device *pdev)
> > olpc_ac = power_supply_register(>dev, _ac_desc,
> > NULL);
> > if (IS_ERR(olpc_ac))
> > return PTR_ERR(olpc_ac);
> > -
> > - if (olpc_board_at_least(olpc_board_pre(0xd0))) { /* XO-1.5 */
> > + if (of_property_match_string(pdev->dev.of_node, "compatible",
> > + "olpc,xo1.5-battery") >= 0) {
> > + /* XO-1.5 */
> > olpc_bat_desc.properties = olpc_xo15_bat_props;
> > olpc_bat_desc.num_properties =
> > ARRAY_SIZE(olpc_xo15_bat_props);
> > - } else { /* XO-1 */
> > + } else {
> > + /* XO-1 */
> > olpc_bat_desc.properties = olpc_xo1_bat_props;
> > olpc_bat_desc.num_properties =
> > ARRAY_SIZE(olpc_xo1_bat_props);
> > }
> > @@ -672,6 +675,7 @@ static int olpc_battery_remove(struct
> > platform_device *pdev)
> >
> > static const struct of_device_id olpc_battery_ids[] = {
> > { .compatible = "olpc,xo1-battery" },
> > + { .compatible = "olpc,xo1.5-battery" },
> > {}
> > };
> > MODULE_DEVICE_TABLE(of, olpc_battery_ids);
> > --
> > 2.19.1
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] ipu3: add missing #include
Lots of warning due to non-static functions are generated because the headers with define them were not included. Signed-off-by: Mauro Carvalho Chehab --- drivers/staging/media/ipu3/ipu3-css-params.c | 1 + drivers/staging/media/ipu3/ipu3-dmamap.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/staging/media/ipu3/ipu3-css-params.c b/drivers/staging/media/ipu3/ipu3-css-params.c index 776206ded83b..053edce54b71 100644 --- a/drivers/staging/media/ipu3/ipu3-css-params.c +++ b/drivers/staging/media/ipu3/ipu3-css-params.c @@ -6,6 +6,7 @@ #include "ipu3-css.h" #include "ipu3-css-fw.h" #include "ipu3-tables.h" +#include "ipu3-css-params.h" #define DIV_ROUND_CLOSEST_DOWN(a, b) (((a) + ((b) / 2) - 1) / (b)) #define roundclosest_down(a, b)(DIV_ROUND_CLOSEST_DOWN(a, b) * (b)) diff --git a/drivers/staging/media/ipu3/ipu3-dmamap.c b/drivers/staging/media/ipu3/ipu3-dmamap.c index 93a393d4e15e..5bed01d5b8df 100644 --- a/drivers/staging/media/ipu3/ipu3-dmamap.c +++ b/drivers/staging/media/ipu3/ipu3-dmamap.c @@ -12,6 +12,7 @@ #include "ipu3.h" #include "ipu3-css-pool.h" #include "ipu3-mmu.h" +#include "ipu3-dmamap.h" /* * Free a buffer allocated by ipu3_dmamap_alloc_buffer() -- 2.20.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 17/17] power: supply: olpc_battery: Add OLPC XO 1.75 support
On Sun, 2018-12-02 at 15:34 -0800, Darren Hart wrote:
> On Fri, Nov 16, 2018 at 05:24:03PM +0100, Lubomir Rintel wrote:
> > The battery and the protocol are essentially the same as OLPC XO 1.5,
> > but the responses from the EC are LSB first.
> >
> > Signed-off-by: Lubomir Rintel
> > Acked-by: Pavel Machek
> >
> > ---
> > Changes since v1:
> > - s/s16 ecword_to_cpu/u16 ecword_to_cpu/
> > - s/u16 ec_byte/u16 ec_word/
> >
> > drivers/power/supply/olpc_battery.c | 23 ++-
> > 1 file changed, 18 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/power/supply/olpc_battery.c
> > b/drivers/power/supply/olpc_battery.c
>
> ...
>
> > @@ -626,6 +635,10 @@ static int olpc_battery_probe(struct platform_device
> > *pdev)
> > if (ecver > 0x44) {
> > /* XO 1 or 1.5 with a new EC firmware. */
> > data->new_proto = 1;
> > + } else if (of_find_compatible_node(NULL, NULL, "olpc,xo1.75-ec")) {
>
> This if/else blocks concerns me a bit, but I might just be missing some
> context.
>
> This tests both ecver as well as the OF compatible string, is this reliable?
> Do
> we know that for all xo1.75-ec compatible nodes the ecver will be <= 0x44? Or,
> is ecver undefined? If the latter, then perhaps this test should be performed
> first?
>
> if (of_find_compatible_nodex01.75-ec...)
> ...
> else if (ecver > 0x44)
> ...
> else
> ...
>
> And what happens when ecver == 0x44? We test for > and < but not ==, <=,
> or >= in this block
You're right, the conditionals are not correct. On XO 1.75 the
versioning is different (now at level 0x05) and uninteresting,
therefore the XO 1.75 check needs to go first.
On XO 1 and XO 1.75, we don't support < 0x44. 0x44 is okay, though uses
stays with an old protocol, and > 0x44 uses a new protocol.
Will follow up with a new version of the patch soon.
>
> > + /* XO 1.75 */
> > + data->new_proto = 1;
> > + data->little_endian = 1;
> > } else if (ecver < 0x44) {
> > /*
> > * We've seen a number of EC protocol changes; this driver
> > --
> > 2.19.1
Thanks
Lubo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: iio: ad7192: replaced bool in struct
On Wed, Jan 02, 2019 at 01:25:27PM -0800, Matt Ranostay wrote:
>
> > On Dec 24, 2018, at 01:58, Himanshu Jha wrote:
> >
> >> On Fri, Dec 21, 2018 at 03:26:26PM -0800, Amir Mahdi Ghorbanian wrote:
> >> Replaced bool in struct with unsigned int bitfield to conserve space and
> >> more clearly define size of varibales
>
> Important thing to note is depending on padding, alignment, and position of
> field it probably won’t save any space.
Well, then what do you say about the following results ;-)
Before:
--
himanshu@himanshu-Vostro-3559:~/gsoc/linux$ pahole -C ad7192_platform_data
drivers/staging/iio/adc/ad7192.o
struct ad7192_platform_data {
u16vref_mv; /* 0 2 */
u8 clock_source_sel; /* 2 1 */
/* XXX 1 byte hole, try to pack */
u32ext_clk_hz; /* 4 4 */
bool refin2_en;/* 8 1 */
bool rej60_en; /* 9 1 */
bool sinc3_en; /*10 1 */
bool chop_en; /*11 1 */
bool buf_en; /*12 1 */
bool unipolar_en; /*13 1 */
bool burnout_curr_en; /*14 1 */
/* size: 16, cachelines: 1, members: 10 */
/* sum members: 14, holes: 1, sum holes: 1 */
/* padding: 1 */
/* last cacheline: 16 bytes */
};
After:
-
himanshu@himanshu-Vostro-3559:~/gsoc/linux$ pahole -C ad7192_platform_data
drivers/staging/iio/adc/ad7192.o
struct ad7192_platform_data {
u16vref_mv; /* 0 2 */
u8 clock_source_sel; /* 2 1 */
/* XXX 1 byte hole, try to pack */
u32ext_clk_hz; /* 4 4 */
unsigned int refin2_en:1; /* 8:31 4 */
unsigned int rej60_en:1; /* 8:30 4 */
unsigned int sinc3_en:1; /* 8:29 4 */
unsigned int chop_en:1;/* 8:28 4 */
unsigned int buf_en:1; /* 8:27 4 */
unsigned int unipolar_en:1;/* 8:26 4 */
unsigned int burnout_curr_en:1;/* 8:25 4 */
/* size: 12, cachelines: 1, members: 10 */
/* sum members: 11, holes: 1, sum holes: 1 */
/* bit_padding: 25 bits */
/* last cacheline: 12 bytes */
};
> Also for internal unpacked structures it really makes little sense to save a
> few bytes of data. Don’t read into that packed structures are good.. they
> usually aren’t :)
Yes, agreed, but I often see patches to save few bytes by marking
array as static.
There is some effort in this direction:
https://lore.kernel.org/lkml/20181221235230.gc13...@ziepe.ca/
Very likely to get more patches if the above patch gets merged.
--
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hv_balloon: avoid touching uninitialized struct page during tail onlining
On Mon, Jan 07, 2019 at 02:44:30PM +0100, Vitaly Kuznetsov wrote: David Hildenbrand writes: On 04.01.19 15:19, Vitaly Kuznetsov wrote: Hyper-V memory hotplug protocol has 2M granularity and in Linux x86 we use 128M. To deal with it we implement partial section onlining by registering custom page onlining callback (hv_online_page()). Later, when more memory arrives we try to online the 'tail' (see hv_bring_pgs_online()). It was found that in some cases this 'tail' onlining causes issues: BUG: Bad page state in process kworker/0:2 pfn:109e3a page:e08344278e80 count:0 mapcount:1 mapping: index:0x0 flags: 0xf8000() raw: 000f8000 dead0100 dead0200 raw: page dumped because: nonzero mapcount ... Workqueue: events hot_add_req [hv_balloon] Call Trace: dump_stack+0x5c/0x80 bad_page.cold.112+0x7f/0xb2 free_pcppages_bulk+0x4b8/0x690 free_unref_page+0x54/0x70 hv_page_online_one+0x5c/0x80 [hv_balloon] hot_add_req.cold.24+0x182/0x835 [hv_balloon] ... Turns out that we now have deferred struct page initialization for memory hotplug so e.g. memory_block_action() in drivers/base/memory.c does pages_correctly_probed() check and in that check it avoids inspecting struct pages and checks sections instead. But in Hyper-V balloon driver we do PageReserved(pfn_to_page()) check and this is now wrong. Switch to checking online_section_nr() instead. Signed-off-by: Vitaly Kuznetsov --- drivers/hv/hv_balloon.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c index 5301fef16c31..7c6349a50ef1 100644 --- a/drivers/hv/hv_balloon.c +++ b/drivers/hv/hv_balloon.c @@ -888,12 +888,14 @@ static unsigned long handle_pg_range(unsigned long pg_start, pfn_cnt -= pgs_ol; /* * Check if the corresponding memory block is already -* online by checking its last previously backed page. -* In case it is we need to bring rest (which was not -* backed previously) online too. +* online. It is possible to observe struct pages still +* being uninitialized here so check section instead. +* In case the section is online we need to bring the +* rest of pfns (which were not backed previously) +* online too. */ if (start_pfn > has->start_pfn && - !PageReserved(pfn_to_page(start_pfn - 1))) + online_section_nr(pfn_to_section_nr(start_pfn))) hv_bring_pgs_online(has, start_pfn, pgs_ol); } I wonder if you should use pfn_to_online_page() and check for PageOffline(). (I guess online_section_nr() should also do the trick) I'm worried a bit about racing with mm code here as we're not doing mem_hotplug_begin()/done() so I'd slightly prefer keeping online_section_nr() (pfn_to_online_page() also uses it but then it gets to the particular struct page). Moreover, with pfn_to_online_page() we will be looking at some other pfn - because the start_pfn is definitelly offline (pre-patch we were looking at start_pfn-1). Just looking at the whole section seems cleaner. P.S. I still think about bringing mem_hotplug_begin()/done() to hv_balloon but that's going to be a separate discussion, here I want to have a small fix backportable to stable. This should probably be marked for stable then :) -- Thanks, Sasha ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8188eu: Add device code for D-Link DWA-121 rev B1
This device was added to the stand-alone driver on github.
Add it to the staging driver as well.
Link: https://github.com/lwfinger/rtl8188eu/commit/a0619a07cd1e
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/os_dep/usb_intf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index 28cbd6b3d26c..dfee6985efa6 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -35,6 +35,7 @@ static const struct usb_device_id rtw_usb_id_tbl[] = {
{USB_DEVICE(0x2001, 0x330F)}, /* DLink DWA-125 REV D1 */
{USB_DEVICE(0x2001, 0x3310)}, /* Dlink DWA-123 REV D1 */
{USB_DEVICE(0x2001, 0x3311)}, /* DLink GO-USB-N150 REV B1 */
+ {USB_DEVICE(0x2001, 0x331B)}, /* D-Link DWA-121 rev B1 */
{USB_DEVICE(0x2357, 0x010c)}, /* TP-Link TL-WN722N v2 */
{USB_DEVICE(0x0df6, 0x0076)}, /* Sitecom N150 v2 */
{USB_DEVICE(USB_VENDER_ID_REALTEK, 0xffef)}, /* Rosewill RNX-N150NUB */
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: staging: rtl8188eu: D-Link DWA-121 rev B1
On Mon, Jan 07, 2019 at 05:08:34PM +0100, Michael Straube wrote: > Hi, > > I noticed "D-Link DWA-121 rev B1" was added to the stand-alone driver on > github. > https://github.com/lwfinger/rtl8188eu/commit/a0619a07cd1e31776b1c9bb956a5b8570a912598 > > Should it also be added to the staging driver? Why not, send a patch! :) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
staging: rtl8188eu: D-Link DWA-121 rev B1
Hi, I noticed "D-Link DWA-121 rev B1" was added to the stand-alone driver on github. https://github.com/lwfinger/rtl8188eu/commit/a0619a07cd1e31776b1c9bb956a5b8570a912598 Should it also be added to the staging driver? I have no such device to test.. Michael ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: wilc1000: fix cast to restricted __le32
On Mon, Jan 07, 2019 at 06:06:55AM +, ajay.kat...@microchip.com wrote: Hi Ajay, > Please resubmit the patch by changing 'frame_type' type to '__le16' in > 'wilc_reg_frame' struct. Done, sent patch version 4. Message subject changed to: "[PATCH v4] staging: wilc1000: fix registration frame size" to fit v4 patch content. Thank you for your review, Julius ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4] staging: wilc1000: fix registration frame size
Fixes the following sparse warnings:
drivers/staging/wilc1000/host_interface.c:2360:30: warning:
incorrect type in assignment (different base types)
expected restricted __le32 [addressable] [assigned] [usertype] frame_type
got restricted __le16 [usertype]
Fixes: 147ccfd451024 ("staging: wilc1000: handle mgmt_frame_register ops from
cfg82011 context")
Signed-off-by: Július Milan
---
drivers/staging/wilc1000/host_interface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
v3:
- nothing really changed since v1, v2, I just messed emails and then patch
format, sorry for that, it's my first patch :)
v4:
- changed struct wilc_reg_frame member frame_type type to le16
- reverted cast of frame_type to le32 in wilc_frame_register
- changed subject line, previous version has subject:
"[PATCH v3] staging: wilc1000: fix cast to restricted __le32"
https://www.spinics.net/lists/linux-wireless/msg181166.html
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index 70c854d939ce..7acb790d850b 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -36,7 +36,7 @@ struct wilc_op_mode {
struct wilc_reg_frame {
bool reg;
u8 reg_id;
- __le32 frame_type;
+ __le16 frame_type;
} __packed;
struct wilc_drv_handler {
--
2.14.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hv_balloon: avoid touching uninitialized struct page during tail onlining
David Hildenbrand writes: > On 04.01.19 15:19, Vitaly Kuznetsov wrote: >> Hyper-V memory hotplug protocol has 2M granularity and in Linux x86 we use >> 128M. To deal with it we implement partial section onlining by registering >> custom page onlining callback (hv_online_page()). Later, when more memory >> arrives we try to online the 'tail' (see hv_bring_pgs_online()). >> >> It was found that in some cases this 'tail' onlining causes issues: >> >> BUG: Bad page state in process kworker/0:2 pfn:109e3a >> page:e08344278e80 count:0 mapcount:1 mapping: index:0x0 >> flags: 0xf8000() >> raw: 000f8000 dead0100 dead0200 >> raw: >> page dumped because: nonzero mapcount >> ... >> Workqueue: events hot_add_req [hv_balloon] >> Call Trace: >> dump_stack+0x5c/0x80 >> bad_page.cold.112+0x7f/0xb2 >> free_pcppages_bulk+0x4b8/0x690 >> free_unref_page+0x54/0x70 >> hv_page_online_one+0x5c/0x80 [hv_balloon] >> hot_add_req.cold.24+0x182/0x835 [hv_balloon] >> ... >> >> Turns out that we now have deferred struct page initialization for memory >> hotplug so e.g. memory_block_action() in drivers/base/memory.c does >> pages_correctly_probed() check and in that check it avoids inspecting >> struct pages and checks sections instead. But in Hyper-V balloon driver we >> do PageReserved(pfn_to_page()) check and this is now wrong. >> >> Switch to checking online_section_nr() instead. >> >> Signed-off-by: Vitaly Kuznetsov >> --- >> drivers/hv/hv_balloon.c | 10 ++ >> 1 file changed, 6 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c >> index 5301fef16c31..7c6349a50ef1 100644 >> --- a/drivers/hv/hv_balloon.c >> +++ b/drivers/hv/hv_balloon.c >> @@ -888,12 +888,14 @@ static unsigned long handle_pg_range(unsigned long >> pg_start, >> pfn_cnt -= pgs_ol; >> /* >> * Check if the corresponding memory block is already >> - * online by checking its last previously backed page. >> - * In case it is we need to bring rest (which was not >> - * backed previously) online too. >> + * online. It is possible to observe struct pages still >> + * being uninitialized here so check section instead. >> + * In case the section is online we need to bring the >> + * rest of pfns (which were not backed previously) >> + * online too. >> */ >> if (start_pfn > has->start_pfn && >> -!PageReserved(pfn_to_page(start_pfn - 1))) >> +online_section_nr(pfn_to_section_nr(start_pfn))) >> hv_bring_pgs_online(has, start_pfn, pgs_ol); >> >> } >> > > I wonder if you should use pfn_to_online_page() and check for PageOffline(). > > (I guess online_section_nr() should also do the trick) I'm worried a bit about racing with mm code here as we're not doing mem_hotplug_begin()/done() so I'd slightly prefer keeping online_section_nr() (pfn_to_online_page() also uses it but then it gets to the particular struct page). Moreover, with pfn_to_online_page() we will be looking at some other pfn - because the start_pfn is definitelly offline (pre-patch we were looking at start_pfn-1). Just looking at the whole section seems cleaner. P.S. I still think about bringing mem_hotplug_begin()/done() to hv_balloon but that's going to be a separate discussion, here I want to have a small fix backportable to stable. Thanks, -- Vitaly ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wilc1000: fix cast to restricted __le32
On Mon, Jan 07, 2019 at 03:54:37PM +0300, Dan Carpenter wrote:
> I'm sort of surprised that the zero day bot didn't complain about this.
> It probably should.
>
> The endianness checking is not turned on by default in Sparse. You have
> to do "make C=1 CF=-D__CHECK_ENDIAN__" to turn it on.
Bitwise (and thus endian) checking is enabled by default in the kernel
since 05de97003 ("linux/types.h: enable endian checks for all sparse builds")
included in v4.10-rc1. Since then they make more than half of sparse
warnings (in a x86-64 allyesconfig).
Best regards,
-- Luc
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: linux-5.0-rc1/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c:412]: (style) Expression is always false
On Mon, Jan 07, 2019 at 11:40:08AM +, David Binderman wrote: > > Hello there, > > linux-5.0-rc1/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c:412]: > (style) Expression is always false because 'else if' condition matches > previous condition at line 410. > > Source code is > > else if (pRaInfo->HighestRate > 0x0b) > pRaInfo->PTModeSS = 2; > else if (pRaInfo->HighestRate > 0x0b) > pRaInfo->PTModeSS = 1; > That's true, but that's how to the code was originally when it was committed 5 years ago so it's hard to tell what the fix should be... regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: rtl8192e: need help with variable naming convention
On Mon, Jan 07, 2019 at 11:52:14AM +0100, Greg KH wrote: > On Mon, Jan 07, 2019 at 04:04:46PM +0530, Himadri Pandya wrote: > > Hello, > > > > I'm getting started with device drivers. And as a starter, I'm working on > > some clean-up patches. I'm particularly targeting to rename a structure > > array "ChannelPlan"(in file dot11d.c) to fix a checkpatch.pl warning "Avoid > > CamelCase". According to the coding style, it should be converted to > > "channel_plan". But the code contains a function argument with the same > > name "channel_plan". Should I then rename the array to something like > > "channel_name_"? Ending a name with an underscore is quite ugly. Feel free to get more creative with the naming scheme. Rethink things as much as you can, don't assume the original code is something to copy. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] v2 staging: rtl8723bs: Clean up dead code
Oh, put the v2 inside the square brackets. [PATCH v3]. That way it gets handled correctly by `cat raw_email.txt | git am`. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] v2 staging: rtl8723bs: Clean up dead code
On Sun, Jan 06, 2019 at 10:20:59AM -0600, Aditya Pakki wrote: > rtw_wps_start() is part of dead code due to CONFIG_INTEL_WIDI. > The fix removes the deadcode and replaces the function with NULL > in rtw_private_handler. Identified as part of copy_from_user bug. > Thanks! Reviewed-by: Dan Carpenter regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wilc1000: fix cast to restricted __le32
I'm sort of surprised that the zero day bot didn't complain about this.
It probably should.
The endianness checking is not turned on by default in Sparse. You have
to do "make C=1 CF=-D__CHECK_ENDIAN__" to turn it on.
regards,
dan carpenter
On Sat, Jan 05, 2019 at 09:23:23AM +0100, Július Milan wrote:
> Fixes the following sparse warnings:
>
> drivers/staging/wilc1000/host_interface.c:2360:30: warning:
> incorrect type in assignment (different base types)
> expected restricted __le32 [addressable] [assigned] [usertype] frame_type
> got restricted __le16 [usertype]
>
> Fixes: 147ccfd451024 ("staging: wilc1000: handle mgmt_frame_register ops from
> cfg82011 context")
> Signed-off-by: Július Milan
> ---
> drivers/staging/wilc1000/host_interface.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/wilc1000/host_interface.c
> b/drivers/staging/wilc1000/host_interface.c
> index 5dae6e7155d3..07c3d6293573 100644
> --- a/drivers/staging/wilc1000/host_interface.c
> +++ b/drivers/staging/wilc1000/host_interface.c
> @@ -2357,7 +2357,7 @@ void wilc_frame_register(struct wilc_vif *vif, u16
> frame_type, bool reg)
> default:
> break;
> }
> - reg_frame.frame_type = cpu_to_le16(frame_type);
> + reg_frame.frame_type = cpu_to_le32(frame_type);
> result = wilc_send_config_pkt(vif, WILC_SET_CFG, , 1,
> wilc_get_vif_idx(vif));
> if (result)
> --
> 2.14.5
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: linux-5.0-rc1/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c:412]: (style) Expression is always false
On Mon, Jan 07, 2019 at 11:40:08AM +, David Binderman wrote: > > Hello there, > > linux-5.0-rc1/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c:412]: > (style) Expression is always false because 'else if' condition matches > previous condition at line 410. > > Source code is > > else if (pRaInfo->HighestRate > 0x0b) > pRaInfo->PTModeSS = 2; > else if (pRaInfo->HighestRate > 0x0b) > pRaInfo->PTModeSS = 1; > > Suggest code rework. Patches are always gladly accepted! thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
linux-5.0-rc1/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c:412]: (style) Expression is always false
Hello there, linux-5.0-rc1/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c:412]: (style) Expression is always false because 'else if' condition matches previous condition at line 410. Source code is else if (pRaInfo->HighestRate > 0x0b) pRaInfo->PTModeSS = 2; else if (pRaInfo->HighestRate > 0x0b) pRaInfo->PTModeSS = 1; Suggest code rework. Regards David Binderman ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] media: staging/intel-ipu3: Fix err handle of ipu3_css_find_binary
Hi Bingbu, On Mon, Jan 07, 2019 at 10:38:19AM +0800, Bingbu Cao wrote: > Hi, Haibing > > Thanks for your patch, it looks fine for me. > Reviewed-by: Bingbu Cao > > On 12/29/2018 10:45 AM, YueHaibing wrote: > > css->pipes[pipe].bindex = binary; I'm taking Colin's patch with equivalent content; it was there first. Thanks! -- Sakari Ailus sakari.ai...@linux.intel.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: rtl8192e: need help with variable naming convention
On Mon, Jan 07, 2019 at 04:04:46PM +0530, Himadri Pandya wrote: > Hello, > > I'm getting started with device drivers. And as a starter, I'm working on > some clean-up patches. I'm particularly targeting to rename a structure > array "ChannelPlan"(in file dot11d.c) to fix a checkpatch.pl warning "Avoid > CamelCase". According to the coding style, it should be converted to > "channel_plan". But the code contains a function argument with the same > name "channel_plan". Should I then rename the array to something like > "channel_name_"? I'm sorry for asking such a silly question. But I want to > know if renaming it in such a ways fits in the convention before I make the > change. A structure name is different from a function name, so odds are you can just do this with no problems. Try it and find out! greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hv_balloon: avoid touching uninitialized struct page during tail onlining
On 04.01.19 15:19, Vitaly Kuznetsov wrote: > Hyper-V memory hotplug protocol has 2M granularity and in Linux x86 we use > 128M. To deal with it we implement partial section onlining by registering > custom page onlining callback (hv_online_page()). Later, when more memory > arrives we try to online the 'tail' (see hv_bring_pgs_online()). > > It was found that in some cases this 'tail' onlining causes issues: > > BUG: Bad page state in process kworker/0:2 pfn:109e3a > page:e08344278e80 count:0 mapcount:1 mapping: index:0x0 > flags: 0xf8000() > raw: 000f8000 dead0100 dead0200 > raw: > page dumped because: nonzero mapcount > ... > Workqueue: events hot_add_req [hv_balloon] > Call Trace: > dump_stack+0x5c/0x80 > bad_page.cold.112+0x7f/0xb2 > free_pcppages_bulk+0x4b8/0x690 > free_unref_page+0x54/0x70 > hv_page_online_one+0x5c/0x80 [hv_balloon] > hot_add_req.cold.24+0x182/0x835 [hv_balloon] > ... > > Turns out that we now have deferred struct page initialization for memory > hotplug so e.g. memory_block_action() in drivers/base/memory.c does > pages_correctly_probed() check and in that check it avoids inspecting > struct pages and checks sections instead. But in Hyper-V balloon driver we > do PageReserved(pfn_to_page()) check and this is now wrong. > > Switch to checking online_section_nr() instead. > > Signed-off-by: Vitaly Kuznetsov > --- > drivers/hv/hv_balloon.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c > index 5301fef16c31..7c6349a50ef1 100644 > --- a/drivers/hv/hv_balloon.c > +++ b/drivers/hv/hv_balloon.c > @@ -888,12 +888,14 @@ static unsigned long handle_pg_range(unsigned long > pg_start, > pfn_cnt -= pgs_ol; > /* >* Check if the corresponding memory block is already > - * online by checking its last previously backed page. > - * In case it is we need to bring rest (which was not > - * backed previously) online too. > + * online. It is possible to observe struct pages still > + * being uninitialized here so check section instead. > + * In case the section is online we need to bring the > + * rest of pfns (which were not backed previously) > + * online too. >*/ > if (start_pfn > has->start_pfn && > - !PageReserved(pfn_to_page(start_pfn - 1))) > + online_section_nr(pfn_to_section_nr(start_pfn))) > hv_bring_pgs_online(has, start_pfn, pgs_ol); > > } > I wonder if you should use pfn_to_online_page() and check for PageOffline(). (I guess online_section_nr() should also do the trick) -- Thanks, David / dhildenb ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] v2 staging: rtl8723bs: Clean up dead code
On Sun, Jan 06, 2019 at 10:20:59AM -0600, Aditya Pakki wrote: > rtw_wps_start() is part of dead code due to CONFIG_INTEL_WIDI. > The fix removes the deadcode and replaces the function with NULL > in rtw_private_handler. Identified as part of copy_from_user bug. > > Signed-off-by: Aditya Pakki > --- > .../staging/rtl8723bs/os_dep/ioctl_linux.c| 34 +-- > 1 file changed, 1 insertion(+), 33 deletions(-) What changed from v1? Always put that below the --- line. Please fix up and send v3. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [linux-sunxi] [PATCH v2 1/2] media: v4l: Add definitions for the HEVC slice format and controls
Hi,
On Mon, 2019-01-07 at 11:49 +0800, Randy Li wrote:
> On 12/12/18 8:51 PM, Paul Kocialkowski wrote:
> > Hi,
> >
> > On Wed, 2018-12-05 at 21:59 +0100, Jernej Škrabec wrote:
> >
> > > > +
> > > > +#define V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_BEFORE 0x01
> > > > +#define V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_AFTER 0x02
> > > > +#define V4L2_HEVC_DPB_ENTRY_RPS_LT_CURR0x03
> > > > +
> > > > +#define V4L2_HEVC_DPB_ENTRIES_NUM_MAX 16
> > > > +
> > > > +struct v4l2_hevc_dpb_entry {
> > > > + __u32 buffer_tag;
> > > > + __u8rps;
> > > > + __u8field_pic;
> > > > + __u16 pic_order_cnt[2];
> > > > +};
>
> Please add a property for reference index, if that rps is not used for
> this, some device would request that(not the rockchip one). And
> Rockchip's VDPU1 and VDPU2 for AVC would request a similar property.
What exactly is that reference index? Is it a bitstream element or
something deduced from the bitstream?
> Adding another buffer_tag for referring the memory of the motion vectors
> for each frames. Or a better method is add a meta data to echo picture
> buffer, since the picture output is just the same as the original,
> display won't care whether the motion vectors are written the button of
> picture or somewhere else.
The motion vectors are passed as part of the raw bitstream data, in the
slices. Is there a case where the motion vectors are coded differently?
> > > > +
> > > > +struct v4l2_hevc_pred_weight_table {
> > > > + __u8luma_log2_weight_denom;
> > > > + __s8delta_chroma_log2_weight_denom;
> > > > +
> > > > + __s8delta_luma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
> > > > + __s8luma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
> > > > + __s8
> > > > delta_chroma_weight_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
> > > > + __s8chroma_offset_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
> > > > +
> > > > + __s8delta_luma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
> > > > + __s8luma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
> > > > + __s8
> > > > delta_chroma_weight_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
> > > > + __s8chroma_offset_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX][2];
> > > > +};
> > > > +
> Those properties I think are not necessary are applying for the
> Rockchip's device, may not work for the others.
Yes, it's possible that some of the elements are not necessary for some
decoders. What we want is to cover all the elements that might be
required for a decoder.
> > > > +struct v4l2_ctrl_hevc_slice_params {
> > > > + __u32 bit_size;
> > > > + __u32 data_bit_offset;
> > > > +
> > > > + /* ISO/IEC 23008-2, ITU-T Rec. H.265: NAL unit header */
> > > > + __u8nal_unit_type;
> > > > + __u8nuh_temporal_id_plus1;
> > > > +
> > > > + /* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment
> > > > header */
> > > > + __u8slice_type;
> > > > + __u8colour_plane_id;
>
> > > > + __u16 slice_pic_order_cnt;
> > > > + __u8slice_sao_luma_flag;
> > > > + __u8slice_sao_chroma_flag;
> > > > + __u8slice_temporal_mvp_enabled_flag;
> > > > + __u8num_ref_idx_l0_active_minus1;
> > > > + __u8num_ref_idx_l1_active_minus1;
> Rockchip's decoder doesn't use this part.
> > > > + __u8mvd_l1_zero_flag;
> > > > + __u8cabac_init_flag;
> > > > + __u8collocated_from_l0_flag;
> > > > + __u8collocated_ref_idx;
> > > > + __u8five_minus_max_num_merge_cand;
> > > > + __u8use_integer_mv_flag;
> > > > + __s8slice_qp_delta;
> > > > + __s8slice_cb_qp_offset;
> > > > + __s8slice_cr_qp_offset;
> > > > + __s8slice_act_y_qp_offset;
> > > > + __s8slice_act_cb_qp_offset;
> > > > + __s8slice_act_cr_qp_offset;
> > > > + __u8slice_deblocking_filter_disabled_flag;
> > > > + __s8slice_beta_offset_div2;
> > > > + __s8slice_tc_offset_div2;
> > > > + __u8slice_loop_filter_across_slices_enabled_flag;
> > > > +
> > > > + /* ISO/IEC 23008-2, ITU-T Rec. H.265: Picture timing SEI
> > > > message */
> > > > + __u8pic_struct;
> I think the decoder doesn't care about this, it is used for display.
The purpose of this field is to indicate whether the current picture is
a progressive frame or an interlaced field picture, which is useful for
decoding.
At least our decoder has a register field to indicate frame/top
field/bottom field, so we certainly need to keep the info around.
Looking at the spec and the ffmpeg implementation, it looks like this
flag of the bitstream is the usual way to report field coding.
Cheers,
Paul
> > > > +
> > > > + /* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment
> > > > header */
> > > > +
