* next-20170420 build: 0 failures 0 warnings (next-20170420)
From: Build bot for Mark Brown @ 2017-04-20 10:31 UTC (permalink / raw)
To: kernel-build-reports, linaro-kernel, linux-next
Tree/Branch: next-20170420
Git describe: next-20170420
Commit: 2fbd8a8f11 Add linux-next specific files for 20170420
Build Time: 115 min 14 sec
Passed: 10 / 10 (100.00 %)
Failed: 0 / 10 ( 0.00 %)
Errors: 0
Warnings: 0
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
-------------------------------------------------------------------------------
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm64-allnoconfig
arm64-allmodconfig
arm-multi_v5_defconfig
arm-multi_v7_defconfig
x86_64-defconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allnoconfig
arm-multi_v4t_defconfig
arm64-defconfig
^ permalink raw reply
* Re: linux-next: manual merge of the scsi-mkp tree with the char-misc tree
From: Boaz Harrosh @ 2017-04-20 13:31 UTC (permalink / raw)
To: Bart Van Assche, sfr@canb.auug.org.au, logang@deltatee.com,
greg@kroah.com, martin.petersen@oracle.com, arnd@arndb.de
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
openosd@gmail.com, linux-next@vger.kernel.org
In-Reply-To: <1491594657.2559.24.camel@sandisk.com>
On 04/07/2017 10:50 PM, Bart Van Assche wrote:
> On Fri, 2017-04-07 at 13:29 -0600, Logan Gunthorpe wrote:
>> On 07/04/17 09:49 AM, Bart Van Assche wrote:
>>> Sorry that I had not yet noticed Logan's patch series. Should my two
>>> patches that conflict with Logan's patch series be dropped and reworked
>>> after Logan's patches are upstream?
>>
>> Yeah, Greg took my patchset around a few maintainers relatively quickly.
>> This is the second conflict, so sorry about that. Looks like the easiest
>> thing would be to just base your change off of mine. It doesn't look too
>> difficult. If you can do it before my patch hits upstream, I'd
>> appreciate some testing and/or review as no one from the scsi side
>> responded and that particular patch was a bit more involved than I would
>> have liked.
>
> Boaz, had you noticed Logan's osd patch? If not, can you have a look?
>
I did look, I even sent an ACK on one of the early versions.
The merge breakage is more of a build issue because I never
had get_device fail for me in my testing so it is more
academic.
Yes they both look fine BTW
Boaz
> Thanks,
> Bart.
>
^ permalink raw reply
* Re: linux-next: build failure after merge of the rcu tree
From: Paul E. McKenney @ 2017-04-20 14:23 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Michael Ellerman, Benjamin Herrenschmidt, PowerPC
In-Reply-To: <20170420153647.1a93652b@canb.auug.org.au>
On Thu, Apr 20, 2017 at 03:36:47PM +1000, Stephen Rothwell wrote:
> Hi Paul,
>
> [Also reported by Michael elsewhere]
>
> After merging the rcu tree, today's linux-next build (powerpc
> pseries_le_defconfig) failed like this:
>
> arch/powerpc/kvm/book3s_hv_rmhandlers.S: Assembler messages:
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:587: Error: operand out of range (0x0000000000009ff8 is not between 0xffffffffffff8000 and 0x0000000000007fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:617: Error: operand out of range (0x0000000000009d88 is not between 0xffffffffffff8000 and 0x0000000000007fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:619: Error: operand out of range (0x0000000000009dc0 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:643: Error: operand out of range (0x0000000000009df8 is not between 0xffffffffffff8000 and 0x0000000000007fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:650: Error: operand out of range (0x0000000000009d8c is not between 0xffffffffffff8000 and 0x0000000000007fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1353: Error: operand out of range (0x0000000000009ff8 is not between 0xffffffffffff8000 and 0x0000000000007fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1663: Error: operand out of range (0x0000000000009db0 is not between 0xffffffffffff8000 and 0x0000000000007fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1665: Error: operand out of range (0x0000000000009dc8 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1734: Error: operand out of range (0x0000000000009db8 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1782: Error: operand out of range (0x0000000000009ff8 is not between 0xffffffffffff8000 and 0x0000000000007fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1837: Error: operand out of range (0x0000000000009de0 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1877: Error: operand out of range (0x0000000000009ff8 is not between 0xffffffffffff8000 and 0x0000000000007fff)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1918: Error: operand out of range (0x0000000000009de0 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1943: Error: operand out of range (0x000000000000a048 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
>
> Caused by commit
>
> b2bb79507ba1 ("srcu: Parallelize callback handling")
>
> I have left it broken for today.
Well, I guess I made good on my promise to break this in a more subtle
and creative way... :-/
Please let me know what you need me to do. I suppose that I could
push part of the srcu_struct into another structure and dynamically
allocate it, but that sounds a bit ugly...
Thanx, Paul
^ permalink raw reply
* RE: linux-next: manual merge of the at91 tree with the arm-soc tree
From: Nicolas.Ferre @ 2017-04-20 14:50 UTC (permalink / raw)
To: sfr, nicolas.ferre, olof, arnd, linux-arm-kernel
Cc: linux-next, alexandre.belloni, linux-kernel, peda
In-Reply-To: <20170420083817.5a44b69c@canb.auug.org.au>
> Hi Nicolas,
>
> Today's linux-next merge of the at91 tree got a conflict in:
>
> arch/arm/boot/dts/at91-tse850-3.dts
> between commit:
>
> e67cedc92812 ("ARM: dts: at91: add envelope detector mux to the Axentia TSE-850")
>
> from the arm-soc tree and commit:
>
> 29dd89418007 ("ARM: dts: at91: add envelope detector mux to the Axentia TSE-850")
>
> from the at91 tree.
>
> I fixed it up (I used the arm-soc tree version) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
Stephen,
Yes, the use of arm-soc version was the way to go. I now have updated my at91-next tree to match Alexandre's pull-request and hope it is not in conflict anymore.
Thanks for your fix.
Best regards,
^ permalink raw reply
* Re: linux-next: Tree for Apr 20 (bfq)
From: Randy Dunlap @ 2017-04-20 15:24 UTC (permalink / raw)
To: Stephen Rothwell, Linux-Next Mailing List
Cc: Linux Kernel Mailing List, axboe, Paolo Valente
In-Reply-To: <20170420164341.77790320@canb.auug.org.au>
On 04/19/17 23:43, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20170419:
>
on i386:
when CONFIG_CGROUPS is not enabled:
In file included from ../block/bfq-iosched.c:105:0:
../block/bfq-iosched.h:819:22: error: array type has incomplete element type
extern struct cftype bfq_blkcg_legacy_files[];
^
../block/bfq-iosched.h:820:22: error: array type has incomplete element type
extern struct cftype bfq_blkg_files[];
^
--
~Randy
^ permalink raw reply
* Re: linux-next: Tree for Apr 20 (bfq)
From: Jens Axboe @ 2017-04-20 15:36 UTC (permalink / raw)
To: Randy Dunlap, Stephen Rothwell, Linux-Next Mailing List
Cc: Linux Kernel Mailing List, Paolo Valente
In-Reply-To: <83a9471d-08d3-6c78-f778-0896896faafa@infradead.org>
On 04/20/2017 09:24 AM, Randy Dunlap wrote:
> On 04/19/17 23:43, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20170419:
>>
>
> on i386:
> when CONFIG_CGROUPS is not enabled:
>
> In file included from ../block/bfq-iosched.c:105:0:
> ../block/bfq-iosched.h:819:22: error: array type has incomplete element type
> extern struct cftype bfq_blkcg_legacy_files[];
> ^
> ../block/bfq-iosched.h:820:22: error: array type has incomplete element type
> extern struct cftype bfq_blkg_files[];
This should fix it:
diff --git a/block/bfq-iosched.h b/block/bfq-iosched.h
index 4ce7915e8d84..ae783c06dfd9 100644
--- a/block/bfq-iosched.h
+++ b/block/bfq-iosched.h
@@ -816,9 +816,6 @@ void bfq_put_async_queues(struct bfq_data *bfqd, struct bfq_group *bfqg);
/* ---------------- cgroups-support interface ---------------- */
-extern struct cftype bfq_blkcg_legacy_files[];
-extern struct cftype bfq_blkg_files[];
-
void bfqg_stats_update_io_add(struct bfq_group *bfqg, struct bfq_queue *bfqq,
unsigned int op);
void bfqg_stats_update_io_remove(struct bfq_group *bfqg, unsigned int op);
@@ -844,6 +841,8 @@ struct bfq_group *bfq_create_group_hierarchy(struct bfq_data *bfqd, int node);
void bfqg_put(struct bfq_group *bfqg);
#ifdef CONFIG_BFQ_GROUP_IOSCHED
+extern struct cftype bfq_blkcg_legacy_files[];
+extern struct cftype bfq_blkg_files[];
extern struct blkcg_policy blkcg_policy_bfq;
#endif
--
Jens Axboe
^ permalink raw reply related
* Re: linux-next: Tree for Apr 20 (bfq)
From: Randy Dunlap @ 2017-04-20 16:10 UTC (permalink / raw)
To: Jens Axboe, Stephen Rothwell, Linux-Next Mailing List
Cc: Linux Kernel Mailing List, Paolo Valente
In-Reply-To: <c2bd1807-8911-747e-24f5-b5b556e58b8b@kernel.dk>
On 04/20/17 08:36, Jens Axboe wrote:
> On 04/20/2017 09:24 AM, Randy Dunlap wrote:
>> On 04/19/17 23:43, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Changes since 20170419:
>>>
>>
>> on i386:
>> when CONFIG_CGROUPS is not enabled:
>>
>> In file included from ../block/bfq-iosched.c:105:0:
>> ../block/bfq-iosched.h:819:22: error: array type has incomplete element type
>> extern struct cftype bfq_blkcg_legacy_files[];
>> ^
>> ../block/bfq-iosched.h:820:22: error: array type has incomplete element type
>> extern struct cftype bfq_blkg_files[];
>
> This should fix it:
>
Yes, it does. Thanks.
Acked-by: Randy Dunlap <rdunlap@infradead.org>
--
~Randy
^ permalink raw reply
* [PATCH] staging: rtl8188eu: style fixes
From: Galo Navarro @ 2017-04-20 21:42 UTC (permalink / raw)
To: linux-next; +Cc: Greg Kroah-Hartman, Larry Finger
Signed-off-by: Galo Navarro <anglor@varoa.net>
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 186 +++++++++++++++++-------------
1 file changed, 103 insertions(+), 83 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 301085a..216fb41 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -38,7 +38,9 @@ int rtw_init_mlme_priv(struct adapter *padapter)
struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
int res = _SUCCESS;
- /* We don't need to memset padapter->XXX to zero, because adapter is allocated by vzalloc(). */
+ /* We don't need to memset padapter->XXX to zero, because adapter is
+ * allocated by vzalloc().
+ */
pmlmepriv->nic_hdl = (u8 *)padapter;
@@ -209,7 +211,6 @@ struct wlan_network *rtw_find_network(struct __queue *scanned_queue, u8 *addr)
return pnetwork;
}
-
void rtw_free_network_queue(struct adapter *padapter, u8 isfreeall)
{
struct list_head *phead, *plist;
@@ -265,7 +266,6 @@ u8 *rtw_get_capability_from_ie(u8 *ie)
return ie + 8 + 2;
}
-
u16 rtw_get_capability(struct wlan_bssid_ex *bss)
{
__le16 val;
@@ -353,7 +353,7 @@ struct wlan_network *rtw_get_oldest_wlan_network(struct __queue *scanned_queue)
}
void update_network(struct wlan_bssid_ex *dst, struct wlan_bssid_ex *src,
- struct adapter *padapter, bool update_ie)
+ struct adapter *padapter, bool update_ie)
{
long rssi_ori = dst->Rssi;
u8 sq_smp = src->PhyInfo.SignalQuality;
@@ -524,7 +524,9 @@ static int rtw_is_desired_network(struct adapter *adapter, struct wlan_network *
privacy = pnetwork->network.Privacy;
if (check_fwstate(pmlmepriv, WIFI_UNDER_WPS)) {
- if (rtw_get_wps_ie(pnetwork->network.IEs+_FIXED_IE_LENGTH_, pnetwork->network.IELength-_FIXED_IE_LENGTH_, NULL, &wps_ielen))
+ if (rtw_get_wps_ie(pnetwork->network.IEs + _FIXED_IE_LENGTH_,
+ pnetwork->network.IELength - _FIXED_IE_LENGTH_,
+ NULL, &wps_ielen))
return true;
else
return false;
@@ -534,7 +536,6 @@ static int rtw_is_desired_network(struct adapter *adapter, struct wlan_network *
bselected = false;
}
-
if ((desired_encmode != Ndis802_11EncryptionDisabled) && (privacy == 0)) {
DBG_88E("desired_encmode: %d, privacy: %d\n", desired_encmode, privacy);
bselected = false;
@@ -598,7 +599,6 @@ void rtw_survey_event_callback(struct adapter *adapter, u8 *pbuf)
exit:
spin_unlock_bh(&pmlmepriv->lock);
- return;
}
void rtw_surveydone_event_callback(struct adapter *adapter, u8 *pbuf)
@@ -660,7 +660,7 @@ void rtw_surveydone_event_callback(struct adapter *adapter, u8 *pbuf)
s_ret = rtw_select_and_join_from_scanned_queue(pmlmepriv);
if (s_ret == _SUCCESS) {
mod_timer(&pmlmepriv->assoc_timer,
- jiffies + msecs_to_jiffies(MAX_JOIN_TIMEOUT));
+ jiffies + msecs_to_jiffies(MAX_JOIN_TIMEOUT));
} else if (s_ret == 2) { /* there is no need to wait for join */
_clr_fwstate_(pmlmepriv, _FW_UNDER_LINKING);
rtw_indicate_connect(adapter);
@@ -770,7 +770,6 @@ void rtw_free_assoc_resources_locked(struct adapter *adapter)
rtw_init_bcmc_stainfo(adapter);
}
-
pwlan = rtw_find_network(&pmlmepriv->scanned_queue, tgt_network->network.MacAddress);
if (pwlan)
pwlan->fixed = false;
@@ -857,7 +856,8 @@ void rtw_scan_abort(struct adapter *adapter)
}
if (check_fwstate(pmlmepriv, _FW_UNDER_SURVEY)) {
if (!adapter->bDriverStopped && !adapter->bSurpriseRemoved)
- DBG_88E(FUNC_NDEV_FMT"waiting for scan_abort time out!\n", FUNC_NDEV_ARG(adapter->pnetdev));
+ DBG_88E(FUNC_NDEV_FMT"waiting for scan_abort time out!\n",
+ FUNC_NDEV_ARG(adapter->pnetdev));
rtw_indicate_scan_done(adapter, true);
}
pmlmeext->scan_abort = false;
@@ -897,7 +897,7 @@ static struct sta_info *rtw_joinbss_update_stainfo(struct adapter *padapter, str
* Commented by Albert 2012/07/21
* When doing the WPS, the wps_ie_len won't equal to 0
* And the Wi-Fi driver shouldn't allow the data
- * packet to be tramsmitted.
+ * packet to be transmitted.
*/
if (padapter->securitypriv.wps_ie_len != 0) {
psta->ieee8021x_blocked = true;
@@ -944,7 +944,6 @@ static void rtw_joinbss_update_network(struct adapter *padapter, struct wlan_net
("\nfw_state:%x, BSSID:%pM\n",
get_fwstate(pmlmepriv), pnetwork->network.MacAddress));
-
/* why not use ptarget_wlan?? */
memcpy(&cur_network->network, &pnetwork->network, pnetwork->network.Length);
/* some IEs in pnetwork is wrong, so we should use ptarget_wlan IEs */
@@ -963,8 +962,8 @@ static void rtw_joinbss_update_network(struct adapter *padapter, struct wlan_net
/* update fw_state will clr _FW_UNDER_LINKING here indirectly */
switch (pnetwork->network.InfrastructureMode) {
case Ndis802_11Infrastructure:
- if (pmlmepriv->fw_state&WIFI_UNDER_WPS)
- pmlmepriv->fw_state = WIFI_STATION_STATE|WIFI_UNDER_WPS;
+ if (pmlmepriv->fw_state & WIFI_UNDER_WPS)
+ pmlmepriv->fw_state = WIFI_STATION_STATE | WIFI_UNDER_WPS;
else
pmlmepriv->fw_state = WIFI_STATION_STATE;
break;
@@ -1136,14 +1135,14 @@ static u8 search_max_mac_id(struct adapter *padapter)
#if defined(CONFIG_88EU_AP_MODE)
if (check_fwstate(pmlmepriv, WIFI_AP_STATE)) {
for (aid = (pstapriv->max_num_sta); aid > 0; aid--) {
- if (pstapriv->sta_aid[aid-1])
+ if (pstapriv->sta_aid[aid - 1])
break;
}
mac_id = aid + 1;
} else
#endif
{/* adhoc id = 31~2 */
- for (mac_id = (NUM_STA-1); mac_id >= IBSS_START_MAC_ID; mac_id--) {
+ for (mac_id = (NUM_STA - 1); mac_id >= IBSS_START_MAC_ID; mac_id--) {
if (pmlmeinfo->FW_sta_info[mac_id].status == 1)
break;
}
@@ -1162,7 +1161,7 @@ void rtw_stassoc_hw_rpt(struct adapter *adapter, struct sta_info *psta)
macid = search_max_mac_id(adapter);
rtw_hal_set_hwreg(adapter, HW_VAR_TX_RPT_MAX_MACID, (u8 *)&macid);
- media_status = (psta->mac_id<<8)|1; /* MACID|OPMODE:1 connect */
+ media_status = (psta->mac_id << 8) | 1; /* MACID|OPMODE:1 connect */
rtw_hal_set_hwreg(adapter, HW_VAR_H2C_MEDIA_STATUS_RPT, (u8 *)&media_status);
}
@@ -1249,7 +1248,7 @@ void rtw_stadel_event_callback(struct adapter *adapter, u8 *pbuf)
if (mac_id >= 0) {
u16 media_status;
- media_status = (mac_id<<8)|0; /* MACID|OPMODE:0 means disconnect */
+ media_status = (mac_id << 8) | 0; /* MACID|OPMODE:0 means disconnect */
/* for STA, AP, ADHOC mode, report disconnect stauts to FW */
rtw_hal_set_hwreg(adapter, HW_VAR_H2C_MEDIA_STATUS_RPT, (u8 *)&media_status);
}
@@ -1329,7 +1328,7 @@ void rtw_cpwm_event_callback(struct adapter *padapter, u8 *pbuf)
}
/*
- * _rtw_join_timeout_handler - Timeout/faliure handler for CMD JoinBss
+ * _rtw_join_timeout_handler - Timeout/failure handler for CMD JoinBss
* @adapter: pointer to struct adapter structure
*/
void _rtw_join_timeout_handler (unsigned long data)
@@ -1356,11 +1355,10 @@ void _rtw_join_timeout_handler (unsigned long data)
continue;
}
break;
- } else {
- DBG_88E("%s We've try roaming but fail\n", __func__);
- rtw_indicate_disconnect(adapter);
- break;
}
+ DBG_88E("%s We've try roaming but fail\n", __func__);
+ rtw_indicate_disconnect(adapter);
+ break;
}
} else {
rtw_indicate_disconnect(adapter);
@@ -1370,7 +1368,7 @@ void _rtw_join_timeout_handler (unsigned long data)
}
/*
- * rtw_scan_timeout_handler - Timeout/Faliure handler for CMD SiteSurvey
+ * rtw_scan_timeout_handler - Timeout/Failure handler for CMD SiteSurvey
* @adapter: pointer to struct adapter structure
*/
void rtw_scan_timeout_handler (unsigned long data)
@@ -1378,7 +1376,8 @@ void rtw_scan_timeout_handler (unsigned long data)
struct adapter *adapter = (struct adapter *)data;
struct mlme_priv *pmlmepriv = &adapter->mlmepriv;
- DBG_88E(FUNC_ADPT_FMT" fw_state=%x\n", FUNC_ADPT_ARG(adapter), get_fwstate(pmlmepriv));
+ DBG_88E(FUNC_ADPT_FMT" fw_state=%x\n", FUNC_ADPT_ARG(adapter),
+ get_fwstate(pmlmepriv));
spin_lock_bh(&pmlmepriv->lock);
_clr_fwstate_(pmlmepriv, _FW_UNDER_SURVEY);
spin_unlock_bh(&pmlmepriv->lock);
@@ -1461,7 +1460,7 @@ static int rtw_check_join_candidate(struct mlme_priv *pmlmepriv
goto exit;
}
- if (*candidate == NULL || (*candidate)->network.Rssi < competitor->network.Rssi) {
+ if (!candidate || (*candidate)->network.Rssi < competitor->network.Rssi) {
*candidate = competitor;
updated = true;
}
@@ -1501,9 +1500,12 @@ int rtw_select_and_join_from_scanned_queue(struct mlme_priv *pmlmepriv)
adapter = (struct adapter *)pmlmepriv->nic_hdl;
pmlmepriv->pscanned = phead->next;
while (phead != pmlmepriv->pscanned) {
- pnetwork = container_of(pmlmepriv->pscanned, struct wlan_network, list);
- if (pnetwork == NULL) {
- RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("%s return _FAIL:(pnetwork==NULL)\n", __func__));
+ pnetwork = container_of(pmlmepriv->pscanned,
+ struct wlan_network, list);
+ if (!pnetwork) {
+ RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_,
+ ("%s return _FAIL:(pnetwork==NULL)\n",
+ __func__));
ret = _FAIL;
goto exit;
}
@@ -1516,7 +1518,8 @@ int rtw_select_and_join_from_scanned_queue(struct mlme_priv *pmlmepriv)
goto exit;
} else {
DBG_88E("%s: candidate: %s(%pM ch:%u)\n", __func__,
- candidate->network.Ssid.Ssid, candidate->network.MacAddress,
+ candidate->network.Ssid.Ssid,
+ candidate->network.MacAddress,
candidate->network.Configuration.DSConfig);
}
@@ -1582,7 +1585,8 @@ int rtw_set_auth(struct adapter *adapter, struct security_priv *psecuritypriv)
return res;
}
-int rtw_set_key(struct adapter *adapter, struct security_priv *psecuritypriv, int keyid, u8 set_tx)
+int rtw_set_key(struct adapter *adapter, struct security_priv *psecuritypriv,
+ int keyid, u8 set_tx)
{
u8 keylen;
struct cmd_obj *pcmd;
@@ -1626,20 +1630,24 @@ int rtw_set_key(struct adapter *adapter, struct security_priv *psecuritypriv, in
switch (psetkeyparm->algorithm) {
case _WEP40_:
keylen = 5;
- memcpy(&(psetkeyparm->key[0]), &(psecuritypriv->dot11DefKey[keyid].skey[0]), keylen);
+ memcpy(&(psetkeyparm->key[0]),
+ &(psecuritypriv->dot11DefKey[keyid].skey[0]), keylen);
break;
case _WEP104_:
keylen = 13;
- memcpy(&(psetkeyparm->key[0]), &(psecuritypriv->dot11DefKey[keyid].skey[0]), keylen);
+ memcpy(&(psetkeyparm->key[0]),
+ &(psecuritypriv->dot11DefKey[keyid].skey[0]), keylen);
break;
case _TKIP_:
keylen = 16;
- memcpy(&psetkeyparm->key, &psecuritypriv->dot118021XGrpKey[keyid], keylen);
+ memcpy(&psetkeyparm->key,
+ &psecuritypriv->dot118021XGrpKey[keyid], keylen);
psetkeyparm->grpkey = 1;
break;
case _AES_:
keylen = 16;
- memcpy(&psetkeyparm->key, &psecuritypriv->dot118021XGrpKey[keyid], keylen);
+ memcpy(&psetkeyparm->key,
+ &psecuritypriv->dot118021XGrpKey[keyid], keylen);
psetkeyparm->grpkey = 1;
break;
default:
@@ -1666,7 +1674,8 @@ int rtw_set_key(struct adapter *adapter, struct security_priv *psecuritypriv, in
}
/* adjust IEs for rtw_joinbss_cmd in WMM */
-int rtw_restruct_wmm_ie(struct adapter *adapter, u8 *in_ie, u8 *out_ie, uint in_len, uint initial_out_len)
+int rtw_restruct_wmm_ie(struct adapter *adapter, u8 *in_ie, u8 *out_ie,
+ uint in_len, uint initial_out_len)
{
unsigned int ielength = 0;
unsigned int i, j;
@@ -1708,13 +1717,12 @@ static int SecIsInPMKIDList(struct adapter *Adapter, u8 *bssid)
do {
if ((psecuritypriv->PMKIDList[i].bUsed) &&
- (!memcmp(psecuritypriv->PMKIDList[i].Bssid, bssid, ETH_ALEN))) {
+ (!memcmp(psecuritypriv->PMKIDList[i].Bssid,
+ bssid, ETH_ALEN))) {
break;
- } else {
- i++;
- /* continue; */
}
-
+ i++;
+ /* continue; */
} while (i < NUM_PMKID_CACHE);
if (i == NUM_PMKID_CACHE)
@@ -1731,7 +1739,8 @@ static int SecIsInPMKIDList(struct adapter *Adapter, u8 *bssid)
/* 13th element in the array is the IE length */
/* */
-static int rtw_append_pmkid(struct adapter *Adapter, int iEntry, u8 *ie, uint ie_len)
+static int rtw_append_pmkid(struct adapter *Adapter, int iEntry, u8 *ie,
+ uint ie_len)
{
struct security_priv *psecuritypriv = &Adapter->securitypriv;
@@ -1749,7 +1758,8 @@ static int rtw_append_pmkid(struct adapter *Adapter, int iEntry, u8 *ie, uint ie
return ie_len;
}
-int rtw_restruct_sec_ie(struct adapter *adapter, u8 *in_ie, u8 *out_ie, uint in_len)
+int rtw_restruct_sec_ie(struct adapter *adapter, u8 *in_ie, u8 *out_ie,
+ uint in_len)
{
u8 authmode;
uint ielength;
@@ -1769,29 +1779,30 @@ int rtw_restruct_sec_ie(struct adapter *adapter, u8 *in_ie, u8 *out_ie, uint in_
ielength = 12;
if ((ndisauthmode == Ndis802_11AuthModeWPA) ||
(ndisauthmode == Ndis802_11AuthModeWPAPSK))
- authmode = _WPA_IE_ID_;
+ authmode = _WPA_IE_ID_;
if ((ndisauthmode == Ndis802_11AuthModeWPA2) ||
(ndisauthmode == Ndis802_11AuthModeWPA2PSK))
authmode = _WPA2_IE_ID_;
if (check_fwstate(pmlmepriv, WIFI_UNDER_WPS)) {
- memcpy(out_ie+ielength, psecuritypriv->wps_ie, psecuritypriv->wps_ie_len);
+ memcpy(out_ie + ielength, psecuritypriv->wps_ie,
+ psecuritypriv->wps_ie_len);
ielength += psecuritypriv->wps_ie_len;
} else if ((authmode == _WPA_IE_ID_) || (authmode == _WPA2_IE_ID_)) {
/* copy RSN or SSN */
- memcpy(&out_ie[ielength], &psecuritypriv->supplicant_ie[0], psecuritypriv->supplicant_ie[1]+2);
- ielength += psecuritypriv->supplicant_ie[1]+2;
- rtw_report_sec_ie(adapter, authmode, psecuritypriv->supplicant_ie);
+ memcpy(&out_ie[ielength], &psecuritypriv->supplicant_ie[0],
+ psecuritypriv->supplicant_ie[1] + 2);
+ ielength += psecuritypriv->supplicant_ie[1] + 2;
+ rtw_report_sec_ie(adapter, authmode,
+ psecuritypriv->supplicant_ie);
}
iEntry = SecIsInPMKIDList(adapter, pmlmepriv->assoc_bssid);
- if (iEntry < 0) {
+ if (iEntry < 0)
return ielength;
- } else {
- if (authmode == _WPA2_IE_ID_)
- ielength = rtw_append_pmkid(adapter, iEntry, out_ie, ielength);
- }
+ if (authmode == _WPA2_IE_ID_)
+ ielength = rtw_append_pmkid(adapter, iEntry, out_ie, ielength);
return ielength;
}
@@ -1804,7 +1815,8 @@ void rtw_init_registrypriv_dev_network(struct adapter *adapter)
memcpy(pdev_network->MacAddress, myhwaddr, ETH_ALEN);
- memcpy(&pdev_network->Ssid, &pregistrypriv->ssid, sizeof(struct ndis_802_11_ssid));
+ memcpy(&pdev_network->Ssid, &pregistrypriv->ssid,
+ sizeof(struct ndis_802_11_ssid));
pdev_network->Configuration.Length = sizeof(struct ndis_802_11_config);
pdev_network->Configuration.BeaconPeriod = 100;
@@ -1898,15 +1910,18 @@ void rtw_joinbss_reset(struct adapter *padapter)
threshold = 1;
else
threshold = 0;
- rtw_hal_set_hwreg(padapter, HW_VAR_RXDMA_AGG_PG_TH, (u8 *)(&threshold));
+ rtw_hal_set_hwreg(padapter, HW_VAR_RXDMA_AGG_PG_TH,
+ (u8 *)(&threshold));
} else {
threshold = 1;
- rtw_hal_set_hwreg(padapter, HW_VAR_RXDMA_AGG_PG_TH, (u8 *)(&threshold));
+ rtw_hal_set_hwreg(padapter, HW_VAR_RXDMA_AGG_PG_TH,
+ (u8 *)(&threshold));
}
}
/* the function is >= passive_level */
-unsigned int rtw_restructure_ht_ie(struct adapter *padapter, u8 *in_ie, u8 *out_ie, uint in_len, uint *pout_len)
+unsigned int rtw_restructure_ht_ie(struct adapter *padapter, u8 *in_ie,
+ u8 *out_ie, uint in_len, uint *pout_len)
{
u32 ielen, out_len;
enum ht_cap_ampdu_factor max_rx_ampdu_factor;
@@ -1919,14 +1934,14 @@ unsigned int rtw_restructure_ht_ie(struct adapter *padapter, u8 *in_ie, u8 *out_
phtpriv->ht_option = false;
- p = rtw_get_ie(in_ie+12, _HT_CAPABILITY_IE_, &ielen, in_len-12);
+ p = rtw_get_ie(in_ie + 12, _HT_CAPABILITY_IE_, &ielen, in_len - 12);
if (p && ielen > 0) {
struct ieee80211_ht_cap ht_cap;
if (pqospriv->qos_option == 0) {
out_len = *pout_len;
- rtw_set_ie(out_ie+out_len, _VENDOR_SPECIFIC_IE_,
+ rtw_set_ie(out_ie + out_len, _VENDOR_SPECIFIC_IE_,
_WMM_IE_Length_, WMM_IE, pout_len);
pqospriv->qos_option = 1;
@@ -1942,13 +1957,15 @@ unsigned int rtw_restructure_ht_ie(struct adapter *padapter, u8 *in_ie, u8 *out_
IEEE80211_HT_CAP_TX_STBC |
IEEE80211_HT_CAP_DSSSCCK40);
- rtw_hal_get_def_var(padapter, HAL_DEF_RX_PACKET_OFFSET, &rx_packet_offset);
- rtw_hal_get_def_var(padapter, HAL_DEF_MAX_RECVBUF_SZ, &max_recvbuf_sz);
+ rtw_hal_get_def_var(padapter, HAL_DEF_RX_PACKET_OFFSET,
+ &rx_packet_offset);
+ rtw_hal_get_def_var(padapter, HAL_DEF_MAX_RECVBUF_SZ,
+ &max_recvbuf_sz);
/*
- ampdu_params_info [1:0]:Max AMPDU Len => 0:8k , 1:16k, 2:32k, 3:64k
- ampdu_params_info [4:2]:Min MPDU Start Spacing
- */
+ * ampdu_params_info [1:0]:Max AMPDU Len => 0:8k , 1:16k, 2:32k, 3:64k
+ * ampdu_params_info [4:2]:Min MPDU Start Spacing
+ */
rtw_hal_get_def_var(padapter, HW_VAR_MAX_RX_AMPDU_FACTOR, &max_rx_ampdu_factor);
ht_cap.ampdu_params_info = max_rx_ampdu_factor & 0x03;
@@ -1958,16 +1975,18 @@ unsigned int rtw_restructure_ht_ie(struct adapter *padapter, u8 *in_ie, u8 *out_
else
ht_cap.ampdu_params_info |= IEEE80211_HT_CAP_AMPDU_DENSITY & 0x00;
- rtw_set_ie(out_ie+out_len, _HT_CAPABILITY_IE_,
+ rtw_set_ie(out_ie + out_len, _HT_CAPABILITY_IE_,
sizeof(struct ieee80211_ht_cap),
(unsigned char *)&ht_cap, pout_len);
phtpriv->ht_option = true;
- p = rtw_get_ie(in_ie+12, _HT_ADD_INFO_IE_, &ielen, in_len-12);
+ p = rtw_get_ie(in_ie + 12, _HT_ADD_INFO_IE_, &ielen,
+ in_len - 12);
if (p && (ielen == sizeof(struct ieee80211_ht_addt_info))) {
out_len = *pout_len;
- rtw_set_ie(out_ie+out_len, _HT_ADD_INFO_IE_, ielen, p+2, pout_len);
+ rtw_set_ie(out_ie + out_len, _HT_ADD_INFO_IE_,
+ ielen, p + 2, pout_len);
}
}
return phtpriv->ht_option;
@@ -2033,7 +2052,8 @@ void rtw_update_ht_cap(struct adapter *padapter, u8 *pie, uint ie_len)
pmlmeinfo->HT_protection = pmlmeinfo->HT_info.infos[1] & 0x3;
}
-void rtw_issue_addbareq_cmd(struct adapter *padapter, struct xmit_frame *pxmitframe)
+void rtw_issue_addbareq_cmd(struct adapter *padapter,
+ struct xmit_frame *pxmitframe)
{
u8 issued;
int priority;
@@ -2058,8 +2078,8 @@ void rtw_issue_addbareq_cmd(struct adapter *padapter, struct xmit_frame *pxmitfr
phtpriv = &psta->htpriv;
if ((phtpriv->ht_option) && (phtpriv->ampdu_enable)) {
- issued = (phtpriv->agg_enable_bitmap>>priority)&0x1;
- issued |= (phtpriv->candidate_tid_bitmap>>priority)&0x1;
+ issued = (phtpriv->agg_enable_bitmap >> priority) & 0x1;
+ issued |= (phtpriv->candidate_tid_bitmap >> priority) & 0x1;
if (issued == 0) {
DBG_88E("rtw_issue_addbareq_cmd, p=%d\n", priority);
@@ -2092,27 +2112,27 @@ void _rtw_roaming(struct adapter *padapter, struct wlan_network *tgt_network)
if (pmlmepriv->to_roaming > 0) {
DBG_88E("roaming from %s(%pM length:%d\n",
- pnetwork->network.Ssid.Ssid, pnetwork->network.MacAddress,
+ pnetwork->network.Ssid.Ssid,
+ pnetwork->network.MacAddress,
pnetwork->network.Ssid.SsidLength);
- memcpy(&pmlmepriv->assoc_ssid, &pnetwork->network.Ssid, sizeof(struct ndis_802_11_ssid));
+ memcpy(&pmlmepriv->assoc_ssid, &pnetwork->network.Ssid,
+ sizeof(struct ndis_802_11_ssid));
pmlmepriv->assoc_by_bssid = false;
while (1) {
do_join_r = rtw_do_join(padapter);
- if (do_join_r == _SUCCESS) {
+ if (do_join_r == _SUCCESS)
break;
- } else {
- DBG_88E("roaming do_join return %d\n", do_join_r);
- pmlmepriv->to_roaming--;
+ DBG_88E("roaming do_join return %d\n", do_join_r);
+ pmlmepriv->to_roaming--;
- if (pmlmepriv->to_roaming > 0) {
- continue;
- } else {
- DBG_88E("%s(%d) -to roaming fail, indicate_disconnect\n", __func__, __LINE__);
- rtw_indicate_disconnect(padapter);
- break;
- }
+ if (pmlmepriv->to_roaming > 0) {
+ continue;
+ } else {
+ DBG_88E("%s(%d) -to roaming fail, indicate_disconnect\n", __func__, __LINE__);
+ rtw_indicate_disconnect(padapter);
+ break;
}
}
}
--
2.1.4
^ permalink raw reply related
* linux-next: build failure after merge of the arm tree
From: Stephen Rothwell @ 2017-04-20 22:40 UTC (permalink / raw)
To: Russell King; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mason
Hi Russell,
After merging the arm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from include/linux/bitops.h:36:0,
from include/linux/bitmap.h:7,
from drivers/dma/sun4i-dma.c:11:
drivers/dma/sun4i-dma.c: In function 'find_and_use_pchan':
include/linux/bitops.h:56:34: error: passing argument 1 of '_find_next_zero_bit_le' from incompatible pointer type [-Werror=incompatible-pointer-types]
for ((bit) = find_next_zero_bit((addr), (size), (bit)); \
^
arch/arm/include/asm/bitops.h:200:61: note: in definition of macro 'find_next_zero_bit'
#define find_next_zero_bit(p,sz,off) _find_next_zero_bit_le(p,sz,off)
^
drivers/dma/sun4i-dma.c:241:2: note: in expansion of macro 'for_each_clear_bit_from'
for_each_clear_bit_from(i, &priv->pchans_used, max) {
^
arch/arm/include/asm/bitops.h:163:12: note: expected 'const long unsigned int *' but argument is of type 'long unsigned int (*)[1]'
extern int _find_next_zero_bit_le(const unsigned long *p, int size, int offset);
^
include/linux/bitops.h:58:34: error: passing argument 1 of '_find_next_zero_bit_le' from incompatible pointer type [-Werror=incompatible-pointer-types]
(bit) = find_next_zero_bit((addr), (size), (bit) + 1))
^
arch/arm/include/asm/bitops.h:200:61: note: in definition of macro 'find_next_zero_bit'
#define find_next_zero_bit(p,sz,off) _find_next_zero_bit_le(p,sz,off)
^
drivers/dma/sun4i-dma.c:241:2: note: in expansion of macro 'for_each_clear_bit_from'
for_each_clear_bit_from(i, &priv->pchans_used, max) {
^
arch/arm/include/asm/bitops.h:163:12: note: expected 'const long unsigned int *' but argument is of type 'long unsigned int (*)[1]'
extern int _find_next_zero_bit_le(const unsigned long *p, int size, int offset);
^
Caused (or exposed) by commit
c4f8ff16b46b ("ARM: 8669/1: bitops: Align prototypes to generic API")
I have used the arm tree from next-20170420 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the pci tree with the kbuild tree
From: Stephen Rothwell @ 2017-04-21 0:20 UTC (permalink / raw)
To: Bjorn Helgaas, Masahiro Yamada
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Nicolas Dichtel, Kishon Vijay Abraham I
Hi all,
Today's linux-next merge of the pci tree got a conflict in:
include/uapi/linux/Kbuild
between commit:
65017bab8a9e ("uapi: export all headers under uapi directories")
from the kbuild tree and commit:
58c89c8aa0e8 ("misc: Add host side PCI driver for PCI test function device")
from the pci tree.
I fixed it up (I just dropped the latter change to this file) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the pm tree with the arm-soc tree
From: Stephen Rothwell @ 2017-04-21 0:50 UTC (permalink / raw)
To: Rafael J. Wysocki, Olof Johansson, Arnd Bergmann, ARM
Cc: Nishanth Menon, Dave Gerlach, Keerthy, Linux Kernel Mailing List,
Linux-Next Mailing List, Santosh Shilimkar
Hi Rafael,
Today's linux-next merge of the pm tree got a conflict in:
drivers/soc/ti/ti_sci_pm_domains.c
between commit:
52835d59fc6c ("soc: ti: Add ti_sci_pm_domains driver")
from the arm-soc tree and commit:
112572283742 ("soc: ti: Add ti_sci_pm_domains driver")
from the pm tree.
I fixed it up (I used the pm tree version, but it was an arbitrary
choice as the only difference is the URL in the Copyright line) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the pm tree with the arm-soc tree
From: Stephen Rothwell @ 2017-04-21 0:54 UTC (permalink / raw)
To: Rafael J. Wysocki, Olof Johansson, Arnd Bergmann, ARM
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Dave Gerlach,
Santosh Shilimkar, Nishanth Menon
Hi all,
Today's linux-next merge of the pm tree got a conflict in:
include/dt-bindings/genpd/k2g.h
between commit:
7cc119f29b19 ("dt-bindings: Add TI SCI PM Domains")
from the arm-soc tree and commit:
45da8edd1741 ("dt-bindings: Add TI SCI PM Domains")
from the pm tree.
I fixed it up (I just used the pm tree version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: build failure after merge of the rdma tree
From: Stephen Rothwell @ 2017-04-21 1:42 UTC (permalink / raw)
To: Doug Ledford
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Joe Perches,
Steve Wise
Hi Doug,
After merging the rdma tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/infiniband/hw/cxgb4/cm.c: In function 'send_connect':
drivers/infiniband/hw/cxgb4/cm.c:830:5: error: implicit declaration of function 'PDBG' [-Werror=implicit-function-declaration]
PDBG("%s snd_isn %u\n", __func__, t6req->rsvd);
^
Caused by commit
a9a42886d0b3 ("cxgb4: Convert PDBG to pr_debug")
I have used the rdma tree from next-20170420 for today.
There was another PDBG() missed in that file as well.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: build failure after merge of the rdma tree
From: Joe Perches @ 2017-04-21 1:58 UTC (permalink / raw)
To: Stephen Rothwell, Doug Ledford
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Steve Wise
In-Reply-To: <20170421114216.7878bee4@canb.auug.org.au>
On Fri, 2017-04-21 at 11:42 +1000, Stephen Rothwell wrote:
> Hi Doug,
>
> After merging the rdma tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/infiniband/hw/cxgb4/cm.c: In function 'send_connect':
> drivers/infiniband/hw/cxgb4/cm.c:830:5: error: implicit declaration of function 'PDBG' [-Werror=implicit-function-declaration]
> PDBG("%s snd_isn %u\n", __func__, t6req->rsvd);
> ^
>
> Caused by commit
>
> a9a42886d0b3 ("cxgb4: Convert PDBG to pr_debug")
>
> I have used the rdma tree from next-20170420 for today.
>
> There was another PDBG() missed in that file as well.
Pretty sure there were crossing commits adding PDBG()
as the original patches were written against next-20170209
>From my tree:
$ git log --pretty=oneline -5 747edc68212781296de30dd2b4e63711240da7a9
747edc68212781296de30dd2b4e63711240da7a9 cxgb4: Convert PDBG to pr_debug
d054cd530aeef452c7c252504f7d4d6ebba31ae3 cxgb4: Use more common logging style
41a74ceecd35cf2f38e2a1a1a394c7718547deb6 cxgb3: Convert PDBG to pr_debug
15772862930dfd2f2e10574b86c063d781976a89 cxgb3: Use more common logging style
9f7e70ff42dbf3af7ed0699906b699c41930b265 Add linux-next specific files for 20170209
$ git grep -w PDBG 747edc68212781296de30dd2b4e63711240da7a9
$
^ permalink raw reply
* linux-next: build failure after merge of the drm-misc tree
From: Stephen Rothwell @ 2017-04-21 2:10 UTC (permalink / raw)
To: Daniel Vetter, Intel Graphics, DRI, Olof Johansson, Arnd Bergmann,
ARM
Cc: Jens Wiklander, Linux-Next Mailing List, Logan Gunthorpe,
Linux Kernel Mailing List, Sumit Semwal
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/tee/tee_shm.c:87:2: error: unknown field 'kmap_atomic' specified in initializer
.kmap_atomic = tee_shm_op_kmap_atomic,
^
drivers/tee/tee_shm.c:87:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.kmap_atomic = tee_shm_op_kmap_atomic,
^
drivers/tee/tee_shm.c:87:17: note: (near initialization for 'tee_shm_dma_buf_ops.begin_cpu_access')
drivers/tee/tee_shm.c:88:2: error: unknown field 'kmap' specified in initializer
.kmap = tee_shm_op_kmap,
^
drivers/tee/tee_shm.c:88:10: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.kmap = tee_shm_op_kmap,
^
drivers/tee/tee_shm.c:88:10: note: (near initialization for 'tee_shm_dma_buf_ops.end_cpu_access')
Caused by commit
f9b67f0014cb ("dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro")
interacting with commit
967c9cca2cc5 ("tee: generic TEE subsystem")
from the arm-soc tree.
I applied the following merge fix patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 21 Apr 2017 12:06:32 +1000
Subject: [PATCH] tee: merge fix for dma-ops field name changes
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/tee/tee_shm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
index 0be1e3e93bee..4e14c9c9cb1c 100644
--- a/drivers/tee/tee_shm.c
+++ b/drivers/tee/tee_shm.c
@@ -84,8 +84,8 @@ static struct dma_buf_ops tee_shm_dma_buf_ops = {
.map_dma_buf = tee_shm_op_map_dma_buf,
.unmap_dma_buf = tee_shm_op_unmap_dma_buf,
.release = tee_shm_op_release,
- .kmap_atomic = tee_shm_op_kmap_atomic,
- .kmap = tee_shm_op_kmap,
+ .map_atomic = tee_shm_op_kmap_atomic,
+ .map = tee_shm_op_kmap,
.mmap = tee_shm_op_mmap,
};
--
2.11.0
--
Cheers,
Stephen Rothwell
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: linux-next: build failure after merge of the rdma tree
From: Doug Ledford @ 2017-04-21 2:21 UTC (permalink / raw)
To: Joe Perches, Stephen Rothwell
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Steve Wise
In-Reply-To: <1492739935.30293.20.camel@perches.com>
On Thu, 2017-04-20 at 18:58 -0700, Joe Perches wrote:
> On Fri, 2017-04-21 at 11:42 +1000, Stephen Rothwell wrote:
> >
> > Hi Doug,
> >
> > After merging the rdma tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > drivers/infiniband/hw/cxgb4/cm.c: In function 'send_connect':
> > drivers/infiniband/hw/cxgb4/cm.c:830:5: error: implicit declaration
> > of function 'PDBG' [-Werror=implicit-function-declaration]
> > PDBG("%s snd_isn %u\n", __func__, t6req->rsvd);
> > ^
> >
> > Caused by commit
> >
> > a9a42886d0b3 ("cxgb4: Convert PDBG to pr_debug")
> >
> > I have used the rdma tree from next-20170420 for today.
> >
> > There was another PDBG() missed in that file as well.
>
> Pretty sure there were crossing commits adding PDBG()
> as the original patches were written against next-20170209
>
> From my tree:
>
> $ git log --pretty=oneline -5
> 747edc68212781296de30dd2b4e63711240da7a9
> 747edc68212781296de30dd2b4e63711240da7a9 cxgb4: Convert PDBG to
> pr_debug
> d054cd530aeef452c7c252504f7d4d6ebba31ae3 cxgb4: Use more common
> logging style
> 41a74ceecd35cf2f38e2a1a1a394c7718547deb6 cxgb3: Convert PDBG to
> pr_debug
> 15772862930dfd2f2e10574b86c063d781976a89 cxgb3: Use more common
> logging style
> 9f7e70ff42dbf3af7ed0699906b699c41930b265 Add linux-next specific
> files for 20170209
>
> $ git grep -w PDBG 747edc68212781296de30dd2b4e63711240da7a9
> $
I created a fix and added it to my tree.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
^ permalink raw reply
* Re: linux-next: build failure after merge of the rdma tree
From: Stephen Rothwell @ 2017-04-21 2:21 UTC (permalink / raw)
To: Joe Perches
Cc: Doug Ledford, Linux-Next Mailing List, Linux Kernel Mailing List,
Steve Wise
In-Reply-To: <1492739935.30293.20.camel@perches.com>
Hi Joe,
On Thu, 20 Apr 2017 18:58:55 -0700 Joe Perches <joe@perches.com> wrote:
>
> Pretty sure there were crossing commits adding PDBG()
> as the original patches were written against next-20170209
>
> From my tree:
>
> $ git log --pretty=oneline -5 747edc68212781296de30dd2b4e63711240da7a9
> 747edc68212781296de30dd2b4e63711240da7a9 cxgb4: Convert PDBG to pr_debug
> d054cd530aeef452c7c252504f7d4d6ebba31ae3 cxgb4: Use more common logging style
> 41a74ceecd35cf2f38e2a1a1a394c7718547deb6 cxgb3: Convert PDBG to pr_debug
> 15772862930dfd2f2e10574b86c063d781976a89 cxgb3: Use more common logging style
> 9f7e70ff42dbf3af7ed0699906b699c41930b265 Add linux-next specific files for 20170209
>
> $ git grep -w PDBG 747edc68212781296de30dd2b4e63711240da7a9
> $
In the rdma tree:
$ git log --pretty=oneline -5 a9a42886d0b3
a9a42886d0b3b989166472b7ea59b1c157d90f9b cxgb4: Convert PDBG to pr_debug
700456bd25946ef531773d1ad2dd511e1cc4515e cxgb4: Use more common logging style
b7b37ee0e137c8384c6cb3a37c4621649d5acdf6 cxgb3: Convert PDBG to pr_debug
46b2d4e8eca752003b903e68c3bec6b15fd7eba0 cxgb3: Use more common logging style
cd565b4b51e5fe258d6ce9ddc167ee51f3044ba5 IB/IPoIB: Support acceleration options callbacks
$ git grep -w PDBG a9a42886d0b3
a9a42886d0b3:drivers/infiniband/hw/cxgb4/cm.c: PDBG("%s snd_isn %u\n", __func__, t6req->rsvd);
a9a42886d0b3:drivers/infiniband/hw/cxgb4/cm.c: PDBG("%s snd_isn %u\n", __func__, t6req6->rsvd);
So these were added somewhere in Doug's tree and they need to be fixed
up there. Your patches were rebased/cherrypicked/applied on to Doug's tree.
Ah, the new ones come from commit
192539f4ce36 "iw_cxgb4: clean up send_connect()"
but that is in v4.11-rc1 and so should would not have been in next-20170209.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: build failure after merge of the rdma tree
From: Stephen Rothwell @ 2017-04-21 2:23 UTC (permalink / raw)
To: Doug Ledford
Cc: Joe Perches, Linux-Next Mailing List, Linux Kernel Mailing List,
Steve Wise
In-Reply-To: <1492741275.3041.21.camel@redhat.com>
Hi Doug,
On Thu, 20 Apr 2017 22:21:15 -0400 Doug Ledford <dledford@redhat.com> wrote:
>
> I created a fix and added it to my tree.
Thanks.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: [PATCH] staging: rtl8188eu: style fixes
From: Greg Kroah-Hartman @ 2017-04-21 4:21 UTC (permalink / raw)
To: Galo Navarro; +Cc: linux-next, Larry Finger
In-Reply-To: <20170420214226.GB1347@lear>
On Thu, Apr 20, 2017 at 11:42:26PM +0200, Galo Navarro wrote:
> Signed-off-by: Galo Navarro <anglor@varoa.net>
I can't take patches without any changelog text.
Also please use scripts/get_maintainer.pl to determine who, and what
mailing lists, to send patches too.
good luck!
greg k-h
^ permalink raw reply
* linux-next: manual merge of the usb tree with the jc_docs tree
From: Stephen Rothwell @ 2017-04-21 4:28 UTC (permalink / raw)
To: Greg KH, Jonathan Corbet
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Mauro Carvalho Chehab
Hi all,
Today's linux-next merge of the usb tree got a conflict in:
Documentation/media/v4l-drivers/philips.rst
between commit:
9b06f754133c ("convert philips.txt to ReST and add to media docs")
from the jc_docs tree and commit:
21470e32ca7f ("usb: fix some references for /proc/bus/usb")
from the usb tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/media/v4l-drivers/philips.rst
index 620bcfea7af0,be8c80eff374..000000000000
--- a/Documentation/media/v4l-drivers/philips.rst
+++ b/Documentation/media/v4l-drivers/philips.rst
@@@ -145,8 -140,8 +145,8 @@@ dev_hin
A camera is specified by its type (the number from the camera model,
like PCA645, PCVC750VC, etc) and optionally the serial number (visible
- in /proc/bus/usb/devices). A hint consists of a string with the following
+ in /sys/kernel/debug/usb/devices). A hint consists of a string with the following
- format:
+ format::
[type[.serialnumber]:]node
^ permalink raw reply
* linux-next: manual merge of the char-misc tree with the pci tree
From: Stephen Rothwell @ 2017-04-21 4:45 UTC (permalink / raw)
To: Greg KH, Arnd Bergmann, Bjorn Helgaas
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Kishon Vijay Abraham I, Cyril Bur, Andy Shevchenko
Hi all,
Today's linux-next merge of the char-misc tree got a conflict in:
drivers/misc/Makefile
between commit:
58c89c8aa0e8 ("misc: Add host side PCI driver for PCI test function device")
from the pci tree and commits:
6c4e97678501 ("drivers/misc: Add Aspeed LPC control driver")
51c1e9b554c9 ("auxdisplay: Move panel.c to drivers/auxdisplay folder")
from the char-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/misc/Makefile
index 6e139cd70421,4fb10af2ea1c..000000000000
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@@ -53,8 -52,7 +52,8 @@@ obj-$(CONFIG_GENWQE) += genwqe
obj-$(CONFIG_ECHO) += echo/
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
obj-$(CONFIG_CXL_BASE) += cxl/
- obj-$(CONFIG_PANEL) += panel.o
+ obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
+obj-$(CONFIG_PCI_ENDPOINT_TEST) += pci_endpoint_test.o
lkdtm-$(CONFIG_LKDTM) += lkdtm_core.o
lkdtm-$(CONFIG_LKDTM) += lkdtm_bugs.o
^ permalink raw reply
* Re: linux-next: manual merge of the char-misc tree with the pci tree
From: Greg KH @ 2017-04-21 4:55 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Arnd Bergmann, Bjorn Helgaas, Linux-Next Mailing List,
Linux Kernel Mailing List, Kishon Vijay Abraham I, Cyril Bur,
Andy Shevchenko
In-Reply-To: <20170421144540.2635313f@canb.auug.org.au>
On Fri, Apr 21, 2017 at 02:45:40PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the char-misc tree got a conflict in:
>
> drivers/misc/Makefile
>
> between commit:
>
> 58c89c8aa0e8 ("misc: Add host side PCI driver for PCI test function device")
>
> from the pci tree and commits:
>
> 6c4e97678501 ("drivers/misc: Add Aspeed LPC control driver")
> 51c1e9b554c9 ("auxdisplay: Move panel.c to drivers/auxdisplay folder")
>
> from the char-misc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/misc/Makefile
> index 6e139cd70421,4fb10af2ea1c..000000000000
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@@ -53,8 -52,7 +52,8 @@@ obj-$(CONFIG_GENWQE) += genwqe
> obj-$(CONFIG_ECHO) += echo/
> obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
> obj-$(CONFIG_CXL_BASE) += cxl/
> - obj-$(CONFIG_PANEL) += panel.o
> + obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
> +obj-$(CONFIG_PCI_ENDPOINT_TEST) += pci_endpoint_test.o
>
> lkdtm-$(CONFIG_LKDTM) += lkdtm_core.o
> lkdtm-$(CONFIG_LKDTM) += lkdtm_bugs.o
Looks good to me!
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: build failure after merge of the drm-misc tree
From: Logan Gunthorpe @ 2017-04-21 5:03 UTC (permalink / raw)
To: Stephen Rothwell, Daniel Vetter, Intel Graphics, DRI,
Olof Johansson, Arnd Bergmann, ARM
Cc: Jens Wiklander, Linux-Next Mailing List,
Linux Kernel Mailing List, Sumit Semwal
In-Reply-To: <20170421121014.3ee14a83@canb.auug.org.au>
Thanks Stephen. Looks good to me.
Logan
On 20/04/17 08:10 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/tee/tee_shm.c:87:2: error: unknown field 'kmap_atomic' specified in initializer
> .kmap_atomic = tee_shm_op_kmap_atomic,
> ^
> drivers/tee/tee_shm.c:87:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> .kmap_atomic = tee_shm_op_kmap_atomic,
> ^
> drivers/tee/tee_shm.c:87:17: note: (near initialization for 'tee_shm_dma_buf_ops.begin_cpu_access')
> drivers/tee/tee_shm.c:88:2: error: unknown field 'kmap' specified in initializer
> .kmap = tee_shm_op_kmap,
> ^
> drivers/tee/tee_shm.c:88:10: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> .kmap = tee_shm_op_kmap,
> ^
> drivers/tee/tee_shm.c:88:10: note: (near initialization for 'tee_shm_dma_buf_ops.end_cpu_access')
>
> Caused by commit
>
> f9b67f0014cb ("dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro")
>
> interacting with commit
>
> 967c9cca2cc5 ("tee: generic TEE subsystem")
>
> from the arm-soc tree.
>
> I applied the following merge fix patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 21 Apr 2017 12:06:32 +1000
> Subject: [PATCH] tee: merge fix for dma-ops field name changes
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/tee/tee_shm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
> index 0be1e3e93bee..4e14c9c9cb1c 100644
> --- a/drivers/tee/tee_shm.c
> +++ b/drivers/tee/tee_shm.c
> @@ -84,8 +84,8 @@ static struct dma_buf_ops tee_shm_dma_buf_ops = {
> .map_dma_buf = tee_shm_op_map_dma_buf,
> .unmap_dma_buf = tee_shm_op_unmap_dma_buf,
> .release = tee_shm_op_release,
> - .kmap_atomic = tee_shm_op_kmap_atomic,
> - .kmap = tee_shm_op_kmap,
> + .map_atomic = tee_shm_op_kmap_atomic,
> + .map = tee_shm_op_kmap,
> .mmap = tee_shm_op_mmap,
> };
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: linux-next: manual merge of the pm tree with the arm-soc tree
From: Arnd Bergmann @ 2017-04-21 5:53 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Rafael J. Wysocki, Olof Johansson, ARM, Linux-Next Mailing List,
Linux Kernel Mailing List, Dave Gerlach, Santosh Shilimkar,
Nishanth Menon
In-Reply-To: <20170421105405.6a690b35@canb.auug.org.au>
On Fri, Apr 21, 2017 at 2:54 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the pm tree got a conflict in:
>
> include/dt-bindings/genpd/k2g.h
>
> between commit:
>
> 7cc119f29b19 ("dt-bindings: Add TI SCI PM Domains")
>
> from the arm-soc tree and commit:
>
> 45da8edd1741 ("dt-bindings: Add TI SCI PM Domains")
>
> from the pm tree.
>
> I fixed it up (I just used the pm tree version) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
Dave, Santosh,
any idea what happened here? It seems that we picked up the wrong
version of the tree, do we need to drop this from arm-soc?
Arnd
^ permalink raw reply
* Re: linux-next: manual merge of the pm tree with the arm-soc tree
From: santosh.shilimkar @ 2017-04-21 6:39 UTC (permalink / raw)
To: Arnd Bergmann, Stephen Rothwell
Cc: Rafael J. Wysocki, Olof Johansson, ARM, Linux-Next Mailing List,
Linux Kernel Mailing List, Dave Gerlach, Santosh Shilimkar,
Nishanth Menon
In-Reply-To: <CAK8P3a3kHO1NZFJXvDwWO625aEmXoo2540FRKe+YYzoYE9NCSg@mail.gmail.com>
On 4/20/17 10:53 PM, Arnd Bergmann wrote:
> On Fri, Apr 21, 2017 at 2:54 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi all,
>>
>> Today's linux-next merge of the pm tree got a conflict in:
>>
>> include/dt-bindings/genpd/k2g.h
>>
>> between commit:
>>
>> 7cc119f29b19 ("dt-bindings: Add TI SCI PM Domains")
>>
>> from the arm-soc tree and commit:
>>
>> 45da8edd1741 ("dt-bindings: Add TI SCI PM Domains")
>>
>> from the pm tree.
>>
>> I fixed it up (I just used the pm tree version) and can carry the fix as
>> necessary. This is now fixed as far as linux-next is concerned, but any
>> non trivial conflicts should be mentioned to your upstream maintainer
>> when your tree is submitted for merging. You may also want to consider
>> cooperating with the maintainer of the conflicting tree to minimise any
>> particularly complex conflicts.
>
> Dave, Santosh,
>
> any idea what happened here? It seems that we picked up the wrong
> version of the tree, do we need to drop this from arm-soc?
>
Nope. Its because this series was in my 'next' branch for a week or
so and now it made it via arm-soc tree next as well.
I just cleaned up my next head so it linux-next next tag should have
only arm-soc copy.
Regards,
Santosh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox