From: George Kashperko <george@znau.edu.ua>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: linux-wireless@vger.kernel.org,
"John W. Linville" <linville@tuxdriver.com>,
"Michael Büsch" <mb@bu3sch.de>,
b43-dev@lists.infradead.org
Subject: Re: [RFC][PATCH] ssb: separate common scanning functions
Date: Fri, 18 Mar 2011 17:58:45 +0200 [thread overview]
Message-ID: <1300463925.13499.118.camel@dev.znau.edu.ua> (raw)
In-Reply-To: <AANLkTi=2qBhKfJZ8a2GEgx_4aJL_85FKODUX31BddmN1@mail.gmail.com>
> 2011/3/18 George Kashperko <george@znau.edu.ua>:
> >> 2011/3/18 George Kashperko <george@znau.edu.ua>:
> >> > Current ssb code ideology isn't really good place to start with support
> >> > for ai backplanes. Its really great to see you willing to get ai
> >> > supported in mainline but I'm sure this should be done apart from the
> >> > ssb code and not even with one as the design decisions origin. Several
> >> > concepts the ssb is based on are not designed to support anything else
> >> > than ocp/sb and will require workarounds to suport ai.
> >> > Thanks to Michael I had a time to think over the possibly code
> >> > abstraction for shared sb and ai support. And while I'm still sure the
> >> > patchwork for ai over ssb support is of good use as some intermediate
> >> > decision to support ai-based hardware in sertain distributions but now I
> >> > support Michael in that such (hopefully) a temporary buildups should not
> >> > be in mainline.
> >>
> >> Please, give some concrete arguments, which part of design does not match AI.
> > SSB design is core-centric, where all the bus activities are made in
> > regard to the cores. This mostly is correct as most of the time
> > bus/drivers code work with cores.
>
> So finally, is there anything wrong about that?
Nothing wrong as soon as technically imperfect solution is not intended
to be in mainline :) Otherwise my latest AI RFC already ready to merge.
> >> My patch has shown we need to duplicate 40% of SSB's scanning code.
> >> What for example about pci.c? Which functions from that file won't be
> >> duplicated in totally separated?
> >>
> > Going further in extending ssb to support ai will either require the
> > host to be confident of the backplane type and layout (see
> > drivers/staging/brcm80211/utils for the good example of messup it will
> > lead to) or will reguire the backplane-specific code to break into the
> > host code (brcm80211/utils again).
>
> I don't want to extend ssb, I said that with my patch message. I
> wanted separated drivers sharing some functions, please take a look at
> my comment included in patch. I think we could also create *separated*
> host drivers sharing most of the code.
My english is awful therefore seems we missunderstood each other. I'm
sure I got your point right - you plan to start up the new (bcmb)
project for both sb and ai support.
My point here is - this is great but making design decisions on ssb code
model is wrong.
Have nice day,
George
next prev parent reply other threads:[~2011-03-18 15:59 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-18 12:02 [RFC][PATCH] ssb: separate common scanning functions Rafał Miłecki
2011-03-18 13:03 ` George Kashperko
2011-03-18 14:10 ` Rafał Miłecki
2011-03-18 14:50 ` Rafał Miłecki
2011-03-18 15:49 ` George Kashperko
2011-03-18 16:25 ` Rafał Miłecki
2011-03-18 17:13 ` Larry Finger
2011-03-18 18:11 ` George Kashperko
2011-03-18 19:04 ` Rafał Miłecki
2011-03-18 20:01 ` George Kashperko
2011-03-18 21:52 ` Rafał Miłecki
2011-03-18 22:40 ` George Kashperko
2011-03-18 23:06 ` Rafał Miłecki
2011-03-18 23:22 ` George Kashperko
2011-03-18 23:32 ` Rafał Miłecki
2011-03-18 14:59 ` George Kashperko
2011-03-18 15:17 ` Rafał Miłecki
2011-03-18 15:58 ` George Kashperko [this message]
2011-03-18 16:04 ` Rafał Miłecki
2011-03-18 20:26 ` Rafał Miłecki
2011-03-18 21:18 ` George Kashperko
2011-03-18 22:42 ` Rafał Miłecki
2011-03-18 22:50 ` George Kashperko
2011-03-18 13:06 ` Arend van Spriel
2011-03-18 19:49 ` Rafał Miłecki
2011-03-19 8:59 ` Arend van Spriel
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=1300463925.13499.118.camel@dev.znau.edu.ua \
--to=george@znau.edu.ua \
--cc=b43-dev@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=mb@bu3sch.de \
--cc=zajec5@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox