All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: David Lin <dlin@marvell.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	Pete Hsieh <peteh@marvell.com>, Chor Teck Law <ctlaw@marvell.com>
Subject: Re: [PATCH v2] Add new mac80211 driver mwlwifi.
Date: Wed, 17 Jun 2015 09:32:35 -0500	[thread overview]
Message-ID: <1434551555.3952.8.camel@redhat.com> (raw)
In-Reply-To: <9c9237415bfe49568467f9795dc08111@SC-EXCH02.marvell.com>

On Wed, 2015-06-17 at 08:34 +0000, David Lin wrote:
> > Johannes Berg wrote:
> > 
> > On Wed, 2015-06-17 at 08:07 +0000, David Lin wrote:
> > 
> > > > Also, you probably really should have two header files - one for the
> > > > firmware structs and one for the driver structs - especially since
> > > > you seem to be confusing the two!
> > > >
> > > As mentioned before, this is current interface with F/W, and this F/W
> > > is used by other marvell's drivers, I can't change it.
> > 
> > You're misunderstanding. I'm not asking you to change the interface. I'm just
> > asking you to make sure you know which part is firmware interface and which
> > isn't. Clearly, pointers *cannot* be firmware interface - if there's something
> > "cookie-like" that you use as pointers you at least need to make sure you know
> > how long this field is (32 or 64 bits)...
> >
> Yes, we know this kind of issue. We will enhance it in the future.
> > 
> > > All structures defined in this file are related to F/W commands, it
> > > should be better let them be defined in this file.
> > 
> > Given your own confusion on what's firmware API and what isn't, I'm not so
> > sure about that ...
> >
> I am sure all structures defined in this file is related to firmware command.

They may well be related, but that doesn't necessarily mean that the
driver side cannot be clearer about what fields of a struct are actually
read by the firmware, and what fields are private to the host
implementation as a data stash (eg, 'priv'-type stuff).  Redoing the
structs like Johannes suggested originally would make that
crystal-clear...

Dan


  reply	other threads:[~2015-06-17 14:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-17  6:06 [PATCH v2] Add new mac80211 driver mwlwifi David Lin
2015-06-17  7:27 ` Johannes Berg
2015-06-17  8:07   ` David Lin
2015-06-17  8:27     ` Johannes Berg
2015-06-17  8:34       ` David Lin
2015-06-17 14:32         ` Dan Williams [this message]
2015-06-17 14:42           ` David Lin
2015-06-17 14:30   ` Dan Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1434551555.3952.8.camel@redhat.com \
    --to=dcbw@redhat.com \
    --cc=ctlaw@marvell.com \
    --cc=dlin@marvell.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=peteh@marvell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.