21 Feb, 2013
1 commit
-
Linux 3.8-rc7
* tag 'v3.8-rc7': (12052 commits)
Linux 3.8-rc7
net: sctp: sctp_endpoint_free: zero out secret key data
net: sctp: sctp_setsockopt_auth_key: use kzfree instead of kfree
atm/iphase: rename fregt_t -> ffreg_t
ARM: 7641/1: memory: fix broken mmap by ensuring TASK_UNMAPPED_BASE is aligned
ARM: DMA mapping: fix bad atomic test
ARM: realview: ensure that we have sufficient IRQs available
ARM: GIC: fix GIC cpumask initialization
net: usb: fix regression from FLAG_NOARP code
l2tp: dont play with skb->truesize
net: sctp: sctp_auth_key_put: use kzfree instead of kfree
netback: correct netbk_tx_err to handle wrap around.
xen/netback: free already allocated memory on failure in xen_netbk_get_requests
xen/netback: don't leak pages on failure in xen_netbk_tx_check_gop.
xen/netback: shutdown the ring if it contains garbage.
drm/ttm: fix fence locking in ttm_buffer_object_transfer, 2nd try
virtio_console: Don't access uninitialized data.
net: qmi_wwan: add more Huawei devices, including E320
net: cdc_ncm: add another Huawei vendor specific device
ipv6/ip6_gre: fix error case handling in ip6gre_tunnel_xmit()
...
04 Jan, 2013
1 commit
-
CONFIG_HOTPLUG is going away as an option. As a result, the __dev*
markings need to be removed.This change removes the use of __devinit, __devexit_p, and __devexit
from these drivers.Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.Cc: Bill Pemberton
Cc: Doug Thompson
Cc: Borislav Petkov
Cc: Mark Gross
Cc: Jason Uhlenkott
Cc: Mauro Carvalho Chehab
Cc: Tim Small
Cc: Ranganathan Desikan
Cc: "Arvind R."
Cc: Ralf Baechle
Cc: David Daney
Cc: Egor Martovetsky
Cc: Olof Johansson
Cc: Chris Metcalf
Signed-off-by: Greg Kroah-Hartman
21 Dec, 2012
1 commit
-
Remove size from lookup arrays and mark them as const.
Reviewed-by: Jesper Juhl
Signed-off-by: Niklas Söderlund
Signed-off-by: Mauro Carvalho Chehab
28 Nov, 2012
1 commit
-
The i7core_edac addrmatch_dev and chancounts_dev have sysfs files
associated with them. The sysfs files, however, are coded so that the
parent device is is the mci device. This is incorrect and the mci struct
should be obtained through the addrmatch_dev and chancounts_dev device's
private data field which is populated in i7core_create_sysfs_devices().Signed-off-by: Prarit Bhargava
Signed-off-by: Mauro Carvalho Chehab
30 Jul, 2012
1 commit
-
* devel: (33 commits)
edac i5000, i5400: fix pointer math in i5000_get_mc_regs()
edac: allow specifying the error count with fake_inject
edac: add support for Calxeda highbank L2 cache ecc
edac: add support for Calxeda highbank memory controller
edac: create top-level debugfs directory
sb_edac: properly handle error count
i7core_edac: properly handle error count
edac: edac_mc_handle_error(): add an error_count parameter
edac: remove arch-specific parameter for the error handler
amd64_edac: Don't pass driver name as an error parameter
edac_mc: check for allocation failure in edac_mc_alloc()
edac: Increase version to 3.0.0
edac_mc: Cleanup per-dimm_info debug messages
edac: Convert debugfX to edac_dbg(X,
edac: Use more normal debugging macro style
edac: Don't add __func__ or __FILE__ for debugf[0-9] msgs
Edac: Add ABI Documentation for the new device nodes
edac: move documentation ABI to ABI/testing/sysfs-devices-edac
i7core_edac: change the mem allocation scheme to make Documentation/kobject.txt happy
edac: change the mem allocation scheme to make Documentation/kobject.txt happy
...
12 Jun, 2012
7 commits
-
Instead of generating a burst of errors or reporting the error
count via driver-specific details, use the new way provided by
edac_mc_handle_error.Signed-off-by: Mauro Carvalho Chehab
-
In order to avoid loosing error events, it is desirable to group
error events together and generate a single trace for several identical
errors.The trace API already allows reporting multiple errors. Change the
handle_error function to also allow that.The changes at the drivers were made by this small script:
$file .=$_ while (<>);
$file =~ s/(edac_mc_handle_error)\s*\(([^\,]+)\,([^\,]+)\,/$1($2,$3, 1,/g;
print $file;Signed-off-by: Mauro Carvalho Chehab
-
Remove the arch-dependent parameter, as it were not used,
as the MCE tracepoint weren't implemented. It probably doesn't
make sense to have an MCE-specific tracepoint, as this will
cost more bytes at the tracepoint, and tracepoint is not free.The changes at the EDAC drivers were done by this small perl script:
$file .=$_ while (<>);
$file =~ s/(edac_mc_handle_error)\s*\(([^\;]+)\,([^\,\)]+)\s*\)/$1($2)/g;
print $file;Signed-off-by: Mauro Carvalho Chehab
-
Use a more common debugging style.
Remove __FILE__ uses, add missing newlines,
coalesce formats and align arguments.Signed-off-by: Joe Perches
Signed-off-by: Mauro Carvalho Chehab -
The debug macro already adds that. Most of the work here was
made by this small script:$f .=$_ while (<>);
$f =~ s/(debugf[0-9]\s*\(\s*)__FILE__\s*": /\1"/g;
$f =~ s/(debugf[0-9]\s*\(\s*)__FILE__\s*/\1/g;
$f =~ s/(debugf[0-9]\s*\(\s*)__FILE__\s*"MC: /\1"/g;$f =~ s/(debugf[0-9]\s*\(\")\%s[\:\,\(\)]*\s*([^\"]*\s*[^\)]+)__func__\s*\,\s*/\1\2/g;
$f =~ s/(debugf[0-9]\s*\(\")\%s[\:\,\(\)]*\s*([^\"]*\s*[^\)]+),\s*__func__\s*\)/\1\2)/g;
$f =~ s/(debugf[0-9]\s*\(\"MC\:\s*)\%s[\:\,\(\)]*\s*([^\"]*\s*[^\)]+)__func__\s*\,\s*/\1\2/g;
$f =~ s/(debugf[0-9]\s*\(\"MC\:\s*)\%s[\:\,\(\)]*\s*([^\"]*\s*[^\)]+),\s*__func__\s*\)/\1\2)/g;$f =~ s/\"MC\: \\n\"/"MC:\\n"/g;
print $f;
After running the script, manual cleanups were done to fix it the remaining
places.While here, removed the __LINE__ on most places, as it doesn't actually give
useful info on most places.Signed-off-by: Mauro Carvalho Chehab
-
Kernel kobjects have rigid rules: each container object should be
dynamically allocated, and can't be allocated into a single kmalloc.EDAC never obeyed this rule: it has a single malloc function that
allocates all needed data into a single kzalloc.As this is not accepted anymore, change the allocation schema of the
EDAC *_info structs to enforce this Kernel standard.Cc: Aristeu Rozanski
Signed-off-by: Mauro Carvalho Chehab -
Instead of relying on a complex logic inside the edac core to create
a "device tree-like" sysfs struct, just use device_add.Reviewed-by: Aristeu Rozanski
Signed-off-by: Mauro Carvalho Chehab
11 Jun, 2012
2 commits
-
As EDAC doesn't use struct device itself, it created a parent dev
pointer called as "pdev". Now that we'll be converting it to use
struct device, instead of struct devsys, this needs to be fixed.No functional changes.
Reviewed-by: Aristeu Rozanski
Acked-by: Chris Metcalf
Cc: Doug Thompson
Cc: Borislav Petkov
Cc: Mark Gross
Cc: Jason Uhlenkott
Cc: Tim Small
Cc: Ranganathan Desikan
Cc: "Arvind R."
Cc: Olof Johansson
Cc: Egor Martovetsky
Cc: Michal Marek
Cc: Jiri Kosina
Cc: Joe Perches
Cc: Dmitry Eremin-Solenikov
Cc: Benjamin Herrenschmidt
Cc: Hitoshi Mitake
Cc: Andrew Morton
Cc: "Niklas Söderlund"
Cc: Shaohui Xie
Cc: Josh Boyer
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab -
Some edac drivers register themselves as mce decoders via
notifier_chain. But in current notifier_chain implementation logic,
it doesn't accept same notifier registered twice. If so, it will be
wrong when adding/removing the element from the list. For example,
on one SandyBridge platform, remove module sb_edac and then trigger
one error, it will hit oops because it has no mce decoder registered
but related notifier_chain still points to an invalid callback
function. Here is an example:Call Trace:
[] atomic_notifier_call_chain+0x1a/0x20
[] mce_log+0x46/0x180
[] apei_mce_report_mem_error+0x4a/0x60
[] ghes_do_proc+0x192/0x210
[] ghes_proc+0x46/0x70
[] ghes_notify_sci+0x48/0x80
[] notifier_call_chain+0x55/0x80
[] __blocking_notifier_call_chain+0x5a/0x80
[] ? acpi_os_wait_events_complete+0x23/0x23
[] blocking_notifier_call_chain+0x16/0x20
[] acpi_hed_notify+0x19/0x1b
[] acpi_device_notify+0x19/0x1b
[] acpi_ev_notify_dispatch+0x67/0x7f
[] acpi_os_execute_deferred+0x29/0x36
[] process_one_work+0x132/0x450
[] worker_thread+0x17b/0x3c0
[] ? manage_workers+0x120/0x120
[] kthread+0x9e/0xb0
[] kernel_thread_helper+0x4/0x10
[] ? kthread_freezable_should_stop+0x70/0x70
[] ? gs_change+0x13/0x13
Code: f3 49 89 d4 45 85 ed 4d 89 c6 48 8b 0f 74 48 48 85 c9 75 17 eb 41
0f 1f 80 00 00 00 00 41 83 ed 01 4c 89 f9 74 22 4d 85 ff 74 1d 8b
79 08 4c 89 e2 48 89 de 48 89 cf ff 11 4d 85 f6 74 04 41
RIP [] notifier_call_chain+0x46/0x80
RSP
CR2: ffffffffa01af838
---[ end trace 0100930068e73e6f ]---
BUG: unable to handle kernel paging request at fffffffffffffff8
IP: [] kthread_data+0x10/0x20
PGD 1a0d067 PUD 1a0e067 PMD 0
Oops: 0000 [#2] SMPOnly i7core_edac and sb_edac have such issues because they have more
than one memory controller which means they have to register mce
decoder many times.Cc: # 3.2 and upper
Signed-off-by: Chen Gong
Signed-off-by: Mauro Carvalho Chehab
30 May, 2012
1 commit
-
Pull EDAC internal API changes from Mauro Carvalho Chehab:
"This changeset is the first part of a series of patches that fixes the
EDAC sybsystem. On this set, it changes the Kernel EDAC API in order
to properly represent the Intel i3/i5/i7, Xeon 3xxx/5xxx/7xxx, and
Intel E5-xxxx memory controllers.The EDAC core used to assume that:
- the DRAM chip select pin is directly accessed by the memory
controller- when multiple channels are used, they're all filled with the
same type of memory.None of the above premises is true on Intel memory controllers since
2002, when RAMBUS and FB-DIMMs were introduced, and Advanced Memory
Buffer or by some similar technologies hides the direct access to the
DRAM pins.So, the existing drivers for those chipsets had to lie to the EDAC
core, in general telling that just one channel is filled. That
produces some hard to understand error messages like:EDAC MC0: CE row 3, channel 0, label "DIMM1": 1 Unknown error(s): memory read error on FATAL area : cpu=0 Err=0008:00c2 (ch=2), addr = 0xad1f73480 => socket=0, Channel=0(mask=2), rank=1
The location information there (row3 channel 0) is completely bogus:
it has no physical meaning, and are just some random values that the
driver uses to talk with the EDAC core. The error actually happened
at CPU socket 0, channel 0, slot 1, but this is not reported anywhere,
as the EDAC core doesn't know anything about the memory layout. So,
only advanced users that know how the EDAC driver works and that tests
their systems to see how DIMMs are mapped can actually benefit for
such error logs.This patch series fixes the error report logic, in order to allow the
EDAC to expose the memory architecture used by them to the EDAC core.
So, as the EDAC core now understands how the memory is organized, it
can provide an useful report:EDAC MC0: CE memory read error on DIMM1 (channel:0 slot:1 page:0x364b1b offset:0x600 grain:32 syndrome:0x0 - count:1 area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:4)
The location of the DIMM where the error happened is reported by "MC0"
(cpu socket #0), at "channel:0 slot:1" location, and matches the
physical location of the DIMM.There are two remaining issues not covered by this patch series:
- The EDAC sysfs API will still report bogus values. So,
userspace tools like edac-utils will still use the bogus data;- Add a new tracepoint-based way to get the binary information
about the errors.Those are on a second series of patches (also at -next), but will
probably miss the train for 3.5, due to the slow review process."Fix up trivial conflict (due to spelling correction of removed code) in
drivers/edac/edac_device.c* git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac: (42 commits)
i7core: fix ranks information at the per-channel struct
i5000: Fix the fatal error handling
i5100_edac: Fix a warning when compiled with 32 bits
i82975x_edac: Test nr_pages earlier to save a few CPU cycles
e752x_edac: provide more info about how DIMMS/ranks are mapped
i5000_edac: Fix the logic that retrieves memory information
i5400_edac: improve debug messages to better represent the filled memory
edac: Cleanup the logs for i7core and sb edac drivers
edac: Initialize the dimm label with the known information
edac: Remove the legacy EDAC ABI
x38_edac: convert driver to use the new edac ABI
tile_edac: convert driver to use the new edac ABI
sb_edac: convert driver to use the new edac ABI
r82600_edac: convert driver to use the new edac ABI
ppc4xx_edac: convert driver to use the new edac ABI
pasemi_edac: convert driver to use the new edac ABI
mv64x60_edac: convert driver to use the new edac ABI
mpc85xx_edac: convert driver to use the new edac ABI
i82975x_edac: convert driver to use the new edac ABI
i82875p_edac: convert driver to use the new edac ABI
...
29 May, 2012
8 commits
-
There is a flag at the per-channel struct that indicates if there are
any 4R dimm on it. The way the presence of this flag were reported
is not ok, as it might give the false idea that the channel were filled
with 2R memories:[ 580.588701] EDAC DEBUG: get_dimm_config: Ch1 phy rd1, wr1 (0x063f7431): 2 ranks, UDIMMs
[ 580.588704] EDAC DEBUG: get_dimm_config: dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400(in this case, just one 1R memory is filled on channel 1)
So, use a better way to represent the per-channel ranks information.
After the patch, it will show:[ 2002.233978] EDAC DEBUG: get_dimm_config: Ch0 phy rd0, wr0 (0x063f7431): UDIMMs
[ 2002.233982] EDAC DEBUG: get_dimm_config: dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
[ 2002.233988] EDAC DEBUG: get_dimm_config: dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400(in this case, there isn't any 4R memories)
Reported-by: Borislav Petkov
Signed-off-by: Mauro Carvalho Chehab -
Remove some information that it is duplicated at the MCE log,
and don't have much usage for the error. Those data will be
added again, when creating a trace function that outputs both
memory errors and MCE fields.Cc: Aristeu Rozanski
Signed-off-by: Mauro Carvalho Chehab -
Now that all drivers got converted to use the new ABI, we can
drop the old one.Acked-by: Chris Metcalf
Signed-off-by: Mauro Carvalho Chehab -
The legacy edac ABI is going to be removed. Port the driver to use
and benefit from the new API functionality.Signed-off-by: Mauro Carvalho Chehab
-
The number of pages is a dimm property. Move it to the dimm struct.
After this change, it is possible to add sysfs nodes for the DIMM's that
will properly represent the DIMM stick properties, including its size.A TODO fix here is to properly represent dual-rank/quad-rank DIMMs when
the memory controller represents the memory via chip select rows.Reviewed-by: Aristeu Rozanski
Acked-by: Borislav Petkov
Acked-by: Chris Metcalf
Cc: Doug Thompson
Cc: Mark Gross
Cc: Jason Uhlenkott
Cc: Tim Small
Cc: Ranganathan Desikan
Cc: "Arvind R."
Cc: Olof Johansson
Cc: Egor Martovetsky
Cc: Michal Marek
Cc: Jiri Kosina
Cc: Joe Perches
Cc: Dmitry Eremin-Solenikov
Cc: Benjamin Herrenschmidt
Cc: Hitoshi Mitake
Cc: Andrew Morton
Cc: "Niklas Söderlund"
Cc: Shaohui Xie
Cc: Josh Boyer
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab -
Almost all edac drivers initialize csrow_info->first_page,
csrow_info->last_page and csrow_info->page_mask. Those vars are
used inside the EDAC core, in order to calculate the csrow affected
by an error, by using the routine edac_mc_find_csrow_by_page().However, very few drivers actually use it:
e752x_edac.c
e7xxx_edac.c
i3000_edac.c
i82443bxgx_edac.c
i82860_edac.c
i82875p_edac.c
i82975x_edac.c
r82600_edac.cThere also a few other drivers that have their own calculus
formula internally using those vars.All the others are just wasting time by initializing those
data.While initializing data without using them won't cause any troubles, as
those information is stored at the wrong place (at csrows structure), it
is better to remove what is unused, in order to simplify the next patch.Reviewed-by: Aristeu Rozanski
Acked-by: Borislav Petkov
Acked-by: Chris Metcalf
Cc: Doug Thompson
Cc: Hitoshi Mitake
Cc: Andrew Morton
Cc: "Niklas Söderlund"
Cc: Josh Boyer
Cc: Jiri Kosina
Signed-off-by: Mauro Carvalho Chehab -
On systems based on chip select rows, all channels need to use memories
with the same properties, otherwise the memories on channels A and B
won't be recognized.However, such assumption is not true for all types of memory
controllers.Controllers for FB-DIMM's don't have such requirements.
Also, modern Intel controllers seem to be capable of handling such
differences.So, we need to get rid of storing the DIMM information into a per-csrow
data, storing it, instead at the right place.The first step is to move grain, mtype, dtype and edac_mode to the
per-dimm struct.Reviewed-by: Aristeu Rozanski
Reviewed-by: Borislav Petkov
Acked-by: Chris Metcalf
Cc: Doug Thompson
Cc: Borislav Petkov
Cc: Mark Gross
Cc: Jason Uhlenkott
Cc: Tim Small
Cc: Ranganathan Desikan
Cc: "Arvind R."
Cc: Olof Johansson
Cc: Egor Martovetsky
Cc: Michal Marek
Cc: Jiri Kosina
Cc: Joe Perches
Cc: Dmitry Eremin-Solenikov
Cc: Benjamin Herrenschmidt
Cc: Hitoshi Mitake
Cc: Andrew Morton
Cc: James Bottomley
Cc: "Niklas Söderlund"
Cc: Shaohui Xie
Cc: Josh Boyer
Cc: Mike Williams
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab -
The way a DIMM is currently represented implies that they're
linked into a per-csrow struct. However, some drivers don't see
csrows, as they're ridden behind some chip like the AMB's
on FBDIMM's, for example.This forced drivers to fake^Wvirtualize a csrow struct, and to create
a mess under csrow/channel original's concept.Move the DIMM labels into a per-DIMM struct, and add there
the real location of the socket, in terms of csrow/channel.
Latter patches will modify the location to properly represent the
memory architecture.All other drivers will use a per-csrow type of location.
Some of those drivers will require a latter conversion, as
they also fake the csrows internally.TODO: While this patch doesn't change the existing behavior, on
csrows-based memory controllers, a csrow/channel pair points to a memory
rank. There's a known bug at the EDAC core that allows having different
labels for the same DIMM, if it has more than one rank. A latter patch
is need to merge the several ranks for a DIMM into the same dimm_info
struct, in order to avoid having different labels for the same DIMM.The edac_mc_alloc() will now contain a per-dimm initialization loop that
will be changed by latter patches in order to match other types of
memory architectures.Reviewed-by: Aristeu Rozanski
Reviewed-by: Borislav Petkov
Cc: Doug Thompson
Cc: Ranganathan Desikan
Cc: "Arvind R."
Cc: "Niklas Söderlund"
Signed-off-by: Mauro Carvalho Chehab
30 Apr, 2012
1 commit
-
Signed-off-by: David Mackey
Signed-off-by: Vinson Lee
Acked-by: Randy Dunlap
Signed-off-by: Jiri Kosina
19 Mar, 2012
1 commit
-
These const tables are currently marked __devinitdata, but
Documentation/PCI/pci.txt says:"o The ID table array should be marked __devinitconst; this is done
automatically if the table is declared with DEFINE_PCI_DEVICE_TABLE()."So use DEFINE_PCI_DEVICE_TABLE(x).
Based on PaX and earlier work by Andi Kleen.
Signed-off-by: Lionel Debroux
Signed-off-by: Borislav Petkov
14 Dec, 2011
1 commit
-
No functionality change, this is done so that in a follow-on patch all
queued-up MCEs can be decoded after registering on the chain.Signed-off-by: Borislav Petkov
01 Nov, 2011
11 commits
-
Signed-off-by: Mauro Carvalho Chehab
-
on i386:
ERROR: "__udivdi3" [drivers/edac/i7core_edac.ko] undefined!\In both get_sdram_scrub_rate() and set_sdram_scrub_rate()
Reported-by: Randy Dunlap
Signed-off-by: Mauro Carvalho Chehab -
Get a more reliable DCLK value from DMI, name the SCRUBINTERVAL mask
and guard against potential overflow in the scrub rate computations.Signed-off-by: Nils Carlson
-
Nehalem-EX uses a different memory controller. However, as the
memory controller is not visible on some Nehalem/Nehalem-EP, we
need to indirectly probe via a X58 PCI device. The same devices
are found on (some) Nehalem-EX. So, on those machines, the
probe routine needs to return -ENODEV, as the actual Memory
Controller registers won't be detected.Signed-off-by: Mauro Carvalho Chehab
-
Signed-off-by: Mauro Carvalho Chehab
-
Remove edac_mce pieces and use the normal MCE decoder notifier chain by
retaining the same functionality with considerably less code.Signed-off-by: Borislav Petkov
Signed-off-by: Mauro Carvalho Chehab -
mce->socketid and cpu_data(mce->cpu).phys_proc_id are the same,
compare with mce_setup (in mce.c):
m->cpu = m->extcpu = smp_processor_id();
...
m->socketid = cpu_data(m->extcpu).phys_proc_id;This makes it easier for example for XEN patches to hook into
the MCE subsystem.
Compile tested on x86_64.Signed-off-by: Thomas Renninger
CC: JBeulich@novell.com
CC: linux-edac@vger.kernel.org
CC: Mauro Carvalho Chehab -
Xeon 35xx doesn't mention memory scrub. It seems that only Xeon 55xx
and above supports it.Signed-off-by: Mauro Carvalho Chehab
-
Add scrubbing support to i7core_edac, tested on intel Xeon L5638.
Signed-off-by: Samuel Gabrielsson
Signed-off-by: Mauro Carvalho Chehab -
Error injection needs the pci device 0:0. So, we need to revert
this changeset: 79daef2099a02fed35747c23bad22f30441133ea.Tests need to be made to be sure that refcount won't be wrong
as noticed before.Signed-off-by: Mauro Carvalho Chehab
-
CC: Mauro Carvalho Chehab
Signed-off-by: David Sterba
Signed-off-by: Mauro Carvalho Chehab
19 Aug, 2011
1 commit
-
Based on a patch from the PaX Team, found during a clang analysis pass.
Signed-off-by: Mathias Krause
Acked-by: Mauro Carvalho Chehab
Cc: PaX Team
Cc: stable@kernel.org [v2.6.35+]
Signed-off-by: Linus Torvalds
27 May, 2011
1 commit
-
* 'trivial' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6:
gfs2: Drop __TIME__ usage
isdn/diva: Drop __TIME__ usage
atm: Drop __TIME__ usage
dlm: Drop __TIME__ usage
wan/pc300: Drop __TIME__ usage
parport: Drop __TIME__ usage
hdlcdrv: Drop __TIME__ usage
baycom: Drop __TIME__ usage
pmcraid: Drop __DATE__ usage
edac: Drop __DATE__ usage
rio: Drop __DATE__ usage
scsi/wd33c93: Drop __TIME__ usage
scsi/in2000: Drop __TIME__ usage
aacraid: Drop __TIME__ usage
media/cx231xx: Drop __TIME__ usage
media/radio-maxiradio: Drop __TIME__ usage
nozomi: Drop __TIME__ usage
cyclades: Drop __TIME__ usage
19 Apr, 2011
1 commit
-
The kernel already prints its build timestamp during boot, no need to
repeat it in random drivers and produce different object files each
time.Cc: Doug Thompson
Cc: bluesmoke-devel@lists.sourceforge.net
Cc: linux-edac@vger.kernel.org
Acked-by: Mauro Carvalho Chehab
Signed-off-by: Michal Marek
