I recently submitted a patch (attached below) that corrects a couple of 'sparse' warnings in drivers/staging/rtl8192u/r8192U_dm.c. I got this reply back from greg k-h:
This patch does not apply to my tree at all :( Please rebase it against linux-next and try again.
However, I thought I *was* working off linux-next. This is what I did: $ git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git $ git fetch linux-next $ git fetch --tags linux-next $ git remote update $ git checkout next-20170310 $ git apply 0001-staging-rtl8192u-use-__le16_to_cpu-instead-of-cast.patch ... and the patch applied ok. Just to be sure, I also did this: $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git $ git apply 0001-staging-rtl8192u-use-__le16_to_cpu-instead-of-cast.patch ... and the patch again applied OK. What am I doing wrong / where should I go for more info? Thanks, Perry --- drivers/staging/rtl8192u/r8192U_dm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/rtl8192u/r8192U_dm.c b/drivers/staging/rtl8192u/r8192U_dm.c index 9209aad..33d105d 100644 --- a/drivers/staging/rtl8192u/r8192U_dm.c +++ b/drivers/staging/rtl8192u/r8192U_dm.c @@ -2304,9 +2304,9 @@ static void dm_check_edca_turbo( /* For Each time updating EDCA parameter, reset EDCA turbo mode status. */ dm_init_edca_turbo(dev); u1bAIFS = qos_parameters->aifs[0] * ((mode&(IEEE_G|IEEE_N_24G)) ? 9 : 20) + aSifsTime; - u4bAcParam = (((u32)(qos_parameters->tx_op_limit[0])) << AC_PARAM_TXOP_LIMIT_OFFSET)| - (((u32)(qos_parameters->cw_max[0])) << AC_PARAM_ECW_MAX_OFFSET)| - (((u32)(qos_parameters->cw_min[0])) << AC_PARAM_ECW_MIN_OFFSET)| + u4bAcParam = (((u32)__le16_to_cpu(qos_parameters->tx_op_limit[0])) << AC_PARAM_TXOP_LIMIT_OFFSET) | + (((u32)__le16_to_cpu(qos_parameters->cw_max[0])) << AC_PARAM_ECW_MAX_OFFSET) | + (((u32)__le16_to_cpu(qos_parameters->cw_min[0])) << AC_PARAM_ECW_MIN_OFFSET) | ((u32)u1bAIFS << AC_PARAM_AIFS_OFFSET); /*write_nic_dword(dev, WDCAPARA_ADD[i], u4bAcParam);*/ write_nic_dword(dev, EDCAPARA_BE, u4bAcParam);
On Tue, Mar 14, 2017 at 07:52:36PM -0600, Perry Hooker wrote:
I recently submitted a patch (attached below) that corrects a couple of 'sparse' warnings in drivers/staging/rtl8192u/r8192U_dm.c.
I got this reply back from greg k-h:
This patch does not apply to my tree at all :( Please rebase it against linux-next and try again.
However, I thought I *was* working off linux-next. This is what I did:
$ git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git $ git fetch linux-next $ git fetch --tags linux-next $ git remote update $ git checkout next-20170310 $ git apply 0001-staging-rtl8192u-use-__le16_to_cpu-instead-of-cast.patch
... and the patch applied ok. Just to be sure, I also did this:
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git $ git apply 0001-staging-rtl8192u-use-__le16_to_cpu-instead-of-cast.patch
... and the patch again applied OK.
What am I doing wrong / where should I go for more info?
linux-next is usually a day or so behind my tree, so maybe there were other patches from other developers that caused the conflict. Try linux-next now and see if there still is a conflict or not, and if not, rebase and resend the patches. If you really want to do a lot of staging tree work, I suggest working off of my staging-next or staging-testing branch. Note, sometimes staging-testing gets rebased, so unless you know how to handle that, I would stay away from it :) That's the fun of dealing with a subsystem that gets a few hundred patches submitted every day, it moves fast... thanks, greg k-h
On Thu, 16 Mar 2017 10:26:48 +0900, Greg KH said:
On Tue, Mar 14, 2017 at 07:52:36PM -0600, Perry Hooker wrote:
$ git checkout next-20170310
What am I doing wrong / where should I go for more info?
linux-next is usually a day or so behind my tree, so maybe there were other patches from other developers that caused the conflict. Try linux-next now and see if there still is a conflict or not, and if not, rebase and resend the patches.
Stephen Rothwell posted that there won't be any linux-next this week. Try on Monday.
participants (3)
-
Greg KH -
Perry Hooker -
valdis.kletnieks@vt.edu