Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

2018-10-11 Thread Andy Lutomirski 
On Thu, Oct 11, 2018 at 3:28 PM Marcelo Tosatti  wrote:
>
> On Tue, Oct 09, 2018 at 01:09:42PM -0700, Andy Lutomirski wrote:
> > On Tue, Oct 9, 2018 at 8:28 AM Marcelo Tosatti  wrote:
> > >
> > > On Mon, Oct 08, 2018 at 10:38:22AM -0700, Andy Lutomirski wrote:
> > > > On Mon, Oct 8, 2018 at 8:27 AM Marcelo Tosatti  
> > > > wrote:
> >
> > > > I read the comment three more times and even dug through the git
> > > > history.  It seems like what you're saying is that, under certain
> > > > conditions (which arguably would be bugs in the core Linux timing
> > > > code),
> > >
> > > I don't see that as a bug. Its just a side effect of reading two
> > > different clocks (one is CLOCK_MONOTONIC and the other is TSC),
> > > and using those two clocks to as a "base + offset".
> > >
> > > As the comment explains, if you do that, can't guarantee monotonicity.
> > >
> > > > actually calling ktime_get_boot_ns() could be non-monotonic
> > > > with respect to the kvmclock timing.  But get_kvmclock_ns() isn't used
> > > > for VM timing as such -- it's used for the IOCTL interfaces for
> > > > updating the time offset.  So can you explain how my patch is
> > > > incorrect?
> > >
> > > ktime_get_boot_ns() has frequency correction applied, while
> > > reading masterclock + TSC offset does not.
> > >
> > > So the clock reads differ.
> > >
> >
> > Ah, okay, I finally think I see what's going on.  In the kvmclock data
> > exposed to the guest, tsc_shift and tsc_to_system_mul come from
> > tgt_tsc_khz, whereas master_kernel_ns and master_cycle_now come from
> > CLOCK_BOOTTIME.  So the kvmclock and kernel clock drift apart at a
> > rate given by the frequency shift and then suddenly agree again every
> > time the pvclock data is updated.
>
> Yes.
>
> > Is there a reason to do it this way?
>
> Since pvclock updates which update system_timestamp are expensive (must stop 
> all vcpus),
> they should be avoided.
>

Fair enough.

> So only HW TSC counts

makes sense.

>, and used as offset against vcpu's tsc_timestamp.
>

Why don't you just expose CLOCK_MONTONIC_RAW or CLOCK_MONOTONIC_RAW
plus suspend time, though?  Then you would actually be tracking a real
kernel timekeeping mode, and you wouldn't need all this complicated
offsetting work to avoid accidentally going backwards.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH net-next] hv_netvsc: fix vf serial matching with pci slot info

2018-10-11 Thread Haiyang Zhang 



> -Original Message-
> From: Haiyang Zhang 
> Sent: Thursday, October 11, 2018 4:15 PM
> To: da...@davemloft.net; net...@vger.kernel.org
> Cc: Haiyang Zhang ; KY Srinivasan
> ; Stephen Hemminger ;
> o...@aepfle.de; vkuznets ;
> de...@linuxdriverproject.org; linux-ker...@vger.kernel.org
> Subject: [PATCH net-next] hv_netvsc: fix vf serial matching with pci slot info
> 
> From: Haiyang Zhang 
> 
> The VF device's serial number is saved as a string in PCI slot's kobj name, 
> not
> the slot->number. This patch corrects the netvsc driver, so the VF device can 
> be
> successfully paired with synthetic NIC.
> 
> Fixes: 00d7ddba1143 ("hv_netvsc: pair VF based on serial number")
> Signed-off-by: Haiyang Zhang 

Thanks Stephen for the reminder -- I added the "reported-by" here:

Reported-by: Vitaly Kuznetsov 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

2018-10-11 Thread Marcelo Tosatti 
On Tue, Oct 09, 2018 at 01:09:42PM -0700, Andy Lutomirski wrote:
> On Tue, Oct 9, 2018 at 8:28 AM Marcelo Tosatti  wrote:
> >
> > On Mon, Oct 08, 2018 at 10:38:22AM -0700, Andy Lutomirski wrote:
> > > On Mon, Oct 8, 2018 at 8:27 AM Marcelo Tosatti  
> > > wrote:
> 
> > > I read the comment three more times and even dug through the git
> > > history.  It seems like what you're saying is that, under certain
> > > conditions (which arguably would be bugs in the core Linux timing
> > > code),
> >
> > I don't see that as a bug. Its just a side effect of reading two
> > different clocks (one is CLOCK_MONOTONIC and the other is TSC),
> > and using those two clocks to as a "base + offset".
> >
> > As the comment explains, if you do that, can't guarantee monotonicity.
> >
> > > actually calling ktime_get_boot_ns() could be non-monotonic
> > > with respect to the kvmclock timing.  But get_kvmclock_ns() isn't used
> > > for VM timing as such -- it's used for the IOCTL interfaces for
> > > updating the time offset.  So can you explain how my patch is
> > > incorrect?
> >
> > ktime_get_boot_ns() has frequency correction applied, while
> > reading masterclock + TSC offset does not.
> >
> > So the clock reads differ.
> >
> 
> Ah, okay, I finally think I see what's going on.  In the kvmclock data
> exposed to the guest, tsc_shift and tsc_to_system_mul come from
> tgt_tsc_khz, whereas master_kernel_ns and master_cycle_now come from
> CLOCK_BOOTTIME.  So the kvmclock and kernel clock drift apart at a
> rate given by the frequency shift and then suddenly agree again every
> time the pvclock data is updated.

Yes.

> Is there a reason to do it this way?

Since pvclock updates which update system_timestamp are expensive (must stop 
all vcpus), 
they should be avoided. 

So only HW TSC counts, and used as offset against vcpu's tsc_timestamp.



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH net-next] hv_netvsc: fix vf serial matching with pci slot info

2018-10-11 Thread Haiyang Zhang 
From: Haiyang Zhang 

The VF device's serial number is saved as a string in PCI slot's
kobj name, not the slot->number. This patch corrects the netvsc
driver, so the VF device can be successfully paired with synthetic
NIC.

Fixes: 00d7ddba1143 ("hv_netvsc: pair VF based on serial number")
Signed-off-by: Haiyang Zhang 
---
 drivers/net/hyperv/netvsc_drv.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 9bcaf204a7d4..8121ce34a39f 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -2030,14 +2030,15 @@ static void netvsc_vf_setup(struct work_struct *w)
rtnl_unlock();
 }
 
-/* Find netvsc by VMBus serial number.
- * The PCI hyperv controller records the serial number as the slot.
+/* Find netvsc by VF serial number.
+ * The PCI hyperv controller records the serial number as the slot kobj name.
  */
 static struct net_device *get_netvsc_byslot(const struct net_device *vf_netdev)
 {
struct device *parent = vf_netdev->dev.parent;
struct net_device_context *ndev_ctx;
struct pci_dev *pdev;
+   u32 serial;
 
if (!parent || !dev_is_pci(parent))
return NULL; /* not a PCI device */
@@ -2048,16 +2049,22 @@ static struct net_device *get_netvsc_byslot(const 
struct net_device *vf_netdev)
return NULL;
}
 
+   if (kstrtou32(pdev->slot->kobj.name, 10, )) {
+   netdev_notice(vf_netdev, "Invalid vf serial:%s\n",
+ pdev->slot->kobj.name);
+   return NULL;
+   }
+
list_for_each_entry(ndev_ctx, _dev_list, list) {
if (!ndev_ctx->vf_alloc)
continue;
 
-   if (ndev_ctx->vf_serial == pdev->slot->number)
+   if (ndev_ctx->vf_serial == serial)
return hv_get_drvdata(ndev_ctx->device_ctx);
}
 
netdev_notice(vf_netdev,
- "no netdev found for slot %u\n", pdev->slot->number);
+ "no netdev found for vf serial:%u\n", serial);
return NULL;
 }
 
-- 
2.18.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 6/8] staging: rtl8188eu: cleanup long lines in rtw_get_sta_pending()

2018-10-11 Thread Michael Straube 
Line break lines over 80 characters in rtw_get_sta_pending() to
clear checkpatch warnings.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_xmit.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c 
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index 55ce9e67d1c7..53325599ed96 100644
--- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
+++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
@@ -1426,7 +1426,8 @@ struct xmit_frame *rtw_dequeue_xframe(struct xmit_priv 
*pxmitpriv, struct hw_xmi
return pxmitframe;
 }
 
-struct tx_servq *rtw_get_sta_pending(struct adapter *padapter, struct sta_info 
*psta, int up, u8 *ac)
+struct tx_servq *rtw_get_sta_pending(struct adapter *padapter,
+struct sta_info *psta, int up, u8 *ac)
 {
struct tx_servq *ptxservq;
 
@@ -1435,26 +1436,30 @@ struct tx_servq *rtw_get_sta_pending(struct adapter 
*padapter, struct sta_info *
case 2:
ptxservq = >sta_xmitpriv.bk_q;
*(ac) = 3;
-   RT_TRACE(_module_rtl871x_xmit_c_, _drv_info_, ("%s : BK\n", 
__func__));
+   RT_TRACE(_module_rtl871x_xmit_c_, _drv_info_,
+("%s : BK\n", __func__));
break;
case 4:
case 5:
ptxservq = >sta_xmitpriv.vi_q;
*(ac) = 1;
-   RT_TRACE(_module_rtl871x_xmit_c_, _drv_info_, ("%s : VI\n", 
__func__));
+   RT_TRACE(_module_rtl871x_xmit_c_, _drv_info_,
+("%s : VI\n", __func__));
break;
case 6:
case 7:
ptxservq = >sta_xmitpriv.vo_q;
*(ac) = 0;
-   RT_TRACE(_module_rtl871x_xmit_c_, _drv_info_, ("%s : VO\n", 
__func__));
+   RT_TRACE(_module_rtl871x_xmit_c_, _drv_info_,
+("%s : VO\n", __func__));
break;
case 0:
case 3:
default:
ptxservq = >sta_xmitpriv.be_q;
*(ac) = 2;
-   RT_TRACE(_module_rtl871x_xmit_c_, _drv_info_, ("%s : BE\n", 
__func__));
+   RT_TRACE(_module_rtl871x_xmit_c_, _drv_info_,
+("%s : BE\n", __func__));
break;
}
 
-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 7/8] staging: rtl8188eu: cleanup long lines in stop_sta_xmit()

