> On Mon, Aug 19, 2013 at 09:32:58AM +0000, Grumbach, Emmanuel wrote:
> > >
> > > I would like to ask if below change is safe (I'm considering to do
> > > that change on iwlegacy):
> > >
> > > diff --git a/drivers/net/wireless/iwlwifi/pcie/rx.c
> > > b/drivers/net/wireless/iwlwifi/pcie/rx.c
> > > index 567e67a..1ebdb83 100644
> > > --- a/drivers/net/wireless/iwlwifi/pcie/rx.c
> > > +++ b/drivers/net/wireless/iwlwifi/pcie/rx.c
> > > @@ -183,7 +183,7 @@ static void iwl_pcie_rxq_inc_wr_ptr(struct
> > > iwl_trans *trans, struct iwl_rxq *q)
> > > } else {
> > > /* Device expects a multiple of 8 */
> > > q->write_actual = (q->write & ~0x7);
> > > - iwl_write_direct32(trans, FH_RSCSR_CHNL0_WPTR,
> > > + iwl_write32(trans, FH_RSCSR_CHNL0_WPTR,
> > > q->write_actual);
> > > }
> > > }
> > >
> > > This register seems to be only read by firmware, so maybe we can
> > > modify it without grab nic access. We are doing that on
> iwl_pcie_txq_inc_wr_ptr().
> > >
> >
> > I am not sure...
> > I am not sure what would be the behavior: not updating the value at all, or
> having the HW use an old value for a while.
> > Does this cost you so much CPU that it justifies such a change?
>
> I have those bug reports:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=863386
> https://bugzilla.redhat.com/show_bug.cgi?id=889467
> https://bugzilla.redhat.com/show_bug.cgi?id=895650
> https://bugzilla.redhat.com/show_bug.cgi?id=989025
>
> All are 4965 specific - I haven't seen similar traces on iwlwifi. On some cases
> use nohz=off boot option helped with the problem, so this could be also
> some kernel issue when udelay() is not working as expected. Anyway I'm
> considering to remove grab_nic_access from that path and would like to
> know possible consequences from firmware perspective.
>
I see... I am sorry to tell you that I can't be sure on the exact consequences, but I am pretty sure that it is not a good idea to do that...
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
