All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3 2/5] ARM: pm: add generic CPU suspend/resume support
From: Russell King - ARM Linux @ 2011-02-11 11:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <AANLkTimCtaSZ=CHT5snWZ496_bi4sH=0LU7vJ-Jfh=dP@mail.gmail.com>

On Wed, Feb 09, 2011 at 07:15:25PM -0800, Colin Cross wrote:
> The diagnostic register also needs to be saved to keep the errata bits
> set in __v7_setup.

Saving I've no problem with.  Restoring gets hairy with kernels running
in non-secure mode, as we can't just write the register - we don't know
whether we are running in secure or non-secure mode.  A write to the
register in NS mode will crash.

Santosh: is the diagnostic register on OMAP4 re-initialized by the secure
code on OMAP?

> > + ? ? ? stmia ? r0, {r4 - r11}
> > + ? ? ? ldmfd ? sp!, {r4 - r11, pc}
> > +ENDPROC(cpu_v7_do_suspend)
> > +
> > +ENTRY(cpu_v7_do_resume)
> > + ? ? ? mov ? ? ip, #0
> > + ? ? ? mcr ? ? p15, 0, ip, c8, c7, 0 ? @ invalidate TLBs
> > + ? ? ? mcr ? ? p15, 0, ip, c7, c5, 0 ? @ invalidate I cache
> 
> Does this need the same ALT_SMP/ALT_UP combo as v7_flush_icache_all?

That depends whether you the CPU which is resuming is part of a coherent
SMP system at that point.  This instruction will invalidate the I-cache
for the local CPU only, whereas the c7, c1 variant will invalidate the
instruction caches of all CPUs within the inner sharable domain.

Has anything changed in the other CPUs as a result of this CPU resuming
at this point?  I don't think so, so I think we just need to ensure that
the local CPU instruction cache is invalidated at this point.

> Tegra2 suspend and cpuidle works on top of this patch and the patch
> that adds SMP support to sleep_save_sp.  Tegra seems to need to
> invalidate the entire l1 data cache before enabling it,

As it's undefined what state the data cache is in on resume, I'm surprised
the s5pv210 code doesn't also need a D-cache invalidate too.  Maybe Samsung
folk can answer that.

> so I'm using a
> custom reset vector that branches to cpu_resume, and I'm handling the
> TLB invalidate in the function cpu_resume returns to.
> 
> Tested-by: Colin Cross <ccross@android.com>
> 
> Are you targeting 2.6.39 with these patches?  They replace a few
> hundred lines of code in the Tegra2 suspend, hotplug, and idle
> patches, so I'd like to wait until this is in before pushing mine.

Undecided at the moment.  It's great that you've tested it, and I've
also tested it on Assabet, but PXA and Samsung stuff hasn't been
tested yet.  I guess I could just push the generic and sa1100 bits for
2.6.39, unless the remainder gets tested.

Once the above issues have answers, I'll see about posting a new set of
patches.

^ permalink raw reply

* [ath9k-devel] 'RX-STBC12' and 'GF' not accepted
From: Thomas Andrews @ 2011-02-11 11:58 UTC (permalink / raw)
  To: ath9k-devel

Hi,

I have a couple of AR9220 cards running in 'N' mode, but I can't seem to get
either Greenfield or two RX STBC streams going. These are the errors I get in
each case:

  Driver does not support configured HT capability [GF]

and

  Driver does not support configured HT capability [RX-STBC*]

Is this something that is controlled in the eeprom?
You can see from the output of 'iw list' that only one RX spatial stream is allowed:

    RX STBC 1-stream

As I understand it, the AR9220 (AR9280) supports two spatial straams for both
TX and RX, and greenfield mode too. I am running the one card as an AP and the 
other as a STA. Is it possible that I have to do something on the STA to get 
greenfield operation to work?

When the link comes up, it generally goes into MCS 15 mode with short GI, but
throughput tests with iperf UDP never get above about 140 Mbit/s

Here's some more info:

This is a stock Ubuntu LTS installation with no custom compilations.
# -----------------------------------------------------------------------------
Linux atom 2.6.35-22-generic-pae #33-Ubuntu SMP Sun Sep 19 22:14:14 UTC 2010 i686 GNU/Linux
hostapd 1:0.6.10-2
wpasupplicant 0.6.10-2
iw 0.9.19-1
# -----------------------------------------------------------------------------
# Output of dmesg:

