Hi George, On 22/03/20 5:34 pm, George Spelvin wrote: > > The code in lib/ is the desired polynomial, and even includes > the 1-bit left shift in the table rather than needing to code > it explicitly. These changes will break functionality. The crc7 used in 'wilc' is based on the previous revision(commit# ad241528c491). The new changes can not be adopted from 'wilc' device side because the crc calculation is done on hardware IP and it expects the value based the older implementation. > > Signed-off-by: George Spelvin <lkml@xxxxxxx> > Cc: Adham Abozaeid <adham.abozaeid@xxxxxxxxxxxxx> > Cc: Ajay Singh <ajay.kathat@xxxxxxxxxxxxx> > Cc: linux-wireless@xxxxxxxxxxxxxxx > --- > Just a drive-by fix I happened to spot. Another possible bug I found in > the code is in wilc_wfi_cfg_tx_vendor_spec: > > get_random_bytes(&priv->p2p.local_random, 1); > priv->p2p.local_random++; > > What is the point of the increment? Since local_random is an 8-bit > variable, the result is 8 random bits in the range [0..255], the same > thing that was there before the increment. > > Also, I was thinking it could be replaced by prandom_u32(); does this > application call for crypto-grade randomness? > It seems you are using an old version of 'wilc' driver. This logic is already changed in the latest code. We have remove custom behavior to decide p2p role (P2P_Go/P2P_Client) between 2 wilc devices based on 'local_random' value and now relies on 'intent' value received from 'wpa_s'. To submit changes for wilc, please use 'staging-next' branch of https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git repo. Regards, Ajay
