Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history 
yaml
---
r: 139776
b: refs/heads/master
c: a7a5eb9
h: refs/heads/master
v: v3
  • Loading branch information
Jaswinder Singh Rajput committed Mar 30, 2009
1 parent 358f409 commit 96e519e
Show file tree
Hide file tree
Showing 1,797 changed files with 41,554 additions and 110,753 deletions.
2 changes: 1 addition & 1 deletion [refs]
View file
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: 377f0a08e4cb56658d878d22c3aed4716e283c6b
refs/heads/master: a7a5eb9d4eb9908709df66e8f8f1724b5b108258
6 changes: 0 additions & 6 deletions trunk/Documentation/DocBook/mac80211.tmpl
View file
Original file line number Diff line number Diff line change
Expand Up @@ -227,12 +227,6 @@ usage should require reading the full document.
!Pinclude/net/mac80211.h Powersave support
</chapter>

<chapter id="beacon-filter">
<title>Beacon filter support</title>
!Pinclude/net/mac80211.h Beacon filter support
!Finclude/net/mac80211.h ieee80211_beacon_loss
</chapter>

<chapter id="qos">
<title>Multiple queues and QoS support</title>
<para>TBD</para>
Expand Down
8 changes: 4 additions & 4 deletions trunk/Documentation/arm/Samsung-S3C24XX/Suspend.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -40,13 +40,13 @@ Resuming
Machine Support
---------------

The machine specific functions must call the s3c_pm_init() function
The machine specific functions must call the s3c2410_pm_init() function
to say that its bootloader is capable of resuming. This can be as
simple as adding the following to the machine's definition:

INITMACHINE(s3c_pm_init)
INITMACHINE(s3c2410_pm_init)

A board can do its own setup before calling s3c_pm_init, if it
A board can do its own setup before calling s3c2410_pm_init, if it
needs to setup anything else for power management support.

There is currently no support for over-riding the default method of
Expand Down Expand Up @@ -74,7 +74,7 @@ statuc void __init machine_init(void)

enable_irq_wake(IRQ_EINT0);

s3c_pm_init();
s3c2410_pm_init();
}


Expand Down
9 changes: 1 addition & 8 deletions trunk/Documentation/arm/memory.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -29,14 +29,7 @@ ffff0000 ffff0fff CPU vector page.
CPU supports vector relocation (control
register V bit.)

fffe0000 fffeffff XScale cache flush area. This is used
in proc-xscale.S to flush the whole data
cache. Free for other usage on non-XScale.

fff00000 fffdffff Fixmap mapping region. Addresses provided
by fix_to_virt() will be located here.

ffc00000 ffefffff DMA memory mapping region. Memory returned
ffc00000 fffeffff DMA memory mapping region. Memory returned
by the dma_alloc_xxx functions will be
dynamically mapped here.

Expand Down
6 changes: 3 additions & 3 deletions trunk/Documentation/cputopology.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -18,11 +18,11 @@ For an architecture to support this feature, it must define some of
these macros in include/asm-XXX/topology.h:
#define topology_physical_package_id(cpu)
#define topology_core_id(cpu)
#define topology_thread_cpumask(cpu)
#define topology_core_cpumask(cpu)
#define topology_thread_siblings(cpu)
#define topology_core_siblings(cpu)

The type of **_id is int.
The type of siblings is (const) struct cpumask *.
The type of siblings is cpumask_t.

To be consistent on all architectures, include/linux/topology.h
provides default definitions for any of the above macros that are
Expand Down
6 changes: 0 additions & 6 deletions trunk/Documentation/devices.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3145,12 +3145,6 @@ Your cooperation is appreciated.
1 = /dev/blockrom1 Second ROM card's translation layer interface
...

260 char OSD (Object-based-device) SCSI Device
0 = /dev/osd0 First OSD Device
1 = /dev/osd1 Second OSD Device
...
255 = /dev/osd255 256th OSD Device

**** ADDITIONAL /dev DIRECTORY ENTRIES

This section details additional entries that should or may exist in
Expand Down
40 changes: 6 additions & 34 deletions trunk/Documentation/feature-removal-schedule.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,47 +6,20 @@ be removed from this file.

---------------------------

What: The ieee80211_regdom module parameter
When: March 2010 / desktop catchup

Why: This was inherited by the CONFIG_WIRELESS_OLD_REGULATORY code,
and currently serves as an option for users to define an
ISO / IEC 3166 alpha2 code for the country they are currently
present in. Although there are userspace API replacements for this
through nl80211 distributions haven't yet caught up with implementing
decent alternatives through standard GUIs. Although available as an
option through iw or wpa_supplicant its just a matter of time before
distributions pick up good GUI options for this. The ideal solution
would actually consist of intelligent designs which would do this for
the user automatically even when travelling through different countries.
Until then we leave this module parameter as a compromise.

When userspace improves with reasonable widely-available alternatives for
this we will no longer need this module parameter. This entry hopes that
by the super-futuristically looking date of "March 2010" we will have
such replacements widely available.

