b43-dev.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Rafał Miłecki" <zajec5@gmail.com>
To: b43-dev@lists.infradead.org
Subject: unable to write flashrom, functionality broken?
Date: Tue, 1 Feb 2011 13:51:01 +0100	[thread overview]
Message-ID: <AANLkTikoBMgObBgM7tz8sPPKRdKV0fky-BAoe_K_LgPj@mail.gmail.com> (raw)
In-Reply-To: <26E2E0F1-1CD4-4A96-B96F-D1F7B6EE5B17@daleenterprise.com>

2011/2/1 Dale Walsh <dale@daleenterprise.com>:
> I had a hard drive failure which forced me to perform a fresh/clean
> installation of ubuntu 10 on a new drive since the old drive no longer
> functions (it was rather old).
> My use of the b43 software is only for modification of the PCI ID's of the
> flashrom and the original installation was provided to me on the HD.
> Now I am unable to write the flashrom after the new installation it always
> reports "write error: Operation Not Supported" and this is using the same
> cards I was flashing before, I even tried using a?previously?modified card
> and I get the same failure.
> Since it worked before I can only conclude that the new software is broken
> and the ability to write is a requirement, can someone help me resolve this
> please.

Do you mean ssb driver functionality? I remember Michael was fixing
writing some time ago:

commit e33761e6f23881de9f3ee77cc2204ab2e26f3d9a
Author: Michael Buesch <mb@bu3sch.de>
Date:   Mon Nov 23 20:58:06 2009 +0100

    ssb: Fix range check in sprom write

    The range check in the sprom image parser hex2sprom() is broken.
    One sprom word is 4 hex characters.
    This fixes the check and also adds much better sanity checks to the code.
    We better make sure the image is OK by doing some sanity checks to avoid
    bricking the device by accident.

    Signed-off-by: Michael Buesch <mb@bu3sch.de>
    Cc: stable at kernel.org
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 3ba6018aa314559c5867138a8173b068268a70db
Author: Michael Buesch <mb@bu3sch.de>
Date:   Mon Nov 23 20:12:13 2009 +0100

    ssb: Fix SPROM writing

    The SPROM writing routines were broken since we rewrote the suspend
    handling on wireless devices, because SPROM writing depended on suspend.

    This patch changes it and freezes devices with the driver remove(), probe()
    callbacks instead. This also simplifies the whole logics a lot.

    Signed-off-by: Michael Buesch <mb@bu3sch.de>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

Do you have that patches in your kernel?

-- 
Rafa?

  reply	other threads:[~2011-02-01 12:51 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-01 11:23 unable to write flashrom, functionality broken? Dale Walsh
2011-02-01 12:51 ` Rafał Miłecki [this message]
2011-02-01 12:57 ` Ehud Gavron
2011-02-01 16:28 ` Larry Finger
2011-02-02  7:50   ` Dale Walsh
2011-02-03  3:27     ` Larry Finger
2011-02-03 11:49       ` Dale Walsh
2011-02-03 11:59         ` Michael Büsch
2011-02-03 12:27           ` Dale Walsh
2011-02-03 22:06             ` Michael Büsch
2011-02-03 22:34               ` Peter Stuge
2011-02-03 22:49                 ` Michael Büsch
2011-02-03 23:47                   ` Peter Stuge
2011-02-04  0:29                     ` Michael Büsch
2011-02-04  1:16                       ` Peter Stuge
2011-02-04  3:14                       ` Dale Walsh
2011-02-04  5:49                         ` richardvoigt at gmail.com
2011-02-04 12:06                           ` Dale Walsh
2011-02-04 12:21                             ` Michael Büsch
2011-02-04 21:38                               ` Dale Walsh
2011-02-04 22:22                                 ` Ehud Gavron
2011-02-04 22:26                                 ` Michael Büsch
2011-02-04 22:29                                 ` Rafał Miłecki
2011-02-04 11:20                         ` Michael Büsch
2011-02-04 12:17                           ` Dale Walsh
2011-02-04 16:55                             ` Michael Büsch
2011-02-03 23:36               ` Dale Walsh
2011-02-03 23:49                 ` Peter Stuge
2011-02-04  0:17                 ` Michael Büsch

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=AANLkTikoBMgObBgM7tz8sPPKRdKV0fky-BAoe_K_LgPj@mail.gmail.com \
    --to=zajec5@gmail.com \
    --cc=b43-dev@lists.infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).