lkml.org 
[lkml]   [2006]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Promise 'stex' driver
    Ed Lin wrote:
    > So it seems there are several possibilities here(regarding no.1 comment):
    > 1.The bridge code is kept unchanged. And, as this is a violation to
    > Linux tradition and requirement, it could not be admitted upstream.
    > 2.The code could be modified to be conforming to Linux standard. But,
    > we are new to Linux. Maybe we need some specific instructions to know
    > how to do it. Sorry if this request becomes annoying.
    > 3.Remove the code.
    >
    > We are wondering what should we do next. We are seeking the community's
    > help, and advice, something we definitely need.

    The normal process for submitting changes to the Linux kernel is by
    submitting a series of patches, each containing a single logical set of
    changes. For example:

    [PATCH 1/4] stex: white space/ minor fix(INQUIRY, max_channel)
    [PATCH 2/4] stex: add new device ids
    [PATCH 3/4] stex: update internal copy code path
    [PATCH 4/4] stex: add hard reset function

    Each patch may be dependent on prior patches. Each patch should produce
    a usable driver, e.g.

    patch #1 must produce a usable driver.
    patch #1 + #2 must produce a usable driver.
    patch #1 + #2 + #3 must produce a usable driver.
    patch #2 + #3 (missing patch #1) need not produce a usable driver.

    This is analogous to a mathematical proof: each step in the proof
    describes a complete equation.

    Therefore, to move forward, I would suggest that you break up your
    submitted patch into multiple patches, ordered such that the PCI
    bridge-related code is in the final patch. This permits me to
    immediately merge patches not related to PCI bridge stuff, while
    simultaneously discussing the hard reset/bridge change.

    Note that this is standard iterative development:

    1. 'stex' driver development, testing.
    2. Post a set of 'stex' patches.
    3. Community reviews patches.
    4. Upstream maintainer merges some or all of the patches.
    5. Go to step #1, perhaps to resend (changed or unchanged)
    the patches that were not merged.

    Regards,

    Jeff



    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-07-25 19:33    [W:0.023 / U:62.320 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site