2018-10-11 Thread Michael Straube 
Line break lines over 80 characters in stop_sta_xmit() to
clear checkpatch warnings.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_xmit.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c 
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index 53325599ed96..f0dde8aa853d 100644
--- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
+++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
@@ -1775,21 +1775,26 @@ void stop_sta_xmit(struct adapter *padapter, struct 
sta_info *psta)
 
pstapriv->sta_dz_bitmap |= BIT(psta->aid);
 
-   dequeue_xmitframes_to_sleeping_queue(padapter, psta, 
>vo_q.sta_pending);
+   dequeue_xmitframes_to_sleeping_queue(padapter, psta,
+>vo_q.sta_pending);
list_del_init(>vo_q.tx_pending);
 
-   dequeue_xmitframes_to_sleeping_queue(padapter, psta, 
>vi_q.sta_pending);
+   dequeue_xmitframes_to_sleeping_queue(padapter, psta,
+>vi_q.sta_pending);
list_del_init(>vi_q.tx_pending);
 
-   dequeue_xmitframes_to_sleeping_queue(padapter, psta, 
>be_q.sta_pending);
+   dequeue_xmitframes_to_sleeping_queue(padapter, psta,
+>be_q.sta_pending);
list_del_init(>be_q.tx_pending);
 
-   dequeue_xmitframes_to_sleeping_queue(padapter, psta, 
>bk_q.sta_pending);
+   dequeue_xmitframes_to_sleeping_queue(padapter, psta,
+>bk_q.sta_pending);
list_del_init(>bk_q.tx_pending);
 
/* for BC/MC Frames */
pstaxmitpriv = _bmc->sta_xmitpriv;
-   dequeue_xmitframes_to_sleeping_queue(padapter, psta_bmc, 
>be_q.sta_pending);
+   dequeue_xmitframes_to_sleeping_queue(padapter, psta_bmc,
+>be_q.sta_pending);
list_del_init(>be_q.tx_pending);
 
spin_unlock_bh(>lock);
-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 4/8] staging: rtl8188eu: remove commented code

2018-10-11 Thread Michael Straube 
Remove unused commented code in the file core/rte_xmit.c.
Clears 'please, no space before tabs' and 'line over 80
characters' checkpatch warnings.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_xmit.c | 23 ++-
 1 file changed, 2 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c 
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index 4a2921d8c862..9413cd21e201 100644
--- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
+++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
@@ -77,8 +77,6 @@ s32 _rtw_init_xmit_priv(struct xmit_priv *pxmitpriv, struct 
adapter *padapter)
goto exit;
}
pxmitpriv->pxmit_frame_buf = PTR_ALIGN(pxmitpriv->pallocated_frame_buf, 
4);
-   /* pxmitpriv->pxmit_frame_buf = pxmitpriv->pallocated_frame_buf + 4 - */
-   /*  ((size_t) 
(pxmitpriv->pallocated_frame_buf) &3); */
 
pxframe = (struct xmit_frame *)pxmitpriv->pxmit_frame_buf;
 
@@ -115,8 +113,6 @@ s32 _rtw_init_xmit_priv(struct xmit_priv *pxmitpriv, struct 
adapter *padapter)
}
 
pxmitpriv->pxmitbuf = PTR_ALIGN(pxmitpriv->pallocated_xmitbuf, 4);
-   /* pxmitpriv->pxmitbuf = pxmitpriv->pallocated_xmitbuf + 4 - */
-   /*  ((size_t) 
(pxmitpriv->pallocated_xmitbuf) &3); */
 
pxmitbuf = (struct xmit_buf *)pxmitpriv->pxmitbuf;
 
