Re: [PATCH 1/2] mtd: delete unneeded call to platform_get_drvdata
On Sat, May 17, 2014 at 3:32 AM, Julia Lawall wrote:
> From: Julia Lawall
>
> Platform_get_drvdata is an accessor function, and has no purpose if its
> result is not used.
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
> identifier x;
> type T;
> @@
> - T x = platform_get_drvdata(...);
> ... when != x
> //
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/mtd/nand/bf5xx_nand.c |4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/mtd/nand/bf5xx_nand.c b/drivers/mtd/nand/bf5xx_nand.c
> index b7a2494..b5fbd48 100644
> --- a/drivers/mtd/nand/bf5xx_nand.c
> +++ b/drivers/mtd/nand/bf5xx_nand.c
> @@ -840,15 +840,11 @@ out_err_kzalloc:
>
> static int bf5xx_nand_suspend(struct platform_device *dev, pm_message_t pm)
> {
> - struct bf5xx_nand_info *info = platform_get_drvdata(dev);
> -
> return 0;
> }
>
> static int bf5xx_nand_resume(struct platform_device *dev)
> {
> - struct bf5xx_nand_info *info = platform_get_drvdata(dev);
> -
> return 0;
In this case bf5xx_nand_suspend/resume 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: [RFC PATCH 0/2] kpatch: dynamic kernel patching
On Fri, 16 May 2014, Steven Rostedt wrote: > Why I still favor the stop_machine approach, is because the method of > patching is a bit simpler that way. A "lazy" approach will be more > complex and more likely to be buggy. The thing I'm arguing here is not > the end result being a problem, but the implementation of the patching > itself causing bugs. Well, what can I say to this. 21 files changed, 594 insertions(+), 10 deletions(-) that's a complete implementation, including comments and some documentation. Yes, it still has TODOs (such as patching modules as they are modprobed, we're working on multi-arch support, etc), but it's more or less complete working x86 skeleton. > I rather have a "lazy" approach, I'm glad to hear that, thanks :) > but like ftrace and its breakpoint method, the stop_machine approach is > the simpler way to make sure the patching works before we try to > optimize it. I am still not convinced that it's more complex. It's actually lazy both in the way it performs patching and in implementation -- we basically set a flag, flip the switch, and let the universe converge to a new state by itself. It's basically hard to argue about level of bugginess when no actual bugs are being pointed out :) (well, yes, the kthreads stuff needs to be taken care of, but both kgraft and kpatch have similar issues there). Thanks, -- Jiri Kosina SUSE Labs -- 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/2] mtd: delete unneeded call to platform_get_drvdata
On Sat, 17 May 2014, Fabio Estevam wrote:
> On Sat, May 17, 2014 at 3:32 AM, Julia Lawall wrote:
> > From: Julia Lawall
> >
> > Platform_get_drvdata is an accessor function, and has no purpose if its
> > result is not used.
> >
> > The semantic patch that fixes this problem is as follows:
> > (http://coccinelle.lip6.fr/)
> >
> > //
> > @@
> > identifier x;
> > type T;
> > @@
> > - T x = platform_get_drvdata(...);
> > ... when != x
> > //
> >
> > Signed-off-by: Julia Lawall
> >
> > ---
> > drivers/mtd/nand/bf5xx_nand.c |4
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/bf5xx_nand.c b/drivers/mtd/nand/bf5xx_nand.c
> > index b7a2494..b5fbd48 100644
> > --- a/drivers/mtd/nand/bf5xx_nand.c
> > +++ b/drivers/mtd/nand/bf5xx_nand.c
> > @@ -840,15 +840,11 @@ out_err_kzalloc:
> >
> > static int bf5xx_nand_suspend(struct platform_device *dev, pm_message_t pm)
> > {
> > - struct bf5xx_nand_info *info = platform_get_drvdata(dev);
> > -
> > return 0;
> > }
> >
> > static int bf5xx_nand_resume(struct platform_device *dev)
> > {
> > - struct bf5xx_nand_info *info = platform_get_drvdata(dev);
> > -
> > return 0;
>
> In this case bf5xx_nand_suspend/resume could be removed?
I don't know. It looks like it is intentional to have a definition that
returns an indication of success? The complete set of definitions is:
#ifdef CONFIG_PM
static int bf5xx_nand_suspend(struct platform_device *dev, pm_message_t
pm)
{
struct bf5xx_nand_info *info = platform_get_drvdata(dev);
return 0;
}
static int bf5xx_nand_resume(struct platform_device *dev)
{
struct bf5xx_nand_info *info = platform_get_drvdata(dev);
return 0;
}
#else
#define bf5xx_nand_suspend NULL
#define bf5xx_nand_resume NULL
#endif
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/
[PULL REQUEST] i2c for 3.15
Linus, here are some I2C bugfixes for 3.15. Typical stuff, I'd say. Please pull. Thanks, Wolfram The following changes since commit d6d211db37e75de2ddc3a4f979038c40df7cc79c: Linux 3.15-rc5 (2014-05-09 13:10:52 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current for you to fetch changes up to d7653964c590ba846aa11a8f6edf409773cbc492: i2c: rcar: bail out on zero length transfers (2014-05-14 18:59:57 +0200) Andy Gross (1): i2c: qup: Fix pm_runtime_get_sync usage Du, Wenkai (1): i2c: designware: Mask all interrupts during i2c controller enable Olof Johansson (1): i2c: s3c2410: resume race fix Ulf Hansson (1): i2c: nomadik: Don't use IS_ERR for devm_ioremap Wolfram Sang (1): i2c: rcar: bail out on zero length transfers drivers/i2c/busses/i2c-designware-core.c | 3 +++ drivers/i2c/busses/i2c-nomadik.c | 2 +- drivers/i2c/busses/i2c-qup.c | 2 +- drivers/i2c/busses/i2c-rcar.c| 9 - drivers/i2c/busses/i2c-s3c2410.c | 2 +- 5 files changed, 14 insertions(+), 4 deletions(-) signature.asc Description: Digital signature
Re: [PATCH] Staging: speakup: fixed reporting_keystroke variable type
On Sat, May 17, 2014 at 12:46:43AM +, Son P. Nguyen wrote: > From: "Son P. Nguyen" > > Fixed reporting_keystroke type to int instead of bool to quiet sparse > complaints of error cannot size expression. > > This is a part of eudyptula-challenge. > This is a bug in Sparse. The original code is correct. regards, dan carpenter -- 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] devicetree: Add generic IOMMU device tree bindings
On Fri, 16 May 2014 14:23:18 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> This commit introduces a generic device tree binding for IOMMU devices.
> Only a very minimal subset is described here, but it is enough to cover
> the requirements of both the Exynos System MMU and Tegra SMMU as
> discussed here:
>
> https://lkml.org/lkml/2014/4/27/346
>
> More advanced functionality such as the dma-ranges property can easily
> be added in a backwards-compatible way. In the absence of a dma-ranges
> property it should be safe to default to the whole address space.
>
> Signed-off-by: Thierry Reding
> ---
> Documentation/devicetree/bindings/iommu/iommu.txt | 109
> ++
> 1 file changed, 109 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iommu/iommu.txt
>
> diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt
> b/Documentation/devicetree/bindings/iommu/iommu.txt
> new file mode 100644
> index ..2d67b52b656e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/iommu.txt
> @@ -0,0 +1,109 @@
> +This document describes the generic device tree binding for IOMMUs and their
> +master(s).
> +
> +
> +IOMMU device node:
> +==
> +
> +An IOMMU can provide the following services:
> +
> +* Remap address space to allow devices to access physical memory ranges that
> + they otherwise wouldn't be capable of accessing.
> +
> + Example: 32-bit DMA to 64-bit physical addresses
> +
> +* Implement scatter-gather at page level granularity so that the device does
> + not have to.
> +
> +* Provide system protection against "rogue" DMA by forcing all accesses to go
> + through the IOMMU and faulting when encountering accesses to unmapped
> + address regions.
> +
> +* Provide address space isolation between multiple contexts.
> +
> + Example: Virtualization
> +
> +Device nodes compatible with this binding represent hardware with some of the
> +above capabilities.
> +
> +IOMMUs can be single-master or multiple-master. Single-master IOMMU devices
> +typically have a fixed association to the master device, whereas multiple-
> +master IOMMU devices can translate accesses from more than one master.
> +
> +Required properties:
> +
> +- #iommu-cells: The number of cells in an IOMMU specifier. The meaning of the
> + cells is defined by the binding for the IOMMU device.
> +
> + Typical values include:
> + * 0: Single-master IOMMU devices are often not configurable, therefore the
> +specifying doesn't need to encode any information and can be empty.
> +
> + * 1: Multiple-master IOMMU devices need to know for which master they
> should
> +enable translation. Typically the single cell in the specifier
> corresponds
> +to the master device's ID.
> +
> +
> +IOMMU master node:
> +==
> +
> +Devices that access memory through an IOMMU are called masters. A device can
> +have multiple master interfaces (to one or more IOMMU devices).
> +
> +Required properties:
> +
> +- iommus: A list of phandle and IOMMU specifier pairs that describe the IOMMU
> + master interfaces of the device. One entry in the list describes one master
> + interface of the device.
> +
> +Optional properties:
> +
> +- iommu-names: A list of names identifying each entry in the iommus property.
> +
> +
> +Examples:
> +=
> +
> +Single-master IOMMU:
> +
> +
> + iommu {
> + #iommu-cells = <0>;
> + };
> +
> + master {
> + iommu = <&/iommu>;
> + };
> +
Great work, Thierry.
One simple comment.
This should be also applicable to multi-master IOMMUs that the masters
of an IOMMU is not configurable with ID or something.
I think the title needs to be changed to cover such IOMMUs which always
translate master's transactions and unable to change the configuration
of the relationship between the masters and IOMMUs by S/W.
Regards,
KyongHo
> +Multi-master IOMMU:
> +---
> +
> + iommu {
> + /* the specifier represents the ID of the master */
> + #iommu-cells = <1>;
> + };
> +
> + master {
> + /* device has master ID 42 in the IOMMU */
> + iommu = <&/iommu 42>;
> + };
> +
> +Multi-master device:
> +
> +
> + /* single-master IOMMU */
> + iommu@1 {
> + #iommu-cells = <0>;
> + };
> +
> + /* multi-master IOMMU */
> + iommu@2 {
> + /* the specifier represents the ID of the master */
> + #iommu-cells = <1>;
> + };
> +
> + /* device with two master interfaces */
> + master {
> + iommus = <&/iommu@1>,/* master of the single-master IOMMU */
> + <&/iommu@2 42>; /* ID 42 in multi-master IOMMU */
> + };
> --
> 1.9.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vg
Re: [PATCH 8/8] Kbuild: add inline-account tool to find inline bloat
Hi Andi. On Fri, May 16, 2014 at 02:43:15PM -0700, Andi Kleen wrote: > From: Andi Kleen > > Add a tool to hunt for inline bloat. It uses objdump -S to account > inlines. I tried this on my sparc32 build - but it failed with: objdump: can't disassemble for architecture UNKNOWN! It looks simple to add CROSS_COMPILE support but I did not do so. My python skills are non-existing. Sam -- 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/1 linux-next] fs/cifs/inode.c: replace deprecated smp_mb__after_clear_bit
based on
febdbfe8a91ce0
"arch: Prepare for smp_mb__{before,after}_atomic()"
Cc: Jeff Layton
Cc: Steve French
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
fs/cifs/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index 9ff8df8..a174605 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -1806,7 +1806,7 @@ cifs_revalidate_mapping(struct inode *inode)
}
clear_bit_unlock(CIFS_INO_LOCK, flags);
- smp_mb__after_clear_bit();
+ smp_mb__after_atomic();
wake_up_bit(flags, CIFS_INO_LOCK);
return rc;
--
1.8.4.5
--
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] x86/mce: Clear a useless global variable in mce.c
This patch is just used to remove a useless global variable mce_entry and relative operations in mce.c. Signed-off-by: Chen Yucong --- arch/x86/include/asm/mce.h |2 -- arch/x86/kernel/cpu/mcheck/mce.c |5 - 2 files changed, 7 deletions(-) diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h index 6e4ce2d..958b90f 100644 --- a/arch/x86/include/asm/mce.h +++ b/arch/x86/include/asm/mce.h @@ -176,8 +176,6 @@ int mce_available(struct cpuinfo_x86 *c); DECLARE_PER_CPU(unsigned, mce_exception_count); DECLARE_PER_CPU(unsigned, mce_poll_count); -extern atomic_t mce_entry; - typedef DECLARE_BITMAP(mce_banks_t, MAX_NR_BANKS); DECLARE_PER_CPU(mce_banks_t, mce_poll_banks); diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c index 68317c8..8f520a1 100644 --- a/arch/x86/kernel/cpu/mcheck/mce.c +++ b/arch/x86/kernel/cpu/mcheck/mce.c @@ -60,8 +60,6 @@ static DEFINE_MUTEX(mce_chrdev_read_mutex); #define SPINUNIT 100 /* 100ns */ -atomic_t mce_entry; - DEFINE_PER_CPU(unsigned, mce_exception_count); struct mce_bank *mce_banks __read_mostly; @@ -1041,8 +1039,6 @@ void do_machine_check(struct pt_regs *regs, long error_code) DECLARE_BITMAP(valid_banks, MAX_NR_BANKS); char *msg = "Unknown"; - atomic_inc(&mce_entry); - this_cpu_inc(mce_exception_count); if (!cfg->banks) @@ -1172,7 +1168,6 @@ void do_machine_check(struct pt_regs *regs, long error_code) mce_report_event(regs); mce_wrmsrl(MSR_IA32_MCG_STATUS, 0); out: - atomic_dec(&mce_entry); sync_core(); } EXPORT_SYMBOL_GPL(do_machine_check); -- 1.7.10.4 -- 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] ARM: remove ARM710 specific assembler code
On Fri, May 16, 2014 at 01:55:46PM +0100, Russell King - ARM Linux wrote: > There was a CPU called the ARM710, it was ARMv3 and it had no Thumb support. > > There is also a CPU called the ARM710T, which is ARMv4 and has Thumb support. > > These are two completely different CPUs, the former was removed along with > the removal of ARMv3 support. The latter remains because we still support > ARMv4. BTW, while clearly this patch was removing code for the wrong reasons, I think we should set a longer term timeline for getting rid of some of old features. Let's say in 10 years time we remove everything ARMv4, another 10 years ARMv5 and so on. We could make these milestones shorter but it really depends on what people use, we should not force them out of the kernel if still in use. We can start with ARM core and SoC code that we suspect people haven't used in a while (or at least not with mainline). We should not remove them straight away but give some advanced warning. My proposal is to add a CONFIG_DEPRECATED option and update it with a 2 year cadence. Code that we want to remove will depend on DEPRECATED and explicitly not covered by defconfig. This way we can get interested parties sending patches to remove the DEPRECATED dependency. Something like this: config DEPRECATED bool "Enable deprecated kernel features" help Kernel features no longer in use are marked as DEPRECATED for two years and removed at the end of this period. This option should only be enabled explicitly and must not be included in defconfig files. If you think a DEPRECATED kernel feature is still needed, please contact the corresponding maintainers to remove the DEPRECATED dependency. The next scheduled DEPRECATED code removal is planned for 2016. It would be even better if we make such option across the whole kernel, especially since we have significant ARM SoC code into drivers. Otherwise calling it ARM_DEPRECATED would work as well. -- Catalin -- 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] x86, hugetlb: add missing TLB page invalidation for hugetlb_cow()
Hi Oren, On Thu, May 15, 2014 at 10:05:05AM +0300, Oren Twaig wrote: > > On 05/15/2014 08:00 PM, Anthony Iliopoulos wrote: > > I have dismissed this case, since I assume that there are many more > > cycles spent in servicing the TLB invalidation IPI, walking the pgtable > > plus other related overhead (e.g. sched) than in updating the pte/pmd > > so I am not sure how possible it would be to hit this condition. > > Hi Anthony, > > I have a question about the above statement. What will happen with multi > cpu VMs ? won't the race described above can happen ? I.e one virtual CPU > can will visit the host and the other will continue to encounter your race ? I don't think there will be any race for the vcpu cases, since the sptes will be cleared via the mmu_notifier, so this should take care of it in the same manner as ptep_get_and_clear() does, as described by Dave earlier in this thread. Regards, Anthony -- 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 8/8] Kbuild: add inline-account tool to find inline bloat
On Sat, May 17, 2014 at 10:31:44AM +0200, Sam Ravnborg wrote: > Hi Andi. > > On Fri, May 16, 2014 at 02:43:15PM -0700, Andi Kleen wrote: > > From: Andi Kleen > > > > Add a tool to hunt for inline bloat. It uses objdump -S to account > > inlines. > I tried this on my sparc32 build - but it failed with: > objdump: can't disassemble for architecture UNKNOWN! > > It looks simple to add CROSS_COMPILE support but I did not do so. > My python skills are non-existing. Patched the calls to nm and objdump - but it gave no output when I ran the script. nm --print-size shows following output: 2910 0024 r CSWTCH.946 2bd4 0024 r CSWTCH.951 U PDE_DATA U ROOT_DEV 00fc 0014 T SyS_accept 2c98 01a8 T SyS_accept4 0fc4 008c T SyS_bind 0eb4 0094 T SyS_connect 0d98 0094 T SyS_getpeername 0e2c 0088 T SyS_getsockname 0c6c 0090 T SyS_getsockopt 0f48 007c T SyS_listen 0128 0018 T SyS_recv 142c 00f0 T SyS_recvfrom 1920 00d0 T SyS_recvmmsg 1238 0010 T SyS_recvmsg 0110 0018 T SyS_send 1d38 0010 T SyS_sendmmsg 1db0 0010 T SyS_sendmsg 15f4 00dc T SyS_sendto 0cfc 009c T SyS_setsockopt 0c0c 0060 T SyS_shutdown 3020 00b4 T SyS_socket 07ec 01f8 T SyS_socketcall 2e40 01e0 T SyS_socketpair 000b776c 0098 t T.1063 000b762c 00d0 t T.1064 objdump -Sl shows following output: 00d4 : sock_mmap(): d4: 9d e3 bf a0 save %sp, -96, %sp d8: c2 06 20 78 ld [ %i0 + 0x78 ], %g1 dc: 94 10 00 19 mov %i1, %o2 e0: 92 10 00 01 mov %g1, %o1 e4: c2 00 60 18 ld [ %g1 + 0x18 ], %g1 e8: c2 00 60 40 ld [ %g1 + 0x40 ], %g1 ec: 9f c0 40 00 call %g1 f0: 90 10 00 18 mov %i0, %o0 f4: 81 c7 e0 08 ret f8: 91 e8 00 08 restore %g0, %o0, %o0 00fc : sys_accept(): fc: 96 10 20 00 clr %o3 100: 82 13 c0 00 mov %o7, %g1 104: 40 00 00 00 call 104 108: 9e 10 40 00 mov %g1, %o7 10c: 01 00 00 00 nop 0110 : SyS_send(): 110: 98 10 20 00 clr %o4! 0 114: 9a 10 20 00 clr %o5 118: 82 13 c0 00 mov %o7, %g1 11c: 40 00 00 00 call 11c 120: 9e 10 40 00 mov %g1, %o7 124: 01 00 00 00 nop 0128 : sys_recv(): 128: 98 10 20 00 clr %o4! 0 12c: 9a 10 20 00 clr %o5 130: 82 13 c0 00 mov %o7, %g1 134: 40 00 00 00 call 134 138: 9e 10 40 00 mov %g1, %o7 13c: 01 00 00 00 nop Sam -- 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 5/9] I2C: Add smbus quick read/write helper function
On Mon, Apr 28, 2014 at 10:27:44PM +0800, Lan Tianyu wrote: > Add i2c_smbus_quick_write/read() helper function. These will be used > in the implementation of i2c ACPI address space handler. > > Reviewed-by: Mika Westerberg > Signed-off-by: Lan Tianyu We had such a function once but removed because of no users. Please check 67c2e66571c383404a5acd08189194da660da942 what it takes to bring them back. Especially missing are documentation updates... > +s32 i2c_smbus_quick_write(const struct i2c_client *client) ... and I like the original function much better. 1) It is named *_write_quick which follows other function name patterns 2) It uses a parameter for the r/w bit. Make sense to me, since this bit is the information we send to the device. quick_read doesn't make sense to me. We don't receive a bit from the device. signature.asc Description: Digital signature
Re: Dell Latitude E6440 & i8k
On Fri, 16 May 2014 21:23:02 +0200, Pali Rohár wrote: > So is not there any documentation? I think that Dell released > some SMM/BIOS code... But I'm not sure about it. I don't know either. But even with some SMM/BIOS code, it doesn't tell you which sensors are present on which machines, nor what they correspond to, nor what scaling factors need to be applied. > > (...) > > Load the i8k driver with fan_mult=1. > > Looks like now it reports more plausible value for fan. When fan > is at low it reporting between 3000 - 3100 RPM. > > > Add the following to /etc/sensors.d/i8k.conf: > > > > chip "i8k-virtual-0" > > > >label fan2 "Left Fan" > >ignore temp4 > > And this fixing output from sensors program. > > $ sensors > i8k-virtual-0 > Adapter: Virtual device > Left Fan:3088 RPM > CPU: +54.0°C > temp2:+57.0°C > temp3:+40.0°C > > But Right Fan name is still present in kernel sysfs: > > $ grep "" /sys/class/hwmon/hwmon1/* > /sys/class/hwmon/hwmon1/fan2_input:3091 > /sys/class/hwmon/hwmon1/fan2_label:Right Fan > /sys/class/hwmon/hwmon1/name:i8k > /sys/class/hwmon/hwmon1/pwm2:128 > /sys/class/hwmon/hwmon1/temp1_input:56000 > /sys/class/hwmon/hwmon1/temp1_label:CPU > /sys/class/hwmon/hwmon1/temp2_input:57000 > /sys/class/hwmon/hwmon1/temp3_input:4 > /sys/class/hwmon/hwmon1/temp4_input:127000 The drivers sets default labels in sysfs, the libsensors configuration files lets you override these defaults with your own labels. -- Jean Delvare SUSE L3 Support -- 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] ARM: remove ARM710 specific assembler code
On Sat, May 17, 2014 at 10:23:37AM +0100, Catalin Marinas wrote: > On Fri, May 16, 2014 at 01:55:46PM +0100, Russell King - ARM Linux wrote: > > There was a CPU called the ARM710, it was ARMv3 and it had no Thumb support. > > > > There is also a CPU called the ARM710T, which is ARMv4 and has Thumb > > support. > > > > These are two completely different CPUs, the former was removed along with > > the removal of ARMv3 support. The latter remains because we still support > > ARMv4. > > BTW, while clearly this patch was removing code for the wrong reasons, I > think we should set a longer term timeline for getting rid of some of > old features. Let's say in 10 years time we remove everything ARMv4, > another 10 years ARMv5 and so on. We could make these milestones shorter > but it really depends on what people use, we should not force them out > of the kernel if still in use. I still use StrongARM based machines here, and I don't see that changing unless some suitably designed ARM boards come my way which (a) offer the same features and (b) out perform it. The problem is that there's lots of ARM boards which satisfy (b) - the iMX6 stuff clearly does - but hardly anything which satisfies (a). There's also been some recent effort with SA1100 SoC code, so there's also other interest there still. So, ARMv4 is still very much in use with modern kernels. The difference between what you're proposing and what happened to ARMv3 is that ARMv3 was broken for quite some time (we read from some of the CP15 registers which are read-only in ARMv3) and no one ever raised a problem with that. So, after a sufficient period of time, it got removed - and no one batted an eyelid. That's the correct way to do it - allow code to age, and if no one notices it's been broken, then it can be removed. That process is slightly broken by the automated build testing we now have (provided people are looking at the results.) -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from 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] ARM: remove ARM710 specific assembler code
On 17 May 2014, at 10:46, Russell King - ARM Linux wrote: > On Sat, May 17, 2014 at 10:23:37AM +0100, Catalin Marinas wrote: >> On Fri, May 16, 2014 at 01:55:46PM +0100, Russell King - ARM Linux wrote: >>> There was a CPU called the ARM710, it was ARMv3 and it had no Thumb support. >>> >>> There is also a CPU called the ARM710T, which is ARMv4 and has Thumb >>> support. >>> >>> These are two completely different CPUs, the former was removed along with >>> the removal of ARMv3 support. The latter remains because we still support >>> ARMv4. >> >> BTW, while clearly this patch was removing code for the wrong reasons, I >> think we should set a longer term timeline for getting rid of some of >> old features. Let's say in 10 years time we remove everything ARMv4, >> another 10 years ARMv5 and so on. We could make these milestones shorter >> but it really depends on what people use, we should not force them out >> of the kernel if still in use. > > I still use StrongARM based machines here, and I don't see that changing > unless some suitably designed ARM boards come my way which (a) offer the > same features and (b) out perform it. > > The problem is that there's lots of ARM boards which satisfy (b) - the > iMX6 stuff clearly does - but hardly anything which satisfies (a). > > There's also been some recent effort with SA1100 SoC code, so there's > also other interest there still. > > So, ARMv4 is still very much in use with modern kernels. That’s why I said maybe aim for removing it in 10 year. But if code is still in use by that time, we keep it. > The difference between what you're proposing and what happened to ARMv3 > is that ARMv3 was broken for quite some time (we read from some of the > CP15 registers which are read-only in ARMv3) and no one ever raised a > problem with that. So, after a sufficient period of time, it got removed > - and no one batted an eyelid. That's the correct way to do it - allow > code to age, and if no one notices it's been broken, then it can be > removed. I’m more for pro-actively “breaking” it with a DEPRECATED dependency. For example, if you suspect that some code like ARM710T is no longer in use, we mark it and see if anyone complains about this over a two years period. If not, it gets removed. Waiting for code to get broken is another way but it’s less predictable. Catalin-- 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] x86/mce: Clear a useless global variable in mce.c
On Sat, May 17, 2014 at 04:45:24PM +0800, Chen Yucong wrote: > This patch is just used to remove a useless global variable mce_entry > and relative operations in mce.c. Well, I can see from the diff below what you're saying here but a commit message should contain information which explains *why* you're doing the change and not *what* you're doing - that we can see. IOW, you could instead do some git history research and write in your commit message why this mce_entry got unused and quote commits which removed it, why they removed it and why we want to remove the remains of it now. In any case, the change itself is correct, I would like to have a commit message which explains why we're removing it. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting 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 v3 1/7] pinctrl: berlin: add the core pinctrl driver for Marvell Berlin SoCs
On 05/05/2014 07:27 AM, Antoine Ténart wrote:
> The Marvell Berlin boards have a group based pinmuxing mechanism. This
> adds the core driver support. We actually do not need any information
> about the pins here and only have the definition of the groups.
>
> Let's take the example of the uart0 pinmuxing on the BG2Q. Balls BK4 and
> BH6 are muxed to respectively UART0 RX and TX if the group GSM12 is set
> to mode 0:
>
> Group Modes Offset Base Offset LSB Bit Width
> GSM12 3 sm_base 0x400x100x2
>
> Ball Group Mode 0 Mode 1 Mode 2
> BK4 GSM12 UART0_RXIrDA0_RXGPIO9
> BH6 GSM12 UART0_TXIrDA0_TXGPIO10
>
> So in order to configure BK4 -> UART0_TX and BH6 -> UART0_RX, we need
> to set (sm_base + 0x40 + 0x10) &= ff3f.
>
> Signed-off-by: Antoine Ténart
> Acked-by: Sebastian Hesselbarth
> ---
[...]
> +static int berlin_pinctrl_dt_node_to_map(struct pinctrl_dev *pctrl_dev,
> + struct device_node *node,
> + struct pinctrl_map **map,
> + unsigned *num_maps)
> +{
Linus,
thinking of your request to make "function"/"groups" standard
properties, I guess you also had some corresponding helpers in
mind.
Looking at the map and free functions here, I can see no Berlin
specific code at all. One option would be to make those functions
a standard callback for .dt_node_to_map and .dt_free_map, i.e.
pinctrl_utils_function_group_dt_node_to_map.
IMHO, the more flexible option would be to rather have
of_pinctrl_utils_read_function(node, &function_name, &ngroups)
and
of_pinctrl_for_each_function_group(node, group_name)
swallowing the property names and reuse it like below.
The simple option would be to just remove the marvell, prefix
now and have a closer look at other pinctrl drivers to see what
will be required, of course.
Do you have any preference?
Sebastian
> + struct berlin_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctrl_dev);
> + struct property *prop;
> + const char *function_name, *group_name;
> + unsigned reserved_maps = 0;
> + int ret, ngroups;
> +
> + *map = NULL;
> + *num_maps = 0;
> +
> + ret = of_property_read_string(node, "marvell,function", &function_name);
> + if (ret) {
> + dev_err(pctrl->dev,
> + "missing 'marvell,function' property in node %s\n",
> + node->name);
> + return -EINVAL;
> + }
> +
> + ngroups = of_property_count_strings(node, "marvell,groups");
> + if (ngroups < 0) {
> + dev_err(pctrl->dev,
> + "missing 'marvell,groups' property in node %s\n",
> + node->name);
> + return -EINVAL;
> + }
> +
> + ret = pinctrl_utils_reserve_map(pctrl_dev, map, &reserved_maps,
> + num_maps, ngroups);
> + if (ret) {
> + dev_err(pctrl->dev, "can't reserve map: %d\n", ret);
> + return ret;
> + }
> +
> + of_property_for_each_string(node, "marvell,groups", prop, group_name) {
> + ret = pinctrl_utils_add_map_mux(pctrl_dev, map, &reserved_maps,
> + num_maps, group_name,
> + function_name);
> + if (ret) {
> + dev_err(pctrl->dev, "can't add map: %d\n", ret);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void berlin_pinctrl_dt_free_map(struct pinctrl_dev *pctrl_dev,
> +struct pinctrl_map *map,
> +unsigned nmaps)
> +{
> + int i;
> +
> + for (i = 0; i < nmaps; i++) {
> + if (map[i].type == PIN_MAP_TYPE_MUX_GROUP) {
> + kfree(map[i].data.mux.group);
> +
> + /* a function can be applied to multiple groups */
> + if (i == 0)
> + kfree(map[i].data.mux.function);
> + }
> + }
> +
> + kfree(map);
> +}
> +
> +static const struct pinctrl_ops berlin_pinctrl_ops = {
> + .get_groups_count = &berlin_pinctrl_get_group_count,
> + .get_group_name = &berlin_pinctrl_get_group_name,
> + .dt_node_to_map = &berlin_pinctrl_dt_node_to_map,
> + .dt_free_map= &berlin_pinctrl_dt_free_map,
> +};
--
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 6/9] I2C: Add smbus word/block process call helper function
On Mon, Apr 28, 2014 at 10:27:45PM +0800, Lan Tianyu wrote:
> Add i2c_smbus_word/block_proc_call() helper function. These will be used
> in the implementation of i2c ACPI address space handler.
>
> Reviewed-by: Mika Westerberg
> Signed-off-by: Lan Tianyu
> ---
> drivers/i2c/i2c-core.c | 56
> ++
> include/linux/i2c.h| 4
> 2 files changed, 60 insertions(+)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 3bf0048..638befd 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -2306,6 +2306,30 @@ s32 i2c_smbus_write_word_data(const struct i2c_client
> *client, u8 command,
> EXPORT_SYMBOL(i2c_smbus_write_word_data);
>
> /**
> + * i2c_smbus_word_proc_call - SMBus "word proc call" protocol
> + * @client: Handle to slave device
> + * @command: Byte interpreted by slave
> + * @value: 16-bit "word" being written
> + *
> + * This executes the SMBus "word proc all" protocol, returning negative errno
> + * else a 16-bit unsigned "word" received from the device.
> + */
> +s32 i2c_smbus_word_proc_call(const struct i2c_client *client, u8 command,
> + u16 value)
> +{
> + union i2c_smbus_data data;
> + int status;
> +
> + data.word = value;
> + status = i2c_smbus_xfer(client->adapter, client->addr, client->flags,
> + I2C_SMBUS_READ, command,
> + I2C_SMBUS_PROC_CALL, &data);
> +
> + return (status < 0) ? status : data.word;
> +}
> +EXPORT_SYMBOL(i2c_smbus_word_proc_call);
> +
> +/**
Same as smbus_quick function before, documentation updates are missing.
Also similar, we had such a function before which was removed due to no
users? It looks very much like the function here, so we should stick to
the old naming IMO. Is it the old one? Such information would be nice
since it affects reviewing.
> * i2c_smbus_read_block_data - SMBus "block read" protocol
> * @client: Handle to slave device
> * @command: Byte interpreted by slave
> @@ -2362,6 +2386,38 @@ s32 i2c_smbus_write_block_data(const struct i2c_client
> *client, u8 command,
> }
> EXPORT_SYMBOL(i2c_smbus_write_block_data);
>
> +/**
> + * i2c_smbus_block_proc_call - SMBus "block write" protocol
> + * @client: Handle to slave device
> + * @command: Byte interpreted by slave
> + * @length: Size of data block; SMBus allows at most 32 bytes
> + * @values: Byte array which will be written.
> + *
> + * This executes the SMBus "block proc call" protocol, returning negative
> errno
> + * else the number of read bytes.
> + */
> +s32 i2c_smbus_block_proc_call(const struct i2c_client *client, u8 command,
> +u8 length, u8 *values)
Please rename to "i2c_smbus_block_process_call" as the old function was
named. Needs documentation updates.
> + if (length > I2C_SMBUS_BLOCK_MAX)
> + length = I2C_SMBUS_BLOCK_MAX;
I think we should return an error here.
BTW what were your test scenarios for these functions and smbus quick?
signature.asc
Description: Digital signature
Re: [PATCH] ARM: remove ARM710 specific assembler code
On Sat, May 17, 2014 at 10:56:02AM +0100, Catalin Marinas wrote: > > The difference between what you're proposing and what happened to ARMv3 > > is that ARMv3 was broken for quite some time (we read from some of the > > CP15 registers which are read-only in ARMv3) and no one ever raised a > > problem with that. So, after a sufficient period of time, it got removed > > - and no one batted an eyelid. That's the correct way to do it - allow > > code to age, and if no one notices it's been broken, then it can be > > removed. > > I’m more for pro-actively “breaking” it with a DEPRECATED > dependency. For example, if you suspect that some code like ARM710T is > no longer in use, we mark it and see if anyone complains about this over > a two years period. If not, it gets removed. > > Waiting for code to get broken is another way but it’s less > predictable. When code being used gets broken, it's nice to think that we'll get bug reports which will tell us if it's still being used. The problem with DEPRECATED is that it will get lost amongst all the thousands of other config options and won't be noticed. Just like EXPERIMENTAL or any of the other similar options we've had. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from 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 0/2] staging: rtl8188eu: fix Coverity defects in rtw_drv_init()
This addresses two issues currently reported by static analysis for function rtw_drv_init() in drivers/staging/rtl8188eu/os_dep/usb_intf.c. CID 1077553 - Logically dead code CID 1077832 - Uninitialized scalar variable Compile tested only. Applies against branch staging-next of tree git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git Christian Engelmayer (2): staging: rtl8188eu: fix usage of uninit scalar in rtw_drv_init() staging: rtl8188eu: remove dead code in rtw_drv_init() drivers/staging/rtl8188eu/os_dep/usb_intf.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) -- 1.9.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 2/2] staging: rtl8188eu: remove dead code in rtw_drv_init()
(status != _SUCCESS) immediately after 'status = _SUCCESS' will never evaluate true. Thus remove the logically dead code. Detected by Coverity - CID 1077553. Signed-off-by: Christian Engelmayer --- drivers/staging/rtl8188eu/os_dep/usb_intf.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c b/drivers/staging/rtl8188eu/os_dep/usb_intf.c index 632a5b0a..2a96add 100644 --- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c +++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c @@ -713,8 +713,6 @@ static int rtw_drv_init(struct usb_interface *pusb_intf, const struct usb_device status = _SUCCESS; - if (status != _SUCCESS && if1) - rtw_usb_if1_deinit(if1); free_dvobj: if (status != _SUCCESS) usb_dvobj_deinit(pusb_intf); -- 1.9.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 1/2] staging: rtl8188eu: fix usage of uninit scalar in rtw_drv_init()
Function rtw_drv_init() is written in a way that assumes 'status' != _SUCCESS
as long as not explicitly set. Thus initialize 'status' to FAIL, in order to
prevent undefined behaviour if going through the exit paths. Detected by
Coverity - CID 1077832.
Signed-off-by: Christian Engelmayer
---
drivers/staging/rtl8188eu/os_dep/usb_intf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index 8ed2ac8..632a5b0a 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -685,7 +685,7 @@ static void rtw_usb_if1_deinit(struct adapter *if1)
static int rtw_drv_init(struct usb_interface *pusb_intf, const struct
usb_device_id *pdid)
{
struct adapter *if1 = NULL;
- int status;
+ int status = _FAIL;
struct dvobj_priv *dvobj;
RT_TRACE(_module_hci_intfs_c_, _drv_err_, ("+rtw_drv_init\n"));
--
1.9.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/
Linux 3.12.20
I'm announcing the release of the 3.12.20 kernel. All users of the 3.12 kernel series must upgrade. The updated 3.12.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.12.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary Aaron Sanders (1): USB: pl2303: add ids for Hewlett-Packard HP POS pole displays Alan Stern (2): USB: fix crash during hotplug of PCI USB controller card USB: unbind all interfaces before rebinding any Alec Berg (1): iio: querying buffer scan_mask should return 0/1 Alexander Gordeev (1): ahci: Do not receive interrupts sent by dummy ports Alexander Usyskin (1): mei: ignore client writing state during cb completion Andrew Lunn (1): ARM: Fix default CPU selection for ARCH_MULTI_V5 Andy Grover (1): target/tcm_fc: Fix use-after-free of ft_tpg Antoine Ténart (1): video: atmel_lcdfb: ensure the hardware is initialized with the correct mode Anton Blanchard (1): powerpc/compat: 32-bit little endian machine name is ppcle, not ppc Antti Palosaari (1): media: em28xx: fix PCTV 290e LNA oops Bart Van Assche (1): dlm: Avoid that dlm_release_lockspace() incorrectly returns -EBUSY Benjamin LaHaise (1): aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration Brian Austin (3): ASoC: cs42l51: Fix SOC_DOUBLE_R_SX_TLV shift values for ADC, PCM, and Analog kcontrols ASoC: cs42l52: Fix mask bits for SOC_VALUE_ENUM_SINGLE ASoC: cs42l73: Fix mask bits for SOC_VALUE_ENUM_SINGLE Catalin Marinas (2): arm64: Do not synchronise I and D caches for special ptes arm64: Make DMA coherent and strongly ordered mappings not executable Charles Keepax (1): regulator: arizona-ldo1: Correct default regulator init_data Christian Borntraeger (1): KVM: s390: Optimize ucontrol path Christopher Covington (1): ARM: 8007/1: Remove extraneous kcmp syscall ignore Colin Ian King (1): rtlwifi: rtl8188ee: initialize packet_beacon Dan Carpenter (4): SCSI: qla2xxx: fix error handling of qla2x00_mem_alloc() SCSI: arcmsr: upper 32 of dma address lost mtd: nuc900_nand: NULL dereference in nuc900_nand_enable() mtd: sm_ftl: heap corruption in sm_create_sysfs_attributes() Dan Williams (1): libata/ahci: accommodate tag ordered controllers David Cohen (1): usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM David Fries (1): w1: fix w1_send_slave dropping a slave id David Milburn (1): ahci: do not request irq for dummy port Denis Turischev (1): xhci: Switch Intel Lynx Point ports to EHCI on shutdown. Dennis Dalessandro (1): IB/ipath: Fix potential buffer overrun in sending diag packet routine Emmanuel Grumbach (1): iwlwifi: dvm: take mutex when sending SYNC BT config command Fam Zheng (1): virtio-scsi: Skip setting affinity on uninitialized vq Felipe Balbi (2): usb: dwc3: fix randconfig build errors usb: musb: avoid NULL pointer dereference Felipe Franciosi (2): mtip32xx: Set queue bounce limit mtip32xx: Unmap the DMA segments before completing the IO request Felix Fietkau (2): mac80211: exclude AP_VLAN interfaces from tx power calculation ath9k: fix ready time of the multicast buffer queue Florian Vaussard (1): media: omap3isp: preview: Fix the crop margins Gerd Hoffmann (1): drm: cirrus: add power management support Giacomo Comes (1): Skip intel_crt_init for Dell XPS 8700 Gregory CLEMENT (1): usb: gadget: atmel_usba: fix crashed during stopping when DEBUG is enabled Guenter Roeck (1): mfd: kempld-core: Fix potential hang-up during boot H Hartley Sweeten (1): staging: comedi: usbdux: bug fix for accessing 'ao_chanlist' in private data H. Peter Anvin (1): x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels Haibin Wang (1): KVM: ARM: vgic: Fix sgi dispatch problem Hans Verkuil (4): media: videodev2.h: add parenthesis around macro arguments media: v4l2-dv-timings: add module name, description, license media: v4l2-compat-ioctl32: fix wrong VIDIOC_SUBDEV_G/S_EDID32 support media: saa7134: fix WARN_ON during resume Hans de Goede (2): Input: synaptics - add min/max quirk for ThinkPad T431s, L440, L540, S1 Yoga and X1 Input: synaptics - add min/max quirk for ThinkPad Edge E431 Herve Codina (1): mtd: atmel_nand: Disable subpage NAND write when using Atmel PMECC Himangi Saraogi (1): staging:serqt_usb2: Fix sparse warning restricted __le16 degrades to integer Huacai Chen (1): MIPS: Hibernate: Flush TLB entries in swsusp_arch_resume() Huang Rui (1): usb: dwc3: fix wrong bit mask in dwc3_event_devt Hui Wang (1):
[PATCH] target: fix memory leak on XCOPY
On each processed XCOPY command, two "kmalloc-512" memory objects are leaked. These represent two allocations of struct xcopy_pt_cmd in target_core_xcopy.c. The reason for the memory leak is that the cmd_kref field is not initialized (thus, it is zero because the allocations were done with kzalloc). When we decrement zero kref in target_put_sess_cmd, the result is not zero, thus target_release_cmd_kref is not called. This patch fixes the bug by moving kref initialization from target_get_sess_cmd to transport_init_se_cmd (this function is called from target_core_xcopy.c, so it will correctly initialize cmd_kref). It can be easily verified that all code that calls target_get_sess_cmd also calls transport_init_se_cmd earlier, thus moving kref_init shouldn't introduce any new problems. Signed-off-by: Mikulas Patocka Cc: sta...@vger.kernel.org # 3.12+ --- drivers/target/target_core_transport.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-3.15-rc5/drivers/target/target_core_transport.c === --- linux-3.15-rc5.orig/drivers/target/target_core_transport.c 2014-04-14 16:08:15.0 +0200 +++ linux-3.15-rc5/drivers/target/target_core_transport.c 2014-05-16 18:24:57.0 +0200 @@ -1113,6 +1113,7 @@ void transport_init_se_cmd( init_completion(&cmd->cmd_wait_comp); init_completion(&cmd->task_stop_comp); spin_lock_init(&cmd->t_state_lock); + kref_init(&cmd->cmd_kref); cmd->transport_state = CMD_T_DEV_ACTIVE; cmd->se_tfo = tfo; @@ -2357,7 +2358,6 @@ int target_get_sess_cmd(struct se_sessio unsigned long flags; int ret = 0; - kref_init(&se_cmd->cmd_kref); /* * Add a second kref if the fabric caller is expecting to handle * fabric acknowledgement that requires two target_put_sess_cmd() -- 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] kref: warn on uninitialized kref
I found a memory leak in iSCSI target that was caused by kref initialized
to zero (the memory object was allocated with kzalloc, kref_init was not
called and kref_put_spinlock_irqsave was called which changed "0" to "-1"
and didn't free the object).
Similar bugs may exist in other kernel areas, so I submit this patch that
adds a check to kref.h. If the value is zero or negative, we can assume
that it is uninitialized and we warn about it.
Signed-off-by: Mikulas Patocka
---
include/linux/kref.h |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-3.15-rc5/include/linux/kref.h
===
--- linux-3.15-rc5.orig/include/linux/kref.h2013-07-02 22:23:38.0
+0200
+++ linux-3.15-rc5/include/linux/kref.h 2014-05-16 18:56:18.0 +0200
@@ -69,7 +69,7 @@ static inline int kref_sub(struct kref *
void (*release)(struct kref *kref))
{
WARN_ON(release == NULL);
-
+ WARN_ON_ONCE(atomic_read(&kref->refcount) <= 0);
if (atomic_sub_and_test((int) count, &kref->refcount)) {
release(kref);
return 1;
@@ -119,6 +119,7 @@ static inline int kref_put_spinlock_irqs
unsigned long flags;
WARN_ON(release == NULL);
+ WARN_ON_ONCE(atomic_read(&kref->refcount) <= 0);
if (atomic_add_unless(&kref->refcount, -1, 1))
return 0;
spin_lock_irqsave(lock, flags);
@@ -136,6 +137,7 @@ static inline int kref_put_mutex(struct
struct mutex *lock)
{
WARN_ON(release == NULL);
+ WARN_ON_ONCE(atomic_read(&kref->refcount) <= 0);
if (unlikely(!atomic_add_unless(&kref->refcount, -1, 1))) {
mutex_lock(lock);
if (unlikely(!atomic_dec_and_test(&kref->refcount))) {
--
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] kref: warn on uninitialized kref
On Sat, May 17, 2014 at 06:53:17AM -0400, Mikulas Patocka wrote:
> I found a memory leak in iSCSI target that was caused by kref initialized
> to zero (the memory object was allocated with kzalloc, kref_init was not
> called and kref_put_spinlock_irqsave was called which changed "0" to "-1"
> and didn't free the object).
>
> Similar bugs may exist in other kernel areas, so I submit this patch that
> adds a check to kref.h. If the value is zero or negative, we can assume
> that it is uninitialized and we warn about it.
>
> Signed-off-by: Mikulas Patocka
>
> ---
> include/linux/kref.h |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> Index: linux-3.15-rc5/include/linux/kref.h
> ===
> --- linux-3.15-rc5.orig/include/linux/kref.h 2013-07-02 22:23:38.0
> +0200
> +++ linux-3.15-rc5/include/linux/kref.h 2014-05-16 18:56:18.0
> +0200
> @@ -69,7 +69,7 @@ static inline int kref_sub(struct kref *
>void (*release)(struct kref *kref))
> {
> WARN_ON(release == NULL);
> -
> + WARN_ON_ONCE(atomic_read(&kref->refcount) <= 0);
> if (atomic_sub_and_test((int) count, &kref->refcount)) {
> release(kref);
> return 1;
> @@ -119,6 +119,7 @@ static inline int kref_put_spinlock_irqs
> unsigned long flags;
>
> WARN_ON(release == NULL);
> + WARN_ON_ONCE(atomic_read(&kref->refcount) <= 0);
> if (atomic_add_unless(&kref->refcount, -1, 1))
> return 0;
> spin_lock_irqsave(lock, flags);
> @@ -136,6 +137,7 @@ static inline int kref_put_mutex(struct
>struct mutex *lock)
> {
> WARN_ON(release == NULL);
> + WARN_ON_ONCE(atomic_read(&kref->refcount) <= 0);
> if (unlikely(!atomic_add_unless(&kref->refcount, -1, 1))) {
> mutex_lock(lock);
> if (unlikely(!atomic_dec_and_test(&kref->refcount))) {
This has a side effect of detecting some overputs, which is nice.
However, could be made better if kref_sub checked that refs you want to
take don't put the count below 0.
i.e.
WARN_ON(count > atomic_read(&kref->refcount));
this also detects your original problem.
--
Mateusz Guzik
--
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/2] staging: rtl8188eu: fix Coverity defects in rtw_drv_init()
Christian Engelmayer writes: > This addresses two issues currently reported by static analysis for function > rtw_drv_init() in drivers/staging/rtl8188eu/os_dep/usb_intf.c. > >CID 1077553 - Logically dead code >CID 1077832 - Uninitialized scalar variable > > Compile tested only. Applies against branch staging-next of tree > git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git > > Christian Engelmayer (2): > staging: rtl8188eu: fix usage of uninit scalar in rtw_drv_init() > staging: rtl8188eu: remove dead code in rtw_drv_init() > > drivers/staging/rtl8188eu/os_dep/usb_intf.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) Acked-by: Jes Sorensen -- 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] Hexagon: remove check for CONFIG_COMET_EARLY_UART_DEBUG
There's been a check for CONFIG_COMET_EARLY_UART_DEBUG ever since Hexagon was added in v3.2. But the related Kconfig symbol has never been added to the tree. Remove this check. Signed-off-by: Paul Bolle --- Not tested. arch/hexagon/kernel/vm_init_segtable.S | 5 - 1 file changed, 5 deletions(-) diff --git a/arch/hexagon/kernel/vm_init_segtable.S b/arch/hexagon/kernel/vm_init_segtable.S index 80967f2192b3..167b48458620 100644 --- a/arch/hexagon/kernel/vm_init_segtable.S +++ b/arch/hexagon/kernel/vm_init_segtable.S @@ -85,12 +85,7 @@ swapper_pg_dir: .word X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X .word X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X,X /*0xa8*/.word X,X,X,X -#ifdef CONFIG_COMET_EARLY_UART_DEBUG -UART_PTE_ENTRY: -/*0xa9*/.word BKPG_IO(0xa900),BKPG_IO(0xa900),BKPG_IO(0xa900),BKPG_IO(0xa900) -#else /*0xa9*/.word X,X,X,X -#endif /*0xaa*/.word X,X,X,X /*0xab*/.word X,X,X,X /*0xac*/.word X,X,X,X -- 1.9.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/
[PATCH] fs: Fix theoretical division by 0 in super_cache_scan().
>From 7a2ed4e9c91864736ce5ad89489fd5862d59542e Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Sat, 17 May 2014 20:56:38 +0900 Subject: [PATCH] fs: Fix theoretical division by 0 in super_cache_scan(). total_objects could be 0 and is used as a denom. While total_objects is a "long", total_objects == 0 unlikely happens for 3.12 and later kernels because 32-bit architectures would not be able to hold (1 << 32) objects. However, total_objects == 0 may happen for kernels between 3.1 and 3.11 because total_objects in prune_super() was an "int" and (e.g.) x86_64 architecture might be able to hold (1 << 32) objects. Signed-off-by: Tetsuo Handa Cc: stable # 3.1+ --- fs/super.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/fs/super.c b/fs/super.c index 48377f7..1408362 100644 --- a/fs/super.c +++ b/fs/super.c @@ -81,6 +81,8 @@ static unsigned long super_cache_scan(struct shrinker *shrink, inodes = list_lru_count_node(&sb->s_inode_lru, sc->nid); dentries = list_lru_count_node(&sb->s_dentry_lru, sc->nid); total_objects = dentries + inodes + fs_objects + 1; + if (!total_objects) + total_objects = 1; /* proportion the scan between the caches */ dentries = mult_frac(sc->nr_to_scan, dentries, total_objects); -- 1.7.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] x86/mce: Clear a useless global variable in mce.c
The mce_entry, which was defined as a global variable in mce.c, was used in nmi_watchdog_tick().But nmi_watchdog_tick() has been discarded in the new generic nmi_watchdog implementation - commit 1fb9d6ad2766. So, of course, there is no need for the mce_entry. This patch is just used to remove a useless global variable mce_entry and relative operations in mce.c. Signed-off-by: Chen Yucong --- arch/x86/include/asm/mce.h |2 -- arch/x86/kernel/cpu/mcheck/mce.c |5 - 2 files changed, 7 deletions(-) diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h index 6e4ce2d..958b90f 100644 --- a/arch/x86/include/asm/mce.h +++ b/arch/x86/include/asm/mce.h @@ -176,8 +176,6 @@ int mce_available(struct cpuinfo_x86 *c); DECLARE_PER_CPU(unsigned, mce_exception_count); DECLARE_PER_CPU(unsigned, mce_poll_count); -extern atomic_t mce_entry; - typedef DECLARE_BITMAP(mce_banks_t, MAX_NR_BANKS); DECLARE_PER_CPU(mce_banks_t, mce_poll_banks); diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c index 68317c8..8f520a1 100644 --- a/arch/x86/kernel/cpu/mcheck/mce.c +++ b/arch/x86/kernel/cpu/mcheck/mce.c @@ -60,8 +60,6 @@ static DEFINE_MUTEX(mce_chrdev_read_mutex); #define SPINUNIT 100 /* 100ns */ -atomic_t mce_entry; - DEFINE_PER_CPU(unsigned, mce_exception_count); struct mce_bank *mce_banks __read_mostly; @@ -1041,8 +1039,6 @@ void do_machine_check(struct pt_regs *regs, long error_code) DECLARE_BITMAP(valid_banks, MAX_NR_BANKS); char *msg = "Unknown"; - atomic_inc(&mce_entry); - this_cpu_inc(mce_exception_count); if (!cfg->banks) @@ -1172,7 +1168,6 @@ void do_machine_check(struct pt_regs *regs, long error_code) mce_report_event(regs); mce_wrmsrl(MSR_IA32_MCG_STATUS, 0); out: - atomic_dec(&mce_entry); sync_core(); } EXPORT_SYMBOL_GPL(do_machine_check); -- 1.7.10.4 -- 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] IB/mlx4: Fix potentially uninitialized use of 'is_mcast' in create_iboe_ah()
Before commit 297e0da (IB/mlx4: Handle Ethernet L2 parameters for IP based GID
addressing) local variable 'is_mcast' in function create_iboe_ah() was
guaranteed to be set after calling mlx4_ib_resolve_grh(). Since 297e0da
'is_mcast' is set in case of rdma_is_multicast_addr(), but otherwise left
uninitialized. Thus init 'is_mcast' to 0. Detected by Coverity - CID 1164324
Signed-off-by: Christian Engelmayer
---
Compile tested. Applies against branch for-next in tree
git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
---
drivers/infiniband/hw/mlx4/ah.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx4/ah.c b/drivers/infiniband/hw/mlx4/ah.c
index 170dca6..2d8c339 100644
--- a/drivers/infiniband/hw/mlx4/ah.c
+++ b/drivers/infiniband/hw/mlx4/ah.c
@@ -73,7 +73,7 @@ static struct ib_ah *create_iboe_ah(struct ib_pd *pd, struct
ib_ah_attr *ah_attr
{
struct mlx4_ib_dev *ibdev = to_mdev(pd->device);
struct mlx4_dev *dev = ibdev->dev;
- int is_mcast;
+ int is_mcast = 0;
struct in6_addr in6;
u16 vlan_tag;
--
1.9.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: [RFC PATCH 1/9] dt: deps: dtc: Automatically add new property 'dependencies' which contains a list of referenced phandles
Hi Alexander, On 12.05.2014 18:47, Alexander Holler wrote: > During the step from .dts to .dtb the information about dependcies contained > in the .dts through phandle references is lost. This makes it impossible to > use the binary blob to create a dependency graph without knowing the semantic > of all cell arrays. > > Therefor automatically add a new property called 'dependencies' to all nodes > which have phandle references in one of their properties. > > This new property will contain an array of phandles with one value for every > phandle referenced by other properties in the node. > > If such a property already exists (e.g. to manually add dependencies through > the .dts), the existing list will be expanded. > > Added phandles will be the phandle of either the referenced node itself (if > it has a property named 'compatible', or of the next parent of the referenced > node which as property named 'compatible'. This ensures only dependencies to > drivers will be added. > Sounds good. > References to phandles of parent or child nodes will not be added to this > property, because this information is already contained in the blob (in the > form of the tree itself). I wonder if we shouldn't be including them too for consistency related reasons, so we have all the necessary information in one place. References to child nodes are great recipes for cycles, though... No strong opinion, though, just an idea. > > No dependencies to disabled nodes will be added. > Same here. IMHO it might be wise to let the parsing entity (e.g. kernel) decide whether to ignore a dependency to disabled node or not. Otherwise, I like the simplicity of compile-time dependency list creation. Quite a nice work. Best regards, Tomasz -- 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/3] dma-mapping: pci: Add devm_ interface for pci_map_single
Signed-off-by: Eli Billauer
---
Documentation/driver-model/devres.txt |2 ++
include/asm-generic/pci-dma-compat.h | 17 +
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-model/devres.txt
index 2112a00..fea2c69 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -274,6 +274,8 @@ DMA
PCI
pcim_enable_device() : after success, all PCI ops become managed
pcim_pin_device(): keep PCI device enabled after release
+ pcim_map_single()
+ pcim_unmap_single()
IOMAP
devm_ioport_map()
diff --git a/include/asm-generic/pci-dma-compat.h
b/include/asm-generic/pci-dma-compat.h
index 1437b7d..444e598 100644
--- a/include/asm-generic/pci-dma-compat.h
+++ b/include/asm-generic/pci-dma-compat.h
@@ -113,4 +113,21 @@ static inline int pci_set_consistent_dma_mask(struct
pci_dev *dev, u64 mask)
}
#endif
+/*
+ * Managed DMA API
+ */
+
+static inline dma_addr_t
+pcim_map_single(struct pci_dev *hwdev, void *ptr, size_t size, int direction)
+{
+ return dmam_map_single(hwdev == NULL ? NULL : &hwdev->dev, ptr, size,
(enum dma_data_direction)direction);
+}
+
+static inline void
+pcim_unmap_single(struct pci_dev *hwdev, dma_addr_t dma_addr,
+size_t size, int direction)
+{
+ dmam_unmap_single(hwdev == NULL ? NULL : &hwdev->dev, dma_addr, size,
(enum dma_data_direction)direction);
+}
+
#endif
--
1.7.2.3
--
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] dma-mapping: Add devm_ interface for dma_map_single_attrs()
dmam_map_single_attrs() and dmam_unmap_single_attrs() replace the non-*_attrs
functions, which are implemented as defines instead.
The case of a non-NULL @attrs parameter has not been tested.
Suggested-by: Tejun Heo
Signed-off-by: Eli Billauer
---
Documentation/driver-model/devres.txt|2 +
drivers/base/dma-mapping.c | 43 +
include/asm-generic/dma-mapping-common.h |2 +
include/linux/dma-mapping.h | 10 ---
4 files changed, 41 insertions(+), 16 deletions(-)
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-model/devres.txt
index 13b8be0..2112a00 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -268,6 +268,8 @@ DMA
dmam_pool_destroy()
dmam_map_single()
dmam_unmap_single()
+ dmam_map_single_attrs()
+ dmam_unmap_single_attrs()
PCI
pcim_enable_device() : after success, all PCI ops become managed
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index db1c496..4e80db1 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
/*
* Managed DMA API
@@ -20,6 +21,7 @@ struct dma_devres {
void*vaddr;
dma_addr_t dma_handle;
enum dma_data_direction direction;
+ struct dma_attrs *attrs;
};
static void dmam_coherent_release(struct device *dev, void *res)
@@ -285,24 +287,29 @@ static void dmam_map_single_release(struct device *dev,
void *res)
{
struct dma_devres *this = res;
- dma_unmap_single(dev, this->dma_handle, this->size, this->direction);
+ dma_unmap_single_attrs(dev, this->dma_handle, this->size,
+ this->direction, this->attrs);
+
+ kfree(this->attrs);
}
/**
- * dmam_map_single - Managed dma_map_single()
+ * dmam_map_single_attrs - Managed dma_map_single_attrs()
* @dev: Device to map DMA region for
* @ptr: Pointer to region
* @size: Size to map
* @direction: The mapping's direction
+ * @attrs: Attributes associated with the DMA mapping
*
- * Managed dma_map_single(). The region mapped using this
+ * Managed dma_map_single_attrs(). The region mapped using this
* function will be automatically unmapped on driver detach.
*
* RETURNS:
* The DMA handle of the mapped region upon success, 0 otherwise.
*/
-dma_addr_t dmam_map_single(struct device *dev, void *ptr, size_t size,
- enum dma_data_direction direction)
+dma_addr_t dmam_map_single_attrs(struct device *dev, void *ptr, size_t size,
+enum dma_data_direction direction,
+struct dma_attrs *attrs)
{
struct dma_devres *dr;
@@ -312,8 +319,18 @@ dma_addr_t dmam_map_single(struct device *dev, void *ptr,
size_t size,
if (!dr)
return 0;
- dma_handle = dma_map_single(dev, ptr, size, direction);
+ if (attrs) {
+ dr->attrs = kmemdup(attrs, sizeof(*attrs), GFP_KERNEL);
+ if (!dr->attrs) {
+ devres_free(dr);
+ return 0;
+ }
+ } else
+ dr->attrs = NULL;
+
+ dma_handle = dma_map_single_attrs(dev, ptr, size, direction, attrs);
if (dma_mapping_error(dev, dma_handle)) {
+ kfree(dr->attrs);
devres_free(dr);
return 0;
}
@@ -327,23 +344,25 @@ dma_addr_t dmam_map_single(struct device *dev, void *ptr,
size_t size,
return dma_handle;
}
-EXPORT_SYMBOL(dmam_map_single);
+EXPORT_SYMBOL(dmam_map_single_attrs);
/**
- * dmam_unmap_single - Managed dma_unmap_single()
+ * dmam_unmap_single_attrs - Managed dma_unmap_single_attrs()
* @dev: Device to map DMA region for
* @dma_handle: DMA handle of the region to unmap
* @size: Size to unmap
* @direction: The mapping's direction
+ * @attrs: Attributes associated with the DMA mapping.
*
- * Managed dma_unmap_single().
+ * Managed dma_unmap_single_attrs().
*/
-void dmam_unmap_single(struct device *dev, dma_addr_t dma_handle,
- size_t size, enum dma_data_direction direction)
+void dmam_unmap_single_attrs(struct device *dev, dma_addr_t dma_handle,
+size_t size, enum dma_data_direction direction,
+struct dma_attrs *attrs)
{
struct dma_devres match_data = { size, NULL, dma_handle, direction };
WARN_ON(devres_release(dev, dmam_map_single_release, dmam_map_match,
&match_data));
}
-EXPORT_SYMBOL(dmam_unmap_single);
+EXPORT_SYMBOL(dmam_unmap_single_attrs);
diff --git a/include/asm-generic/dma-mapping-common.h
b/include/asm-generic/dma-mapping-common.h
index de8bf89..aaa7c68 100644
--- a/include/asm-generic/dma-mapping-common.h
+++ b/include/asm-generic/dma-mapping-common.h
@@ -175,6 +175,8 @@ dma_sync_s
[PATCH 1/3] dma-mapping: Add devm_ interface for dma_map_single()
dmam_map_single() and dmam_unmap_single() are the managed counterparts
for the respective dma_* functions.
Note that dmam_map_single() returns zero on failure, and not a value to
be handled by dma_mapping_error(): The error check is done by
dmam_map_single() to avoid the registration of a mapping that failed.
Signed-off-by: Eli Billauer
---
Documentation/driver-model/devres.txt |2 +
drivers/base/dma-mapping.c| 80 +
include/linux/dma-mapping.h |5 ++-
3 files changed, 86 insertions(+), 1 deletions(-)
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-model/devres.txt
index e1a2707..13b8be0 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -266,6 +266,8 @@ DMA
dmam_declare_coherent_memory()
dmam_pool_create()
dmam_pool_destroy()
+ dmam_map_single()
+ dmam_unmap_single()
PCI
pcim_enable_device() : after success, all PCI ops become managed
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 0ce39a3..db1c496 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -19,6 +19,7 @@ struct dma_devres {
size_t size;
void*vaddr;
dma_addr_t dma_handle;
+ enum dma_data_direction direction;
};
static void dmam_coherent_release(struct device *dev, void *res)
@@ -267,3 +268,82 @@ int dma_common_mmap(struct device *dev, struct
vm_area_struct *vma,
return ret;
}
EXPORT_SYMBOL(dma_common_mmap);
+
+static int dmam_map_match(struct device *dev, void *res, void *match_data)
+{
+ struct dma_devres *this = res, *match = match_data;
+
+ if (this->dma_handle == match->dma_handle) {
+ WARN_ON(this->size != match->size ||
+ this->direction != match->direction);
+ return 1;
+ }
+ return 0;
+}
+
+static void dmam_map_single_release(struct device *dev, void *res)
+{
+ struct dma_devres *this = res;
+
+ dma_unmap_single(dev, this->dma_handle, this->size, this->direction);
+}
+
+/**
+ * dmam_map_single - Managed dma_map_single()
+ * @dev: Device to map DMA region for
+ * @ptr: Pointer to region
+ * @size: Size to map
+ * @direction: The mapping's direction
+ *
+ * Managed dma_map_single(). The region mapped using this
+ * function will be automatically unmapped on driver detach.
+ *
+ * RETURNS:
+ * The DMA handle of the mapped region upon success, 0 otherwise.
+ */
+dma_addr_t dmam_map_single(struct device *dev, void *ptr, size_t size,
+ enum dma_data_direction direction)
+
+{
+ struct dma_devres *dr;
+ dma_addr_t dma_handle;
+
+ dr = devres_alloc(dmam_map_single_release, sizeof(*dr), GFP_KERNEL);
+ if (!dr)
+ return 0;
+
+ dma_handle = dma_map_single(dev, ptr, size, direction);
+ if (dma_mapping_error(dev, dma_handle)) {
+ devres_free(dr);
+ return 0;
+ }
+
+ dr->vaddr = ptr;
+ dr->dma_handle = dma_handle;
+ dr->size = size;
+ dr->direction = direction;
+
+ devres_add(dev, dr);
+
+ return dma_handle;
+}
+EXPORT_SYMBOL(dmam_map_single);
+
+/**
+ * dmam_unmap_single - Managed dma_unmap_single()
+ * @dev: Device to map DMA region for
+ * @dma_handle: DMA handle of the region to unmap
+ * @size: Size to unmap
+ * @direction: The mapping's direction
+ *
+ * Managed dma_unmap_single().
+ */
+void dmam_unmap_single(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction direction)
+{
+ struct dma_devres match_data = { size, NULL, dma_handle, direction };
+
+ WARN_ON(devres_release(dev, dmam_map_single_release, dmam_map_match,
+ &match_data));
+}
+EXPORT_SYMBOL(dmam_unmap_single);
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index fd4aee2..cdb14a8 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -233,7 +233,10 @@ static inline void dmam_release_declared_memory(struct
device *dev)
{
}
#endif /* ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY */
-
+dma_addr_t dmam_map_single(struct device *dev, void *ptr, size_t size,
+ enum dma_data_direction direction);
+void dmam_unmap_single(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction direction);
#ifndef CONFIG_HAVE_DMA_ATTRS
struct dma_attrs;
--
1.7.2.3
--
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] ntfs: Cleanup string initializations (char[] instead of char *)
Initializations like 'char *foo = "bar"' will create two variables: a static
string and a pointer (foo) to that static string. Instead 'char foo[] = "bar"'
will allocate only a declare a single variable and will end up in shorter
assembly (according to Jeff Garzik on the KernelJanitor's TODO list).
Signed-off-by: Manuel Schölling
---
fs/ntfs/inode.c |2 +-
fs/ntfs/super.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
index f47af5e..3975798 100644
--- a/fs/ntfs/inode.c
+++ b/fs/ntfs/inode.c
@@ -2368,7 +2368,7 @@ int ntfs_truncate(struct inode *vi)
ntfs_attr_search_ctx *ctx;
MFT_RECORD *m;
ATTR_RECORD *a;
- const char *te = " Leaving file length out of sync with i_size.";
+ const char te[] = " Leaving file length out of sync with i_size.";
int err, mp_size, size_change, alloc_change;
u32 attr_len;
diff --git a/fs/ntfs/super.c b/fs/ntfs/super.c
index 9de2491..eb2c195 100644
--- a/fs/ntfs/super.c
+++ b/fs/ntfs/super.c
@@ -676,7 +676,7 @@ not_ntfs:
static struct buffer_head *read_ntfs_boot_sector(struct super_block *sb,
const int silent)
{
- const char *read_err_str = "Unable to read %s boot sector.";
+ const char read_err_str[] = "Unable to read %s boot sector.";
struct buffer_head *bh_primary, *bh_backup;
sector_t nr_blocks = NTFS_SB(sb)->nr_blocks;
--
1.7.10.4
--
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/5] dma-mapping: Add devm_ interface for dma_map_single()
Hello Tejun,
On 17/05/14 00:08, Tejun Heo wrote:
Don't we wanna map the underlying operation - dma_map_single_attrs() -
instead?
I'll resubmit this patch promptly, with a follow-up patch for the diff
to implement dmam_map_single_attrs() instead. Plus a define-statement
for dmam_map_single(). I can't test the case of a non-NULL value for
@attrs however.
+ if (dma_mapping_error(dev, dma_handle)) {
+ devres_free(dr);
+ return 0;
Can't we just keep returning dma_handle? Even if that means invoking
->mapping_error() twice? It's yucky to have subtly different error
return especially because in most cases it won't fail.
Yucky it is indeed. There are however two problems with keeping the
existing API:
* What to do if devres_alloc() fails. How do I signal back an error? The
only way I can think of is returning zero. But if the caller should know
that zero means failure, I've already broken the API. I might as well
return zero for any kind of failure.
* It seems like a lot of dma_mapping_error() implementations always
return no-error, since the DMA mapping can't fail on specific
architectures. If callers use dma_mapping_error(), the possible
devres_alloc() failure will be missed.
By the way, where I've seen dma_mapping_error() doing something, it
checks for dma_handle == 0.
Submitting updated patches for the DMA mapping part soon.
Regards,
Eli
--
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] kref: warn on uninitialized kref
On Sat, 17 May 2014, Mateusz Guzik wrote:
> On Sat, May 17, 2014 at 06:53:17AM -0400, Mikulas Patocka wrote:
> > I found a memory leak in iSCSI target that was caused by kref initialized
> > to zero (the memory object was allocated with kzalloc, kref_init was not
> > called and kref_put_spinlock_irqsave was called which changed "0" to "-1"
> > and didn't free the object).
> >
> > Similar bugs may exist in other kernel areas, so I submit this patch that
> > adds a check to kref.h. If the value is zero or negative, we can assume
> > that it is uninitialized and we warn about it.
> >
> > Signed-off-by: Mikulas Patocka
> >
> > ---
> > include/linux/kref.h |4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > Index: linux-3.15-rc5/include/linux/kref.h
> > ===
> > --- linux-3.15-rc5.orig/include/linux/kref.h2013-07-02
> > 22:23:38.0 +0200
> > +++ linux-3.15-rc5/include/linux/kref.h 2014-05-16 18:56:18.0
> > +0200
> > @@ -69,7 +69,7 @@ static inline int kref_sub(struct kref *
> > void (*release)(struct kref *kref))
> > {
> > WARN_ON(release == NULL);
> > -
> > + WARN_ON_ONCE(atomic_read(&kref->refcount) <= 0);
> > if (atomic_sub_and_test((int) count, &kref->refcount)) {
> > release(kref);
> > return 1;
> > @@ -119,6 +119,7 @@ static inline int kref_put_spinlock_irqs
> > unsigned long flags;
> >
> > WARN_ON(release == NULL);
> > + WARN_ON_ONCE(atomic_read(&kref->refcount) <= 0);
> > if (atomic_add_unless(&kref->refcount, -1, 1))
> > return 0;
> > spin_lock_irqsave(lock, flags);
> > @@ -136,6 +137,7 @@ static inline int kref_put_mutex(struct
> > struct mutex *lock)
> > {
> > WARN_ON(release == NULL);
> > + WARN_ON_ONCE(atomic_read(&kref->refcount) <= 0);
> > if (unlikely(!atomic_add_unless(&kref->refcount, -1, 1))) {
> > mutex_lock(lock);
> > if (unlikely(!atomic_dec_and_test(&kref->refcount))) {
>
> This has a side effect of detecting some overputs, which is nice.
>
> However, could be made better if kref_sub checked that refs you want to
> take don't put the count below 0.
>
> i.e.
> WARN_ON(count > atomic_read(&kref->refcount));
>
> this also detects your original problem.
>
> --
> Mateusz Guzik
Good point. I'm sending the updated patch.
Mikulas
--
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 v2] kref: warn on uninitialized kref
I found a memory leak in iSCSI target that was caused by kref initialized
to zero (the memory object was allocated with kzalloc, kref_init was not
called and kref_put_spinlock_irqsave was called which changed "0" to "-1"
and didn't free the object).
Similar bugs may exist in other kernel areas, so I submit this patch that
adds a check to kref.h. If the value is zero or negative, we can assume
that it is uninitialized and we warn about it.
Signed-off-by: Mikulas Patocka
---
include/linux/kref.h |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-3.15-rc5/include/linux/kref.h
===
--- linux-3.15-rc5.orig/include/linux/kref.h2014-05-16 19:00:18.0
+0200
+++ linux-3.15-rc5/include/linux/kref.h 2014-05-17 13:19:31.0 +0200
@@ -69,7 +69,7 @@ static inline int kref_sub(struct kref *
void (*release)(struct kref *kref))
{
WARN_ON(release == NULL);
-
+ WARN_ON_ONCE(atomic_read(&kref->refcount) < (int)count);
if (atomic_sub_and_test((int) count, &kref->refcount)) {
release(kref);
return 1;
@@ -119,6 +119,7 @@ static inline int kref_put_spinlock_irqs
unsigned long flags;
WARN_ON(release == NULL);
+ WARN_ON_ONCE(atomic_read(&kref->refcount) <= 0);
if (atomic_add_unless(&kref->refcount, -1, 1))
return 0;
spin_lock_irqsave(lock, flags);
@@ -136,6 +137,7 @@ static inline int kref_put_mutex(struct
struct mutex *lock)
{
WARN_ON(release == NULL);
+ WARN_ON_ONCE(atomic_read(&kref->refcount) <= 0);
if (unlikely(!atomic_add_unless(&kref->refcount, -1, 1))) {
mutex_lock(lock);
if (unlikely(!atomic_dec_and_test(&kref->refcount))) {
--
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: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Thu, 2014-05-15 at 21:35 -0700, Greg Kroah-Hartman wrote: > On Fri, May 16, 2014 at 01:49:59AM +, Serge Hallyn wrote: > > > I think having to pick and choose what device nodes you want in a > > > container is a good thing. Becides, you would have to do the same thing > > > in the kernel anyway, what's wrong with userspace making the decision > > > here, especially as it knows exactly what it wants to do much more so > > > than the kernel ever can. > > > > For 'real' devices that sounds sensible. The thing about loop devices > > is that we simply want to allow a container to say "give me a loop > > device to use" and have it receive a unique loop device (or 3), without > > having to pre-assign them. I think that would be cleaner to do using > > a pseudofs and loop-control device, rather than having to have a > > daemon in userspace on the host farming those out in response to > > some, I don't know, dbus request? > I agree that loop devices would be nice to have in a container, and that > the existing loop interface doesn't really lend itself to that. So > create a new type of thing that acts like a loop device in a container. > But don't try to mess with the whole driver core just for a single type > of device. Yeah, a lot of dynamic devices (like serial devices) can be handled in user space with the proviso that we could use some way to tickle udev and hotplug in the container with events. But the loop device is the real ugly duckling here. It's a unique case of an on-demand device with a shared control device that's not really hot-plug and not really deterministic enough to be handled purely in user space. It presents unique challenges unto itself. Makes sense to me. > greg k-h Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [Patch V2 5/9] I2C: Add smbus quick read/write helper function
On 05/17/2014 05:41 PM, Wolfram Sang wrote: On Mon, Apr 28, 2014 at 10:27:44PM +0800, Lan Tianyu wrote: Add i2c_smbus_quick_write/read() helper function. These will be used in the implementation of i2c ACPI address space handler. Reviewed-by: Mika Westerberg Signed-off-by: Lan Tianyu We had such a function once but removed because of no users. Please check 67c2e66571c383404a5acd08189194da660da942 what it takes to bring them back. Especially missing are documentation updates... +s32 i2c_smbus_quick_write(const struct i2c_client *client) ... and I like the original function much better. 1) It is named *_write_quick which follows other function name patterns 2) It uses a parameter for the r/w bit. Make sense to me, since this bit is the information we send to the device. quick_read doesn't make sense to me. We don't receive a bit from the device. Hi Wolfram: Great thanks for your review. Ok. I will follow commit 67c2e665 to bring i2c_smbus_write_quick(struct i2c_client *client, u8 value) back. BTW, how about i2c_probe_func_quick_read()? Should we replace it with the original i2c_smbus_write_quick()? -- 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: as102: replace custom dprintk() with dev_dbg()
don't reinvent dev_dbg(). use the common kernel coding style.
Signed-off-by: Martin Kepplinger
---
this applies to next-20140516.
drivers/staging/media/as102/as102_drv.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/as102/as102_drv.c
b/drivers/staging/media/as102/as102_drv.c
index 09d64cd..99c3ed93 100644
--- a/drivers/staging/media/as102/as102_drv.c
+++ b/drivers/staging/media/as102/as102_drv.c
@@ -74,7 +74,8 @@ static void as102_stop_stream(struct as102_dev_t *dev)
return;
if (as10x_cmd_stop_streaming(bus_adap) < 0)
- dprintk(debug, "as10x_cmd_stop_streaming failed\n");
+ dev_dbg(&dev->bus_adap.usb_dev->dev,
+ "as10x_cmd_stop_streaming failed\n");
mutex_unlock(&dev->bus_adap.lock);
}
@@ -112,14 +113,16 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
int ret = -EFAULT;
if (mutex_lock_interruptible(&dev->bus_adap.lock)) {
- dprintk(debug, "mutex_lock_interruptible(lock) failed !\n");
+ dev_dbg(&dev->bus_adap.usb_dev->dev,
+ "amutex_lock_interruptible(lock) failed !\n");
return -EBUSY;
}
switch (onoff) {
case 0:
ret = as10x_cmd_del_PID_filter(bus_adap, (uint16_t) pid);
- dprintk(debug, "DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n",
+ dev_dbg(&dev->bus_adap.usb_dev->dev,
+ "DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n",
index, pid, ret);
break;
case 1:
@@ -131,7 +134,7 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
filter.pid = pid;
ret = as10x_cmd_add_PID_filter(bus_adap, &filter);
- dprintk(debug,
+ dev_dbg(&dev->bus_adap.usb_dev->dev,
"ADD_PID_FILTER([%02d -> %02d], 0x%04x) ret = %d\n",
index, filter.idx, filter.pid, ret);
break;
--
1.7.10.4
--
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] Fix for possible null pointer dereference in node.c
Okay, everyone agrees with Dan..? I have made a new patch, which does not check if hnode is NULL. Best regards Rickard Strandqvist 2014-05-16 0:43 GMT+02:00 Dan Carpenter : > On Thu, May 15, 2014 at 11:53:53PM +0200, Rickard Strandqvist wrote: >> There is otherwise a risk of a possible null pointer dereference. >> > > None of the callers pass in a NULL hnode so there isn't actually a NULL > dereference here. You could just remove the check. > > regards, > dan carpenter > From 5986593f49044f1c4faef09b1e4db3ed8ec557d3 Mon Sep 17 00:00:00 2001 From: Rickard Strandqvist Date: Sun, 11 May 2014 18:51:42 +0200 Subject: [PATCH] staging: tidspridge: node.c: fix for possible null pointer dereference Removde unnecessary check for null pointer. Was largely found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist --- drivers/staging/tidspbridge/rmgr/node.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/tidspbridge/rmgr/node.c b/drivers/staging/tidspbridge/rmgr/node.c index 9d3044a..d918f7f 100644 --- a/drivers/staging/tidspbridge/rmgr/node.c +++ b/drivers/staging/tidspbridge/rmgr/node.c @@ -2365,8 +2365,6 @@ static void delete_node(struct node_object *hnode, (struct proc_object *)hnode->processor; #endif int status; - if (!hnode) - goto func_end; hnode_mgr = hnode->node_mgr; if (!hnode_mgr) goto func_end; -- 1.7.10.4
Re: [PATCH 2/2] regulator: s2mpa01: Fix accidental enable of buck4 ramp delay
On Mon, May 05, 2014 at 05:10:03PM +0200, Krzysztof Kozlowski wrote: > S2MPA01 supports enabling/disabling ramp delay only for buck[1234]. > Other bucks have ramp delay enabled always. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 1/2] regulator: s2mps11: Fix accidental enable of buck6 ramp delay
On Mon, May 05, 2014 at 05:10:02PM +0200, Krzysztof Kozlowski wrote: > S2MPS11 supports enabling/disabling ramp delay only for buck[2346]. > Other bucks have ramp delay enabled always. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH v2 3/3] regulator: s2mpa01: Use rdev_get_id() to access id of regulator
On Tue, May 06, 2014 at 08:37:38AM +0200, Krzysztof Kozlowski wrote: > Use regulator API rdev_get_id() to access id of regulator. Applied, thanks (I did actually apply the v2 of the first two, I just replied to the wrong version in my mailbox). signature.asc Description: Digital signature
[PATCH] ia64: remove check for CONFIG_IA64_FW_EMU
The config macro CONFIG_IA64_FW_EMU briefly appeared in the v2.3 development cycle. It would apparently have allowed to emulate "PAL/SAL/EFI firmware". It was abandoned before v2.4.0. Finally remove its last traces. Signed-off-by: Paul Bolle --- Untested. arch/ia64/kernel/head.S | 5 - 1 file changed, 5 deletions(-) diff --git a/arch/ia64/kernel/head.S b/arch/ia64/kernel/head.S index a4acddad0c78..d047701bf513 100644 --- a/arch/ia64/kernel/head.S +++ b/arch/ia64/kernel/head.S @@ -437,11 +437,6 @@ num_hypervisor_hooks = (. - hypervisor_setup_hooks) / 8 // This is executed by the bootstrap processor (bsp) only: -#ifdef CONFIG_IA64_FW_EMU - // initialize PAL & SAL emulator: - br.call.sptk.many rp=sys_fw_init -.ret1: -#endif br.call.sptk.many rp=start_kernel .ret2: addl r3=@ltoff(halt_msg),gp ;; -- 1.9.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: [PATCH 1/5] workqueue: Allow changing attributions of ordered workqueues
On Fri, May 16, 2014 at 04:12:25PM -0400, Tejun Heo wrote:
> Hello,
>
> On Fri, May 16, 2014 at 06:16:51PM +0200, Frederic Weisbecker wrote:
> > From: Lai Jiangshan
> >
> > Changing the attributions of a workqueue imply the addition of new pwqs
> > to replace the old ones. But the current implementation doesn't handle
> > ordered workqueues because they can't carry multi-pwqs without breaking
> > ordering. Hence ordered workqueues currently aren't allowed to call
> > apply_workqueue_attrs().
> ...
> > Signed-off-by: Lai Jiangshan
> > Cc: Christoph Lameter
> > Cc: Kevin Hilman
> > Cc: Lai Jiangshan
> > Cc: Mike Galbraith
> > Cc: Paul E. McKenney
> > Cc: Tejun Heo
> > Cc: Viresh Kumar
> > Signed-off-by: Frederic Weisbecker
>
> Do you mind touching up the description and comment a bit as it's
> going through you? They have gotten a lot better (kudos to Lai :) but
> I still feel the need to touch them up a bit before applying. I'd
> really appreciate if you can do it as part of your series.
Sure, I mean I actually seldom apply other's patches as is. I actually edited,
reworded and reorganized this changelog a lot. Same for some comments.
But since I was still not sure that the direction was the final one, I probably
left some parts with light explanations.
I'll have a second pass, just don't hesitate to point me out comments or
anything
that need improvement.
>
> > diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> > index c3f076f..c68e84f 100644
> > --- a/kernel/workqueue.c
> > +++ b/kernel/workqueue.c
> > @@ -1355,8 +1355,16 @@ retry:
> > * If @work was previously on a different pool, it might still be
> > * running there, in which case the work needs to be queued on that
> > * pool to guarantee non-reentrancy.
> > +*
> > +* We guarantee that only one pwq is active on an ordered workqueue.
> > +* That alone enforces non-reentrancy for works. So ordered works don't
>
> Let's use "work items" instead of "works".
Ok.
>
> > +* need to be requeued to their previous pool. Not to mention that
> > +* an ordered work requeing itself over and over on the same pool may
> > +* prevent a pwq from being released in case of a pool switch. The
> > +* newest pool in that case couldn't switch in and its pending works
> > +* would starve.
> > */
> > - last_pool = get_work_pool(work);
> > + last_pool = wq->flags & __WQ_ORDERED ? NULL : get_work_pool(work);
> > if (last_pool && last_pool != pwq->pool) {
> > struct worker *worker;
>
> I'm not a big fan of the fact that ordered queues need to be handled
> differently when queueing, but as the code is currently written, this
> is pretty much necessary to maintain execution order, right?
>
> Otherwise, you end up with requeueing work items targeting the pwq it
> was executing on and new ones targeting the newest one screwing up the
> ordering. I think that'd be a lot more important to note in the
> comment. This is a correctness measure. Back-to-back requeueing
> being affected by this is just a side-effect.
In the case of ordered workqueues it actually doesn't matter much in
term of ordering. But it's needed when pwqs are replaced (as it happens
in apply_workqueue_attrs(). We must make sure works requeueing themselves
don't always requeue to the old pwq otherwise it will never be able to
switch and be released. Also the next work items will be queued on the next
pwq but this one will never be able to run due to the old workqueue still
being used by the item requeing itself. So we also risk starvation on the
new workqueue.
But the ordering itself is actually fine for ordered workqueue. It's actually
enforced by the fact that only one pwq can run at a time for a given workqueue.
OTOH non-ordered workqueues still depend on the above machinery to ensure
ordering at the work item scope. Which is what we rather call re-entrancy.
So I think the comment is not misleading. But it may deserve to be rephrased.
>
> Also, can you please use plain if/else instead of "?:"? This isn't a
> simple logic and I don't think compressing it with ?: is a good idea.
Agreed, will do.
>
> > @@ -3708,6 +3712,13 @@ static void rcu_free_pwq(struct rcu_head *rcu)
> > container_of(rcu, struct pool_workqueue, rcu));
> > }
> >
> > +static struct pool_workqueue *oldest_pwq(struct workqueue_struct *wq)
> > +{
> > + return list_last_entry(&wq->pwqs, struct pool_workqueue, pwqs_node);
> > +}
> > +
> > +static void pwq_adjust_max_active(struct pool_workqueue *pwq);
> > +
> > /*
> > * Scheduled on system_wq by put_pwq() when an unbound pwq hits zero refcnt
> > * and needs to be destroyed.
> > @@ -3723,14 +3734,12 @@ static void pwq_unbound_release_workfn(struct
> > work_struct *work)
> > if (WARN_ON_ONCE(!(wq->flags & WQ_UNBOUND)))
> > return;
> >
> > - /*
> > -* Unlink @pwq. Synchronization against wq->mutex isn't strictly
> > -* necessary on relea
Re: [PATCH v2] kref: warn on uninitialized kref
On 05/17/14 14:38, Mikulas Patocka wrote:
> I found a memory leak in iSCSI target that was caused by kref initialized
> to zero (the memory object was allocated with kzalloc, kref_init was not
> called and kref_put_spinlock_irqsave was called which changed "0" to "-1"
> and didn't free the object).
>
> Similar bugs may exist in other kernel areas, so I submit this patch that
> adds a check to kref.h. If the value is zero or negative, we can assume
> that it is uninitialized and we warn about it.
>
> Signed-off-by: Mikulas Patocka
>
> ---
> include/linux/kref.h |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> Index: linux-3.15-rc5/include/linux/kref.h
> ===
> --- linux-3.15-rc5.orig/include/linux/kref.h 2014-05-16 19:00:18.0
> +0200
> +++ linux-3.15-rc5/include/linux/kref.h 2014-05-17 13:19:31.0
> +0200
> @@ -69,7 +69,7 @@ static inline int kref_sub(struct kref *
>void (*release)(struct kref *kref))
> {
> WARN_ON(release == NULL);
> -
> + WARN_ON_ONCE(atomic_read(&kref->refcount) < (int)count);
> if (atomic_sub_and_test((int) count, &kref->refcount)) {
> release(kref);
> return 1;
> @@ -119,6 +119,7 @@ static inline int kref_put_spinlock_irqs
> unsigned long flags;
>
> WARN_ON(release == NULL);
> + WARN_ON_ONCE(atomic_read(&kref->refcount) <= 0);
> if (atomic_add_unless(&kref->refcount, -1, 1))
> return 0;
> spin_lock_irqsave(lock, flags);
> @@ -136,6 +137,7 @@ static inline int kref_put_mutex(struct
>struct mutex *lock)
> {
> WARN_ON(release == NULL);
> + WARN_ON_ONCE(atomic_read(&kref->refcount) <= 0);
> if (unlikely(!atomic_add_unless(&kref->refcount, -1, 1))) {
> mutex_lock(lock);
> if (unlikely(!atomic_dec_and_test(&kref->refcount))) {
This patch adds two conditional branches and one atomic read to
kref_sub(). What is the performance impact of this patch on kernel code
that uses kref_put() in the hot path ? Has it been considered to enable
the newly added code only if a CONFIG_DEBUG_* macro has been set ?
Bart.
--
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 6/9] I2C: Add smbus word/block process call helper function
On 05/17/2014 06:21 PM, Wolfram Sang wrote:
On Mon, Apr 28, 2014 at 10:27:45PM +0800, Lan Tianyu wrote:
Add i2c_smbus_word/block_proc_call() helper function. These will be used
in the implementation of i2c ACPI address space handler.
Reviewed-by: Mika Westerberg
Signed-off-by: Lan Tianyu
---
drivers/i2c/i2c-core.c | 56 ++
include/linux/i2c.h| 4
2 files changed, 60 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 3bf0048..638befd 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -2306,6 +2306,30 @@ s32 i2c_smbus_write_word_data(const struct i2c_client
*client, u8 command,
EXPORT_SYMBOL(i2c_smbus_write_word_data);
/**
+ * i2c_smbus_word_proc_call - SMBus "word proc call" protocol
+ * @client: Handle to slave device
+ * @command: Byte interpreted by slave
+ * @value: 16-bit "word" being written
+ *
+ * This executes the SMBus "word proc all" protocol, returning negative errno
+ * else a 16-bit unsigned "word" received from the device.
+ */
+s32 i2c_smbus_word_proc_call(const struct i2c_client *client, u8 command,
+ u16 value)
+{
+ union i2c_smbus_data data;
+ int status;
+
+ data.word = value;
+ status = i2c_smbus_xfer(client->adapter, client->addr, client->flags,
+ I2C_SMBUS_READ, command,
+ I2C_SMBUS_PROC_CALL, &data);
+
+ return (status < 0) ? status : data.word;
+}
+EXPORT_SYMBOL(i2c_smbus_word_proc_call);
+
+/**
Same as smbus_quick function before, documentation updates are missing.
Also similar, we had such a function before which was removed due to no
users? It looks very much like the function here, so we should stick to
the old naming IMO. Is it the old one? Such information would be nice
since it affects reviewing.
Yes, there was an old function and commit c8110933 removed it. Sorry, I didn't
that before. I will bring the old one back.
* i2c_smbus_read_block_data - SMBus "block read" protocol
* @client: Handle to slave device
* @command: Byte interpreted by slave
@@ -2362,6 +2386,38 @@ s32 i2c_smbus_write_block_data(const struct i2c_client
*client, u8 command,
}
EXPORT_SYMBOL(i2c_smbus_write_block_data);
+/**
+ * i2c_smbus_block_proc_call - SMBus "block write" protocol
+ * @client: Handle to slave device
+ * @command: Byte interpreted by slave
+ * @length: Size of data block; SMBus allows at most 32 bytes
+ * @values: Byte array which will be written.
+ *
+ * This executes the SMBus "block proc call" protocol, returning negative errno
+ * else the number of read bytes.
+ */
+s32 i2c_smbus_block_proc_call(const struct i2c_client *client, u8 command,
+ u8 length, u8 *values)
Please rename to "i2c_smbus_block_process_call" as the old function was
named. Needs documentation updates.
+ if (length > I2C_SMBUS_BLOCK_MAX)
+ length = I2C_SMBUS_BLOCK_MAX;
I think we should return an error here.
Ok.
BTW what were your test scenarios for these functions and smbus quick?
From ACPI spec, Read/Write quick and Word/Block process call protocol will be
used by Bios ACPI code. But so far, I don't find such machines. So these
functions has not been tested.
--
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: media: as102: replace custom dprintk() with dev_dbg()
you forget to remove debug parameter itself.
Antti
On 05/17/2014 04:16 PM, Martin Kepplinger wrote:
don't reinvent dev_dbg(). use the common kernel coding style.
Signed-off-by: Martin Kepplinger
---
this applies to next-20140516.
drivers/staging/media/as102/as102_drv.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/as102/as102_drv.c
b/drivers/staging/media/as102/as102_drv.c
index 09d64cd..99c3ed93 100644
--- a/drivers/staging/media/as102/as102_drv.c
+++ b/drivers/staging/media/as102/as102_drv.c
@@ -74,7 +74,8 @@ static void as102_stop_stream(struct as102_dev_t *dev)
return;
if (as10x_cmd_stop_streaming(bus_adap) < 0)
- dprintk(debug, "as10x_cmd_stop_streaming failed\n");
+ dev_dbg(&dev->bus_adap.usb_dev->dev,
+ "as10x_cmd_stop_streaming failed\n");
mutex_unlock(&dev->bus_adap.lock);
}
@@ -112,14 +113,16 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
int ret = -EFAULT;
if (mutex_lock_interruptible(&dev->bus_adap.lock)) {
- dprintk(debug, "mutex_lock_interruptible(lock) failed !\n");
+ dev_dbg(&dev->bus_adap.usb_dev->dev,
+ "amutex_lock_interruptible(lock) failed !\n");
return -EBUSY;
}
switch (onoff) {
case 0:
ret = as10x_cmd_del_PID_filter(bus_adap, (uint16_t) pid);
- dprintk(debug, "DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n",
+ dev_dbg(&dev->bus_adap.usb_dev->dev,
+ "DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n",
index, pid, ret);
break;
case 1:
@@ -131,7 +134,7 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
filter.pid = pid;
ret = as10x_cmd_add_PID_filter(bus_adap, &filter);
- dprintk(debug,
+ dev_dbg(&dev->bus_adap.usb_dev->dev,
"ADD_PID_FILTER([%02d -> %02d], 0x%04x) ret = %d\n",
index, filter.idx, filter.pid, ret);
break;
--
http://palosaari.fi/
--
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 2/9] dt: deps: dependency based device creation
Hi, On 14.05.2014 16:05, Grant Likely wrote: > On Mon, 12 May 2014 18:47:53 +0200, Alexander Holler > wrote: >> Use the properties named 'dependencies' in binary device tree blobs to build >> a dependency based initialization order for platform devices and drivers. >> >> This is done by building a directed acyclic graph using an adjacency list >> and doing a topological sort to retrieve the order in which devices/drivers >> should be created/initialized. >> >> Signed-off-by: Alexander Holler > > Hi Alexander, > > Thanks for looking at this. It is a difficult problem. I've made > comments below, but first I've got some general comments... > > First, I'm going to be very cautious about this. It is a complicated > piece of code making the device initialization process a lot more > complicated than it already is. I'm the first one to admit that deferred > probe handles the problem in quite a naive manner, but it is simple, > correct (when drivers support deferred probe) and easy to audit. This > series digs deep into the registration order of *both* devices and > drivers which gives me the heebee jeebees. > > Personally, I think the parts of this patch that manipulate the device > registration > order is entirely the wrong way to handle it. If anything, I would say > continue to register the devices, even if the dependencies are unmet. > Instead, I would focus on the driver core (drivers/base) to catch > device probe attempts when a known dependency is not met, remember it, > and perform the probe after the other driver shows up. That is also > going to be a complicated bit of code, but it works for every kind of > device, not just platform_devices, and has far less impact on the > platform setup code. Grant, I tend to disagree with you on this. While Alexander's solution has certain flaws (that I'm going to list further in my reply), I also believe that an approach based on device registration order is most likely the way to go. As compared to other possible approaches, here is the list of advantages I can see (in random order): 1) If compared with resource-based approach, when you detect dependencies at runtime, based on existing resource specifiers (GPIOs, clocks, etc.), you don't need to change anything in the implementation whenever a new kind of resources is introduced. Moreover, there is no need to make device probing code aware of any resources or dependencies, because all you need to do is to register devices in certain order, as defined by precompiled dependency lists. 2) If implemented properly, it helps solving problem of binding proper driver to a device with multiple compatible strings. Current way of handling this by Linux is _broken_, because the device will be bound to first driver that shows up and contains matching compatible string in its match table. Notice that this way the whole idea of having multiple compatible strings specified from most specific to most generic is made useless. Now you may wonder how both problems relate. Basically in both cases you need to wait until drivers for devices are available (e.g. registered in system-wide list), either to guarantee that registering a device means probing it (in first case) or to look through the list of available drivers and select the one that is a best match (in second case). 3) DeviceTree is not the only firmware "interface" supported by Linux and so I'd be careful with pushing this into generic driver core that is also shared with board files and ACPI and possibly something else I'm not aware of. Moreover, I think the existing driver core is already quite complex and complicating it even more might not be the best idea, unless really the only option. 4) This approach is far less complicated than anything mentioned above. What's so complicated in creating a graph of devices and registering them in certain order? > > BTW, this has to be able to work at the level of struct device instead > of struct platform_device. There are far more kinds of devices than just > platform_device, and they all have the same problem. Agreed. > Also, may I suggest that the more pieces that you can break this series > up into, the greater chance you'll have of getting a smaller subset > merged earlier if it can be proven to be useful on its own. Agreed. It is usually a good idea to separate things that could live on their own and be useful. Now, I'll spare myself from judging the code, as until we get an accepted design, I don't think there is any point in discussing about implementation details, not even mentioning things like coding style (which is important, but not when much of the code might still be rewritten completely). OK, so I mentioned above what I like in this kind of approach. Now let's move to what I don't like. I think the part that alters driver registration and initcalls isn't really necessary. With current code, we can see that initcalls themselves (not driver code in terms of driver model) are already well ordered, as
Re: [PATCH] gpio: Add support for Intel SoC PMIC (Crystal Cove)
On Thu, May 15, 2014 at 12:44 AM, Zhu, Lejun wrote:
> Devices based on Intel SoC products such as Baytrail have a Power
> Management IC. In the PMIC there are subsystems for voltage regulation,
> A/D conversion, GPIO and PWMs. The PMIC in Baytrail-T platform is called
> Crystal Cove.
>
> This patch adds support for the GPIO function in Crystal Cove.
>
> Signed-off-by: Yang, Bin
> Signed-off-by: Zhu, Lejun
> ---
> drivers/gpio/Kconfig| 9 ++
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-crystalcove.c | 323
>
> 3 files changed, 333 insertions(+)
> create mode 100644 drivers/gpio/gpio-crystalcove.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index a86c49a..95bb5a0 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -440,6 +440,15 @@ config GPIO_ARIZONA
> help
> Support for GPIOs on Wolfson Arizona class devices.
>
> +config GPIO_INTEL_SOC_PMIC
> + bool "GPIO on Intel SoC PMIC"
> + depends on INTEL_SOC_PMIC
> + help
> + Support for GPIO pins on Intel SoC PMIC, such as Crystal
> + Cove.
> + Say Y if you have a tablet with Intel SoC (e.g. Baytrail)
> + inside.
> +
> config GPIO_LP3943
> tristate "TI/National Semiconductor LP3943 GPIO expander"
> depends on MFD_LP3943
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 6309aff..5380608 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_GPIO_F7188X) += gpio-f7188x.o
> obj-$(CONFIG_GPIO_GE_FPGA) += gpio-ge.o
> obj-$(CONFIG_GPIO_GRGPIO) += gpio-grgpio.o
> obj-$(CONFIG_GPIO_ICH) += gpio-ich.o
> +obj-$(CONFIG_GPIO_INTEL_SOC_PMIC) += gpio-crystalcove.o
> obj-$(CONFIG_GPIO_IOP) += gpio-iop.o
> obj-$(CONFIG_GPIO_IT8761E) += gpio-it8761e.o
> obj-$(CONFIG_GPIO_JANZ_TTL)+= gpio-janz-ttl.o
> diff --git a/drivers/gpio/gpio-crystalcove.c b/drivers/gpio/gpio-crystalcove.c
> new file mode 100644
> index 000..974f9b8
> --- /dev/null
> +++ b/drivers/gpio/gpio-crystalcove.c
> @@ -0,0 +1,323 @@
> +/*
> + * gpio-crystalcove.c - Intel Crystal Cove GPIO Driver
> + *
> + * Copyright (C) 2012, 2014 Intel Corporation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Author: Yang, Bin
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define NUM_GPIO 16
> +
> +#define UPDATE_TYPE(1 << 0)
> +#define UPDATE_MASK(1 << 1)
> +
> +#define GPIO0IRQ 0x0b
> +#define GPIO1IRQ 0x0c
> +#define MGPIO0IRQS00x19
> +#define MGPIO1IRQS00x1a
> +#define MGPIO0IRQSX0x1b
> +#define MGPIO1IRQSX0x1c
> +#define GPIO0P0CTLO0x2b
> +#define GPIO0P0CTLI0x33
> +#define GPIO1P0CTLO0x3b
> +#define GPIO1P0CTLI0x43
> +
> +#define CTLI_INTCNT_NE (1 << 1)
> +#define CTLI_INTCNT_PE (2 << 1)
> +#define CTLI_INTCNT_BE (3 << 1)
> +
> +#define CTLO_DIR_OUT (1 << 5)
> +#define CTLO_DRV_CMOS (0 << 4)
> +#define CTLO_DRV_OD(1 << 4)
> +#define CTLO_DRV_REN (1 << 3)
> +#define CTLO_RVAL_2KDW (0)
> +#define CTLO_RVAL_2KUP (1 << 1)
> +#define CTLO_RVAL_50KDW(2 << 1)
> +#define CTLO_RVAL_50KUP(3 << 1)
> +
> +#define CTLO_INPUT_DEF (CTLO_DRV_CMOS | CTLO_DRV_REN | CTLO_RVAL_2KUP)
> +#define CTLO_OUTPUT_DEF(CTLO_DIR_OUT | CTLO_INPUT_DEF)
> +
> +struct crystalcove_gpio {
> + struct mutexbuslock; /* irq_bus_lock */
> + struct gpio_chipchip;
> + int irq;
> + int irq_base;
> + int update;
> + int trigger_type;
> + int irq_mask;
> +};
> +static struct crystalcove_gpio gpio_info;
> +
> +static void __crystalcove_irq_mask(int gpio, int mask)
> +{
> + u8 mirqs0 = gpio < 8 ? MGPIO0IRQS0 : MGPIO1IRQS0;
> + int offset = gpio < 8 ? gpio : gpio - 8;
> +
> + if (mask)
> + intel_soc_pmic_setb(mirqs0, 1 << offset);
> + else
> + intel_soc_pmic_clearb(mirqs0, 1 << offset);
> +}
> +
> +static void __crystalcove_irq_type(int gpio, int type)
> +{
> + u8 ctli = gpio < 8 ? GPIO0P0CTLI + gpio
[PATCH] pinctrl: Cleanup string initializations (char[] instead of char *)
Initializations like 'char *foo = "bar"' will create two variables: a static
string and a pointer (foo) to that static string. Instead 'char foo[] = "bar"'
will declare a single variable and will end up in shorter
assembly (according to Jeff Garzik on the KernelJanitor's TODO list).
Signed-off-by: Manuel Schölling
---
drivers/pinctrl/pinctrl-mxs.c|6 +++---
drivers/pinctrl/pinctrl-single.c |4 ++--
drivers/pinctrl/pinctrl-tegra.c |2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-mxs.c b/drivers/pinctrl/pinctrl-mxs.c
index 40c76f2..cd4215e 100644
--- a/drivers/pinctrl/pinctrl-mxs.c
+++ b/drivers/pinctrl/pinctrl-mxs.c
@@ -351,7 +351,7 @@ static int mxs_pinctrl_parse_group(struct platform_device
*pdev,
struct mxs_pinctrl_data *d = platform_get_drvdata(pdev);
struct mxs_group *g = &d->soc->groups[idx];
struct property *prop;
- const char *propname = "fsl,pinmux-ids";
+ const char propname[] = "fsl,pinmux-ids";
char *group;
int length = strlen(np->name) + SUFFIX_LEN;
u32 val, i;
@@ -399,8 +399,8 @@ static int mxs_pinctrl_probe_dt(struct platform_device
*pdev,
struct device_node *np = pdev->dev.of_node;
struct device_node *child;
struct mxs_function *f;
- const char *gpio_compat = "fsl,mxs-gpio";
- const char *fn, *fnull = "";
+ const char gpio_compat[] = "fsl,mxs-gpio";
+ const char *fn, fnull[] = "";
int i = 0, idxf = 0, idxg = 0;
int ret;
u32 val;
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 2960557..a3ed99f 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1561,8 +1561,8 @@ static struct of_device_id pcs_of_match[];
static int pcs_add_gpio_func(struct device_node *node, struct pcs_device *pcs)
{
- const char *propname = "pinctrl-single,gpio-range";
- const char *cellname = "#pinctrl-single,gpio-range-cells";
+ const char propname[] = "pinctrl-single,gpio-range";
+ const char cellname[] = "#pinctrl-single,gpio-range-cells";
struct of_phandle_args gpiospec;
struct pcs_gpiofunc_range *range;
int ret, i;
diff --git a/drivers/pinctrl/pinctrl-tegra.c b/drivers/pinctrl/pinctrl-tegra.c
index 6545809..43eeb1b 100644
--- a/drivers/pinctrl/pinctrl-tegra.c
+++ b/drivers/pinctrl/pinctrl-tegra.c
@@ -576,7 +576,7 @@ static void tegra_pinconf_config_dbg_show(struct
pinctrl_dev *pctldev,
{
enum tegra_pinconf_param param = TEGRA_PINCONF_UNPACK_PARAM(config);
u16 arg = TEGRA_PINCONF_UNPACK_ARG(config);
- const char *pname = "unknown";
+ const char pname[] = "unknown";
int i;
for (i = 0; i < ARRAY_SIZE(cfg_params); i++) {
--
1.7.10.4
--
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/
dm-writeboost: Progress Report
Hi DM Guys, I will share the latest progress report about Writeboost. 1. Where we are working on now Kernel code --- First of all, Writeboost is now merged into thin-dev branch in Joe's tree. URL: https://github.com/jthornber/linux-2.6 Testing --- Testing for Writeboost is merged into master branch in Joe's device-mapper-test-suite (or dmts). URL: https://github.com/jthornber/device-mapper-test-suite Docs You can access to the lastest documentations here. URL: https://github.com/akiradeveloper/dm-writeboost/tree/develop/doc - writeboost.txt : Will be merged into Documentation/ but is not merged yet. It will be really thankful if you help me improve the sentences (I am not native). Aside this, - writeboost-ja.txt : For Japanese forks - writeboost.pdf : Very first introduction slides to Writeboost DOWNLOAD: https://github.com/akiradeveloper/dm-writeboost/blob/develop/doc/writeboost.pdf?raw=true 2. New feature from the last progress report The kernel code wasn't changed drastically but included many important fixes (most of them are revealed after tested upon Joe's tree and dmts. I recommend other target developers test their codes on dmts). Aside the fixes two major new features will be introduced. Sorted write back - In April, a patch to introduce sorting writes for dm-crypt was introduced. I thought it is also useful for Writeboost and decided to do it for Writeboost, too. This feature is implemented now. Related thread: http://www.redhat.com/archives/dm-devel/2014-April/msg9.html As a result, writeback is really efficiently done by Writeboost. You can see the detail in Section 4 "Benchmarking Results". Persistent Logging and parameter in constructor -- Writeboost has three layers - RAM buffer, SSD (or cache device) and HDD (or backing device). The data on the RAM buffer are written on SSD when FLUSH is requested. Practically, it is not so frequent but in some arbitrary workload Writeboost performs really badly because of the overhead of writing the RAM buffer on each FLUSH request. Persistent Logging is to solve this problem. It writes the dirty data into Persistent Logging Device (plog_dev) to reduce this overhead. For more detail, please read writeboost.pdf. DOWNLOAD: https://github.com/akiradeveloper/dm-writeboost/blob/develop/doc/writeboost.pdf?raw=true 3. What we are gonna do? We are engaged in investigating Writeboost in terms of what kind of workload is good/bad for Writeboost and the all tests are in the dmts. URL: https://github.com/jthornber/device-mapper-test-suite The on-going discussion between I and Joe is accessible in dmts. If you are interested in Writeboost I recommend you to watch the repository. It will be also thankful if you join us on this work. Since my hardware environment is not rich, testing this accelerator on richer environment will help me a lot. Especially, I want to test Writeboost with RAID-ed backing device (e.g. 100-HDDs). 4. Benchmarking Results I will share the latest benchmark result on my hardware environment. FYI, formerly, I share this benchmark (randwrite throughput). http://www.redhat.com/archives/dm-devel/2014-February/msg0.html Summary: Stacking Writeboost on a spindle block device will reveal these benefits. - It will always improve writes. If the cache device is small and the dirties are always overflown. This is because of the optimization in writeback algorithm. I think the sorting really affects. This is supported by the test (A). - Writeboost doesn't much deteriorate the read although it splits the I/O into 4KB fragments. This is supported by (B). - Even in read-many workload, Writeboost performs really nicely. This is supported by (C). - In realistic workload, Writeboost Type1 really improves the score. This is supported by (D). Test: Writeboost in comparison with backing device only (i.e. wo Writeboost) (A) 128MB writes to the HDD: Type0 (batch size:256) improves 396% (B) 128MB reads: Type0 1% slower (iosize=128KB) (C) Git Extract: Type0 22% faster (Total time) (D) dbench: Type1 improves 234%-299% (depends on the option) Details: (A) writeback_sorting_effect To see how writeback optimization effects the time to complete all writeback is measured. As the number of segments batched in writeback is the major factor in writeback optimization we will see how this parameter affects by changing it. Note the data amount to write is 128MB. WriteboostTestsBackingDevice Elapsed 118.693293268 WriteboostTestsType0 Elapsed 117.053297884: batch_size(4) Elapsed 76.709325916: batch_size(32) Elapsed 47.994442515: batch_size(128) Elapsed 29.953923952: batch_size(256) The bigger the batched size is the elapsed time is shortened. The best case is 118.69 -> 29.95 sec (x3.96) It is easy to imagine more higher batch_size will be more gain. This result means Writeboost has a potential to act as really efficient I/O schedul
[PATCH 0/2] dell-wmi: Add support for Fn key combinations
This patch series add support for Fn key combinations to dell-wmi driver. I tested this patch series on laptop Dell Latitude E6440. Here is Bios DMI table which contains scancode to keycode mapping: Handle 0xB200, DMI type 178, 80 bytes OEM-specific Type Header and Data: B2 50 00 B2 07 01 0C 00 08 01 0A 00 09 01 0B 00 0A 01 12 00 3B 00 20 00 42 00 18 00 48 00 14 00 50 00 13 00 10 00 FF 00 11 00 FF 00 12 00 FF 00 13 00 FF 00 14 00 FF 00 1E 00 FF 00 1F 00 FF 00 20 00 FF 00 21 00 FF 00 22 00 FF 00 4D 00 16 00 Strings: As you can see, more different keys are mapped to one keycode 0xFF. Pali Rohár (2): Input: Add keycodes for some missing Fn key combinations dell-wmi: Add support for Fn key combinations drivers/platform/x86/dell-wmi.c | 27 ++- include/uapi/linux/input.h |6 ++ 2 files changed, 32 insertions(+), 1 deletion(-) -- 1.7.9.5 -- 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/2] staging: rtl8188eu: fix usage of uninit scalar in rtw_drv_init()
On Sat, May 17, 2014 at 12:38:57PM +0200, Christian Engelmayer wrote: > Function rtw_drv_init() is written in a way that assumes 'status' != _SUCCESS > as long as not explicitly set. Thus initialize 'status' to FAIL, in order to > prevent undefined behaviour if going through the exit paths. Detected by > Coverity - CID 1077832. > > Signed-off-by: Christian Engelmayer This is a bugfix and we like to merge bugfixes without asking redo things, so don't redo. But really the better fix is to get rid of the status variable completely. Just return directly on the success path. If we were to do that, then both patches would be merged together and called: [patch] Staging: rtl8188eu: fix error handling in rtw_drv_init() But this patch is also acceptable as-is. Thanks for fixing the bug. :) regards, dan carpenter -- 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/2] dell-wmi: Add support for Fn key combinations
Bios DMI table contains scancodes for some Fn key combinations. But
corresponding keycodes in DMI table have same value 255. And dell-wmi driver
map value 255 to KEY_PROG3. This means that it is not possible to distinguish
between Fn key combinations (e.g Fn+Q and Fn+W), because kernel reports for all
of them only KEY_PROG3.
This patch adding new table for mapping Bios DMI scancodes to linux keycodes
when bios DMI keycode is set to "generic" keycode 255. So different Fn key
combinations will have different keycodes.
Signed-off-by: Pali Rohár
---
drivers/platform/x86/dell-wmi.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 390e8e3..c54d675 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -140,7 +140,27 @@ static const u16 bios_to_linux_keycode[256] __initconst = {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, KEY_PROG3
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
+};
+
+/* table for bios code 0xff */
+static const u16 scancode_to_linux_keycode[256] __initconst = {
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ KEY_FN_Q, KEY_FN_W, KEY_FN_E, KEY_FN_R,
+ KEY_FN_T, 0, 0, 0,
+ 0, 0, 0, 0,
+ 0, 0, KEY_FN_A, KEY_FN_S,
+ KEY_FN_D, KEY_FN_F, KEY_FN_G, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
};
static struct input_dev *dell_wmi_input_dev;
@@ -212,6 +232,11 @@ static const struct key_entry * __init
dell_wmi_prepare_new_keymap(void)
keymap[i].keycode = bios_entry->keycode < 256 ?
bios_to_linux_keycode[bios_entry->keycode] :
KEY_RESERVED;
+ if (bios_entry->keycode == 255 && bios_entry->scancode < 256)
+ keymap[i].keycode =
+ scancode_to_linux_keycode[bios_entry->scancode];
+ if (!keymap[i].keycode)
+ keymap[i].keycode = KEY_RESERVED;
}
keymap[hotkey_num].type = KE_END;
--
1.7.9.5
--
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/2] Input: Add keycodes for some missing Fn key combinations
There are already defined some Fn key combinations, but not all.
This patch adds missing combinations for support in dell-wmi driver.
Signed-off-by: Pali Rohár
---
include/uapi/linux/input.h |6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index f484952..3a32799 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -672,6 +672,12 @@ struct input_keymap_entry {
#define KEY_FN_F 0x1e2
#define KEY_FN_S 0x1e3
#define KEY_FN_B 0x1e4
+#define KEY_FN_Q 0x1e5
+#define KEY_FN_W 0x1e6
+#define KEY_FN_R 0x1e7
+#define KEY_FN_T 0x1e8
+#define KEY_FN_A 0x1e9
+#define KEY_FN_G 0x1ea
#define KEY_BRL_DOT1 0x1f1
#define KEY_BRL_DOT2 0x1f2
--
1.7.9.5
--
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] fs: Cleanup string initializations (char[] instead of char *)
Initializations like 'char *foo = "bar"' will create two variables: a static
string and a pointer (foo) to that static string. Instead 'char foo[] = "bar"'
will declare a single variable and will end up in shorter
assembly (according to Jeff Garzik on the KernelJanitor's TODO list).
Signed-off-by: Manuel Schölling
---
fs/binfmt_misc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
index b605003..2a10529 100644
--- a/fs/binfmt_misc.c
+++ b/fs/binfmt_misc.c
@@ -419,7 +419,7 @@ static void entry_status(Node *e, char *page)
{
char *dp;
char *status = "disabled";
- const char * flags = "flags: ";
+ const char flags[] = "flags: ";
if (test_bit(Enabled, &e->flags))
status = "enabled";
--
1.7.10.4
--
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] fs: FAT: Cleanup string initializations (char[] instead of char *)
Initializations like 'char *foo = "bar"' will create two variables: a static
string and a pointer (foo) to that static string. Instead 'char foo[] = "bar"'
will declare a single variable and will end up in shorter
assembly (according to Jeff Garzik on the KernelJanitor's TODO list).
Signed-off-by: Manuel Schölling
---
fs/fat/inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index b3361fe..8b7d00e 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -359,7 +359,7 @@ struct inode *fat_iget(struct super_block *sb, loff_t i_pos)
static int is_exec(unsigned char *extension)
{
- unsigned char *exe_extensions = "EXECOMBAT", *walk;
+ unsigned char exe_extensions[] = "EXECOMBAT", *walk;
for (walk = exe_extensions; *walk; walk += 3)
if (!strncmp(extension, walk, 3))
--
1.7.10.4
--
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: dgap: implement error handling in dgap_tty_register()
2014-05-17 8:09 GMT+09:00, Greg KH : > On Fri, Apr 25, 2014 at 04:04:59PM +0900, Daeseok Youn wrote: >> - alloc_tty_driver() is deprecated so it is changed to >> tty_alloc_driver() >> - Pointers which are allocated by alloc_tty_driver() and kzalloc() >> can be NULL so it need to check NULL for them. >> - If one of those is failed, it need to add proper handler for >> avoiding memory leak. >> >> Signed-off-by: Daeseok Youn >> --- >> drivers/staging/dgap/dgap.c | 49 >> +++ >> 1 files changed, 40 insertions(+), 9 deletions(-) > > This doesn't apply at all to my tree anymore, please refresh it and > resend. > Yes. It need to rebase on staging-next branch. I will rebase and resend this. Thanks Daeseok Youn. > thanks, > > greg k-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/
kernel 3.14.2 oops: seems related to EFI
[ +0.018677] general protection fault: [#1] PREEMPT SMP [ +0.68] Modules linked in: usb_storage tun raid1 md_mod loop fuse joydev coretemp hwmon arc4 intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel nls_iso8859_1 nls_cp437 iTCO_wdt kvm vfat fat iTCO_vendor_support iwldvm uvcvideo led_class crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel mac80211 videobuf2_vmalloc videobuf2_memops videobuf2_core aesni_intel videodev aes_x86_64 snd_hda_codec_hdmi lrw gf128mul mousedev glue_helper btusb snd_hda_codec_via ablk_helper media cryptd iwlwifi snd_hda_codec_generic bluetooth psmouse microcode i2c_i801 serio_raw cfg80211 6lowpan_iphc rtsx_pci_ms r8169 memstick rfkill lpc_ich mii snd_hda_intel snd_hda_codec thermal snd_hwdep wmi snd_pcm tpm_infineon snd_timer tpm_tis mei_me snd tpm mei shpchp evdev soundcore processor battery mac_hid ac [ +0.000803] ext4 crc16 mbcache jbd2 hid_generic usbhid hid bcache sd_mod sr_mod crc_t10dif cdrom crct10dif_common rtsx_pci_sdmmc mmc_core atkbd libps2 ahci libahci ehci_pci libata xhci_hcd ehci_hcd scsi_mod rtsx_pci usbcore usb_common i8042 serio i915 video button intel_gtt i2c_algo_bit drm_kms_helper drm i2c_core [ +0.000328] CPU: 0 PID: 30835 Comm: systemd-udevd Not tainted 3.14.2-1-ARCH #1 [ +0.64] Hardware name: CLEVO CO.W55xEU /W55xEU , BIOS 4.6.5 03/05/2013 [ +0.000102] task: 880405ee6bf0 ti: 880400f4a000 task.ti: 880400f4a000 [ +0.60] RIP: 0010:[] [] efi_call5+0x6f/0xf0 [ +0.71] RSP: 0018:880400f4bdb0 EFLAGS: 00010002 [ +0.45] RAX: 80050033 RBX: 8804040e3000 RCX: 8804040e3000 [ +0.55] RDX: 8804040e3400 RSI: 8804040e3000 RDI: bff7f7af [ +0.56] RBP: 880400f4be80 R08: R09: 880400f4bec0 [ +0.55] R10: R11: 0246 R12: 8804040e3400 [ +0.56] R13: R14: 880400f4bec0 R15: 0009b000 [ +0.002960] FS: 7fb6167c97c0() GS:88041e20() knlGS: [ +0.002958] CS: 0010 DS: ES: CR0: 80050033 [ +0.003177] CR2: 7fb61581f4c0 CR3: 0009b000 CR4: 001427e0 [ +0.003258] Stack: [ +0.003257] 0201 8065 8804 8801 [ +0.003328] 880400f4be50 80050033 [ +0.003354] 00ff 00ff [ +0.003368] Call Trace: [ +0.003389] [] ? virt_efi_get_variable+0x51/0x80 [ +0.003353] [] efivar_entry_size+0x41/0x80 [ +0.003315] [] efivarfs_file_read+0x49/0x100 [ +0.003326] [] vfs_read+0x97/0x160 [ +0.003305] [] SyS_read+0x59/0xd0 [ +0.003263] [] system_call_fastpath+0x16/0x1b [ +0.003239] Code: 89 c8 48 89 f1 80 3d e8 16 7d 00 00 74 1d 4c 89 3d c7 16 7d 00 41 0f 20 df 4c 89 3d c4 16 7d 00 4c 8b 3d c5 16 7d 00 41 0f 22 df d7 80 3d c0 16 7d 00 00 74 41 4c 8b 3d a7 16 7d 00 41 0f 22 [ +0.003648] RIP [] efi_call5+0x6f/0xf0 [ +0.003511] RSP [ +0.024630] ---[ end trace 3670998c9a49abb7 ]--- [ +0.05] note: systemd-udevd[30835] exited with preempt_count 2 -- 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: Dell Latitude E6440 & i8k
On 05/16/2014 12:11 PM, Jean Delvare wrote: Hi Pali, On Fri, 16 May 2014 20:37:41 +0200, Pali Rohár wrote: Hello, on Dell Latitude E6440 driver i8k reporting total nonsense values That's kind of excessive wording, the output isn't that bad. $ sensors i8k-virtual-0 Adapter: Virtual device Right Fan: 93450 RPM CPU: +57.0°C temp2:+57.0°C temp3:+40.0°C temp4: +127.0°C Right Fan and temp4 are for sure incorrect. Driver is reverse-engineered so this is best effort and some tweaking may be needed. Value temp4 is always 127 and is never changing, but value for Right Fan is increasing when fan is more noisy. So it looks like value for Right Fan is not correctly normalized or multiplier is incorrect. And name "Right" is incorrect too. Fan is on left side of this notebook, not right as reported by driver. It is possible to fix these problems? Load the i8k driver with fan_mult=1. Would it make sense to change the default multiplier to 1 ? Lots of people have problems with it, and trying to figure out affected machines one by one would be an all but impossible task. Guenter -- 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: Dell Latitude E6440 & i8k
On 05/16/2014 12:23 PM, Pali Rohár wrote: On Friday 16 May 2014 21:11:17 Jean Delvare wrote: Hi Pali, On Fri, 16 May 2014 20:37:41 +0200, Pali Rohár wrote: Hello, on Dell Latitude E6440 driver i8k reporting total nonsense values That's kind of excessive wording, the output isn't that bad. I mean fan RPM & temp4. Those are for sure incorrect. $ sensors i8k-virtual-0 Adapter: Virtual device Right Fan: 93450 RPM CPU: +57.0°C temp2:+57.0°C temp3:+40.0°C temp4: +127.0°C Right Fan and temp4 are for sure incorrect. Driver is reverse-engineered so this is best effort and some tweaking may be needed. Ok, if driver is developed without any documentation, then it make sense that not working correctly on new machines... So is not there any documentation? I think that Dell released some SMM/BIOS code... But I'm not sure about it. If you find it, please let us know. Guenter -- 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] ARM: imx: fix error handling
Hello Uwe,
On Fri, May 16, 2014 at 09:31:39PM +0200, Uwe Kleine-König wrote:
> Hello Walter,
>
> On Fri, May 16, 2014 at 01:49:10PM +0200, walter harms wrote:
> > Am 16.05.2014 13:16, schrieb Emil Goode:
> > > Hello Walter,
> > >
> > > On Fri, May 16, 2014 at 12:40:19PM +0200, walter harms wrote:
> > >>
> > >>
> > >> Am 16.05.2014 11:54, schrieb Emil Goode:
> > >>> If we fail to allocate struct platform_device pdev we
> > >>> dereference it after the goto label err.
> > >>>
> > >>> I have rearranged the error handling a bit to fix the issue
> > >>> and also make it more clear.
> > >>>
> > >>> Signed-off-by: Emil Goode
> > >>> ---
> > >>> v2: Changed to return -ENOMEM instead of ret where possible and
> > >>> updated the subject line.
> > >>>
> > >>> arch/arm/mach-imx/devices/platform-ipu-core.c | 22
> > >>> +-
> > >>> 1 file changed, 13 insertions(+), 9 deletions(-)
> > >>>
> > >>> diff --git a/arch/arm/mach-imx/devices/platform-ipu-core.c
> > >>> b/arch/arm/mach-imx/devices/platform-ipu-core.c
> > >>> index fc4dd7c..68f2a4a 100644
> > >>> --- a/arch/arm/mach-imx/devices/platform-ipu-core.c
> > >>> +++ b/arch/arm/mach-imx/devices/platform-ipu-core.c
> > >>> @@ -77,34 +77,38 @@ struct platform_device *__init imx_alloc_mx3_camera(
> > >>>
> > >>> pdev = platform_device_alloc("mx3-camera", 0);
> > >>> if (!pdev)
> > >>> - goto err;
> > >>> + return ERR_PTR(-ENOMEM);
> > >>>
> > >>> pdev->dev.dma_mask = kmalloc(sizeof(*pdev->dev.dma_mask),
> > >>> GFP_KERNEL);
> > >>> if (!pdev->dev.dma_mask)
> > >>> - goto err;
> > >>> + goto put_pdev;
> > >>>
> > >>> *pdev->dev.dma_mask = DMA_BIT_MASK(32);
> > >>> pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> > >>>
> > >>> ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
> > >>> if (ret)
> > >>> - goto err;
> > >>> + goto free_dma_mask;
> > >>>
> > >>> if (pdata) {
> > >>> struct mx3_camera_pdata *copied_pdata;
> > >>>
> > >>> ret = platform_device_add_data(pdev, pdata,
> > >>> sizeof(*pdata));
> > >>> - if (ret) {
> > >>> -err:
> > >>> - kfree(pdev->dev.dma_mask);
> > >>> - platform_device_put(pdev);
> > >>> - return ERR_PTR(-ENODEV);
> > >>> - }
> > >>> + if (ret)
> > >>> + goto free_dma_mask;
> > >>> +
> > >>> copied_pdata = dev_get_platdata(&pdev->dev);
> > >>> copied_pdata->dma_dev = &imx_ipu_coredev->dev;
> > >>
> > >>
> > >> the patch is fine, but what use is this copied_pdata ?
> > >> It scope ends next line ?
> > >>
> > >> re,
> > >> wh
> > >
> > > I also thought that looked a bit odd, but copied_pdata is a temporary
> > > pointer to platform_data of the dev struct.
> > >
> > > dev_get_platdata looks like this:
> > >
> > > static inline void *dev_get_platdata(const struct device *dev)
> > > {
> > > return dev->platform_data;
> > > }
> > >
> > > So I believe it's a more compact way of writing:
> > >
> > > pdev->dev->platform_data->dma_dev = &imx_ipu_coredev->dev;
> It's not about compactness. The dev_get_platdata accessor exists to be
> used instead of directly accessing dev->platform_data. I admit a comment
> would be nice ...
>
> Anyhow this is all ugly, actually you'd want to have the dma_dev member
> already fixed when calling platform_device_add_data. But you cannot
> simply do
>
> pdata->dma_dev = &imx_ipu_coredev->dev;
> ret = platform_device_add_data(pdev, pdata, sizeof(*pdata));
>
> because *pdata is const.
Thank you for the explanation. Regarding the possibility of using
platform_device_register_full() to simplify this function. It seem to
be possible, the following inline function is available to help with this.
imx_add_platform_device_dmamask()
Available here:
arch/arm/mach-imx/devices/devices-common.h
But as you mentioned above we need to allocate a new platform_device
struct before we can assign &imx_ipu_coredev->dev to dma_dev, since
pdata is const. I guess this assignment could be done after calling
imx_add_platform_device_dmamask() but I don't think that makes the
code easier to read.
I think it's best to resend the current patch. (with updated subject line)
Best regards,
Emil Goode
--
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 00/34] perf and kconfig / kbuild
Hello, Sorry for the late reply, On Wed, May 14, 2014 at 4:15 AM, David Ahern wrote: > On 5/13/14, 4:02 PM, Alexis Berlemont wrote: >> >> Hello, >> >> A few months ago, I tried to make a proposal to introduce Kconfig in >> perf's generation procedure. >> (cf. https://lkml.org/lkml/2013/12/20/511) >> >> I started from David Ahern's work; I was not aware that Jiri Olsa >> pushed further the idea and proposed an alternative which integrated >> kbuild too. >> >> So, here is another proposal based on Jiri Olsa work (from April 2013). >> * Most of the NO_* and HAVE_* makefile variables were removed on >>behalf of Kconfig's ones (CONFIG_*); perf source code was modified >>accordingly; >> * These changes make the glue files tools/perf/config/Makefile.fix-* >> useless >> * The build test cases now relies on generated configuration files (in >>tools/perf/tests/configs); >> > > Thanks for picking this up. I skimmed through all of the patches and > conceptually looks good. I doubt I will have time for a detailed review any > time soon. > > Looks like they apply to Linus' top of tree but with a few errors -- see > below. You should always run checkpatch.pl before sending out: Sorry, I indeed did not run checkpatch. I will come back with a cleaner version. > > Applying: kbuild: Introduce KBUILD_AUTOCONF variable for auto.conf include > Applying: kbuild: Introduce KCONFIG_AUTOCONFIGDEP variable for conf tool > Applying: perf tools: Kbuild builtin source related fixies > Applying: perf tools: Kbuild source related fixies > Applying: perf tools: Add kbuild support into Makefile.kbuild > Applying: perf kbuild: fix recursive invocation of config/features-checks > Applying: perf kbuild: store in config-detected missing variables (libdir, > ...) > Applying: perf kbuild: remove useless #ifdef directives > Applying: perf kbuild: fix a link issue if BUILTIN_TRACE is disabled > Applying: perf kbuild: add missing files and missing flags in Kbuild files > /Users/dsa/sw/perf/ahern.git/.git/rebase-apply/patch:30: trailing > whitespace. > CFLAGS_Context.o += -Wno-redundant-decls -Wno-strict-prototypes > /Users/dsa/sw/perf/ahern.git/.git/rebase-apply/patch:137: trailing > whitespace. > CFLAGS_trace-event-perl.o += -Wno-redundant-decls -Wno-strict-prototypes > /Users/dsa/sw/perf/ahern.git/.git/rebase-apply/patch:138: trailing > whitespace. > CFLAGS_trace-event-perl.o += -Wno-unused-parameter -Wno-shadow -Wno-undef > /Users/dsa/sw/perf/ahern.git/.git/rebase-apply/patch:143: trailing > whitespace. > CFLAGS_trace-event-python.o += -Wno-redundant-decls -Wno-strict-prototypes > warning: 4 lines applied after fixing whitespace errors. > Applying: perf kbuild: update kbuild files according to last changes > Applying: perf kbuild: remove legacy slang-related build variables > Applying: perf kbuild: remove legacy libaudit-related build variables > Applying: perf kbuild: remove legacy libgtk2-related build variables > /Users/dsa/sw/perf/ahern.git/.git/rebase-apply/patch:204: trailing > whitespace. > #else > warning: 1 line applied after fixing whitespace errors. > Applying: perf kbuild: remove legacy libperl-related build variables > Applying: perf kbuild: remove legacy timerfd-related build variable > Applying: perf kbuild: remove legacy demangle-related build variables > Applying: perf kbuild: remove legacy on_exit-related build variable > Applying: perf kbuild: remove legacy backtrace-related build variable > Applying: perf kbuild: remove legacy numa-related build variable > Applying: perf kbuild: remove legacy bionic-related build variable > Applying: perf kbuild: remove legacy libelf-related build variables (1st > part) > Applying: perf kbuild: remove legacy libelf-related build variables (2nd > part) > Applying: perf kbuild: remove legacy libdwarf-related build variables > /Users/dsa/sw/perf/ahern.git/.git/rebase-apply/patch:342: trailing > whitespace. > endif # CONFIG_LIBDWARF_UNWIND > warning: 1 line applied after fixing whitespace errors. > Applying: perf kbuild: remove legacy libunwind-related build variables > Applying: perf kbuild: remove legacy libpython-related build variable > Applying: perf kbuild: add generated Kconfig build-test cases > Applying: perf kbuild: fix installation of traceevent plugins > /Users/dsa/sw/perf/ahern.git/.git/rebase-apply/patch:74: trailing > whitespace. > make_pure := > warning: 1 line applied after fixing whitespace errors. > Applying: perf kbuild: fix tarpkg target in tests/make > Applying: perf kbuild: update Kbuild files with new and removed sources > Applying: perf kbuild: update build test configurations > /Users/dsa/sw/perf/ahern.git/.git/rebase-apply/patch:773: trailing > whitespace. > > warning: 1 line applied after fixing whitespace errors. > Applying: perf kbuild: relocate the configs generating script > Applying: perf kbuild: minor changes > Applying: perf kbuild: remove Makefile.perf > > David > Alexis. -- To unsubscribe from this list: send the line "uns
Re: [PATCH] fs: Cleanup string initializations (char[] instead of char *)
On Sat, May 17, 2014 at 05:00:18PM +0200, Manuel Schölling wrote:
> Initializations like 'char *foo = "bar"' will create two variables: a static
> string and a pointer (foo) to that static string. Instead 'char foo[] = "bar"'
> will declare a single variable and will end up in shorter
> assembly (according to Jeff Garzik on the KernelJanitor's TODO list).
>
This is a greatly oversimplifying things, this may or may not happen.
Out of curiosity I checked my kernel on x86-64 and it has this
optimized:
0xa00a9629 : movabs $0x203a7367616c66,%rcx
crash> ascii 0x203a7367616c66
00203a7367616c66: flags:
> fs/binfmt_misc.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
> index b605003..2a10529 100644
> --- a/fs/binfmt_misc.c
> +++ b/fs/binfmt_misc.c
> @@ -419,7 +419,7 @@ static void entry_status(Node *e, char *page)
> {
> char *dp;
> char *status = "disabled";
> - const char * flags = "flags: ";
> + const char flags[] = "flags: ";
>
> if (test_bit(Enabled, &e->flags))
> status = "enabled";
This particular function would be better of with removing this variable
and replacing all pairs like:
sprintf(dp, ...);
dp += strlen(...)
with:
dp += sprintf(dp, ...);
--
Mateusz Guzik
--
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] fs: FAT: Cleanup string initializations (char[] instead of char *)
Manuel Schölling writes:
> Initializations like 'char *foo = "bar"' will create two variables: a static
> string and a pointer (foo) to that static string. Instead 'char foo[] = "bar"'
> will declare a single variable and will end up in shorter
> assembly (according to Jeff Garzik on the KernelJanitor's TODO list).
>
> Signed-off-by: Manuel Schölling
Looks good.
Acked-by: OGAWA Hirofumi
> ---
> fs/fat/inode.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/fat/inode.c b/fs/fat/inode.c
> index b3361fe..8b7d00e 100644
> --- a/fs/fat/inode.c
> +++ b/fs/fat/inode.c
> @@ -359,7 +359,7 @@ struct inode *fat_iget(struct super_block *sb, loff_t
> i_pos)
>
> static int is_exec(unsigned char *extension)
> {
> - unsigned char *exe_extensions = "EXECOMBAT", *walk;
> + unsigned char exe_extensions[] = "EXECOMBAT", *walk;
>
> for (walk = exe_extensions; *walk; walk += 3)
> if (!strncmp(extension, walk, 3))
--
OGAWA Hirofumi
--
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 0/9] 3.4.91-stable review
On 05/16/2014 03:55 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.4.91 release. There are 9 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun May 18 22:54:50 UTC 2014. Anything received after that time might be too late. Build results: total: 134 pass: 109 skipped: 18 fail: 7 Qemu tests all passed. There are two new build failures, powerpc:ppc64e_defconfig and powerpc:chroma_defconfig. Those are not due to source code changes, but due to added builds. Failures are seen if the images are built with binutils 2.24, and are caused by a changed assembler ABI. A patch to fix the problem has been submitted but is not yet upstream. Detailed results are available at http://server.roeck-us.net:8010/builders. powerpc builds with binutils 2.24 are shown as 'powerpc_24' architecture. Guenter -- 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] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
On 05/16/2014 09:37 AM, Andreas Werner wrote:
The MEN 14F021P00 Board Management Controller provides an
I2C interface to the host to access the feature implemented in the BMC.
The BMC is a PIC Microntroller assembled on CPCI Card from MEN Mikroelektronik
and on a few Box/Display Computer.
Added MFD Core driver, supporting the I2C communication to the device.
The MFD driver currently supports the following features:
- Watchdog
- LEDs
Signed-off-by: Andreas Werner
---
drivers/mfd/Kconfig | 12 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/menf21bmc.c | 193 ++
include/linux/mfd/menf21bmc.h | 32 +++
4 files changed, 238 insertions(+)
create mode 100644 drivers/mfd/menf21bmc.c
create mode 100644 include/linux/mfd/menf21bmc.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index ab5a43c..7c2e8d2 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -427,6 +427,18 @@ config MFD_MAX8998
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MENF21BMC
+ tristate "MEN 14F021P00 Board Management Controller Support"
+ depends on I2C=y
+ select MFD_CORE
+ help
+ Say yes here to add support for the MEN 14F021P00 BMC
+ which is a Board Management Controller connected to the I2C bus.
+ This driver provides common support for accessing the devices;
+ additional drivers must be enabled in order to use the
+ functionality of the BMC device.
+
+
config EZX_PCAP
bool "Motorola EZXPCAP Support"
depends on SPI_MASTER
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 5913208..8f2be38 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -167,3 +167,4 @@ obj-$(CONFIG_MFD_AS3711)+= as3711.o
obj-$(CONFIG_MFD_AS3722) += as3722.o
obj-$(CONFIG_MFD_STW481X) += stw481x.o
obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
+obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
diff --git a/drivers/mfd/menf21bmc.c b/drivers/mfd/menf21bmc.c
new file mode 100644
index 000..77de1a8
--- /dev/null
+++ b/drivers/mfd/menf21bmc.c
@@ -0,0 +1,193 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) MFD Core Driver.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ * Author: Andreas Werner
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BMC_CMD_REV_MAJOR 0x80
+#define BMC_CMD_REV_MINOR 0x81
+#define BMC_CMD_REV_MAIN 0x82
+#define BMC_CMD_REV_BUILD 0x83
+#define BMC_CMD_REV_VERI 0x84
+
+static struct mfd_cell menf21bmc_cell[] = {
+ {
+ .name = "menf21bmc_wd",
+ },
+ {
+ .name = "menf21bmc_led",
+ },
+};
+
+static int
+menf21bmc_read_byte_data(struct i2c_client *client, u8 reg, uint8_t *val)
+{
+ int ret;
+ struct menf21bmc *data = i2c_get_clientdata(client);
+
+ mutex_lock(&data->lock);
+ ret = i2c_smbus_read_byte_data(client, reg);
+ mutex_unlock(&data->lock);
+
+ if (ret < 0) {
+ dev_err(&client->dev, "failed to read byte at 0x%02x\n", reg);
+ return ret;
+ }
+
+ *val = (uint8_t)ret;
+
+ return 0;
+}
+
I personally would prefer if you would retain the original API, which returns
both value
and error code as return value. I don't see the benefit of changing the API as
you did -
it just complicates the code.
Thanks,
Guenter
--
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] drivers/watchdog/menf21bmc_wd: introduce MEN 14F021P00 BMC Watchdog driver
On 05/16/2014 09:37 AM, Andreas Werner wrote:
Added driver to support the 14F021P00 BMC Watchdog.
The BMC is a Board Management Controller including watchdog functionality.
This driver use the I2C interface to the BMC using the menf21bmc MFD Core
driver.
Signed-off-by: Andreas Werner
---
drivers/watchdog/Kconfig| 7 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/menf21bmc_wd.c | 263
3 files changed, 271 insertions(+)
create mode 100644 drivers/watchdog/menf21bmc_wd.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 2b4c1fc..ede3201 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -95,6 +95,13 @@ config GPIO_WATCHDOG
If you say yes here you get support for watchdog device
controlled through GPIO-line.
+config MENF21BMC_WATCHDOG
+ tristate "MEN 14F021P00 BMC Watchdog"
+ depends on MFD_MENF21BMC
+ select WATCHDOG_CORE
+ help
+ Say Y here to include support for the MEN 14F021P00 BMC Watchdog.
+
config WM831X_WATCHDOG
tristate "WM831x watchdog"
depends on MFD_WM831X
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 1b5f3d5..0a5465d 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -178,3 +178,4 @@ obj-$(CONFIG_WM831X_WATCHDOG) += wm831x_wdt.o
obj-$(CONFIG_WM8350_WATCHDOG) += wm8350_wdt.o
obj-$(CONFIG_MAX63XX_WATCHDOG) += max63xx_wdt.o
obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o
+obj-$(CONFIG_MENF21BMC_WATCHDOG) += menf21bmc_wd.o
diff --git a/drivers/watchdog/menf21bmc_wd.c b/drivers/watchdog/menf21bmc_wd.c
new file mode 100644
index 000..31ccea8
--- /dev/null
+++ b/drivers/watchdog/menf21bmc_wd.c
@@ -0,0 +1,263 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) Watchdog Driver.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ * Author: Andreas Werner
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEVNAME "menf21bmc_wd"
+
+#define BMC_CMD_WD_ON 0x11
+#define BMC_CMD_WD_OFF 0x12
+#define BMC_CMD_WD_TRIG0x13
+#define BMC_CMD_WD_TIME0x14
+#define BMC_CMD_WD_STATE 0x17
+#define BMC_CMD_WD_ARM_SET 0x18
+#define BMC_CMD_WD_ARM_GET 0x19
+#define BMC_CMD_ARM_STATE 0x19
+#define BMC_WD_OFF_VAL 0x69
+#define BMC_CMD_RST_RSN0x92
+
+#define BMC_WD_TIMEOUT_MIN 1 /* in sec -> BMC min = 0.1 s */
I find the comment a bit confusing. The timeout is in seconds. The BMC minimum
timeout may be 0.1s, but that is not reflected in the define. Maybe replace
the comment with something like
/* in sec (BMC min = 0.1 s) */
+#define BMC_WD_TIMEOUT_MAX 6553/* in sec -> BMC max = 6553,5 s */
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+ __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+struct menf21bmc_wd_data {
+ struct watchdog_device wdt;
+ struct menf21bmc *menf21bmc;
+};
+
+static int menf21bmc_wd_set_bootstatus(struct menf21bmc_wd_data *data)
+{
+ u8 rst_rsn;
+ int ret;
+ struct menf21bmc *menf21bmc = data->menf21bmc;
+
+ ret = menf21bmc->read_byte_data(menf21bmc->client,
+ BMC_CMD_RST_RSN, &rst_rsn);
+ if (ret < 0)
+ return -EIO;
+
Please return the original error.
+ if (rst_rsn == 0x02)
+ data->wdt.bootstatus |= WDIOF_CARDRESET;
+ else if (rst_rsn == 0x05)
+ data->wdt.bootstatus |= WDIOF_EXTERN1;
+ else if (rst_rsn == 0x06)
+ data->wdt.bootstatus |= WDIOF_EXTERN2;
+ else if (rst_rsn == 0x0A)
+ data->wdt.bootstatus |= WDIOF_POWERUNDER;
+
+ return 0;
+}
+
+static int menf21bmc_wd_leave_prod_mode(struct platform_device *pdev)
+{
+ int ret;
+ uint8_t val;
+ struct menf21bmc_wd_data *data = platform_get_drvdata(pdev);
+ struct menf21bmc *menf21bmc = data->menf21bmc;
+
+ ret = menf21bmc->read_byte_data(menf21bmc->client,
+ BMC_CMD_WD_ARM_GET, &val);
+ if (ret < 0)
+ return -EIO;
+
Please return the original error.
+ /*
+* Production mode should be not active after delivery of the Board.
+* To be sure we check it, inform the user and leave the mode
+* if active.
+*/
+ if (val == 0x00) {
+ dev_info(&pdev->dev,
Re: [PATCH 1/2] x86: insn decoder: create artificial 3rd byte for 2-byte VEX
(2014/05/17 3:34), Denys Vlasenko wrote:
> Before this patch, users need to do this to fetch vex.:
>
> if (insn->vex_prefix.nbytes == 2) {
> vex_ = ((insn->vex_prefix.bytes[1] >> 3) & 0xf) ^ 0xf;
> }
> if (insn->vex_prefix.nbytes == 3) {
> vex_ = ((insn->vex_prefix.bytes[2] >> 3) & 0xf) ^ 0xf;
> }
>
> Make it so that insn->vex_prefix.bytes[2] always contains vex.wLpp bits.
I like this hack :)
If you don't mind, please add inline functions to get such vex bits from
struct insn too?
Thank you,
>
> Signed-off-by: Denys Vlasenko
> Cc: Masami Hiramatsu
> Cc: Frank Ch. Eigler
> Cc: Srikar Dronamraju
> Cc: Ananth N Mavinakayanahalli
> Cc: Jim Keniston
> Cc: Oleg Nesterov
> Cc: Andi Kleen
> Cc: Ingo Molnar
> ---
> arch/x86/lib/insn.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/x86/lib/insn.c b/arch/x86/lib/insn.c
> index 54fcffe..829ca4c 100644
> --- a/arch/x86/lib/insn.c
> +++ b/arch/x86/lib/insn.c
> @@ -163,6 +163,12 @@ found:
> /* VEX.W overrides opnd_size */
> insn->opnd_bytes = 8;
> } else {
> + /*
> + * For VEX2, fake VEX3-like byte#2.
> + * Makes it easier to decode vex.W, vex.,
> + * vex.L and vex.pp. Masking with 0x7f sets vex.W == 0.
> + */
> + insn->vex_prefix.bytes[2] = b2 & 0x7f;
> insn->vex_prefix.nbytes = 2;
> insn->next_byte += 2;
> }
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
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/2] x86: extend insn decoder to understand xop and evex prefixes
(2014/05/17 3:34), Denys Vlasenko wrote:
> Since xop and evex prefixes are extensions of vex mechanism,
> they have similar bit layouts, and they can never be combined
> (an instruction can have only one of them),
> (ab)use insn->vex_prefix to store data of xop and evex too.
>
> Users will need to conditionalize on insn->vex_prefix.bytes[0]
> instead of insn->vex_prefix.nbytes if they want to determine
> which of vex(-like) prefixes are there.
>
> Instead of adding more inattr bits for these prefixes, drop
> VEX inattr bits and use VEX opcode values directly to detect them.
> There is no point in having additional level of indirection here.
> (And we are close to running out of inattr bits for prefixes).
Thank you very much for trying this work :)
But sorry, Nak, I don't like to use the prefix byte directly.
I'd rather like to add additional inattr bits for them.
This is a drawback of what I've done by gen-insn-atter-x86.awk.
It is prefer that x86 instruction information should be hidden
in opcode map and awk decoder.
And also, we should expand x86-opcode-map.txt for new instructions.
>
> Signed-off-by: Denys Vlasenko
> Cc: Masami Hiramatsu
> Cc: Frank Ch. Eigler
> Cc: Srikar Dronamraju
> Cc: Ananth N Mavinakayanahalli
> Cc: Jim Keniston
> Cc: Oleg Nesterov
> Cc: Andi Kleen
> Cc: Ingo Molnar
> ---
> arch/x86/include/asm/inat.h | 14 ---
> arch/x86/include/asm/insn.h | 6 +
> arch/x86/lib/insn.c | 47
> +---
> arch/x86/lib/x86-opcode-map.txt | 4 +--
> arch/x86/tools/gen-insn-attr-x86.awk | 2 --
> 5 files changed, 41 insertions(+), 32 deletions(-)
>
> diff --git a/arch/x86/include/asm/inat.h b/arch/x86/include/asm/inat.h
> index 74a2e31..5aa6c05 100644
> --- a/arch/x86/include/asm/inat.h
> +++ b/arch/x86/include/asm/inat.h
> @@ -45,9 +45,6 @@
> #define INAT_PFX_ADDRSZ 11 /* 0x67 */
> /* x86-64 REX prefix */
> #define INAT_PFX_REX 12 /* 0x4X */
> -/* AVX VEX prefixes */
> -#define INAT_PFX_VEX213 /* 2-bytes VEX prefix */
> -#define INAT_PFX_VEX314 /* 3-bytes VEX prefix */
>
> #define INAT_LSTPFX_MAX 3
> #define INAT_LGCPFX_MAX 11
> @@ -138,17 +135,6 @@ static inline int inat_last_prefix_id(insn_attr_t attr)
> return attr & INAT_PFX_MASK;
> }
>
> -static inline int inat_is_vex_prefix(insn_attr_t attr)
> -{
> - attr &= INAT_PFX_MASK;
> - return attr == INAT_PFX_VEX2 || attr == INAT_PFX_VEX3;
> -}
> -
> -static inline int inat_is_vex3_prefix(insn_attr_t attr)
> -{
> - return (attr & INAT_PFX_MASK) == INAT_PFX_VEX3;
> -}
> -
> static inline int inat_is_escape(insn_attr_t attr)
> {
> return attr & INAT_ESC_MASK;
> diff --git a/arch/x86/include/asm/insn.h b/arch/x86/include/asm/insn.h
> index 48eb30a..e098fec 100644
> --- a/arch/x86/include/asm/insn.h
> +++ b/arch/x86/include/asm/insn.h
> @@ -83,6 +83,12 @@ struct insn {
> #define X86_REX_X(rex) ((rex) & 2)
> #define X86_REX_B(rex) ((rex) & 1)
>
> +/* VEX and VEX-like multi-byte prefixes */
> +#define X86_BYTE_VEX3 0xc4
> +#define X86_BYTE_VEX2 0xc5
> +#define X86_BYTE_XOP 0x8f
> +#define X86_BYTE_EVEX 0x62
> +
> /* VEX bit flags */
> #define X86_VEX_W(vex) ((vex) & 0x80) /* VEX3 Byte2 */
> #define X86_VEX_R(vex) ((vex) & 0x80) /* VEX2/3 Byte1 */
> diff --git a/arch/x86/lib/insn.c b/arch/x86/lib/insn.c
> index 829ca4c..2351977 100644
> --- a/arch/x86/lib/insn.c
> +++ b/arch/x86/lib/insn.c
> @@ -138,31 +138,34 @@ found:
> }
> insn->rex_prefix.got = 1;
>
> - /* Decode VEX prefix */
> + /* Decode VEX prefixes et al. Layouts are:
> + * vex2: c5rLpp
> + * vex3/xop: c4/8f rxbm wLpp
> + * evex: 62rxbR00mm w1pp zllBVaaa
> + */
> b = peek_next(insn_byte_t, insn);
> - attr = inat_get_opcode_attribute(b);
> - if (inat_is_vex_prefix(attr)) {
> + if (b == X86_BYTE_VEX2 || b == X86_BYTE_VEX3 ||
> + b == X86_BYTE_EVEX ||
> + b == X86_BYTE_XOP) {
> insn_byte_t b2 = peek_nbyte_next(insn_byte_t, insn, 1);
> - if (!insn->x86_64) {
> + /*
> + * XOP: If the modrm.reg bits are 000, it's POP reg/mem.
> + */
> + if (b == X86_BYTE_XOP && X86_MODRM_REG(b2) == 0) {
> + goto vex_end;
> + }
> + else if (!insn->x86_64) {
> /*
>* In 32-bits mode, if the [7:6] bits (mod bits of
>* ModRM) on the second byte are not 11b, it is
> - * LDS or LES.
> + * LDS, LES or BOUND.
>*/
> if (X86_MODRM_MOD(b2) != 3)
> goto vex_end;
> }
> insn->vex_prefix.bytes[0] = b;
> insn->vex_prefix.bytes[1] = b2;
> - if (inat_is_vex3_pref
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Fri, May 16, 2014 at 09:31:37PM -0700, Eric W. Biederman wrote: > Greg Kroah-Hartman writes: > > > On Fri, May 16, 2014 at 01:49:59AM +, Serge Hallyn wrote: > >> > I think having to pick and choose what device nodes you want in a > >> > container is a good thing. Becides, you would have to do the same thing > >> > in the kernel anyway, what's wrong with userspace making the decision > >> > here, especially as it knows exactly what it wants to do much more so > >> > than the kernel ever can. > >> > >> For 'real' devices that sounds sensible. The thing about loop devices > >> is that we simply want to allow a container to say "give me a loop > >> device to use" and have it receive a unique loop device (or 3), without > >> having to pre-assign them. I think that would be cleaner to do using > >> a pseudofs and loop-control device, rather than having to have a > >> daemon in userspace on the host farming those out in response to > >> some, I don't know, dbus request? > > > > I agree that loop devices would be nice to have in a container, and that > > the existing loop interface doesn't really lend itself to that. So > > create a new type of thing that acts like a loop device in a container. > > But don't try to mess with the whole driver core just for a single type > > of device. > > Yes. Something like devpts (without the newinstance option). Built to > allow unprivileged users to create loopback devices. That's where I started, and I've got code, so I guess I'll clean it up and send patches. If the stance is that only system-wide CAP_SYS_ADMIN gets to do privileged block device ioctls, including reading partitions on a block device which has been assigned to a contiainer, then I guess that approach works well enough. > There is still a huge kettle of fish in with verifying a filesystem is > safe from a hostile user that has acess to the block device while the > filesystem is mounted. > > Having a few filesystems that are robust enough to trust with arbitrary > filesystem corruption would be very interesting. > > I assume unprivileged and hostile users because if you trusted the real > root inside of your container this would not be an issue. > > Eric > -- > 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/ -- 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/
[PATCHv2] staging: media: as102: replace custom dprintk() with dev_dbg()
don't reinvent dev_dbg(). remove dprintk() in as102_drv.c.
use the common kernel coding style.
Signed-off-by: Martin Kepplinger
---
this applies to next-20140516. any more suggestions?
more cleanup can be done when dprintk() is completely gone.
drivers/staging/media/as102/as102_drv.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/media/as102/as102_drv.c
b/drivers/staging/media/as102/as102_drv.c
index 09d64cd..e0ee618 100644
--- a/drivers/staging/media/as102/as102_drv.c
+++ b/drivers/staging/media/as102/as102_drv.c
@@ -31,10 +31,6 @@
#include "as102_fw.h"
#include "dvbdev.h"
-int as102_debug;
-module_param_named(debug, as102_debug, int, 0644);
-MODULE_PARM_DESC(debug, "Turn on/off debugging (default: off)");
-
int dual_tuner;
module_param_named(dual_tuner, dual_tuner, int, 0644);
MODULE_PARM_DESC(dual_tuner, "Activate Dual-Tuner config (default: off)");
@@ -74,7 +70,8 @@ static void as102_stop_stream(struct as102_dev_t *dev)
return;
if (as10x_cmd_stop_streaming(bus_adap) < 0)
- dprintk(debug, "as10x_cmd_stop_streaming failed\n");
+ dev_dbg(&dev->bus_adap.usb_dev->dev,
+ "as10x_cmd_stop_streaming failed\n");
mutex_unlock(&dev->bus_adap.lock);
}
@@ -112,14 +109,16 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
int ret = -EFAULT;
if (mutex_lock_interruptible(&dev->bus_adap.lock)) {
- dprintk(debug, "mutex_lock_interruptible(lock) failed !\n");
+ dev_dbg(&dev->bus_adap.usb_dev->dev,
+ "amutex_lock_interruptible(lock) failed !\n");
return -EBUSY;
}
switch (onoff) {
case 0:
ret = as10x_cmd_del_PID_filter(bus_adap, (uint16_t) pid);
- dprintk(debug, "DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n",
+ dev_dbg(&dev->bus_adap.usb_dev->dev,
+ "DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n",
index, pid, ret);
break;
case 1:
@@ -131,7 +130,7 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
filter.pid = pid;
ret = as10x_cmd_add_PID_filter(bus_adap, &filter);
- dprintk(debug,
+ dev_dbg(&dev->bus_adap.usb_dev->dev,
"ADD_PID_FILTER([%02d -> %02d], 0x%04x) ret = %d\n",
index, filter.idx, filter.pid, ret);
break;
--
1.7.10.4
--
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: BUG_ON drivers/char/random.c:986 (Was: perf: use after free in perf_remove_from_context)
On 05/16/2014 10:18 PM, Theodore Ts'o wrote:
> On Fri, May 16, 2014 at 05:46:22PM -0700, Hannes Frederic Sowa wrote:
>> > This should do the trick:
>> > dd if=/dev/urandom of=/dev/zero bs=67108707
>> >
>> > I suspect ee1de406ba6eb1 ("random: simplify accounting logic") as the
>> > culprit.
> Yep, that it's it. Thanks for noticing this so quickly! I'll push
> the following patch to Linus.
Peter, could you describe the infrastructure you're running on? I don't
think Dave or myself have ever hit this issue, and I wonder what made you
stumble on it.
Thanks,
Sasha
--
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/4] Fix coding style of if statement
The following pateches fix the errors and warnings in
dgnc_neo.c and dgnc_tty.c to meet kernel coding style.
ERROR: else should follow close brace '}'
ERROR: that open brace { should be on the previous line
WARNING: line over 80 characters
WARNING: braces {} are not necessary for single statement blocks
Masaru Nomura (4):
staging: dgnc: Fix indenting of if-else statement
staging: dgnc: dgnc_neo: Fix indenting of if statement
staging: dgnc: dgnc_neo: Fix conditional part of if statement
staging: dgnc: Remove unnecessary braces
drivers/staging/dgnc/dgnc_neo.c | 67 ++-
drivers/staging/dgnc/dgnc_tty.c | 42
2 files changed, 38 insertions(+), 71 deletions(-)
--
1.7.9.5
--
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/4] staging: dgnc: Fix indenting of if-else statement
Fix indenting of if-else statement in dgnc_neo.c and dgnc_tty.c
so that following else-if or else statement meets coding style.
Signed-off-by: Masaru Nomura
---
drivers/staging/dgnc/dgnc_neo.c | 48 +--
drivers/staging/dgnc/dgnc_tty.c | 36 ++---
2 files changed, 28 insertions(+), 56 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index cf22c7b..e87cf49 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -485,8 +485,7 @@ static inline void neo_parse_isr(struct dgnc_board *brd,
uint port)
DGNC_UNLOCK(ch->ch_lock, lock_flags);
}
DPR_INTR(("Port %d. XON detected in incoming
data\n", port));
- }
- else if (cause == UART_17158_XOFF_DETECT) {
+ } else if (cause == UART_17158_XOFF_DETECT) {
if (!(brd->channels[port]->ch_flags & CH_STOP))
{
DGNC_LOCK(ch->ch_lock, lock_flags);
ch->ch_flags |= CH_STOP;
@@ -511,8 +510,7 @@ static inline void neo_parse_isr(struct dgnc_board *brd,
uint port)
DGNC_LOCK(ch->ch_lock, lock_flags);
ch->ch_mostat |= UART_MCR_RTS;
DGNC_UNLOCK(ch->ch_lock, lock_flags);
- }
- else {
+ } else {
DGNC_LOCK(ch->ch_lock, lock_flags);
ch->ch_mostat &= ~(UART_MCR_RTS);
DGNC_UNLOCK(ch->ch_lock, lock_flags);
@@ -522,8 +520,7 @@ static inline void neo_parse_isr(struct dgnc_board *brd,
uint port)
DGNC_LOCK(ch->ch_lock, lock_flags);
ch->ch_mostat |= UART_MCR_DTR;
DGNC_UNLOCK(ch->ch_lock, lock_flags);
- }
- else {
+ } else {
DGNC_LOCK(ch->ch_lock, lock_flags);
ch->ch_mostat &= ~(UART_MCR_DTR);
DGNC_UNLOCK(ch->ch_lock, lock_flags);
@@ -624,8 +621,7 @@ static inline void neo_parse_lsr(struct dgnc_board *brd,
uint port)
/* Transfer data (if any) from Write Queue -> UART. */
neo_copy_data_from_queue_to_uart(ch);
- }
- else if (linestatus & UART_17158_TX_AND_FIFO_CLR) {
+ } else if (linestatus & UART_17158_TX_AND_FIFO_CLR) {
brd->intr_tx++;
ch->ch_intr_tx++;
DGNC_LOCK(ch->ch_lock, lock_flags);
@@ -834,8 +830,7 @@ static void neo_param(struct tty_struct *tty)
if (ch->ch_c_cflag & CREAD) {
ier |= (UART_IER_RDI | UART_IER_RLSI);
- }
- else {
+ } else {
ier &= ~(UART_IER_RDI | UART_IER_RLSI);
}
@@ -848,8 +843,7 @@ static void neo_param(struct tty_struct *tty)
!(ch->ch_c_cflag & CLOCAL))
{
ier |= UART_IER_MSI;
- }
- else {
+ } else {
ier &= ~UART_IER_MSI;
}
@@ -863,29 +857,25 @@ static void neo_param(struct tty_struct *tty)
if (ch->ch_digi.digi_flags & CTSPACE || ch->ch_c_cflag & CRTSCTS) {
neo_set_cts_flow_control(ch);
- }
- else if (ch->ch_c_iflag & IXON) {
+ } else if (ch->ch_c_iflag & IXON) {
/* If start/stop is set to disable, then we should disable flow
control */
if ((ch->ch_startc == _POSIX_VDISABLE) || (ch->ch_stopc ==
_POSIX_VDISABLE))
neo_set_no_output_flow_control(ch);
else
neo_set_ixon_flow_control(ch);
- }
- else {
+ } else {
neo_set_no_output_flow_control(ch);
}
if (ch->ch_digi.digi_flags & RTSPACE || ch->ch_c_cflag & CRTSCTS) {
neo_set_rts_flow_control(ch);
- }
- else if (ch->ch_c_iflag & IXOFF) {
+ } else if (ch->ch_c_iflag & IXOFF) {
/* If start/stop is set to disable, then we should disable flow
control */
if ((ch->ch_startc == _POSIX_VDISABLE) || (ch->ch_stopc ==
_POSIX_VDISABLE))
neo_set_no_input_flow_control(ch);
else
neo_set_ixoff_flow_control(ch);
- }
- else {
+ } else {
neo_set_no_input_flow_control(ch);
}
@@ -1227,8 +1217,7 @@ static void neo_copy_data_from_uart_to_queue(struct
channel_t *ch)
[PATCH 2/4] staging: dgnc: dgnc_neo: Fix indenting of if statement
Fix indenting of if statement in dgnc_neo.c so that an open brace
follows if-condition part to meet kernel coding style.
Signed-off-by: Masaru Nomura
---
drivers/staging/dgnc/dgnc_neo.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index e87cf49..8988346 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -840,8 +840,7 @@ static void neo_param(struct tty_struct *tty)
*/
if ((ch->ch_digi.digi_flags & CTSPACE) || (ch->ch_digi.digi_flags &
RTSPACE) ||
(ch->ch_c_cflag & CRTSCTS) || !(ch->ch_digi.digi_flags &
DIGI_FORCEDCD) ||
- !(ch->ch_c_cflag & CLOCAL))
- {
+ !(ch->ch_c_cflag & CLOCAL)) {
ier |= UART_IER_MSI;
} else {
ier &= ~UART_IER_MSI;
--
1.7.9.5
--
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 4/4] staging: dgnc: Remove unnecessary braces
Remove unnecessary braces of if-else statements in dgnc_neo.c and
dgnc_tty.c to meet kernel coding style.
Signed-off-by: Masaru Nomura
---
drivers/staging/dgnc/dgnc_neo.c | 20
drivers/staging/dgnc/dgnc_tty.c | 10 --
2 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index c211f9f..c4ab17b 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -828,11 +828,10 @@ static void neo_param(struct tty_struct *tty)
if (uart_lcr != lcr)
writeb(lcr, &ch->ch_neo_uart->lcr);
- if (ch->ch_c_cflag & CREAD) {
+ if (ch->ch_c_cflag & CREAD)
ier |= (UART_IER_RDI | UART_IER_RLSI);
- } else {
+ else
ier &= ~(UART_IER_RDI | UART_IER_RLSI);
- }
/*
* Have the UART interrupt on modem signal changes ONLY when
@@ -842,11 +841,10 @@ static void neo_param(struct tty_struct *tty)
|| (ch->ch_digi.digi_flags & RTSPACE)
|| (ch->ch_c_cflag & CRTSCTS)
|| !(ch->ch_digi.digi_flags & DIGI_FORCEDCD)
- || !(ch->ch_c_cflag & CLOCAL)) {
+ || !(ch->ch_c_cflag & CLOCAL))
ier |= UART_IER_MSI;
- } else {
+ else
ier &= ~UART_IER_MSI;
- }
ier |= UART_IER_THRI;
@@ -1216,11 +1214,10 @@ static void neo_copy_data_from_uart_to_queue(struct
channel_t *ch)
* The count can be any where from 0-3 bytes "off".
* Bizarre, but true.
*/
- if ((ch->ch_bd->dvid & 0xf0) >= UART_XR17E158_DVID) {
+ if ((ch->ch_bd->dvid & 0xf0) >= UART_XR17E158_DVID)
total -= 1;
- } else {
+ else
total -= 3;
- }
}
@@ -1423,11 +1420,10 @@ static int neo_drain(struct tty_struct *tty, uint
seconds)
rc = wait_event_interruptible(un->un_flags_wait, ((un->un_flags &
UN_EMPTY) == 0));
/* If ret is non-zero, user ctrl-c'ed us */
- if (rc) {
+ if (rc)
DPR_IOCTL(("%d Drain - User ctrl c'ed\n", __LINE__));
- } else {
+ else
DPR_IOCTL(("%d Drain wait finished.\n", __LINE__));
- }
return rc;
}
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index e432c04..cda2254 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -2549,17 +2549,15 @@ static int dgnc_set_modem_info(struct tty_struct *tty,
unsigned int command, uns
case TIOCMSET:
- if (arg & TIOCM_RTS) {
+ if (arg & TIOCM_RTS)
ch->ch_mostat |= UART_MCR_RTS;
- } else {
+ else
ch->ch_mostat &= ~(UART_MCR_RTS);
- }
- if (arg & TIOCM_DTR) {
+ if (arg & TIOCM_DTR)
ch->ch_mostat |= UART_MCR_DTR;
- } else {
+ else
ch->ch_mostat &= ~(UART_MCR_DTR);
- }
break;
--
1.7.9.5
--
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/4] staging: dgnc: dgnc_neo: Fix conditional part of if statement
Fix line over 80 characters of if-condition part and also
indent the lines to tell the difference between the condition and
body of the if statement.
Then I think we can keep the readability and meet coding style
with this change.
Signed-off-by: Masaru Nomura
---
drivers/staging/dgnc/dgnc_neo.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index 8988346..c211f9f 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -838,9 +838,11 @@ static void neo_param(struct tty_struct *tty)
* Have the UART interrupt on modem signal changes ONLY when
* we are in hardware flow control mode, or CLOCAL/FORCEDCD is not set.
*/
- if ((ch->ch_digi.digi_flags & CTSPACE) || (ch->ch_digi.digi_flags &
RTSPACE) ||
- (ch->ch_c_cflag & CRTSCTS) || !(ch->ch_digi.digi_flags &
DIGI_FORCEDCD) ||
- !(ch->ch_c_cflag & CLOCAL)) {
+ if ((ch->ch_digi.digi_flags & CTSPACE)
+ || (ch->ch_digi.digi_flags & RTSPACE)
+ || (ch->ch_c_cflag & CRTSCTS)
+ || !(ch->ch_digi.digi_flags & DIGI_FORCEDCD)
+ || !(ch->ch_c_cflag & CLOCAL)) {
ier |= UART_IER_MSI;
} else {
ier &= ~UART_IER_MSI;
--
1.7.9.5
--
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] Fix for possible null pointer dereference in auth.c
Hi
I have made a new patch according Sergei specification.
But there remains Tronds question though.
Best regards
Rickard Strandqvist
2014-05-16 14:19 GMT+02:00 Sergei Shtylyov :
> Hello.
>
>
> On 16-05-2014 1:56, Rickard Strandqvist wrote:
>
>> There is otherwise a risk of a possible null pointer dereference.
>
>
>> Was largely found by using a static code analysis program called cppcheck.
>
>
>> Signed-off-by: Rickard Strandqvist
>>
>> ---
>> net/sunrpc/auth.c | 10 +++---
>> 1 fil ändrad, 7 tillägg(+), 3 borttagningar(-)
>
>
>> diff --git a/net/sunrpc/auth.c b/net/sunrpc/auth.c
>> index 5285ead..3a55698 100644
>> --- a/net/sunrpc/auth.c
>> +++ b/net/sunrpc/auth.c
>> @@ -801,10 +801,14 @@ rpcauth_invalcred(struct rpc_task *task)
>> {
>> struct rpc_cred *cred = task->tk_rqstp->rq_cred;
>>
>> - dprintk("RPC: %5u invalidating %s cred %p\n",
>> - task->tk_pid, cred->cr_auth->au_ops->au_name, cred);
>> - if (cred)
>> + if (cred) {
>> + dprintk("RPC: %5u invalidating %s cred %p\n",
>> + task->tk_pid, cred->cr_auth->au_ops->au_name,
>> cred);
>> +
>> clear_bit(RPCAUTH_CRED_UPTODATE, &cred->cr_flags);
>> + }
>> + else
>
>
>} and *else* should be on the same line, and there should be {} in the
> *else* arm since there's {} in the *if* arm already, according to
> Documentation/CodingStyle.
>
>
>> + dprintk("RPC: %5u invalidating is NULL\n", task->tk_pid);
>
>
>That's not a proper English, I'm afraid.
>
>> }
>
>
> WBR, Sergei
>
>
From 210994905f7f7b13f6c621f110699f28fd134980 Mon Sep 17 00:00:00 2001
From: Rickard Strandqvist
Date: Sun, 11 May 2014 18:51:42 +0200
Subject: [PATCH] net: sunrpc: auth.c: Fix for possible null pointer dereference
There is otherwise a risk of a possible null pointer dereference.
Was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
---
net/sunrpc/auth.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/sunrpc/auth.c b/net/sunrpc/auth.c
index 5285ead..a9e1866 100644
--- a/net/sunrpc/auth.c
+++ b/net/sunrpc/auth.c
@@ -801,10 +801,14 @@ rpcauth_invalcred(struct rpc_task *task)
{
struct rpc_cred *cred = task->tk_rqstp->rq_cred;
- dprintk("RPC: %5u invalidating %s cred %p\n",
- task->tk_pid, cred->cr_auth->au_ops->au_name, cred);
- if (cred)
+ if (cred) {
+ dprintk("RPC: %5u invalidating %s cred %p\n",
+ task->tk_pid, cred->cr_auth->au_ops->au_name, cred);
+
clear_bit(RPCAUTH_CRED_UPTODATE, &cred->cr_flags);
+ } else {
+ dprintk("RPC: %5u cred pointer is 0", task->tk_pid);
+ }
}
int
--
1.7.10.4
Re: [PATCH 8/8] Kbuild: add inline-account tool to find inline bloat
> Patched the calls to nm and objdump - but it gave no output > when I ran the script. You have to compile with debug info on. -Andi -- 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] fs: Cleanup string initializations (char[] instead of char *)
On Sat, May 17, 2014 at 05:00:18PM +0200, Manuel Schölling wrote:
> Initializations like 'char *foo = "bar"' will create two variables: a static
> string and a pointer (foo) to that static string. Instead 'char foo[] = "bar"'
> will declare a single variable and will end up in shorter
> assembly (according to Jeff Garzik on the KernelJanitor's TODO list).
The hell it will. Compare assembler generated e.g. for 32bit x86 before
and after.
> {
> char *dp;
> char *status = "disabled";
> - const char * flags = "flags: ";
> + const char flags[] = "flags: ";
The first variant puts address of constant array into local variable
(on stack or in a register). The second one fills local _array_ - the
string itself goes on 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/
Re: [PATCH 1/3] FS/HPFS: convert printk to pr_foo()
They are all (except commented printks) rather serious filesystem errors,
so you should use at least pr_err.
Mikulas
On Thu, 15 May 2014, Fabian Frederick wrote:
> -No level printk in hptfs_error converted to pr_err
> (others to pr_warn or pr_info)
>
> This patch also fixes if/then/else checkpatch warnings
>
> Cc: Mikulas Patocka
> Cc: Andrew Morton
> Signed-off-by: Fabian Frederick
> ---
> fs/hpfs/alloc.c | 2 +-
> fs/hpfs/buffer.c | 12 ++--
> fs/hpfs/dir.c| 6 +++---
> fs/hpfs/dnode.c | 42 +-
> fs/hpfs/ea.c | 6 +++---
> fs/hpfs/inode.c | 3 ++-
> fs/hpfs/map.c| 17 ++---
> fs/hpfs/name.c | 11 ++-
> fs/hpfs/namei.c | 2 +-
> fs/hpfs/super.c | 55 ---
> 10 files changed, 89 insertions(+), 67 deletions(-)
>
> diff --git a/fs/hpfs/alloc.c b/fs/hpfs/alloc.c
> index 58b5106..f005046 100644
> --- a/fs/hpfs/alloc.c
> +++ b/fs/hpfs/alloc.c
> @@ -316,7 +316,7 @@ void hpfs_free_sectors(struct super_block *s, secno sec,
> unsigned n)
> struct quad_buffer_head qbh;
> __le32 *bmp;
> struct hpfs_sb_info *sbi = hpfs_sb(s);
> - /*printk("2 - ");*/
> + /*pr_info("2 - ");*/
> if (!n) return;
> if (sec < 0x12) {
> hpfs_error(s, "Trying to free reserved sector %08x", sec);
> diff --git a/fs/hpfs/buffer.c b/fs/hpfs/buffer.c
> index 139ef16..4b61be3 100644
> --- a/fs/hpfs/buffer.c
> +++ b/fs/hpfs/buffer.c
> @@ -55,7 +55,7 @@ void *hpfs_map_sector(struct super_block *s, unsigned
> secno, struct buffer_head
> if (bh != NULL)
> return bh->b_data;
> else {
> - printk("HPFS: hpfs_map_sector: read error\n");
> + pr_warn("HPFS: hpfs_map_sector: read error\n");
> return NULL;
> }
> }
> @@ -76,7 +76,7 @@ void *hpfs_get_sector(struct super_block *s, unsigned
> secno, struct buffer_head
> set_buffer_uptodate(bh);
> return bh->b_data;
> } else {
> - printk("HPFS: hpfs_get_sector: getblk failed\n");
> + pr_warn("HPFS: hpfs_get_sector: getblk failed\n");
> return NULL;
> }
> }
> @@ -93,7 +93,7 @@ void *hpfs_map_4sectors(struct super_block *s, unsigned
> secno, struct quad_buffe
> cond_resched();
>
> if (secno & 3) {
> - printk("HPFS: hpfs_map_4sectors: unaligned read\n");
> + pr_warn("HPFS: hpfs_map_4sectors: unaligned read\n");
> return NULL;
> }
>
> @@ -112,7 +112,7 @@ void *hpfs_map_4sectors(struct super_block *s, unsigned
> secno, struct quad_buffe
>
> qbh->data = data = kmalloc(2048, GFP_NOFS);
> if (!data) {
> - printk("HPFS: hpfs_map_4sectors: out of memory\n");
> + pr_warn("HPFS: hpfs_map_4sectors: out of memory\n");
> goto bail4;
> }
>
> @@ -145,7 +145,7 @@ void *hpfs_get_4sectors(struct super_block *s, unsigned
> secno,
> hpfs_lock_assert(s);
>
> if (secno & 3) {
> - printk("HPFS: hpfs_get_4sectors: unaligned read\n");
> + pr_warn("HPFS: hpfs_get_4sectors: unaligned read\n");
> return NULL;
> }
>
> @@ -161,7 +161,7 @@ void *hpfs_get_4sectors(struct super_block *s, unsigned
> secno,
> }
>
> if (!(qbh->data = kmalloc(2048, GFP_NOFS))) {
> - printk("HPFS: hpfs_get_4sectors: out of memory\n");
> + pr_warn("HPFS: hpfs_get_4sectors: out of memory\n");
> goto bail4;
> }
> return qbh->data;
> diff --git a/fs/hpfs/dir.c b/fs/hpfs/dir.c
> index 292b1ac..11ea936 100644
> --- a/fs/hpfs/dir.c
> +++ b/fs/hpfs/dir.c
> @@ -36,7 +36,7 @@ static loff_t hpfs_dir_lseek(struct file *filp, loff_t off,
> int whence)
> mutex_lock(&i->i_mutex);
> hpfs_lock(s);
>
> - /*printk("dir lseek\n");*/
> + /*pr_info("dir lseek\n");*/
> if (new_off == 0 || new_off == 1 || new_off == 11 || new_off == 12 ||
> new_off == 13) goto ok;
> pos = ((loff_t) hpfs_de_as_down_as_possible(s, hpfs_inode->i_dno) << 4)
> + 1;
> while (pos != new_off) {
> @@ -51,7 +51,7 @@ ok:
> mutex_unlock(&i->i_mutex);
> return new_off;
> fail:
> - /*printk("illegal lseek: %016llx\n", new_off);*/
> + /*pr_warn("illegal lseek: %016llx\n", new_off);*/
> hpfs_unlock(s);
> mutex_unlock(&i->i_mutex);
> return -ESPIPE;
> @@ -127,7 +127,7 @@ static int hpfs_readdir(struct file *file, struct
> dir_context *ctx)
> if (ctx->pos == 12)
> goto out;
> if (ctx->pos == 3 || ctx->pos == 4 || ctx->pos == 5) {
> - printk("HPFS: warning: pos==%d\n",(int)ctx->pos);
> + pr_warn("HPFS: warning: pos==%d\n", (int)ctx->pos);
> goto out;
> }
> if (ctx->pos == 0) {
> diff --git a/fs/hpfs/dnode.c b/fs/hp
Re: uprobes && shmem (Was: uprobes: Shift ->readpage check from __copy_insn() to uprobe_register())
On 05/16, Hugh Dickins wrote: > > On Fri, 16 May 2014, Hugh Dickins wrote: > > On Fri, 16 May 2014, Oleg Nesterov wrote: > > > shmem_getpage_gfp(). But, is there any way to figure out that this > > > inode/mapping/aops/whatever is actually shmem? > > > > On 3.15 and later, you're in luck: Hannes added bool shmem_mapping(mapping) > > in his 0cd6144aadd2 "mm + fs: prepare for non-page entries in page cache > > radix trees"; and I just checked, it builds for "tiny" !CONFIG_SHMEM too. > > > > If you're backporting to an earlier kernel, it would probably be best > > to add in a very small patch, extracting just shmem_mapping() and its > > linux/mm.h declarations from 0cd6144aadd2. > > Looking into something else, I've just been reminded of > mapping_cap_swap_backed(mapping): mm/madvise.c has been using that test > for a year. It also returns true on swapper_space, the imaginary mapping > you get from a PageSwapCache page: so I suppose it would be wrong to make > Hannes's shmem_mapping() a wrapper to that. But for any backport of your > change, it would better than extracting part of 0cd6144aadd2. Yes, this should work, swap_address_space() can't be seen as ->i_mapping, > (Sorry for going on about backporting, when you may have no such intention.) No, no, thanks for additional info. Perhaps we will actually backport this, at least in rhel. Although in the latter case perhaps it would be better to extract shmem_mapping() from 0cd6144aadd2, it is simple and straightforward. Thanks, Oleg. -- 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: BUG_ON drivers/char/random.c:986 (Was: perf: use after free in perf_remove_from_context)
On Sat, May 17, 2014 at 12:24:32PM -0400, Sasha Levin wrote:
> On 05/16/2014 10:18 PM, Theodore Ts'o wrote:
> > On Fri, May 16, 2014 at 05:46:22PM -0700, Hannes Frederic Sowa wrote:
> >> > This should do the trick:
> >> > dd if=/dev/urandom of=/dev/zero bs=67108707
> >> >
> >> > I suspect ee1de406ba6eb1 ("random: simplify accounting logic") as the
> >> > culprit.
> > Yep, that it's it. Thanks for noticing this so quickly! I'll push
> > the following patch to Linus.
>
> Peter, could you describe the infrastructure you're running on? I don't
> think Dave or myself have ever hit this issue, and I wonder what made you
> stumble on it.
I'm running it on a WSP-EP, 2 nodes, 6 cores per node, 2 threads per
core for a total of 24 cpus.
I'm running trinity as user, and using:
MALLOC_CHECK_=0 ./trinity -xinit_module -xreboot -xshutdown -xunshare
-xnfsservctl -xclock_nanosleep -xuselib -xumount -xmount -m --quiet -C 400 -l
off -xmremap
to run it.
I'm currently also running with syscall and a few other trace bits
enabled, but I suppose that shouldn't affect things too much.
The machine is running Debian wheezy with a few choice testing bits.
pgpE3FyvLCayQ.pgp
Description: PGP signature
[PATCH] Staging: rtl8192u: Remove old WIRELESS_EXT support
Remove support for building against ancient WIRELESS_EXT versions,
only leaving support for the current version: 22
Signed-off-by: Joel Pelaez Jorge
---
drivers/staging/rtl8192u/ieee80211/ieee80211.h| 14 -
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 5 +--
drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c | 38 ++-
drivers/staging/rtl8192u/r8192U_core.c| 6 +---
drivers/staging/rtl8192u/r8192U_wx.c | 20 +---
5 files changed, 5 insertions(+), 78 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
index cac2056..3b40b61 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
@@ -354,12 +354,10 @@ enum _ReasonCode{
#define ieee80211_wx_get_scan ieee80211_wx_get_scan_rsl
#define ieee80211_wx_set_encodeieee80211_wx_set_encode_rsl
#define ieee80211_wx_get_encodeieee80211_wx_get_encode_rsl
-#if WIRELESS_EXT >= 18
#define ieee80211_wx_set_mlme ieee80211_wx_set_mlme_rsl
#define ieee80211_wx_set_auth ieee80211_wx_set_auth_rsl
#define ieee80211_wx_set_encode_extieee80211_wx_set_encode_ext_rsl
#define ieee80211_wx_get_encode_extieee80211_wx_get_encode_ext_rsl
-#endif
typedef struct ieee_param {
@@ -392,16 +390,6 @@ typedef struct ieee_param {
}ieee_param;
-#if WIRELESS_EXT < 17
-#define IW_QUAL_QUAL_INVALID 0x10
-#define IW_QUAL_LEVEL_INVALID 0x20
-#define IW_QUAL_NOISE_INVALID 0x40
-#define IW_QUAL_QUAL_UPDATED 0x1
-#define IW_QUAL_LEVEL_UPDATED 0x2
-#define IW_QUAL_NOISE_UPDATED 0x4
-#endif
-
-
// linux under 2.6.9 release may not support it, so modify it for common use
#define MSECS(t) msecs_to_jiffies(t)
#define msleep_interruptible_rsl msleep_interruptible
@@ -2398,7 +2386,6 @@ extern int ieee80211_wx_set_encode(struct
ieee80211_device *ieee,
extern int ieee80211_wx_get_encode(struct ieee80211_device *ieee,
struct iw_request_info *info,
union iwreq_data *wrqu, char *key);
-#if WIRELESS_EXT >= 18
extern int ieee80211_wx_get_encode_ext(struct ieee80211_device *ieee,
struct iw_request_info *info,
union iwreq_data *wrqu, char *extra);
@@ -2411,7 +2398,6 @@ extern int ieee80211_wx_set_auth(struct ieee80211_device
*ieee,
extern int ieee80211_wx_set_mlme(struct ieee80211_device *ieee,
struct iw_request_info *info,
union iwreq_data *wrqu, char *extra);
-#endif
extern int ieee80211_wx_set_gen_ie(struct ieee80211_device *ieee, u8 *ie,
size_t len);
/* ieee80211_softmac.c */
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
index a98414a..b32f965 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
@@ -950,7 +950,6 @@ int ieee80211_rx(struct ieee80211_device *ieee, struct
sk_buff *skb,
//IEEE80211_DEBUG_DATA(IEEE80211_DL_DATA, skb->data, skb->len);
#ifdef NOT_YET
-#if WIRELESS_EXT > 15
/* Put this code here so that we avoid duplicating it in all
* Rx paths. - Jean II */
#ifdef IW_WIRELESS_SPY /* defined in iw_handler.h */
@@ -964,18 +963,16 @@ int ieee80211_rx(struct ieee80211_device *ieee, struct
sk_buff *skb,
wireless_spy_update(dev, hdr->addr2, &wstats);
}
#endif /* IW_WIRELESS_SPY */
-#endif /* WIRELESS_EXT > 15 */
hostap_update_rx_stats(local->ap, hdr, rx_stats);
#endif
-#if WIRELESS_EXT > 15
if (ieee->iw_mode == IW_MODE_MONITOR) {
ieee80211_monitor_rx(ieee, skb, rx_stats);
stats->rx_packets++;
stats->rx_bytes += skb->len;
return 1;
}
-#endif
+
if (ieee->host_decrypt) {
int idx = 0;
if (skb->len >= hdrlen + 3)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
index bdf67ec..b2660fe 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
@@ -194,37 +194,7 @@ static inline char *rtl819x_translate_scan(struct
ieee80211_device *ieee,
iwe.u.data.length = p - custom;
if (iwe.u.data.length)
start = iwe_stream_add_point(info, start, stop, &iwe, custom);
-#if (WIRELESS_EXT < 18)
- if (ieee->wpa_enabled && network->wpa_ie_len){
- char buf[MAX_WPA_IE_LEN * 2 + 30];
- // printk("WPA IE\n");
- u8 *p = buf;
- p += sprintf(p, "wpa_ie=");
- for (i = 0; i < network->wpa_ie_len; i++) {
- p += sprintf(p, "%02x", network->wpa_ie[i]);
- }
-
- mem
[PATCH] i2c: busses: i2c-pxa.c: Fix for possible null pointer dereference
There is otherwise a risk of a possible null pointer dereference.
Was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/i2c/busses/i2c-pxa.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index bbe6dfb..dbe5ebe 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1269,7 +1269,9 @@ eremap:
eclk:
kfree(i2c);
emalloc:
- release_mem_region(res->start, resource_size(res));
+ if(res) {
+ release_mem_region(res->start, resource_size(res));
+ }
return ret;
}
--
1.7.10.4
--
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] infiniband: hw: ehca: ehca_mrmw.c: Fix for possible null pointer dereference
There is otherwise a risk of a possible null pointer dereference.
Was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/infiniband/hw/ehca/ehca_mrmw.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_mrmw.c
b/drivers/infiniband/hw/ehca/ehca_mrmw.c
index 3488e8c..1fe4344 100644
--- a/drivers/infiniband/hw/ehca/ehca_mrmw.c
+++ b/drivers/infiniband/hw/ehca/ehca_mrmw.c
@@ -316,9 +316,8 @@ struct ib_mr *ehca_reg_user_mr(struct ib_pd *pd, u64 start,
u64 length,
{
struct ib_mr *ib_mr;
struct ehca_mr *e_mr;
- struct ehca_shca *shca =
- container_of(pd->device, struct ehca_shca, ib_device);
- struct ehca_pd *e_pd = container_of(pd, struct ehca_pd, ib_pd);
+ struct ehca_shca *shca;
+ struct ehca_pd *e_pd;
struct ehca_mr_pginfo pginfo;
int ret, page_shift;
u32 num_kpages;
@@ -330,6 +329,9 @@ struct ib_mr *ehca_reg_user_mr(struct ib_pd *pd, u64 start,
u64 length,
return ERR_PTR(-EFAULT);
}
+ shca = container_of(pd->device, struct ehca_shca, ib_device);
+ e_pd = container_of(pd, struct ehca_pd, ib_pd);
+
if (((mr_access_flags & IB_ACCESS_REMOTE_WRITE) &&
!(mr_access_flags & IB_ACCESS_LOCAL_WRITE)) ||
((mr_access_flags & IB_ACCESS_REMOTE_ATOMIC) &&
--
1.7.10.4
--
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 5/9] I2C: Add smbus quick read/write helper function
> >2) It uses a parameter for the r/w bit. Make sense to me, since this bit > >is the information we send to the device. quick_read doesn't make sense > >to me. We don't receive a bit from the device. > > > > Hi Wolfram: > Great thanks for your review. Ok. I will follow commit 67c2e665 to > bring i2c_smbus_write_quick(struct i2c_client *client, u8 value) > back. > > BTW, how about i2c_probe_func_quick_read()? Should we replace it > with the original i2c_smbus_write_quick()? As said above "quick_read doesn't make sense to me. We don't receive a bit from the device." Start implementing and you will see why we don't need it :) signature.asc Description: Digital signature
[PATCH] iommu: fsl_pamu.c: Fix for possible null pointer dereference
There is otherwise a risk of a possible null pointer dereference.
Was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/iommu/fsl_pamu.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index cba0498..b99dd88 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -592,8 +592,7 @@ found_cpu_node:
/* advance to next node in cache hierarchy */
node = of_find_node_by_phandle(*prop);
if (!node) {
- pr_debug("Invalid node for cache hierarchy %s\n",
- node->full_name);
+ pr_debug("Invalid node for cache hierarchy\n");
return ~(u32)0;
}
}
--
1.7.10.4
--
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] Fix for possible null pointer dereference in auth.c
On Sat, May 17, 2014 at 12:36 PM, Rickard Strandqvist
wrote:
> Hi
>
> I have made a new patch according Sergei specification.
>
I'll be happy to apply this patch once someone explains to me why we
can't just remove that check for cred != NULL, however I'm not
applying a patch purely in order to silence a warning from cppcheck.
Cheers,
Trond
> But there remains Tronds question though.
>
> Best regards
> Rickard Strandqvist
>
>
> 2014-05-16 14:19 GMT+02:00 Sergei Shtylyov
> :
>> Hello.
>>
>>
>> On 16-05-2014 1:56, Rickard Strandqvist wrote:
>>
>>> There is otherwise a risk of a possible null pointer dereference.
>>
>>
>>> Was largely found by using a static code analysis program called cppcheck.
>>
>>
>>> Signed-off-by: Rickard Strandqvist
>>>
>>> ---
>>> net/sunrpc/auth.c | 10 +++---
>>> 1 fil ändrad, 7 tillägg(+), 3 borttagningar(-)
>>
>>
>>> diff --git a/net/sunrpc/auth.c b/net/sunrpc/auth.c
>>> index 5285ead..3a55698 100644
>>> --- a/net/sunrpc/auth.c
>>> +++ b/net/sunrpc/auth.c
>>> @@ -801,10 +801,14 @@ rpcauth_invalcred(struct rpc_task *task)
>>> {
>>> struct rpc_cred *cred = task->tk_rqstp->rq_cred;
>>>
>>> - dprintk("RPC: %5u invalidating %s cred %p\n",
>>> - task->tk_pid, cred->cr_auth->au_ops->au_name, cred);
>>> - if (cred)
>>> + if (cred) {
>>> + dprintk("RPC: %5u invalidating %s cred %p\n",
>>> + task->tk_pid, cred->cr_auth->au_ops->au_name,
>>> cred);
>>> +
>>> clear_bit(RPCAUTH_CRED_UPTODATE, &cred->cr_flags);
>>> + }
>>> + else
>>
>>
>>} and *else* should be on the same line, and there should be {} in the
>> *else* arm since there's {} in the *if* arm already, according to
>> Documentation/CodingStyle.
>>
>>
>>> + dprintk("RPC: %5u invalidating is NULL\n", task->tk_pid);
>>
>>
>>That's not a proper English, I'm afraid.
>>
>>> }
>>
>>
>> WBR, Sergei
>>
>>
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.mykleb...@primarydata.com
--
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] isdn: hisax: l3dss1.c: Fix for possible null pointer dereference
There is otherwise a risk of a possible null pointer dereference.
Was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/isdn/hisax/l3dss1.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/isdn/hisax/l3dss1.c b/drivers/isdn/hisax/l3dss1.c
index cda7006..3ea6257 100644
--- a/drivers/isdn/hisax/l3dss1.c
+++ b/drivers/isdn/hisax/l3dss1.c
@@ -2208,8 +2208,12 @@ static int l3dss1_cmd_global(struct PStack *st,
isdn_ctrl *ic)
{ free_invoke_id(st, id);
return (-2);
}
- pc->prot.dss1.ll_id = ic->parm.dss1_io.ll_id; /*
remember id */
- pc->prot.dss1.proc = ic->parm.dss1_io.proc; /* and
procedure */
+
+ if (pc)
+ {
+ pc->prot.dss1.ll_id = ic->parm.dss1_io.ll_id;
/* remember id */
+ pc->prot.dss1.proc = ic->parm.dss1_io.proc; /*
and procedure */
+ }
if (!(skb = l3_alloc_skb(l)))
{ free_invoke_id(st, id);
--
1.7.10.4
--
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 6/9] I2C: Add smbus word/block process call helper function
> >BTW what were your test scenarios for these functions and smbus quick? > > > > From ACPI spec, Read/Write quick and Word/Block process call > protocol will be used by Bios ACPI code. But so far, I don't find > such machines. So these functions has not been tested. Uh oh, I have some trouble adding untested code. Can't we add until we have a user to verify it? BTW I have to review the other patches later, so please wait before resending the series. signature.asc Description: Digital signature
[PATCH] isdn: hisax: l3ni1.c: Fix for possible null pointer dereference
There is otherwise a risk of a possible null pointer dereference.
Was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/isdn/hisax/l3ni1.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/isdn/hisax/l3ni1.c b/drivers/isdn/hisax/l3ni1.c
index 0df6691..367b9d6 100644
--- a/drivers/isdn/hisax/l3ni1.c
+++ b/drivers/isdn/hisax/l3ni1.c
@@ -2064,8 +2064,12 @@ static int l3ni1_cmd_global(struct PStack *st, isdn_ctrl
*ic)
{ free_invoke_id(st, id);
return (-2);
}
- pc->prot.ni1.ll_id = ic->parm.ni1_io.ll_id; /* remember
id */
- pc->prot.ni1.proc = ic->parm.ni1_io.proc; /* and
procedure */
+
+ if (pc)
+ {
+ pc->prot.ni1.ll_id = ic->parm.ni1_io.ll_id; /*
remember id */
+ pc->prot.ni1.proc = ic->parm.ni1_io.proc; /*
and procedure */
+ }
if (!(skb = l3_alloc_skb(l)))
{ free_invoke_id(st, id);
--
1.7.10.4
--
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] i2c: busses: i2c-pxa.c: Fix for possible null pointer dereference
On Sat, May 17, 2014 at 07:14:08PM +0200, Rickard Strandqvist wrote:
> There is otherwise a risk of a possible null pointer dereference.
>
> Was largely found by using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/i2c/busses/i2c-pxa.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
> index bbe6dfb..dbe5ebe 100644
> --- a/drivers/i2c/busses/i2c-pxa.c
> +++ b/drivers/i2c/busses/i2c-pxa.c
> @@ -1269,7 +1269,9 @@ eremap:
> eclk:
> kfree(i2c);
> emalloc:
> - release_mem_region(res->start, resource_size(res));
> + if(res) {
> + release_mem_region(res->start, resource_size(res));
> + }
> return ret;
> }
>
This looks incorrect.
request_mem_region, which I believe is a prerequisite for this function
may not be called when you jump here.
--
Mateusz Guzik
--
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] macintosh: windfarm_pm121.c: Fix for possible null pointer dereference
There is otherwise a risk of a possible null pointer dereference.
Was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/macintosh/windfarm_pm121.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/macintosh/windfarm_pm121.c
b/drivers/macintosh/windfarm_pm121.c
index 7fe58b0..b350fb8 100644
--- a/drivers/macintosh/windfarm_pm121.c
+++ b/drivers/macintosh/windfarm_pm121.c
@@ -555,8 +555,18 @@ static void pm121_create_sys_fans(int loop_id)
pid_param.interval = PM121_SYS_INTERVAL;
pid_param.history_len = PM121_SYS_HISTORY_SIZE;
pid_param.itarget = param->itarget;
- pid_param.min = control->ops->get_min(control);
- pid_param.max = control->ops->get_max(control);
+ if(control)
+ {
+ pid_param.min = control->ops->get_min(control);
+ pid_param.max = control->ops->get_max(control);
+ } else {
+ /*
+* This is probably not the right!?
+* Perhaps goto fail if control == NULL above?
+*/
+ pid_param.min = 0;
+ pid_param.max = 0;
+ }
wf_pid_init(&pm121_sys_state[loop_id]->pid, &pid_param);
@@ -571,7 +581,7 @@ static void pm121_create_sys_fans(int loop_id)
control the same control */
printk(KERN_WARNING "pm121: failed to set up %s loop "
"setting \"%s\" to max speed.\n",
- loop_names[loop_id], control->name);
+ loop_names[loop_id], control ? control->name : "uninitialized
value");
if (control)
wf_control_set_max(control);
--
1.7.10.4
--
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/
