Date:   Tue, 14 Feb 2023 10:07:50 +0300
From:   Dan Carpenter <error27@gmail.com>
To:     Martin Kaiser <martin@kaiser.cx>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Larry Finger <Larry.Finger@lwfinger.net>,
        Phillip Potter <phil@philpotter.co.uk>,
        Michael Straube <straube.linux@gmail.com>,
        Pavel Skripkin <paskripkin@gmail.com>,
        linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] staging: r8188eu: Revert "staging: r8188eu: simplify
 rtw_get_ff_hwaddr"
Message-ID: <Y+szRoaj2rEz/0KN@kadam>
References: <20230211183205.426820-1-martin@kaiser.cx>
 <20230213195407.15085-1-martin@kaiser.cx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230213195407.15085-1-martin@kaiser.cx>
Precedence: bulk

On Mon, Feb 13, 2023 at 08:54:08PM +0100, Martin Kaiser wrote:
> This reverts commit fd48124e0982 ("staging: r8188eu: simplify
> rtw_get_ff_hwaddr").
> 
> The cleanup in this commit removes the qsel to addr mappings in
> rtw_get_ff_hwaddr. The underlying assumption is that rtw_write_port
> uses its addr parameter only for the high_queue check.
> 
> This is obviously incorrect as rtw_write_port calls
> ffaddr2pipehdl(pdvobj, addr);
> where addr is mapped to a usb bulk endpoint.
> 
> Unfortunately, testing did not show any problems. The Edimax V2 on which I
> tested has two bulk out endpoints. I guess that with the incorrect patch,
> addr could only be 0 (no high queue) or 6 (high queue), both of which were
> mapped to the first bulk out endpoint. Data transfers did still work...
> 
> Fixes: fd48124e0982 ("staging: r8188eu: simplify rtw_get_ff_hwaddr")
> Signed-off-by: Martin Kaiser <martin@kaiser.cx>
> ---
> v2:
>  - use correct patch prefix
>  - add a Fixes tag
>  - use 12-digit hash to refer to the reverted commit

Thanks, Martin!

regards,
dan carpenter