@@ -321,13 +317,6 @@ static void update_attrib_vcs_info(struct adapter 
*padapter, struct xmit_frame *
 
 static void update_attrib_phy_info(struct pkt_attrib *pattrib, struct sta_info 
*psta)
 {
-   /*if (psta->rtsen)
-   pattrib->vcs_mode = RTS_CTS;
-   else if (psta->cts2self)
-   pattrib->vcs_mode = CTS_TO_SELF;
-   else
-   pattrib->vcs_mode = NONE_VCS;*/
-
pattrib->mdata = 0;
pattrib->eosp = 0;
pattrib->triggered = 0;
@@ -606,7 +595,7 @@ static s32 xmitframe_addmic(struct adapter *padapter, 
struct xmit_frame *pxmitfr
 
hw_hdr_offset = TXDESC_SIZE + (pxmitframe->pkt_offset * 
PACKET_OFFSET_SZ);
 
-   if (pattrib->encrypt == _TKIP_) {/* if 
(psecuritypriv->dot11PrivacyAlgrthm == _TKIP_PRIVACY_) */
+   if (pattrib->encrypt == _TKIP_) {
/* encode mic code */
if (stainfo) {
u8 null_key[16] = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
@@ -621,11 +610,8 @@ static s32 xmitframe_addmic(struct adapter *padapter, 
struct xmit_frame *pxmitfr
/* start to calculate the mic code */
rtw_secmicsetkey(, 
psecuritypriv->dot118021XGrptxmickey[psecuritypriv->dot118021XGrpKeyid].skey);
} else {
-   if 
(!memcmp(>dot11tkiptxmickey.skey[0], null_key, 16)) {
-   /* 
DbgPrint("\nxmitframe_addmic:stainfo->dot11tkiptxmickey == 0\n"); */
-   /* msleep(10); */
+   if 
(!memcmp(>dot11tkiptxmickey.skey[0], null_key, 16))
return _FAIL;
-   }
/* start to calculate the mic code */
rtw_secmicsetkey(, 
>dot11tkiptxmickey.skey[0]);
}
@@ -1157,7 +1143,6 @@ struct xmit_buf *rtw_alloc_xmitbuf_ext(struct xmit_priv 
*pxmitpriv)
list_del_init(>list);
pxmitpriv->free_xmit_extbuf_cnt--;
pxmitbuf->priv_data = NULL;
-   /* pxmitbuf->ext_tag = true; */
if (pxmitbuf->sctx) {
DBG_88E("%s pxmitbuf->sctx is not NULL\n", __func__);
rtw_sctx_done_err(>sctx, 
RTW_SCTX_DONE_BUF_ALLOC);
@@ -1194,8 +1179,6 @@ struct xmit_buf *rtw_alloc_xmitbuf(struct xmit_priv 
*pxmitpriv)
struct xmit_buf *pxmitbuf;
struct __queue *pfree_xmitbuf_queue = >free_xmitbuf_queue;
 
-   /* DBG_88E("+rtw_alloc_xmitbuf\n"); */
-
spin_lock_irqsave(_xmitbuf_queue->lock, irql);
pxmitbuf = list_first_entry_or_null(_xmitbuf_queue->queue,
struct xmit_buf, list);
@@ -1286,7 +1269,6 @@ struct xmit_frame *rtw_alloc_xmitframe(struct xmit_priv 
*pxmitpriv)
pxframe->pxmitbuf = NULL;
 
memset(>attrib, 0, sizeof(struct pkt_attrib));
-   /* pxframe->attrib.psta = NULL; */
 
pxframe->frame_tag = DATA_FRAMETAG;
 
@@ -1360,7 +1342,6 @@ s32 rtw_xmitframe_enqueue(struct adapter *padapter, 
struct xmit_frame *pxmitfram
if (rtw_xmit_classifier(padapter, pxmitframe) == _FAIL) {
RT_TRACE(_module_rtl871x_xmit_c_, _drv_err_,
 ("%s: drop xmit pkt for classifier fail\n", __func__));
-/* pxmitframe->pkt = NULL; */
return _FAIL;
}
 
-- 
2.19.1

[PATCH 8/8] staging: rtl8188eu: remove whitespace in qos_acm()

2018-10-11 Thread Michael Straube 
Remove whitespace in qos_acm() to improve readability.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_xmit.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c 
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index f0dde8aa853d..ce631efd48e5 100644
--- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
+++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
@@ -335,9 +335,9 @@ static void update_attrib_phy_info(struct pkt_attrib 
*pattrib, struct sta_info *
pattrib->retry_ctrl = false;
 }
 
-u8 qos_acm(u8 acm_mask, u8 priority)
+u8 qos_acm(u8 acm_mask, u8 priority)
 {
-   u8  change_priority = priority;
+   u8 change_priority = priority;
 
switch (priority) {
case 0:
-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 5/8] staging: rtl8188eu: cleanup block comments

2018-10-11 Thread Michael Straube 
Cleanup block comments to clear 'please, no space before tabs'
and 'line over 80 characters' checkpatch warnings.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_xmit.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c 
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index 9413cd21e201..55ce9e67d1c7 100644
--- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
+++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
@@ -250,10 +250,12 @@ static void update_attrib_vcs_info(struct adapter 
*padapter, struct xmit_frame *
else /* no frag */
sz = pattrib->last_txcmdsz;
 
-   /*  (1) RTS_Threshold is compared to the MPDU, not MSDU. */
-   /*  (2) If there are more than one frag in  this MSDU, only the first 
frag uses protection frame. */
-   /*  Other fragments are protected by previous fragment. */
-   /*  So we only need to check the length of first fragment. 
*/
+   /* (1) RTS_Threshold is compared to the MPDU, not MSDU.
+* (2) If there are more than one frag in this MSDU,
+* only the first frag uses protection frame.
+* Other fragments are protected by previous fragment.
+* So we only need to check the length of first fragment.
+*/
if (pmlmeext->cur_wireless_mode < WIRELESS_11_24N  || 
padapter->registrypriv.wifi_spec) {
if (sz > padapter->registrypriv.rts_thresh) {
pattrib->vcs_mode = RTS_CTS;
@@ -373,8 +375,10 @@ static void set_qos(struct sk_buff *skb, struct pkt_attrib 
*pattrib)
skb_copy_bits(skb, ETH_HLEN, _hdr, sizeof(ip_hdr));
pattrib->priority = ip_hdr.tos >> 5;
} else if (pattrib->ether_type == ETH_P_PAE) {
-   /*  "When priority processing of data frames is supported, */
-   /*  a STA's SME should send EAPOL-Key frames at the highest 
priority." */
+   /* When priority processing of data frames is supported,
+* a STA's SME should send EAPOL-Key frames at the highest
+* priority.
+*/
pattrib->priority = 7;
} else {
pattrib->priority = 0;
@@ -420,8 +424,10 @@ static s32 update_attrib(struct adapter *padapter, struct 
sk_buff *pkt, struct p
pattrib->pktlen = pkt->len - ETH_HLEN;
 
if (pattrib->ether_type == ETH_P_IP) {
-   /*  The following is for DHCP and ARP packet, we use cck1M to 
tx these packets and let LPS awake some time */
-   /*  to prevent DHCP protocol fail */
+   /* The following is for DHCP and ARP packet, we use
+* cck1M to tx these packets and let LPS awake some
+* time to prevent DHCP protocol fail.
+*/
u8 tmp[24];
 
skb_copy_bits(pkt, ETH_HLEN, tmp, 24);
-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/8] staging: rtl8188eu: cleanup alignment issue

2018-10-11 Thread Michael Straube 
Clear a 'Alignment should match open parenthesis'
checkpatch issue.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_xmit.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c 
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index 07b6e680377f..4a2921d8c862 100644
--- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
+++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
@@ -863,9 +863,9 @@ s32 rtw_txframes_pending(struct adapter *padapter)
struct xmit_priv *pxmitpriv = >xmitpriv;
 
return (!list_empty(>be_pending.queue) ||
-   !list_empty(>bk_pending.queue) ||
-   !list_empty(>vi_pending.queue) ||
-   !list_empty(>vo_pending.queue));
+   !list_empty(>bk_pending.queue) ||
+   !list_empty(>vi_pending.queue) ||
+   !list_empty(>vo_pending.queue));
 }
 
 s32 rtw_txframes_sta_ac_pending(struct adapter *padapter, struct pkt_attrib 
*pattrib)
-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/8] staging: rtl8188eu: cleanup style issues in rtw_xmit.c

2018-10-11 Thread Michael Straube 
Cleanup style/checkpatch issues in the file core/rtw_xmit.c.

Michael Straube (8):
  staging: rtl8188eu: cleanup missing spaces around operators
  staging: rtl8188eu: use __func__ in qos_acm()
  staging: rtl8188eu: cleanup alignment issue
  staging: rtl8188eu: remove commented code
  staging: rtl8188eu: cleanup block comments
  staging: rtl8188eu: cleanup long lines in rtw_get_sta_pending()
  staging: rtl8188eu: cleanup long lines in stop_sta_xmit()
  staging: rtl8188eu: remove whitespace in qos_acm()

 drivers/staging/rtl8188eu/core/rtw_xmit.c | 148 --
 1 file changed, 79 insertions(+), 69 deletions(-)

-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/8] staging: rtl8188eu: cleanup missing spaces around operators

2018-10-11 Thread Michael Straube 
Clear all missing spaces around operators checkpatch issues
in the file core/rtw_xmit.c. Use '+=' or '-=' where possible.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_xmit.c | 60 ++-
 1 file changed, 36 insertions(+), 24 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c 
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index fc06a13a6ea1..8336a7252440 100644
--- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
+++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
@@ -494,7 +494,8 @@ static s32 update_attrib(struct adapter *padapter, struct 
sk_buff *pkt, struct p
pattrib->subtype = WIFI_DATA_TYPE;
pattrib->priority = 0;
 
-   if (check_fwstate(pmlmepriv, 
WIFI_AP_STATE|WIFI_ADHOC_STATE|WIFI_ADHOC_MASTER_STATE)) {
+   if (check_fwstate(pmlmepriv, WIFI_AP_STATE |
+ WIFI_ADHOC_STATE | WIFI_ADHOC_MASTER_STATE)) {
if (psta->qos_option)
set_qos(pkt, pattrib);
} else {
@@ -628,15 +629,15 @@ static s32 xmitframe_addmic(struct adapter *padapter, 
struct xmit_frame *pxmitfr
rtw_secmicsetkey(, 
>dot11tkiptxmickey.skey[0]);
}
 
-   if (pframe[1]&1) {   /* ToDS == 1 */
+   if (pframe[1] & 1) {   /* ToDS == 1 */
rtw_secmicappend(, [16], 6);  /* 
DA */
-   if (pframe[1]&2)  /* From Ds == 1 */
+   if (pframe[1] & 2)  /* From Ds == 1 */
rtw_secmicappend(, [24], 
6);
else
rtw_secmicappend(, [10], 6);
} else {/* ToDS == 0 */
rtw_secmicappend(, [4], 6);   /* 
DA */
-   if (pframe[1]&2)  /* From Ds == 1 */
+   if (pframe[1] & 2)  /* From Ds == 1 */
rtw_secmicappend(, [16], 
6);
else
rtw_secmicappend(, [10], 
6);
@@ -653,23 +654,31 @@ static s32 xmitframe_addmic(struct adapter *padapter, 
struct xmit_frame *pxmitfr
payload = (u8 *)round_up((size_t)(payload), 4);
RT_TRACE(_module_rtl871x_xmit_c_, _drv_err_,
 ("=== curfragnum=%d, pframe = 0x%.2x, 
0x%.2x, 0x%.2x, 0x%.2x, 0x%.2x, 0x%.2x, 0x%.2x, 0x%.2x,!!!\n",
-curfragnum, *payload, *(payload+1),
-*(payload+2), *(payload+3),
-*(payload+4), *(payload+5),
-*(payload+6), *(payload+7)));
+curfragnum, *payload, *(payload + 1),
+*(payload + 2), *(payload + 3),
+*(payload + 4), *(payload + 5),
+*(payload + 6), *(payload + 7)));
 
-   payload = 
payload+pattrib->hdrlen+pattrib->iv_len;
+   payload += pattrib->hdrlen + pattrib->iv_len;
RT_TRACE(_module_rtl871x_xmit_c_, _drv_err_,
 ("curfragnum=%d pattrib->hdrlen=%d 
pattrib->iv_len=%d",
 curfragnum, pattrib->hdrlen, 
pattrib->iv_len));
-   if ((curfragnum+1) == pattrib->nr_frags) {
-   length = 
pattrib->last_txcmdsz-pattrib->hdrlen-pattrib->iv_len-((pattrib->bswenc) ? 
pattrib->icv_len : 0);
+   if (curfragnum + 1 == pattrib->nr_frags) {
+   length = pattrib->last_txcmdsz -
+pattrib->hdrlen -
+pattrib->iv_len -
+((pattrib->bswenc) ?
+ pattrib->icv_len : 0);
rtw_secmicappend(, payload, 
length);
-   payload = payload+length;
+   payload += length;
} else {
-   length = 
pxmitpriv->frag_len-pattrib->hdrlen-pattrib->iv_len-((pattrib->bswenc) ? 
pattrib->icv_len : 0);
+   length = pxmitpriv->frag_len -
+pattrib->hdrlen -
+pattrib->iv_len -
+((pattrib->bswenc) ?
+ pattrib->icv_len : 0);

[PATCH 2/8] staging: rtl8188eu: use __func__ in qos_acm()

2018-10-11 Thread Michael Straube 
Use __func__ instead of hardcoded name in qos_acm().
Reported by checkpatch.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/core/rtw_xmit.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c 
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index 8336a7252440..07b6e680377f 100644
--- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
+++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
@@ -368,7 +368,8 @@ u8  qos_acm(u8 acm_mask, u8 priority)
change_priority = 5;
break;
default:
-   DBG_88E("qos_acm(): invalid pattrib->priority: %d!!!\n", 
priority);
+   DBG_88E("%s(): invalid pattrib->priority: %d!!!\n",
+   __func__, priority);
break;
}
 
-- 
2.19.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: comedi: tio: fix multiple missing break in switch bugs

2018-10-11 Thread Gustavo A. R. Silva 
Currently, there are multiple missing break statements in two switch code
blocks. This makes the execution path to fall all the way down through
to the default cases, which makes the function ni_tio_set_gate_src() to
always return -EINVAL.

Fix this by adding the missing break statements.

Also, notice that due to the absence of the break statements,
the following pieces of code are unreachable:

1078if (ret)
1079return ret;
1080/* 3.  reenable & set mode to starts things back up */
1081ni_tio_set_gate_mode(counter, src);

1098if (ret)
1099return ret;
1100/* 3.  reenable & set mode to starts things back up */
1101ni_tio_set_gate2_mode(counter, src);

So, by adding the missing breaks, this patch also fixes the problem
above.

Addresses-Coverity-ID: 1474165 ("Missing break in switch")
Addresses-Coverity-ID: 1474162 ("Structurally dead code")
Fixes: 347e244884c3 ("staging: comedi: tio: implement global tio/ctr routing")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/staging/comedi/drivers/ni_tio.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/staging/comedi/drivers/ni_tio.c 
b/drivers/staging/comedi/drivers/ni_tio.c
index 838614e..0eb388c 100644
--- a/drivers/staging/comedi/drivers/ni_tio.c
+++ b/drivers/staging/comedi/drivers/ni_tio.c
@@ -1070,8 +1070,10 @@ int ni_tio_set_gate_src(struct ni_gpct *counter,
case ni_gpct_variant_e_series:
case ni_gpct_variant_m_series:
ret = ni_m_set_gate(counter, chan);
+   break;
case ni_gpct_variant_660x:
ret = ni_660x_set_gate(counter, chan);
+   break;
default:
return -EINVAL;
}
@@ -1090,8 +1092,10 @@ int ni_tio_set_gate_src(struct ni_gpct *counter,
switch (counter_dev->variant) {
case ni_gpct_variant_m_series:
ret = ni_m_set_gate2(counter, chan);
+   break;
case ni_gpct_variant_660x:
ret = ni_660x_set_gate2(counter, chan);
+   break;
default:
return -EINVAL;
}
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Direct io failed with ion

2018-10-11 Thread Laura Abbott 

On 10/11/2018 03:44 AM, Rock Lee wrote:

On Thu, Oct 11, 2018 at 4:12 PM Dan Carpenter  wrote:


On Thu, Oct 11, 2018 at 11:24:49AM +0800, Rock Lee wrote:

Hi
 I tested direct io with a ion allocated buffer, got a -EFAULT
error. It turned out that ion_mmap() set VM_IO & VM_PFNMAP, but
check_vma_flags() (do_direct_IO() calls it) doesn't allow that VMA has
these flags set. Could you give me any hit that could solve this
issue?



You must be using an old kernel because ion_mmap() was changed in April.


Yes, I am using linux-4.4 which is a little old. Even in linux-4.18,
ion_mmap() still callls remap_pfn_range() if the heap is
carvout/system/cma/chunk. But remap_pfn_range() set VM_IO & IO_PFNMAP
as well.



Yes, I don't think there's a way around this without moving away
from remap_pfn_range. I thought there was a reason why we
needed to use remap_pfn_range but it's escaping me. If you wanted
to do the work to move away from remap_pfn_range, that would
be appreciated.

Thanks,
Laura


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 03/21] media: davinci_vpfe: fix vpfe_ipipe_init() error handling

2018-10-11 Thread Joel Fernandes 
On Mon, Oct 08, 2018 at 09:46:01PM -0700, Joel Fernandes wrote:
> On Fri, Apr 06, 2018 at 10:23:04AM -0400, Mauro Carvalho Chehab wrote:
> > As warned:
> > drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1834 vpfe_ipipe_init() 
> > error: we previously assumed 'res' could be null (see line 1797)
> > 
> > There's something wrong at vpfe_ipipe_init():
> > 
> > 1) it caches the resourse_size() from from the first region
> >and reuses to the second region;
> > 
> > 2) the "res" var is overriden 3 times;
> > 
> > 3) at free logic, it assumes that "res->start" is not
> >overriden by platform_get_resource(pdev, IORESOURCE_MEM, 6),
> >but that's not true, as it can even be NULL there.
> > 
> > This patch fixes the above issues by:
> > 
> > a) store the resources used by release_mem_region() on
> >a separate var;
> > 
> > b) stop caching resource_size(), using the function where
> >needed.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> 
> I ran coccicheck on a 4.14.74 stable kernel and noticed that 'res' can be
> NULL in vpfe_ipipe_init. It looks like this patch is not included in the 4.14
> stable series. Can this patch be applied? I applied it myself and it applies
> cleanly, but I have no way to test it.
> 
> That 'res->start' error_release could end up a NULL pointer deref.

Should this patch goto 4.14 stable? Seems straightforward and worth it to
prevent the possible NULL pointer deref issue.

 - Joel

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: mt7621-mmc: Use BIT macro instead of explicit shifting in dbg.h

2018-10-11 Thread Nishad Kamdar 
Replace explicit shifting with BIT macro in dbg.h.
Issue found by checkpatch.

Signed-off-by: Nishad Kamdar 
---
 drivers/staging/mt7621-mmc/dbg.h | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/mt7621-mmc/dbg.h b/drivers/staging/mt7621-mmc/dbg.h
index 89acf590ed11..b0502d15b0c9 100644
--- a/drivers/staging/mt7621-mmc/dbg.h
+++ b/drivers/staging/mt7621-mmc/dbg.h
@@ -74,17 +74,17 @@ enum msdc_dbg {
 };
 
 /* Debug message event */
-#define DBG_EVT_NONE(0)   /* No event */
-#define DBG_EVT_DMA (1 << 0)  /* DMA related event */
-#define DBG_EVT_CMD (1 << 1)  /* MSDC CMD related event */
-#define DBG_EVT_RSP (1 << 2)  /* MSDC CMD RSP related event */
-#define DBG_EVT_INT (1 << 3)  /* MSDC INT event */
-#define DBG_EVT_CFG (1 << 4)  /* MSDC CFG event */
-#define DBG_EVT_FUC (1 << 5)  /* Function event */
-#define DBG_EVT_OPS (1 << 6)  /* Read/Write operation event */
-#define DBG_EVT_FIO (1 << 7)  /* FIFO operation event */
-#define DBG_EVT_WRN (1 << 8)  /* Warning event */
-#define DBG_EVT_PWR (1 << 9)  /* Power event */
+#define DBG_EVT_NONE(0) /* No event */
+#define DBG_EVT_DMA BIT(0)  /* DMA related event */
+#define DBG_EVT_CMD BIT(1)  /* MSDC CMD related event */
+#define DBG_EVT_RSP BIT(2)  /* MSDC CMD RSP related event */
+#define DBG_EVT_INT BIT(3)  /* MSDC INT event */
+#define DBG_EVT_CFG BIT(4)  /* MSDC CFG event */
+#define DBG_EVT_FUC BIT(5)  /* Function event */
+#define DBG_EVT_OPS BIT(6)  /* Read/Write operation event */
+#define DBG_EVT_FIO BIT(7)  /* FIFO operation event */
+#define DBG_EVT_WRN BIT(8)  /* Warning event */
+#define DBG_EVT_PWR BIT(9)  /* Power event */
 #define DBG_EVT_ALL (0x)
 
 #define DBG_EVT_MASK(DBG_EVT_ALL)
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: mt7621-mmc: Fix lines over 80 characters in dbg.h

2018-10-11 Thread Nishad Kamdar 
This patch fixes lines over 80 characters in dbg.h.
Issue found by checkpatch.

Signed-off-by: Nishad Kamdar 
---
 drivers/staging/mt7621-mmc/dbg.h | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/mt7621-mmc/dbg.h b/drivers/staging/mt7621-mmc/dbg.h
index 89acf590ed11..0822de5b8f42 100644
--- a/drivers/staging/mt7621-mmc/dbg.h
+++ b/drivers/staging/mt7621-mmc/dbg.h
@@ -5,7 +5,8 @@
  * is confidential and proprietary to MediaTek Inc. and/or its licensors.
  * Without the prior written permission of MediaTek inc. and/or its licensors,
  * any reproduction, modification, use or disclosure of MediaTek Software,
- * and information contained herein, in whole or in part, shall be strictly 
prohibited.
+ * and information contained herein, in whole or in part, shall be strictly
+ * prohibited.
  *
  * MediaTek Inc. (C) 2010. All rights reserved.
  *
@@ -18,19 +19,20 @@
  * NEITHER DOES MEDIATEK PROVIDE ANY WARRANTY WHATSOEVER WITH RESPECT TO THE
  * SOFTWARE OF ANY THIRD PARTY WHICH MAY BE USED BY, INCORPORATED IN, OR
  * SUPPLIED WITH THE MEDIATEK SOFTWARE, AND RECEIVER AGREES TO LOOK ONLY TO 
SUCH
- * THIRD PARTY FOR ANY WARRANTY CLAIM RELATING THERETO. RECEIVER EXPRESSLY 
ACKNOWLEDGES
- * THAT IT IS RECEIVER'S SOLE RESPONSIBILITY TO OBTAIN FROM ANY THIRD PARTY 
ALL PROPER LICENSES
- * CONTAINED IN MEDIATEK SOFTWARE. MEDIATEK SHALL ALSO NOT BE RESPONSIBLE FOR 
ANY MEDIATEK
- * SOFTWARE RELEASES MADE TO RECEIVER'S SPECIFICATION OR TO CONFORM TO A 
PARTICULAR
- * STANDARD OR OPEN FORUM. RECEIVER'S SOLE AND EXCLUSIVE REMEDY AND MEDIATEK'S 
ENTIRE AND
- * CUMULATIVE LIABILITY WITH RESPECT TO THE MEDIATEK SOFTWARE RELEASED 
HEREUNDER WILL BE,
- * AT MEDIATEK'S OPTION, TO REVISE OR REPLACE THE MEDIATEK SOFTWARE AT ISSUE,
- * OR REFUND ANY SOFTWARE LICENSE FEES OR SERVICE CHARGE PAID BY RECEIVER TO
- * MEDIATEK FOR SUCH MEDIATEK SOFTWARE AT ISSUE.
+ * THIRD PARTY FOR ANY WARRANTY CLAIM RELATING THERETO. RECEIVER EXPRESSLY
+ * ACKNOWLEDGES THAT IT IS RECEIVER'S SOLE RESPONSIBILITY TO OBTAIN FROM ANY
+ * THIRD PARTY ALL PROPER LICENSES CONTAINED IN MEDIATEK SOFTWARE. MEDIATEK
+ * SHALL ALSO NOT BE RESPONSIBLE FOR ANY MEDIATEK SOFTWARE RELEASES MADE TO
+ * RECEIVER'S SPECIFICATION OR TO CONFORM TO A PARTICULAR STANDARD OR OPEN
+ * FORUM. RECEIVER'S SOLE AND EXCLUSIVE REMEDY AND MEDIATEK'S ENTIRE AND
+ * CUMULATIVE LIABILITY WITH RESPECT TO THE MEDIATEK SOFTWARE RELEASED
+ * HEREUNDER WILL BE, AT MEDIATEK'S OPTION, TO REVISE OR REPLACE THE MEDIATEK
+ * SOFTWARE AT ISSUE, OR REFUND ANY SOFTWARE LICENSE FEES OR SERVICE CHARGE
+ * PAID BY RECEIVER TO MEDIATEK FOR SUCH MEDIATEK SOFTWARE AT ISSUE.
  *
- * The following software/firmware and/or related documentation ("MediaTek 
Software")
- * have been modified by MediaTek Inc. All revisions are subject to any 
receiver's
- * applicable license agreements with MediaTek Inc.
+ * The following software/firmware and/or related documentation
+ * ("MediaTek Software") have been modified by MediaTek Inc. All revisions are
+ * subject to any receiver's applicable license agreements with MediaTek Inc.
  */
 #ifndef __MT_MSDC_DEUBG__
 #define __MT_MSDC_DEUBG__
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: mt7621-mmc: Fix lines over 80 characters in dbg.c

2018-10-11 Thread Nishad Kamdar 
This patch fixes lines over 80 characters in dbg.c.
Issue found by checkpatch.

Signed-off-by: Nishad Kamdar 
---
 drivers/staging/mt7621-mmc/dbg.c | 79 +++-
 1 file changed, 47 insertions(+), 32 deletions(-)

diff --git a/drivers/staging/mt7621-mmc/dbg.c b/drivers/staging/mt7621-mmc/dbg.c
index 2bafb3bd026e..829d3d0e895e 100644
--- a/drivers/staging/mt7621-mmc/dbg.c
+++ b/drivers/staging/mt7621-mmc/dbg.c
@@ -5,7 +5,8 @@
  * is confidential and proprietary to MediaTek Inc. and/or its licensors.
  * Without the prior written permission of MediaTek inc. and/or its licensors,
  * any reproduction, modification, use or disclosure of MediaTek Software,
- * and information contained herein, in whole or in part, shall be strictly 
prohibited.
+ * and information contained herein, in whole or in part, shall be strictly
+ * prohibited.
  *
  * MediaTek Inc. (C) 2010. All rights reserved.
  *
@@ -17,20 +18,22 @@
  * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT.
  * NEITHER DOES MEDIATEK PROVIDE ANY WARRANTY WHATSOEVER WITH RESPECT TO THE
  * SOFTWARE OF ANY THIRD PARTY WHICH MAY BE USED BY, INCORPORATED IN, OR
- * SUPPLIED WITH THE MEDIATEK SOFTWARE, AND RECEIVER AGREES TO LOOK ONLY TO 
SUCH
- * THIRD PARTY FOR ANY WARRANTY CLAIM RELATING THERETO. RECEIVER EXPRESSLY 
ACKNOWLEDGES
- * THAT IT IS RECEIVER'S SOLE RESPONSIBILITY TO OBTAIN FROM ANY THIRD PARTY 
ALL PROPER LICENSES
- * CONTAINED IN MEDIATEK SOFTWARE. MEDIATEK SHALL ALSO NOT BE RESPONSIBLE FOR 
ANY MEDIATEK
- * SOFTWARE RELEASES MADE TO RECEIVER'S SPECIFICATION OR TO CONFORM TO A 
PARTICULAR
- * STANDARD OR OPEN FORUM. RECEIVER'S SOLE AND EXCLUSIVE REMEDY AND MEDIATEK'S 
ENTIRE AND
- * CUMULATIVE LIABILITY WITH RESPECT TO THE MEDIATEK SOFTWARE RELEASED 
HEREUNDER WILL BE,
- * AT MEDIATEK'S OPTION, TO REVISE OR REPLACE THE MEDIATEK SOFTWARE AT ISSUE,
- * OR REFUND ANY SOFTWARE LICENSE FEES OR SERVICE CHARGE PAID BY RECEIVER TO
- * MEDIATEK FOR SUCH MEDIATEK SOFTWARE AT ISSUE.
+ * SUPPLIED WITH THE MEDIATEK SOFTWARE, AND RECEIVER AGREES TO LOOK ONLY TO
+ * SUCH THIRD PARTY FOR ANY WARRANTY CLAIM RELATING THERETO. RECEIVER EXPRESSLY
+ * ACKNOWLEDGES THAT IT IS RECEIVER'S SOLE RESPONSIBILITY TO OBTAIN FROM ANY
+ * THIRD PARTY ALL PROPER LICENSES CONTAINED IN MEDIATEK SOFTWARE. MEDIATEK
+ * SHALL ALSO NOT BE RESPONSIBLE FOR ANY MEDIATEK SOFTWARE RELEASES MADE TO
+ * RECEIVER'S SPECIFICATION OR TO CONFORM TO A PARTICULAR STANDARD OR OPEN
+ * FORUM. RECEIVER'S SOLE AND EXCLUSIVE REMEDY AND MEDIATEK'S ENTIRE AND
+ * CUMULATIVE LIABILITY WITH RESPECT TO THE MEDIATEK SOFTWARE RELEASED
+ * HEREUNDER WILL BE, AT MEDIATEK'S OPTION, TO REVISE OR REPLACE THE MEDIATEK
+ * SOFTWARE AT ISSUE, OR REFUND ANY SOFTWARE LICENSE FEES OR SERVICE CHARGE
+ * PAID BY RECEIVER TO MEDIATEK FOR SUCH MEDIATEK SOFTWARE AT ISSUE.
  *
- * The following software/firmware and/or related documentation ("MediaTek 
Software")
- * have been modified by MediaTek Inc. All revisions are subject to any 
receiver's
- * applicable license agreements with MediaTek Inc.
+ * The following software/firmware and/or related documentation
+ * ("MediaTek Software") have been modified by MediaTek Inc. All revisions
+ * are subject to any receiver's applicable license agreements with MediaTek
+ * Inc.
  */
 
 #include 
@@ -74,7 +77,8 @@ u32 msdc_time_calc(u32 old_L32, u32 old_H32, u32 new_L32, u32 
new_H32)
ret = new_L32 - old_L32;
} else if (new_H32 == (old_H32 + 1)) {
if (new_L32 > old_L32)
-   pr_debug("msdc old_L<0x%x> new_L<0x%x>\n", old_L32, 
new_L32);
+   pr_debug("msdc old_L<0x%x> new_L<0x%x>\n",
+old_L32, new_L32);
ret = (0x - old_L32);
ret += new_L32;
} else {
@@ -96,27 +100,33 @@ void msdc_sdio_profile(struct sdio_profile *result)
 
/* CMD52 Dump */
cmd = >cmd52_rx;
-   pr_debug("sdio === CMD52 Rx <%d>times tick<%d> Max<%d> Min<%d> 
Aver<%d>\n", cmd->count, cmd->tot_tc,
-cmd->max_tc, cmd->min_tc, cmd->tot_tc / cmd->count);
+   pr_debug("sdio === CMD52 Rx <%d>times tick<%d> Max<%d> Min<%d> 
Aver<%d>\n",
+cmd->count, cmd->tot_tc, cmd->max_tc, cmd->min_tc,
+cmd->tot_tc / cmd->count);
cmd = >cmd52_tx;
-   pr_debug("sdio === CMD52 Tx <%d>times tick<%d> Max<%d> Min<%d> 
Aver<%d>\n", cmd->count, cmd->tot_tc,
-cmd->max_tc, cmd->min_tc, cmd->tot_tc / cmd->count);
+   pr_debug("sdio === CMD52 Tx <%d>times tick<%d> Max<%d> Min<%d> 
Aver<%d>\n",
+cmd->count, cmd->tot_tc, cmd->max_tc, cmd->min_tc,
+cmd->tot_tc / cmd->count);
 
/* CMD53 Rx bytes + block mode */
for (i = 0; i < 512; i++) {
cmd = >cmd53_rx_byte[i];
if (cmd->count) {
-   
pr_debug("sdio<%6d><%3dB>_Rx_<%9d><%9d><%6d><%6d>_<%9dB><%2dM>\n",

[PATCH 3.18 036/120] staging: android: ashmem: Fix mmap size validation

2018-10-11 Thread Greg Kroah-Hartman 
3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Alistair Strachan 

[ Upstream commit 8632c614565d0c5fdde527889601c018e97b6384 ]

The ashmem driver did not check that the size/offset of the vma passed
to its .mmap() function was not larger than the ashmem object being
mapped. This could cause mmap() to succeed, even though accessing parts
of the mapping would later fail with a segmentation fault.

Ensure an error is returned by the ashmem_mmap() function if the vma
size is larger than the ashmem object size. This enables safer handling
of the problem in userspace.

Cc: Todd Kjos 
Cc: de...@driverdev.osuosl.org
Cc: linux-ker...@vger.kernel.org
Cc: kernel-t...@android.com
Cc: Joel Fernandes 
Signed-off-by: Alistair Strachan 
Acked-by: Joel Fernandes (Google) 
Reviewed-by: Martijn Coenen 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/staging/android/ashmem.c |6 ++
 1 file changed, 6 insertions(+)

--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -370,6 +370,12 @@ static int ashmem_mmap(struct file *file
goto out;
}
 
+   /* requested mapping size larger than object size */
+   if (vma->vm_end - vma->vm_start > PAGE_ALIGN(asma->size)) {
+   ret = -EINVAL;
+   goto out;
+   }
+
/* requested protection bits must match our allowed protection mask */
if (unlikely((vma->vm_flags & ~calc_vm_prot_bits(asma->prot_mask)) &
 calc_vm_prot_bits(PROT_MASK))) {


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: iio: adc: ad7280a: fix 2 checks

2018-10-11 Thread Slawomir Stepien 
On paź 11, 2018 10:32, Dan Carpenter wrote:
> On Sat, Oct 06, 2018 at 10:25:42PM +0200, Slawomir Stepien wrote:
> > On paź 06, 2018 13:27, Gabriel Capella wrote:
> > > This patch does not change the logic, it only
> > > corrects the checkpatch checks.
> > > 
> > > The patch fixes 2 checks of type:
> > > "CHECK: spaces preferred around that '-'"
> > 
> > I've made the same mistake few days ago. This change is incorrect.
> > Please see: https://lore.kernel.org/patchwork/patch/635994/.
> >
> 
> You could add a comment.  /* do not put spaces around the hyphen.  
> #checkpatch.pl */
> 
> These are the only places which use this style and a lot of people
> bump into it.

Gabriel go ahead if you want to. If not then I would be happy to prepare this
patch.

-- 
Slawomir Stepien
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: erofs: harden inode lookup for 32-bit platforms

2018-10-11 Thread Gao Xiang 
Hi Dan,

On 2018/10/11 19:12, Dan Carpenter wrote:
> On Thu, Oct 11, 2018 at 06:49:57PM +0800, Gao Xiang wrote:
>> Hi Dan,
>>
>> On 2018/10/11 18:18, Dan Carpenter wrote:
>>> On Thu, Oct 11, 2018 at 05:46:26PM +0800, Gao Xiang wrote:


 On 2018/10/11 16:44, Dan Carpenter wrote:
> On Tue, Oct 09, 2018 at 10:07:13PM +0800, Gao Xiang wrote:
>> This patch introduces inode hash function, test and set callbacks,
>> and iget5_locked to find the right inode for 32-bit platforms.
>>
>
> The way I read this changelog, we're trying to deal with corrupt file
> systems?  Is that correct?  Presumably in the current code it could lead
> to a Oops or something?

 No, this commit isn't trying to deal with corrupt file systems.
 In EROFS, the nid is not continuous and it represents the inode offset
 inode offset = nid * 32.
 Therefore the nid is 64-bit both for 32-bit and 64-bit platforms. However,
 i_ino is 'unsigned long', which means for 32-bit platforms, i_ino is not 
 enough
 to contain the nid.

 Therefore, we should use iget5_locked for this case.
>>>
>>> I guess what I'm saying is, what are the user visible effects of this
>>> patch?  It's hard for me to tell from the patch description.  Could you
>>> please re-write the description and send a v2?
>>
>> Sorry for my just hurry reply. It seems I really misunderstood your point :-(
>>
>> If all nids are less than 32-bit, the user will see the correct inode/nid 
>> number
>> for all 32-bit platforms, but if some nids are greater than 32-bit, it could 
>> be
>> collisions without this patch for 32-bit platforms.
>>
>> This patch switch the inode number by XOR the high 32-bit and the low 32-bit,
>> use customized tester to avoid collisions for 32-bit platforms.
>>
>> I will send v2 to fix the commit message...but it seems Greg is already 
>> merged in
>> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing=2abd7814138774eb56319e9dcc0abd08ece45424
>>
> 
> Oh.  Then that's fine then.  If Greg already merged it, then it's too
> late to change.  Thanks for the explanation, though.

I appended the v2 patch in the end of this reply for reference...

Thanks,
Gao Xiang

> 
> regards,
> dan carpenter
> 


>From 175eb3f1c6e1cddf8292853ab0fb7644320c3ae2 Mon Sep 17 00:00:00 2001
From: Gao Xiang 
Date: Mon, 1 Oct 2018 12:32:55 +0800
Subject: [PATCH v2] staging: erofs: harden inode lookup for 32-bit platforms

Each erofs inode has a unique 64-bit nid to distinguish from others.
However, the inode number is usually defined as `unsigned long',
which means some collisions could happen if we directly use iget_locked
for 32-bit platforms.

Therefore, this patch introduces a inode hash function, test and set
callbacks, and iget5_locked to avoid potential collisions
for 32-bit platforms.

In addition, if the value of a nid is greater than 32-bit, users from
32-bit platforms will see XOR-ed inode numbers after this patch.

Reviewed-by: Chao Yu 
Signed-off-by: Gao Xiang 
---

change log v2:
 - add more infos to the commit message as pointed out by Dan Carpenter.

Thanks,
Gao Xiang

 drivers/staging/erofs/inode.c| 37 -
 drivers/staging/erofs/internal.h |  9 +
 2 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/erofs/inode.c b/drivers/staging/erofs/inode.c
index da8693a7c3d3..04c61a9d7b76 100644
--- a/drivers/staging/erofs/inode.c
+++ b/drivers/staging/erofs/inode.c
@@ -232,10 +232,45 @@ static int fill_inode(struct inode *inode, int isdir)
return err;
 }
 
+/*
+ * erofs nid is 64bits, but i_ino is 'unsigned long', therefore
+ * we should do more for 32-bit platform to find the right inode.
+ */
+#if BITS_PER_LONG == 32
+static int erofs_ilookup_test_actor(struct inode *inode, void *opaque)
+{
+   const erofs_nid_t nid = *(erofs_nid_t *)opaque;
+
+   return EROFS_V(inode)->nid == nid;
+}
+
+static int erofs_iget_set_actor(struct inode *inode, void *opaque)
+{
+   const erofs_nid_t nid = *(erofs_nid_t *)opaque;
+
+   inode->i_ino = erofs_inode_hash(nid);
+   return 0;
+}
+#endif
+
+static inline struct inode *erofs_iget_locked(struct super_block *sb,
+ erofs_nid_t nid)
+{
+   const unsigned long hashval = erofs_inode_hash(nid);
+
+#if BITS_PER_LONG >= 64
+   /* it is safe to use iget_locked for >= 64-bit platform */
+   return iget_locked(sb, hashval);
+#else
+   return iget5_locked(sb, hashval, erofs_ilookup_test_actor,
+   erofs_iget_set_actor, );
+#endif
+}
+
 struct inode *erofs_iget(struct super_block *sb,
erofs_nid_t nid, bool isdir)
 {
-   struct inode *inode = iget_locked(sb, nid);
+   struct inode *inode = erofs_iget_locked(sb, nid);
 
if (unlikely(inode == NULL))
return ERR_PTR(-ENOMEM);
diff --git a/drivers/staging/erofs/internal.h

Re: [PATCH] staging: erofs: harden inode lookup for 32-bit platforms

2018-10-11 Thread Dan Carpenter 
On Thu, Oct 11, 2018 at 06:49:57PM +0800, Gao Xiang wrote:
> Hi Dan,
> 
> On 2018/10/11 18:18, Dan Carpenter wrote:
> > On Thu, Oct 11, 2018 at 05:46:26PM +0800, Gao Xiang wrote:
> >>
> >>
> >> On 2018/10/11 16:44, Dan Carpenter wrote:
> >>> On Tue, Oct 09, 2018 at 10:07:13PM +0800, Gao Xiang wrote:
>  This patch introduces inode hash function, test and set callbacks,
>  and iget5_locked to find the right inode for 32-bit platforms.
> 
> >>>
> >>> The way I read this changelog, we're trying to deal with corrupt file
> >>> systems?  Is that correct?  Presumably in the current code it could lead
> >>> to a Oops or something?
> >>
> >> No, this commit isn't trying to deal with corrupt file systems.
> >> In EROFS, the nid is not continuous and it represents the inode offset
> >> inode offset = nid * 32.
> >> Therefore the nid is 64-bit both for 32-bit and 64-bit platforms. However,
> >> i_ino is 'unsigned long', which means for 32-bit platforms, i_ino is not 
> >> enough
> >> to contain the nid.
> >>
> >> Therefore, we should use iget5_locked for this case.
> > 
> > I guess what I'm saying is, what are the user visible effects of this
> > patch?  It's hard for me to tell from the patch description.  Could you
> > please re-write the description and send a v2?
> 
> Sorry for my just hurry reply. It seems I really misunderstood your point :-(
> 
> If all nids are less than 32-bit, the user will see the correct inode/nid 
> number
> for all 32-bit platforms, but if some nids are greater than 32-bit, it could 
> be
> collisions without this patch for 32-bit platforms.
> 
> This patch switch the inode number by XOR the high 32-bit and the low 32-bit,
> use customized tester to avoid collisions for 32-bit platforms.
> 
> I will send v2 to fix the commit message...but it seems Greg is already 
> merged in
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing=2abd7814138774eb56319e9dcc0abd08ece45424
> 

Oh.  Then that's fine then.  If Greg already merged it, then it's too
late to change.  Thanks for the explanation, though.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: erofs: harden inode lookup for 32-bit platforms

2018-10-11 Thread Gao Xiang 
Hi Dan,

On 2018/10/11 18:18, Dan Carpenter wrote:
> On Thu, Oct 11, 2018 at 05:46:26PM +0800, Gao Xiang wrote:
>>
>>
>> On 2018/10/11 16:44, Dan Carpenter wrote:
>>> On Tue, Oct 09, 2018 at 10:07:13PM +0800, Gao Xiang wrote:
 This patch introduces inode hash function, test and set callbacks,
 and iget5_locked to find the right inode for 32-bit platforms.

>>>
>>> The way I read this changelog, we're trying to deal with corrupt file
>>> systems?  Is that correct?  Presumably in the current code it could lead
>>> to a Oops or something?
>>
>> No, this commit isn't trying to deal with corrupt file systems.
>> In EROFS, the nid is not continuous and it represents the inode offset
>> inode offset = nid * 32.
>> Therefore the nid is 64-bit both for 32-bit and 64-bit platforms. However,
>> i_ino is 'unsigned long', which means for 32-bit platforms, i_ino is not 
>> enough
>> to contain the nid.
>>
>> Therefore, we should use iget5_locked for this case.
> 
> I guess what I'm saying is, what are the user visible effects of this
> patch?  It's hard for me to tell from the patch description.  Could you
> please re-write the description and send a v2?

Sorry for my just hurry reply. It seems I really misunderstood your point :-(

If all nids are less than 32-bit, the user will see the correct inode/nid number
for all 32-bit platforms, but if some nids are greater than 32-bit, it could be
collisions without this patch for 32-bit platforms.

This patch switch the inode number by XOR the high 32-bit and the low 32-bit,
use customized tester to avoid collisions for 32-bit platforms.

I will send v2 to fix the commit message...but it seems Greg is already merged 
in
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing=2abd7814138774eb56319e9dcc0abd08ece45424

Thanks,
Gao Xiang

> 
> regards,
> dan carpenter
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Direct io failed with ion

2018-10-11 Thread Rock Lee 
On Thu, Oct 11, 2018 at 4:12 PM Dan Carpenter  wrote:
>
> On Thu, Oct 11, 2018 at 11:24:49AM +0800, Rock Lee wrote:
> > Hi
> > I tested direct io with a ion allocated buffer, got a -EFAULT
> > error. It turned out that ion_mmap() set VM_IO & VM_PFNMAP, but
> > check_vma_flags() (do_direct_IO() calls it) doesn't allow that VMA has
> > these flags set. Could you give me any hit that could solve this
> > issue?
> >
>
> You must be using an old kernel because ion_mmap() was changed in April.

Yes, I am using linux-4.4 which is a little old. Even in linux-4.18,
ion_mmap() still callls remap_pfn_range() if the heap is
carvout/system/cma/chunk. But remap_pfn_range() set VM_IO & IO_PFNMAP
as well.

-- 
Cheers,
Rock
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/15] Add support for OLPC XO 1.75 Embedded Controller

2018-10-11 Thread Lubomir Rintel 
On Wed, 2018-10-10 at 14:26 -0500, Rob Herring wrote:
> On Wed, Oct 10, 2018 at 12:23 PM Lubomir Rintel  wrote:
> > Hi.
> > 
> > This patchset adds support for the Embedded Controller on an OLPC XO
> > 1.75 machine. OLPC XO 1.75 is a MMP2 based ARM laptop. It plugs into
> > the existing OLPC platform infrastructure, currently used by the x86
> > based models.
> > 
> > The EC operates in SPI master mode, meaning the SOC is the SPI slave. It
> > uses extra handshake signal to signal readiness of SOC to accept data
> > from EC and to initiate a transaction if SOC wishes to submit data.
> > 
> > The SPI slave support for MMP2 was submitted separately:
> > https://lore.kernel.org/lkml/20181010170936.316862-1-lkund...@v3.sk/T/#t
> > 
> > THe "power: supply: olpc_battery: correct the temperature" patch was
> > already sent out separately, but I'm including it because the last
> > commit of the set depends on it.
> > 
> > Tested to work on an OLPC XO 1.75 and also tested not to break x86
> > support with an OLPC XO 1 machine. I don't have a XO 1.5, but it's
> > unlikely this breaks it when XO 1 works.
> 
> I asked this on the OLPC devel list recently, but I don't think my
> message ever got past the moderator. Could you generate a DT dump from
> /proc/device-tree of an XO 1 and send to me? I have some DT changes
> planned and need to see if they'd be okay for x86 OLPC.

The /proc/device-tree tarball: http://v3.sk/~lkundrak/olpc/xo1.tar
(Mirror: https://people.freedesktop.org/~lkundrak/olpc/xo1.tar)

My distro's dtc crashes with this (could be related to your recent dtc
fixes), the git tip needs -f to work around some funny property names.
I figure a raw data as opposed to a dts/dtb dump would be a better
idea.

Also, there's no phandles, so it's of rather limited use. If you need
those, then I can share a dump directly from ofw instead or patch the
kernel to fabricate and expose the phandle properties.

This is with the latest firmware. I guess the exact version is
somewhere within the device tree.

> 
> Rob

Cheers
Lubo

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: erofs: harden inode lookup for 32-bit platforms

2018-10-11 Thread Dan Carpenter 
On Thu, Oct 11, 2018 at 05:46:26PM +0800, Gao Xiang wrote:
> 
> 
> On 2018/10/11 16:44, Dan Carpenter wrote:
> > On Tue, Oct 09, 2018 at 10:07:13PM +0800, Gao Xiang wrote:
> >> This patch introduces inode hash function, test and set callbacks,
> >> and iget5_locked to find the right inode for 32-bit platforms.
> >>
> > 
> > The way I read this changelog, we're trying to deal with corrupt file
> > systems?  Is that correct?  Presumably in the current code it could lead
> > to a Oops or something?
> 
> No, this commit isn't trying to deal with corrupt file systems.
> In EROFS, the nid is not continuous and it represents the inode offset
> inode offset = nid * 32.
> Therefore the nid is 64-bit both for 32-bit and 64-bit platforms. However,
> i_ino is 'unsigned long', which means for 32-bit platforms, i_ino is not 
> enough
> to contain the nid.
> 
> Therefore, we should use iget5_locked for this case.

I guess what I'm saying is, what are the user visible effects of this
patch?  It's hard for me to tell from the patch description.  Could you
please re-write the description and send a v2?

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/3] staging: greybus: loopback.c: do insertion in O(n) instead of O(n lg n)

2018-10-11 Thread Rasmus Villemoes 
On 2018-10-11 01:03, Bryan O'Donoghue wrote:
> On 05/10/2018 15:28, Rasmus Villemoes wrote:
>> Signed-off-by: Rasmus Villemoes
>> ---
>> I have no idea if the performance matters (it probably doesn't). Feel
>> free to ignore this and the followup cleanup.
> 
> What's the problem you're fixing here ?

No problem, really, other than my inner Paul Hogan telling me "That's
not an insertion sort, ...".

> Is it tested ?

Compile-tested. As I said, if the performance (and inaccurate comment)
is irrelevant, just drop it.

Rasmus
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: erofs: harden inode lookup for 32-bit platforms

2018-10-11 Thread Gao Xiang 



On 2018/10/11 16:44, Dan Carpenter wrote:
> On Tue, Oct 09, 2018 at 10:07:13PM +0800, Gao Xiang wrote:
>> This patch introduces inode hash function, test and set callbacks,
>> and iget5_locked to find the right inode for 32-bit platforms.
>>
> 
> The way I read this changelog, we're trying to deal with corrupt file
> systems?  Is that correct?  Presumably in the current code it could lead
> to a Oops or something?

No, this commit isn't trying to deal with corrupt file systems.
In EROFS, the nid is not continuous and it represents the inode offset
inode offset = nid * 32.
Therefore the nid is 64-bit both for 32-bit and 64-bit platforms. However,
i_ino is 'unsigned long', which means for 32-bit platforms, i_ino is not enough
to contain the nid.

Therefore, we should use iget5_locked for this case.

> 
> regards,
> dan carpenter
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: vboxvideo: make a couple of funcs static

2018-10-11 Thread Hans de Goede 

Hi,

On 10-10-18 22:17, Craig Kewley wrote:

Fix Sparse warnings:
drivers/staging/vboxvideo/vbox_mode.c:309:6: warning:
symbol 'vbox_primary_atomic_disable' was not declared. Should it be static?

drivers/staging/vboxvideo/vbox_mode.c:452:6: warning:
symbol 'vbox_cursor_atomic_disable' was not declared. Should it be static?

Signed-off-by: Craig Kewley 


Thanks.

Reviewed-by: Hans de Goede 

Regards,

Hans




---
  drivers/staging/vboxvideo/vbox_mode.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/vboxvideo/vbox_mode.c 
b/drivers/staging/vboxvideo/vbox_mode.c
index 042e4f384df9..deed28c7a1db 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -306,8 +306,8 @@ static void vbox_primary_atomic_update(struct drm_plane 
*plane,
plane->state->src_y >> 16);
  }
  
-void vbox_primary_atomic_disable(struct drm_plane *plane,

-struct drm_plane_state *old_state)
+static void vbox_primary_atomic_disable(struct drm_plane *plane,
+   struct drm_plane_state *old_state)
  {
struct drm_crtc *crtc = old_state->crtc;
  
@@ -449,8 +449,8 @@ static void vbox_cursor_atomic_update(struct drm_plane *plane,

mutex_unlock(>hw_mutex);
  }
  
-void vbox_cursor_atomic_disable(struct drm_plane *plane,

-   struct drm_plane_state *old_state)
+static void vbox_cursor_atomic_disable(struct drm_plane *plane,
+  struct drm_plane_state *old_state)
  {
struct vbox_private *vbox =
container_of(plane->dev, struct vbox_private, ddev);


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: vboxvideo: unlock on error in vbox_cursor_atomic_update()

2018-10-11 Thread Hans de Goede 

Hi,

On 11-10-18 09:59, Dan Carpenter wrote:

We need to unlock before returning on this error path.

Fixes: 35f3288c453e ("staging: vboxvideo: Atomic phase 1: convert cursor to 
universal plane")
Signed-off-by: Dan Carpenter 


Thanks, the kbuild test robot had already notified me about this
but I did not get around to fixing it yet.

Fix looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans



diff --git a/drivers/staging/vboxvideo/vbox_mode.c 
b/drivers/staging/vboxvideo/vbox_mode.c
index 042e4f384df9..78a9c9b13ff6 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -424,6 +424,7 @@ static void vbox_cursor_atomic_update(struct drm_plane 
*plane,
/* pinning is done in prepare/cleanup framebuffer */
src = vbox_bo_kmap(bo);
if (IS_ERR(src)) {
+   mutex_unlock(>hw_mutex);
DRM_WARN("Could not kmap cursor bo, skipping update\n");
return;
}


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: erofs: harden inode lookup for 32-bit platforms

2018-10-11 Thread Dan Carpenter 
On Tue, Oct 09, 2018 at 10:07:13PM +0800, Gao Xiang wrote:
> This patch introduces inode hash function, test and set callbacks,
> and iget5_locked to find the right inode for 32-bit platforms.
> 

The way I read this changelog, we're trying to deal with corrupt file
systems?  Is that correct?  Presumably in the current code it could lead
to a Oops or something?

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-11 Thread Michal Hocko 
On Thu 11-10-18 10:07:02, Vlastimil Babka wrote:
> On 10/10/18 6:56 PM, Arun KS wrote:
> > On 2018-10-10 21:00, Vlastimil Babka wrote:
> >> On 10/5/18 10:10 AM, Arun KS wrote:
> >>> When free pages are done with higher order, time spend on
> >>> coalescing pages by buddy allocator can be reduced. With
> >>> section size of 256MB, hot add latency of a single section
> >>> shows improvement from 50-60 ms to less than 1 ms, hence
> >>> improving the hot add latency by 60%. Modify external
> >>> providers of online callback to align with the change.
> >>>
> >>> Signed-off-by: Arun KS 
> >>
> >> [...]
> >>
> >>> @@ -655,26 +655,44 @@ void __online_page_free(struct page *page)
> >>>  }
> >>>  EXPORT_SYMBOL_GPL(__online_page_free);
> >>>
> >>> -static void generic_online_page(struct page *page)
> >>> +static int generic_online_page(struct page *page, unsigned int order)
> >>>  {
> >>> - __online_page_set_limits(page);
> >>
> >> This is now not called anymore, although the xen/hv variants still do
> >> it. The function seems empty these days, maybe remove it as a followup
> >> cleanup?
> >>
> >>> - __online_page_increment_counters(page);
> >>> - __online_page_free(page);
> >>> + __free_pages_core(page, order);
> >>> + totalram_pages += (1UL << order);
> >>> +#ifdef CONFIG_HIGHMEM
> >>> + if (PageHighMem(page))
> >>> + totalhigh_pages += (1UL << order);
> >>> +#endif
> >>
> >> __online_page_increment_counters() would have used
> >> adjust_managed_page_count() which would do the changes under
> >> managed_page_count_lock. Are we safe without the lock? If yes, there
> >> should perhaps be a comment explaining why.
> > 
> > Looks unsafe without managed_page_count_lock. I think better have a 
> > similar implementation of free_boot_core() in memory_hotplug.c like we 
> > had in version 1 of patch. And use adjust_managed_page_count() instead 
> > of page_zone(page)->managed_pages += nr_pages;
> > 
> > https://lore.kernel.org/patchwork/patch/989445/
> 
> Looks like deferred_free_range() has the same problem calling
> __free_pages_core() to adjust zone->managed_pages.

deferred initialization has one thread per node AFAIR so we cannot race
on managed_pages updates. Well, unless some of the mentioned can run
that early which I dunno.

> __free_pages_bootmem() is OK because at that point the system is still
> single-threaded?
> Could be solved by moving that out of __free_pages_core().
> 
> But do we care about readers potentially seeing a store tear? If yes
> then maybe these counters should be converted to atomics...

I wanted to suggest that already but I have no idea whether the lock
instructions would cause more overhead.
-- 
Michal Hocko
SUSE Labs
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Direct io failed with ion

2018-10-11 Thread Dan Carpenter 
On Thu, Oct 11, 2018 at 11:24:49AM +0800, Rock Lee wrote:
> Hi
> I tested direct io with a ion allocated buffer, got a -EFAULT
> error. It turned out that ion_mmap() set VM_IO & VM_PFNMAP, but
> check_vma_flags() (do_direct_IO() calls it) doesn't allow that VMA has
> these flags set. Could you give me any hit that could solve this
> issue?
> 

You must be using an old kernel because ion_mmap() was changed in April.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-11 Thread Vlastimil Babka 
On 10/10/18 6:56 PM, Arun KS wrote:
> On 2018-10-10 21:00, Vlastimil Babka wrote:
>> On 10/5/18 10:10 AM, Arun KS wrote:
>>> When free pages are done with higher order, time spend on
>>> coalescing pages by buddy allocator can be reduced. With
>>> section size of 256MB, hot add latency of a single section
>>> shows improvement from 50-60 ms to less than 1 ms, hence
>>> improving the hot add latency by 60%. Modify external
>>> providers of online callback to align with the change.
>>>
>>> Signed-off-by: Arun KS 
>>
>> [...]
>>
>>> @@ -655,26 +655,44 @@ void __online_page_free(struct page *page)
>>>  }
>>>  EXPORT_SYMBOL_GPL(__online_page_free);
>>>
>>> -static void generic_online_page(struct page *page)
>>> +static int generic_online_page(struct page *page, unsigned int order)
>>>  {
>>> -   __online_page_set_limits(page);
>>
>> This is now not called anymore, although the xen/hv variants still do
>> it. The function seems empty these days, maybe remove it as a followup
>> cleanup?
>>
>>> -   __online_page_increment_counters(page);
>>> -   __online_page_free(page);
>>> +   __free_pages_core(page, order);
>>> +   totalram_pages += (1UL << order);
>>> +#ifdef CONFIG_HIGHMEM
>>> +   if (PageHighMem(page))
>>> +   totalhigh_pages += (1UL << order);
>>> +#endif
>>
>> __online_page_increment_counters() would have used
>> adjust_managed_page_count() which would do the changes under
>> managed_page_count_lock. Are we safe without the lock? If yes, there
>> should perhaps be a comment explaining why.
> 
> Looks unsafe without managed_page_count_lock. I think better have a 
> similar implementation of free_boot_core() in memory_hotplug.c like we 
> had in version 1 of patch. And use adjust_managed_page_count() instead 
> of page_zone(page)->managed_pages += nr_pages;
> 
> https://lore.kernel.org/patchwork/patch/989445/

Looks like deferred_free_range() has the same problem calling
__free_pages_core() to adjust zone->managed_pages. I expect
__free_pages_bootmem() is OK because at that point the system is still
single-threaded?
Could be solved by moving that out of __free_pages_core().

But do we care about readers potentially seeing a store tear? If yes
then maybe these counters should be converted to atomics...

> -static void generic_online_page(struct page *page)
> +static int generic_online_page(struct page *page, unsigned int order)
>   {
> - __online_page_set_limits(page);
> - __online_page_increment_counters(page);
> - __online_page_free(page);
> + unsigned long nr_pages = 1 << order;
> + struct page *p = page;
> +
> + for (loop = 0 ; loop < nr_pages ; loop++, p++) {
> + __ClearPageReserved(p);
> + set_page_count(p, 0);
> + }
> +
> + adjust_managed_page_count(page, nr_pages);
> + set_page_refcounted(page);
> + __free_pages(page, order);
> +
> + return 0;
> +}
> 
> 
> Regards,
> Arun
> 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: vboxvideo: unlock on error in vbox_cursor_atomic_update()

2018-10-11 Thread Dan Carpenter 
We need to unlock before returning on this error path.

Fixes: 35f3288c453e ("staging: vboxvideo: Atomic phase 1: convert cursor to 
universal plane")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/vboxvideo/vbox_mode.c 
b/drivers/staging/vboxvideo/vbox_mode.c
index 042e4f384df9..78a9c9b13ff6 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -424,6 +424,7 @@ static void vbox_cursor_atomic_update(struct drm_plane 
*plane,
/* pinning is done in prepare/cleanup framebuffer */
src = vbox_bo_kmap(bo);
if (IS_ERR(src)) {
+   mutex_unlock(>hw_mutex);
DRM_WARN("Could not kmap cursor bo, skipping update\n");
return;
}
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 1/2] memory_hotplug: Free pages as higher order

2018-10-11 Thread Michal Hocko 
On Thu 11-10-18 07:59:32, Arun KS wrote:
> On 2018-10-10 23:03, Michal Hocko wrote:
> > On Wed 10-10-18 22:26:41, Arun KS wrote:
> > > On 2018-10-10 21:00, Vlastimil Babka wrote:
> > > > On 10/5/18 10:10 AM, Arun KS wrote:
> > > > > When free pages are done with higher order, time spend on
> > > > > coalescing pages by buddy allocator can be reduced. With
> > > > > section size of 256MB, hot add latency of a single section
> > > > > shows improvement from 50-60 ms to less than 1 ms, hence
> > > > > improving the hot add latency by 60%. Modify external
> > > > > providers of online callback to align with the change.
> > > > >
> > > > > Signed-off-by: Arun KS 
> > > >
> > > > [...]
> > > >
> > > > > @@ -655,26 +655,44 @@ void __online_page_free(struct page *page)
> > > > >  }
> > > > >  EXPORT_SYMBOL_GPL(__online_page_free);
> > > > >
> > > > > -static void generic_online_page(struct page *page)
> > > > > +static int generic_online_page(struct page *page, unsigned int order)
> > > > >  {
> > > > > - __online_page_set_limits(page);
> > > >
> > > > This is now not called anymore, although the xen/hv variants still do
> > > > it. The function seems empty these days, maybe remove it as a followup
> > > > cleanup?
> > > >
> > > > > - __online_page_increment_counters(page);
> > > > > - __online_page_free(page);
> > > > > + __free_pages_core(page, order);
> > > > > + totalram_pages += (1UL << order);
> > > > > +#ifdef CONFIG_HIGHMEM
> > > > > + if (PageHighMem(page))
> > > > > + totalhigh_pages += (1UL << order);
> > > > > +#endif
> > > >
> > > > __online_page_increment_counters() would have used
> > > > adjust_managed_page_count() which would do the changes under
> > > > managed_page_count_lock. Are we safe without the lock? If yes, there
> > > > should perhaps be a comment explaining why.
> > > 
> > > Looks unsafe without managed_page_count_lock.
> > 
> > Why does it matter actually? We cannot online/offline memory in
> > parallel. This is not the case for the boot where we initialize memory
> > in parallel on multiple nodes. So this seems to be safe currently unless
> > I am missing something. A comment explaining that would be helpful
> > though.
> 
> Other main callers of adjust_manage_page_count(),
> 
> static inline void free_reserved_page(struct page *page)
> {
> __free_reserved_page(page);
> adjust_managed_page_count(page, 1);
> }
> 
> static inline void mark_page_reserved(struct page *page)
> {
> SetPageReserved(page);
> adjust_managed_page_count(page, -1);
> }
> 
> Won't they race with memory hotplug?
> 
> Few more,
> ./drivers/xen/balloon.c:519:adjust_managed_page_count(page, -1);
> ./drivers/virtio/virtio_balloon.c:175:  adjust_managed_page_count(page, -1);
> ./drivers/virtio/virtio_balloon.c:196:  adjust_managed_page_count(page, 1);
> ./mm/hugetlb.c:2158:adjust_managed_page_count(page, 1 <<
> h->order);

They can, and I have missed those.

-- 
Michal Hocko
SUSE Labs
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[staging:staging-testing 240/554] ERROR: "__udivdi3" [drivers/md/dm-thin-pool.ko] undefined!

2018-10-11 Thread kbuild test robot 
Hi Nick,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
staging-testing
head:   a2d6e3e60abddbd0b949841611140c614957f6d5
commit: c3873a5c741f75847ae50a3f566fea2c171c1054 [240/554] staging: gasket: fix 
gasket_free_coherent_memory metadata frees
config: i386-randconfig-i3-1049 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout c3873a5c741f75847ae50a3f566fea2c171c1054
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> ERROR: "__udivdi3" [drivers/md/dm-thin-pool.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: iio: adc: ad7280a: fix 2 checks

2018-10-11 Thread Dan Carpenter 
On Sat, Oct 06, 2018 at 10:25:42PM +0200, Slawomir Stepien wrote:
> On paź 06, 2018 13:27, Gabriel Capella wrote:
> > This patch does not change the logic, it only
> > corrects the checkpatch checks.
> > 
> > The patch fixes 2 checks of type:
> > "CHECK: spaces preferred around that '-'"
> 
> I've made the same mistake few days ago. This change is incorrect.
> Please see: https://lore.kernel.org/patchwork/patch/635994/.
>

You could add a comment.  /* do not put spaces around the hyphen.  
#checkpatch.pl */

These are the only places which use this style and a lot of people
bump into it.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel