Re: [PATCH v2 3/3] PM: Introduce Intel PowerClamp Driver
On Mon, 2012-11-26 at 06:37 -0800, Jacob Pan wrote:
> Intel PowerClamp driver performs synchronized idle injection across
> all online CPUs. The goal is to maintain a given package level C-state
> ratio.
trivial notes:
> diff --git a/drivers/thermal/intel_powerclamp.c
> b/drivers/thermal/intel_powerclamp.c
You should still add #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
before any include so that all messages are prefixed with powerclamp:
> +
> +/* #define DEBUG */
> +
> +#include
> +#include
[]
> +static void adjust_compensation(int target_ratio, unsigned int win)
> +{
> + int delta;
It'd be shorter code to use a temporary like
struct powerclamp_calibration_data *d = &cal_data[target_ratio];
> +
> + /*
> + * adjust compensations if confidence level has not been reached or
> + * there are too many wakeups during the last idle injection period, we
> + * cannot trust the data for compensation.
> + */
> + if (cal_data[target_ratio].confidence >= CONFIDENCE_OK ||
> + atomic_read(&idle_wakeup_counter) >
> + win * num_online_cpus())
> + return;
> +
> + delta = set_target_ratio - current_ratio;
> + /* filter out bad data */
> + if (delta >= 0 && delta <= (1+target_ratio/10)) {
> + if (cal_data[target_ratio].steady_comp)
> + cal_data[target_ratio].steady_comp =
> + roundup(delta+
> + cal_data[target_ratio].steady_comp,
> + 2)/2;
so that this fits on a single line and becomes:
if (d->steady_comp)
d->steady_comp = roundup(delta + d->steady_comp, 2) / 2;
etc.
What clamps target_ratio to the correct range?
I briefly scanned the code but didn't spot it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm: tegra: Add maintainers entry
On Wed, 2012-11-28 at 12:10 +0100, Thierry Reding wrote: > Add myself as the maintainer of the NVIDIA Tegra DRM driver. > diff --git a/MAINTAINERS b/MAINTAINERS [] > @@ -2504,6 +2504,14 @@ S: Supported > F: drivers/gpu/drm/exynos > F: include/drm/exynos* > > +NVIDIA TEGRA DRM DRIVER Alphabetic order please Maybe DRM DRIVER FOR NVIDIA TEGRA if you really want to use this file location > +M: Thierry Reding > +L: dri-de...@lists.freedesktop.org > +T: git://gitorious.org/thierryreding/linux.git T: git git://gitorious.org/thierryreding/linux.git > +S: Maintained > +F: drivers/gpu/drm/tegra F: drivers/gpu/drm/tegra/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/23] media: Replace memcpy with struct assignment
On Wed, 2012-11-28 at 16:06 -0300, Ezequiel Garcia wrote: > On Tue, Oct 23, 2012 at 4:57 PM, Ezequiel Garcia > wrote: > > This is a large patchset that replaces struct memcpy with struct assignment, > > whenever possible at drivers/media. [] > > A simplified version of the semantic match that finds > > this problem is as follows: (http://coccinelle.lip6.fr/) > > > > // > > @@ > > identifier struct_name; > > struct struct_name to; > > struct struct_name from; > > expression E; > > @@ > > -memcpy(&(to), &(from), E); > > +to = from; > > // [] > > Comments, feedback and flames are welcome. Thanks! [] > Given we're very near merge window, I'm wondering if you're > considering picking this series. I think you should verify that sizeof is any of sizeof(struct struct_name) or sizeof(*to) or sizeof(*from) and highlight any entries that aren't. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MAINTAINERS: TTY - Add linux-serial mailing list
Signed-off-by: Joe Perches --- MAINTAINERS |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index afc0b27..255dafb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7658,6 +7658,7 @@ K:^Subject:.*(?i)trivial TTY LAYER M: Greg Kroah-Hartman M: Jiri Slaby +L: linux-ser...@vger.kernel.org S: Supported T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git F: drivers/tty/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] cifs: neatening and embedded module size reduction
Joe Perches (3): cifs: Remove unused cEVENT macro cifs: Make CIFS_DEBUG possible to undefine cifs: Enable Kconfig control of CIFS_DEBUG fs/cifs/Kconfig | 10 ++- fs/cifs/cifs_debug.h | 74 + 2 files changed, 53 insertions(+), 31 deletions(-) -- 1.7.8.112.g3fd21 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] cifs: Remove unused cEVENT macro
It uses an undefined KERN_EVENT and is itself unused.
Signed-off-by: Joe Perches
---
fs/cifs/cifs_debug.h |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/fs/cifs/cifs_debug.h b/fs/cifs/cifs_debug.h
index c0c68bb..b0fc344 100644
--- a/fs/cifs/cifs_debug.h
+++ b/fs/cifs/cifs_debug.h
@@ -63,12 +63,6 @@ do { \
/* debug event message: */
extern int cifsERROR;
-#define cEVENT(fmt, arg...)\
-do { \
- if (cifsERROR) \
- printk(KERN_EVENT "%s: " fmt "\n", __FILE__, ##arg);\
-} while (0)
-
/* error event message: e.g., i/o error */
#define cifserror(fmt, arg...) \
do { \
@@ -88,7 +82,6 @@ do { \
*/
#else /* _CIFS_DEBUG */
#define cERROR(set, fmt, arg...)
-#define cEVENT(fmt, arg...)
#define cFYI(set, fmt, arg...)
#define cifserror(fmt, arg...)
#endif /* _CIFS_DEBUG */
--
1.7.8.112.g3fd21
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] cifs: Make CIFS_DEBUG possible to undefine
Make the compilation work again when CIFS_DEBUG is not #define'd.
Add format and argument verification for the various macros when
CIFS_DEBUG is not #define'd.
Signed-off-by: Joe Perches
---
fs/cifs/cifs_debug.h | 64 --
1 files changed, 41 insertions(+), 23 deletions(-)
diff --git a/fs/cifs/cifs_debug.h b/fs/cifs/cifs_debug.h
index b0fc344..4d12fe4 100644
--- a/fs/cifs/cifs_debug.h
+++ b/fs/cifs/cifs_debug.h
@@ -37,6 +37,9 @@ void dump_smb(void *, int);
#define CIFS_RC0x02
#define CIFS_TIMER 0x04
+extern int cifsFYI;
+extern int cifsERROR;
+
/*
* debug ON
*
@@ -44,36 +47,33 @@ void dump_smb(void *, int);
#ifdef CIFS_DEBUG
/* information message: e.g., configuration, major event */
-extern int cifsFYI;
-#define cifsfyi(fmt, arg...) \
+#define cifsfyi(fmt, ...) \
do { \
if (cifsFYI & CIFS_INFO)\
- printk(KERN_DEBUG "%s: " fmt "\n", __FILE__, ##arg);\
+ printk(KERN_DEBUG "%s: " fmt "\n", \
+ __FILE__, ##__VA_ARGS__);\
} while (0)
-#define cFYI(set, fmt, arg...) \
-do { \
- if (set)\
- cifsfyi(fmt, ##arg);\
+#define cFYI(set, fmt, ...)\
+do { \
+ if (set)\
+ cifsfyi(fmt, ##__VA_ARGS__);\
} while (0)
-#define cifswarn(fmt, arg...) \
- printk(KERN_WARNING fmt "\n", ##arg)
-
-/* debug event message: */
-extern int cifsERROR;
+#define cifswarn(fmt, ...) \
+ printk(KERN_WARNING fmt "\n", ##__VA_ARGS__)
/* error event message: e.g., i/o error */
-#define cifserror(fmt, arg...) \
-do { \
- if (cifsERROR) \
- printk(KERN_ERR "CIFS VFS: " fmt "\n", ##arg); \
+#define cifserror(fmt, ...)\
+do { \
+ if (cifsERROR) \
+ printk(KERN_ERR "CIFS VFS: " fmt "\n", ##__VA_ARGS__); \
} while (0)
-#define cERROR(set, fmt, arg...) \
-do { \
- if (set)\
- cifserror(fmt, ##arg); \
+#define cERROR(set, fmt, ...) \
+do { \
+ if (set)\
+ cifserror(fmt, ##__VA_ARGS__); \
} while (0)
/*
@@ -81,9 +81,27 @@ do { \
* -
*/
#else /* _CIFS_DEBUG */
-#define cERROR(set, fmt, arg...)
-#define cFYI(set, fmt, arg...)
-#define cifserror(fmt, arg...)
+#define cifsfyi(fmt, ...) \
+do { \
+ if (0) \
+ printk(KERN_DEBUG "%s: " fmt "\n", \
+ __FILE__, ##__VA_ARGS__);\
+} while (0)
+#define cFYI(set, fmt, ...)\
+do { \
+ if (0 && set) \
+ cifsfyi(fmt, ##__VA_ARGS__);\
+} while (0)
+#define cifserror(fmt, ...)\
+do { \
+ if (0) \
+ printk(KERN_ERR "CIFS VFS: " fmt "\n", ##__VA_ARGS__); \
+} while (0)
+#define cERROR(set, fmt, ...) \
+do { \
+ if (0 && set) \
+ cifserror(fmt, ##__VA_ARGS__); \
+} while (0)
#endif /* _C
[PATCH 3/3] cifs: Enable Kconfig control of CIFS_DEBUG
Rather than havign a permanently enabled #define, allow control over it. This can reduce the size of the module by ~100KB which could be useful for embedded systems. Signed-off-by: Joe Perches --- fs/cifs/Kconfig | 10 +- fs/cifs/cifs_debug.h |5 - 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/fs/cifs/Kconfig b/fs/cifs/Kconfig index 2075ddf..21ff76c 100644 --- a/fs/cifs/Kconfig +++ b/fs/cifs/Kconfig @@ -122,9 +122,17 @@ config CIFS_ACL Allows fetching CIFS/NTFS ACL from the server. The DACL blob is handed over to the application/caller. +config CIFS_DEBUG + bool "Enable CIFS debugging routines" + default y + depends on CIFS + help + Enabling this option adds helpful debugging messages to + the cifs code which increases the size of the cifs module. + If unsure, say Y. config CIFS_DEBUG2 bool "Enable additional CIFS debugging routines" - depends on CIFS + depends on CIFS_DEBUG help Enabling this option adds a few more debugging routines to the cifs code which slightly increases the size of diff --git a/fs/cifs/cifs_debug.h b/fs/cifs/cifs_debug.h index 4d12fe4..6867a7f 100644 --- a/fs/cifs/cifs_debug.h +++ b/fs/cifs/cifs_debug.h @@ -18,7 +18,10 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA * */ -#define CIFS_DEBUG /* BB temporary */ + +#ifdef CONFIG_CIFS_DEBUG +#define CIFS_DEBUG +#endif #ifndef _H_CIFS_DEBUG #define _H_CIFS_DEBUG -- 1.7.8.112.g3fd21 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] checkpatch: Warn when declaring "struct spinlock foo;"
spinlock_t should always be used.
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e0a674f..f27b0b5 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3336,6 +3336,12 @@ sub process {
"Avoid line continuations in quoted strings\n" .
$herecurr);
}
+# check for struct spinlock declarations
+ if ($line =~ /^.\s*\bstruct\s+spinlock\s+\w+\s*;/) {
+ WARN("USE_SPINLOCK_T",
+"struct spinlock should be spinlock_t\n" .
$herecurr);
+ }
+
# Check for misused memsets
if ($^V && $^V ge 5.10.0 &&
defined $stat &&
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] char/tpm: Use true and false for bools
On Thu, 2012-11-29 at 22:08 +0100, Peter Huewe wrote: > Bool initializations should use true and false. Bool tests don't need > comparisons [] > .v3 for this tiny patch... shame on me. Don't be silly... > diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c [] > @@ -545,7 +545,7 @@ static int tpm_tis_init(struct device *dev, > resource_size_t start, > rc = -ENODEV; > goto out_err; > } > - itpm = (probe == 0) ? 0 : 1; > + itpm = !!probe; Even more trivia: This !! isn't necessary as ints assigned to bool are converted by the compiler to 0 or 1. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 00/23] printk: refactoring
On Mon, 2012-11-12 at 15:26 -0800, Andrew Morton wrote: > On Mon, 12 Nov 2012 14:54:10 -0800 > Joe Perches wrote: > > > On Fri, 2012-11-02 at 06:49 -0700, Joe Perches wrote: > > > On Wed, 2012-10-24 at 20:43 -0700, Joe Perches wrote: > > > > Make printk a bit more readable. > > > > > > Andrew? Are you going to apply this again for -next? > > > > Andrew? Any answer? > > Backlogged, not lost. Hopefully this week or next week. > > I trust it has had more thorough compilation coverage testing > than v1? Well, it's getting to be too late for this series. There are a few outstanding patches to printk that should be queued before this restructuring is redone for the next cycle. Kay has some, Jan has some. Likely those should go first. When would be the best time to resubmit and get this into -next? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] aerdrv: Enhanced AER logging
On Thu, 2012-11-29 at 14:54 -0700, Lance Ortiz wrote:
> This patch will provide a more reliable and easy way for user-space
> applications to have access to AER logs rather than reading them from the
> message buffer. It also provides a way to notify user-space when an AER
> event occurs.
[]
> diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c
> index e6defd8..ef1e1c0 100644
> --- a/drivers/acpi/apei/cper.c
> +++ b/drivers/acpi/apei/cper.c
> @@ -281,9 +281,16 @@ static void cper_print_pcie(const char *pfx, const
> struct cper_sec_pcie *pcie,
> "%s""bridge: secondary_status: 0x%04x, control: 0x%04x\n",
> pfx, pcie->bridge.secondary_status, pcie->bridge.control);
> #ifdef CONFIG_ACPI_APEI_PCIEAER
> - if (pcie->validation_bits & CPER_PCIE_VALID_AER_INFO) {
> + dev = pci_get_domain_bus_and_slot(pcie->device_id.segment,
> + pcie->device_id.bus, pcie->device_id.function);
> + if (!dev)
> + pr_info(KERN_INFO, "PCI AER Cannot get PCI device
> %04x:%02x:%02x.%d\n",
> + domain, bus, slot, func);
You've not tried this with CONFIG_ACPI_APEI_PCIEAER enabled.
pr_info("PCI AER Cannot get PCI device %04x:%02x:%02x.%d\n",
domain, bus, slot, func);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 00/23] printk: refactoring
On Thu, 2012-11-29 at 14:21 -0800, Andrew Morton wrote: > On Thu, 29 Nov 2012 14:08:15 -0800 > Joe Perches wrote: > > Well, it's getting to be too late for this series. > > Yeah sorry, stuff got in the way, then people patched printk.c. No worries. > > When would be the best time to resubmit and get this > > into -next? > > I think at rc1. Then if all is OK I'd aim at a merge for rc2 or rc3 > because these patches are rather a pain to keep alive. It's still a scheduling issue with Kay and Jan's patches. Does anyone have any idea if/when those patches are going in? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] aerdrv: Enhanced AER logging
On Thu, 2012-11-29 at 15:58 -0700, Lance Ortiz wrote:
> This patch will provide a more reliable and easy way for user-space
> applications to have access to AER logs rather than reading them from the
> message buffer. It also provides a way to notify user-space when an AER
> event occurs.
[]
> 0 files changed, 0 insertions(+), 0 deletions(-)
Those are odd patch statistics
> diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c
[]
> @@ -249,6 +250,10 @@ static const char *cper_pcie_port_type_strs[] = {
> static void cper_print_pcie(const char *pfx, const struct cper_sec_pcie
> *pcie,
> const struct acpi_hest_generic_data *gdata)
> {
> +#ifdef CONFIG_ACPI_APEI_PCIEAER
> + struct pci_dev *dev;
> +#endif
> +
> if (pcie->validation_bits & CPER_PCIE_VALID_PORT_TYPE)
> printk("%s""port_type: %d, %s\n", pfx, pcie->port_type,
> pcie->port_type < ARRAY_SIZE(cper_pcie_port_type_strs) ?
> @@ -281,9 +286,17 @@ static void cper_print_pcie(const char *pfx, const
> struct cper_sec_pcie *pcie,
> "%s""bridge: secondary_status: 0x%04x, control: 0x%04x\n",
> pfx, pcie->bridge.secondary_status, pcie->bridge.control);
> #ifdef CONFIG_ACPI_APEI_PCIEAER
> - if (pcie->validation_bits & CPER_PCIE_VALID_AER_INFO) {
> + dev = pci_get_domain_bus_and_slot(pcie->device_id.segment,
> + pcie->device_id.bus, pcie->device_id.function);
> + if (!dev)
> + printk("PCI AER Cannot get PCI device %04x:%02x:%02x.%d\n",
> + pcie->device_id.segment, pcie->device_id.bus,
> + pcie->device_id.slot, pcie->device_id.function);
> +
> + if (pcie->validation_bits & CPER_PCIE_VALID_AER_INFO && dev) {
> struct aer_capability_regs *aer_regs = (void *)pcie->aer_info;
> - cper_print_aer(pfx, gdata->error_severity, aer_regs);
> + cper_print_aer(dev, gdata->error_severity, aer_regs);
> + pci_dev_put(dev);
> }
This could be written something like:
dev = etc..
if (!dev) {
pr_err(etc...)
} else if {pcie->validation_bits & ...) {
etc...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bluetooth: use PTR_RET instead of IS_ERR + PTR_ERR
On Mon, 2013-03-18 at 20:05 +0200, Silviu Popescu wrote:
> On Wed, Mar 13, 2013 at 11:31 AM, David Miller wrote:
> > From: Silviu-Mihai Popescu
> > Date: Tue, 12 Mar 2013 20:13:15 +0200
> >
> >> @@ -590,10 +590,7 @@ int __init bt_sysfs_init(void)
> >> bt_debugfs = debugfs_create_dir("bluetooth", NULL);
> >>
> >> bt_class = class_create(THIS_MODULE, "bluetooth");
> >> - if (IS_ERR(bt_class))
> >> - return PTR_ERR(bt_class);
> >> -
> >> - return 0;
> >> + return PTR_RET(bt_class)
> >
> > Don't bother submitting patches you aren't even going to try
> > to compile.
> >
> > I'm rejecting all of your current submissions. Resubmit them
> > when you feel like typing 'make' from time to time.
> >
> >
>
> Sorry for the trouble caused and sorry for the late reply.
> That being said, I'd like to understand a bit better what exactly I messed up.
> I've just pulled the latest revision of the mainline kernel and made
> the changes in this patch.
> I've tried with make defconfig (which would be x86_64_defconfig in my
> case), followed by
> make menuconfig to select the bluetooth options and make allyesconfig.
> Both defconfig and allyesconfig compile successfully on my system.
> Would you be so kind as to tell me what error you have encountered?
> Or perhaps enlighten me as to what I'm still doing wrong. I'd like to
> learn from my mistakes.
You do have to ensure that the file you modify
is actually compiled.
Sometimes it's easier to type make path/file.o
In any case, this is missing the statement terminating
semicolon after PTR_RET(bt_class).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] rbtree_test: use pr_info for module prefix in messages
On Mon, 2013-03-18 at 16:20 -0700, Davidlohr Bueso wrote:
> This provides nicer message output. Since it seems more appropriate
> for the nature of this module, also use KERN_INFO instead of other
> levels.
[]
> diff --git a/lib/rbtree_test.c b/lib/rbtree_test.c
[]
> @@ -153,7 +156,7 @@ static int rbtree_test_init(void)
> int i, j;
> cycles_t time1, time2, time;
>
> - printk(KERN_ALERT "rbtree testing");
> + pr_info("rbtree testing");
>
> prandom_seed_state(&rnd, 3141592653589793238ULL);
> init();
> @@ -171,7 +174,7 @@ static int rbtree_test_init(void)
> time = time2 - time1;
>
> time = div_u64(time, PERF_LOOPS);
> - printk(" -> %llu cycles\n", (unsigned long long)time);
> + pr_info(" -> %llu cycles\n", (unsigned long long)time);
You change the output here by more than just adding a prefix.
The first printk didn't have a newline.
The old code would print:
"rbtree testing -> cycles"
The new code prints:
"rbtree_test: rbtree testing"
"rbtree_test: -> cycles"
btw: each pr_info should have a newline termination
or be followed by a some number of pr_cont/printk with
the last one having a terminating newline.
The first pr_info here doesn't have a newline
so it's possible (though unlikely) that another
thread could have its output appended/interleaved
on the same line.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] rbtree_test: use pr_info for module prefix in messages
On Mon, 2013-03-18 at 16:47 -0700, Davidlohr Bueso wrote:
> On Mon, 2013-03-18 at 16:44 -0700, Joe Perches wrote:
> > On Mon, 2013-03-18 at 16:20 -0700, Davidlohr Bueso wrote:
> > > This provides nicer message output. Since it seems more appropriate
> > > for the nature of this module, also use KERN_INFO instead of other
> > > levels.
> > []
> > > diff --git a/lib/rbtree_test.c b/lib/rbtree_test.c
> > []
> > > @@ -153,7 +156,7 @@ static int rbtree_test_init(void)
> > > int i, j;
> > > cycles_t time1, time2, time;
> > >
> > > - printk(KERN_ALERT "rbtree testing");
> > > + pr_info("rbtree testing");
> > >
> > > prandom_seed_state(&rnd, 3141592653589793238ULL);
> > > init();
> > > @@ -171,7 +174,7 @@ static int rbtree_test_init(void)
> > > time = time2 - time1;
> > >
> > > time = div_u64(time, PERF_LOOPS);
> > > - printk(" -> %llu cycles\n", (unsigned long long)time);
> > > + pr_info(" -> %llu cycles\n", (unsigned long long)time);
> >
> > You change the output here by more than just adding a prefix.
> >
> > The first printk didn't have a newline.
> >
> > The old code would print:
> >
> > "rbtree testing -> cycles"
> >
> > The new code prints:
> >
> > "rbtree_test: rbtree testing"
> > "rbtree_test: -> cycles"
> >
>
> Ah, I see. This is actually the first time I'm using pr_* calls. I
> actually don't mind the new format, it looked
> ok, but if others don't agree, I can always resend it.
Your choice. I don't prefer one over the other.
I do prefer you add an explicit newline to the first
format though instead of relying on the implicit
newline the printk subsystem will emit during the next
pr_ call.
cheers, Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] seq_file: Use seq_puts when seq_printf has only a format with no args
On Mon, 2013-03-18 at 13:59 -0700, Andrew Morton wrote:
> On Sat, 16 Mar 2013 17:54:47 + Al Viro wrote:
>
> > On Sat, Mar 16, 2013 at 06:50:44AM -0700, Joe Perches wrote:
> > > Instead of converting the 800 or so uses of seq_printf with
> > > a constant format (without a % substitution) to seq_puts,
> > > maybe there's another way to slightly speed up these outputs.
> > >
> > > Taking a similar approach to commit abd84d60eb
> > > ("tracing: Optimize trace_printk() with one arg to use trace_puts()")
> > > use the preprocessor to convert seq_printf(seq, "string constant")
> > > to seq_puts(seq, "string constant")
> > >
> > > By stringifying __VA_ARGS__, we can, at compile time, determine
> > > the number of args that are being passed to seq_printf() and
> > > call seq_puts or seq_printf appropriately.
> > >
> > > The actual function definition for seq_printf must now
> > > be enclosed in parenthesis to avoid further macro expansion.
> >
> > Joe, would you mind showing me a single real-world case where that
> > "optimization" would really matter?
>
> There's also a small reduction in code footprint. We merge less
> significant things all day ;)
It's small. ~1kb x86/32 defconfig
$ size def/vmlinux.o*
textdata bss dec hex filename
9296433 661732 1822196 11780361 b3c109 def/vmlinux.o.new
9297361 661732 1822196 11781289 b3c4a9 def/vmlinux.o.old
> > NAKed-because: GAFL
I'm delighted to have a ViroGAFL score of 2.
> Yeah, that macro thing should be nuked from orbit.
It is kinda cute though.
Perhaps it could become something more generic like:
#define __VA_ARGS__EXIST(...) \
({ \
int ret;\
char __va_args__exist[] = __stringify(__VA_ARGS__); \
ret = sizeof(__va_args__exist) != 1;\
ret;\
})
so the hacky ugliness is confined.
> Please let's add the
> checkpatch rule (resend when convenient with clean changelog, please)
> and if people want to send "convert seq_printk to seq_puts" patches to
> Jan and he takes them into the trivial tree then all is good.
I'll resend it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] checkpatch: Prefer seq_puts to seq_printf
Add a check for seq_printf use with a constant format
without additional arguments. Suggest seq_puts instead.
Suggested-by: Bjorn Helgaas
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 16
1 file changed, 16 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index b28cc38..e5b50c5 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -628,6 +628,13 @@ sub sanitise_line {
return $res;
}
+sub get_quoted_string {
+ my ($line, $rawline) = @_;
+
+ return "" if ($line !~ m/(\"[X]+\")/g);
+ return substr($rawline, $-[0], $+[0] - $-[0]);
+}
+
sub ctx_statement_block {
my ($linenr, $remain, $off) = @_;
my $line = $linenr - 1;
@@ -3372,6 +3379,15 @@ sub process {
"struct spinlock should be spinlock_t\n" .
$herecurr);
}
+# check for seq_printf uses that could be seq_puts
+ if ($line =~ /\bseq_printf\s*\(/) {
+ my $fmt = get_quoted_string($line, $rawline);
+ if ($fmt !~ /[^\\]\%/) {
+ WARN("PREFER_SEQ_PUTS",
+"Prefer seq_puts to seq_printf\n" .
$herecurr);
+ }
+ }
+
# Check for misused memsets
if ($^V && $^V ge 5.10.0 &&
defined $stat &&
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] kernel/srcu: merge common code into a macro
On Tue, 2013-03-19 at 15:16 +0100, Sebastian Andrzej Siewior wrote: > DEFINE_SRCU() and DEFINE_STATIC_SRCU() does the same thing except for > the "static" attribute. This patch moves the common pieces into > _DEFINE_SRCU() which is used by the the former macros either adding the > static attribute or not. [] > diff --git a/include/linux/srcu.h b/include/linux/srcu.h [] > +#define DEFINE_SRCU(name)_DEFINE_SRCU(name, ) > +#define DEFINE_STATIC_SRCU(name) _DEFINE_SRCU(name, static) I think the use of an empty argument, even in a macro, unsightly. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sound: max98090: Remove executable bit
Source files shouldn't have the executable bit set. Signed-off-by: Joe Perches --- include/sound/max98090.h| 0 sound/soc/codecs/max98090.c | 0 sound/soc/codecs/max98090.h | 0 3 files changed, 0 insertions(+), 0 deletions(-) diff --git a/include/sound/max98090.h b/include/sound/max98090.h old mode 100755 new mode 100644 diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c old mode 100755 new mode 100644 diff --git a/sound/soc/codecs/max98090.h b/sound/soc/codecs/max98090.h old mode 100755 new mode 100644 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Documentation: Remove executable bit from tps6507x.txt
Text files shouldn't be executable. Signed-off-by: Joe Perches --- Documentation/devicetree/bindings/mfd/tps6507x.txt | 0 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/tps6507x.txt b/Documentation/devicetree/bindings/mfd/tps6507x.txt old mode 100755 new mode 100644 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] checkpatch: Complain about executable files
Complain about files with an executable bit set that are
not in a scripts/ directory and are not type
.pl, .py, .awk, or .sh
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index b28cc38..f119c84 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1576,7 +1576,8 @@ sub process {
# Check for incorrect file permissions
if ($line =~ /^new (file )?mode.*[7531]\d{0,2}$/) {
my $permhere = $here . "FILE: $realfile\n";
- if ($realfile =~
/(Makefile|Kconfig|\.c|\.h|\.S|\.tmpl)$/) {
+ if ($realfile !~ m@scripts/@ &&
+ $realfile !~ /\.(py|pl|awk|sh)$/) {
ERROR("EXECUTE_PERMISSIONS",
"do not set execute permissions for
source files\n" . $permhere);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sound: max98090: Remove executable bit
On Wed, 2013-03-20 at 10:57 +0100, Mark Brown wrote: > On Tue, Mar 19, 2013 at 02:58:43PM -0700, Joe Perches wrote: > > Source files shouldn't have the executable bit set. > > I've applied this but I'm fed up to the back teeth of having to hand > edit trivial patches from you because you ignore the subject line styles > of subsystems and make up your own. Your style rules just don't matter to me and you can ignore the patches and fix it yourself. Or better, create a tool for others to use that follow your silly style rules. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: comedi: serial2002: fixed consistent spacing issue
On Wed, 2013-03-20 at 15:29 +, Al Viro wrote:
> On Wed, Mar 20, 2013 at 03:47:53PM +0300, Dan Carpenter wrote:
>
> > The original code here needs to broken up into functions so it isn't
> > squashed up against the 80 character limit.
>
> I'd say what needs to be done to the original code...
All good things, thanks for taking the time to write it Al.
Not that I'm ever touching comedi code, but Hartley is, so
I'm adding him to cc just in case he didn't see it...
> Observation 1:
> if (foo) {
> A /* two lines */
> } else {
> B /* huge pile of shite */
> }
> return result;
>
> is equivalent to
>
> if (foo) {
> A
> return result;
> }
> B
> return result;
>
> Observation 2:
> while (1) {
> A /* a couple of lines */
> if (foo) {
> break;
> } else {
> B /* huge pile of shite */
> }
> }
> is equivalent to
> while (1) {
> A
> if (foo)
> break;
> B
> }
>
> Observation 3:
> while (1) {
> A /* moderate pile of shite, assigning foo */
> if (foo) {
> B /* huge pile of shite */
> }
> }
> is equivalent to
> while (1) {
> A
> if (!foo)
> continue;
> B
> }
>
> Observation 4: functions are there for purpose. When you have two identical
> piles of garbage (avert your eyes, or risk taking another look at your dinner)
> such as
> int unit, sign, min;
> unit =
> (data.value >> 10) &
> 0x7;
> sign =
> (data.value >> 13) &
> 0x1;
> min =
> (data.value >> 14) &
> 0xf;
>
> switch (unit) {
> case 0:{
> min =
> min
> *
> 100;
> }
> break;
> case 1:{
> min =
> min
> *
> 1000;
> }
> break;
> case 2:{
> min =
> min
> * 1;
> }
> break;
> }
> if (sign)
> min = -min;
>
> you just might consider turning that pile of excrements into a helper
> function. Incidentally, min = min * 1 is somewhat, er, pointless...
>
> Observation 5:
> for (i = 0; i <= 4; i++) {
> {
> switch (i) {
> case 0: c = non_NULL_1; ... break;
> case 1: c = non_NULL_2; ... break;
> case 2: c = non_NULL_3; ... break;
> case 3: c = non_NULL_4; ... break;
> case 4: c = non_NULL_5; ... break;
> default: c = NULL; break;
> }
> if (c) {
> pile_of_shite
> }
> }
> might, perhaps, be taking defensive programming a bit too far...
>
> Observation 6:
> the Vogon whose brain has produced that code up had been brought up on Pascal,
> Ada or something worse, and had been badly traumatized by semantics of switch
> and break.
> switch (foo) {
> case 0: {
> bar = baz;
> } break;
> case 1: {
> .
> }
> is not quite conventional for C.
>
> Observation 7: down, not across...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] CodingStyle: Add tab indentation avoidance tips
Add Al's comments in from https://lkml.org/lkml/2013/3/20/345
Signed-off-by: Joe Perches
---
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index e00b8f0..c4ba183 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -836,6 +836,141 @@ next instruction in the assembly output:
: /* outputs */ : /* inputs */ : /* clobbers */);
+ Chapter 20:
+
+Tips to avoid overly tab indented code.
+
+Tip 1:
+ if (foo) {
+ A /* two lines */
+ } else {
+ B /* huge pile of shite */
+ }
+ return result;
+
+is equivalent to
+
+ if (foo) {
+ A
+ return result;
+ }
+ B
+ return result;
+
+Tip 2:
+ while (1) {
+ A /* a couple of lines */
+ if (foo) {
+ break;
+ } else {
+ B /* huge pile of shite */
+ }
+ }
+
+is equivalent to
+
+ while (1) {
+ A
+ if (foo)
+ break;
+ B
+ }
+
+Tip 3:
+ while (1) {
+ A /* moderate pile of shite, assigning foo */
+ if (foo) {
+ B /* huge pile of shite */
+ }
+ }
+
+is equivalent to
+
+ while (1) {
+ A
+ if (!foo)
+ continue;
+ B
+ }
+
+Tip 4:
+
+functions are there for purpose. When you have two identical piles of
+garbage (avert your eyes, or risk taking another look at your dinner)
+such as
+ int unit, sign, min;
+ unit =
+ (data.value >> 10) &
+ 0x7;
+ sign =
+ (data.value >> 13) &
+ 0x1;
+ min =
+ (data.value >> 14) &
+ 0xf;
+
+ switch (unit) {
+ case 0:{
+ min =
+ min
+ *
+ 100;
+ }
+ break;
+ case 1:{
+ min =
+ min
+ *
+ 1000;
+ }
+ break;
+ case 2:{
+ min =
+ min
+ * 1;
+ }
+ break;
+ }
+ if (sign)
+ min = -min;
+
+you just might consider turning that pile of excrements into a helper
+function. Incidentally, min = min * 1 is somewhat, er, pointless...
+
+Tip 5:
+ for (i = 0; i <= 4; i++) {
+ {
+ switch (i) {
+ case 0: c = non_NULL_1; ... break;
+ case 1: c = non_NULL_2; ... break;
+ case 2: c = non_NULL_3; ... break;
+ case 3: c = non_NULL_4; ... break;
+ case 4: c = non_NULL_5; ... break;
+ default: c = NULL; break;
+ }
+ if (c) {
+ pile_of_shite
+ }
+ }
+might, perhaps, be taking defensive programming a bit too far...
+
+Tip 6:
+The Vogon whose brain has produced that code up had been brought up on Pascal,
+Ada or something worse, and had been badly traumatized by semantics of switch
+and break.
+ switch (foo) {
+ case 0: {
+ bar = baz;
+ } break;
+ case 1: {
+ .
+ }
+ is not quite conventional for C.
+
+Tip 7:
+Code flow is down, not across...
+
+
Appendix I: References
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sound: max98090: Remove executable bit
On Wed, 2013-03-20 at 17:36 +0100, Mark Brown wrote: > On Wed, Mar 20, 2013 at 08:22:16AM -0700, Joe Perches wrote: > > On Wed, 2013-03-20 at 10:57 +0100, Mark Brown wrote: > > > > I've applied this but I'm fed up to the back teeth of having to hand > > > edit trivial patches from you because you ignore the subject line styles > > > of subsystems and make up your own. > > > Your style rules just don't matter to me and > > you can ignore the patches and fix it yourself. > > > Or better, create a tool for others to use that > > follow your silly style rules. > > This is just like any other coding style thing - you should be creating > patches that look like other patches for the affected, if there's things > like obvious visual differences in what you're doing you're doing it > wrong. We've had this conversation before and I proposed to you a simple solution. https://lkml.org/lkml/2010/11/16/245 and I still more or less agree with Florian https://lkml.org/lkml/2010/11/16/314 I'm not doing it wrong. You have another demand others don't. I simply don't find it necessary to cater to you. If you want it to be agreed that there is a specific form for subject headers that varies by maintainer tree, change SubmittingPatches Paragraph 11. > Automation doesn't work for things like this, there's a good solid > reason why there's generally a human involved in patch; the other people > who submit lots of cleanups generally manage to figure this out > usefully, you might want to discuss techniques with them. I suggest you use a git pre-commit hook to your tree and use sed/perl to add a specific prefix if it doesn't exist. http://codeinthehole.com/writing/tips-for-using-a-git-pre-commit-hook/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CodingStyle: Add tab indentation avoidance tips
On Wed, 2013-03-20 at 16:52 +, Al Viro wrote: > On Wed, Mar 20, 2013 at 09:26:54AM -0700, Joe Perches wrote: > > Add Al's comments in from https://lkml.org/lkml/2013/3/20/345 > > > +Tip 7: > > +Code flow is down, not across... > > That one is a lovely improvement on what I actually said. google > "down, not across" for context... Heh. Context is everything. I shoulda known better, given the source ;) cheers, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about printking
On Sat, 2013-02-02 at 16:30 -0300, Ezequiel Garcia wrote:
> ptr = kmalloc(sizeof(foo));
> if (!ptr) {
> pr_err("Cannot allocate memory for foo\n");
> return -ENOMEM;
> }
> His argue against it was that kmalloc already takes care of
> reporting/printking
> a good deal of interesting information when this happens.
> Can someone expand a bit on this whole idea? (of abuse of printing,
> or futility of printing).
k.alloc() takes a GFP_ flag as an arg.
One of those GFP flags is __GFP_NOWARN.
For all failed allocs without GFP_NOWARN
a message is emitted and a dump_stack is
done.
(see: mm/page_alloc.c warn_alloc_failed())
So, most all of these printks after
k.alloc()'s are not necessary.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/8] drivers/net: Remove unnecessary alloc/OOM messages
Remove all the OOM messages that follow kernel alloc failures as there is already a generic equivalent to these messages in the mm subsystem. Joe Perches (8): caif: Remove unnecessary alloc/OOM messages can: Remove unnecessary alloc/OOM messages ethernet: Remove unnecessary alloc/OOM messages, alloc cleanups drivers: net: usb: Remove unnecessary alloc/OOM messages wan: Remove unnecessary alloc/OOM messages wimax: Remove unnecessary alloc/OOM messages, alloc cleanups wireless: Remove unnecessary alloc/OOM messages, alloc cleanups drivers:net:misc: Remove unnecessary alloc/OOM messages drivers/net/caif/caif_shmcore.c| 6 - drivers/net/can/sja1000/ems_pci.c | 1 - drivers/net/can/sja1000/peak_pci.c | 5 +--- drivers/net/can/sja1000/peak_pcmcia.c | 1 - drivers/net/can/sja1000/plx_pci.c | 1 - drivers/net/can/usb/ems_usb.c | 4 +--- drivers/net/can/usb/kvaser_usb.c | 2 -- drivers/net/can/usb/peak_usb/pcan_usb_core.c | 5 drivers/net/can/usb/usb_8dev.c | 4 +--- drivers/net/ethernet/atheros/atl1c/atl1c_main.c| 6 ++--- drivers/net/ethernet/atheros/atl1e/atl1e_main.c| 2 -- drivers/net/ethernet/broadcom/b44.c| 4 +--- drivers/net/ethernet/broadcom/bcm63xx_enet.c | 6 ++--- drivers/net/ethernet/broadcom/cnic.c | 6 ++--- drivers/net/ethernet/broadcom/tg3.c| 4 +--- drivers/net/ethernet/freescale/gianfar_ethtool.c | 9 drivers/net/ethernet/ibm/ehea/ehea_main.c | 4 +--- drivers/net/ethernet/ibm/ehea/ehea_qmr.c | 19 +-- drivers/net/ethernet/ibm/emac/mal.c| 7 ++ drivers/net/ethernet/ibm/ibmveth.c | 1 - drivers/net/ethernet/intel/igb/igb_main.c | 5 ++-- drivers/net/ethernet/intel/igbvf/netdev.c | 8 +++ drivers/net/ethernet/marvell/mv643xx_eth.c | 8 +++ drivers/net/ethernet/marvell/mvmdio.c | 1 - drivers/net/ethernet/marvell/skge.c| 5 ++-- drivers/net/ethernet/marvell/sky2.c| 4 +--- drivers/net/ethernet/mellanox/mlx4/en_main.c | 4 +--- drivers/net/ethernet/mellanox/mlx4/main.c | 4 +--- drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 5 ++-- .../net/ethernet/qlogic/netxen/netxen_nic_ctx.c| 5 +--- drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c | 18 --- .../net/ethernet/qlogic/netxen/netxen_nic_init.c | 27 -- .../net/ethernet/qlogic/netxen/netxen_nic_main.c | 5 +--- drivers/net/ethernet/qlogic/qla3xxx.c | 10 .../net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c | 14 --- drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c | 6 ++--- drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c | 26 +++-- drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 19 +-- .../net/ethernet/qlogic/qlcnic/qlcnic_minidump.c | 7 ++ drivers/net/ethernet/qlogic/qlge/qlge_main.c | 1 - drivers/net/ethernet/rdc/r6040.c | 3 +-- drivers/net/ethernet/renesas/sh_eth.c | 10 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 11 + drivers/net/ethernet/sun/niu.c | 2 +- drivers/net/ethernet/ti/cpsw.c | 8 +++ drivers/net/ethernet/ti/davinci_mdio.c | 4 +--- drivers/net/ethernet/xilinx/ll_temac_main.c| 6 ++--- drivers/net/hamradio/dmascc.c | 7 +- drivers/net/phy/spi_ks8995.c | 4 +--- drivers/net/usb/ax88172a.c | 6 ++--- drivers/net/usb/hso.c | 25 ++-- drivers/net/usb/sierra_net.c | 10 +++- drivers/net/usb/smsc75xx.c | 6 ++--- drivers/net/usb/smsc95xx.c | 6 ++--- drivers/net/usb/usbnet.c | 5 +--- drivers/net/virtio_net.c | 4 +--- drivers/net/wan/cosa.c | 9 drivers/net/wan/farsync.c | 6 ++--- drivers/net/wan/hdlc.c | 9 drivers/net/wan/x25_asy.c | 1 - drivers/net/wimax/i2400m/rx.c | 16 - drivers/net/wimax/i2400m/usb-notif.c | 1 - drivers/net/wireless/airo_cs.c | 5 ++-- drivers/net/wireless/at76c50x-usb.c| 4 +--- .../net/wireless/ath/ath9k/dfs_pattern_detector.c | 6 ++--- drivers/net/wireless/atmel_cs.c| 5 ++-- drivers/net/wireless/ipw2x00/ipw2100.c | 9 +++- drivers/net/wireless/libertas/cfg.c| 4 +--- drivers/net/wireless/mwifiex/11n.c
[PATCH 1/8] caif: Remove unnecessary alloc/OOM messages
alloc failures already get standardized OOM
messages and a dump_stack.
Signed-off-by: Joe Perches
---
drivers/net/caif/caif_shmcore.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/net/caif/caif_shmcore.c b/drivers/net/caif/caif_shmcore.c
index bc497d7..bce8bac 100644
--- a/drivers/net/caif/caif_shmcore.c
+++ b/drivers/net/caif/caif_shmcore.c
@@ -633,9 +633,6 @@ int caif_shmcore_probe(struct shmdev_layer *pshm_dev)
kmalloc(sizeof(struct buf_list), GFP_KERNEL);
if (tx_buf == NULL) {
- pr_warn("ERROR, Could not"
- " allocate dynamic mem. for tx_buf,"
- " Bailing out ...\n");
free_netdev(pshm_dev->pshm_netdev);
return -ENOMEM;
}
@@ -662,9 +659,6 @@ int caif_shmcore_probe(struct shmdev_layer *pshm_dev)
kmalloc(sizeof(struct buf_list), GFP_KERNEL);
if (rx_buf == NULL) {
- pr_warn("ERROR, Could not"
- " allocate dynamic mem.for rx_buf,"
- " Bailing out ...\n");
free_netdev(pshm_dev->pshm_netdev);
return -ENOMEM;
}
--
1.8.0.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] can: Remove unnecessary alloc/OOM messages
alloc failures already get standardized OOM
messages and a dump_stack.
Signed-off-by: Joe Perches
---
drivers/net/can/sja1000/ems_pci.c| 1 -
drivers/net/can/sja1000/peak_pci.c | 5 +
drivers/net/can/sja1000/peak_pcmcia.c| 1 -
drivers/net/can/sja1000/plx_pci.c| 1 -
drivers/net/can/usb/ems_usb.c| 4 +---
drivers/net/can/usb/kvaser_usb.c | 2 --
drivers/net/can/usb/peak_usb/pcan_usb_core.c | 5 -
drivers/net/can/usb/usb_8dev.c | 4 +---
8 files changed, 3 insertions(+), 20 deletions(-)
diff --git a/drivers/net/can/sja1000/ems_pci.c
b/drivers/net/can/sja1000/ems_pci.c
index 036a326..36d298d 100644
--- a/drivers/net/can/sja1000/ems_pci.c
+++ b/drivers/net/can/sja1000/ems_pci.c
@@ -238,7 +238,6 @@ static int ems_pci_add_card(struct pci_dev *pdev,
/* Allocating card structures to hold addresses, ... */
card = kzalloc(sizeof(struct ems_pci_card), GFP_KERNEL);
if (card == NULL) {
- dev_err(&pdev->dev, "Unable to allocate memory\n");
pci_disable_device(pdev);
return -ENOMEM;
}
diff --git a/drivers/net/can/sja1000/peak_pci.c
b/drivers/net/can/sja1000/peak_pci.c
index 600ac72..d1e7f10 100644
--- a/drivers/net/can/sja1000/peak_pci.c
+++ b/drivers/net/can/sja1000/peak_pci.c
@@ -450,11 +450,8 @@ static int peak_pciec_probe(struct pci_dev *pdev, struct
net_device *dev)
} else {
/* create the bit banging I2C adapter structure */
card = kzalloc(sizeof(struct peak_pciec_card), GFP_KERNEL);
- if (!card) {
- dev_err(&pdev->dev,
-"failed allocating memory for i2c chip\n");
+ if (!card)
return -ENOMEM;
- }
card->cfg_base = chan->cfg_base;
card->reg_base = priv->reg_base;
diff --git a/drivers/net/can/sja1000/peak_pcmcia.c
b/drivers/net/can/sja1000/peak_pcmcia.c
index f117514..1a7020b 100644
--- a/drivers/net/can/sja1000/peak_pcmcia.c
+++ b/drivers/net/can/sja1000/peak_pcmcia.c
@@ -660,7 +660,6 @@ static int pcan_probe(struct pcmcia_device *pdev)
card = kzalloc(sizeof(struct pcan_pccard), GFP_KERNEL);
if (!card) {
- dev_err(&pdev->dev, "couldn't allocate card memory\n");
err = -ENOMEM;
goto probe_err_2;
}
diff --git a/drivers/net/can/sja1000/plx_pci.c
b/drivers/net/can/sja1000/plx_pci.c
index 11d1062..a042cdc 100644
--- a/drivers/net/can/sja1000/plx_pci.c
+++ b/drivers/net/can/sja1000/plx_pci.c
@@ -508,7 +508,6 @@ static int plx_pci_add_card(struct pci_dev *pdev,
/* Allocate card structures to hold addresses, ... */
card = kzalloc(sizeof(*card), GFP_KERNEL);
if (!card) {
- dev_err(&pdev->dev, "Unable to allocate memory\n");
pci_disable_device(pdev);
return -ENOMEM;
}
diff --git a/drivers/net/can/usb/ems_usb.c b/drivers/net/can/usb/ems_usb.c
index c69f0b7..0e7bde7 100644
--- a/drivers/net/can/usb/ems_usb.c
+++ b/drivers/net/can/usb/ems_usb.c
@@ -1014,10 +1014,8 @@ static int ems_usb_probe(struct usb_interface *intf,
}
dev->intr_in_buffer = kzalloc(INTR_IN_BUFFER_SIZE, GFP_KERNEL);
- if (!dev->intr_in_buffer) {
- dev_err(&intf->dev, "Couldn't alloc Intr buffer\n");
+ if (!dev->intr_in_buffer)
goto cleanup_intr_urb;
- }
dev->tx_msg_buffer = kzalloc(CPC_HEADER_SIZE +
sizeof(struct ems_cpc_msg), GFP_KERNEL);
diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index 5b58a4d..45cb9f3 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -561,7 +561,6 @@ static int kvaser_usb_simple_msg_async(struct
kvaser_usb_net_priv *priv,
buf = kmalloc(sizeof(struct kvaser_msg), GFP_ATOMIC);
if (!buf) {
- netdev_err(netdev, "No memory left for USB buffer\n");
usb_free_urb(urb);
return -ENOMEM;
}
@@ -1268,7 +1267,6 @@ static netdev_tx_t kvaser_usb_start_xmit(struct sk_buff
*skb,
buf = kmalloc(sizeof(struct kvaser_msg), GFP_ATOMIC);
if (!buf) {
- netdev_err(netdev, "No memory left for USB buffer\n");
stats->tx_dropped++;
goto nobufmem;
}
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
index d9290ea..a0f647f 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
@@ -386,7 +386,6 @@ static int peak_usb_start(struct peak_usb_device *dev)
buf = kmalloc(dev-
[PATCH 4/8] drivers: net: usb: Remove unnecessary alloc/OOM messages
alloc failures already get standardized OOM
messages and a dump_stack.
Signed-off-by: Joe Perches
---
drivers/net/usb/ax88172a.c | 6 ++
drivers/net/usb/hso.c| 25 +++--
drivers/net/usb/sierra_net.c | 10 +++---
drivers/net/usb/smsc75xx.c | 6 ++
drivers/net/usb/smsc95xx.c | 6 ++
drivers/net/usb/usbnet.c | 5 +
6 files changed, 17 insertions(+), 41 deletions(-)
diff --git a/drivers/net/usb/ax88172a.c b/drivers/net/usb/ax88172a.c
index 76ee541..d012203 100644
--- a/drivers/net/usb/ax88172a.c
+++ b/drivers/net/usb/ax88172a.c
@@ -117,7 +117,6 @@ static int ax88172a_init_mdio(struct usbnet *dev)
priv->mdio->irq = kzalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL);
if (!priv->mdio->irq) {
- netdev_err(dev->net, "Could not allocate mdio->irq\n");
ret = -ENOMEM;
goto mfree;
}
@@ -236,10 +235,9 @@ static int ax88172a_bind(struct usbnet *dev, struct
usb_interface *intf)
usbnet_get_endpoints(dev, intf);
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
- if (!priv) {
- netdev_err(dev->net, "Could not allocate memory for private
data\n");
+ if (!priv)
return -ENOMEM;
- }
+
dev->driver_priv = priv;
/* Get the MAC address */
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index f902a14..e2dd324 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -2315,10 +2315,8 @@ static int hso_serial_common_create(struct hso_serial
*serial, int num_urbs,
serial->rx_urb[i]->transfer_buffer_length = 0;
serial->rx_data[i] = kzalloc(serial->rx_data_length,
GFP_KERNEL);
- if (!serial->rx_data[i]) {
- dev_err(dev, "%s - Out of memory\n", __func__);
+ if (!serial->rx_data[i])
goto exit;
- }
}
/* TX, allocate urb and initialize */
@@ -2334,15 +2332,12 @@ static int hso_serial_common_create(struct hso_serial
*serial, int num_urbs,
serial->tx_buffer_count = 0;
serial->tx_data_length = tx_size;
serial->tx_data = kzalloc(serial->tx_data_length, GFP_KERNEL);
- if (!serial->tx_data) {
- dev_err(dev, "%s - Out of memory\n", __func__);
+ if (!serial->tx_data)
goto exit;
- }
+
serial->tx_buffer = kzalloc(serial->tx_data_length, GFP_KERNEL);
- if (!serial->tx_buffer) {
- dev_err(dev, "%s - Out of memory\n", __func__);
+ if (!serial->tx_buffer)
goto exit;
- }
return 0;
exit:
@@ -2578,10 +2573,8 @@ static struct hso_device *hso_create_net_device(struct
usb_interface *interface,
}
hso_net->mux_bulk_rx_buf_pool[i] = kzalloc(MUX_BULK_RX_BUF_SIZE,
GFP_KERNEL);
- if (!hso_net->mux_bulk_rx_buf_pool[i]) {
- dev_err(&interface->dev, "Could not allocate rx buf\n");
+ if (!hso_net->mux_bulk_rx_buf_pool[i])
goto exit;
- }
}
hso_net->mux_bulk_tx_urb = usb_alloc_urb(0, GFP_KERNEL);
if (!hso_net->mux_bulk_tx_urb) {
@@ -2589,10 +2582,8 @@ static struct hso_device *hso_create_net_device(struct
usb_interface *interface,
goto exit;
}
hso_net->mux_bulk_tx_buf = kzalloc(MUX_BULK_TX_BUF_SIZE, GFP_KERNEL);
- if (!hso_net->mux_bulk_tx_buf) {
- dev_err(&interface->dev, "Could not allocate tx buf\n");
+ if (!hso_net->mux_bulk_tx_buf)
goto exit;
- }
add_net_device(hso_dev);
@@ -2816,10 +2807,8 @@ struct hso_shared_int *hso_create_shared_int(struct
usb_interface *interface)
mux->shared_intr_buf =
kzalloc(le16_to_cpu(mux->intr_endp->wMaxPacketSize),
GFP_KERNEL);
- if (!mux->shared_intr_buf) {
- dev_err(&interface->dev, "Could not allocate intr buf?\n");
+ if (!mux->shared_intr_buf)
goto exit;
- }
mutex_init(&mux->shared_int_lock);
diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c
index 453aa6c..79ab243 100644
--- a/drivers/net/usb/sierra_net.c
+++ b/drivers/net/usb/sierra_net.c
@@ -459,11 +459,9 @@ static void sierra_net_kevent(struct work_struct *work)
/* Query the modem for the LSI message */
buf = kzalloc(SIERRA_NET_USBCTL_BUF_LEN, GFP_KERNEL);
- if (!buf) {
- netdev_err(dev->net,
- &
[PATCH 5/8] wan: Remove unnecessary alloc/OOM messages
alloc failures already get standardized OOM
messages and a dump_stack.
Hoist assigns from if tests.
Signed-off-by: Joe Perches
---
drivers/net/wan/cosa.c| 9 -
drivers/net/wan/farsync.c | 6 ++
drivers/net/wan/hdlc.c| 9 -
drivers/net/wan/x25_asy.c | 1 -
4 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wan/cosa.c b/drivers/net/wan/cosa.c
index 6aed238..0179cef 100644
--- a/drivers/net/wan/cosa.c
+++ b/drivers/net/wan/cosa.c
@@ -795,8 +795,8 @@ static ssize_t cosa_read(struct file *file,
if (mutex_lock_interruptible(&chan->rlock))
return -ERESTARTSYS;
- if ((chan->rxdata = kmalloc(COSA_MTU, GFP_DMA|GFP_KERNEL)) == NULL) {
- pr_info("%s: cosa_read() - OOM\n", cosa->name);
+ chan->rxdata = kmalloc(COSA_MTU, GFP_DMA|GFP_KERNEL);
+ if (chan->rxdata == NULL) {
mutex_unlock(&chan->rlock);
return -ENOMEM;
}
@@ -874,9 +874,8 @@ static ssize_t cosa_write(struct file *file,
count = COSA_MTU;
/* Allocate the buffer */
- if ((kbuf = kmalloc(count, GFP_KERNEL|GFP_DMA)) == NULL) {
- pr_notice("%s: cosa_write() OOM - dropping packet\n",
- cosa->name);
+ kbuf = kmalloc(count, GFP_KERNEL|GFP_DMA);
+ if (kbuf == NULL) {
up(&chan->wsem);
return -ENOMEM;
}
diff --git a/drivers/net/wan/farsync.c b/drivers/net/wan/farsync.c
index 56941d6..3f0c4f2 100644
--- a/drivers/net/wan/farsync.c
+++ b/drivers/net/wan/farsync.c
@@ -2448,11 +2448,9 @@ fst_add_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
}
/* Allocate driver private data */
- card = kzalloc(sizeof (struct fst_card_info), GFP_KERNEL);
- if (card == NULL) {
- pr_err("FarSync card found but insufficient memory for driver
storage\n");
+ card = kzalloc(sizeof(struct fst_card_info), GFP_KERNEL);
+ if (card == NULL)
return -ENOMEM;
- }
/* Try to enable the device */
if ((err = pci_enable_device(pdev)) != 0) {
diff --git a/drivers/net/wan/hdlc.c b/drivers/net/wan/hdlc.c
index 10cc7df..a0a932c 100644
--- a/drivers/net/wan/hdlc.c
+++ b/drivers/net/wan/hdlc.c
@@ -280,14 +280,13 @@ int attach_hdlc_protocol(struct net_device *dev, struct
hdlc_proto *proto,
if (!try_module_get(proto->module))
return -ENOSYS;
- if (size)
- if ((dev_to_hdlc(dev)->state = kmalloc(size,
- GFP_KERNEL)) == NULL) {
- netdev_warn(dev,
- "Memory squeeze on hdlc_proto_attach()\n");
+ if (size) {
+ dev_to_hdlc(dev)->state = kmalloc(size, GFP_KERNEL);
+ if (dev_to_hdlc(dev)->state == NULL) {
module_put(proto->module);
return -ENOBUFS;
}
+ }
dev_to_hdlc(dev)->proto = proto;
return 0;
}
diff --git a/drivers/net/wan/x25_asy.c b/drivers/net/wan/x25_asy.c
index 44db8b7..5895f19 100644
--- a/drivers/net/wan/x25_asy.c
+++ b/drivers/net/wan/x25_asy.c
@@ -128,7 +128,6 @@ static int x25_asy_change_mtu(struct net_device *dev, int
newmtu)
rbuff = kmalloc(len + 4, GFP_ATOMIC);
if (xbuff == NULL || rbuff == NULL) {
- netdev_warn(dev, "unable to grow X.25 buffers, MTU change
cancelled\n");
kfree(xbuff);
kfree(rbuff);
return -ENOMEM;
--
1.8.0.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] wimax: Remove unnecessary alloc/OOM messages, alloc cleanups
alloc failures already get standardized OOM
messages and a dump_stack.
Convert kzalloc's with multiplies to kcalloc.
Remove now unused size variables.
Signed-off-by: Joe Perches
---
drivers/net/wimax/i2400m/rx.c| 16 +---
drivers/net/wimax/i2400m/usb-notif.c | 1 -
2 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wimax/i2400m/rx.c b/drivers/net/wimax/i2400m/rx.c
index 37becfc..8077e6e 100644
--- a/drivers/net/wimax/i2400m/rx.c
+++ b/drivers/net/wimax/i2400m/rx.c
@@ -1351,24 +1351,18 @@ int i2400m_rx_setup(struct i2400m *i2400m)
i2400m->rx_reorder = i2400m_rx_reorder_disabled? 0 : 1;
if (i2400m->rx_reorder) {
unsigned itr;
- size_t size;
struct i2400m_roq_log *rd;
result = -ENOMEM;
- size = sizeof(i2400m->rx_roq[0]) * (I2400M_RO_CIN + 1);
- i2400m->rx_roq = kzalloc(size, GFP_KERNEL);
- if (i2400m->rx_roq == NULL) {
- dev_err(dev, "RX: cannot allocate %zu bytes for "
- "reorder queues\n", size);
+ i2400m->rx_roq = kcalloc(I2400M_RO_CIN + 1,
+sizeof(i2400m->rx_roq[0]), GFP_KERNEL);
+ if (i2400m->rx_roq == NULL)
goto error_roq_alloc;
- }
- size = sizeof(*i2400m->rx_roq[0].log) * (I2400M_RO_CIN + 1);
- rd = kzalloc(size, GFP_KERNEL);
+ rd = kcalloc(I2400M_RO_CIN + 1, sizeof(*i2400m->rx_roq[0].log),
+GFP_KERNEL);
if (rd == NULL) {
- dev_err(dev, "RX: cannot allocate %zu bytes for "
- "reorder queues log areas\n", size);
result = -ENOMEM;
goto error_roq_log_alloc;
}
diff --git a/drivers/net/wimax/i2400m/usb-notif.c
b/drivers/net/wimax/i2400m/usb-notif.c
index d44b545..fc1355d 100644
--- a/drivers/net/wimax/i2400m/usb-notif.c
+++ b/drivers/net/wimax/i2400m/usb-notif.c
@@ -199,7 +199,6 @@ int i2400mu_notification_setup(struct i2400mu *i2400mu)
d_fnstart(4, dev, "(i2400m %p)\n", i2400mu);
buf = kmalloc(I2400MU_MAX_NOTIFICATION_LEN, GFP_KERNEL | GFP_DMA);
if (buf == NULL) {
- dev_err(dev, "notification: buffer allocation failed\n");
ret = -ENOMEM;
goto error_buf_alloc;
}
--
1.8.0.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] wireless: Remove unnecessary alloc/OOM messages, alloc cleanups
alloc failures already get standardized OOM
messages and a dump_stack.
Convert kzalloc's with multiplies to kcalloc.
Convert kmalloc's with multiplies to kmalloc_array.
Remove now unused variables.
Remove unnecessary memset after kzalloc->kcalloc.
Whitespace cleanups for these changes.
Signed-off-by: Joe Perches
---
drivers/net/wireless/airo_cs.c | 5 ++--
drivers/net/wireless/at76c50x-usb.c| 4 +---
.../net/wireless/ath/ath9k/dfs_pattern_detector.c | 6 ++---
drivers/net/wireless/atmel_cs.c| 5 ++--
drivers/net/wireless/ipw2x00/ipw2100.c | 9 +++-
drivers/net/wireless/libertas/cfg.c| 4 +---
drivers/net/wireless/mwifiex/11n.c | 5 +---
drivers/net/wireless/mwifiex/11n_rxreorder.c | 5 +---
drivers/net/wireless/mwifiex/cfg80211.c| 4 +---
drivers/net/wireless/mwifiex/cmdevt.c | 11 +++--
drivers/net/wireless/mwifiex/init.c| 5 +---
drivers/net/wireless/mwifiex/scan.c| 27 +++---
drivers/net/wireless/mwifiex/sdio.c| 11 ++---
drivers/net/wireless/mwifiex/sta_ioctl.c | 11 +++--
drivers/net/wireless/mwifiex/wmm.c | 7 ++
drivers/net/wireless/orinoco/main.c| 16 -
drivers/net/wireless/p54/p54usb.c | 10 ++--
drivers/net/wireless/prism54/islpci_mgt.c | 14 ---
drivers/net/wireless/rndis_wlan.c | 5 +---
drivers/net/wireless/ti/wlcore/sdio.c | 4 +---
drivers/net/wireless/ti/wlcore/spi.c | 14 +++
drivers/net/wireless/zd1211rw/zd_usb.c | 1 -
22 files changed, 50 insertions(+), 133 deletions(-)
diff --git a/drivers/net/wireless/airo_cs.c b/drivers/net/wireless/airo_cs.c
index 630577d..956024a 100644
--- a/drivers/net/wireless/airo_cs.c
+++ b/drivers/net/wireless/airo_cs.c
@@ -69,10 +69,9 @@ static int airo_probe(struct pcmcia_device *p_dev)
/* Allocate space for private device-specific data */
local = kzalloc(sizeof(local_info_t), GFP_KERNEL);
- if (!local) {
- printk(KERN_ERR "airo_cs: no memory for new device\n");
+ if (!local)
return -ENOMEM;
- }
+
p_dev->priv = local;
return airo_config(p_dev);
diff --git a/drivers/net/wireless/at76c50x-usb.c
b/drivers/net/wireless/at76c50x-usb.c
index 77fa428..5ac5f7a 100644
--- a/drivers/net/wireless/at76c50x-usb.c
+++ b/drivers/net/wireless/at76c50x-usb.c
@@ -2164,10 +2164,8 @@ static int at76_alloc_urbs(struct at76_priv *priv,
buffer_size = sizeof(struct at76_tx_buffer) + MAX_PADDING_SIZE;
priv->bulk_out_buffer = kmalloc(buffer_size, GFP_KERNEL);
- if (!priv->bulk_out_buffer) {
- dev_err(&interface->dev, "cannot allocate output buffer\n");
+ if (!priv->bulk_out_buffer)
return -ENOMEM;
- }
at76_dbg(DBG_PROC_ENTRY, "%s: EXIT", __func__);
diff --git a/drivers/net/wireless/ath/ath9k/dfs_pattern_detector.c
b/drivers/net/wireless/ath/ath9k/dfs_pattern_detector.c
index 24877b0..467b600 100644
--- a/drivers/net/wireless/ath/ath9k/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/ath9k/dfs_pattern_detector.c
@@ -288,11 +288,11 @@ struct dfs_pattern_detector *
dfs_pattern_detector_init(enum nl80211_dfs_regions region)
{
struct dfs_pattern_detector *dpd;
+
dpd = kmalloc(sizeof(*dpd), GFP_KERNEL);
- if (dpd == NULL) {
- pr_err("allocation of dfs_pattern_detector failed\n");
+ if (dpd == NULL)
return NULL;
- }
+
*dpd = default_dpd;
INIT_LIST_HEAD(&dpd->channel_detectors);
diff --git a/drivers/net/wireless/atmel_cs.c b/drivers/net/wireless/atmel_cs.c
index ded03d2..b42930f 100644
--- a/drivers/net/wireless/atmel_cs.c
+++ b/drivers/net/wireless/atmel_cs.c
@@ -79,10 +79,9 @@ static int atmel_probe(struct pcmcia_device *p_dev)
/* Allocate space for private device-specific data */
local = kzalloc(sizeof(local_info_t), GFP_KERNEL);
- if (!local) {
- printk(KERN_ERR "atmel_cs: no memory for new device\n");
+ if (!local)
return -ENOMEM;
- }
+
p_dev->priv = local;
return atmel_config(p_dev);
diff --git a/drivers/net/wireless/ipw2x00/ipw2100.c
b/drivers/net/wireless/ipw2x00/ipw2100.c
index d92b21a..04d5e64 100644
--- a/drivers/net/wireless/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/ipw2x00/ipw2100.c
@@ -4478,13 +4478,10 @@ static int ipw2100_tx_allocate(struct ipw2100_priv
*priv)
return err;
}
- priv->tx_buffers =
- kmalloc(TX_PENDED_QUEUE_LENGTH * sizeof(struct ipw2100_tx_packet),
- GFP_ATOMIC);
+ priv->tx_buff
[PATCH 8/8] drivers:net:misc: Remove unnecessary alloc/OOM messages
alloc failures already get standardized OOM
messages and a dump_stack.
Signed-off-by: Joe Perches
---
drivers/net/hamradio/dmascc.c | 7 +--
drivers/net/phy/spi_ks8995.c | 4 +---
drivers/net/virtio_net.c | 4 +---
3 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/net/hamradio/dmascc.c b/drivers/net/hamradio/dmascc.c
index ce555d9..6636022 100644
--- a/drivers/net/hamradio/dmascc.c
+++ b/drivers/net/hamradio/dmascc.c
@@ -463,13 +463,8 @@ static int __init setup_adapter(int card_base, int type,
int n)
/* Initialize what is necessary for write_scc and write_scc_data */
info = kzalloc(sizeof(struct scc_info), GFP_KERNEL | GFP_DMA);
- if (!info) {
- printk(KERN_ERR "dmascc: "
- "could not allocate memory for %s at %#3x\n",
- hw[type].name, card_base);
+ if (!info)
goto out;
- }
-
info->dev[0] = alloc_netdev(0, "", dev_setup);
if (!info->dev[0]) {
diff --git a/drivers/net/phy/spi_ks8995.c b/drivers/net/phy/spi_ks8995.c
index 41eb8ff..5c87eef 100644
--- a/drivers/net/phy/spi_ks8995.c
+++ b/drivers/net/phy/spi_ks8995.c
@@ -275,10 +275,8 @@ static int ks8995_probe(struct spi_device *spi)
pdata = spi->dev.platform_data;
ks = kzalloc(sizeof(*ks), GFP_KERNEL);
- if (!ks) {
- dev_err(&spi->dev, "no memory for private data\n");
+ if (!ks)
return -ENOMEM;
- }
mutex_init(&ks->lock);
ks->pdata = pdata;
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index eda2042..381a2d8 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -976,10 +976,8 @@ static void virtnet_set_rx_mode(struct net_device *dev)
buf = kzalloc(((uc_count + mc_count) * ETH_ALEN) +
(2 * sizeof(mac_data->entries)), GFP_ATOMIC);
mac_data = buf;
- if (!buf) {
- dev_warn(&dev->dev, "No memory for MAC address buffer\n");
+ if (!buf)
return;
- }
sg_init_table(sg, 2);
--
1.8.0.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8] ethernet: Remove unnecessary alloc/OOM messages, alloc cleanups
alloc failures already get standardized OOM
messages and a dump_stack.
Convert kzalloc's with multiplies to kcalloc.
Convert kmalloc's with multiplies to kmalloc_array.
Fix a few whitespace defects.
Convert a constant 6 to ETH_ALEN.
Use parentheses around sizeof.
Convert vmalloc/memset to vzalloc.
Remove now unused size variables.
Signed-off-by: Joe Perches
---
drivers/net/ethernet/atheros/atl1c/atl1c_main.c| 6 ++---
drivers/net/ethernet/atheros/atl1e/atl1e_main.c| 2 --
drivers/net/ethernet/broadcom/b44.c| 4 +---
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 6 ++---
drivers/net/ethernet/broadcom/cnic.c | 6 ++---
drivers/net/ethernet/broadcom/tg3.c| 4 +---
drivers/net/ethernet/freescale/gianfar_ethtool.c | 9
drivers/net/ethernet/ibm/ehea/ehea_main.c | 4 +---
drivers/net/ethernet/ibm/ehea/ehea_qmr.c | 19 +--
drivers/net/ethernet/ibm/emac/mal.c| 7 ++
drivers/net/ethernet/ibm/ibmveth.c | 1 -
drivers/net/ethernet/intel/igb/igb_main.c | 5 ++--
drivers/net/ethernet/intel/igbvf/netdev.c | 8 +++
drivers/net/ethernet/marvell/mv643xx_eth.c | 8 +++
drivers/net/ethernet/marvell/mvmdio.c | 1 -
drivers/net/ethernet/marvell/skge.c| 5 ++--
drivers/net/ethernet/marvell/sky2.c| 4 +---
drivers/net/ethernet/mellanox/mlx4/en_main.c | 4 +---
drivers/net/ethernet/mellanox/mlx4/main.c | 4 +---
drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 5 ++--
.../net/ethernet/qlogic/netxen/netxen_nic_ctx.c| 5 +---
drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c | 18 ---
.../net/ethernet/qlogic/netxen/netxen_nic_init.c | 27 --
.../net/ethernet/qlogic/netxen/netxen_nic_main.c | 5 +---
drivers/net/ethernet/qlogic/qla3xxx.c | 10
.../net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c | 14 ---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c | 6 ++---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c | 26 +++--
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 19 +--
.../net/ethernet/qlogic/qlcnic/qlcnic_minidump.c | 7 ++
drivers/net/ethernet/qlogic/qlge/qlge_main.c | 1 -
drivers/net/ethernet/rdc/r6040.c | 3 +--
drivers/net/ethernet/renesas/sh_eth.c | 10
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 11 +
drivers/net/ethernet/sun/niu.c | 2 +-
drivers/net/ethernet/ti/cpsw.c | 8 +++
drivers/net/ethernet/ti/davinci_mdio.c | 4 +---
drivers/net/ethernet/xilinx/ll_temac_main.c| 6 ++---
38 files changed, 97 insertions(+), 197 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index 8df02ba..571b514 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -982,11 +982,9 @@ static int atl1c_setup_ring_resources(struct atl1c_adapter
*adapter)
size = sizeof(struct atl1c_buffer) * (tpd_ring->count * 2 +
rfd_ring->count);
tpd_ring->buffer_info = kzalloc(size, GFP_KERNEL);
- if (unlikely(!tpd_ring->buffer_info)) {
- dev_err(&pdev->dev, "kzalloc failed, size = %d\n",
- size);
+ if (unlikely(!tpd_ring->buffer_info))
goto err_nomem;
- }
+
for (i = 0; i < AT_MAX_TRANSMIT_QUEUE; i++) {
tpd_ring[i].buffer_info =
(tpd_ring->buffer_info + count);
diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
index cf79d93..92f4734 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
@@ -819,8 +819,6 @@ static int atl1e_setup_ring_resources(struct atl1e_adapter
*adapter)
size = sizeof(struct atl1e_tx_buffer) * (tx_ring->count);
tx_ring->tx_buffer = kzalloc(size, GFP_KERNEL);
if (tx_ring->tx_buffer == NULL) {
- netdev_err(adapter->netdev, "kzalloc failed, size = D%d\n",
- size);
err = -ENOMEM;
goto failed;
}
diff --git a/drivers/net/ethernet/broadcom/b44.c
b/drivers/net/ethernet/broadcom/b44.c
index 3ba6be6..c030274 100644
--- a/drivers/net/ethernet/broadcom/b44.c
+++ b/drivers/net/ethernet/broadcom/b44.c
@@ -1518,10 +1518,8 @@ static void b44_setup_pseudo_magicp(struct b44 *bp)
u8 pwol_mask[B44_PMASK_SIZE];
pwol_pattern = kzalloc(B44_PATTERN_SIZE, GFP_KERNEL);
- if (!pwol_pattern) {
- pr_err("Memory not available for WOL\n")
[PATCH] net: core: Remove unnecessary alloc/OOM messages
alloc failures already get standardized OOM
messages and a dump_stack.
Signed-off-by: Joe Perches
---
net/core/dev.c| 14 +-
net/core/netprio_cgroup.c | 4 +---
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index a87bc74..e04bfdc 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5958,10 +5958,9 @@ static int netif_alloc_rx_queues(struct net_device *dev)
BUG_ON(count < 1);
rx = kcalloc(count, sizeof(struct netdev_rx_queue), GFP_KERNEL);
- if (!rx) {
- pr_err("netdev: Unable to allocate %u rx queues\n", count);
+ if (!rx)
return -ENOMEM;
- }
+
dev->_rx = rx;
for (i = 0; i < count; i++)
@@ -5992,10 +5991,9 @@ static int netif_alloc_netdev_queues(struct net_device
*dev)
BUG_ON(count < 1);
tx = kcalloc(count, sizeof(struct netdev_queue), GFP_KERNEL);
- if (!tx) {
- pr_err("netdev: Unable to allocate %u tx queues\n", count);
+ if (!tx)
return -ENOMEM;
- }
+
dev->_tx = tx;
netdev_for_each_tx_queue(dev, netdev_init_one_queue, NULL);
@@ -6482,10 +6480,8 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv,
const char *name,
alloc_size += NETDEV_ALIGN - 1;
p = kzalloc(alloc_size, GFP_KERNEL);
- if (!p) {
- pr_err("alloc_netdev: Unable to allocate device\n");
+ if (!p)
return NULL;
- }
dev = PTR_ALIGN(p, NETDEV_ALIGN);
dev->padded = (char *)dev - (char *)p;
diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index 5e67def..0777d0a 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -69,10 +69,8 @@ static int extend_netdev_table(struct net_device *dev, u32
target_idx)
/* allocate & copy */
new = kzalloc(new_sz, GFP_KERNEL);
- if (!new) {
- pr_warn("Unable to alloc new priomap!\n");
+ if (!new)
return -ENOMEM;
- }
if (old)
memcpy(new->priomap, old->priomap,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH wireless-next] brcmsmac: avoid 512 byte stack variable
On Thu, 2013-02-07 at 13:13 -0700, Tim Gardner wrote:
> Dynamically allocate the probe response template which
> avoids potential stack corruption. Observed with smatch:
trivial:
> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c
> b/drivers/net/wireless/brcm80211/brcmsmac/main.c
[]
> @@ -7408,9 +7408,16 @@ brcms_c_bss_update_probe_resp(struct brcms_c_info *wlc,
[]
> + prb_resp = kmalloc(BCN_TMPL_LEN, GFP_ATOMIC);
> + if (!prb_resp) {
> + wiphy_err(wlc->wiphy, "wl: %s: failed to alloc %u bytes\n",
> + __func__, BCN_TMPL_LEN);
Please remove the error message.
alloc's don't need specific OOM messages.
The mm subsystem already provides a standardized
message with a dump_stack().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mwl8k: Remove unnecessary alloc/OOM messages
alloc failures already get standardized OOM
messages and a dump_stack.
Signed-off-by: Joe Perches
---
drivers/net/wireless/mwl8k.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index 224cf91..e31f779 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -1146,7 +1146,6 @@ static int mwl8k_rxq_init(struct ieee80211_hw *hw, int
index)
rxq->buf = kcalloc(MWL8K_RX_DESCS, sizeof(*rxq->buf), GFP_KERNEL);
if (rxq->buf == NULL) {
- wiphy_err(hw->wiphy, "failed to alloc RX skbuff list\n");
pci_free_consistent(priv->pdev, size, rxq->rxd, rxq->rxd_dma);
return -ENOMEM;
}
@@ -1439,7 +1438,6 @@ static int mwl8k_txq_init(struct ieee80211_hw *hw, int
index)
txq->skb = kcalloc(MWL8K_TX_DESCS, sizeof(*txq->skb), GFP_KERNEL);
if (txq->skb == NULL) {
- wiphy_err(hw->wiphy, "failed to alloc TX skbuff list\n");
pci_free_consistent(priv->pdev, size, txq->txd, txq->txd_dma);
return -ENOMEM;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: net: Remove remaining alloc/OOM messages
alloc failures already get standardized OOM
messages and a dump_stack.
For the affected mallocs around these OOM messages:
Converted kmallocs with multiplies to kmalloc_array.
Converted a kmalloc/memcpy to kmemdup.
Removed now unused stack variables.
Removed unnecessary parentheses.
Neatened alignment.
Signed-off-by: Joe Perches
---
Let me know if you want multiple small patches instead.
drivers/net/can/usb/ems_usb.c | 4 +-
drivers/net/ethernet/amd/pcnet32.c | 47 +++---
drivers/net/ethernet/freescale/gianfar.c | 25 +---
drivers/net/ethernet/intel/e1000/e1000_main.c | 14 ++-
drivers/net/ethernet/intel/ixgb/ixgb_main.c| 10 +
drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 4 +-
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c| 2 -
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 11 ++---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 6 +--
drivers/net/ethernet/qlogic/qlge/qlge_main.c | 22 --
drivers/net/ethernet/smsc/smsc9420.c | 9 ++---
drivers/net/usb/pegasus.c | 6 +--
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 11 ++---
drivers/net/wireless/ath/ath9k/hw.c| 7 +---
drivers/net/wireless/ath/ath9k/rc.c| 12 +-
drivers/net/wireless/ath/wil6210/txrx.c| 2 -
drivers/net/wireless/ath/wil6210/wmi.c | 10 ++---
drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c | 5 +--
drivers/net/wireless/brcm80211/brcmfmac/usb.c | 7 ++--
drivers/net/wireless/mwl8k.c | 2 -
20 files changed, 66 insertions(+), 150 deletions(-)
diff --git a/drivers/net/can/usb/ems_usb.c b/drivers/net/can/usb/ems_usb.c
index 0e7bde7..5f9a7ad 100644
--- a/drivers/net/can/usb/ems_usb.c
+++ b/drivers/net/can/usb/ems_usb.c
@@ -1019,10 +1019,8 @@ static int ems_usb_probe(struct usb_interface *intf,
dev->tx_msg_buffer = kzalloc(CPC_HEADER_SIZE +
sizeof(struct ems_cpc_msg), GFP_KERNEL);
- if (!dev->tx_msg_buffer) {
- dev_err(&intf->dev, "Couldn't alloc Tx buffer\n");
+ if (!dev->tx_msg_buffer)
goto cleanup_intr_in_buffer;
- }
usb_set_intfdata(intf, dev);
diff --git a/drivers/net/ethernet/amd/pcnet32.c
b/drivers/net/ethernet/amd/pcnet32.c
index 74cfc01..797f847 100644
--- a/drivers/net/ethernet/amd/pcnet32.c
+++ b/drivers/net/ethernet/amd/pcnet32.c
@@ -494,19 +494,15 @@ static void pcnet32_realloc_tx_ring(struct net_device
*dev,
}
memset(new_tx_ring, 0, sizeof(struct pcnet32_tx_head) * (1 << size));
- new_dma_addr_list = kcalloc((1 << size), sizeof(dma_addr_t),
- GFP_ATOMIC);
- if (!new_dma_addr_list) {
- netif_err(lp, drv, dev, "Memory allocation failed\n");
+ new_dma_addr_list = kcalloc(1 << size, sizeof(dma_addr_t),
+ GFP_ATOMIC);
+ if (!new_dma_addr_list)
goto free_new_tx_ring;
- }
- new_skb_list = kcalloc((1 << size), sizeof(struct sk_buff *),
- GFP_ATOMIC);
- if (!new_skb_list) {
- netif_err(lp, drv, dev, "Memory allocation failed\n");
+ new_skb_list = kcalloc(1 << size, sizeof(struct sk_buff *),
+ GFP_ATOMIC);
+ if (!new_skb_list)
goto free_new_lists;
- }
kfree(lp->tx_skbuff);
kfree(lp->tx_dma_addr);
@@ -564,19 +560,14 @@ static void pcnet32_realloc_rx_ring(struct net_device
*dev,
}
memset(new_rx_ring, 0, sizeof(struct pcnet32_rx_head) * (1 << size));
- new_dma_addr_list = kcalloc((1 << size), sizeof(dma_addr_t),
- GFP_ATOMIC);
- if (!new_dma_addr_list) {
- netif_err(lp, drv, dev, "Memory allocation failed\n");
+ new_dma_addr_list = kcalloc(1 << size, sizeof(dma_addr_t), GFP_ATOMIC);
+ if (!new_dma_addr_list)
goto free_new_rx_ring;
- }
- new_skb_list = kcalloc((1 << size), sizeof(struct sk_buff *),
- GFP_ATOMIC);
- if (!new_skb_list) {
- netif_err(lp, drv, dev, "Memory allocation failed\n");
+ new_skb_list = kcalloc(1 << size, sizeof(struct sk_buff *),
+ GFP_ATOMIC);
+ if (!new_skb_list)
goto free_new_lists;
- }
/* first copy the current receive buffers */
overlap = min(size, lp->rx_ring_size);
@@ -1933,31 +1924,23 @@ static int pcnet32_alloc_ring(struct net_device *dev,
const char *name)
lp->tx_dma_addr = kcalloc(lp->tx_ring_size, sizeof(dma_addr_t),
Other alloc/OOM message question
On Fri, 2013-02-08 at 17:45 -0500, David Miller wrote: > From: Joe Perches > Date: Thu, 07 Feb 2013 13:46:27 -0800 > > alloc failures already get standardized OOM > > messages and a dump_stack. Does anyone know if all the other alloc's like dma_alloc_coherent, dma_alloc_noncoherent, pci_alloc_consistent always produce OOM messages via page_alloc/warn_alloc_failed for all arches? If so, there are many more of these OOM messages that could be removed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: add keyword "tegra" to Tegra section
On Fri, 2013-02-08 at 13:04 -0700, Stephen Warren wrote: > (?http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: add keyword "tegra" to Tegra section
On Fri, 2013-02-08 at 17:47 -0700, Stephen Warren wrote: > On 02/08/2013 05:40 PM, Joe Perches wrote: > > On Fri, 2013-02-08 at 13:04 -0700, Stephen Warren wrote: > >> (? > > > This doesn't work well. It matches too many > > words like integral. > > Hmmm. That's exactly what the (? attempting to avoid. It works fine here. Is there some dependency on > Perl version or something? My Perl version is v5.14.2. Integral matches I don't see any issue with using a leading \b -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: add keyword "tegra" to Tegra section
On Fri, 2013-02-08 at 20:15 -0700, Stephen Warren wrote: > Perhaps a custom almost-equivalent (?i)[^a-z]tegra would work? I didn't notice false positives with that one. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib: memcmp_nta: add timing-attack secure memcmp
On Sun, 2013-02-10 at 23:00 +0100, Daniel Borkmann wrote:
> add memcmp_nta ({n}o {t}iming {a}ttacks)
Why should this be in the kernel?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the wireless-next tree with the net-next tree
On Mon, 2013-02-11 at 13:33 +1100, Stephen Rothwell wrote:
> Hi John,
>
> Today's linux-next merge of the wireless-next tree got conflicts in
> drivers/net/wireless/ti/wlcore/sdio.c and
> drivers/net/wireless/ti/wlcore/spi.c between commit 0d2e7a5c6080
> ("wireless: Remove unnecessary alloc/OOM messages, alloc cleanups") from
> the net-next tree and commit afb43e6d88e5 ("wlcore: remove if_ops from
> platform_data") from the wireless-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
Thanks Stephen.
Can you remove just the dev_err below too please.
+ pdev_data = kzalloc(sizeof(*pdev_data), GFP_KERNEL);
+ if (!pdev_data) {
+ dev_err(&func->dev, "can't allocate platdev_data\n");
+ goto out;
+ }
Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] wlcore: remove newly introduced alloc/OOM messages
On Mon, 2013-02-11 at 10:02 +0200, Luciano Coelho wrote: > In commit 0d2e7a5c (wireless: Remove unnecessary alloc/OOM messages, > alloc cleanups) OOM messages after alloc were removed from the wlcore > modules. > > Commit afb43e6d (wlcore: remove if_ops from platform_data) > reintroduced a couple of those. This patch removes them. You sure? The largish patch doesn't match the commit message. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] MAINTAINERS: add keyword "tegra" to Tegra section
On Mon, 2013-02-11 at 10:51 -0700, Stephen Warren wrote: > From: Stephen Warren > > The intent is to ensure that all Tegra-related patches are sent to the > linux-tegra@ mailing list, so people can keep up-to-date on all misc > driver changes. > > Doing this with a keyword is far simpler and more compact than listing > all Tegra-related drivers, even if wildcards were used. > > Words such as integrate or integrator are common. Ensure the character > right before "tegra" isn't a-z (case-insensitive), to make sure the > keyword doesn't match those. > > Cc: Joe Perches > Signed-off-by: Stephen Warren > --- > MAINTAINERS |4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index b98c89b..10e9b31 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7829,9 +7829,7 @@ L: linux-te...@vger.kernel.org > Q: http://patchwork.ozlabs.org/project/linux-tegra/list/ > T: git > git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git > S: Supported > -F: arch/arm/mach-tegra > -F: arch/arm/boot/dts/tegra* > -F: arch/arm/configs/tegra_defconfig > +K: (?i)[^a-z]tegra > > TEHUTI ETHERNET DRIVER > M: Andy Gospodarek It's probably not a good idea to remove any of the F: lines as there are files that could get modified in those paths without any tegra word in the patch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] MAINTAINERS: add keyword "tegra" to Tegra section
On Mon, 2013-02-11 at 11:01 -0700, Stephen Warren wrote: > On 02/11/2013 10:56 AM, Joe Perches wrote: > > On Mon, 2013-02-11 at 10:51 -0700, Stephen Warren wrote: > >> From: Stephen Warren > >> > >> The intent is to ensure that all Tegra-related patches are sent to the > >> linux-tegra@ mailing list, so people can keep up-to-date on all misc > >> driver changes. > >> > >> Doing this with a keyword is far simpler and more compact than listing > >> all Tegra-related drivers, even if wildcards were used. > >> > >> Words such as integrate or integrator are common. Ensure the character > >> right before "tegra" isn't a-z (case-insensitive), to make sure the > >> keyword doesn't match those. > >> > >> Cc: Joe Perches > >> Signed-off-by: Stephen Warren > >> --- > >> MAINTAINERS |4 +--- > >> 1 file changed, 1 insertion(+), 3 deletions(-) > >> > >> diff --git a/MAINTAINERS b/MAINTAINERS > >> index b98c89b..10e9b31 100644 > >> --- a/MAINTAINERS > >> +++ b/MAINTAINERS > >> @@ -7829,9 +7829,7 @@ L: linux-te...@vger.kernel.org > >> Q:http://patchwork.ozlabs.org/project/linux-tegra/list/ > >> T:git > >> git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git > >> S:Supported > >> -F:arch/arm/mach-tegra > >> -F:arch/arm/boot/dts/tegra* > >> -F:arch/arm/configs/tegra_defconfig > >> +K:(?i)[^a-z]tegra > >> > >> TEHUTI ETHERNET DRIVER > >> M:Andy Gospodarek > > > > It's probably not a good idea to remove > > any of the F: lines as there are files > > that could get modified in those paths > > without any tegra word in the patch. > > At least for those F: lines that exist already and are removed above, > the keyword will match their filename, so there's no issue here. > Not every use of get_maintainers is by patch. ./scripts/get_maintainer.pl -f arch/arm/mach-tegra wouldn't match anything. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] MAINTAINERS: add keyword "tegra" to Tegra section
On Mon, 2013-02-11 at 11:12 -0700, Stephen Warren wrote: > On 02/11/2013 11:04 AM, Joe Perches wrote: > > ./scripts/get_maintainer.pl -f arch/arm/mach-tegra > > wouldn't match anything. > > That's annoying; it kinda defeats the whole purpose of this patch then. > > The way this patch works out with a patch is because the file-names are > matched against the keywords since they appear in the patch. A solution > to the issue you raise would be to do the same in -f mode, by adding an > explicit pass to check the filenames that are found against MAINTAINERS > too. Do you have any objection to that? Knock yourself out. Are there any tegra related files that would not have tegra in the path? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] MAINTAINERS: add keyword "tegra" to Tegra section
On Mon, 2013-02-11 at 10:19 -0800, Joe Perches wrote: > On Mon, 2013-02-11 at 11:12 -0700, Stephen Warren wrote: > > On 02/11/2013 11:04 AM, Joe Perches wrote: > > > ./scripts/get_maintainer.pl -f arch/arm/mach-tegra > > > wouldn't match anything. > > > > That's annoying; it kinda defeats the whole purpose of this patch then. > > > > The way this patch works out with a patch is because the file-names are > > matched against the keywords since they appear in the patch. A solution > > to the issue you raise would be to do the same in -f mode, by adding an > > explicit pass to check the filenames that are found against MAINTAINERS > > too. Do you have any objection to that? > > Knock yourself out. > > Are there any tegra related files that would not > have tegra in the path? To answer my own question: $ git ls-files | grep -v tegra | xargs grep -Pl "(?i)[^a-z]tegra" ... Several. Most are Kconfig and Makefiles. Most except staging/nvec don't seem to be very important. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: media: Remove unnecessary OOM messages
alloc failures already get standardized OOM
messages and a dump_stack.
Signed-off-by: Joe Perches
---
drivers/staging/media/as102/as102_usb_drv.c | 4 +---
drivers/staging/media/go7007/go7007-fw.c| 24 +++-
drivers/staging/media/go7007/s2250-loader.c | 5 ++---
drivers/staging/media/lirc/lirc_imon.c | 3 ---
drivers/staging/media/lirc/lirc_sasem.c | 6 --
5 files changed, 10 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/media/as102/as102_usb_drv.c
b/drivers/staging/media/as102/as102_usb_drv.c
index aaf1bc2..9f275f0 100644
--- a/drivers/staging/media/as102/as102_usb_drv.c
+++ b/drivers/staging/media/as102/as102_usb_drv.c
@@ -374,10 +374,8 @@ static int as102_usb_probe(struct usb_interface *intf,
}
as102_dev = kzalloc(sizeof(struct as102_dev_t), GFP_KERNEL);
- if (as102_dev == NULL) {
- dev_err(&intf->dev, "%s: kzalloc failed\n", __func__);
+ if (as102_dev == NULL)
return -ENOMEM;
- }
/* Assign the user-friendly device name */
for (i = 0; i < ARRAY_SIZE(as102_usb_id_table); i++) {
diff --git a/drivers/staging/media/go7007/go7007-fw.c
b/drivers/staging/media/go7007/go7007-fw.c
index f99c05b..a5ede1c 100644
--- a/drivers/staging/media/go7007/go7007-fw.c
+++ b/drivers/staging/media/go7007/go7007-fw.c
@@ -381,11 +381,8 @@ static int gen_mjpeghdr_to_package(struct go7007 *go,
__le16 *code, int space)
int size = 0, i, off = 0, chunk;
buf = kzalloc(4096, GFP_KERNEL);
- if (buf == NULL) {
- dev_err(go->dev,
- "unable to allocate 4096 bytes for firmware
construction\n");
+ if (buf == NULL)
return -1;
- }
for (i = 1; i < 32; ++i) {
mjpeg_frame_header(go, buf + size, i);
@@ -651,11 +648,9 @@ static int gen_mpeg1hdr_to_package(struct go7007 *go,
int i, off = 0, chunk;
buf = kzalloc(5120, GFP_KERNEL);
- if (buf == NULL) {
- dev_err(go->dev,
- "unable to allocate 5120 bytes for firmware
construction\n");
+ if (buf == NULL)
return -1;
- }
+
framelen[0] = mpeg1_frame_header(go, buf, 0, 1, PFRAME);
if (go->interlace_coding)
framelen[0] += mpeg1_frame_header(go, buf + framelen[0] / 8,
@@ -838,11 +833,9 @@ static int gen_mpeg4hdr_to_package(struct go7007 *go,
int i, off = 0, chunk;
buf = kzalloc(5120, GFP_KERNEL);
- if (buf == NULL) {
- dev_err(go->dev,
- "unable to allocate 5120 bytes for firmware
construction\n");
+ if (buf == NULL)
return -1;
- }
+
framelen[0] = mpeg4_frame_header(go, buf, 0, PFRAME);
i = 368;
framelen[1] = mpeg4_frame_header(go, buf + i, 0, BFRAME_PRE);
@@ -1582,12 +1575,9 @@ int go7007_construct_fw_image(struct go7007 *go, u8
**fw, int *fwlen)
return -1;
}
code = kzalloc(codespace * 2, GFP_KERNEL);
- if (code == NULL) {
- dev_err(go->dev,
- "unable to allocate %d bytes for firmware
construction\n",
- codespace * 2);
+ if (code == NULL)
goto fw_failed;
- }
+
src = (__le16 *)fw_entry->data;
srclen = fw_entry->size / 2;
while (srclen >= 2) {
diff --git a/drivers/staging/media/go7007/s2250-loader.c
b/drivers/staging/media/go7007/s2250-loader.c
index f57eb3b..72e5175 100644
--- a/drivers/staging/media/go7007/s2250-loader.c
+++ b/drivers/staging/media/go7007/s2250-loader.c
@@ -81,10 +81,9 @@ static int s2250loader_probe(struct usb_interface *interface,
/* Allocate dev data structure */
s = kmalloc(sizeof(device_extension_t), GFP_KERNEL);
- if (s == NULL) {
- dev_err(&interface->dev, "Out of memory\n");
+ if (s == NULL)
goto failed;
- }
+
s2250_dev_table[minor] = s;
dev_info(&interface->dev,
diff --git a/drivers/staging/media/lirc/lirc_imon.c
b/drivers/staging/media/lirc/lirc_imon.c
index 343c622..0a2c45d 100644
--- a/drivers/staging/media/lirc/lirc_imon.c
+++ b/drivers/staging/media/lirc/lirc_imon.c
@@ -744,7 +744,6 @@ static int imon_probe(struct usb_interface *interface,
context = kzalloc(sizeof(struct imon_context), GFP_KERNEL);
if (!context) {
- dev_err(dev, "%s: kzalloc failed for context\n", __func__);
alloc_status = 1;
goto alloc_status_switch;
}
@@ -826,13 +825,11 @@ static int imon_probe(struct usb_interface *interface,
driver = kzalloc(sizeof(struct lirc_driver), GFP_KERNEL);
if (!driver) {
- dev_err(dev, "%s: kzalloc failed for lirc_driver\n", __
[PATCH] scripts: Remove Lindent and suggestions to use it
Lindent had its last good day more than a decade ago. Time to put it down. Remove suggestions to use it too. Signed-off-by: Joe Perches --- Documentation/CodingStyle | 15 --- Documentation/hwmon/submitting-patches | 5 - scripts/Lindent| 18 -- 3 files changed, 38 deletions(-) delete mode 100755 scripts/Lindent diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index e00b8f0..020d1b6 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -514,21 +514,6 @@ values. To do the latter, you can stick the following in your .emacs file: This will make emacs go better with the kernel coding style for C files below ~/src/linux-trees. -But even if you fail in getting emacs to do sane formatting, not -everything is lost: use "indent". - -Now, again, GNU indent has the same brain-dead settings that GNU emacs -has, which is why you need to give it a few command line options. -However, that's not too bad, because even the makers of GNU indent -recognize the authority of K&R (the GNU people aren't evil, they are -just severely misguided in this matter), so you just give indent the -options "-kr -i8" (stands for "K&R, 8 character indents"), or use -"scripts/Lindent", which indents in the latest style. - -"indent" has a lot of options, and especially when it comes to comment -re-formatting you may want to take a look at the man page. But -remember: "indent" is not a fix for bad programming. - Chapter 10: Kconfig configuration files diff --git a/Documentation/hwmon/submitting-patches b/Documentation/hwmon/submitting-patches index 843751c..449d630 100644 --- a/Documentation/hwmon/submitting-patches +++ b/Documentation/hwmon/submitting-patches @@ -49,11 +49,6 @@ increase the chances of your change being accepted. 3. New drivers -- -* Running your patch or driver file(s) through checkpatch does not mean its - formatting is clean. If unsure about formatting in your new driver, run it - through Lindent. Lindent is not perfect, and you may have to do some minor - cleanup, but it is a good start. - * Consider adding yourself to MAINTAINERS. * Document the driver in Documentation/hwmon/. diff --git a/scripts/Lindent b/scripts/Lindent deleted file mode 100755 index 9c4b3e2..000 --- a/scripts/Lindent +++ /dev/null @@ -1,18 +0,0 @@ -#!/bin/sh -PARAM="-npro -kr -i8 -ts8 -sob -l80 -ss -ncs -cp1" -RES=`indent --version` -V1=`echo $RES | cut -d' ' -f3 | cut -d'.' -f1` -V2=`echo $RES | cut -d' ' -f3 | cut -d'.' -f2` -V3=`echo $RES | cut -d' ' -f3 | cut -d'.' -f3` -if [ $V1 -gt 2 ]; then - PARAM="$PARAM -il0" -elif [ $V1 -eq 2 ]; then - if [ $V2 -gt 2 ]; then -PARAM="$PARAM -il0"; - elif [ $V2 -eq 2 ]; then -if [ $V3 -ge 10 ]; then - PARAM="$PARAM -il0" -fi - fi -fi -indent $PARAM "$@" -- 1.8.1.2.459.gbcd45b4.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 1/2] get_maintainer: allow keywords to match filenames
On Mon, 2013-02-11 at 16:40 -0700, Stephen Warren wrote:
> From: Stephen Warren
>
> Allow K: entries in MAINTAINERS to match directly against filenames;
> either those extracted from patch +++ or --- lines, or those specified
> on the command-line using the -f option.
[]
> I don't think setting exact_pattern_match_hash would be appropriate here;
> at least for intended Tegra use case, this feature is to ensure that all
> Tegra-related driver changes get Cc'd to the Tegra mailing list. Setting
> exact_pattern_match_hash would prevent git history parsing for e.g. S-o-b
> tags, which still seems like it would be useful. Hence, this flag isn't
> set.
And I don't think that's necessary because for filenames,
you could add the appropriate control to the MAINTAINERS
"K: ^pattern$"
> The value in $hash{$tvi} doesn't seem relevant, so I just assign 0.
0 is good.
It would be relevant if --pattern-depth was set.
> Joe, I'm not sure if you care where this gets merged; could it go through
> arm-soc together with patch 2/2? A quick look at git history of the
> script in linux-next indicates there won't be conflicts doing that.
I don't care how it gets merged.
Andrew Morton typically picks these up but
if you want to get it merged separately,
I don't see a problem.
trivial comment below:
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
[]
> @@ -611,6 +611,10 @@ sub get_maintainers {
> $hash{$tvi} = $value_pd;
> }
> }
> + } elsif ($type eq "K") {
This should probably be 'K' to match the other
'F' use above it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/2] MAINTAINERS: update Tegra section to capture all Tegra files
On Mon, 2013-02-11 at 16:40 -0700, Stephen Warren wrote: > From: Stephen Warren > > The intent is to ensure that all Tegra-related patches are sent to the > linux-tegra@ mailing list, so people can keep up-to-date on all misc > driver changes. > > Doing this with a keyword is far simpler and more compact than listing > all Tegra-related drivers, even if wildcards were used. > > Words such as integrate or integrator are common. Ensure the character > right before "tegra" isn't a-z (case-insensitive), to make sure the > keyword doesn't match those. > > The only files that the keyword doesn't match are the NVEC driver. Add > the linux-tegra mailing list to the NVEC entry to solve this. You should probably add some commentary/documentation to the K: section description of MAINTAINERS in patch 1/2. Something about K: patterns also matching filenames. K: Keyword perl extended regex pattern to match content in a patch or file. For instance: K: of_get_profile matches patches or files that contain "of_get_profile" K: \b(printk|pr_(info|err))\b matches patches or files that contain one or more of the words printk, pr_info or pr_err One regex pattern per line. Multiple K: lines acceptable. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 1/2] get_maintainer: allow keywords to match filenames
On Mon, 2013-02-11 at 17:08 -0700, Stephen Warren wrote: > Does "that" above mean "not setting exact_pattern_match_hash", or > "changing the patch so that it does set exact_pattern_match_hash". Sorry... I think what you have is fine. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 1/2] get_maintainer: allow keywords to match filenames
On Mon, 2013-02-11 at 17:39 -0700, Stephen Warren wrote: > From: Stephen Warren > > Allow K: entries in MAINTAINERS to match directly against filenames; > either those extracted from patch +++ or --- lines, or those specified > on the command-line using the -f option. [] > diff --git a/MAINTAINERS b/MAINTAINERS [] > @@ -97,12 +97,12 @@ Descriptions of section entries: > X: net/ipv6/ > matches all files in and below net excluding net/ipv6/ > K: Keyword perl extended regex pattern to match content in a > -patch or file. For instance: > +patch, or an affected filename. For instance: The removal of file isn't correct. This should read "patch, file or filename". If the -f pattern is a single file, get_maintainer reads that file content and then matches any K: patterns. When the -f pattern is a directory, it doesn't. > K: of_get_profile > - matches patches or files that contain "of_get_profile" > + matches patches or filenames that contain "of_get_profile" here too. > K: \b(printk|pr_(info|err))\b > - matches patches or files that contain one or more of the words > - printk, pr_info or pr_err > + matches patches or filenames that contain one or more of > + the words printk, pr_info or pr_err three. cheers, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 1/2] get_maintainer: allow keywords to match filenames
On Tue, 2013-02-12 at 11:17 -0700, Stephen Warren wrote: > On 02/11/2013 11:17 PM, Joe Perches wrote: > > If the -f pattern is a single file, > > get_maintainer reads that file content and then > > matches any K: patterns. > > > > When the -f pattern is a directory, it doesn't. > > Yes, I guess that's true; I had convinced myself that "file" wasn't > accurate since "-f directory/" didn't scan the files within that > directory tree, but as you say "-f file" does scan the file content. > > BTW, given I'm adding "filename" to the list, I intend to change the > existing "file" to "file content" to be clear. Are you OK with that? Sure. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MAINTAINERS: Remove Jarod Wilson and orphan LIRC drivers
His email bounces and he hasn't done work on these sections in a couple of years. Signed-off-by: Joe Perches --- MAINTAINERS | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1d0651e..8d47b3a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7523,7 +7523,6 @@ F:drivers/staging/comedi/ STAGING - CRYSTAL HD VIDEO DECODER M: Naren Sankar -M: Jarod Wilson M: Scott Davilla M: Manu Abraham S: Odd Fixes @@ -7557,9 +7556,8 @@ S:Odd Fixes F: drivers/staging/iio/ STAGING - LIRC (LINUX INFRARED REMOTE CONTROL) DRIVERS -M: Jarod Wilson W: http://www.lirc.org/ -S: Odd Fixes +S: Orphan F: drivers/staging/media/lirc/ STAGING - NVIDIA COMPLIANT EMBEDDED CONTROLLER INTERFACE (nvec) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Fwd: Re: [PATCH] MAINTAINERS: Remove Jarod Wilson and orphan LIRC drivers]
Jerod? Remove you from MAINTAINERS or not? Your wilsonet address is bouncing. https://lkml.org/lkml/2013/2/12/531 cheers, Joe Forwarded Message From: Hans de Goede To: Joe Perches Subject: Re: [PATCH] MAINTAINERS: Remove Jarod Wilson and orphan LIRC drivers Hi On 02/12/2013 10:20 PM, Joe Perches wrote: > His email bounces jwil...@redhat.com should work I think. Note I think this may be the right call, but asking him directly is better :) Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] Introduce Intel RAPL cooling device driver
On Tue, 2013-04-02 at 15:15 -0700, Jacob Pan wrote:
> RAPL(Running Average Power Limit) interface provides platform software
> with the ability to monitor, control, and get notifications on SOC
> power consumptions. Since its first appearance on Sandy Bridge, more
> features have being added to extend its usage. In RAPL, platforms are
> divided into domains for fine grained control. These domains include
> package, DRAM controller, CPU core (Power Plane 0), graphics uncore
> (power plane 1), etc.
trivia only:
> diff --git a/drivers/platform/x86/intel_rapl.c
> b/drivers/platform/x86/intel_rapl.c
[]
> +static char *rapl_domain_names[] = {
> + "package",
> + "power_plane_0",
> + "power_plane_1",
> + "dram",
> +};
const
> +static void rapl_init_domains(void)
> +{
> + int i, j = 0;
I think this below is unpleasant to read.
Maybe add a temporary pointer and get rid of j?
typeof rapl_domains *t = rapl_domains;
(not typeof, but the actual type)
> +
> + for (i = 0; i < RAPL_DOMAIN_MAX; i++) {
> + unsigned int mask = rg_data.domain_map & (1 << i);
> +
> + switch (mask) {
> + case 1 << RAPL_DOMAIN_PKG:
> + rapl_domains[j].name =
> + rapl_domain_names[RAPL_DOMAIN_PKG];
t->name = rapl_domain_names[RAPL_DOMAIN_PKG];
etc...
[]
> + if (mask)
> + j++;
t++;
> +/* in the order of enum rapl_primitives */
> +static struct rapl_primitive_info rpi[] = {
const?
> + /* name, mask, shift, msr index, unit divisor*/
> + PRIMITIVE_INFO_INIT(energy, ENERGY_STATUS_MASK, 0,
> + RAPL_DOMAIN_MSR_STATUS, ENERGY_UNIT,
> + RAPL_PRIMITIVE_EVENT_CAP),
[]
> +static int rapl_read_data_raw(struct rapl_domain *domain,
> + struct rapl_primitive_info *rp, bool xlate, u64 *data)
> +{
[]
> + /* specical-case pkg lock bit since pkg domain uses a different bit */
special-case
[]
> +static ssize_t store_event_control(struct rapl_domain *rd, const char *buf,
> + size_t size)
> +{
> + unsigned int efd, cfd, new_threshold;
> + struct file *efile = NULL;
> + struct file *cfile = NULL;
> + int ret = 0;
> + int prim;
> + struct rapl_event *ep;
> + u64 val;
> +
> + if (sscanf(buf, "%u %u %u", &efd, &cfd, &new_threshold) != 3)
> + return -EINVAL;
> +
> + efile = eventfd_fget(efd);
> + if (IS_ERR(efile)) {
> + ret = PTR_ERR(efile);
> + pr_err("failed to get eventfd file %d\n", efd);
> + goto done;
> + }
> + cfile = fget(cfd);
> + if (!cfile) {
> + ret = -EBADF;
> + fput(efile);
> + goto done;
> + }
> + /* check if the cfile belongs to the same rapl domain */
> + if (strcmp(rd->kobj.sd->s_name,
> + cfile->f_dentry->d_parent->d_name.name)) {
> + pr_debug("cfile does not belong to domain %s\n",
> + rd->kobj.sd->s_name);
> + ret = -EINVAL;
> + goto exit_cleanup_fds;
> + }
> + prim = primitive_name_to_entry(
> + (const char *)cfile->f_dentry->d_name.name);
> + if (prim < 0) {
> + pr_err("failed lookup primitive id for control file %s\n",
> + cfile->f_dentry->d_name.name);
> + ret = -EINVAL;
> + goto exit_cleanup_fds;
> + }
> + if (!(rpi[prim].flag & RAPL_PRIMITIVE_EVENT_CAP)) {
> + pr_info("Invalid control file %d\n", prim);
> + ret = -EINVAL;
> + goto exit_cleanup_fds;
> + }
Perhaps all these pr_ should be pr_err as they
all lead to a failure path.
[]
> +static int stop_periodic_polling(void)
> +{
> + if (true == polling_started) {
You don't need a comparison,
if (polling_started) {
is perhaps better.
[]
> +static int rapl_detect_domains(void)
> +{
[]
> + pr_info("Found %d vaild RAPL domains\n", rg_data.nr_domains);
valid
> + rapl_domains = kzalloc(sizeof(struct rapl_domain) * rg_data.nr_domains,
> + GFP_KERNEL);
kcalloc
> + if (NULL == rapl_domains) {
> + pr_err("Failed to allocate memory for rapl domain\n");
You don't need OOM messages as the memory
subsystem already does a dump_stack on OOM.
[]
> +static int __init intel_rapl_init(void)
> +{
> + rd_data = kzalloc(sizeof(struct rapl_domain_data) * rg_data.nr_domains,
> + GFP_KERNEL);
kcalloc again.
> + if (NULL == rd_data) {
> + pr_err("Failed to allocate memory for rapl domain data\n");
OOM too.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux
Re: [PATCH] nfc: Remove useless Makefile line
On Fri, 2013-04-05 at 18:31 +0200, Paul Bolle wrote: > There's no Kconfig symbol NFC_DEBUG. Besides, there doesn't seem to be > any nfc code that uses a DEBUG macro. This line can safely be removed. [] > diff --git a/drivers/nfc/Makefile b/drivers/nfc/Makefile [] > -ccflags-$(CONFIG_NFC_DEBUG) := -DDEBUG pr_debug/dev_dbg/nfc_dev_dbg logging messages depend on this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nfc: Remove useless Makefile line
On Fri, 2013-04-05 at 18:39 +0200, Paul Bolle wrote: > On Fri, 2013-04-05 at 09:35 -0700, Joe Perches wrote: > > On Fri, 2013-04-05 at 18:31 +0200, Paul Bolle wrote: > > > -ccflags-$(CONFIG_NFC_DEBUG) := -DDEBUG > > > > pr_debug/dev_dbg/nfc_dev_dbg logging messages > > depend on this. > > Thanks. But then a NFC_DEBUG symbol needs to be added, because now the > DEBUG macro will never be set, won't it? Probably right. I think all the nfc_dev_ uses are unsightly too. Almost all the nfc_dev_dbg uses are functdion enter/leave logging and should be done via the function tracer. I'll submit some patches for that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] nfc: standardize logging styles
Fix some defects in the logging too Joe Perches (3): nfc: Replace nfc_dev_dbg with dev_dbg, remove function tracing nfc: Convert nfc_dev_info and nfc_dev_err to nfc_ nfc: Standardize logging style drivers/nfc/microread/i2c.c | 32 ++--- drivers/nfc/microread/mei.c | 20 +-- drivers/nfc/microread/microread.c | 7 +- drivers/nfc/nfcwilink.c | 95 ++--- drivers/nfc/pn533.c | 271 -- drivers/nfc/pn544/i2c.c | 38 +++--- drivers/nfc/pn544/pn544.c | 13 +- include/net/nfc/nfc.h | 5 +- 8 files changed, 196 insertions(+), 285 deletions(-) -- 1.8.1.2.459.gbcd45b4.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] nfc: Replace nfc_dev_dbg with dev_dbg, remove function tracing
Use the generic kernel function instead of a home-grown
one that does the same thing. Remove empty function
tracing style uses as the kernel function tracer does
that too.
Add \n to uses not at the macro. Don't add \n where
the nfc_dev_dbg macro mistakenly had them already.
Signed-off-by: Joe Perches
---
drivers/nfc/nfcwilink.c | 51 +++--
drivers/nfc/pn533.c | 118
include/net/nfc/nfc.h | 1 -
3 files changed, 56 insertions(+), 114 deletions(-)
diff --git a/drivers/nfc/nfcwilink.c b/drivers/nfc/nfcwilink.c
index 3b731ac..b2f4040 100644
--- a/drivers/nfc/nfcwilink.c
+++ b/drivers/nfc/nfcwilink.c
@@ -146,8 +146,6 @@ static int nfcwilink_get_bts_file_name(struct nfcwilink
*drv, char *file_name)
unsigned long comp_ret;
int rc;
- nfc_dev_dbg(&drv->pdev->dev, "get_bts_file_name entry");
-
skb = nfcwilink_skb_alloc(sizeof(struct nci_vs_nfcc_info_cmd),
GFP_KERNEL);
if (!skb) {
@@ -172,17 +170,16 @@ static int nfcwilink_get_bts_file_name(struct nfcwilink
*drv, char *file_name)
comp_ret = wait_for_completion_timeout(&drv->completed,
msecs_to_jiffies(NFCWILINK_CMD_TIMEOUT));
- nfc_dev_dbg(&drv->pdev->dev, "wait_for_completion_timeout returned %ld",
- comp_ret);
+ dev_dbg(&drv->pdev->dev, "wait_for_completion_timeout returned %ld\n",
+ comp_ret);
if (comp_ret == 0) {
- nfc_dev_err(&drv->pdev->dev,
- "timeout on wait_for_completion_timeout");
+ dev_err(&drv->pdev->dev,
+ "timeout on wait_for_completion_timeout\n");
return -ETIMEDOUT;
}
- nfc_dev_dbg(&drv->pdev->dev, "nci_vs_nfcc_info_rsp: plen %d, status %d",
- drv->nfcc_info.plen,
- drv->nfcc_info.status);
+ dev_dbg(&drv->pdev->dev, "nci_vs_nfcc_info_rsp: plen %d, status %d\n",
+ drv->nfcc_info.plen, drv->nfcc_info.status);
if ((drv->nfcc_info.plen != 5) || (drv->nfcc_info.status != 0)) {
nfc_dev_err(&drv->pdev->dev,
@@ -209,8 +206,6 @@ static int nfcwilink_send_bts_cmd(struct nfcwilink *drv,
__u8 *data, int len)
unsigned long comp_ret;
int rc;
- nfc_dev_dbg(&drv->pdev->dev, "send_bts_cmd entry");
-
/* verify valid cmd for the NFC channel */
if ((len <= sizeof(struct nfcwilink_hdr)) ||
(len > BTS_FILE_CMD_MAX_LEN) ||
@@ -242,8 +237,8 @@ static int nfcwilink_send_bts_cmd(struct nfcwilink *drv,
__u8 *data, int len)
comp_ret = wait_for_completion_timeout(&drv->completed,
msecs_to_jiffies(NFCWILINK_CMD_TIMEOUT));
- nfc_dev_dbg(&drv->pdev->dev, "wait_for_completion_timeout returned %ld",
- comp_ret);
+ dev_dbg(&drv->pdev->dev, "wait_for_completion_timeout returned %ld\n",
+ comp_ret);
if (comp_ret == 0) {
nfc_dev_err(&drv->pdev->dev,
"timeout on wait_for_completion_timeout");
@@ -261,8 +256,6 @@ static int nfcwilink_download_fw(struct nfcwilink *drv)
__u8 *ptr;
int len, rc;
- nfc_dev_dbg(&drv->pdev->dev, "download_fw entry");
-
set_bit(NFCWILINK_FW_DOWNLOAD, &drv->flags);
rc = nfcwilink_get_bts_file_name(drv, file_name);
@@ -284,8 +277,8 @@ static int nfcwilink_download_fw(struct nfcwilink *drv)
ptr = (__u8 *)fw->data;
if ((len == 0) || (ptr == NULL)) {
- nfc_dev_dbg(&drv->pdev->dev,
- "request_firmware returned size %d", len);
+ dev_dbg(&drv->pdev->dev,
+ "request_firmware returned size %d\n", len);
goto release_fw;
}
@@ -306,8 +299,8 @@ static int nfcwilink_download_fw(struct nfcwilink *drv)
action_len =
__le16_to_cpu(((struct bts_file_action *)ptr)->len);
- nfc_dev_dbg(&drv->pdev->dev, "bts_file_action type %d, len %d",
- action_type, action_len);
+ dev_dbg(&drv->pdev->dev, "bts_file_action type %d, len %d\n",
+ action_type, action_len);
switch (action_type) {
case BTS_FILE_ACTION_TYPE_SEND_CMD:
@@ -337,8 +330,6 @@ static void nfcwilink_register_complete(void *priv_data,
char data)
{
struct nf
[PATCH 2/3] nfc: Convert nfc_dev_info and nfc_dev_err to nfc_
Use a more standard kernel style macro logging name.
Standardize the spacing of the "NFC: " prefix.
Add \n to uses, remove from macro.
Fix the defective uses that already had a \n.
Signed-off-by: Joe Perches
---
drivers/nfc/nfcwilink.c | 44 +++---
drivers/nfc/pn533.c | 156
include/net/nfc/nfc.h | 4 +-
3 files changed, 100 insertions(+), 104 deletions(-)
diff --git a/drivers/nfc/nfcwilink.c b/drivers/nfc/nfcwilink.c
index b2f4040..f58b390 100644
--- a/drivers/nfc/nfcwilink.c
+++ b/drivers/nfc/nfcwilink.c
@@ -149,8 +149,8 @@ static int nfcwilink_get_bts_file_name(struct nfcwilink
*drv, char *file_name)
skb = nfcwilink_skb_alloc(sizeof(struct nci_vs_nfcc_info_cmd),
GFP_KERNEL);
if (!skb) {
- nfc_dev_err(&drv->pdev->dev,
- "no memory for nci_vs_nfcc_info_cmd");
+ nfc_err(&drv->pdev->dev,
+ "no memory for nci_vs_nfcc_info_cmd\n");
return -ENOMEM;
}
@@ -182,8 +182,7 @@ static int nfcwilink_get_bts_file_name(struct nfcwilink
*drv, char *file_name)
drv->nfcc_info.plen, drv->nfcc_info.status);
if ((drv->nfcc_info.plen != 5) || (drv->nfcc_info.status != 0)) {
- nfc_dev_err(&drv->pdev->dev,
- "invalid nci_vs_nfcc_info_rsp");
+ nfc_err(&drv->pdev->dev, "invalid nci_vs_nfcc_info_rsp\n");
return -EINVAL;
}
@@ -194,7 +193,7 @@ static int nfcwilink_get_bts_file_name(struct nfcwilink
*drv, char *file_name)
drv->nfcc_info.sw_ver_z,
drv->nfcc_info.patch_id);
- nfc_dev_info(&drv->pdev->dev, "nfcwilink FW file name: %s", file_name);
+ nfc_info(&drv->pdev->dev, "nfcwilink FW file name: %s\n", file_name);
return 0;
}
@@ -211,8 +210,8 @@ static int nfcwilink_send_bts_cmd(struct nfcwilink *drv,
__u8 *data, int len)
(len > BTS_FILE_CMD_MAX_LEN) ||
(hdr->chnl != NFCWILINK_CHNL) ||
(hdr->opcode != NFCWILINK_OPCODE)) {
- nfc_dev_err(&drv->pdev->dev,
- "ignoring invalid bts cmd, len %d, chnl %d, opcode %d",
+ nfc_err(&drv->pdev->dev,
+ "ignoring invalid bts cmd, len %d, chnl %d, opcode
%d\n",
len, hdr->chnl, hdr->opcode);
return 0;
}
@@ -223,7 +222,7 @@ static int nfcwilink_send_bts_cmd(struct nfcwilink *drv,
__u8 *data, int len)
skb = nfcwilink_skb_alloc(len, GFP_KERNEL);
if (!skb) {
- nfc_dev_err(&drv->pdev->dev, "no memory for bts cmd");
+ nfc_err(&drv->pdev->dev, "no memory for bts cmd\n");
return -ENOMEM;
}
@@ -240,8 +239,8 @@ static int nfcwilink_send_bts_cmd(struct nfcwilink *drv,
__u8 *data, int len)
dev_dbg(&drv->pdev->dev, "wait_for_completion_timeout returned %ld\n",
comp_ret);
if (comp_ret == 0) {
- nfc_dev_err(&drv->pdev->dev,
- "timeout on wait_for_completion_timeout");
+ nfc_err(&drv->pdev->dev,
+ "timeout on wait_for_completion_timeout\n");
return -ETIMEDOUT;
}
@@ -264,7 +263,7 @@ static int nfcwilink_download_fw(struct nfcwilink *drv)
rc = request_firmware(&fw, file_name, &drv->pdev->dev);
if (rc) {
- nfc_dev_err(&drv->pdev->dev, "request_firmware failed %d", rc);
+ nfc_err(&drv->pdev->dev, "request_firmware failed %d\n", rc);
/* if the file is not found, don't exit with failure */
if (rc == -ENOENT)
@@ -284,7 +283,7 @@ static int nfcwilink_download_fw(struct nfcwilink *drv)
if (__le32_to_cpu(((struct bts_file_hdr *)ptr)->magic) !=
BTS_FILE_HDR_MAGIC) {
- nfc_dev_err(&drv->pdev->dev, "wrong bts magic number");
+ nfc_err(&drv->pdev->dev, "wrong bts magic number\n");
rc = -EINVAL;
goto release_fw;
}
@@ -367,7 +366,7 @@ static long nfcwilink_receive(void *priv_data, struct
sk_buff *skb)
/* Forward skb to NCI core layer */
rc = nci_recv_frame(skb);
if (rc < 0) {
- nfc_dev_err(&drv->pdev->dev, "nci_recv_frame failed %d", rc);
+ nfc_err(&drv->pdev->dev, "nci_rec
[PATCH 3/3] nfc: Standardize logging style
Use standardized styles to minimize coding defects.
Always use nfc_ where feasible.
Add \n to formats where appropriate.
Tyop "it it" correction.
Add #define pr_fmt where appropriate.
Remove function tracing logging messages.
Remove OOM messages.
Signed-off-by: Joe Perches
---
drivers/nfc/microread/i2c.c | 32 +++-
drivers/nfc/microread/mei.c | 20 +---
drivers/nfc/microread/microread.c | 7 ---
drivers/nfc/nfcwilink.c | 2 +-
drivers/nfc/pn533.c | 7 +++
drivers/nfc/pn544/i2c.c | 38 +++---
drivers/nfc/pn544/pn544.c | 13 +++--
7 files changed, 46 insertions(+), 73 deletions(-)
diff --git a/drivers/nfc/microread/i2c.c b/drivers/nfc/microread/i2c.c
index 1010894..696e346 100644
--- a/drivers/nfc/microread/i2c.c
+++ b/drivers/nfc/microread/i2c.c
@@ -18,6 +18,8 @@
* 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -95,12 +97,8 @@ static int check_crc(struct sk_buff *skb)
crc = crc ^ skb->data[i];
if (crc != skb->data[skb->len-1]) {
- pr_err(MICROREAD_I2C_DRIVER_NAME
- ": CRC error 0x%x != 0x%x\n",
- crc, skb->data[skb->len-1]);
-
- pr_info(DRIVER_DESC ": %s : BAD CRC\n", __func__);
-
+ pr_err("CRC error 0x%x != 0x%x\n", crc, skb->data[skb->len-1]);
+ pr_info("%s: BAD CRC\n", __func__);
return -EPERM;
}
@@ -160,18 +158,15 @@ static int microread_i2c_read(struct microread_i2c_phy
*phy,
u8 tmp[MICROREAD_I2C_LLC_MAX_SIZE - 1];
struct i2c_client *client = phy->i2c_dev;
- pr_debug("%s\n", __func__);
-
r = i2c_master_recv(client, &len, 1);
if (r != 1) {
- dev_err(&client->dev, "cannot read len byte\n");
+ nfc_err(&client->dev, "cannot read len byte\n");
return -EREMOTEIO;
}
if ((len < MICROREAD_I2C_LLC_MIN_SIZE) ||
(len > MICROREAD_I2C_LLC_MAX_SIZE)) {
- dev_err(&client->dev, "invalid len byte\n");
- pr_err("invalid len byte\n");
+ nfc_err(&client->dev, "invalid len byte\n");
r = -EBADMSG;
goto flush;
}
@@ -228,7 +223,6 @@ static irqreturn_t microread_i2c_irq_thread_fn(int irq,
void *phy_id)
}
client = phy->i2c_dev;
- dev_dbg(&client->dev, "IRQ\n");
if (phy->hard_fault != 0)
return IRQ_HANDLED;
@@ -263,20 +257,18 @@ static int microread_i2c_probe(struct i2c_client *client,
dev_get_platdata(&client->dev);
int r;
- dev_dbg(&client->dev, "client %p", client);
+ dev_dbg(&client->dev, "client %p\n", client);
if (!pdata) {
- dev_err(&client->dev, "client %p: missing platform data",
+ nfc_err(&client->dev, "client %p: missing platform data\n",
client);
return -EINVAL;
}
phy = devm_kzalloc(&client->dev, sizeof(struct microread_i2c_phy),
GFP_KERNEL);
- if (!phy) {
- dev_err(&client->dev, "Can't allocate microread phy");
+ if (!phy)
return -ENOMEM;
- }
i2c_set_clientdata(client, phy);
phy->i2c_dev = client;
@@ -285,7 +277,7 @@ static int microread_i2c_probe(struct i2c_client *client,
IRQF_TRIGGER_RISING | IRQF_ONESHOT,
MICROREAD_I2C_DRIVER_NAME, phy);
if (r) {
- dev_err(&client->dev, "Unable to register IRQ handler");
+ nfc_err(&client->dev, "Unable to register IRQ handler\n");
return r;
}
@@ -296,7 +288,7 @@ static int microread_i2c_probe(struct i2c_client *client,
if (r < 0)
goto err_irq;
- dev_info(&client->dev, "Probed");
+ nfc_info(&client->dev, "Probed");
return 0;
@@ -310,8 +302,6 @@ static int microread_i2c_remove(struct i2c_client *client)
{
struct microread_i2c_phy *phy = i2c_get_clientdata(client);
- dev_dbg(&client->dev, "%s\n", __func__);
-
microread_remove(phy->hdev);
free_irq(client->irq, phy);
diff --git a/drivers/nfc/microread/mei.c b/drivers/nfc/microread/mei.c
index 13bde92..dbad24b 100644
--- a/drivers/nfc/microread/mei.c
+++ b/
Re: [PATCH v2] Introduce Intel RAPL cooling device driver
On Fri, 2013-04-05 at 14:02 -0700, Jacob Pan wrote:
> RAPL(Running Average Power Limit) interface provides platform software
> with the ability to monitor, control, and get notifications on SOC
> power consumptions. Since its first appearance on Sandy Bridge, more
> features have being added to extend its usage. In RAPL, platforms are
> divided into domains for fine grained control. These domains include
> package, DRAM controller, CPU core (Power Plane 0), graphics uncore
> (power plane 1), etc.
Some more trivia...
> diff --git a/drivers/platform/x86/intel_rapl.c
> b/drivers/platform/x86/intel_rapl.c
[]
> +/* in the order of enum rapl_primitives */
> +static struct rapl_primitive_info rpi[] = {
const?
> + /* name, mask, shift, msr index, unit divisor*/
> + PRIMITIVE_INFO_INIT(energy, ENERGY_STATUS_MASK, 0,
> + RAPL_DOMAIN_MSR_STATUS, ENERGY_UNIT,
> + RAPL_PRIMITIVE_EVENT_CAP),
> +static int rapl_set_cur_state(struct thermal_cooling_device *cdev,
> + unsigned long state)
I think most of this would look nicer if you
adopted the net style of aligning multi-line
statements to the appropriate open parenthesis.
> +static ssize_t store_event_control(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t size)
> +{
> + struct rapl_domain *rd = dev_get_drvdata(dev);
> + unsigned int efd, new_threshold;
> + struct file *efile = NULL;
> + int ret = 0;
> + int prim;
> + struct rapl_event *ep;
> + u64 val;
> + char cmd[MAX_PRIM_NAME];
> +
> + if (sscanf(buf, "%u %s %u", &efd, cmd, &new_threshold) != 3)
> + return -EINVAL;
This sscanf looks fragile.
buf = "1 some_really_long_name_longer_than_MAX_PRIM_NAME 2"
stack overrun.
Where does buf come from?
> +#define primitive_show_fn(n) \
> +
> +#define primitive_store_fn(n)
> \
Can't both of these be consolidated into a 2 functions using
offset_of and/or adding a string argument?
> +static struct attribute *all_attrs[] = {
const?
> + &dev_attr_energy.attr,
> +static void rapl_update_domain_data(void)
> +{
> + int i, j;
> + u64 val;
> + bool xlate;
> +
> + for (i = 0; i < rg_data.nr_domains; i++) {
> + /* exclude non-raw primitives */
> + for (j = 0; j < NR_RAW_PRIMITIVES; j++)
> + xlate = !!(rpi[j].unit);
You don't really need the !!. The compiler does that.
> +/* for global rapl data */
> +static struct class_attribute rapl_class_attrs[] = {
const?
> + GLOBAL_CLASS_RO_ATTR(energy_unit_divisor),
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
coccinelle and bitmask arithmetic (was: Re: [patch] TTY: synclink, small cleanup in dtr_rts())
On Tue, 2013-01-29 at 10:55 -0500, valdis.kletni...@vt.edu wrote: > On Sun, 27 Jan 2013 23:19:47 +0300, Dan Carpenter said: > > > Yeah. I think it would be, but adding bitflags together instead of > > doing bitwise ORs is very common as well. > > The fact it's common doesn't mean it's good programming practice, > or even correct. Consider: > > #define F_FOO 0x01 > #define F_BAR 0x02 > #define F_BAZ 0x04 > > unsigned int flags = F_FOO; > ... > flags |= F_BAR; > > Now some time later, another code path does this: > > flags += F_FOO; > > If it was another |, it would be a no harm no foul class of bug. > But how long is it going to take you to figure out who set F_BAZ? > > I wonder if there's a way to write a coccinelle patch to find places > where we do arithmetic operations on bitmasks Not so far as I know, but maybe someone on the cocci lists does. (cc'd) I could imagine a test for variables that have uses of both arithmetic and bit operations but not a discriminator for when one type is appropriate and the other is not. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: coccinelle and bitmask arithmetic (was: Re: [patch] TTY: synclink, small cleanup in dtr_rts())
On Tue, 2013-01-29 at 17:19 +0100, Julia Lawall wrote: > > On Tue, 2013-01-29 at 10:55 -0500, valdis.kletni...@vt.edu wrote: [] > > > I wonder if there's a way to write a coccinelle patch to find places > > > where we do arithmetic operations on bitmasks [] > If the definition of a bitmask is an identifier in all capital letters, > that would be easy. Another possibility is such an identifier that is > defined to a value expressed beginning with 0x. Another possibility is > such an identifier that is sometimes used with & and | and sometimes used > with an arithmetic operation. I will give them a try. Thanks Julia. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: coccinelle and bitmask arithmetic (was: Re: [patch] TTY: synclink, small cleanup in dtr_rts())
On Tue, 2013-01-29 at 18:49 +0100, Julia Lawall wrote:
> How about the following (from today's linux-next). They appear to be
> trying to do the same calculation, once with + and once with |.
(cc'ing the original developer and Russell King)
Likely the it8152_pci_platform_notify uses should use +
> arch/arm/common/it8152.c
>
> int dma_set_coherent_mask(struct device *dev, u64 mask)
> {
> if (mask >= PHYS_OFFSET + SZ_64M - 1)
> return 0;
>
> return -EIO;
> }
>
> static int it8152_pci_platform_notify(struct device *dev)
> {
> if (dev->bus == &pci_bus_type) {
> if (dev->dma_mask)
> *dev->dma_mask = (SZ_64M - 1) | PHYS_OFFSET;
> dev->coherent_dma_mask = (SZ_64M - 1) | PHYS_OFFSET;
> dmabounce_register_dev(dev, 2048, 4096, it8152_needs_bounce);
> }
> return 0;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 0/7] zswap: compressed swap caching
On Tue, 2013-01-29 at 15:40 -0600, Seth Jennings wrote:
> The code required for the flushing is in a separate patch now
> as requested.
What tree does this apply to?
Both -next and linus fail to compile.
There's a whitespace error applying 3/7 (line 543 in zswap.c)
and on 3.8-rc5 (allyesconfig x86-32):
CC mm/zswap.o
mm/zswap.c:407:15: error: variable ‘zswap_zs_ops’ has initializer but
incomplete type
mm/zswap.c:408:2: error: unknown field ‘alloc’ specified in initializer
mm/zswap.c:408:2: warning: excess elements in struct initializer [enabled by
default]
mm/zswap.c:408:2: warning: (near initialization for ‘zswap_zs_ops’) [enabled by
default]
mm/zswap.c:409:2: error: unknown field ‘free’ specified in initializer
mm/zswap.c:410:1: warning: excess elements in struct initializer [enabled by
default]
mm/zswap.c:410:1: warning: (near initialization for ‘zswap_zs_ops’) [enabled by
default]
mm/zswap.c: In function ‘zswap_frontswap_store’:
mm/zswap.c:723:4: error: too many arguments to function ‘zs_malloc’
In file included from mm/zswap.c:35:0:
include/linux/zsmalloc.h:34:15: note: declared here
mm/zswap.c:748:5: error: too many arguments to function ‘zs_malloc’
In file included from mm/zswap.c:35:0:
include/linux/zsmalloc.h:34:15: note: declared here
mm/zswap.c: In function ‘zswap_frontswap_init’:
mm/zswap.c:940:2: warning: passing argument 2 of ‘zs_create_pool’ makes integer
from pointer without a cast [enabled by default]
In file included from mm/zswap.c:35:0:
include/linux/zsmalloc.h:31:17: note: expected ‘gfp_t’ but argument is of type
‘struct zs_ops *’
make[1]: *** [mm/zswap.o] Error 1
make: *** [mm/zswap.o] Error 2
I also suggest this patch to use a more
current logging style via pr_fmt and
removing embedded "zswap: " prefixes from
logging output formats.
---
mm/zswap.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/mm/zswap.c b/mm/zswap.c
index b8e5673..1e21f46 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -1,5 +1,5 @@
/*
- * zswap-drv.c - zswap driver file
+ * zswap.c - zswap driver file
*
* zswap is a backend for frontswap that takes pages that are in the
* process of being swapped out and attempts to compress them and store
@@ -20,6 +20,8 @@
* GNU General Public License for more details.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -137,15 +139,14 @@ static int zswap_comp_op(enum comp_op op, const u8 *src,
unsigned int slen,
static int __init zswap_comp_init(void)
{
if (!crypto_has_comp(zswap_compressor, 0, 0)) {
- pr_info("zswap: %s compressor not available\n",
- zswap_compressor);
+ pr_info("%s compressor not available\n", zswap_compressor);
/* fall back to default compressor */
zswap_compressor = ZSWAP_COMPRESSOR_DEFAULT;
if (!crypto_has_comp(zswap_compressor, 0, 0))
/* can't even load the default compressor */
return -ENODEV;
}
- pr_info("zswap: using %s compressor\n", zswap_compressor);
+ pr_info("using %s compressor\n", zswap_compressor);
/* alloc percpu transforms */
zswap_comp_pcpu_tfms = alloc_percpu(struct crypto_comp *);
@@ -296,13 +297,13 @@ static int __zswap_cpu_notifier(unsigned long action,
unsigned long cpu)
case CPU_UP_PREPARE:
tfm = crypto_alloc_comp(zswap_compressor, 0, 0);
if (IS_ERR(tfm)) {
- pr_err("zswap: can't allocate compressor transform\n");
+ pr_err("can't allocate compressor transform\n");
return NOTIFY_BAD;
}
*per_cpu_ptr(zswap_comp_pcpu_tfms, cpu) = tfm;
dst = (u8 *)__get_free_pages(GFP_KERNEL, 1);
if (!dst) {
- pr_err("zswap: can't allocate compressor buffer\n");
+ pr_err("can't allocate compressor buffer\n");
crypto_free_comp(tfm);
*per_cpu_ptr(zswap_comp_pcpu_tfms, cpu) = NULL;
return NOTIFY_BAD;
@@ -949,7 +950,7 @@ static void zswap_frontswap_init(unsigned type)
freetree:
kfree(tree);
err:
- pr_err("zswap: alloc failed, zswap disabled for swap type %d\n", type);
+ pr_err("alloc failed, zswap disabled for swap type %d\n", type);
}
static struct frontswap_ops zswap_frontswap_ops = {
@@ -1031,28 +1032,28 @@ static int __init init_zswap(void)
pr_info("loading zswap\n");
if (zswap_entry_cache_create()) {
- pr_err("zswap: entry cache creation failed\n");
+ pr_err("entry cache creation failed\n");
goto error;
}
if (zswap_page_pool_create()) {
- pr_err("zswap: page pool initialization failed\n");
+ pr_err("page pool initialization failed\n");
Re: [Q]staging/comedi: Considation of *_find_boardinfo possible?
On Wed, 2013-01-30 at 00:41 +0100, Peter Hüwe wrote:
> ---> is there a way to consolidate these functions into one function (which
> can operate on the different types) ? It's almost a bit like 'templates'.
> Maybe with some gcc extensions or kernel magic functions ?
Nothing wrong with a macro.
Maybe something like:
#define comedi_find_board(array, board_id) \
({ \
int i; \
typeof array *p = array;\
typeof array *rtn = NULL; \
for (i = 0; i < ARRAY_SIZE(array); i++, p++) { \
if (p->device_id == board_id) { \
rtn = p;\
break; \
} \
} \
rtn;\
})
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: coccinelle and bitmask arithmetic
On Wed, 2013-01-30 at 09:21 +0100, walter harms wrote:
> Am 29.01.2013 19:03, schrieb Joe Perches:
> > On Tue, 2013-01-29 at 18:49 +0100, Julia Lawall wrote:
> >> How about the following (from today's linux-next). They appear to be
> >> trying to do the same calculation, once with + and once with |.
> >
> > (cc'ing the original developer and Russell King)
> >
> > Likely the it8152_pci_platform_notify uses should use +
> >
> >> arch/arm/common/it8152.c
> >>
> >> int dma_set_coherent_mask(struct device *dev, u64 mask)
> >> {
> >> if (mask >= PHYS_OFFSET + SZ_64M - 1)
> >> return 0;
> >>
> >> return -EIO;
> >> }
> >>
>
> Great hit Joe :)
Julia and the others in the coccinelle group are the ones
with the whizzy program.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: coccinelle and bitmask arithmetic
On Wed, 2013-01-30 at 11:35 +, Russell King - ARM Linux wrote: > On Wed, Jan 30, 2013 at 12:21:21PM +0100, Julia Lawall wrote: > > On Wed, 30 Jan 2013, Russell King - ARM Linux wrote: > > > So, _either_ logical OR or addition works. > > > > > > If we _did_ end up with a PHYS_OFFSET with bits less than bit 26 set > > > here, we'd have bigger problems - because the base of RAM in PCI space > > > will not correspond with PHYS_OFFSET and all the DMA mapping stuff breaks. > > > > The "problem" is that the computation is done inconsistently within the > > same file. Sometimes with + and sometimes with |. > > And I say that is not a problem; if it _does_ become a problem, there are > bigger problems that would also need solving, which given a multi-subarch > kernel become a lot lot harder. > > Sure, we can just change them to all be a bitwise OR (sorry, not logical) > but that's really only half the story. As far as I can tell, there'd be a lot of +'s to change in arch/arm and only 2 uses of | in it8152.c $ git grep -P "\(?\s*SZ_\d+[A-Z]\s*-\s*1\s*\)?\s*\|" arch/arm arch/arm/common/it8152.c: *dev->dma_mask = (SZ_64M - 1) | PHYS_OFFSET; arch/arm/common/it8152.c: dev->coherent_dma_mask = (SZ_64M - 1) | PHYS_OFFSET; $ git grep -P "\+\s*\(?\s*SZ_\d+[A-Z]\b\s*-\s*1\s*\)?" arch/arm | wc -l 460 I think consistently using + would make it simpler for some possible future conversion. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checkpatch: fix USLEEP_RANGE test
On Wed, 2013-01-30 at 11:15 -0800, Bruce Allan wrote:
> Do not test udelay() for a value less than 10usec when passed a variable
> instead of a hard-coded number;
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -3237,9 +3237,9 @@ sub process {
[]
> # prefer usleep_range over udelay
> - if ($line =~ /\budelay\s*\(\s*(\w+)\s*\)/) {
> + if ($line =~ /\budelay\s*\(\s*(\d+)\s*\)/) {
> # ignore udelay's < 10, however
> - if (! (($1 =~ /(\d+)/) && ($1 < 10)) ) {
> + if (! ($1 < 10) ) {
> CHK("USLEEP_RANGE",
> "usleep_range is preferred over udelay; see
> Documentation/timers/timers-howto.txt\n" . $line);
> }
Thanks Bruce.
Just a trivial comment:
Maybe this would be a little neater as
if ($line =~ \budelay\s*\(\s*(\d+)\s*\) &&
$1 >= 10) {
CHK(etc...)
}
No worries though.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] block: partition: optimize memory allocation in check_partition
On Fri, 2013-02-01 at 11:07 +0800, Ming Lei wrote:
> Currently, sizeof(struct parsed_partitions) may be 64KB in 32bit arch,
> so it is easy to trigger page allocation failure by check_partition,
[]
> This patch does below optimizations on the allocation of struct
> parsed_partitions to try to address the issue:
>
> - make parsed_partitions.parts as pointer so that the pointed memory
> can fit in 32KB buffer, then approximate 32KB memory can be saved
>
> - vmalloc the buffer pointed by parsed_partitions.parts because
> 32KB is still a bit big for kmalloc
[]
> diff --git a/block/partitions/check.h b/block/partitions/check.h
[]
> @@ -15,13 +15,15 @@ struct parsed_partitions {
> int flags;
> bool has_info;
> struct partition_meta_info info;
> - } parts[DISK_MAX_PARTS];
> + } *parts;
This is relatively unusual style.
Could you break out this struct instead?
struct partition_parts {
...
};
and use
struct partition_parts *parts;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] SubmittingPatches: add penalty for forcing a maintainer to edit a patch
On Fri, 2013-02-01 at 16:43 +0100, Greg Kroah-Hartman wrote: > From: Greg Kroah-Hartman > > Maintainers have to hand-edit patches (body of patches and changelog > entries) all the time. There needs to be some kind of penalty put into > place to keep developers from abusing maintainers. No, there doesn't. It's funny as a joke, it's not as an actual patch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tile: revert pr_info to printk in
On Fri, 2013-02-01 at 12:34 -0500, Chris Metcalf wrote:
> Using pr_info in a header exposes us to potential trouble from
> subsystems that define pr_fmt. This change fixes:
>
> In file included from include/linux/scatterlist.h:10,
>from include/scsi/scsi.h:12,
>from drivers/infiniband/ulp/srp/ib_srp.c:46:
> arch/tile/include/asm/io.h: In function ‘ioport_map’:
> arch/tile/include/asm/io.h:296: error: expected ‘)’ before ‘PFX’
Interesting.
> diff --git a/arch/tile/include/asm/io.h b/arch/tile/include/asm/io.h
[]
> @@ -292,7 +292,7 @@ static inline long ioport_panic(void)
>
> static inline void __iomem *ioport_map(unsigned long port, unsigned int len)
> {
> - pr_info("ioport_map: mapping IO resources is unsupported on tile.\n");
> + printk("ioport_map: mapping IO resources is unsupported on tile.\n");
It'd be nicer to add an appropriate KERN_ here.
My preference would be to change ib_srp.c (and ib_srpt) like:
---
drivers/infiniband/ulp/srp/ib_srp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b/drivers/infiniband/ulp/srp/ib_srp.c
index d5088ce..59bf409 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -30,7 +30,7 @@
* SOFTWARE.
*/
-#define pr_fmt(fmt) PFX fmt
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include
#include
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH next-20130124] Sound: pci: Fix unused variable warning in patch_sigmatel.c
On Fri, 2013-01-25 at 10:09 +0100, Takashi Iwai wrote:
> At Fri, 25 Jan 2013 00:38:06 +0200,
> Stratos Karafotis wrote:
> > Fix the following build warnings
> > sound/pci/hda/patch_sigmatel.c: In function ‘stac92hd71bxx_fixup_hp’:
> > sound/pci/hda/patch_sigmatel.c:2434:24: warning: unused variable ‘spec’
> > [-Wunused-variable]
[]
> I'm going to fix the definition of snd_printd() itself for fixing this
> kind of warnings. We can use inline functions instead of empty macros
> to achieve the same but without triggering compiler warnings.
It's probably better to use a macro like:
do {\
if (0) \
printk(fmt, ##__VA_ARGS__); \
} while (0)
to allow the compiler to avoid any argument evaluation
while still doing fmt/arg matching.
Something like:
include/sound/core.h | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/include/sound/core.h b/include/sound/core.h
index 93896ad..ce5d224 100644
--- a/include/sound/core.h
+++ b/include/sound/core.h
@@ -394,8 +394,17 @@ void __snd_printk(unsigned int level, const char *file,
int line,
#else /* !CONFIG_SND_DEBUG */
-#define snd_printd(fmt, args...) do { } while (0)
-#define _snd_printd(level, fmt, args...) do { } while (0)
+#define snd_printd(fmt, ...) \
+do { \
+ if (0) \
+ __snd_printk(1, __FILE__, __LINE__, fmt, ##__VA_ARGS__); \
+} while (0)
+#define _snd_printd(level, fmt, ...) \
+do { \
+ if (0) \
+ __snd_printk(level, __FILE__, __LINE__, fmt, ##__VA_ARGS__); \
+} while (0)
+
#define snd_BUG() do { } while (0)
static inline int __snd_bug_on(int cond)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] checkpatch: Fix $Float creation of match variables
commit 74349bccedb
("checkpatch: add support for floating point constants")
added an unnecessary match variable that caused
tests that used a $Constant or $LvalOrFunc to have
one too many matches.
This causes problems with usleep_range, min/max and
other extended tests.
Avoid using match variables in $Float.
Avoid using match variables in $Assignment too.
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 9de3a69..3d0f577 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -230,12 +230,12 @@ our $Inline = qr{inline|__always_inline|noinline};
our $Member= qr{->$Ident|\.$Ident|\[[^]]*\]};
our $Lval = qr{$Ident(?:$Member)*};
-our $Float_hex = qr{(?i:0x[0-9a-f]+p-?[0-9]+[fl]?)};
-our $Float_dec =
qr{(?i:((?:[0-9]+\.[0-9]*|[0-9]*\.[0-9]+)(?:e-?[0-9]+)?[fl]?))};
-our $Float_int = qr{(?i:[0-9]+e-?[0-9]+[fl]?)};
+our $Float_hex = qr{(?i)0x[0-9a-f]+p-?[0-9]+[fl]?};
+our $Float_dec = qr{(?i)(?:[0-9]+\.[0-9]*|[0-9]*\.[0-9]+)(?:e-?[0-9]+)?[fl]?};
+our $Float_int = qr{(?i)[0-9]+e-?[0-9]+[fl]?};
our $Float = qr{$Float_hex|$Float_dec|$Float_int};
-our $Constant = qr{(?:$Float|(?i:(?:0x[0-9a-f]+|[0-9]+)[ul]*))};
-our $Assignment= qr{(?:\*\=|/=|%=|\+=|-=|<<=|>>=|&=|\^=|\|=|=)};
+our $Constant = qr{$Float|(?i)(?:0x[0-9a-f]+|[0-9]+)[ul]*};
+our $Assignment= qr{\*\=|/=|%=|\+=|-=|<<=|>>=|&=|\^=|\|=|=};
our $Compare= qr{<=|>=|==|!=|<|>};
our $Operators = qr{
<=|>=|==|!=|
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]cputime: make bool type for steal ticks
On Sat, 2013-01-26 at 01:45 +0100, Frederic Weisbecker wrote: > > diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c [] > > @@ -282,7 +282,7 @@ static __always_inline bool > > steal_account_process_tick(void) [] > > - return st; > > + return !!st; > > I would expect gcc to perform the semantic "!!" cast implicitly. I > just did some basic tests locally and it does. > I prefer to be paranoid and not do any assumption though, unless I'm > told gcc always guarantees this correct implicit cast. I'm queuing > this patch and will send it to Ingo. It's unnecessary. 6.3.1.2p1: "When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] edac: Fix kcalloc argument order
First number, then size.
Signed-off-by: Joe Perches
---
drivers/edac/edac_mc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c
index a641f62..fb219bc 100644
--- a/drivers/edac/edac_mc.c
+++ b/drivers/edac/edac_mc.c
@@ -340,7 +340,7 @@ struct mem_ctl_info *edac_mc_alloc(unsigned mc_num,
/*
* Alocate and fill the csrow/channels structs
*/
- mci->csrows = kcalloc(sizeof(*mci->csrows), tot_csrows, GFP_KERNEL);
+ mci->csrows = kcalloc(tot_csrows, sizeof(*mci->csrows), GFP_KERNEL);
if (!mci->csrows)
goto error;
for (row = 0; row < tot_csrows; row++) {
@@ -351,7 +351,7 @@ struct mem_ctl_info *edac_mc_alloc(unsigned mc_num,
csr->csrow_idx = row;
csr->mci = mci;
csr->nr_channels = tot_channels;
- csr->channels = kcalloc(sizeof(*csr->channels), tot_channels,
+ csr->channels = kcalloc(tot_channels, sizeof(*csr->channels),
GFP_KERNEL);
if (!csr->channels)
goto error;
@@ -369,7 +369,7 @@ struct mem_ctl_info *edac_mc_alloc(unsigned mc_num,
/*
* Allocate and fill the dimm structs
*/
- mci->dimms = kcalloc(sizeof(*mci->dimms), tot_dimms, GFP_KERNEL);
+ mci->dimms = kcalloc(tot_dimms, sizeof(*mci->dimms), GFP_KERNEL);
if (!mci->dimms)
goto error;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gro: Fix kcalloc argument order
First number, then size. Signed-off-by: Joe Perches --- include/net/gro_cells.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/net/gro_cells.h b/include/net/gro_cells.h index e5062c9..734d9b5 100644 --- a/include/net/gro_cells.h +++ b/include/net/gro_cells.h @@ -73,8 +73,8 @@ static inline int gro_cells_init(struct gro_cells *gcells, struct net_device *de int i; gcells->gro_cells_mask = roundup_pow_of_two(netif_get_num_default_rss_queues()) - 1; - gcells->cells = kcalloc(sizeof(struct gro_cell), - gcells->gro_cells_mask + 1, + gcells->cells = kcalloc(gcells->gro_cells_mask + 1, + sizeof(struct gro_cell), GFP_KERNEL); if (!gcells->cells) return -ENOMEM; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] checkpatch: Add check for kcalloc argument order
kcalloc is sometimes misused with the
first and second arguments switched.
Same issue with kmalloc_array too.
Bleat if sizeof is the first argument
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 6 ++
1 file changed, 6 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 9cec6dd..b7326af 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3476,6 +3476,12 @@ sub process {
"unnecessary cast may hide bugs, see
http://c-faq.com/malloc/mallocnocast.html\n"; . $herecurr);
}
+# check for alloc argument mismatch
+ if ($line =~ /\b(kcalloc|kmalloc_array)\s*\(\s*sizeof\b/) {
+ WARN("ALLOC_ARRAY_ARGS",
+"$1 uses number as first arg, sizeof is generally
wrong\n" . $herecurr);
+ }
+
# check for multiple semicolons
if ($line =~ /;\s*;\s*$/) {
WARN("ONE_SEMICOLON",
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checkpatch.pl: Fix warnings on (networking specific) code comments
On Sun, 2013-01-27 at 03:35 -0800, Jeff Kirsher wrote:
> This patch reverts a portion of the commit to allow multi-line code
> comments to use either style.
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -1878,13 +1878,6 @@ sub process {
> }
>
> if ($realfile =~ m@^(drivers/net/|net/)@ &&
> - $rawline =~ /^\+[ \t]*\/\*[ \t]*$/ &&
> - $prevrawline =~ /^\+[ \t]*$/) {
> - WARN("NETWORKING_BLOCK_COMMENT_STYLE",
> - "networking block comments don't use an empty /*
> line, use /* Comment...\n" . $hereprev);
> - }
> -
> - if ($realfile =~ m@^(drivers/net/|net/)@ &&
> $rawline !~ m@^\+[ \t]*\*/[ \t]*$@ && #trailing */
> $rawline !~ m@^\+.*/\*.*\*/[ \t]*$@ && #inline /*...*/
> $rawline !~ m@^\+.*\*{2,}/[ \t]*$@ && #trailing **/
Shrug.
Ignore things you don't agree with.
David has written many, many emails
requesting changes for this specific
comment style.
I think you and Intel should use
--ignore=NETWORKING_BLOCK_COMMENT_STYLE
to avoid seeing this if you don't agree
with it.
I also think expectations that everyone
will agree with every checkpatch bleat
are unrealistic.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] TTY: synclink, small cleanup in dtr_rts()
On Sun, 2013-01-27 at 22:40 +0300, Dan Carpenter wrote:
> There is a kind of precedence problem here, but it doesn't affect how
> the code works because ->serial_signals is unsigned char. We want to
> clear two flags here.
>
> #define SerialSignal_RTS0x20 /* Request to Send */
> #define SerialSignal_DTR0x80 /* Data Terminal Ready */
>
> Without the parenthesis then it does:
>
> info->serial_signals &= 0x5f;
>
> With the parenthesis it does:
>
> info->serial_signals &= 0xff5f;
>
> info->serial_signals is an unsigned char so the two statements are
> equivalent, but it's cleaner to add the parenthesis. In other dtr_rts()
> functions the parenthesis are there so this makes it more consistent.
Wouldn't it be clearer still to use | instead of +
> diff --git a/drivers/char/pcmcia/synclink_cs.c
> b/drivers/char/pcmcia/synclink_cs.c
[]
> @@ -2466,7 +2466,7 @@ static void dtr_rts(struct tty_port *port, int onoff)
> if (onoff)
> info->serial_signals |= SerialSignal_RTS + SerialSignal_DTR;
> else
> - info->serial_signals &= ~SerialSignal_RTS + SerialSignal_DTR;
> + info->serial_signals &= ~(SerialSignal_RTS + SerialSignal_DTR);
drivers/tty/synclink.c| 16
drivers/tty/synclink_gt.c | 18 +-
drivers/tty/synclinkmp.c | 18 +-
3 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/tty/synclink.c b/drivers/tty/synclink.c
index 555fdc0..636ef3e 100644
--- a/drivers/tty/synclink.c
+++ b/drivers/tty/synclink.c
@@ -1850,7 +1850,7 @@ static void shutdown(struct mgsl_struct * info)
usc_OutReg(info, PCR, (u16)((usc_InReg(info, PCR) | BIT13) | BIT12));
if (!info->port.tty || info->port.tty->termios.c_cflag & HUPCL) {
- info->serial_signals &= ~(SerialSignal_DTR + SerialSignal_RTS);
+ info->serial_signals &= ~(SerialSignal_DTR | SerialSignal_RTS);
usc_set_serial_signals(info);
}
@@ -1918,9 +1918,9 @@ static void mgsl_change_params(struct mgsl_struct *info)
/* if B0 rate (hangup) specified then negate DTR and RTS */
/* otherwise assert DTR and RTS */
if (cflag & CBAUD)
- info->serial_signals |= SerialSignal_RTS + SerialSignal_DTR;
+ info->serial_signals |= SerialSignal_RTS | SerialSignal_DTR;
else
- info->serial_signals &= ~(SerialSignal_RTS + SerialSignal_DTR);
+ info->serial_signals &= ~(SerialSignal_RTS | SerialSignal_DTR);
/* byte size and parity */
@@ -3044,7 +3044,7 @@ static void mgsl_set_termios(struct tty_struct *tty,
struct ktermios *old_termio
/* Handle transition to B0 status */
if (old_termios->c_cflag & CBAUD &&
!(tty->termios.c_cflag & CBAUD)) {
- info->serial_signals &= ~(SerialSignal_RTS + SerialSignal_DTR);
+ info->serial_signals &= ~(SerialSignal_RTS | SerialSignal_DTR);
spin_lock_irqsave(&info->irq_spinlock,flags);
usc_set_serial_signals(info);
spin_unlock_irqrestore(&info->irq_spinlock,flags);
@@ -3243,9 +3243,9 @@ static void dtr_rts(struct tty_port *port, int on)
spin_lock_irqsave(&info->irq_spinlock,flags);
if (on)
- info->serial_signals |= SerialSignal_RTS + SerialSignal_DTR;
+ info->serial_signals |= SerialSignal_RTS | SerialSignal_DTR;
else
- info->serial_signals &= ~(SerialSignal_RTS + SerialSignal_DTR);
+ info->serial_signals &= ~(SerialSignal_RTS | SerialSignal_DTR);
usc_set_serial_signals(info);
spin_unlock_irqrestore(&info->irq_spinlock,flags);
}
@@ -6240,7 +6240,7 @@ static void usc_get_serial_signals( struct mgsl_struct
*info )
u16 status;
/* clear all serial signals except DTR and RTS */
- info->serial_signals &= SerialSignal_DTR + SerialSignal_RTS;
+ info->serial_signals &= SerialSignal_DTR | SerialSignal_RTS;
/* Read the Misc Interrupt status Register (MISR) to get */
/* the V24 status signals. */
@@ -7780,7 +7780,7 @@ static int hdlcdev_open(struct net_device *dev)
}
/* assert DTR and RTS, apply hardware settings */
- info->serial_signals |= SerialSignal_RTS + SerialSignal_DTR;
+ info->serial_signals |= SerialSignal_RTS | SerialSignal_DTR;
mgsl_program_hw(info);
/* enable network layer transmit */
diff --git a/drivers/tty/synclink_gt.c b/drivers/tty/synclink_gt.c
index ac8599a..a66539c 100644
--- a/drivers/tty/synclink_gt.c
+++ b/drivers/tty/synclink_gt.c
@@ -785,7 +785,7 @@ static void set_termios(struct tty_struct *tty, struct
ktermios *old_termios)
/* Handle transition to B0 status */
if (old_termios->c_cflag & CBAUD &&
!(tty->termios.c_cflag & CBAUD)) {
- info->signals &= ~(SerialSignal_RTS
Re: [patch] TTY: synclink, small cleanup in dtr_rts()
On Sun, 2013-01-27 at 23:19 +0300, Dan Carpenter wrote: > On Sun, Jan 27, 2013 at 12:04:38PM -0800, Joe Perches wrote: > > Wouldn't it be clearer still to use | instead of + > Yeah. I think it would be, but adding bitflags together instead of > doing bitwise ORs is very common as well. Fortunately, less and less so. Another option might be to add another #define to include/uapi/linux/synclink.h #define SerialSignal_DTR_RTS(SerialSignal_DTR | SerialSignal_RTS) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] TTY: synclink: Convert + to | for bit operations
Dan Carpenter noticed a missing set of parentheses
around a multiple field addition.
https://lkml.org/lkml/2013/1/27/166
His original commit message:
There is a kind of precedence problem here, but it doesn't affect how
the code works because ->serial_signals is unsigned char. We want to
clear two flags here.
#define SerialSignal_RTS0x20 /* Request to Send */
#define SerialSignal_DTR0x80 /* Data Terminal Ready */
Without the parenthesis then it does:
info->serial_signals &= 0x5f;
With the parenthesis it does:
info->serial_signals &= 0xff5f;
info->serial_signals is an unsigned char so the two statements are
equivalent, but it's cleaner to add the parenthesis. In other dtr_rts()
functions the parenthesis are there so this makes it more consistent.
Other changes:
Convert all + uses to | for these bit operations.
Reorder the multiple fields for consistency.
Update the comments too.
cc: Dan Carpenter
Signed-off-by: Joe Perches
---
drivers/char/pcmcia/synclink_cs.c | 26 -
drivers/tty/synclink.c| 26 -
drivers/tty/synclink_gt.c | 26 -
drivers/tty/synclinkmp.c | 40 +++
4 files changed, 59 insertions(+), 59 deletions(-)
diff --git a/drivers/char/pcmcia/synclink_cs.c
b/drivers/char/pcmcia/synclink_cs.c
index 34e52ed..d0c9852 100644
--- a/drivers/char/pcmcia/synclink_cs.c
+++ b/drivers/char/pcmcia/synclink_cs.c
@@ -1343,7 +1343,7 @@ static void shutdown(MGSLPC_INFO * info, struct
tty_struct *tty)
reset_device(info);
if (!tty || tty->termios.c_cflag & HUPCL) {
- info->serial_signals &= ~(SerialSignal_DTR + SerialSignal_RTS);
+ info->serial_signals &= ~(SerialSignal_RTS | SerialSignal_DTR);
set_signals(info);
}
@@ -1405,12 +1405,12 @@ static void mgslpc_change_params(MGSLPC_INFO *info,
struct tty_struct *tty)
cflag = tty->termios.c_cflag;
- /* if B0 rate (hangup) specified then negate DTR and RTS */
- /* otherwise assert DTR and RTS */
+ /* if B0 rate (hangup) specified then negate RTS and DTR */
+ /* otherwise assert RTS and DTR */
if (cflag & CBAUD)
- info->serial_signals |= SerialSignal_RTS + SerialSignal_DTR;
+ info->serial_signals |= SerialSignal_RTS | SerialSignal_DTR;
else
- info->serial_signals &= ~(SerialSignal_RTS + SerialSignal_DTR);
+ info->serial_signals &= ~(SerialSignal_RTS | SerialSignal_DTR);
/* byte size and parity */
@@ -2301,7 +2301,7 @@ static void mgslpc_set_termios(struct tty_struct *tty,
struct ktermios *old_term
/* Handle transition to B0 status */
if (old_termios->c_cflag & CBAUD &&
!(tty->termios.c_cflag & CBAUD)) {
- info->serial_signals &= ~(SerialSignal_RTS + SerialSignal_DTR);
+ info->serial_signals &= ~(SerialSignal_RTS | SerialSignal_DTR);
spin_lock_irqsave(&info->lock,flags);
set_signals(info);
spin_unlock_irqrestore(&info->lock,flags);
@@ -2464,9 +2464,9 @@ static void dtr_rts(struct tty_port *port, int onoff)
spin_lock_irqsave(&info->lock,flags);
if (onoff)
- info->serial_signals |= SerialSignal_RTS + SerialSignal_DTR;
+ info->serial_signals |= SerialSignal_RTS | SerialSignal_DTR;
else
- info->serial_signals &= ~SerialSignal_RTS + SerialSignal_DTR;
+ info->serial_signals &= ~(SerialSignal_RTS | SerialSignal_DTR);
set_signals(info);
spin_unlock_irqrestore(&info->lock,flags);
}
@@ -3575,8 +3575,8 @@ static void get_signals(MGSLPC_INFO *info)
{
unsigned char status = 0;
- /* preserve DTR and RTS */
- info->serial_signals &= SerialSignal_DTR + SerialSignal_RTS;
+ /* preserve RTS and DTR */
+ info->serial_signals &= SerialSignal_RTS | SerialSignal_DTR;
if (read_reg(info, CHB + VSTR) & BIT7)
info->serial_signals |= SerialSignal_DCD;
@@ -3590,7 +3590,7 @@ static void get_signals(MGSLPC_INFO *info)
info->serial_signals |= SerialSignal_DSR;
}
-/* Set the state of DTR and RTS based on contents of
+/* Set the state of RTS and DTR based on contents of
* serial_signals member of device extension.
*/
static void set_signals(MGSLPC_INFO *info)
@@ -4009,8 +4009,8 @@ static int hdlcdev_open(struct net_device *dev)
spin_unlock_irqrestore(&info->netlock, flags);
return rc;
}
- /* assert DTR and RTS, apply hardware settings */
- info->serial_signals |= Ser
Re: [PATCH] checkpatch.pl: Fix warnings on code comments
On Mon, 2013-01-28 at 17:17 +, Allan, Bruce W wrote: > David Miller Sent: Sunday, January 27, 2013 7:07 PM > > From: Jeff Kirsher > > > So will you be fine with cleanup patches which go through and > > > convert all the existing code comments to the desired format? > > Sure. > Not all Intel drivers...e1000e already conforms to the comment style :-) In case anyone cares, here's a perl regex to do network comment style conversion. $text =~ s@/\*[ \t]*\n[ \t]*\*@/*@g; $text =~ s@/\*([ \t]*)([^\n]+)\n[ \t]*\*/@/\*$1$2 \*/@g; (assumes the entire file is in $text) It creates a ~220KB diff for drivers/net/ethernet/intel/ that I won't post. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] block: IBM RamSan 70/80 branding changes.
On Mon, 2013-02-25 at 12:58 -0600, Philip J. Kelleher wrote: > From: Philip J Kelleher > > This patch includes changing the hardware branding name from > IBM RamSan to IBM FlashSystem. just a trivial comment > diff -uprN -X linux-block-vanilla/Documentation/dontdiff > linux-block-vanilla/drivers/block/rsxx/rsxx_priv.h > linux-block/drivers/block/rsxx/rsxx_priv.h [] > @@ -45,16 +45,14 @@ > > struct proc_cmd; > > -#define PCI_VENDOR_ID_TMS_IBM0x15B6 > -#define PCI_DEVICE_ID_RS70_FLASH 0x0019 > -#define PCI_DEVICE_ID_RS70D_FLASH0x001A > -#define PCI_DEVICE_ID_RS80_FLASH 0x001C > -#define PCI_DEVICE_ID_RS81_FLASH 0x001E > +#define PCI_VENDOR_ID_IBM0x1014 PCI_VENDOR_ID_IBM is already #defined in pci_ids.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] kexec: Use min_t to simplify logic
On Tue, 2013-02-26 at 13:30 +0800, Zhang Yanfei wrote:
> This is just a tweak: using min_t to simplify logic of variable
> assignments.
>
> v3:
> - cast type of (PAGE_SIZE - (maddr & ~PAGE_MASK)) into size_t.
Why? Isn't this just a redundant cast?
> diff --git a/kernel/kexec.c b/kernel/kexec.c
[]
> @@ -822,13 +822,9 @@ static int kimage_load_normal_segment(struct kimage
> *image,
[]
> + mchunk = min_t(size_t, mbytes,
> +(size_t)(PAGE_SIZE - (maddr & ~PAGE_MASK)));
#define min_t(type, x, y) ({\
type __min1 = (x); \
type __min2 = (y); \
__min1 < __min2 ? __min1: __min2; })
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 03/12] hwmon: (nct6775) Add support for temperature sensors
On Tue, 2013-02-26 at 10:23 -0800, Guenter Roeck wrote:
> diff --git a/drivers/hwmon/nct6775.c b/drivers/hwmon/nct6775.c
[]
> +static const u16 NCT6779_REG_TEMP_CONFIG[11] = { 0x18, 0x152 };
Isn't 11 too magic a number?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 0/4] Add support for LZ4-compressed kernel
On Tue, 2013-02-26 at 22:10 +, Russell King - ARM Linux wrote: > So... for a selected kernel version of a particular size, can we please > have a comparison between the new LZO code and this LZ4 code, so that > we can see whether it's worth updating the LZO code or replacing the > LZO code with LZ4? How could it be questionable that it's worth updating the LZO code? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 0/4] Add support for LZ4-compressed kernel
On Wed, 2013-02-27 at 09:56 +, Russell King - ARM Linux wrote: > On Tue, Feb 26, 2013 at 05:40:34PM -0800, Joe Perches wrote: > > On Tue, 2013-02-26 at 22:10 +, Russell King - ARM Linux wrote: > > > So... for a selected kernel version of a particular size, can we please > > > have a comparison between the new LZO code and this LZ4 code, so that > > > we can see whether it's worth updating the LZO code or replacing the > > > LZO code with LZ4? > > > > How could it be questionable that it's worth updating the LZO code? > > Please read the comments against the previous posting of these patches > where I first stated this argument - and with agreement from those > following the thread. The thread started on 26 Jan 2013. Thanks. https://lkml.org/lkml/2013/1/29/145 I did not and do not see significant value in adding LZ4 given Markus' LZO improvements. I asked about LZO. Why would the LZO code not be updated? The new LZO code is faster than ever and it's a standalone improvement. Markus has posted what seems a clean git pull request. It was not cc'd to arm or linux-arch. http://linux-kernel.2935.n7.nabble.com/GIT-PULL-Update-LZO-compression-code-for-v3-9-td605184.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 0/4] Add support for LZ4-compressed kernel
On Wed, 2013-02-27 at 16:31 +, Russell King - ARM Linux wrote: > On Wed, Feb 27, 2013 at 07:49:12AM -0800, Joe Perches wrote: > > On Wed, 2013-02-27 at 09:56 +, Russell King - ARM Linux wrote: > > > On Tue, Feb 26, 2013 at 05:40:34PM -0800, Joe Perches wrote: > > > > On Tue, 2013-02-26 at 22:10 +, Russell King - ARM Linux wrote: > > > > > So... for a selected kernel version of a particular size, can we > > > > > please > > > > > have a comparison between the new LZO code and this LZ4 code, so that > > > > > we can see whether it's worth updating the LZO code or replacing the > > > > > LZO code with LZ4? > > > > > > > > How could it be questionable that it's worth updating the LZO code? > > > > > > Please read the comments against the previous posting of these patches > > > where I first stated this argument - and with agreement from those > > > following the thread. The thread started on 26 Jan 2013. Thanks. > > > > https://lkml.org/lkml/2013/1/29/145 > > > > I did not and do not see significant value in > > adding LZ4 given Markus' LZO improvements. > > Sorry, a 66% increase in decompression speed over the updated LZO code > isn't "significant value" ? We disagree. > I'm curious - what in your mind qualifies "significant value" ? faster boot time. smaller, faster overall code. > Maybe "significant value" is a patch which buggily involves converting > all those "" printk format strings in assembly files to KERN_* macros, > thereby breaking those strings because you've not paid attention to what > .asciz means? (Yes, I've just cleaned that crap up after you...) If you mean commit 0cc41e4a21d43, perhaps you could clarify with an example. I don't see any relevant changes by you in -next, but maybe I'm not looking in the right spot. The change did enable reducing code size. > > Why would the LZO code not be updated? > I'm not saying that the LZO code should not be updated. You said: > > > > > so that we can see whether it's worth updating the LZO code Sounded as if you were doubtful to me. > I'm saying that > the kernel boot time decompressor is not a play ground for an ever > increasing number of "my favourite compression method" crap. Completely agree. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 0/4] Add support for LZ4-compressed kernel
On Wed, 2013-02-27 at 12:16 -0500, Nicolas Pitre wrote: > On Wed, 27 Feb 2013, Joe Perches wrote: > > On Wed, 2013-02-27 at 16:31 +, Russell King - ARM Linux wrote: > > > On Wed, Feb 27, 2013 at 07:49:12AM -0800, Joe Perches wrote: > > > > On Wed, 2013-02-27 at 09:56 +, Russell King - ARM Linux wrote: > > > > > On Tue, Feb 26, 2013 at 05:40:34PM -0800, Joe Perches wrote: > > > > > > On Tue, 2013-02-26 at 22:10 +, Russell King - ARM Linux wrote: > > > > > > > So... for a selected kernel version of a particular size, can we > > > > > > > please > > > > > > > have a comparison between the new LZO code and this LZ4 code, so > > > > > > > that > > > > > > > we can see whether it's worth updating the LZO code or replacing > > > > > > > the > > > > > > > LZO code with LZ4? > > > > > > > > > > > > How could it be questionable that it's worth updating the LZO code? > > > > > > > > > > Please read the comments against the previous posting of these patches > > > > > where I first stated this argument - and with agreement from those > > > > > following the thread. The thread started on 26 Jan 2013. Thanks. > > > > > > > > https://lkml.org/lkml/2013/1/29/145 > > > > > > > > I did not and do not see significant value in > > > > adding LZ4 given Markus' LZO improvements. > > > > > > Sorry, a 66% increase in decompression speed over the updated LZO code > > > isn't "significant value" ? > > > > We disagree. > > > > > I'm curious - what in your mind qualifies "significant value" ? > > > > faster boot time. smaller, faster overall code. > > Sorry, but you certainly successfully got me confused, and probably > others as well. > > RMK says that "66% increase in decompression speed over LZO" is > significant. You apparently disagree with that. Yeah, I can see how that can be interpreted. I'm referring only to the new LZO. I guess Russell has not reviewed the new LZO. There is apparently no speed increase for LZ4 over the new LZO. I believe Markus has shown comparison testing in this very thread. https://patchwork.kernel.org/patch/2187441/ > Then you say that faster boot time is significant. Increasing speed in incumbent code without adding defects is always useful no?. Replacing incumbent code with new code should be debated for utility. I still think there's not much value in adding LZ4. LZ4 is not not faster than LZO, it's just more code. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 0/4] Add support for LZ4-compressed kernel
(removed Richard Purdie and Albin Tonnerre as their email addresses seem to be bounding) > While recently asking someone to enable VFP debugging, so I could help > sort out a problem they had reported, this is the debug output I was > greeted by thanks to your meddling: :) Meddling... You sound like one of those nameless villains on Scooby Doo. If only I had a cool nickname like Dave "Shaggy" Kliekamp. I guess you'd have to call me Velma. > [ 927.235546] \x01\x01\x01\x01\x01\x01\x01\x01 > ... > [ 927.241505] \x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01 > > > 7.6 `.asciz "STRING"'... > > > `.asciz' is just like `.ascii', but each string is followed by a zero > ^ > byte. The "z" in `.asciz' stands for "zero". > ^ Yeah, sorry. I thought that the zero was after any concatenation like .c. Learned something. 'preciate that. Would have appreciated a polite "you broke it" email too. > ??? Yea, right, meanwhile breaking the ability of stuff to produce > kernel messages. Fortunately, that's the only .S instance. > > > > > > > so that we can see whether it's worth updating the LZO code > > Sounded as if you were doubtful to me. > _In_ the decompressor. We're talking about the _decompressor_ in > this thread. My opinion is it's useful to update LZO. cheers, Joe (aka: Velma) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