Who: Luis R. Rodriguez <lrodriguez@atheros.com>

---------------------------

What: CONFIG_WIRELESS_OLD_REGULATORY - old static regulatory information
When: March 2010 / desktop catchup

What: old static regulatory information and ieee80211_regdom module parameter
When: 2.6.29
Why: The old regulatory infrastructure has been replaced with a new one
which does not require statically defined regulatory domains. We do
not want to keep static regulatory domains in the kernel due to the
the dynamic nature of regulatory law and localization. We kept around
the old static definitions for the regulatory domains of:

* US
* JP
* EU

and used by default the US when CONFIG_WIRELESS_OLD_REGULATORY was
set. We will remove this option once the standard Linux desktop catches
up with the new userspace APIs we have implemented.

set. We also kept around the ieee80211_regdom module parameter in case
some applications were relying on it. Changing regulatory domains
can now be done instead by using nl80211, as is done with iw.
Who: Luis R. Rodriguez <lrodriguez@atheros.com>

---------------------------
Expand Down Expand Up @@ -340,8 +313,7 @@ Who: Krzysztof Piotr Oledzki <ole@ans.pl>
---------------------------

What: i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client()
When: 2.6.30
Check: i2c_attach_client i2c_detach_client
When: 2.6.29 (ideally) or 2.6.30 (more likely)
Why: Deprecated by the new (standard) device driver binding model. Use
i2c_driver->probe() and ->remove() instead.
Who: Jean Delvare <khali@linux-fr.org>
Expand Down
12 changes: 4 additions & 8 deletions trunk/Documentation/i2c/busses/i2c-nforce2
View file
Original file line number Diff line number Diff line change
Expand Up @@ -7,14 +7,10 @@ Supported adapters:
* nForce3 250Gb MCP 10de:00E4
* nForce4 MCP 10de:0052
* nForce4 MCP-04 10de:0034
* nForce MCP51 10de:0264
* nForce MCP55 10de:0368
* nForce MCP61 10de:03EB
* nForce MCP65 10de:0446
* nForce MCP67 10de:0542
* nForce MCP73 10de:07D8
* nForce MCP78S 10de:0752
* nForce MCP79 10de:0AA2
* nForce4 MCP51 10de:0264
* nForce4 MCP55 10de:0368
* nForce4 MCP61 10de:03EB
* nForce4 MCP65 10de:0446

Datasheet: not publicly available, but seems to be similar to the
AMD-8111 SMBus 2.0 adapter.
Expand Down
2 changes: 1 addition & 1 deletion trunk/Documentation/i2c/busses/i2c-piix4
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ Supported adapters:
* Intel 82371AB PIIX4 and PIIX4E
* Intel 82443MX (440MX)
Datasheet: Publicly available at the Intel website
* ServerWorks OSB4, CSB5, CSB6, HT-1000 and HT-1100 southbridges
* ServerWorks OSB4, CSB5, CSB6 and HT-1000 southbridges
Datasheet: Only available via NDA from ServerWorks
* ATI IXP200, IXP300, IXP400, SB600, SB700 and SB800 southbridges
Datasheet: Not publicly available
Expand Down
167 changes: 0 additions & 167 deletions trunk/Documentation/i2c/instantiating-devices
View file

This file was deleted.

19 changes: 4 additions & 15 deletions trunk/Documentation/i2c/writing-clients
View file
Original file line number Diff line number Diff line change
Expand Up @@ -207,26 +207,15 @@ You simply have to define a detect callback which will attempt to
identify supported devices (returning 0 for supported ones and -ENODEV
for unsupported ones), a list of addresses to probe, and a device type
(or class) so that only I2C buses which may have that type of device
connected (and not otherwise enumerated) will be probed. For example,
a driver for a hardware monitoring chip for which auto-detection is
needed would set its class to I2C_CLASS_HWMON, and only I2C adapters
with a class including I2C_CLASS_HWMON would be probed by this driver.
Note that the absence of matching classes does not prevent the use of
a device of that type on the given I2C adapter. All it prevents is
auto-detection; explicit instantiation of devices is still possible.
connected (and not otherwise enumerated) will be probed. The i2c
core will then call you back as needed and will instantiate a device
for you for every successful detection.

Note that this mechanism is purely optional and not suitable for all
devices. You need some reliable way to identify the supported devices
(typically using device-specific, dedicated identification registers),
otherwise misdetections are likely to occur and things can get wrong
quickly. Keep in mind that the I2C protocol doesn't include any
standard way to detect the presence of a chip at a given address, let
alone a standard way to identify devices. Even worse is the lack of
semantics associated to bus transfers, which means that the same
transfer can be seen as a read operation by a chip and as a write
operation by another chip. For these reasons, explicit device
instantiation should always be preferred to auto-detection where
possible.
quickly.


Device Deletion
Expand Down
Loading

0 comments on commit 96e519e

Please sign in to comment.