[   15.905053] ath9k 0000:03:07.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[   17.464303] ath: EEPROM regdomain: 0x0
[   17.464312] ath: EEPROM indicates default country code should be used
[   17.464319] ath: doing EEPROM country->regdmn map search
[   17.464327] ath: country maps to regdmn code: 0x3a
[   17.464334] ath: Country alpha2 being used: US
[   17.464340] ath: Regpair used: 0x3a
[   17.552718] phy0: Selected rate control algorithm 'ath9k_rate_control'
[   17.554541] Registered led device: ath9k-phy0::radio
[   17.554612] Registered led device: ath9k-phy0::assoc
[   17.554685] Registered led device: ath9k-phy0::tx
[   17.554765] Registered led device: ath9k-phy0::rx
[   17.554778] phy0: Atheros AR9280 Rev:2 mem=0xf8660000, irq=19
[   17.555130] cfg80211: Calling CRDA for country: US
[   17.576278] cfg80211: Regulatory domain changed to country: US
[   17.576290]     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[   17.576302]     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[   17.576312]     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
[   17.576322]     (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[   17.576332]     (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[   17.576342]     (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[   17.576352]     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
[   17.752556] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   17.817705] cfg80211: Found new beacon on frequency: 5180 MHz (Ch 36) on phy0
[   20.272330] wlan0: authenticate with 00:19:70:3f:97:74 (try 1)
[   20.275367] wlan0: authenticated
[   20.275404] wlan0: associate with 00:19:70:3f:97:74 (try 1)
[   20.315174] wlan0: RX AssocResp from 00:19:70:3f:97:74 (capab=0x11 status=0 aid=1)
[   20.315189] wlan0: associated
[   20.323407] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

# -----------------------------------------------------------------------------
# Contents of /etc/hostapd.conf

interface=wlan0
driver=nl80211
ssid=test_network
channel=36
hw_mode=a
auth_algs=1
wpa=3
wpa_passphrase=foobar
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP CCMP
rsn_pairwise=CCMP
wme_enabled=1
ieee80211n=1
ht_capab=[HT40+][SHORT-GI-40][DSSS_CCK-40][TX-STBC]
# doesn't work ---->  ht_capab=[HT40+][SHORT-GI-40][DSSS_CCK-40][TX-STBC][GF]
# doesn't work ---->  ht_capab=[HT40+][SHORT-GI-40][DSSS_CCK-40][TX-STBC][RX-STBC12]
country_code=US
wmm_enabled=1
wmm_ac_bk_cwmin=4
wmm_ac_bk_cwmax=10
wmm_ac_bk_aifs=7
wmm_ac_bk_txop_limit=0
wmm_ac_bk_acm=0
wmm_ac_be_aifs=3
wmm_ac_be_cwmin=4
wmm_ac_be_cwmax=10
wmm_ac_be_txop_limit=0
wmm_ac_be_acm=0
wmm_ac_vi_aifs=2
wmm_ac_vi_cwmin=3
wmm_ac_vi_cwmax=4
wmm_ac_vi_txop_limit=94
wmm_ac_vi_acm=0
wmm_ac_vo_aifs=2
wmm_ac_vo_cwmin=2
wmm_ac_vo_cwmax=3
wmm_ac_vo_txop_limit=47
wmm_ac_vo_acm=0
# -----------------------------------------------------------------------------
# iw reg get
country 00:
        (2402 - 2472 @ 40), (3, 20)
        (2457 - 2482 @ 20), (3, 20), PASSIVE-SCAN, NO-IBSS
        (2474 - 2494 @ 20), (3, 20), NO-OFDM, PASSIVE-SCAN, NO-IBSS
        (5170 - 5250 @ 40), (3, 20), PASSIVE-SCAN, NO-IBSS
        (5735 - 5835 @ 40), (3, 20), PASSIVE-SCAN, NO-IBSS
# -----------------------------------------------------------------------------
# iw list
Wiphy phy0
        Band 1:
                Capabilities: 0x11ce
                        HT20/HT40
                        SM Power Save disabled
                        RX HT40 SGI
                        TX STBC
                        RX STBC 1-stream
                        Max AMSDU length: 7935 bytes
                        DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 8 usec (0x06)
                HT TX/RX MCS rate indexes supported: 0-15
                Frequencies:
                        * 5180 MHz [36] (17.0 dBm)
                        * 5200 MHz [40] (17.0 dBm)
                        * 5220 MHz [44] (17.0 dBm)
                        * 5240 MHz [48] (17.0 dBm)
                        * 5260 MHz [52] (20.0 dBm) (passive scanning, no IBSS, radar detection)
                        * 5280 MHz [56] (20.0 dBm) (passive scanning, no IBSS, radar detection)
                        * 5300 MHz [60] (20.0 dBm) (passive scanning, no IBSS, radar detection)
                        * 5320 MHz [64] (20.0 dBm) (passive scanning, no IBSS, radar detection)
                        * 5500 MHz [100] (20.0 dBm) (passive scanning, no IBSS, radar detection)
                        * 5520 MHz [104] (20.0 dBm) (passive scanning, no IBSS, radar detection)
                        * 5540 MHz [108] (20.0 dBm) (passive scanning, no IBSS, radar detection)
                        * 5560 MHz [112] (20.0 dBm) (passive scanning, no IBSS, radar detection)
                        * 5580 MHz [116] (20.0 dBm) (passive scanning, no IBSS, radar detection)
                        * 5600 MHz [120] (disabled)
                        * 5620 MHz [124] (disabled)
                        * 5640 MHz [128] (disabled)
                        * 5660 MHz [132] (20.0 dBm) (passive scanning, no IBSS, radar detection)
                        * 5680 MHz [136] (20.0 dBm) (passive scanning, no IBSS, radar detection)
                        * 5700 MHz [140] (20.0 dBm) (passive scanning, no IBSS, radar detection)
                        * 5745 MHz [149] (30.0 dBm)
                        * 5765 MHz [153] (30.0 dBm)
                        * 5785 MHz [157] (30.0 dBm)
                        * 5805 MHz [161] (30.0 dBm)
                        * 5825 MHz [165] (30.0 dBm)
                Bitrates (non-HT):
                        * 6.0 Mbps
                        * 9.0 Mbps
                        * 12.0 Mbps
                        * 18.0 Mbps
                        * 24.0 Mbps
                        * 36.0 Mbps
                        * 48.0 Mbps
                        * 54.0 Mbps
        max # scan SSIDs: 4
        Supported interface modes:
                 * IBSS
                 * managed
                 * AP
                 * AP/VLAN
                 * monitor
                 * mesh point
        Supported commands:
                 * new_interface
                 * set_interface
                 * new_key
                 * new_beacon
                 * new_station
                 * new_mpath
                 * set_mesh_params
                 * set_bss
                 * authenticate
                 * associate
                 * deauthenticate
                 * disassociate
                 * join_ibss
                 * Unknown command (55)
                 * Unknown command (57)
                 * Unknown command (59)
                 * set_wiphy_netns
                 * Unknown command (65)
                 * connect
                 * disconnect
# -----------------------------------------------------------------------------
# On the STA, I just have a very basic setup in /etc/network/interfaces:

iface wlan0 inet static
    address 10.3.3.6
    netmask 255.255.255.0
    wireless-essid test_network
    wireless-mode managed
    wpa-ssid test_network
    wpa-psk foobar
# -----------------------------------------------------------------------------

^ permalink raw reply

* Re: [PATCH] picoxcell_crypto: add support for the picoxcell crypto engines
From: Jamie Iles @ 2011-02-11 11:57 UTC (permalink / raw)
  To: Kim Phillips; +Cc: Jamie Iles, linux-crypto, linux-arm-kernel, Herbert Xu
In-Reply-To: <20110210220916.aac2b545.kim.phillips@freescale.com>

On Thu, Feb 10, 2011 at 10:09:16PM -0600, Kim Phillips wrote:
> On Tue, 8 Feb 2011 15:56:16 +0000
> Jamie Iles <jamie@jamieiles.com> wrote:
> 
> > Picochip picoXcell devices have two crypto engines, one targeted
> > at IPSEC offload and the other at WCDMA layer 2 ciphering.
> >
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> > ---
> 
> nice driver ;).  Have a couple of comments though.

Hi Kim,

Thanks for the great review!

> 
> > +     help
> > +       This option enables support for the hardware offload engines in the
> > +       Picochip picoXcell SoC devices. Select this for IPSEC ESP offload
> > +       and for 3gpp Layer 2 ciphering support.
> 
> it'd be nice to mention what name the module will have.

Ok, will add.

> 
> > +#define SPACC_CRYPTO_AES_MAX_KEY_LEN 32
> > +#define SPACC_CRYPTO_AES_IV_LEN              16
> > +#define SPACC_CRYPTO_DES_IV_LEN              8
> 
> these are identical to algorithm-generic symbolic constants
> AES_MAX_KEY_SIZE, [AD]ES_BLOCK_SIZE - why not use them instead?

I wasn't aware of these constants but yes, that's much better.
> 
> > +struct spacc_generic_ctx;
> 
> this declaration isn't used prior to its definition, so it's not needed.

Ok, will remove.

> > +/* DDT format. This must match the hardware DDT format exactly. */
> > +struct spacc_ddt {
> > +     u32 p, len;
> 
> type-consistency: p should be a dma_addr_t

The reason I used a u32 was the the engine descriptor format is two 32 
bit words so I was trying to be explicit but I'll change this to 
dma_addr_t.

> 
> > +     /* AEAD specifc bits. */
> 
> specific

Good spot!

> > +static inline struct spacc_ablk_ctx *
> > +to_spacc_ablk_ctx(struct spacc_generic_ctx *ctx)
> > +{
> > +     return ctx ? container_of(ctx, struct spacc_ablk_ctx, generic) : NULL;
> > +}
> > +
> > +static inline struct spacc_aead_ctx *
> > +to_spacc_aead_ctx(struct spacc_generic_ctx *ctx)
> > +{
> > +     return ctx ? container_of(ctx, struct spacc_aead_ctx, generic) : NULL;
> > +}
> 
> these aren't being used anywhere.

Ok, will remove.

> 
> > +static inline struct spacc_alg *to_spacc_alg(struct crypto_alg *alg);
> 
> define it here - forward declarations should only be necessary when
> dealing with circular dependencies.

Hmm, not sure why I didn't do that originally!  Will change.

> 
> > +/*
> > + * Take a crypto request and scatterlists for the data and turn them into DDTs
> > + * for passing to the crypto engines. This also DMA maps the data so that the
> > + * crypto engines can DMA to/from them.
> > + */
> > +static struct spacc_ddt *spacc_sg_to_ddt(struct spacc_engine *engine,
> > +                                      struct scatterlist *payload,
> > +                                      unsigned nbytes,
> > +                                      enum dma_data_direction dir,
> > +                                      dma_addr_t *ddt_phys)
> > +{
> > +     unsigned nents, mapped_ents;
> > +     struct scatterlist *cur;
> > +     struct spacc_ddt *ddt;
> > +     int i;
> > +
> > +     nents = sg_count(payload, nbytes);
> > +     mapped_ents = dma_map_sg(engine->dev, payload, nents, dir);
> > +
> > +     if (mapped_ents + 1 > MAX_DDT_LEN) {
> > +             dma_unmap_sg(engine->dev, payload, nents, dir);
> > +             return NULL;
> > +     }
> > +
> > +     ddt = dma_pool_alloc(engine->req_pool, GFP_ATOMIC, ddt_phys);
> > +     if (ddt) {
> > +             for_each_sg(payload, cur, mapped_ents, i) {
> > +                     ddt[i].p = sg_dma_address(cur);
> > +                     ddt[i].len = sg_dma_len(cur);
> > +             }
> > +
> > +             ddt[mapped_ents].p = 0;
> > +             ddt[mapped_ents].len = 0;
> > +     } else {
> > +             dma_unmap_sg(engine->dev, payload, nents, dir);
> > +             ddt = NULL;
> > +     }
> > +
> > +     return ddt;
> > +}
> 
> easier to read would be:
> 
>         if (mapped_ents + 1 > MAX_DDT_LEN)
>                 goto out;
> 
>         ddt = dma_pool_alloc(engine->req_pool, GFP_ATOMIC, ddt_phys);
>         if (!ddt)
>                 goto out;
> 
>         for_each_sg(payload, cur, mapped_ents, i) {
>                 ddt[i].p = sg_dma_address(cur);
>                 ddt[i].len = sg_dma_len(cur);
>         }
>         ddt[mapped_ents].p = 0;
>         ddt[mapped_ents].len = 0;
> 
>         return ddt;
> 
> out:
>         dma_unmap_sg(engine->dev, payload, nents, dir);
>         return NULL;
> }
> 
> even more so by moving ddt_set() above it, and then using ddt_set() to
> assign the p, len pairs.

Yes, that's much cleaner.

> 
> > +static inline void ddt_set(struct spacc_ddt *ddt, unsigned long phys,
> 
> phys should be dma_addr_t

Ok.

> 
> > +static int spacc_aead_make_ddts(struct spacc_req *req, u8 *giv)
> > +{
> > +     struct aead_request *areq = container_of(req->req, struct aead_request,
> > +                                              base);
> > +     struct spacc_alg *alg = to_spacc_alg(req->req->tfm->__crt_alg);
> > +     struct spacc_engine *engine = req->engine;
> > +     struct spacc_ddt *src_ddt, *dst_ddt;
> > +     unsigned ivsize = alg->alg.cra_aead.ivsize;
> 
> no need to go through all those hoops to get to the ivsize - use helper
> fns crypto_aead_reqtfm() and crypto_aead_ivsize(), as is done at the
> callsite, or just pass it in from there.

Ok, will do.

> 
> > +static int spacc_aead_des_setkey(struct crypto_aead *aead, const u8 *key,
> > +                              unsigned int len)
> > +{
> > +     struct crypto_tfm *tfm = crypto_aead_tfm(aead);
> > +     struct spacc_aead_ctx *ctx = crypto_tfm_ctx(tfm);
> > +     int err = 0;
> > +     u32 tmp[DES_EXPKEY_WORDS];
> > +
> > +     err = des_ekey(tmp, key);
> > +     if (unlikely(!err) &&
> 
> might want to change the name of the variable err here to something
> like ret or is_weak so as to not mislead the reader.
> 
> > +         (crypto_aead_get_flags(aead)) & CRYPTO_TFM_REQ_WEAK_KEY) {
> > +             tfm->crt_flags |= CRYPTO_TFM_RES_WEAK_KEY;
> > +             return -EINVAL;
> > +     }
> > +     err = 0;
> > +
> > +     memcpy(ctx->cipher_key, key, len);
> > +     ctx->cipher_key_len = len;
> > +
> > +     return err;
> 
> actually, it doesn't look like this fn needs a return variable
> at all.

Ok, I'll get rid of err and put the des_ekey() call into the 
conditional.

> > +/* Set the key for the AES block cipher component of the AEAD 
> > transform. */
> > +static int spacc_aead_aes_setkey(struct crypto_aead *aead, const u8 *key,
> > +                              unsigned int len)
> > +{
> > +     struct crypto_tfm *tfm = crypto_aead_tfm(aead);
> > +     struct spacc_aead_ctx *ctx = crypto_tfm_ctx(tfm);
> > +     int err;
> > +
> > +     /*
> > +      * IPSec engine only supports 128 and 256 bit AES keys. If we get a
> > +      * request for any other size (192 bits) then we need to do a software
> > +      * fallback.
> > +      */
> > +     if (!(16 == len || 32 == len)) {
> 
> if (len != AES_KEYSIZE_128 && len != AES_KEYSIZE_256)

Ok, I'll clean up all of these uses.

> > +             /*
> > +              * Set the fallback transform to use the same request flags as
> > +              * the hardware transform.
> > +              */
> > +             ctx->sw_cipher->base.crt_flags &= ~CRYPTO_TFM_REQ_MASK;
> > +             ctx->sw_cipher->base.crt_flags |=
> > +                     (tfm->crt_flags & CRYPTO_TFM_REQ_MASK);
> 
> parens not needed.

Ok.

> > +             err = crypto_aead_setkey(ctx->sw_cipher, key, len);
> > +     } else {
> > +             memcpy(ctx->cipher_key, key, len);
> > +             ctx->cipher_key_len = len;
> > +             err = 0;
> > +     }
> > +
> > +     return err;
> 
> 	return crypto_aead_setkey(ctx->sw_cipher, key, len);
> }
> memcpy(ctx->cipher_key, key, len);
> ctx->cipher_key_len = len;
> 
> return 0;

Ok.

> > +static int spacc_aead_setkey(struct crypto_aead *tfm, const u8 *key,
> > +                          unsigned int keylen)
> > +{
> > +     struct spacc_aead_ctx *ctx = crypto_aead_ctx(tfm);
> > +     struct spacc_alg *alg = to_spacc_alg(tfm->base.__crt_alg);
> > +     struct rtattr *rta = (void *)key;
> > +     struct crypto_authenc_key_param *param;
> > +     unsigned int authkeylen, enckeylen;
> > +     int err = -EINVAL;
> > +
> > +     if (!RTA_OK(rta, keylen))
> > +             goto badkey;
> > +
> > +     if (rta->rta_type != CRYPTO_AUTHENC_KEYA_PARAM)
> > +             goto badkey;
> > +
> > +     if (RTA_PAYLOAD(rta) < sizeof(*param))
> > +             goto badkey;
> 
> I'm not sure, but it should be safe to remove the above three checks -
> they cause a false badkey failure if the keys aren't within an rtattr
> struct, which, e.g., something like testmgr.c wouldn't do.
> 
> > +     param = RTA_DATA(rta);
> > +     enckeylen = be32_to_cpu(param->enckeylen);
> > +
> > +     key += RTA_ALIGN(rta->rta_len);
> > +     keylen -= RTA_ALIGN(rta->rta_len);
> 
> actually, I doubt crypto drivers should be including rtnetlink.h at
> all...but it's probably ok for now - talitos still does :)

Yes, it doesn't seem the nicest way to pass the keys.  ixp4xx and 
crypto/authenc.c do the same thing (including the first 3 checks).  
Perhaps this is worth refactoring into a generic 
crypto_authenc_get_keys() helper?

> > +     if ((spacc_alg->ctrl_default & SPACC_CRYPTO_ALG_MASK) ==
> > +         SPA_CTRL_CIPH_ALG_AES &&
> > +         !(16 == ctx->cipher_key_len || 32 == ctx->cipher_key_len))
> 
> as above, please use symbolic equivalents

Ok.

> > +static void spacc_aead_complete(struct spacc_req *req)
> > +{
> > +     spacc_aead_free_ddts(req);
> > +
> > +     if (req->req->complete)
> > +             req->req->complete(req->req, req->result);
> 
> when is there not a completion function?

Ok, I'll remove that check.

> > +     /* Set the source and destination DDT pointers. */
> > +     writel((u32)req->src_addr, engine->regs + SPA_SRC_PTR_REG_OFFSET);
> > +     writel((u32)req->dst_addr, engine->regs + SPA_DST_PTR_REG_OFFSET);
> 
> cast necessary?

No, probably not.  I'll double check and remove if ok.

> > +     ctrl = spacc_alg->ctrl_default;
> > +     ctrl |= ((req->ctx_id << SPA_CTRL_CTX_IDX) |
> > +              (1 << SPA_CTRL_ICV_APPEND) |
> > +              (req->is_encrypt ? (1 << SPA_CTRL_ENCRYPT_IDX) : 0) |
> > +              (req->is_encrypt ? (1 << SPA_CTRL_AAD_COPY) : 0));
> > +     if (!req->is_encrypt)
> > +             ctrl |= (1 << SPA_CTRL_KEY_EXP);
> 
> ctrl = spacc_alg->ctrl_default | (req->ctx_id << SPA_CTRL_CTX_IDX) |
>        (1 << SPA_CTRL_ICV_APPEND);
> 
> if (req->is_encrypt)
> 	ctrl |= (1 << SPA_CTRL_ENCRYPT_IDX) | (1 << SPA_CTRL_AAD_COPY);
> else
> 	ctrl |= (1 << SPA_CTRL_KEY_EXP);

Yes, that's nicer.

> > +static int spacc_des_setkey(struct crypto_ablkcipher *cipher, const u8 *key,
> > +                         unsigned int len)
> > +{
> > +     struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
> > +     struct spacc_ablk_ctx *ctx = crypto_tfm_ctx(tfm);
> > +     int err;
> > +     u32 tmp[DES_EXPKEY_WORDS];
> > +
> > +     if (len > SPACC_CRYPTO_AES_MAX_KEY_LEN) {
> 
> AES left overs in a DES setkey

Good spot, will fix.

> > +static int spacc_aes_setkey(struct crypto_ablkcipher *cipher, const u8 *key,
> > +                         unsigned int len)
> > +{
> > +     struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
> > +     struct spacc_ablk_ctx *ctx = crypto_tfm_ctx(tfm);
> > +     int err = 0;
> > +
> > +     if (len > SPACC_CRYPTO_AES_MAX_KEY_LEN) {
> > +             crypto_ablkcipher_set_flags(cipher, CRYPTO_TFM_RES_BAD_KEY_LEN);
> > +             return -EINVAL;
> > +     }
> > +
> > +     /*
> > +      * IPSec engine only supports 128 and 256 bit AES keys. If we get a
> > +      * request for any other size (192 bits) then we need to do a software
> > +      * fallback.
> > +      */
> > +     if (!(16 == len || 32 == len) && ctx->sw_cipher) {
> 
> symbolic constants

Ok.

> > +             /*
> > +              * Set the fallback transform to use the same request flags as
> > +              * the hardware transform.
> > +              */
> > +             ctx->sw_cipher->base.crt_flags &= ~CRYPTO_TFM_REQ_MASK;
> > +             ctx->sw_cipher->base.crt_flags |=
> > +                 (cipher->base.crt_flags & CRYPTO_TFM_REQ_MASK);
> 
> parens not necessary

Ok.

> > +static int spacc_ablk_need_fallback(struct spacc_req *req)
> > +{
> > +     struct spacc_ablk_ctx *ctx;
> > +     struct crypto_tfm *tfm = req->req->tfm;
> > +     struct crypto_alg *alg = req->req->tfm->__crt_alg;
> > +     struct spacc_alg *spacc_alg = to_spacc_alg(alg);
> > +
> > +     ctx = crypto_tfm_ctx(tfm);
> > +
> > +     return (spacc_alg->ctrl_default & SPACC_CRYPTO_ALG_MASK) ==
> > +                     SPA_CTRL_CIPH_ALG_AES &&
> > +             !(16 == ctx->key_len || 32 == ctx->key_len);
> 
> symbolic constants

Ok.

> > +static ssize_t spacc_stat_irq_thresh_store(struct device *dev,
> > +                                        struct device_attribute *attr,
> > +                                        const char *buf, size_t len)
> > +{
> > +     struct spacc_engine *engine = spacc_dev_to_engine(dev);
> > +     unsigned thresh = simple_strtoul(buf, NULL, 0);
> 
> consider using strict_strtoul (checkpatch)

Ok, will change.

> > +static struct spacc_alg ipsec_engine_algs[] = {
> > +     {
> > +             .ctrl_default = SPA_CTRL_CIPH_ALG_AES | SPA_CTRL_CIPH_MODE_CBC,
> > +             .key_offs = 0,
> > +             .iv_offs = SPACC_CRYPTO_AES_MAX_KEY_LEN,
> > +             .alg = {
> > +                     .cra_name = "cbc(aes)",
> > +                     .cra_driver_name = "cbc-aes-picoxcell",
> > +                     .cra_priority = SPACC_CRYPTO_ALG_PRIORITY,
> > +                     .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
> > +                                  CRYPTO_ALG_ASYNC |
> > +                                  CRYPTO_ALG_NEED_FALLBACK,
> > +                     .cra_blocksize = 16,
> 
> symbolic constant, here and throughout the rest of this section.

Ok.

Thanks again for taking the time to review Kim!

Jamie

^ permalink raw reply

* [PATCH] picoxcell_crypto: add support for the picoxcell crypto engines
From: Jamie Iles @ 2011-02-11 11:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20110210220916.aac2b545.kim.phillips@freescale.com>

On Thu, Feb 10, 2011 at 10:09:16PM -0600, Kim Phillips wrote:
> On Tue, 8 Feb 2011 15:56:16 +0000
> Jamie Iles <jamie@jamieiles.com> wrote:
> 
> > Picochip picoXcell devices have two crypto engines, one targeted
> > at IPSEC offload and the other at WCDMA layer 2 ciphering.
> >
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> > ---
> 
> nice driver ;).  Have a couple of comments though.

Hi Kim,

Thanks for the great review!

> 
> > +     help
> > +       This option enables support for the hardware offload engines in the
> > +       Picochip picoXcell SoC devices. Select this for IPSEC ESP offload
> > +       and for 3gpp Layer 2 ciphering support.
> 
> it'd be nice to mention what name the module will have.

Ok, will add.

> 
> > +#define SPACC_CRYPTO_AES_MAX_KEY_LEN 32
> > +#define SPACC_CRYPTO_AES_IV_LEN              16
> > +#define SPACC_CRYPTO_DES_IV_LEN              8
> 
> these are identical to algorithm-generic symbolic constants
> AES_MAX_KEY_SIZE, [AD]ES_BLOCK_SIZE - why not use them instead?

I wasn't aware of these constants but yes, that's much better.
> 
> > +struct spacc_generic_ctx;
> 
> this declaration isn't used prior to its definition, so it's not needed.

Ok, will remove.

> > +/* DDT format. This must match the hardware DDT format exactly. */
> > +struct spacc_ddt {
> > +     u32 p, len;
> 
> type-consistency: p should be a dma_addr_t

The reason I used a u32 was the the engine descriptor format is two 32 
bit words so I was trying to be explicit but I'll change this to 
dma_addr_t.

> 
> > +     /* AEAD specifc bits. */
> 
> specific

Good spot!

> > +static inline struct spacc_ablk_ctx *
> > +to_spacc_ablk_ctx(struct spacc_generic_ctx *ctx)
> > +{
> > +     return ctx ? container_of(ctx, struct spacc_ablk_ctx, generic) : NULL;
> > +}
> > +
> > +static inline struct spacc_aead_ctx *
> > +to_spacc_aead_ctx(struct spacc_generic_ctx *ctx)
> > +{
> > +     return ctx ? container_of(ctx, struct spacc_aead_ctx, generic) : NULL;
> > +}
> 
> these aren't being used anywhere.

Ok, will remove.

> 
> > +static inline struct spacc_alg *to_spacc_alg(struct crypto_alg *alg);
> 
> define it here - forward declarations should only be necessary when
> dealing with circular dependencies.

Hmm, not sure why I didn't do that originally!  Will change.

> 
> > +/*
> > + * Take a crypto request and scatterlists for the data and turn them into DDTs
> > + * for passing to the crypto engines. This also DMA maps the data so that the
> > + * crypto engines can DMA to/from them.
> > + */
> > +static struct spacc_ddt *spacc_sg_to_ddt(struct spacc_engine *engine,
> > +                                      struct scatterlist *payload,
> > +                                      unsigned nbytes,
> > +                                      enum dma_data_direction dir,
> > +                                      dma_addr_t *ddt_phys)
> > +{
> > +     unsigned nents, mapped_ents;
> > +     struct scatterlist *cur;
> > +     struct spacc_ddt *ddt;
> > +     int i;
> > +
> > +     nents = sg_count(payload, nbytes);
> > +     mapped_ents = dma_map_sg(engine->dev, payload, nents, dir);
> > +
> > +     if (mapped_ents + 1 > MAX_DDT_LEN) {
> > +             dma_unmap_sg(engine->dev, payload, nents, dir);
> > +             return NULL;
> > +     }
> > +
> > +     ddt = dma_pool_alloc(engine->req_pool, GFP_ATOMIC, ddt_phys);
> > +     if (ddt) {
> > +             for_each_sg(payload, cur, mapped_ents, i) {
> > +                     ddt[i].p = sg_dma_address(cur);
> > +                     ddt[i].len = sg_dma_len(cur);
> > +             }
> > +
> > +             ddt[mapped_ents].p = 0;
> > +             ddt[mapped_ents].len = 0;
> > +     } else {
> > +             dma_unmap_sg(engine->dev, payload, nents, dir);
> > +             ddt = NULL;
> > +     }
> > +
> > +     return ddt;
> > +}
> 
> easier to read would be:
> 
>         if (mapped_ents + 1 > MAX_DDT_LEN)
>                 goto out;
> 
>         ddt = dma_pool_alloc(engine->req_pool, GFP_ATOMIC, ddt_phys);
>         if (!ddt)
>                 goto out;
> 
>         for_each_sg(payload, cur, mapped_ents, i) {
>                 ddt[i].p = sg_dma_address(cur);
>                 ddt[i].len = sg_dma_len(cur);
>         }
>         ddt[mapped_ents].p = 0;
>         ddt[mapped_ents].len = 0;
> 
>         return ddt;
> 
> out:
>         dma_unmap_sg(engine->dev, payload, nents, dir);
>         return NULL;
> }
> 
> even more so by moving ddt_set() above it, and then using ddt_set() to
> assign the p, len pairs.

Yes, that's much cleaner.

> 
> > +static inline void ddt_set(struct spacc_ddt *ddt, unsigned long phys,
> 
> phys should be dma_addr_t

Ok.

> 
> > +static int spacc_aead_make_ddts(struct spacc_req *req, u8 *giv)
> > +{
> > +     struct aead_request *areq = container_of(req->req, struct aead_request,
> > +                                              base);
> > +     struct spacc_alg *alg = to_spacc_alg(req->req->tfm->__crt_alg);
> > +     struct spacc_engine *engine = req->engine;
> > +     struct spacc_ddt *src_ddt, *dst_ddt;
> > +     unsigned ivsize = alg->alg.cra_aead.ivsize;
> 
> no need to go through all those hoops to get to the ivsize - use helper
> fns crypto_aead_reqtfm() and crypto_aead_ivsize(), as is done at the
> callsite, or just pass it in from there.

Ok, will do.

> 
> > +static int spacc_aead_des_setkey(struct crypto_aead *aead, const u8 *key,
> > +                              unsigned int len)
> > +{
> > +     struct crypto_tfm *tfm = crypto_aead_tfm(aead);
> > +     struct spacc_aead_ctx *ctx = crypto_tfm_ctx(tfm);
> > +     int err = 0;
> > +     u32 tmp[DES_EXPKEY_WORDS];
> > +
> > +     err = des_ekey(tmp, key);
> > +     if (unlikely(!err) &&
> 
> might want to change the name of the variable err here to something
> like ret or is_weak so as to not mislead the reader.
> 
> > +         (crypto_aead_get_flags(aead)) & CRYPTO_TFM_REQ_WEAK_KEY) {
> > +             tfm->crt_flags |= CRYPTO_TFM_RES_WEAK_KEY;
> > +             return -EINVAL;
> > +     }
> > +     err = 0;
> > +
> > +     memcpy(ctx->cipher_key, key, len);
> > +     ctx->cipher_key_len = len;
> > +
> > +     return err;
> 
> actually, it doesn't look like this fn needs a return variable
> at all.

Ok, I'll get rid of err and put the des_ekey() call into the 
conditional.

> > +/* Set the key for the AES block cipher component of the AEAD 
> > transform. */
> > +static int spacc_aead_aes_setkey(struct crypto_aead *aead, const u8 *key,
> > +                              unsigned int len)
> > +{
> > +     struct crypto_tfm *tfm = crypto_aead_tfm(aead);
> > +     struct spacc_aead_ctx *ctx = crypto_tfm_ctx(tfm);
> > +     int err;
> > +
> > +     /*
> > +      * IPSec engine only supports 128 and 256 bit AES keys. If we get a
> > +      * request for any other size (192 bits) then we need to do a software
> > +      * fallback.
> > +      */
> > +     if (!(16 == len || 32 == len)) {
> 
> if (len != AES_KEYSIZE_128 && len != AES_KEYSIZE_256)

Ok, I'll clean up all of these uses.

> > +             /*
> > +              * Set the fallback transform to use the same request flags as
> > +              * the hardware transform.
> > +              */
> > +             ctx->sw_cipher->base.crt_flags &= ~CRYPTO_TFM_REQ_MASK;
> > +             ctx->sw_cipher->base.crt_flags |=
> > +                     (tfm->crt_flags & CRYPTO_TFM_REQ_MASK);
> 
> parens not needed.

Ok.

> > +             err = crypto_aead_setkey(ctx->sw_cipher, key, len);
> > +     } else {
> > +             memcpy(ctx->cipher_key, key, len);
> > +             ctx->cipher_key_len = len;
> > +             err = 0;
> > +     }
> > +
> > +     return err;
> 
> 	return crypto_aead_setkey(ctx->sw_cipher, key, len);
> }
> memcpy(ctx->cipher_key, key, len);
> ctx->cipher_key_len = len;
> 
> return 0;

Ok.

> > +static int spacc_aead_setkey(struct crypto_aead *tfm, const u8 *key,
> > +                          unsigned int keylen)
> > +{
> > +     struct spacc_aead_ctx *ctx = crypto_aead_ctx(tfm);
> > +     struct spacc_alg *alg = to_spacc_alg(tfm->base.__crt_alg);
> > +     struct rtattr *rta = (void *)key;
> > +     struct crypto_authenc_key_param *param;
> > +     unsigned int authkeylen, enckeylen;
> > +     int err = -EINVAL;
> > +
> > +     if (!RTA_OK(rta, keylen))
> > +             goto badkey;
> > +
> > +     if (rta->rta_type != CRYPTO_AUTHENC_KEYA_PARAM)
> > +             goto badkey;
> > +
> > +     if (RTA_PAYLOAD(rta) < sizeof(*param))
> > +             goto badkey;
> 
> I'm not sure, but it should be safe to remove the above three checks -
> they cause a false badkey failure if the keys aren't within an rtattr
> struct, which, e.g., something like testmgr.c wouldn't do.
> 
> > +     param = RTA_DATA(rta);
> > +     enckeylen = be32_to_cpu(param->enckeylen);
> > +
> > +     key += RTA_ALIGN(rta->rta_len);
> > +     keylen -= RTA_ALIGN(rta->rta_len);
> 
> actually, I doubt crypto drivers should be including rtnetlink.h at
> all...but it's probably ok for now - talitos still does :)

Yes, it doesn't seem the nicest way to pass the keys.  ixp4xx and 
crypto/authenc.c do the same thing (including the first 3 checks).  
Perhaps this is worth refactoring into a generic 
crypto_authenc_get_keys() helper?

> > +     if ((spacc_alg->ctrl_default & SPACC_CRYPTO_ALG_MASK) ==
> > +         SPA_CTRL_CIPH_ALG_AES &&
> > +         !(16 == ctx->cipher_key_len || 32 == ctx->cipher_key_len))
> 
> as above, please use symbolic equivalents

Ok.

> > +static void spacc_aead_complete(struct spacc_req *req)
> > +{
> > +     spacc_aead_free_ddts(req);
> > +
> > +     if (req->req->complete)
> > +             req->req->complete(req->req, req->result);
> 
> when is there not a completion function?

Ok, I'll remove that check.

> > +     /* Set the source and destination DDT pointers. */
> > +     writel((u32)req->src_addr, engine->regs + SPA_SRC_PTR_REG_OFFSET);
> > +     writel((u32)req->dst_addr, engine->regs + SPA_DST_PTR_REG_OFFSET);
> 
> cast necessary?

No, probably not.  I'll double check and remove if ok.

> > +     ctrl = spacc_alg->ctrl_default;
> > +     ctrl |= ((req->ctx_id << SPA_CTRL_CTX_IDX) |
> > +              (1 << SPA_CTRL_ICV_APPEND) |
> > +              (req->is_encrypt ? (1 << SPA_CTRL_ENCRYPT_IDX) : 0) |
> > +              (req->is_encrypt ? (1 << SPA_CTRL_AAD_COPY) : 0));
> > +     if (!req->is_encrypt)
> > +             ctrl |= (1 << SPA_CTRL_KEY_EXP);
> 
> ctrl = spacc_alg->ctrl_default | (req->ctx_id << SPA_CTRL_CTX_IDX) |
>        (1 << SPA_CTRL_ICV_APPEND);
> 
> if (req->is_encrypt)
> 	ctrl |= (1 << SPA_CTRL_ENCRYPT_IDX) | (1 << SPA_CTRL_AAD_COPY);
> else
> 	ctrl |= (1 << SPA_CTRL_KEY_EXP);

Yes, that's nicer.

> > +static int spacc_des_setkey(struct crypto_ablkcipher *cipher, const u8 *key,
> > +                         unsigned int len)
> > +{
> > +     struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
> > +     struct spacc_ablk_ctx *ctx = crypto_tfm_ctx(tfm);
> > +     int err;
> > +     u32 tmp[DES_EXPKEY_WORDS];
> > +
> > +     if (len > SPACC_CRYPTO_AES_MAX_KEY_LEN) {
> 
> AES left overs in a DES setkey

Good spot, will fix.

> > +static int spacc_aes_setkey(struct crypto_ablkcipher *cipher, const u8 *key,
> > +                         unsigned int len)
> > +{
> > +     struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher);
> > +     struct spacc_ablk_ctx *ctx = crypto_tfm_ctx(tfm);
> > +     int err = 0;
> > +
> > +     if (len > SPACC_CRYPTO_AES_MAX_KEY_LEN) {
> > +             crypto_ablkcipher_set_flags(cipher, CRYPTO_TFM_RES_BAD_KEY_LEN);
> > +             return -EINVAL;
> > +     }
> > +
> > +     /*
> > +      * IPSec engine only supports 128 and 256 bit AES keys. If we get a
> > +      * request for any other size (192 bits) then we need to do a software
> > +      * fallback.
> > +      */
> > +     if (!(16 == len || 32 == len) && ctx->sw_cipher) {
> 
> symbolic constants

Ok.

> > +             /*
> > +              * Set the fallback transform to use the same request flags as
> > +              * the hardware transform.
> > +              */
> > +             ctx->sw_cipher->base.crt_flags &= ~CRYPTO_TFM_REQ_MASK;
> > +             ctx->sw_cipher->base.crt_flags |=
> > +                 (cipher->base.crt_flags & CRYPTO_TFM_REQ_MASK);
> 
> parens not necessary

Ok.

> > +static int spacc_ablk_need_fallback(struct spacc_req *req)
> > +{
> > +     struct spacc_ablk_ctx *ctx;
> > +     struct crypto_tfm *tfm = req->req->tfm;
> > +     struct crypto_alg *alg = req->req->tfm->__crt_alg;
> > +     struct spacc_alg *spacc_alg = to_spacc_alg(alg);
> > +
> > +     ctx = crypto_tfm_ctx(tfm);
> > +
> > +     return (spacc_alg->ctrl_default & SPACC_CRYPTO_ALG_MASK) ==
> > +                     SPA_CTRL_CIPH_ALG_AES &&
> > +             !(16 == ctx->key_len || 32 == ctx->key_len);
> 
> symbolic constants

Ok.

> > +static ssize_t spacc_stat_irq_thresh_store(struct device *dev,
> > +                                        struct device_attribute *attr,
> > +                                        const char *buf, size_t len)
> > +{
> > +     struct spacc_engine *engine = spacc_dev_to_engine(dev);
> > +     unsigned thresh = simple_strtoul(buf, NULL, 0);
> 
> consider using strict_strtoul (checkpatch)

Ok, will change.

> > +static struct spacc_alg ipsec_engine_algs[] = {
> > +     {
> > +             .ctrl_default = SPA_CTRL_CIPH_ALG_AES | SPA_CTRL_CIPH_MODE_CBC,
> > +             .key_offs = 0,
> > +             .iv_offs = SPACC_CRYPTO_AES_MAX_KEY_LEN,
> > +             .alg = {
> > +                     .cra_name = "cbc(aes)",
> > +                     .cra_driver_name = "cbc-aes-picoxcell",
> > +                     .cra_priority = SPACC_CRYPTO_ALG_PRIORITY,
> > +                     .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
> > +                                  CRYPTO_ALG_ASYNC |
> > +                                  CRYPTO_ALG_NEED_FALLBACK,
> > +                     .cra_blocksize = 16,
> 
> symbolic constant, here and throughout the rest of this section.

Ok.

Thanks again for taking the time to review Kim!

Jamie

^ permalink raw reply

* Re: xen-unstable on OL6 (RHEL6 clone) problems
From: Ian Campbell @ 2011-02-11 11:57 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: Todd Deshane, xen-devel@lists.xensource.com, Dan Magenheimer,
	Fajar A. Nugraha
In-Reply-To: <alpine.DEB.2.00.1102111143210.2826@kaball-desktop>

On Fri, 2011-02-11 at 11:44 +0000, Stefano Stabellini wrote:
> On Fri, 11 Feb 2011, Ian Campbell wrote:
> > On Fri, 2011-02-11 at 03:09 +0000, Todd Deshane wrote: 
> > > On Thu, Feb 10, 2011 at 12:56 PM, Stefano Stabellini
> > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > On Thu, 10 Feb 2011, Dan Magenheimer wrote:
> > > >> Is this commented out and easy to turn on?  Or maybe it's NOT
> > > >> commented out and is causing the breakage I am seeing?
> > > >
> > > > The script is still installed but nobody is calling it.
> > > > If you are using xl you need to add
> > > >
> > > > /etc/xen/scripts/network-bridge start
> > > >
> > > > somewhere in your init scripts.
> > > 
> > > With xl you need to do this?
> > > So like in /etc/rc.local?
> > 
> > This is a quick and dirty hack which brings back the old xend solution,
> > with all the brokenness and caveats described in IanJ's mail from last
> > night (it's worse than the previous xend solution if anything).
> > 
> > We should _not_ be recommending to users that they do this. Stefano,
> > please do not muddy the waters for people trying to upgrade by doing so.
> 
> In no way I meant to recommend this option to the users, but it might be
> worth mentioning it in the wiki.

I don't think so.

The wiki should contains a clear statement of the correct and
recommended best practice.

The only thing worse for users than making a change like this and
failing to adequately document it would be to make a change and then
document it with a set of inconsistent and incompatible recommendations.

Ian.

^ permalink raw reply

* Re: [PATCH] Big endian support for RV730
From: Cédric Cano @ 2011-02-11  9:54 UTC (permalink / raw)
  To: dri-devel
In-Reply-To: <4D5506CE.1080501@ic.fr>

Signed-off-by: Cedric Cano <ccano at interfaceconcept.com>
---
diff -Naur linux-2.6.35.6/drivers/gpu/drm/radeon/atombios_crtc.c 
linux-2.6.35.6/drivers/gpu/drm/radeon/atombios_crtc.c
--- linux-2.6.35.6/drivers/gpu/drm/radeon/atombios_crtc.c    2010-09-27 
02:19:16.000000000 +0200
+++ linux-2.6.35.6/drivers/gpu/drm/radeon/atombios_crtc.c    2011-01-27 
15:03:46.000000000 +0100
@@ -808,6 +808,7 @@
      struct radeon_bo *rbo;
      uint64_t fb_location;
      uint32_t fb_format, fb_pitch_pixels, tiling_flags;
+    u32 fb_swap = EVERGREEN_GRPH_ENDIAN_SWAP(EVERGREEN_GRPH_ENDIAN_NONE);
      int r;

      /* no fb bound */
@@ -844,11 +845,17 @@
      case 16:
          fb_format = (EVERGREEN_GRPH_DEPTH(EVERGREEN_GRPH_DEPTH_16BPP) |
                   EVERGREEN_GRPH_FORMAT(EVERGREEN_GRPH_FORMAT_ARGB565));
+#ifdef __BIG_ENDIAN
+        fb_swap = EVERGREEN_GRPH_ENDIAN_SWAP(EVERGREEN_GRPH_ENDIAN_8IN16);
+#endif
          break;
      case 24:
      case 32:
          fb_format = (EVERGREEN_GRPH_DEPTH(EVERGREEN_GRPH_DEPTH_32BPP) |
                   EVERGREEN_GRPH_FORMAT(EVERGREEN_GRPH_FORMAT_ARGB8888));
+#ifdef __BIG_ENDIAN
+        fb_swap = EVERGREEN_GRPH_ENDIAN_SWAP(EVERGREEN_GRPH_ENDIAN_8IN32);
+#endif
          break;
      default:
          DRM_ERROR("Unsupported screen depth %d\n",
@@ -888,6 +895,7 @@
      WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS + 
radeon_crtc->crtc_offset,
             (u32) fb_location & EVERGREEN_GRPH_SURFACE_ADDRESS_MASK);
      WREG32(EVERGREEN_GRPH_CONTROL + radeon_crtc->crtc_offset, fb_format);
+    WREG32(EVERGREEN_GRPH_SWAP_CONTROL + radeon_crtc->crtc_offset, 
fb_swap);

      WREG32(EVERGREEN_GRPH_SURFACE_OFFSET_X + radeon_crtc->crtc_offset, 0);
      WREG32(EVERGREEN_GRPH_SURFACE_OFFSET_Y + radeon_crtc->crtc_offset, 0);
@@ -942,6 +950,7 @@
      struct radeon_bo *rbo;
      uint64_t fb_location;
      uint32_t fb_format, fb_pitch_pixels, tiling_flags;
+    u32 fb_swap = R600_D1GRPH_SWAP_ENDIAN_NONE;
      int r;

      /* no fb bound */
@@ -981,12 +990,18 @@
          fb_format =
              AVIVO_D1GRPH_CONTROL_DEPTH_16BPP |
              AVIVO_D1GRPH_CONTROL_16BPP_RGB565;
+#ifdef __BIG_ENDIAN
+        fb_swap = R600_D1GRPH_SWAP_ENDIAN_16BIT;
+#endif
          break;
      case 24:
      case 32:
          fb_format =
              AVIVO_D1GRPH_CONTROL_DEPTH_32BPP |
              AVIVO_D1GRPH_CONTROL_32BPP_ARGB8888;
+#ifdef __BIG_ENDIAN
+        fb_swap = R600_D1GRPH_SWAP_ENDIAN_32BIT;
+#endif
          break;
      default:
          DRM_ERROR("Unsupported screen depth %d\n",
@@ -1019,6 +1034,8 @@
      WREG32(AVIVO_D1GRPH_SECONDARY_SURFACE_ADDRESS +
             radeon_crtc->crtc_offset, (u32) fb_location);
      WREG32(AVIVO_D1GRPH_CONTROL + radeon_crtc->crtc_offset, fb_format);
+    if (rdev->family >= CHIP_R600)
+        WREG32(R600_D1GRPH_SWAP_CONTROL + radeon_crtc->crtc_offset, 
fb_swap);

      WREG32(AVIVO_D1GRPH_SURFACE_OFFSET_X + radeon_crtc->crtc_offset, 0);
      WREG32(AVIVO_D1GRPH_SURFACE_OFFSET_Y + radeon_crtc->crtc_offset, 0);
diff -Naur linux-2.6.35.6/drivers/gpu/drm/radeon/r600_blit.c 
linux-2.6.35.6/drivers/gpu/drm/radeon/r600_blit.c
--- linux-2.6.35.6/drivers/gpu/drm/radeon/r600_blit.c    2010-09-27 
02:19:16.000000000 +0200
+++ linux-2.6.35.6/drivers/gpu/drm/radeon/r600_blit.c    2011-02-10 
10:25:32.000000000 +0100
@@ -53,7 +53,9 @@
      if (h < 8)
          h = 8;

-    cb_color_info = ((format << 2) | (1 << 27));
+    cb_color_info = (0 |
+        (format << 2) |
+        (1 << 27));
      pitch = (w / 8) - 1;
      slice = ((w * h) / 64) - 1;

@@ -137,9 +139,9 @@
      ps = (u32 *) ((char *)dev->agp_buffer_map->handle + 
dev_priv->blit_vb->offset + 256);

      for (i = 0; i < r6xx_vs_size; i++)
-        vs[i] = r6xx_vs[i];
+        vs[i] = cpu_to_le32(r6xx_vs[i]);
      for (i = 0; i < r6xx_ps_size; i++)
-        ps[i] = r6xx_ps[i];
+        ps[i] = cpu_to_le32(r6xx_ps[i]);

      dev_priv->blit_vb->used = 512;

@@ -191,7 +193,12 @@
      RING_LOCALS;
      DRM_DEBUG("\n");

-    sq_vtx_constant_word2 = (((gpu_addr >> 32) & 0xff) | (16 << 8));
+    sq_vtx_constant_word2 = (0 |
+#ifdef __BIG_ENDIAN
+        (2 << 30) |
+#endif
+        ((gpu_addr >> 32) & 0xff) |
+        (16 << 8));

      BEGIN_RING(9);
      OUT_RING(CP_PACKET3(R600_IT_SET_RESOURCE, 7));
@@ -235,7 +242,8 @@
      sq_tex_resource_word1 = (format << 26);
      sq_tex_resource_word1 |= ((h - 1) << 0);

-    sq_tex_resource_word4 = ((1 << 14) |
+    sq_tex_resource_word4 = (0 |
+                 (1 << 14) |
                   (0 << 16) |
                   (1 << 19) |
                   (2 << 22) |
@@ -291,7 +299,11 @@
      OUT_RING(DI_PT_RECTLIST);

      OUT_RING(CP_PACKET3(R600_IT_INDEX_TYPE, 0));
+#ifdef __BIG_ENDIAN
+    OUT_RING((2 << 2) | DI_INDEX_SIZE_16_BIT);
+#else
      OUT_RING(DI_INDEX_SIZE_16_BIT);
+#endif

      OUT_RING(CP_PACKET3(R600_IT_NUM_INSTANCES, 0));
      OUT_RING(1);
diff -Naur linux-2.6.35.6/drivers/gpu/drm/radeon/r600_blit_kms.c 
linux-2.6.35.6/drivers/gpu/drm/radeon/r600_blit_kms.c
--- linux-2.6.35.6/drivers/gpu/drm/radeon/r600_blit_kms.c    2010-09-27 
02:19:16.000000000 +0200
+++ linux-2.6.35.6/drivers/gpu/drm/radeon/r600_blit_kms.c    2011-02-10 
10:25:43.000000000 +0100
@@ -29,7 +29,9 @@
      if (h < 8)
          h = 8;

-    cb_color_info = ((format << 2) | (1 << 27));
+    cb_color_info = (0 |
+            (format << 2) |
+            (1 << 27));
      pitch = (w / 8) - 1;
      slice = ((w * h) / 64) - 1;

@@ -139,7 +141,12 @@
  {
      u32 sq_vtx_constant_word2;

-    sq_vtx_constant_word2 = ((upper_32_bits(gpu_addr) & 0xff) | (16 << 8));
+    sq_vtx_constant_word2 = (0 |
+#ifdef __BIG_ENDIAN
+            (2 << 30) |
+#endif
+            (upper_32_bits(gpu_addr) & 0xff) |
+            (16 << 8));

      radeon_ring_write(rdev, PACKET3(PACKET3_SET_RESOURCE, 7));
      radeon_ring_write(rdev, 0x460);
@@ -181,7 +188,8 @@
      sq_tex_resource_word1 = (format << 26);
      sq_tex_resource_word1 |= ((h - 1) << 0);

-    sq_tex_resource_word4 = ((1 << 14) |
+    sq_tex_resource_word4 = (0 |
+                 (1 << 14) |
                   (0 << 16) |
                   (1 << 19) |
                   (2 << 22) |
@@ -228,7 +236,11 @@
      radeon_ring_write(rdev, DI_PT_RECTLIST);

      radeon_ring_write(rdev, PACKET3(PACKET3_INDEX_TYPE, 0));
+#ifdef __BIG_ENDIAN
+    radeon_ring_write(rdev, (2 << 2) | DI_INDEX_SIZE_16_BIT);
+#else
      radeon_ring_write(rdev, DI_INDEX_SIZE_16_BIT);
+#endif

      radeon_ring_write(rdev, PACKET3(PACKET3_NUM_INSTANCES, 0));
      radeon_ring_write(rdev, 1);
@@ -399,7 +411,11 @@
      dwords = ALIGN(rdev->r600_blit.state_len, 0x10);
      gpu_addr = rdev->r600_blit.shader_gpu_addr + 
rdev->r600_blit.state_offset;
      radeon_ring_write(rdev, PACKET3(PACKET3_INDIRECT_BUFFER, 2));
+#ifdef __BIG_ENDIAN
+    radeon_ring_write(rdev, (gpu_addr & 0xFFFFFFFC) | (2 << 0));
+#else
      radeon_ring_write(rdev, gpu_addr & 0xFFFFFFFC);
+#endif
      radeon_ring_write(rdev, upper_32_bits(gpu_addr) & 0xFF);
      radeon_ring_write(rdev, dwords);

@@ -442,7 +458,7 @@
  int r600_blit_init(struct radeon_device *rdev)
  {
      u32 obj_size;
-    int r, dwords;
+    int i, r, dwords;
      void *ptr;
      u32 packet2s[16];
      int num_packet2s = 0;
@@ -460,7 +476,7 @@

      dwords = rdev->r600_blit.state_len;
      while (dwords & 0xf) {
-        packet2s[num_packet2s++] = PACKET2(0);
+        packet2s[num_packet2s++] = cpu_to_le32(PACKET2(0));
          dwords++;
      }

@@ -503,8 +519,12 @@
      if (num_packet2s)
          memcpy_toio(ptr + rdev->r600_blit.state_offset + 
(rdev->r600_blit.state_len * 4),
                  packet2s, num_packet2s * 4);
-    memcpy(ptr + rdev->r600_blit.vs_offset, r6xx_vs, r6xx_vs_size * 4);
-    memcpy(ptr + rdev->r600_blit.ps_offset, r6xx_ps, r6xx_ps_size * 4);
+    for(i = 0; i < r6xx_vs_size; i++) {
+        *(u32 *)((unsigned long)ptr + rdev->r600_blit.vs_offset + i * 
4) = cpu_to_le32(r6xx_vs[i]);
+    }
+    for(i = 0; i < r6xx_ps_size; i++) {
+        *(u32 *)((unsigned long)ptr + rdev->r600_blit.ps_offset + i * 
4) = cpu_to_le32(r6xx_ps[i]);
+    }
      radeon_bo_kunmap(rdev->r600_blit.shader_obj);
      radeon_bo_unreserve(rdev->r600_blit.shader_obj);
      return 0;
diff -Naur linux-2.6.35.6/drivers/gpu/drm/radeon/r600_blit_shaders.c 
linux-2.6.35.6/drivers/gpu/drm/radeon/r600_blit_shaders.c
--- linux-2.6.35.6/drivers/gpu/drm/radeon/r600_blit_shaders.c   
  2010-09-27 02:19:16.000000000 +0200
+++ linux-2.6.35.6/drivers/gpu/drm/radeon/r600_blit_shaders.c   
  2011-01-27 15:09:59.000000000 +0100
@@ -1075,7 +1075,11 @@
      0x00000000,
      0x3c000000,
      0x68cd1000,
+#ifdef __BIG_ENDIAN
+    0x000a0000,
+#else
      0x00080000,
+#endif
      0x00000000,
  };

diff -Naur linux-2.6.35.6/drivers/gpu/drm/radeon/r600.c 
linux-2.6.35.6/drivers/gpu/drm/radeon/r600.c
--- linux-2.6.35.6/drivers/gpu/drm/radeon/r600.c    2010-09-27 
02:19:16.000000000 +0200
+++ linux-2.6.35.6/drivers/gpu/drm/radeon/r600.c    2011-02-09 
11:31:24.000000000 +0100
@@ -2064,7 +2064,11 @@

      r600_cp_stop(rdev);

-    WREG32(CP_RB_CNTL, RB_NO_UPDATE | RB_BLKSZ(15) | RB_BUFSZ(3));
+    WREG32(CP_RB_CNTL,
+#ifdef __BIG_ENDIAN
+        BUF_SWAP_32BIT |
+#endif
+        RB_NO_UPDATE | RB_BLKSZ(15) | RB_BUFSZ(3));

      /* Reset cp */
      WREG32(GRBM_SOFT_RESET, SOFT_RESET_CP);
@@ -2149,7 +2153,11 @@
      WREG32(CP_RB_CNTL, tmp | RB_RPTR_WR_ENA);
      WREG32(CP_RB_RPTR_WR, 0);
      WREG32(CP_RB_WPTR, 0);
-    WREG32(CP_RB_RPTR_ADDR, rdev->cp.gpu_addr & 0xFFFFFFFF);
+#ifdef __BIG_ENDIAN
+    WREG32(CP_RB_RPTR_ADDR, (rdev->cp.gpu_addr & 0xFFFFFFFC) | (2 << 0));
+#else
+    WREG32(CP_RB_RPTR_ADDR, rdev->cp.gpu_addr & 0xFFFFFFFC);
+#endif
      WREG32(CP_RB_RPTR_ADDR_HI, upper_32_bits(rdev->cp.gpu_addr));
      mdelay(1);
      WREG32(CP_RB_CNTL, tmp);
@@ -2306,7 +2314,11 @@
          }
      }
      WREG32(SCRATCH_ADDR, (rdev->wb.gpu_addr >> 8) & 0xFFFFFFFF);
+#ifdef __BIG_ENDIAN
+    WREG32(CP_RB_RPTR_ADDR, ((rdev->wb.gpu_addr + 1024) & 0xFFFFFFFC) | 
(2 << 0));
+#else
      WREG32(CP_RB_RPTR_ADDR, (rdev->wb.gpu_addr + 1024) & 0xFFFFFFFC);
+#endif
      WREG32(CP_RB_RPTR_ADDR_HI, upper_32_bits(rdev->wb.gpu_addr + 1024) 
& 0xFF);
      WREG32(SCRATCH_UMSK, 0xff);
      return 0;
@@ -2661,7 +2673,11 @@
  {
      /* FIXME: implement */
      radeon_ring_write(rdev, PACKET3(PACKET3_INDIRECT_BUFFER, 2));
+#ifdef __BIG_ENDIAN
+    radeon_ring_write(rdev, (ib->gpu_addr & 0xFFFFFFFC) | (2 << 0));
+#else
      radeon_ring_write(rdev, ib->gpu_addr & 0xFFFFFFFC);
+#endif
      radeon_ring_write(rdev, upper_32_bits(ib->gpu_addr) & 0xFF);
      radeon_ring_write(rdev, ib->length_dw);
  }
@@ -3316,8 +3332,8 @@
      while (rptr != wptr) {
          /* wptr/rptr are in bytes! */
          ring_index = rptr / 4;
-        src_id =  rdev->ih.ring[ring_index] & 0xff;
-        src_data = rdev->ih.ring[ring_index + 1] & 0xfffffff;
+        src_id =  readl(rdev->ih.ring + ring_index) & 0xff;
+        src_data = readl(rdev->ih.ring + ring_index + 1) & 0xfffffff;

          switch (src_id) {
          case 1: /* D1 vblank/vline */
diff -Naur linux-2.6.35.6/drivers/gpu/drm/radeon/r600_cp.c 
linux-2.6.35.6/drivers/gpu/drm/radeon/r600_cp.c
--- linux-2.6.35.6/drivers/gpu/drm/radeon/r600_cp.c    2010-09-27 
02:19:16.000000000 +0200
+++ linux-2.6.35.6/drivers/gpu/drm/radeon/r600_cp.c    2011-01-27 
14:29:01.000000000 +0100
@@ -396,6 +396,9 @@
      r600_do_cp_stop(dev_priv);

      RADEON_WRITE(R600_CP_RB_CNTL,
+#ifdef __BIG_ENDIAN
+             RADEON_BUF_SWAP_32BIT |
+#endif
               R600_RB_NO_UPDATE |
               R600_RB_BLKSZ(15) |
               R600_RB_BUFSZ(3));
@@ -486,6 +489,9 @@
      r600_do_cp_stop(dev_priv);

      RADEON_WRITE(R600_CP_RB_CNTL,
+#ifdef __BIG_ENDIAN
+             RADEON_BUF_SWAP_32BIT |
+#endif
               R600_RB_NO_UPDATE |
               (15 << 8) |
               (3 << 0));
@@ -550,7 +556,11 @@

      if (!dev_priv->writeback_works) {
          /* Disable writeback to avoid unnecessary bus master transfer */
-        RADEON_WRITE(R600_CP_RB_CNTL, RADEON_READ(R600_CP_RB_CNTL) |
+        RADEON_WRITE(R600_CP_RB_CNTL,
+#ifdef __BIG_ENDIAN
+                RADEON_BUF_SWAP_32BIT |
+#endif
+                 RADEON_READ(R600_CP_RB_CNTL) |
                   RADEON_RB_NO_UPDATE);
          RADEON_WRITE(R600_SCRATCH_UMSK, 0);
      }
@@ -575,7 +585,11 @@

      RADEON_WRITE(R600_CP_RB_WPTR_DELAY, 0);
      cp_rb_cntl = RADEON_READ(R600_CP_RB_CNTL);
-    RADEON_WRITE(R600_CP_RB_CNTL, R600_RB_RPTR_WR_ENA);
+    RADEON_WRITE(R600_CP_RB_CNTL,
+#ifdef __BIG_ENDIAN
+        RADEON_BUF_SWAP_32BIT |
+#endif
+        R600_RB_RPTR_WR_ENA);

      RADEON_WRITE(R600_CP_RB_RPTR_WR, cp_ptr);
      RADEON_WRITE(R600_CP_RB_WPTR, cp_ptr);
@@ -1838,7 +1852,10 @@
              + dev_priv->gart_vm_start;
      }
      RADEON_WRITE(R600_CP_RB_RPTR_ADDR,
-             rptr_addr & 0xffffffff);
+#ifdef __BIG_ENDIAN
+             (2 << 0) |
+#endif
+             (rptr_addr & 0xfffffffc));
      RADEON_WRITE(R600_CP_RB_RPTR_ADDR_HI,
               upper_32_bits(rptr_addr));

@@ -1889,7 +1906,7 @@
      {
          u64 scratch_addr;

-        scratch_addr = RADEON_READ(R600_CP_RB_RPTR_ADDR);
+        scratch_addr = RADEON_READ(R600_CP_RB_RPTR_ADDR) & 0xFFFFFFFC;
          scratch_addr |= ((u64)RADEON_READ(R600_CP_RB_RPTR_ADDR_HI)) << 32;
          scratch_addr += R600_SCRATCH_REG_OFFSET;
          scratch_addr >>= 8;
diff -Naur linux-2.6.35.6/drivers/gpu/drm/radeon/r600_reg.h 
linux-2.6.35.6/drivers/gpu/drm/radeon/r600_reg.h
--- linux-2.6.35.6/drivers/gpu/drm/radeon/r600_reg.h    2010-09-27 
02:19:16.000000000 +0200
+++ linux-2.6.35.6/drivers/gpu/drm/radeon/r600_reg.h    2011-01-27 
15:05:50.000000000 +0100
@@ -81,7 +81,11 @@
  #define R600_MEDIUM_VID_LOWER_GPIO_CNTL                            0x720
  #define R600_LOW_VID_LOWER_GPIO_CNTL                               0x724

-
+#define R600_D1GRPH_SWAP_CONTROL                               0x610C
+#       define R600_D1GRPH_SWAP_ENDIAN_NONE                    (0 << 0)
+#       define R600_D1GRPH_SWAP_ENDIAN_16BIT                   (1 << 0)
+#       define R600_D1GRPH_SWAP_ENDIAN_32BIT                   (2 << 0)
+#       define R600_D1GRPH_SWAP_ENDIAN_64BIT                   (3 << 0)

  #define R600_HDP_NONSURFACE_BASE                                0x2c04

diff -Naur linux-2.6.35.6/drivers/gpu/drm/radeon/radeon_atombios.c 
linux-2.6.35.6/drivers/gpu/drm/radeon/radeon_atombios.c
--- linux-2.6.35.6/drivers/gpu/drm/radeon/radeon_atombios.c   
  2010-09-27 02:19:16.000000000 +0200
+++ linux-2.6.35.6/drivers/gpu/drm/radeon/radeon_atombios.c   
  2011-01-27 16:08:53.000000000 +0100
@@ -147,7 +147,7 @@
              pin = &gpio_info->asGPIO_Pin[i];
              if (id == pin->ucGPIO_ID) {
                  gpio.id = pin->ucGPIO_ID;
-                gpio.reg = pin->usGpioPin_AIndex * 4;
+                gpio.reg = le16_to_cpu(pin->usGpioPin_AIndex) * 4;
                  gpio.mask = (1 << pin->ucGpioPinBitShift);
                  gpio.valid = true;
                  break;
@@ -1795,7 +1795,7 @@
                  firmware_info =
                      (union firmware_info 
*)(mode_info->atom_context->bios +
                                  fw_data_offset);
-                vddc = firmware_info->info_14.usBootUpVDDCVoltage;
+                vddc = 
le16_to_cpu(firmware_info->info_14.usBootUpVDDCVoltage);
              }

              /* add the i2c bus for thermal/fan chip */
@@ -1882,7 +1882,7 @@
                         
  rdev->pm.power_state[state_index].clock_info[mode_index].voltage.type =
                              VOLTAGE_SW;
                         
  rdev->pm.power_state[state_index].clock_info[mode_index].voltage.voltage =
-                            clock_info->usVDDC;
+                            le16_to_cpu(clock_info->usVDDC);
                          /* XXX usVDDCI */
                          mode_index++;
                      } else {
@@ -1906,7 +1906,7 @@
                         
  rdev->pm.power_state[state_index].clock_info[mode_index].voltage.type =
                              VOLTAGE_SW;
                         
  rdev->pm.power_state[state_index].clock_info[mode_index].voltage.voltage =
-                            clock_info->usVDDC;
+                            le16_to_cpu(clock_info->usVDDC);
                          mode_index++;
                      }
                  }
@@ -2011,7 +2011,7 @@
      int index = GetIndexIntoMasterTable(COMMAND, GetEngineClock);

      atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t 
*)&args);
-    return args.ulReturnEngineClock;
+    return le32_to_cpu(args.ulReturnEngineClock);
  }

  uint32_t radeon_atom_get_memory_clock(struct radeon_device *rdev)
@@ -2020,7 +2020,7 @@
      int index = GetIndexIntoMasterTable(COMMAND, GetMemoryClock);

      atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t 
*)&args);
-    return args.ulReturnMemoryClock;
+    return le32_to_cpu(args.ulReturnMemoryClock);
  }

  void radeon_atom_set_engine_clock(struct radeon_device *rdev,
@@ -2029,7 +2029,7 @@
      SET_ENGINE_CLOCK_PS_ALLOCATION args;
      int index = GetIndexIntoMasterTable(COMMAND, SetEngineClock);

-    args.ulTargetEngineClock = eng_clock;    /* 10 khz */
+    args.ulTargetEngineClock = cpu_to_le32(eng_clock);    /* 10 khz */

      atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t 
*)&args);
  }
@@ -2043,7 +2043,7 @@
      if (rdev->flags & RADEON_IS_IGP)
          return;

-    args.ulTargetMemoryClock = mem_clock;    /* 10 khz */
+    args.ulTargetMemoryClock = cpu_to_le32(mem_clock);    /* 10 khz */

      atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t 
*)&args);
  }
diff -Naur linux-2.6.35.6/drivers/gpu/drm/radeon/radeon_cp.c 
linux-2.6.35.6/drivers/gpu/drm/radeon/radeon_cp.c
--- linux-2.6.35.6/drivers/gpu/drm/radeon/radeon_cp.c    2010-09-27 
02:19:16.000000000 +0200
+++ linux-2.6.35.6/drivers/gpu/drm/radeon/radeon_cp.c    2011-01-27 
14:20:06.000000000 +0100
@@ -911,8 +911,11 @@

      if (!dev_priv->writeback_works) {
          /* Disable writeback to avoid unnecessary bus master transfer */
-        RADEON_WRITE(RADEON_CP_RB_CNTL, RADEON_READ(RADEON_CP_RB_CNTL) |
-                 RADEON_RB_NO_UPDATE);
+        RADEON_WRITE(RADEON_CP_RB_CNTL,
+#ifdef __BIG_ENDIAN
+            RADEON_BUF_SWAP_32BIT |
+#endif
+            RADEON_READ(RADEON_CP_RB_CNTL) | RADEON_RB_NO_UPDATE);
          RADEON_WRITE(RADEON_SCRATCH_UMSK, 0);
      }
  }
diff -Naur linux-2.6.35.6/drivers/gpu/drm/radeon/rv770.c 
linux-2.6.35.6/drivers/gpu/drm/radeon/rv770.c
--- linux-2.6.35.6/drivers/gpu/drm/radeon/rv770.c    2010-09-27 
02:19:16.000000000 +0200
+++ linux-2.6.35.6/drivers/gpu/drm/radeon/rv770.c    2011-01-27 
14:52:04.000000000 +0100
@@ -264,7 +264,11 @@
          return -EINVAL;

      r700_cp_stop(rdev);
-    WREG32(CP_RB_CNTL, RB_NO_UPDATE | (15 << 8) | (3 << 0));
+    WREG32(CP_RB_CNTL,
+#ifdef __BIG_ENDIAN
+        BUF_SWAP_32BIT |
+#endif
+        RB_NO_UPDATE | (15 << 8) | (3 << 0));

      /* Reset cp */
      WREG32(GRBM_SOFT_RESET, SOFT_RESET_CP);
@@ -1114,6 +1118,8 @@
   * should also allow to remove a bunch of callback function
   * like vram_info.
   */
+extern int r600_debugfs_mc_info_init(struct radeon_device *rdev);
+
  int rv770_init(struct radeon_device *rdev)
  {
      int r;
@@ -1121,6 +1127,9 @@
      r = radeon_dummy_page_init(rdev);
      if (r)
          return r;
+    if (r600_debugfs_mc_info_init(rdev)) {
+        DRM_ERROR("Failed to register debugfs file for mc !\n");
+    }
      /* This don't do much */
      r = radeon_gem_init(rdev);
      if (r)

^ permalink raw reply

* Re: Data corruption problem
From: Jeff Layton @ 2011-02-11 11:53 UTC (permalink / raw)
  To: Wayne Walker; +Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110211051458.GD27051-7+hyfkrzchDWTcdHvfGLfFaTQe2KTcn/@public.gmane.org>

On Thu, 10 Feb 2011 23:14:59 -0600
Wayne Walker <wwalker-7+hyfkrzchDWTcdHvfGLfFaTQe2KTcn/@public.gmane.org> wrote:

> First, I'm not certain whether this is samba, the linux cifs driver, or
> something else.
> 
> During testing, one of my QA guys was running an inhouse program that
> generates pseudo-random, but fully recreatable, data and writes it to
> a file, the file is named with a name that is essentially the seed to
> the pseudo- random stream, so, given a filename, it can read the file
> and verify that the data is correct.
> 
> The file he created was on a CentOS 5.5 machine that was mounting a cifs
> share on another CentOS 5.5 host running samba.  After 150K individual
> files from 35 bytes to 9 GB, he created a 9 GB file that failed
> validation.  He ran the test again with the same seed and it succeeded.
> He ran it a 3rd time and it failed again.
> 
> He got me involved.  I found no useful messages (cifs, IO, kernel mem,
> network, or samba) in any logs on client or server anywhere near the
> times of the file creations.
> 
> I cmp'd the files.  Then used "od -A x -t a" with offsets and diffed the
> 3 files.  Each of the 2 failed files has a single block of 56K (57344) nuls.
> The 2 failed files have these at different points in the 2 files.  Each
> 56K nul block starts on an offset where x % 57344 == 0.
> 
> first file:
> >>> 519995392 / 57344.
> 9068.0 # matching 56K blocks before the one null 56K block
> 
> second file is certainly on a 1 K boundary, but I mislaid the diff data
> for it and it's taking forever for cmp to run to find the offset and
> verify that it's on a 56K boundary.  I'll follow up to this email
> tomorrow with the result of the cmp.
> 
> So, I searched the kernel source, expecting to find 56K in the sata
> driver code.  Instead the only place I found it that seemed relevant
> was:
> 
> 	./fs/cifs/README:  wsize default write size (default 57344)
> 
> I have since used cp to copy the file 4 times with tcpdump running at
> both ends.  All 4 times have worked properly.  Don't know if that is
> because tcpdump is slowing it down or if our test app could be at fault.
> Our test app is talking to the local file system and not with a block
> size of 56K, so I don't think it is our app.
> 
> Unfortunately, the tcpdumps at both ends are reporting the kernel
> dropping about 50% of the packets, so even if I can get it to fail,
> I'm still  unsure whether it's the client or the samba server, where
> client would still leave me choosing betweem our app and fs/cifs.
> 
> The only other thing I can think of is the ethernet devices, but since
> the packet is made up of 30+ ethernet frames, and being TCP there is
> a payload checksum, I can't see the network layers being the culprit,
> but just in case:
> 
> client w/ fs/cifs:
> 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 11)
> 
> samba server:
> 01:01.0 Ethernet controller: Intel Corporation 82547GI Gigabit Ethernet Controller
> 03:02.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller
> 
> A few questions:
> 
> 0. Anyone already know of a bug in fs/cifs or samba that has this
> symptom?
> 
> 1. Anyone know how to get the kernel to not drop the packets?
> 
> 2. Any other ideas on what I can do to gather more data to differentiate
> between bad-app, fs/cifs, samba, or other-element-in-the-chain?
> 
> Thank you for all the work you guys do!
> 

Did the close() or fsync() call return an error?

-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

^ permalink raw reply

* [PATCH] mtd: export mtd->writebufsize attribute over sysfs
From: Anatolij Gustschin @ 2011-02-11 11:46 UTC (permalink / raw)
  To: linux-mtd

Also allow to change mtd->writebufsize for MTD ram test
device dynamicaly.

Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
 drivers/mtd/mtdcore.c |   52 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 52 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index b177e75..282ad41 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -230,12 +230,40 @@ static ssize_t mtd_name_show(struct device *dev,
 }
 static DEVICE_ATTR(name, S_IRUGO, mtd_name_show, NULL);
 
+static ssize_t mtd_writebufsize_show(struct device *dev,
+		struct device_attribute *attr, char *buf)
+{
+	struct mtd_info *mtd = dev_to_mtd(dev);
+
+	return snprintf(buf, PAGE_SIZE, "%lu\n",
+			(unsigned long)mtd->writebufsize);
+}
+
+static ssize_t mtd_writebufsize_store(struct device *dev,
+				struct device_attribute *attr,
+				const char *buf, size_t size)
+{
+	struct mtd_info *mtd = dev_to_mtd(dev);
+	unsigned long value;
+	int ret;
+
+	ret = strict_strtoul(buf, 0, &value);
+	if (ret < 0)
+		return ret;
+
+	mtd->writebufsize = value;
+	return size;
+}
+static DEVICE_ATTR(writebufsize, S_IRUGO, mtd_writebufsize_show,
+		   mtd_writebufsize_store);
+
 static struct attribute *mtd_attrs[] = {
 	&dev_attr_type.attr,
 	&dev_attr_flags.attr,
 	&dev_attr_size.attr,
 	&dev_attr_erasesize.attr,
 	&dev_attr_writesize.attr,
+	&dev_attr_writebufsize.attr,
 	&dev_attr_subpagesize.attr,
 	&dev_attr_oobsize.attr,
 	&dev_attr_numeraseregions.attr,
@@ -258,6 +286,28 @@ static struct device_type mtd_devtype = {
 	.release	= mtd_release,
 };
 
+/*
+ * Make attributes of the mtdram test device writable.
+ * Useful for testing different UBIFS images.
+ */
+static inline void mtd_fixup_attr(struct mtd_info *mtd)
+{
+	struct attribute *attr = mtd_attrs[0];
+	int i = 0;
+
+	if (mtd->type != MTD_RAM)
+		return;
+
+	for (i = 0; mtd_attrs[i]; i++) {
+		attr = mtd_attrs[i];
+		if (!strcmp(attr->name, "writebufsize")) {
+			sysfs_chmod_file(&mtd->dev.kobj, attr,
+					 S_IRUGO | S_IWUSR | S_IWGRP);
+			break;
+		}
+	}
+}
+
 /**
  *	add_mtd_device - register an MTD device
  *	@mtd: pointer to new MTD device info structure
@@ -339,6 +389,8 @@ int add_mtd_device(struct mtd_info *mtd)
 						MTD_DEVT(i) + 1,
 						NULL, "mtd%dro", i);
 
+			mtd_fixup_attr(mtd);
+
 			DEBUG(0, "mtd: Giving out device %d to %s\n",i, mtd->name);
 			/* No need to get a refcount on the module containing
 			   the notifier, since we hold the mtd_table_mutex */
-- 
1.7.4

^ permalink raw reply related

* Re: xen-unstable on OL6 (RHEL6 clone) problems
From: Stefano Stabellini @ 2011-02-11 11:44 UTC (permalink / raw)
  To: Ian Campbell
  Cc: Todd Deshane, xen-devel@lists.xensource.com, Fajar A. Nugraha,
	Dan Magenheimer, Stefano Stabellini
In-Reply-To: <1297410584.3221.1436.camel@localhost.localdomain>

On Fri, 11 Feb 2011, Ian Campbell wrote:
> On Fri, 2011-02-11 at 03:09 +0000, Todd Deshane wrote: 
> > On Thu, Feb 10, 2011 at 12:56 PM, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> > > On Thu, 10 Feb 2011, Dan Magenheimer wrote:
> > >> Is this commented out and easy to turn on?  Or maybe it's NOT
> > >> commented out and is causing the breakage I am seeing?
> > >
> > > The script is still installed but nobody is calling it.
> > > If you are using xl you need to add
> > >
> > > /etc/xen/scripts/network-bridge start
> > >
> > > somewhere in your init scripts.
> > 
> > With xl you need to do this?
> > So like in /etc/rc.local?
> 
> This is a quick and dirty hack which brings back the old xend solution,
> with all the brokenness and caveats described in IanJ's mail from last
> night (it's worse than the previous xend solution if anything).
> 
> We should _not_ be recommending to users that they do this. Stefano,
> please do not muddy the waters for people trying to upgrade by doing so.

In no way I meant to recommend this option to the users, but it might be
worth mentioning it in the wiki.


> > If that is the case, why don't we have some xen init script that loads
> > things like this?
> > 
> > >
> > > If you use xend you need to uncomment the line
> > >
> > > # (network-script network-bridge)
> > >
> > > in /etc/xen/xend-config.sxp.
> > >
> > >
> > > It is worth mentioning this in the wiki so that people can still have
> > > the old behaviour if they want to.
> > >
> > Added this second note.
> 
> This option is not commented out in the default xend-config.sxp in the
> xen-unstable.hg tree. There should be no need to uncomment it.
 
Ooops, sorry for the confusion! I double checked and Ian is right :-/

^ permalink raw reply

* [PATCH] ASoC: Ensure supplies are maintained for force enabled widgets
From: Mark Brown @ 2011-02-11 11:44 UTC (permalink / raw)
  To: Liam Girdwood; +Cc: alsa-devel, patches, swarren, Mark Brown

If a widget has been force enabled then not only do we need to keep the
widget itself enabled, we also need to keep any supplies the widget
requires enabled. The user could force all the individual widgets on but
this requires too much knowledge of device internals.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---

This is only compile tested so far.

 sound/soc/soc-dapm.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index b30eda6..1bd24d5 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -712,7 +712,15 @@ static int dapm_supply_check_power(struct snd_soc_dapm_widget *w)
 		    !path->connected(path->source, path->sink))
 			continue;
 
-		if (path->sink && path->sink->power_check &&
+		if (!path->sink)
+			continue;
+
+		if (path->sink->force) {
+			power = 1;
+			break;
+		}
+
+		if (path->sink->power_check &&
 		    path->sink->power_check(path->sink)) {
 			power = 1;
 			break;
-- 
1.7.2.3

^ permalink raw reply related

* [PATCH] testscript.sh: be able to use branches other that testing-next
From: Steffen Sledz @ 2011-02-11 11:41 UTC (permalink / raw)
  To: openembedded-devel

Signed-off-by: Steffen Sledz <sledz@dresearch.de>
---
 contrib/testing/testscript.sh |   22 ++++++++++++++--------
 1 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/contrib/testing/testscript.sh b/contrib/testing/testscript.sh
index 7ae2bd5..23c244b 100755
--- a/contrib/testing/testscript.sh
+++ b/contrib/testing/testscript.sh
@@ -1,21 +1,27 @@
 # this script can be used for testing purposes.
 # see also http://wiki.openembedded.net/index.php/TestingScript
 
-# you can define your machine/distro/recipe below (remove the #) 
-# or you can pick them up from the environment
-#MACHINE="beagleboard"
-#DISTRO="minimal"
-#TARGET_RECIPE="console-image"
+# you can set your machine/distro/recipe/branch in the environment
+# or use these defaults
+[ -n "${MACHINE}" ] || MACHINE="beagleboard"
+[ -n "${DISTRO}" ] || DISTRO="minimal"
+[ -n "${TARGET_RECIPE}" ] || TARGET_RECIPE="console-image"
+[ -n "${TESTING_BRANCH}" ] || TESTING_BRANCH="testing-next"
 
 # test if we have an openembedded dir, clone it if it does not exist
 if [ ! -d openembedded ]
 then
     (git clone git://git.openembedded.org/openembedded)
-    (cd openembedded; git checkout -b testing-next origin/testing-next)
+else
+    # fetch latest objects and refs
+    (cd openembedded; git fetch)
 fi
 
+# create local testing branch if it does not exist yet
+(cd openembedded; git branch --set-upstream ${TESTING_BRANCH} origin/${TESTING_BRANCH})
+
 # switch to the testing branch
-(cd openembedded; git checkout testing-next)
+(cd openembedded; git checkout ${TESTING_BRANCH})
 
 # test if bitbake exist; if not; fetch it and untar it
 if [ ! -d bitbake-1.10.2 ]
@@ -80,7 +86,7 @@ export BBPATH=${TOPDIR}/openembedded
 rm -rf ${TOPDIR}/tmp
 
 # add an echo about the vars so we can see what has been done in a log file
-echo $MACHINE $DISTRO $TARGET_RECIPE
+echo ${MACHINE} ${DISTRO} ${TARGET_RECIPE} ${TESTING_BRANCH} `(cd openembedded;git --no-pager log --max-count=1 --pretty=format:%H)`
 
 # and do the actual work.
 bitbake ${TARGET_RECIPE}
-- 
1.7.1




^ permalink raw reply related

* Re: [patch 34/75] arm: ep93xx: Kill another instance of broken irq_desc fiddling
From: Thomas Gleixner @ 2011-02-11 11:42 UTC (permalink / raw)
  To: Ryan Mallon
  Cc: LKML, Ingo Molnar, Peter Zijlstra, Hartley Sweeten, Russell King
In-Reply-To: <4D548146.5090507@bluewatersys.com>

On Fri, 11 Feb 2011, Ryan Mallon wrote:

> On 02/11/2011 12:37 PM, Thomas Gleixner wrote:
> > 1. This is a copy of the borked code in gpiolib
> > 2. If you need information about irq state which is not exposed, then talk
> >    to the maintainer of that code instead of adding totaly horrible open
> >    coded access.
> 
> This code got added simply because it is sometimes helpful to be able to
> see how various gpio/irq pins are configured. I'm happy to drop the
> functionality (see below), but is there a better way to get this
> information? Is it already available somewhere else (proc, sys)?

No, but we can add that if it's required in a sane form.

I don't have objections to expose debug informations in general, but
I have objections that random code does this especially, when it's
duplicated random code :)

Thanks,

	tglx

^ permalink raw reply

* Re: xen-unstable on OL6 (RHEL6 clone) problems
From: Stefano Stabellini @ 2011-02-11 11:42 UTC (permalink / raw)
  To: Todd Deshane
  Cc: Dan Magenheimer, xen-devel@lists.xensource.com, Fajar A. Nugraha,
	Stefano Stabellini
In-Reply-To: <AANLkTimE_qZtnZS3DJRr0eTXpk1sVPteonoz2oQuS=e2@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

On Fri, 11 Feb 2011, Todd Deshane wrote:
> On Thu, Feb 10, 2011 at 12:56 PM, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 10 Feb 2011, Dan Magenheimer wrote:
> >> Is this commented out and easy to turn on?  Or maybe it's NOT
> >> commented out and is causing the breakage I am seeing?
> >
> > The script is still installed but nobody is calling it.
> > If you are using xl you need to add
> >
> > /etc/xen/scripts/network-bridge start
> >
> > somewhere in your init scripts.
> 
> With xl you need to do this?
> So like in /etc/rc.local?

Users don't need to do this: the recommended way of solving this problem
is using the distro's bridge scripts.


> If that is the case, why don't we have some xen init script that loads
> things like this?

This is only for people that wants the old behaviour.

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply

* Re: Using Origin hashes to improve rebase behavior
From: Johan Herland @ 2011-02-11 11:40 UTC (permalink / raw)
  To: skillzero; +Cc: git, John Wiegley
In-Reply-To: <AANLkTikrVPCr92XHirn1u=73eM--T190V-7nbE6fo8ng@mail.gmail.com>

On Friday 11 February 2011, skillzero@gmail.com wrote:
> On Thu, Feb 10, 2011 at 1:13 PM, John Wiegley <johnw@boostpro.com> wrote:
> >    a   b   c   3'  d   e*  f
> >    o---o---o---o---o---o---o
> >             \
> >              o---o---o---o
> >              1   2   3   4
> > 
> > At a later date, I want to rebase the private branch onto master.  What
> > will happen is that the changes in 3 will conflict with the rewritten
> > changes in e*.  However, I'd like Git to know that 3 was already
> > incorporated at some earlier time, and *not consider it during the
> > rebase*, since it doesn't need to.
> 
> I don't know very much about how git really works so what I'm saying
> may be dumb, but rather than record where a commit came from, would it
> be reasonable for rebase to look at the patch-id for each change on
> the topic branch after the merge base and automatically remove topic
> branch commits that match that patch-id? So in your example, rebase
> would check each topic branch commit against 3', d, e*, and f and see
> that the 3' patch-id is the same as the topic branch 3 and remove
> topic branch 3 before it gets to e*?

I believe "git rebase" already does exactly what you describe [1].

However, comparing patch-ids stops working when the cherry-pick (3 -> 3') 
has conflicts. IINM, it is the conflicting cases that John is interested in 
solving...


...Johan

[1]: I tested the above scenario, and got no conflicts:

$ git init
$ FOO=a && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ FOO=b && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ FOO=c && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ git checkout -b topic
$ FOO=1 && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ FOO=2 && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ FOO=3 && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ FOO=4 && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ git checkout master
$ git cherry-pick topic^
$ FOO=d && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ echo e >> 3 && git add 3
$ FOO=e && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ FOO=f && echo $FOO > $FOO && git add $FOO && git commit -m $FOO
$ git checkout topic
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: 1
Applying: 2
Applying: 4
$ # Look, no conflicts.

-- 
Johan Herland, <johan@herland.net>
www.herland.net

^ permalink raw reply

* Re: [msysGit] git-svn.perl should check GIT_ASKPASS environment
From: Frank Li @ 2011-02-11 11:34 UTC (permalink / raw)
  To: kusmabite; +Cc: Jose Roberto Garcia Chico, msysGit, Git Mailing List, Eric Wong
In-Reply-To: <AANLkTinWLTfU_WmxTCvz+P=rcXY=2u25Eo2QZWmDMdSh@mail.gmail.com>

>> SSH_ASKPASS is used to accept "Enter your OpenSSH passphrase".
>> refer to git-gui/git-gui--askpass
>>
>
> git-gui--askpass can ask for a password, or yes/no questions. But this
> is neither, it's a reject/accept temporary/accept permanently
> question.
>
> Perhaps the prompt could be rewritten as two yes/no questions, though?
> Something like "Accept certificate? (yes/no)" and if the answer is
> "yes", query with something like "Store certificate? (yes/no)".

I think that's fine.
Frank Li

^ permalink raw reply

* Re: [patch 17/75] genirq: Consolidate IRQ_DISABLED
From: Thomas Gleixner @ 2011-02-11 11:39 UTC (permalink / raw)
  To: Lars-Peter Clausen; +Cc: LKML, Ingo Molnar, Peter Zijlstra
In-Reply-To: <4D54EBE0.3050408@metafoo.de>

On Fri, 11 Feb 2011, Lars-Peter Clausen wrote:

> On 02/11/2011 12:36 AM, Thomas Gleixner wrote:
> > Index: linux-2.6-tip/kernel/irq/chip.c
> > ===================================================================
> > --- linux-2.6-tip.orig/kernel/irq/chip.c
> > +++ linux-2.6-tip/kernel/irq/chip.c
> > @@ -192,11 +192,14 @@ EXPORT_SYMBOL_GPL(set_irq_nested_thread)
> >
> >  int irq_startup(struct irq_desc *desc)
> >  {
> > -	desc->status &= ~(IRQ_MASKED | IRQ_DISABLED);
> > +	desc->status &= ~IRQ_DISABLED;
> >  	desc->depth = 0;
> >
> > -	if (desc->irq_data.chip->irq_startup)
> > -		return desc->irq_data.chip->irq_startup(&desc->irq_data);
> > +	if (desc->irq_data.chip->irq_startup) {
> > +		int ret = desc->irq_data.chip->irq_startup(&desc->irq_data);
> > +		desc->status &= IRQ_MASKED;
> 
> Although it is fixed in patch 45 of this series, I guess it should rather be
> desc->status &= ~IRQ_MASKED here too.

Good catch. Will fix nevertheless.

Thanks,

	tglx

^ permalink raw reply

* Re: [PATCH] Platform: add Samsung Laptop platform driver
From: Richard Schütz @ 2011-02-11 11:37 UTC (permalink / raw)
  To: Greg KH; +Cc: Matthew Garrett, Randy Dunlap, linux-kernel, platform-driver-x86
In-Reply-To: <20110209224006.GA11202@kroah.com>

 > +static struct dmi_system_id __initdata samsung_dmi_table[] = {
 > +	{
 > +		.ident = "N128",
 > +		.matches = {
 > +			DMI_MATCH(DMI_SYS_VENDOR,
 > +					"SAMSUNG ELECTRONICS CO., LTD."),
 > +			DMI_MATCH(DMI_PRODUCT_NAME, "N128"),
 > +			DMI_MATCH(DMI_BOARD_NAME, "N128"),
 > +		},
 > +		.callback = dmi_check_cb,
 > +	},
 > +	{
 > +		.ident = "N130",
 > +		.matches = {
 > +			DMI_MATCH(DMI_SYS_VENDOR,
 > +					"SAMSUNG ELECTRONICS CO., LTD."),
 > +			DMI_MATCH(DMI_PRODUCT_NAME, "N130"),
 > +			DMI_MATCH(DMI_BOARD_NAME, "N130"),
 > +		},
 > +		.callback = dmi_check_cb,
 > +	},
 > +	{
 > +		.ident = "X125",
 > +		.matches = {
 > +			DMI_MATCH(DMI_SYS_VENDOR,
 > +					"SAMSUNG ELECTRONICS CO., LTD."),
 > +			DMI_MATCH(DMI_PRODUCT_NAME, "X125"),
 > +			DMI_MATCH(DMI_BOARD_NAME, "X125"),
 > +		},
 > +		.callback = dmi_check_cb,
 > +	},
 > +	{
 > +		.ident = "NC10",
 > +		.matches = {
 > +			DMI_MATCH(DMI_SYS_VENDOR,
 > +					"SAMSUNG ELECTRONICS CO., LTD."),
 > +			DMI_MATCH(DMI_PRODUCT_NAME, "NC10"),
 > +			DMI_MATCH(DMI_BOARD_NAME, "NC10"),
 > +		},
 > +		.callback = dmi_check_cb,
 > +	},
 > +		{
 > +		.ident = "NP-Q45",
 > +		.matches = {
 > +			DMI_MATCH(DMI_SYS_VENDOR,
 > +					"SAMSUNG ELECTRONICS CO., LTD."),
 > +			DMI_MATCH(DMI_PRODUCT_NAME, "SQ45S70S"),
 > +			DMI_MATCH(DMI_BOARD_NAME, "SQ45S70S"),
 > +		},
 > +		.callback = dmi_check_cb,
 > +		},
 > +	{
 > +		.ident = "X360",
 > +		.matches = {
 > +			DMI_MATCH(DMI_SYS_VENDOR,
 > +					"SAMSUNG ELECTRONICS CO., LTD."),
 > +			DMI_MATCH(DMI_PRODUCT_NAME, "X360"),
 > +			DMI_MATCH(DMI_BOARD_NAME, "X360"),
 > +		},
 > +		.callback = dmi_check_cb,
 > +	},
 > +	{
 > +		.ident = "R518",
 > +		.matches = {
 > +			DMI_MATCH(DMI_SYS_VENDOR,
 > +					"SAMSUNG ELECTRONICS CO., LTD."),
 > +			DMI_MATCH(DMI_PRODUCT_NAME, "R518"),
 > +			DMI_MATCH(DMI_BOARD_NAME, "R518"),
 > +		},
 > +		.callback = dmi_check_cb,
 > +	},
 > +	{
 > +		.ident = "N150/N210/N220",
 > +		.matches = {
 > +			DMI_MATCH(DMI_SYS_VENDOR,
 > +					"SAMSUNG ELECTRONICS CO., LTD."),
 > +			DMI_MATCH(DMI_PRODUCT_NAME, "N150/N210/N220"),
 > +			DMI_MATCH(DMI_BOARD_NAME, "N150/N210/N220"),
 > +		},
 > +		.callback = dmi_check_cb,
 > +	},
 > +	{
 > +		.ident = "R530/R730",
 > +		.matches = {
 > +		      DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
 > +		      DMI_MATCH(DMI_PRODUCT_NAME, "R530/R730"),
 > +		      DMI_MATCH(DMI_BOARD_NAME, "R530/R730"),
 > +		},
 > +		.callback = dmi_check_cb,
 > +	},
 > +	{
 > +		.ident = "NF110/NF210/NF310",
 > +		.matches = {
 > +			DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
 > +			DMI_MATCH(DMI_PRODUCT_NAME, "NF110/NF210/NF310"),
 > +			DMI_MATCH(DMI_BOARD_NAME, "NF110/NF210/NF310"),
 > +		},
 > +		.callback = dmi_check_cb,
 > +	},
 > +	{ },
 > +};
 > +MODULE_DEVICE_TABLE(dmi, samsung_dmi_table);

Could you add

.ident = "N145P/N250P/N260P",
.matches = {
	DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
	DMI_MATCH(DMI_PRODUCT_NAME, "N145P/N250P/N260P"),
	DMI_MATCH(DMI_BOARD_NAME, "N145P/N250P/N260P"),
},
.callback = dmi_check_cb,

there, please? I've tested the driver successfully on my N145P.

-- 
Regards,
Richard Schütz

^ permalink raw reply

* Re: [PATCH 3/3] ASoC: Add support for AIF channel muxing on WM8903
From: Mark Brown @ 2011-02-11 11:36 UTC (permalink / raw)
  To: Stephen Warren
  Cc: alsa-devel@alsa-project.org, patches@opensource.wolfsonmicro.com,
	Liam Girdwood
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF0310F605B2@HQMAIL01.nvidia.com>

On Thu, Feb 10, 2011 at 09:40:37PM -0800, Stephen Warren wrote:

> So, what's happening is that once the mic is removed, there's no active path
> in the whole codec, so everything gets shut down, including CLK_SYS.
> In turn, this means that mic detection doesn't work, so when the mic gets
> plugged back in, that event is not noticed, and nothing gets re-enabled.

> If I am playing a stream at the same time as recording, that solves (hides)
> the problem, since the codec is active and CLK_SYS stays enabled.

> I found that if I revert:

> 2c8be5a26e42cfc4906c4daa8a5a5c82610ddb3d
> ASoC: Dynamically manage CLK_SYS in WM8903

> That also fixes the issue. I'm not entirely clear why though; perhaps there
> are simply missing entries in the route map for CLK_SYS to mic-related
> widgets?

There's a link from CLK_SYS to Mic Bias so if Mic Bias is enabled then
CLK_SYS should be kept up too.  However, it looks like the core DAPM
logic is getting this wrong and the force enable is only applying to the
immediate widget.  In the case of a supply widget this is clearly the
wrong thing to do.  I'll send out a patch for this shortly.

^ permalink raw reply

* [PATCH 1/1] doc: Update possible errors
From: Jeevaka Badrappan @ 2011-02-11 11:34 UTC (permalink / raw)
  To: ofono
In-Reply-To: <1297424071-5464-1-git-send-email-jeevaka.badrappan@elektrobit.com>

[-- Attachment #1: Type: text/plain, Size: 31990 bytes --]

---
 doc/audio-settings-api.txt         |    2 -
 doc/call-barring-api.txt           |   31 ++++++++++++++++++++++
 doc/call-forwarding-api.txt        |   16 +++++++++++
 doc/call-meter-api.txt             |   14 ++++++++++
 doc/call-settings-api.txt          |    8 ++++++
 doc/call-volume-api.txt            |    9 +++---
 doc/cdma-voicecall-manager-api.txt |   10 +++++++
 doc/cell-broadcast-api.txt         |    7 ++---
 doc/connman-api.txt                |   25 ++++++++++++++----
 doc/manager-api.txt                |    2 -
 doc/message-api.txt                |    2 -
 doc/message-waiting-api.txt        |    7 +++--
 doc/messagemanager-api.txt         |   14 ++++++++--
 doc/modem-api.txt                  |   10 ++++---
 doc/network-api.txt                |   16 +++++++----
 doc/phonebook-api.txt              |    2 +-
 doc/pushnotification-api.txt       |    8 ++++++
 doc/radio-settings-api.txt         |    9 +++---
 doc/sim-api.txt                    |   37 +++++++++++++++++++++++++-
 doc/stk-api.txt                    |   17 +++++++-----
 doc/supplementaryservices-api.txt  |   20 +++++++++++---
 doc/voicecall-api.txt              |   17 +++++++++++-
 doc/voicecallmanager-api.txt       |   49 ++++++++++++++++++++++++++++++++++-
 23 files changed, 273 insertions(+), 59 deletions(-)

diff --git a/doc/audio-settings-api.txt b/doc/audio-settings-api.txt
index 0f60306..49d7909 100644
--- a/doc/audio-settings-api.txt
+++ b/doc/audio-settings-api.txt
@@ -10,8 +10,6 @@ Methods		dict GetProperties()
 			Returns all audio settings properties. See the
 			properties section for available properties.
 
-			Possible Errors: [service].Error.InvalidArguments
-
 Signals		PropertyChanged(string property, variant value)
 
 			This signal indicates a changed value of the given
diff --git a/doc/call-barring-api.txt b/doc/call-barring-api.txt
index 1534494..a80bf61 100644
--- a/doc/call-barring-api.txt
+++ b/doc/call-barring-api.txt
@@ -9,29 +9,60 @@ Methods		dict GetProperties()
 
 			Contains the properties for this object.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+
 		void ChangePassword(string old_password, string new_password)
 
 			Register new network password for the barring
 			services.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 		void DisableAll(string password)
 
 			Disables all call barrings.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 		void DisableAllIncoming(string password)
 
 			Disables barrings for incoming calls.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 		void DisableAllOutgoing(string password)
 
 			Disables barrings for outgoing calls.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 		void SetProperty(string property, variant value, string pin2)
 
 			Sets the given property value to that specified in
 			call parameter.  For all properties, the password
 			(typically PIN2) must be provided.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 Signals		PropertyChanged(string property, variant value)
 
 			Signal is emitted whenever a property has changed.
diff --git a/doc/call-forwarding-api.txt b/doc/call-forwarding-api.txt
index e8b4b9f..335637f 100644
--- a/doc/call-forwarding-api.txt
+++ b/doc/call-forwarding-api.txt
@@ -8,6 +8,9 @@ Methods		dict GetProperties()
 
 			Contains the properties for this object.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+
 		void DisableAll(string type)
 
 			Disables all call forwarding rules for type.
@@ -16,11 +19,24 @@ Methods		dict GetProperties()
 				"conditional" - Disables all conditional rules,
 					e.g. busy, no reply and not reachable.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 		void SetProperty(string property, variant value)
 
 			Sets the given property value to that specified in
 			call parameter.
 
+			Possible Errors: [service].Error.NotAvailable
+					 [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 Signals		PropertyChanged(string property, variant value)
 
 			Signal is emitted whenever a property has changed.
diff --git a/doc/call-meter-api.txt b/doc/call-meter-api.txt
index 045343b..b668f79 100644
--- a/doc/call-meter-api.txt
+++ b/doc/call-meter-api.txt
@@ -8,6 +8,8 @@ Methods		dict GetProperties()
 
 			Contains the properties for this object.
 
+			Possible Errors: [service].Error.InProgress
+
 		void SetProperty(string property, variant value,
 				 string password)
 
@@ -16,12 +18,24 @@ Methods		dict GetProperties()
 			to pass the SIM PIN2 code which may be
 			required by the SIM.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 		void Reset(string password)
 
 			Attempts to reset the Accumulated Call Meter.
 			Reseting this value requires SIM PIN2, provided
 			by the password parameter.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 Signals		PropertyChanged(string property, variant value)
 
 			Signal is emitted whenever a property has changed.
diff --git a/doc/call-settings-api.txt b/doc/call-settings-api.txt
index ed2a099..de9f314 100644
--- a/doc/call-settings-api.txt
+++ b/doc/call-settings-api.txt
@@ -8,11 +8,19 @@ Methods		dict GetProperties()
 
 			Contains the properties for this object.
 
+			Possible Errors: [service].Error.InProgress
+
 		void SetProperty(string property, variant value)
 
 			Sets the given property value to that specified in
 			call parameter.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 Signals		PropertyChanged(string property, variant value)
 
 			Signal is emitted whenever a property has changed.
diff --git a/doc/call-volume-api.txt b/doc/call-volume-api.txt
index 6db0132..320b25f 100644
--- a/doc/call-volume-api.txt
+++ b/doc/call-volume-api.txt
@@ -10,8 +10,6 @@ Methods		dict GetProperties()
 			Returns properties for the CallVolume object. See
 			the properties section for available properties.
 
-			Possible Errors: [service].Error.InvalidArguments
-
 		void SetProperty(string property, variant value)
 
 			Changes the value of the specified property. Only
@@ -19,8 +17,11 @@ Methods		dict GetProperties()
 			changeable. On success a PropertyChanged signal
 			will be emitted.
 
-			Possible Errors: [service].Error.InvalidArguments
-					 [service].Error.DoesNotExist
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
 
 Signals		PropertyChanged(string name, variant value)
 
diff --git a/doc/cdma-voicecall-manager-api.txt b/doc/cdma-voicecall-manager-api.txt
index 2fd74da..535909a 100644
--- a/doc/cdma-voicecall-manager-api.txt
+++ b/doc/cdma-voicecall-manager-api.txt
@@ -15,10 +15,20 @@ Methods		dict GetProperties()
 			Initiates a new outgoing call.  This is usually
 			implemented using the ATD AT command.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.NotImplemented
+					 [service].Error.Failed
+
 		void Hangup()
 
 			Hangup all active calls.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.Failed
+
 		void Answer()
 
 			Answer the incoming call.  This only affects the
diff --git a/doc/cell-broadcast-api.txt b/doc/cell-broadcast-api.txt
index ec5f14c..52618eb 100644
--- a/doc/cell-broadcast-api.txt
+++ b/doc/cell-broadcast-api.txt
@@ -10,8 +10,6 @@ Methods		dict GetProperties()
 			Returns properties for the cell broadcast object. See
 			the properties section for available properties.
 
-			Possible Errors: [service].Error.InvalidArguments
-
 		void SetProperty(string property, variant value)
 
 			Changes the value of the specified property. Only
@@ -19,8 +17,9 @@ Methods		dict GetProperties()
 			changeable. On success a PropertyChanged signal
 			will be emitted.
 
-			Possible Errors: [service].Error.InvalidArguments
-					 [service].Error.DoesNotExist
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.InvalidArguments
+					 [service].Error.Failed
 
 Signals		PropertyChanged(string name, variant value)
 
diff --git a/doc/connman-api.txt b/doc/connman-api.txt
index 22c59dc..ece5bd3 100644
--- a/doc/connman-api.txt
+++ b/doc/connman-api.txt
@@ -10,20 +10,23 @@ Methods		dict GetProperties()
 			Returns all global system properties. See the
 			properties section for available properties.
 
-			Possible Errors: [service].Error.InvalidArguments
-
 		void SetProperty(string property, variant value)
 
 			Sets the property to a desired value
 
-			Possible Errors: [service].Error.InvalidArguments
-					 [service].Error.InvalidFormat
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.InvalidArguments
 					 [service].Error.Failed
 
 		void DeactivateAll()
 
 			Deactivates all active contexts.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.InvalidArguments
+					 [service].Error.Failed
+
 		array{object,dict} GetContexts()
 
 			Get array of context objects and properties.
@@ -41,12 +44,22 @@ Methods		dict GetProperties()
 			Type documentation of ConnectionContext interface.
 			Returns the object path of the created context.
 
+			Possible Errors: [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 		void RemoveContext(object context)
 
 			Removes a primary context.  All secondary contexts, if
 			any, associated with the primary context are also
 			removed.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.NotFound
+					 [service].Error.Failed
+
 Signals		PropertyChanged(string property, variant value)
 
 			This signal indicates a changed value of the given
@@ -130,8 +143,6 @@ Object path	[variable]
 Methods		dict GetProperties()
 			Returns all properties for the context object.
 
-			Possible Errors: [service].Error.InvalidArguments
-
 		void SetProperty(string property, variant value)
 
 			Sets the property to a desired value
@@ -139,8 +150,10 @@ Methods		dict GetProperties()
 			Possible Errors: [service].Error.InvalidArguments
 					 [service].Error.InvalidFormat
 					 [service].Error.Failed
+					 [service].Error.InProgress
 					 [service].Error.NotAttached
 					 [service].Error.AttachInProgress
+					 [service].Error.NotImplemented
 
 Signals		PropertyChanged(string property, variant value)
 
diff --git a/doc/manager-api.txt b/doc/manager-api.txt
index c231245..1cdedec 100644
--- a/doc/manager-api.txt
+++ b/doc/manager-api.txt
@@ -15,8 +15,6 @@ Methods		array{object,dict} GetModems()
 			and removal shall be monitored via ModemAdded and
 			ModemRemoved signals.
 
-			Possible Errors: [service].Error.InvalidArguments
-
 Signals		ModemAdded(object path, dict properties)
 
 			Signal that is sent when a new modem is added.  It
diff --git a/doc/message-api.txt b/doc/message-api.txt
index 1c68aee..8d962fd 100644
--- a/doc/message-api.txt
+++ b/doc/message-api.txt
@@ -10,8 +10,6 @@ Methods		dict GetProperties()
 			Returns properties for the message object. See
 			the properties section for available properties.
 
-			Possible Errors: [service].Error.InvalidArguments
-
 Signals		PropertyChanged(string name, variant value)
 
 			This signal indicates a changed value of the given
diff --git a/doc/message-waiting-api.txt b/doc/message-waiting-api.txt
index e381923..83c030b 100644
--- a/doc/message-waiting-api.txt
+++ b/doc/message-waiting-api.txt
@@ -10,8 +10,6 @@ Methods		dict GetProperties()
 			Returns properties for the MessageWaiting object. See
 			the properties section for available properties.
 
-			Possible Errors: [service].Error.InvalidArguments
-
 		void SetProperty(string property, variant value)
 
 			Changes the value of the specified property. Only
@@ -20,7 +18,10 @@ Methods		dict GetProperties()
 			will be emitted.
 
 			Possible Errors: [service].Error.InvalidArguments
-					 [service].Error.DoesNotExist
+					 [service].Error.InvalidFormat
+					 [service].Error.NotSupported
+					 [service].Error.SimNotReady
+					 [service].Error.Failed
 
 Signals		PropertyChanged(string name, variant value)
 
diff --git a/doc/messagemanager-api.txt b/doc/messagemanager-api.txt
index 848d6e3..43c4d07 100644
--- a/doc/messagemanager-api.txt
+++ b/doc/messagemanager-api.txt
@@ -10,7 +10,8 @@ Methods		dict GetProperties()
 			Returns properties for the manager object. See
 			the properties section for available properties.
 
-			Possible Errors: [service].Error.InvalidArguments
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
 
 		array{object,dict} GetMessages()
 
@@ -29,8 +30,11 @@ Methods		dict GetProperties()
 			changeable. On success a PropertyChanged signal
 			will be emitted.
 
-			Possible Errors: [service].Error.InvalidArguments
-					 [service].Error.DoesNotExist
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
 
 		object SendMessage(string to, string text)
 
@@ -38,6 +42,10 @@ Methods		dict GetProperties()
 			message could be queued successfully, this method
 			returns an object path to the created Message object.
 
+			Possible Errors: [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 Signals		PropertyChanged(string name, variant value)
 
 			This signal indicates a changed value of the given
diff --git a/doc/modem-api.txt b/doc/modem-api.txt
index 45043b0..fa400a2 100644
--- a/doc/modem-api.txt
+++ b/doc/modem-api.txt
@@ -10,8 +10,6 @@ Methods		dict GetProperties()
 			Returns properties for the modem object. See
 			the properties section for available properties.
 
-			Possible Errors: [service].Error.InvalidArguments
-
 		void SetProperty(string property, variant value)
 
 			Changes the value of the specified property. Only
@@ -19,8 +17,12 @@ Methods		dict GetProperties()
 			changeable. On success a PropertyChanged signal
 			will be emitted.
 
-			Possible Errors: [service].Error.InvalidArguments
-					 [service].Error.DoesNotExist
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.InvalidArguments
+					 [service].Error.NotAvailable
+					 [service].Error.AccessDenied
+					 [service].Error.Failed
 
 Signals		PropertyChanged(string name, variant value)
 
diff --git a/doc/network-api.txt b/doc/network-api.txt
index 4cb6366..159debc 100644
--- a/doc/network-api.txt
+++ b/doc/network-api.txt
@@ -10,8 +10,6 @@ Methods		dict GetProperties()
 			Returns all network registration properties. See the
 			properties section for available properties.
 
-			Possible Errors: [service].Error.InvalidArguments
-
 		void SetProperty(string name, variant value)
 
 			Changes the value of the specified property. Only
@@ -28,7 +26,9 @@ Methods		dict GetProperties()
 			default network is normally selected by the settings
 			from the SIM card.
 
-			Possible Errors: [service].Error.InvalidArguments
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.Failed
 
 		array{object,dict} GetOperators()
 
@@ -56,6 +56,10 @@ Methods		dict GetProperties()
 			GPRS contexts.  Expect the context to be unavailable
 			for the duration of the operator scan.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.Failed
+
 Signals		PropertyChanged(string property, variant value)
 
 			This signal indicates a changed value of the given
@@ -158,8 +162,6 @@ Methods		dict GetProperties()
 			Returns all network operator properties. See the
 			properties section for available properties.
 
-			Possible Errors: [service].Error.InvalidArguments
-
 		void Register()
 
 			Attempts to register to this network operator.
@@ -168,7 +170,9 @@ Methods		dict GetProperties()
 			be observed by tracking the NetworkRegistration Status
 			property.
 
-			Possible Errors: [service].Error.InvalidArguments
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.Failed
 
 Signals		PropertyChanged(string property, variant value)
 
diff --git a/doc/phonebook-api.txt b/doc/phonebook-api.txt
index dc8b95d..92c0e0b 100644
--- a/doc/phonebook-api.txt
+++ b/doc/phonebook-api.txt
@@ -15,4 +15,4 @@ Methods		string Import()
 			The phonebook is returned as a single UTF8 encoded
 			string with zero or more VCard entries.
 
-			Possible Errors: [service].Error.Failed
+			Possible Errors: [service].Error.InProgress
diff --git a/doc/pushnotification-api.txt b/doc/pushnotification-api.txt
index 942ba0f..6938826 100644
--- a/doc/pushnotification-api.txt
+++ b/doc/pushnotification-api.txt
@@ -10,10 +10,18 @@ Methods		void RegisterAgent(object path)
 			Registers an agent which will be called whenever a
 			new Smart Messaging based SMS arrives.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 		void UnregisterAgent(object path)
 
 			Unregisters an agent.
 
+			Possible Errors: [service].Error.InvalidArguments
+					 [service].Error.Failed
+
 PushNotificationAgent Hierarchy [experimental]
 ===============
 
diff --git a/doc/radio-settings-api.txt b/doc/radio-settings-api.txt
index da46ffe..d2dd319 100644
--- a/doc/radio-settings-api.txt
+++ b/doc/radio-settings-api.txt
@@ -10,9 +10,8 @@ Methods		dict GetProperties()
 			Returns all radio access properties. See the
 			properties section for available properties.
 
-			Possible Errors: [service].Error.InvalidArguments
+			Possible Errors: [service].Error.InProgress
 					 [service].Error.NotImplemented
-					 [service].Error.InProgress
 					 [service].Error.Failed
 
 		void SetProperty(string name, variant value)
@@ -22,9 +21,9 @@ Methods		dict GetProperties()
 			changeable. On success a PropertyChanged signal
 			will be emitted.
 
-			Possible Errors: [service].Error.InvalidArguments
-					 [service].Error.DoesNotExist
-					 [service].Error.InProgress
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.InvalidArguments
 					 [service].Error.Failed
 
 Signals		PropertyChanged(string property, variant value)
diff --git a/doc/sim-api.txt b/doc/sim-api.txt
index c8091f7..22fe22b 100644
--- a/doc/sim-api.txt
+++ b/doc/sim-api.txt
@@ -10,23 +10,39 @@ Methods		dict GetProperties()
 			Returns SIM properties for the modem object.  See
 			the properties section for available properties.
 
-			Possible Errors: [service].Error.InvalidArguments
-
 		void ChangePin(string type, string oldpin, string newpin)
 
 			Changes the pin given by string type.
 
+			Possible Errors: [service].Error.NotImplemented
+					 [service].Error.InProgress
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 		void EnterPin(string type, string pin)
 
 			Enters the currently pending pin.  The type value must
 			match the pin type being asked in the PinRequired
 			property.
 
+			Possible Errors: [service].Error.NotImplemented
+					 [service].Error.InProgress
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 		void ResetPin(string type, string puk, string newpin)
 
 			Provides the unblock key to the modem and if correct
 			resets the pin to the new value of newpin.
 
+			Possible Errors: [service].Error.NotImplemented
+					 [service].Error.InProgress
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 		void LockPin(string type, string pin)
 
 			Activates the lock for the particular pin type.  The
@@ -35,17 +51,34 @@ Methods		dict GetProperties()
 			re-inserted.  The current PIN is required for the
 			operation to succeed.
 
+			Possible Errors: [service].Error.NotImplemented
+					 [service].Error.InProgress
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 		void UnlockPin(string type, string pin)
 
 			Deactivates the lock for the particular pin type.  The
 			current PIN is required for the operation to succeed.
 
+			Possible Errors: [service].Error.NotImplemented
+					 [service].Error.InProgress
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 		array{byte} GetIcon(byte id)
 
 			Obtain the icon given by id.  Only ids greater than 1
 			are valid.  XPM format is currently used to return the
 			icon data.
 
+			Possible Errors: [service].Error.NotImplemented
+					 [service].Error.InProgress
+					 [service].Error.InvalidArguments
+					 [service].Error.Failed
+
 Signals		PropertyChanged(string name, variant value)
 
 			This signal indicates a changed value of the given
diff --git a/doc/stk-api.txt b/doc/stk-api.txt
index 93a2434..054821b 100644
--- a/doc/stk-api.txt
+++ b/doc/stk-api.txt
@@ -10,8 +10,6 @@ Methods		dict GetProperties()
 			Returns properties for the SimToolkit object.  See the
 			properties section for available properties.
 
-			Possible Errors: [service].Error.InvalidArguments
-
 		array{byte} GetIcon(byte id)
 
 			Returns the icon data for icon identified by id.
@@ -27,6 +25,12 @@ Methods		dict GetProperties()
 			a new agent to be used for the duration of the
 			user session.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotSupported
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 		void RegisterAgent(object path)
 
 			Registers a default agent to be used for SIM initiated
@@ -35,9 +39,10 @@ Methods		dict GetProperties()
 			received and might not involve interaction from the
 			user.
 
-			Possible Errors: [service].Error.InvalidArguments
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.InvalidArguments
 					 [service].Error.InvalidFormat
-					 [service].Error.InUse
+					 [service].Error.Failed
 
 		void UnregisterAgent(object path)
 
@@ -46,9 +51,7 @@ Methods		dict GetProperties()
 			are rejected.
 
 			Possible Errors: [service].Error.InvalidArguments
-					 [service].Error.InvalidFormat
-					 [service].Error.NotFound
-					 [service].Error.NotAuthorized
+					 [service].Error.Failed
 
 Signals		PropertyChanged(string property, variant value)
 
diff --git a/doc/supplementaryservices-api.txt b/doc/supplementaryservices-api.txt
index 820cce1..e855ead 100644
--- a/doc/supplementaryservices-api.txt
+++ b/doc/supplementaryservices-api.txt
@@ -23,8 +23,11 @@ Methods		string, variant Initiate(string command)
 			The output arguments are described in section
 			"Initiate method outptut arguments" below.
 
-			Possible Errors: [service].Error.Timedout
-			Possible Errors: [service].Error.Canceled
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
 
 		string Respond(string reply)
 
@@ -32,14 +35,23 @@ Methods		string, variant Initiate(string command)
 			it is awaiting further input after Initiate()
 			was called or after a network-initiated request.
 
-			Possible Errors: [service].Error.Timedout
-			Possible Errors: [service].Error.Canceled
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotActive
+					 [service].Error.NotImplemented
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
 
 		void Cancel()
 
 			Cancel an ongoing USSD session, mobile- or
 			network-initiated.
 
+			Possible Errors: [service].Error.NotActive
+					 [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.Failed
+
 		dict GetProperties()
 
 			Returns Supplementary Services related properties. See
diff --git a/doc/voicecall-api.txt b/doc/voicecall-api.txt
index 253c30d..7eb41aa 100644
--- a/doc/voicecall-api.txt
+++ b/doc/voicecall-api.txt
@@ -10,8 +10,6 @@ Methods		dict GetProperties()
 			Returns all properties for this object. See the
 			properties section for available properties.
 
-			Possible Errors: [service].Error.InvalidArguments
-
 		void Deflect(string number)
 
 			Deflects the incoming or waiting call to number given
@@ -25,6 +23,12 @@ Methods		dict GetProperties()
 			This method should not be confused with the Transfer()
 			method.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 		void Hangup()
 
 			Hangs up the voice call.
@@ -43,6 +47,10 @@ Methods		dict GetProperties()
 			of a held multiparty call might not be possible on some
 			implementations.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.Failed
+					 [service].Error.NotImplemented
+
 		void Answer()
 
 			Answers the incoming call.  Only valid if the state
@@ -51,6 +59,11 @@ Methods		dict GetProperties()
 			This functionality is generally implemented by ATA
 			AT command.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.Failed
+					 [service].Error.NotImplemented
+					 [service].Error.Failed
+
 Signals		PropertyChanged(string property, variant value)
 
 			Signal is emitted whenever a property has changed.
diff --git a/doc/voicecallmanager-api.txt b/doc/voicecallmanager-api.txt
index ca8aaec..73205f0 100644
--- a/doc/voicecallmanager-api.txt
+++ b/doc/voicecallmanager-api.txt
@@ -10,8 +10,6 @@ Methods		dict GetProperties()
 			Returns properties for the VoiceCallManager Interface.
 			See the properties section for available properties.
 
-			Possible Errors: [service].Error.InvalidArguments
-
 		array{object,dict} GetCalls()
 
 			Get an array of call object paths and properties
@@ -37,6 +35,12 @@ Methods		dict GetProperties()
 
 			This is usually implemented using the ATD AT command.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.NotImplemented
+					 [service].Error.Failed
+
 		void Transfer()
 
 			Joins the currently Active (or Outgoing, depending
@@ -49,6 +53,10 @@ Methods		dict GetProperties()
 			This functionality is generally implemented by using
 			the +CHLD=4 AT command.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.Failed
+
 		void SwapCalls()
 
 			Swaps Active and Held calls.  The effect of this
@@ -65,6 +73,10 @@ Methods		dict GetProperties()
 			This functionality is generally implemented by using
 			the +CHLD=2 AT command.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.Failed
+
 		void ReleaseAndAnswer()
 
 			Releases currently active call (0 or more) and
@@ -72,6 +84,10 @@ Methods		dict GetProperties()
 			if the current call is a multiparty call, then all
 			parties in the multi-party call will be released.
 
+			Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.Failed
+
 		void HoldAndAnswer()
 
 			Puts the current call (including multi-party calls) on
@@ -80,10 +96,18 @@ Methods		dict GetProperties()
 			Held calls is invalid, since in GSM a user can have
 			only a single Held call at a time.
 
+                        Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.Failed
+
 		void HangupAll()
 
 			Releases all calls.
 
+                        Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.Failed
+
 		array{object} PrivateChat(object call)
 
 			Places the multi-party call on hold and makes desired
@@ -97,6 +121,13 @@ Methods		dict GetProperties()
 
 			This is usually implemented using the +CHLD=2X command.
 
+                        Possible Errors: [service].Error.InProgress
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.NotFound
+					 [service].Error.NotImplemented
+					 [service].Error.Failed
+
 		array{object} CreateMultiparty()
 
 			Joins active and held calls together into a multi-party
@@ -111,11 +142,19 @@ Methods		dict GetProperties()
 			This is usually implemented using the +CHLD=3 AT
 			command.
 
+                        Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.Failed
+
 		void HangupMultiparty()
 
 			Hangs up the multi-party call.  All participating
 			calls are released.
 
+                        Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.Failed
+
 		void SendTones(string tones)
 
 			Sends the DTMF tones to the network.  The tones have
@@ -123,6 +162,12 @@ Methods		dict GetProperties()
 			'*', '#', 'A', 'B', 'C', 'D'.  The last four are
 			typically not used in normal circumstances.
 
+                        Possible Errors: [service].Error.InProgress
+					 [service].Error.NotImplemented
+					 [service].Error.InvalidArguments
+					 [service].Error.InvalidFormat
+					 [service].Error.Failed
+
 Signals		CallAdded(object path, dict properties)
 
 			Signal that is sent when a new call is added.  It
-- 
1.7.0.4


^ permalink raw reply related

* [PATCH 0/1] Update possible errors
From: Jeevaka Badrappan @ 2011-02-11 11:34 UTC (permalink / raw)
  To: ofono

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

Hi,

  Following patch updates the possible errors to the api documentation.
Possible error values are updated based on currently returned errors.

Regards,
Jeevaka

Jeevaka Badrappan (1):
  doc: Update possible errors

 doc/audio-settings-api.txt         |    2 -
 doc/call-barring-api.txt           |   31 ++++++++++++++++++++++
 doc/call-forwarding-api.txt        |   16 +++++++++++
 doc/call-meter-api.txt             |   14 ++++++++++
 doc/call-settings-api.txt          |    8 ++++++
 doc/call-volume-api.txt            |    9 +++---
 doc/cdma-voicecall-manager-api.txt |   10 +++++++
 doc/cell-broadcast-api.txt         |    7 ++---
 doc/connman-api.txt                |   25 ++++++++++++++----
 doc/manager-api.txt                |    2 -
 doc/message-api.txt                |    2 -
 doc/message-waiting-api.txt        |    7 +++--
 doc/messagemanager-api.txt         |   14 ++++++++--
 doc/modem-api.txt                  |   10 ++++---
 doc/network-api.txt                |   16 +++++++----
 doc/phonebook-api.txt              |    2 +-
 doc/pushnotification-api.txt       |    8 ++++++
 doc/radio-settings-api.txt         |    9 +++---
 doc/sim-api.txt                    |   37 +++++++++++++++++++++++++-
 doc/stk-api.txt                    |   17 +++++++-----
 doc/supplementaryservices-api.txt  |   20 +++++++++++---
 doc/voicecall-api.txt              |   17 +++++++++++-
 doc/voicecallmanager-api.txt       |   49 ++++++++++++++++++++++++++++++++++-
 23 files changed, 273 insertions(+), 59 deletions(-)


^ permalink raw reply

* Re: About OpenNebula and XCP integration Pt2
From: Tim Deegan @ 2011-02-11 11:33 UTC (permalink / raw)
  To: Tino Vazquez; +Cc: xen-api
In-Reply-To: <AANLkTimSabucVohMKQ+EbyzaOsU9UUc9XbR9VQO9ya9K@mail.gmail.com>

Hi, 

At 11:26 +0000 on 11 Feb (1297423594), Tino Vazquez wrote:
> First of all, many thanks for the valuable pointers given as answers
> to my last email, that really helped deciding which method to chose
> for integration. We are examining the XAPI to better understand our
> chances. After trying out and reading the doc, I still have some
> doubts that I will lay out in this email:

All of these questions will do better on the xen-api@lists.xensource.com 
mailing list (cc'd), which is where xapi development happens. 

Cheers,

Tim.

> * Is it possible to add users other than with Active Directory? Ho can
> I achieve that using the API? Is it possible to do so xi "xe"?
> * Is it possible to create a VM from previously existing VDIs? What
> parameters should I fill? In my tests, the created VM doesn't find the
> hard disk, these are my steps:
> 
>      * Create vm with xe vm-create
>      * Attach a disk via XenCenter (how can I perform this operation with xe?)
>      * Set a PV-kernel (do it need  to be in /boot/guest/?)
> 
> * Do I need to create VMs off templates?
> * Can I attach a CDROM device using xe?
> 
> Sorry for the extensive list of questions, I tried to keep it to a
> minimum (honest!).
> 
> Many thanks in advance, even brief answers will speed up the
> integration process,
> 
> -Tino
> 
> --
> Constantino Vázquez Blanco, MSc
> OpenNebula Major Contributor  / Cloud Researcher
> www.OpenNebula.org | @tinova79
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

^ permalink raw reply

* reboot not working on linux-2.6.37 for ARMv7
From: shiraz hashim @ 2011-02-11 11:31 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

I am using linux-2.6.37 on our ARM Cortex A9 (dual core) SMP platform
with PL310 as Level 2 cache. We observe that on reboot the control
is not able to reach to the arch_reset.

The problem happens when L1 cache is disabled in
arm_machine_restart, through cpu_proc_fin() and L2 cache is flushed.
L2 cache flushing takes a spinlock and our platform doesnot have monitor
support at L2 thus failing strex instruction. The strex (and hence spin locks)
behave sanely when L1 is enabled as monitor associated with SCU takes
care of it.

-- 
regards
Shiraz Hashim

^ permalink raw reply

* About OpenNebula and XCP integration Pt2
From: Tino Vazquez @ 2011-02-11 11:26 UTC (permalink / raw)
  To: xen-devel

Dear all,

First of all, many thanks for the valuable pointers given as answers
to my last email, that really helped deciding which method to chose
for integration. We are examining the XAPI to better understand our
chances. After trying out and reading the doc, I still have some
doubts that I will lay out in this email:

* Is it possible to add users other than with Active Directory? Ho can
I achieve that using the API? Is it possible to do so xi "xe"?
* Is it possible to create a VM from previously existing VDIs? What
parameters should I fill? In my tests, the created VM doesn't find the
hard disk, these are my steps:

     * Create vm with xe vm-create
     * Attach a disk via XenCenter (how can I perform this operation with xe?)
     * Set a PV-kernel (do it need  to be in /boot/guest/?)

* Do I need to create VMs off templates?
* Can I attach a CDROM device using xe?

Sorry for the extensive list of questions, I tried to keep it to a
minimum (honest!).

Many thanks in advance, even brief answers will speed up the
integration process,

-Tino

--
Constantino Vázquez Blanco, MSc
OpenNebula Major Contributor  / Cloud Researcher
www.OpenNebula.org | @tinova79

^ permalink raw reply

* Re: [PATCH 3/3] ASoC: Add support for AIF channel muxing on WM8903
From: Mark Brown @ 2011-02-11 11:26 UTC (permalink / raw)
  To: Stephen Warren
  Cc: alsa-devel@alsa-project.org, patches@opensource.wolfsonmicro.com,
	Liam Girdwood
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF0310F6050C@HQMAIL01.nvidia.com>

On Thu, Feb 10, 2011 at 02:59:17PM -0800, Stephen Warren wrote:

> However, if I flip the Right Capture Mux to setting Left (while not capturing),
> then this breaks case (3) above; the initial portion of the recording is fine,
> but when I remove and plug the mic back in, something isn't turned on, and so
> nothing is recorded after that.

That's just bizzare; I can't off the top of my head think of any reason
for it and I'm out of the office today so can't test.

Does the left channel data stay OK (assuming you're mapping the data
through on both channels)?

^ permalink raw reply

* Re: [PATCH] Add a test case into intel-gpu-tools for intel display driver validation.
From: Chris Wilson @ 2011-02-11 11:24 UTC (permalink / raw)
  To: hai.lan, intel-gfx
In-Reply-To: <1297440855-18493-1-git-send-email-hai.lan@intel.com>

On Fri, 11 Feb 2011 11:14:15 -0500, hai.lan@intel.com wrote:
> From: Hai Lan <hai.lan@intel.com>
> 
> We have not a unified tool to check Intel display driver and we plan to use
> intel-gpu-tools/testdisplay to check Intel display driver even though some
> function tests can be found in libdrm/test. 3 new features are added:test
> all supported modes, force mode and dump mode info(dump mode info is based on
> libdrm/tests/modetest).

Thanks for the explanation!

There was still some whitespacing issues and a major mangling of the loop
over test modes. Applied and fixed up.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

^ permalink raw reply


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.