[PATCH v2] mm/zswap: Check all pool pages instead of one pool pages
zswap can support multiple swapfiles. So we need to check
all zbud pool pages in zswap.
Version 2:
* add *total_zbud_pages* in zbud to record all the pages in pools
* move the updating of pool pages statistics to
alloc_zbud_page/free_zbud_page to hide the details
Signed-off-by: Cai Liu
---
include/linux/zbud.h |2 +-
mm/zbud.c| 44
mm/zswap.c |4 ++--
3 files changed, 35 insertions(+), 15 deletions(-)
diff --git a/include/linux/zbud.h b/include/linux/zbud.h
index 2571a5c..1dbc13e 100644
--- a/include/linux/zbud.h
+++ b/include/linux/zbud.h
@@ -17,6 +17,6 @@ void zbud_free(struct zbud_pool *pool, unsigned long handle);
int zbud_reclaim_page(struct zbud_pool *pool, unsigned int retries);
void *zbud_map(struct zbud_pool *pool, unsigned long handle);
void zbud_unmap(struct zbud_pool *pool, unsigned long handle);
-u64 zbud_get_pool_size(struct zbud_pool *pool);
+u64 zbud_get_pool_size(void);
#endif /* _ZBUD_H_ */
diff --git a/mm/zbud.c b/mm/zbud.c
index 9451361..711aaf4 100644
--- a/mm/zbud.c
+++ b/mm/zbud.c
@@ -52,6 +52,13 @@
#include
#include
+/*
+* statistics
+**/
+
+/* zbud pages in all pools */
+static u64 total_zbud_pages;
+
/*
* Structures
*/
@@ -142,10 +149,28 @@ static struct zbud_header *init_zbud_page(struct page
*page)
return zhdr;
}
+static struct page *alloc_zbud_page(struct zbud_pool *pool, gfp_t gfp)
+{
+ struct page *page;
+
+ page = alloc_page(gfp);
+
+ if (page) {
+ pool->pages_nr++;
+ total_zbud_pages++;
+ }
+
+ return page;
+}
+
+
/* Resets the struct page fields and frees the page */
-static void free_zbud_page(struct zbud_header *zhdr)
+static void free_zbud_page(struct zbud_pool *pool, struct zbud_header *zhdr)
{
__free_page(virt_to_page(zhdr));
+
+ pool->pages_nr--;
+ total_zbud_pages--;
}
/*
@@ -279,11 +304,10 @@ int zbud_alloc(struct zbud_pool *pool, int size, gfp_t
gfp,
/* Couldn't find unbuddied zbud page, create new one */
spin_unlock(>lock);
- page = alloc_page(gfp);
+ page = alloc_zbud_page(pool, gfp);
if (!page)
return -ENOMEM;
spin_lock(>lock);
- pool->pages_nr++;
zhdr = init_zbud_page(page);
bud = FIRST;
@@ -349,8 +373,7 @@ void zbud_free(struct zbud_pool *pool, unsigned long handle)
if (zhdr->first_chunks == 0 && zhdr->last_chunks == 0) {
/* zbud page is empty, free */
list_del(>lru);
- free_zbud_page(zhdr);
- pool->pages_nr--;
+ free_zbud_page(pool, zhdr);
} else {
/* Add to unbuddied list */
freechunks = num_free_chunks(zhdr);
@@ -447,8 +470,7 @@ next:
* Both buddies are now free, free the zbud page and
* return success.
*/
- free_zbud_page(zhdr);
- pool->pages_nr--;
+ free_zbud_page(pool, zhdr);
spin_unlock(>lock);
return 0;
} else if (zhdr->first_chunks == 0 ||
@@ -496,14 +518,12 @@ void zbud_unmap(struct zbud_pool *pool, unsigned long
handle)
/**
* zbud_get_pool_size() - gets the zbud pool size in pages
- * @pool: pool whose size is being queried
*
- * Returns: size in pages of the given pool. The pool lock need not be
- * taken to access pages_nr.
+ * Returns: size in pages of all the zbud pools.
*/
-u64 zbud_get_pool_size(struct zbud_pool *pool)
+u64 zbud_get_pool_size(void)
{
- return pool->pages_nr;
+ return total_zbud_pages;
}
static int __init init_zbud(void)
diff --git a/mm/zswap.c b/mm/zswap.c
index 5a63f78..ef44d9d 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -291,7 +291,7 @@ static void zswap_free_entry(struct zswap_tree *tree,
zbud_free(tree->pool, entry->handle);
zswap_entry_cache_free(entry);
atomic_dec(_stored_pages);
- zswap_pool_pages = zbud_get_pool_size(tree->pool);
+ zswap_pool_pages = zbud_get_pool_size();
}
/* caller must hold the tree lock */
@@ -716,7 +716,7 @@ static int zswap_frontswap_store(unsigned type, pgoff_t
offset,
/* update stats */
atomic_inc(_stored_pages);
- zswap_pool_pages = zbud_get_pool_size(tree->pool);
+ zswap_pool_pages = zbud_get_pool_size();
return 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] clk: export __clk_get_hw for re-use in others
On Sun, Jan 19, 2014 at 9:37 AM, Greg KH wrote:
> On Sun, Jan 19, 2014 at 02:55:07PM +0900, SeongJae Park wrote:
>> Following build comes while modprobe process:
>> > ERROR: "__clk_get_hw" [drivers/clk/clk-max77686.ko] undefined!
>> > make[2]: *** [__modpost] Error 1
>> > make[1]: *** [modules] Error 2
>>
>> Export the symbol to fix it and for other part's usecase.
>>
>> Signed-off-by: SeongJae Park
>> ---
>> drivers/clk/clk.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index 2b38dc9..3883fba 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -575,6 +575,7 @@ struct clk_hw *__clk_get_hw(struct clk *clk)
>> {
>> return !clk ? NULL : clk->hw;
>> }
>> +EXPORT_SYMBOL_GPL(__clk_get_hw);
>
> __ functions should usually only be for "internal" use, why does this
> get exported to modules? Why not just put it in a .h file?
It was originally used only within the clock core but it is sensible
for hardware-specific clock drivers to use this as well. I plan to
audit all of the double-underscore functions in
include/linux/clk-provider.h for 3.15.
Regards,
Mike
>
> 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/
Re: [PATCH] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
Hi Philip,
On Fri, Jan 17, 2014 at 8:06 PM, Philip Balister wrote:
> On 01/16/2014 12:53 PM, Srikanth Thokala wrote:
>>
>> This is the driver for the AXI Video Direct Memory Access (AXI
>> VDMA) core, which is a soft Xilinx IP core that provides high-
>> bandwidth direct memory access between memory and AXI4-Stream
>> type video target peripherals. The core provides efficient two
>> dimensional DMA operations with independent asynchronous read
>> and write channel operation.
>>
>
> [snip]
>
>
>> +/**
>> + * xilinx_vdma_start - Start VDMA channel
>> + * @chan: Driver specific VDMA channel
>> + */
>> +static void xilinx_vdma_start(struct xilinx_vdma_chan *chan)
>> +{
>> + int loop = XILINX_VDMA_LOOP_COUNT + 1;
>> +
>> + vdma_ctrl_set(chan, XILINX_VDMA_REG_DMACR,
>> XILINX_VDMA_DMACR_RUNSTOP);
>> +
>> + /* Wait for the hardware to start */
>> + while (loop)
>
>
>
> loop-- ?
I will fix it in v2.
Thanks
Srikanth
--
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] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
Hi Levente,
On Thu, Jan 16, 2014 at 11:57 PM, Levente Kurusa wrote:
> Hello,
>
> On 01/16/2014 06:53 PM, Srikanth Thokala wrote:
>> This is the driver for the AXI Video Direct Memory Access (AXI
>> VDMA) core, which is a soft Xilinx IP core that provides high-
>> bandwidth direct memory access between memory and AXI4-Stream
>> type video target peripherals. The core provides efficient two
>> dimensional DMA operations with independent asynchronous read
>> and write channel operation.
>>
>> This module works on Zynq (ARM Based SoC) and Microblaze platforms.
>>
>> Signed-off-by: Srikanth Thokala
>> ---
>
> Just a few suggestions and fixes.
>
>> NOTE:
>> 1. Created a separate directory 'dma/xilinx' as Xilinx has two more
>>DMA IPs and we are also planning to upstream these drivers soon.
>> 2. Rebased on v3.13.0-rc8
>> ---
>> .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt | 71 +
>> .../bindings/dma/xilinx/xilinx_vdma_test.txt | 39 +
>> drivers/dma/Kconfig| 23 +
>> drivers/dma/Makefile |1 +
>> drivers/dma/xilinx/Makefile|2 +
>> drivers/dma/xilinx/xilinx_vdma.c | 1497
>>
>> drivers/dma/xilinx/xilinx_vdma_test.c | 629
>> 7 files changed, 2262 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
>> create mode 100644
>> Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma_test.txt
>> create mode 100644 drivers/dma/xilinx/Makefile
>> create mode 100644 drivers/dma/xilinx/xilinx_vdma.c
>> create mode 100644 drivers/dma/xilinx/xilinx_vdma_test.c
>>
>> diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
>> b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
>> new file mode 100644
>> index 000..3f5c428
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
>> @@ -0,0 +1,71 @@
>> +Xilinx AXI VDMA engine, it does transfers between memory and video devices.
>> +It can be configured to have one channel or two channels. If configured
>> +as two channels, one is to transmit to the video device and another is
>> +to receive from the video device.
>> +
>> +Required properties:
>> +- compatible: Should be "xlnx,axi-vdma-1.00.a"
>> +- #dma-cells: Should be <1>, see "dmas" property below
>> +- reg: Should contain VDMA registers location and length.
>> +- interrupts: Should contain per channel VDMA interrupts.
>> +- compatible (child node): It should be either "xlnx,axi-vdma-mm2s-channel"
>> or
>> + "xlnx,axi-vdma-s2mm-channel". It depends on the hardware design and it
>> + can also have both channels.
>> +- xlnx,device-id: Should contain device number in each channel. It should be
>> + {0,1,2...so on} to the number of VDMA devices configured in hardware.
>> +- xlnx,num-fstores: Should be the number of framebuffers as configured in
>> h/w.
>> +- xlnx,data-width: Should contain the stream data width, takes {32,64...so
>> on}.
>> +- xlnx,flush-fsync: (Optional) Tells whether which channel to Flush on
>> Fsync.
>> + It takes following values:
>> + {1}, flush both channels
>> + {2}, flush mm2s channel
>> + {3}, flush s2mm channel
>> +- xlnx,include-sg: (Optional) Tells whether configured for Scatter-mode in
>> + the hardware.
>> +- xlnx,include-dre: (Optional) Tells whether hardware is configured for Data
>> + Realignment Engine.
>> +- xlnx,genlock-mode: (Optional) Tells whether Genlock synchornisation is
>
> s/synchornisation/synchronization
Sure, will take care.
>
>> + enabled/disabled in hardware.
>> +
>> +Example:
>> +
>> +
>> +axi_vdma_0: axivdma@4003 {
>> + compatible = "xlnx,axi-vdma-1.00.a";
>> + #dma_cells = <1>;
>> + reg = < 0x4003 0x1 >;
>> + xlnx,flush-fsync = <0x1>;
>> + dma-channel@4003 {
>> + compatible = "xlnx,axi-vdma-mm2s-channel";
>> + interrupts = < 0 54 4 >;
>> + xlnx,num-fstores = <0x8>;
>> + xlnx,device-id = <0x0>;
>> + xlnx,datawidth = <0x40>;
>> + } ;
>> + dma-channel@40030030 {
>> + compatible = "xlnx,axi-vdma-s2mm-channel";
>> + interrupts = < 0 53 4 >;
>> + xlnx,num-fstores = <0x8>;
>> + xlnx,device-id = <0x0>;
>> + xlnx,datawidth = <0x40>;
>> + } ;
>> +} ;
>> +
>> +
>> +* Xilinx Video DMA client
>> +
>> +Required properties:
>> +- dmas: a list of <[Video DMA device phandle] [Channel ID]> pairs,
>> + where Channel ID is '0' for write/tx and '1' for read/rx
>> + channel.
>> +- dma-names: a list of DMA channel names, one per "dmas" entry
>> +
>> +VDMA Test Client Example:
>> ++
>> +
>> +vdmatest_0: vdmatest@0 {
>> + compatible ="xlnx,axi-vdma-test-1.00.a";
>> + dmas = <_vdma_0 0
>> + _vdma_0 1>;
>> + dma-names =
[PATCH V2] doc/kmemcheck: add kmemcheck to kernel-parameters
Add "kmemcheck=xx" to Documentation/kernel-parameters.txt. Signed-off-by: Xishi Qiu --- Documentation/kernel-parameters.txt |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 50680a5..671de56 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1415,6 +1415,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Valid arguments: on, off Default: on + kmemcheck= [X86] Boot-time kmemcheck enable/disable/one-shot mode + Valid arguments: 0, 1, 2 + kmemcheck=0 (disabled) + kmemcheck=1 (enabled) + kmemcheck=2 (one-shot mode) + Default: 2 (one-shot mode) + kstack=N[X86] Print N words from the kernel stack in oops dumps. -- 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/
Re: [PATCH 3/4] fix module autoloading for ACPI enumerated devices
On 01/17/2014 05:57 PM, Mark Brown wrote:
On Fri, Jan 17, 2014 at 09:37:56AM +0200, Jarkko Nikula wrote:
Sidenote: actually this modalias/module loading issue is different
and not related to stable ACPI i2c/spi slave device names.
Oh, I'd been under the impression that it was the rewrite that was
triggering this?
IIRC issue has been there since when ACPI slave device support was added.
I have a partial fix for it in cf9eb39c6f7b ("spi: Fix modalias for ACPI
enumerated SPI devices") and when doing similar change for i2c Rui
pointed me that he has a better fix that takes care of _CID string and
platform code too.
--
Jarkko
--
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, quirks: Add workaround for AMD F16h Erratum792
* Aravind Gopalakrishnan wrote: > The workaround for this Erratum is included in AGESA. But BIOSes spun > only after Jan2014 will have the fix (atleast server versions of the > chip). The erratum affects both client and server platforms and since > we cannot say with certainity that ALL BIOSes on systems out in the > field will have the fix, we should probably insulate ourselves in case > BIOS does not do the right thing or someone is using old BIOSes. > > Refer Revision Guide for AMD F16h models 00h-0fh, document 51810 > Rev. 3.04, November2013 for details on the Erratum. > > Tested the patch on Fam16h server platform and works fine. > > Signed-off-by: Aravind Gopalakrishnan > --- > arch/x86/kernel/quirks.c | 31 +++ > 1 file changed, 31 insertions(+) > > diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c > index 04ee1e2..e55ae02 100644 > --- a/arch/x86/kernel/quirks.c > +++ b/arch/x86/kernel/quirks.c > @@ -571,3 +571,34 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, > PCI_DEVICE_ID_AMD_15H_NB_F5, > quirk_amd_nb_node); > > #endif > + > +#if defined(CONFIG_PCI) > +/* > + * Apply AMD Fam16h Erratum792 > + * see Revision Guide for AMD F16h models 00h-0fh, > + * document 51810 rev. 3.04, Nov 2013 > + */ > +static void quirk_amd_dram_scrub(struct pci_dev *dev) The reference to the erratum is useful for people who want to see more details, but at least a short description of the problem being fixed and systems affected by the quirk is needed. 'DRAM scrub' is not very informative. Thanks, Ingo -- 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] SUNRPC: Allow one callback request to be received from two sk_buff
In current code, there only one struct rpc_rqst is prealloced. If one
callback request is received from two sk_buff, the xprt_alloc_bc_request
would be execute two times with the same transport->xid. The first time
xprt_alloc_bc_request will alloc one struct rpc_rqst and the TCP_RCV_COPY_DATA
bit of transport->tcp_flags will not be cleared. The second time
xprt_alloc_bc_request could not alloc struct rpc_rqst any more and NULL
pointer will be returned, then xprt_force_disconnect occur. I think one
callback request can be allowed to be received from two sk_buff.
Signed-off-by: shaobingqing
---
net/sunrpc/xprtsock.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index ee03d35..606950d 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -1271,8 +1271,13 @@ static inline int xs_tcp_read_callback(struct rpc_xprt
*xprt,
struct sock_xprt *transport =
container_of(xprt, struct sock_xprt, xprt);
struct rpc_rqst *req;
+ static struct rpc_rqst *req_partial;
+
+ if (req_partial == NULL)
+ req = xprt_alloc_bc_request(xprt);
+ else if (req_partial->rq_xid == transport->tcp_xid)
+ req = req_partial;
- req = xprt_alloc_bc_request(xprt);
if (req == NULL) {
printk(KERN_WARNING "Callback slot table overflowed\n");
xprt_force_disconnect(xprt);
@@ -1285,6 +1290,7 @@ static inline int xs_tcp_read_callback(struct rpc_xprt
*xprt,
if (!(transport->tcp_flags & TCP_RCV_COPY_DATA)) {
struct svc_serv *bc_serv = xprt->bc_serv;
+ req_partial = NULL;
/*
* Add callback request to callback list. The callback
@@ -1297,7 +1303,8 @@ static inline int xs_tcp_read_callback(struct rpc_xprt
*xprt,
list_add(>rq_bc_list, _serv->sv_cb_list);
spin_unlock(_serv->sv_cb_lock);
wake_up(_serv->sv_cb_waitq);
- }
+ } else
+ req_partial = req;
req->rq_private_buf.len = transport->tcp_copied;
--
1.7.4.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/
linux-next: Tree for Jan 20
Hi all, This tree fails (more than usual) the powerpc allyesconfig build. Changes since 20140117: Dropped tree: sh (complex merge conflicts against very old commits) The powerpc tree still had its build failure. The kvm tree still had its build failure so I used the version from next-20140109. The target-updates tree gained a build failure for which I applied a merge fix patch. The gpio tree gained a build failure for which I reverted a commit. Non-merge commits (relative to Linus' tree): 9729 9131 files changed, 494215 insertions(+), 241500 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. I am currently merging 209 trees (counting Linus' and 29 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (16ec54ad1502 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator) Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" not depend on vmlinux) Merging arc-current/for-curr (7e22e91102c6 Linux 3.13-rc8) Merging arm-current/fixes (b25f3e1c3584 ARM: 7938/1: OMAP4/highbank: Flush L2 cache before disabling) Merging m68k-current/for-linus (77a42796786c m68k: Remove deprecated IRQF_DISABLED) Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2) Merging powerpc-merge/merge (b3084f4db3ae powerpc/thp: Fix crash on mremap) Merging sparc/master (ef350bb7c5e0 Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4) Merging net/master (7d0d46da750a Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging ipsec/master (965cdea82569 dccp: catch failed request_module call in dccp_probe init) Merging sound-current/for-linus (315fba80a664 Merge tag 'asoc-v3.13-rc8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging pci-current/for-linus (f0b75693cbb2 MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI host maintainers) Merging wireless/master (2eff7c791a18 Merge tag 'nfc-fixes-3.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-fixes) Merging driver-core.current/driver-core-linus (413541dd66d5 Linux 3.13-rc5) Merging tty.current/tty-linus (413541dd66d5 Linux 3.13-rc5) Merging usb.current/usb-linus (413541dd66d5 Linux 3.13-rc5) Merging staging.current/staging-linus (413541dd66d5 Linux 3.13-rc5) Merging char-misc.current/char-misc-linus (802eee95bde7 Linux 3.13-rc6) Merging input-current/for-linus (8e2f2325b73f Input: xpad - add new USB IDs for Logitech F310 and F710) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (efb753b8e013 crypto: ixp4xx - Fix kernel compile error) Merging ide/master (c2f7d1e103ef ide: pmac: remove unnecessary pci_set_drvdata()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (44033109e99c SH: Convert out[bwl] macros to inline functions) Merging devicetree-current/devicetree/merge (6f041e99fc7b of: Fix NULL dereference in unflatten_and_copy()) Merging rr-fixes/fixes
Re: ping [PATCH v3] WAN: Adding support for Lantiq PEF2256 E1 chipset (FALC56)
On Sun, 2014-01-19 at 18:50 -0600, Rob Landley wrote:
> On 01/19/14 13:34, Joe Perches wrote:
> > On Sun, 2014-01-19 at 19:07 +0100, Christophe Leroy wrote:
> >> Pinging this watch as we got no feedback since 22 Nov, although we have
> >> taken
> >> into account reviews from v1 and v2.
> >>
> >> The patch adds WAN support for Lantiq FALC56 - PEF2256 E1 Chipset.
> ...
> >> +static ssize_t fs_attr_Tx_TS_store(struct device *dev,
> >> + struct device_attribute *attr, const char *buf,
> >> + size_t count)
> >> +{
> >> + struct net_device *ndev = dev_get_drvdata(dev);
> >> + struct pef2256_dev_priv *priv = dev_to_hdlc(ndev)->priv;
> >> + unsigned long value;
> >> + int ret = kstrtoul(buf, 16, (long int *));
> >
> > unportable cast
> How is that not portable? It's long == pointer on Linux, which supports
> LP64 on all targets. (As do BSD, MacOSX, android, and iOS.)
Sorry, I read it wrong.
long int is the same size as long and is fine.
I thought it was just int.
Still, declaring
unsigned long foo;
and using
(long int *)
is mixing implicit and explicit styles and perhaps
should be avoided.
> Do you mean it's not portable to Windows?
>http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx
I hardly remember that stuff anymore.
cheers, Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: Improve documentation of page_order
On Fri, Jan 17, 2014 at 02:32:21PM +, Mel Gorman wrote: > Developers occasionally try and optimise PFN scanners by using page_order > but miss that in general it requires zone->lock. This has happened twice for > compaction.c and rejected both times. This patch clarifies the documentation > of page_order and adds a note to compaction.c why page_order is not used. > > Signed-off-by: Mel Gorman Except Laura pointed out, Acked-by: Minchan Kim Thanks for following up this issue without forgetting. -- Kind regards, Minchan Kim -- 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]DM: dm-insitu-comp: a compressed DM target for SSD
This is a simple DM target supporting compression for SSD only. Under layer SSD must support 512B sector size, the target only supports 4k sector size. Disk layout: |super|...meta...|..data...| Store unit is 4k (a block). Super is 1 block, which stores meta and data size and compression algorithm. Meta is a bitmap. For each data block, there are 5 bits meta. Data: Data of a block is compressed. Compressed data is round up to 512B, which is the payload. In disk, payload is stored at the begining of logical sector of the block. Let's look at an example. Say we store data to block A, which is in sector B(A*8), its orginal size is 4k, compressed size is 1500. Compressed data (CD) will use 3 sectors (512B). The 3 sectors are the payload. Payload will be stored at sector B. --- ... | CD1 | CD2 | CD3 | | | | || ... --- ^B^B+1 ^B+2 ^B+7 ^B+8 For this block, we will not use sector B+3 to B+7 (a hole). We use 4 meta bits to present payload size. The compressed size (1500) isn't stored in meta directly. Instead, we store it at the last 32bits of payload. In this example, we store it at the end of sector B+2. If compressed size + sizeof(32bits) crosses a sector, payload size will increase one sector. If payload uses 8 sectors, we store uncompressed data directly. If IO size is bigger than one block, we can store the data as an extent. Data of the whole extent will compressed and stored in the similar way like above. The first block of the extent is the head, all others are the tail. If extent is 1 block, the block is head. We have 1 bit of meta to present if a block is head or tail. If 4 meta bits of head block can't store extent payload size, we will borrow tail block meta bits to store payload size. Max allowd extent size is 128k, so we don't compress/decompress too big size data. Meta: Modifying data will modify meta too. Meta will be written(flush) to disk depending on meta write policy. We support writeback and writethrough mode. In writeback mode, meta will be written to disk in an interval or a FLUSH request. In writethrough mode, data and meta data will be written to disk together. Advantages: 1. simple. Since we store compressed data in-place, we don't need complicated disk data management. 2. efficient. For each 4k, we only need 5 bits meta. 1T data will use less than 200M meta, so we can load all meta into memory. And actual compression size is in payload. So if IO doesn't need RMW and we use writeback meta flush, we don't need extra IO for meta. Disadvantages: 1. hole. Since we store compressed data in-place, there are a lot of holes (in above example, B+3 - B+7) Hole can impact IO, because we can't do IO merge. 2. 1:1 size. Compression doesn't change disk size. If disk is 1T, we can only store 1T data even we do compression. But this is for SSD only. Generally SSD firmware has a FTL layer to map disk sectors to flash nand. High end SSD firmware has filesystem-like FTL. 1. hole. Disk has a lot of holes, but SSD FTL can still store data continuous in nand. Even we can't do IO merge in OS layer, SSD firmware can do it. 2. 1:1 size. On one side, we write compressed data to SSD, which means less data is written to SSD. This will be very helpful to improve SSD garbage collection, and so write speed and life cycle. So even this is a problem, the target is still helpful. On the other side, advanced SSD FTL can easily do thin provision. For example, if nand is 1T and we let SSD report it as 2T, and use the SSD as compressed target. In such SSD, we don't have the 1:1 size issue. So if SSD FTL can map non-continuous disk sectors to continuous nand and support thin provision, the compressed target will work very well. V1->V2: 1. Change name to insitu_comp, cleanup code, add comments and doc 2. Improve performance (extent locking, dedicated workqueue) Signed-off-by: Shaohua Li --- Documentation/device-mapper/insitu-comp.txt | 50 drivers/md/Kconfig |6 drivers/md/Makefile |1 drivers/md/dm-insitu-comp.c | 1483 drivers/md/dm-insitu-comp.h | 146 ++ 5 files changed, 1686 insertions(+) Index: linux/drivers/md/Kconfig === --- linux.orig/drivers/md/Kconfig 2014-01-17 14:37:12.186725995 +0800 +++ linux/drivers/md/Kconfig2014-01-17 14:37:12.174726295 +0800 @@ -290,6 +290,12 @@ config DM_CACHE_CLEANER A simple cache policy that writes back all data to the origin. Used when decommissioning a dm-cache. +config DM_INSITU_COMPRESSION + tristate "Insitu compression target" + depends on BLK_DEV_DM + ---help--- + Allow volume managers to insitu compress data for SSD. + config DM_MIRROR tristate "Mirror target" depends on
RE: [PATCH] of: fix of_update_property()
> Subject: Re: [PATCH] of: fix of_update_property()
>
> On Thu, Jan 16, 2014 at 10:46 PM, Xiubo Li wrote:
> > The of_update_property() is intent to update a property in a node
>
> s/intent/indended/
>
> > and if the property does not exist, will add it to the node.
> >
> > The second search of the property is possibly won't be found, that
> > maybe removed by other thread just before the second search begain,
> > if so just retry it.
>
> How did you find this problem? Actual use or some artificial stress test?
>
Some artificial stress test at home.
> > Signed-off-by: Xiubo Li
> > ---
> > drivers/of/base.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/of/base.c b/drivers/of/base.c
> > index f807d0e..d0c53bc 100644
> > --- a/drivers/of/base.c
> > +++ b/drivers/of/base.c
> > @@ -1572,6 +1572,7 @@ int of_update_property(struct device_node *np, struct
> property *newprop)
> > if (!newprop->name)
> > return -EINVAL;
> >
> > +retry:
> > oldprop = of_find_property(np, newprop->name, NULL);
> > if (!oldprop)
> > return of_add_property(np, newprop);
>
> Isn't there also a race that if you do 2 updates for a non-existent
> property and both threads try to add the property, the first one will
> succeed and the 2nd will fail. The 2nd one needs to retry as well.
>
Well, yes, that will happen.
Maybe we could add one __of_add_property() without any locks, like
__of_find_property(). And then in of_update_prperty() move the searching
and adding operations to between lock and unlock, like:
raw_spin_lock_irqsave();
oldprop = __of_find_property();
if (!oldprop) {
rc = __of_add_property(np, newprop);
...
}
...
replace the node...
...
raw_spin_unlock_irqrestore();
> Also, couldn't the node itself be removed while trying to do the update?
>
For this is between the lock operations. I think this doesn't matter here.
> There seem to be multiple problems with this code, but doing multiple
> simultaneous, conflicting updates seems like an unlikely case.
>
Yes, but this will happen in theory.
Thanks,
Best Regards,
Xiubo
--
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] backlight: turn backlight on/off when necessary
We don't have to turn backlight on/off everytime a blanking
or unblanking event comes because the backlight status may
have already been what we want. Another thought is that one
backlight device may be shared by multiple framebuffers. We
don't hope blanking one of the framebuffers may turn the
backlight off for all the other framebuffers, since they are
likely being active to display something. This patch adds
some logics to record each framebuffer's backlight usage to
determine the backlight device use count and whether the
backlight should be turned on or off. To be more specific,
only one unblank operation on a certain blanked framebuffer
may increase the backlight device's use count by one, while
one blank operation on a certain unblanked framebuffer may
decrease the use count by one, because the userspace is
likely to unblank a unblanked framebuffer or blank a blanked
framebuffer.
Signed-off-by: Liu Ying
---
v1 can be found at https://lkml.org/lkml/2013/5/30/139
v1->v2:
* Make the commit message be more specific about the condition
in which backlight device use count can be increased/decreased.
* Correct the setting for bd->props.fb_blank.
drivers/video/backlight/backlight.c | 28 +---
include/linux/backlight.h |6 ++
2 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 5d0..42044be 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -34,13 +34,15 @@ static const char *const backlight_types[] = {
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
/* This callback gets called when something important happens inside a
* framebuffer driver. We're looking if that important event is blanking,
- * and if it is, we're switching backlight power as well ...
+ * and if it is and necessary, we're switching backlight power as well ...
*/
static int fb_notifier_callback(struct notifier_block *self,
unsigned long event, void *data)
{
struct backlight_device *bd;
struct fb_event *evdata = data;
+ int node = evdata->info->node;
+ int fb_blank = 0;
/* If we aren't interested in this event, skip it immediately ... */
if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
@@ -51,12 +53,24 @@ static int fb_notifier_callback(struct notifier_block *self,
if (bd->ops)
if (!bd->ops->check_fb ||
bd->ops->check_fb(bd, evdata->info)) {
- bd->props.fb_blank = *(int *)evdata->data;
- if (bd->props.fb_blank == FB_BLANK_UNBLANK)
- bd->props.state &= ~BL_CORE_FBBLANK;
- else
- bd->props.state |= BL_CORE_FBBLANK;
- backlight_update_status(bd);
+ fb_blank = *(int *)evdata->data;
+ if (fb_blank == FB_BLANK_UNBLANK &&
+ !bd->fb_bl_on[node]) {
+ bd->fb_bl_on[node] = true;
+ if (!bd->use_count++) {
+ bd->props.state &= ~BL_CORE_FBBLANK;
+ bd->props.fb_blank = FB_BLANK_UNBLANK;
+ backlight_update_status(bd);
+ }
+ } else if (fb_blank != FB_BLANK_UNBLANK &&
+ bd->fb_bl_on[node]) {
+ bd->fb_bl_on[node] = false;
+ if (!(--bd->use_count)) {
+ bd->props.state |= BL_CORE_FBBLANK;
+ bd->props.fb_blank = FB_BLANK_POWERDOWN;
+ backlight_update_status(bd);
+ }
+ }
}
mutex_unlock(>ops_lock);
return 0;
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 5f9cd96..7264742 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -9,6 +9,7 @@
#define _LINUX_BACKLIGHT_H
#include
+#include
#include
#include
@@ -104,6 +105,11 @@ struct backlight_device {
struct list_head entry;
struct device dev;
+
+ /* Multiple framebuffers may share one backlight device */
+ bool fb_bl_on[FB_MAX];
+
+ int use_count;
};
static inline void backlight_update_status(struct backlight_device *bd)
--
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/
linux-next: build failure after merge of the gpio tree
Hi Linus,
After merging the gpio tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpio/gpio-mcp23s08.c: In function 'mcp23s08_irq_setup':
drivers/gpio/gpio-mcp23s08.c:482:46: error: 'struct gpio_chip' has no member
named 'of_node'
mcp->irq_domain = irq_domain_add_linear(chip->of_node, chip->ngpio,
^
drivers/gpio/gpio-mcp23s08.c: In function 'mcp23s08_probe_one':
drivers/gpio/gpio-mcp23s08.c:651:55: error: 'struct gpio_chip' has no member
named 'of_node'
mcp->irq_controller = of_property_read_bool(mcp->chip.of_node,
^
drivers/gpio/gpio-mcp23s08.c:654:43: error: 'struct gpio_chip' has no member
named 'of_node'
mirror = of_property_read_bool(mcp->chip.of_node,
^
Caused by commit 4e47f91bf741 ("gpio: mcp23s08: Add irq functionality for
i2c chips"). The presence of of_node depends on CONFIG_OF_GPIO.
I have reverted that commit for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpqLqqdqpTGJ.pgp
Description: PGP signature
Re: [PATCH] dmaengine: Add DMA_PRIVATE to BCM2835 driver
On Fri, Jan 17, 2014 at 06:06:29PM +0100, Florian Meier wrote: > Without DMA_PRIVATE the driver is not able to allocate more than one channel. > Since it uses dma_get_any_slave_channel that calls private_candidate, > the second allocation fails at > /* some channels are already publicly allocated */ > Maybe it should be fixed in the core, but at least this fixes the bug. > > Signed-off-by: Florian Meier > --- > drivers/dma/bcm2835-dma.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c > index 6ae0708..a036021 100644 > --- a/drivers/dma/bcm2835-dma.c > +++ b/drivers/dma/bcm2835-dma.c > @@ -611,6 +611,7 @@ static int bcm2835_dma_probe(struct platform_device *pdev) > od->base = base; > > dma_cap_set(DMA_SLAVE, od->ddev.cap_mask); > + dma_cap_set(DMA_PRIVATE, od->ddev.cap_mask); > dma_cap_set(DMA_CYCLIC, od->ddev.cap_mask); > od->ddev.device_alloc_chan_resources = bcm2835_dma_alloc_chan_resources; > od->ddev.device_free_chan_resources = bcm2835_dma_free_chan_resources; Applied, thanks -- ~Vinod -- 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 resend 1/2] Documentation: move all DMA documentations into Documentaion/dma
On Sat, Jan 18, 2014 at 11:59:13AM -0600, Rob Landley wrote: > On 01/16/14 09:59, Vinod Koul wrote: > >On Thu, Jan 16, 2014 at 06:50:04PM +0800, hongbo.zh...@freescale.com wrote: > >>From: Hongbo Zhang > >> > >>Since there are already seven DMA documentations under the top > >>Documentation/, > >>it is better to create one dedicated directory for them. > > > >Well the problem is that not everything is same. Some of these mean how to > >use > >dma mapping API, couple are related to dmaengine, so clubing everything into > >"dma" doesnt sound right to me! > > Putting everything in the world in the top level directory isn't all > flowers and kittens either. > > Where would be a _better_ place to move one of those files to? As pointed mostly things dma* are dma-mapping and dmaengine, so would apt that we move to two folders, unless i overlooked and assumed everything else is dma-mapping! -- ~Vinod -- 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-next: build failure after merge of the target-updates tree
Hi Nicholas,
After merging the target-updates tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/target/target_core_iblock.c: In function 'iblock_alloc_bip':
drivers/target/target_core_iblock.c:646:5: error: 'struct
bio_integrity_payload' has no member named 'bip_size'
bip->bip_size = (cmd->data_length / dev->dev_attrib.block_size) *
^
drivers/target/target_core_iblock.c:648:5: error: 'struct
bio_integrity_payload' has no member named 'bip_sector'
bip->bip_sector = bio->bi_sector;
^
drivers/target/target_core_iblock.c:648:23: error: 'struct bio' has no member
named 'bi_sector'
bip->bip_sector = bio->bi_sector;
^
In file included from include/linux/printk.h:243:0,
from include/linux/kernel.h:13,
from include/linux/cache.h:4,
from include/linux/time.h:4,
from include/linux/ktime.h:24,
from include/linux/timer.h:5,
from drivers/target/target_core_iblock.c:29:
drivers/target/target_core_iblock.c:650:52: error: 'struct
bio_integrity_payload' has no member named 'bip_size'
pr_debug("IBLOCK BIP Size: %u Sector: %llu\n", bip->bip_size,
^
drivers/target/target_core_iblock.c:651:27: error: 'struct
bio_integrity_payload' has no member named 'bip_sector'
(unsigned long long)bip->bip_sector);
^
Caused by commit ecebbf6ccbca ("target/iblock: Add blk_integrity + BIP
passthrough support") interacting with commits 4f024f3797c4 ("block:
Abstract out bvec iterator") and d57a5f7c6605 ("bio-integrity: Convert to
bvec_iter") from the block tree.
I applied the following merge fix patch:
From: Stephen Rothwell
Date: Mon, 20 Jan 2014 16:21:31 +1100
Subject: [PATCH] tagtet/iblock: merge for for bvec_iter changes
Signed-off-by: Stephen Rothwell
---
drivers/target/target_core_iblock.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/target/target_core_iblock.c
b/drivers/target/target_core_iblock.c
index b7c64ef78338..554d4f75a75a 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -643,12 +643,12 @@ iblock_alloc_bip(struct se_cmd *cmd, struct bio *bio)
return -ENOMEM;
}
- bip->bip_size = (cmd->data_length / dev->dev_attrib.block_size) *
+ bip->bip_iter.bi_size = (cmd->data_length / dev->dev_attrib.block_size)
*
dev->prot_length;
- bip->bip_sector = bio->bi_sector;
+ bip->bip_iter.bi_sector = bio->bi_iter.bi_sector;
- pr_debug("IBLOCK BIP Size: %u Sector: %llu\n", bip->bip_size,
-(unsigned long long)bip->bip_sector);
+ pr_debug("IBLOCK BIP Size: %u Sector: %llu\n", bip->bip_iter.bi_size,
+(unsigned long long)bip->bip_iter.bi_sector);
for_each_sg(cmd->t_prot_sg, sg, cmd->t_prot_nents, i) {
--
1.8.5.3
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
pgpodxywZ5VJP.pgp
Description: PGP signature
Re: [PATCH v2 4/6] arm64: audit: Add 32-bit (compat) syscall support
On 01/18/2014 01:46 AM, Will Deacon wrote:
Hi Akashi,
On Fri, Jan 17, 2014 at 08:13:17AM +, AKASHI Takahiro wrote:
Generic audit code also support compat system calls now.
This patch adds a small piece of architecture dependent code.
[...]
static inline int syscall_get_nr(struct task_struct *task,
@@ -109,6 +110,15 @@ static inline void syscall_set_arguments(struct
task_struct *task,
static inline int syscall_get_arch(struct task_struct *task,
struct pt_regs *regs)
{
+#ifdef CONFIG_COMPAT
+ if (is_compat_thread(task_thread_info(task)))
You can call is_compat_thread even when !CONFIG_COMPAT, so you don't need
that #ifdef.
Right. I will remove it.
+#ifdef __AARCH64EB__
+ return AUDIT_ARCH_ARMEB; /* only BE on BE */
Well, actually, we only support userspace to be the same endianness as the
kernel, so you that comment is slightly misleading. You could probably avoid
these repeated ifdefs by defining things like ARM64_AUDIT_ARCH and
ARM64_COMPAT_AUDIT_ARCH once depending on endianness.
As in the discussions about "audit(userspace)", if we don't have to care
about endianness, I will remove this #ifdef instead.
Thanks,
-Takahiro AKASHI
Will
--
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 3/3] zram: list and select compression algorithms
On Fri, Jan 17, 2014 at 02:04:17PM +0300, Sergey Senozhatsky wrote:
> Add compressor device attr that allows to list and select
> compression algorithms.
>
> Define and make available for selection LZ4 compressor ops.
>
> usage example:
> List available compression algorithms (currently selected
> one is LZO):
> cat /sys/block/zram0/compressor
>lz4
>
> Change compression algorithm to LZ4:
> echo lz4 > /sys/block/zram0/compressor
> cat /sys/block/zram0/compressor
> lzo
Interface looks good to me.
>
> Update documentation with "Select compression algorithm" section
>
> Signed-off-by: Sergey Senozhatsky
> ---
> Documentation/blockdev/zram.txt | 23 -
> drivers/block/zram/Kconfig | 2 ++
> drivers/block/zram/zram_drv.c | 46
> +
> 3 files changed, 62 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
> index 393541be..af90d29 100644
> --- a/Documentation/blockdev/zram.txt
> +++ b/Documentation/blockdev/zram.txt
> @@ -21,7 +21,20 @@ Following shows a typical sequence of steps for using zram.
> This creates 4 devices: /dev/zram{0,1,2,3}
> (num_devices parameter is optional. Default: 1)
>
> -2) Set Disksize
> +2) Select compression algorithm
> +'compressor' sysfs node allows to see available, currently used
> +and change compression algorithms.
> +In order to list available compression algorithms (currently selected
> +one is LZO):
> + cat /sys/block/zram0/compressor
> + lz4
> +
> +Change compression algorithm to LZ4:
> + echo lz4 > /sys/block/zram0/compressor
> + cat /sys/block/zram0/compressor
> + lzo
> +
> +3) Set Disksize
> Set disk size by writing the value to sysfs node 'disksize'.
> The value can be either in bytes or you can use mem suffixes.
> Examples:
> @@ -38,14 +51,14 @@ There is little point creating a zram of greater than
> twice the size of memory
> since we expect a 2:1 compression ratio. Note that zram uses about 0.1% of
> the
> size of the disk when not in use so a huge zram is wasteful.
>
> -3) Activate:
> +4) Activate:
> mkswap /dev/zram0
> swapon /dev/zram0
>
> mkfs.ext4 /dev/zram1
> mount /dev/zram1 /tmp
>
> -4) Stats:
> +5) Stats:
> Per-device statistics are exported as various nodes under
> /sys/block/zram/
> disksize
> @@ -59,11 +72,11 @@ size of the disk when not in use so a huge zram is
> wasteful.
> compr_data_size
> mem_used_total
>
> -5) Deactivate:
> +6) Deactivate:
> swapoff /dev/zram0
> umount /dev/zram1
>
> -6) Reset:
> +7) Reset:
> Write any positive value to 'reset' sysfs node
> echo 1 > /sys/block/zram0/reset
> echo 1 > /sys/block/zram1/reset
> diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
> index 3450be8..09dacd6 100644
> --- a/drivers/block/zram/Kconfig
> +++ b/drivers/block/zram/Kconfig
> @@ -3,6 +3,8 @@ config ZRAM
> depends on BLOCK && SYSFS && ZSMALLOC
> select LZO_COMPRESS
> select LZO_DECOMPRESS
> + select LZ4_COMPRESS
> + select LZ4_DECOMPRESS
But user should select what kinds of compressor then want
some user want only lzo while others want lzo, lz2 and zlib all.
> default n
> help
> Creates virtual block devices called /dev/zramX (X = 0, 1, ...).
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 4f2c748..f1434f8 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
>
> #include "zram_drv.h"
>
> @@ -47,6 +48,12 @@ static struct zram_compress_ops lzo_compressor = {
> .decompress = lzo1x_decompress_safe,
> };
>
> +static struct zram_compress_ops lz4_compressor = {
> + .workmem_sz = LZ4_MEM_COMPRESS,
> + .compress = lz4_compress,
> + .decompress = lz4_decompress_unknownoutputsize,
> +};
> +
> #define ZRAM_ATTR_RO(name) \
> static ssize_t zram_attr_##name##_show(struct device *d, \
> struct device_attribute *attr, char *b) \
> @@ -113,6 +120,34 @@ static ssize_t mem_used_total_show(struct device *dev,
> return sprintf(buf, "%llu\n", val);
> }
>
> +static ssize_t compressor_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct zram *zram = dev_to_zram(dev);
> + if (zram->ops == _compressor)
> + return sprintf(buf, " lz4\n");
> + return sprintf(buf, "lzo \n");
> +}
> +
> +static ssize_t compressor_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t len)
> +{
> + struct zram *zram = dev_to_zram(dev);
> +
> + down_write(>init_lock);
> + if (init_done(zram)) {
> +
Re: [RFC PATCH 2/3] zram: introduce zram compressor operations struct
Hello Sergey,
I reviewed this patchset and I suggest somethings.
Please have a look and feedback to me. :)
1. Let's define new file zram_comp.c
2. zram_comp includes following field
.create
.compress
.decompress.
.destroy
.name
1) create/destroy
Will set up necessary things like allocating buffer, lock init or other things
might happen in future when initialization time.
I have a plan to support multiple buffer to do compression/decompression in
parallel so we could optimize write VS write path, too.
2) compress/decompress
It's very clear.
3) name field will be used for tell to user what's kinds of compression
algorithm zram support.
On Fri, Jan 17, 2014 at 02:04:16PM +0300, Sergey Senozhatsky wrote:
> This is preparation patch to add LZ4 compression support.
>
> struct zram_compress_ops defines common compress and decompress
> prototypes. Use these ops->compress and ops->decompress callbacks
> instead of direct LZO lzo1x_1_compress() and lzo1x_decompress_safe()
> calls.
>
> Compressor ops should be defined before zram meta allocation,
> because the size of meta->compress_workmem depends on selected
> compression algorithm.
>
> Define LZO compressor ops and set it as the only one available
> zram compressor at the moment.
>
> Signed-off-by: Sergey Senozhatsky
> ---
> drivers/block/zram/zram_drv.c | 20 +---
> drivers/block/zram/zram_drv.h | 10 ++
> 2 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 7124042..4f2c748 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -28,10 +28,9 @@
> #include
> #include
> #include
> -#include
> -#include
> #include
> #include
> +#include
Let's include zram_comps.h only and zram_comps.h includes other compression
alrogithms header. If user don't want to support some compression
alrogithm, it shouldn't be included.
Of course, user can select kinds of compressor in configuration step.
>
> #include "zram_drv.h"
>
> @@ -42,6 +41,12 @@ static struct zram *zram_devices;
> /* Module params (documentation at end) */
> static unsigned int num_devices = 1;
>
> +static struct zram_compress_ops lzo_compressor = {
> + .workmem_sz = LZO1X_MEM_COMPRESS,
workmem_sz should be part of compressor internal.
> + .compress = lzo1x_1_compress,
> + .decompress = lzo1x_decompress_safe,
> +};
> +
> #define ZRAM_ATTR_RO(name) \
> static ssize_t zram_attr_##name##_show(struct device *d, \
> struct device_attribute *attr, char *b) \
> @@ -166,14 +171,14 @@ static void zram_meta_free(struct zram_meta *meta)
> kfree(meta);
> }
>
> -static struct zram_meta *zram_meta_alloc(u64 disksize)
> +static struct zram_meta *zram_meta_alloc(int workmem_sz, u64 disksize)
> {
> size_t num_pages;
> struct zram_meta *meta = kmalloc(sizeof(*meta), GFP_KERNEL);
> if (!meta)
> goto out;
>
> - meta->compress_workmem = kzalloc(LZO1X_MEM_COMPRESS, GFP_KERNEL);
> + meta->compress_workmem = kzalloc(workmem_sz, GFP_KERNEL);
Instead of exposing compression internal stuff, let's call comp->create.
> if (!meta->compress_workmem)
> goto free_meta;
>
> @@ -301,7 +306,7 @@ static int zram_decompress_page(struct zram *zram, char
> *mem, u32 index)
> if (size == PAGE_SIZE)
> copy_page(mem, cmem);
> else
> - ret = lzo1x_decompress_safe(cmem, size, mem, );
> + ret = zram->ops->decompress(cmem, size, mem, );
> zs_unmap_object(meta->mem_pool, handle);
> read_unlock(>tb_lock);
>
> @@ -420,7 +425,7 @@ static int zram_bvec_write(struct zram *zram, struct
> bio_vec *bvec, u32 index,
> goto out;
> }
>
> - ret = lzo1x_1_compress(uncmem, PAGE_SIZE, src, ,
> + ret = zram->ops->compress(uncmem, PAGE_SIZE, src, ,
> meta->compress_workmem);
Ditto. compress_workmem should be part of compressor itself.
> if (!is_partial_io(bvec)) {
> kunmap_atomic(user_mem);
> @@ -551,7 +556,7 @@ static ssize_t disksize_store(struct device *dev,
> }
>
> disksize = PAGE_ALIGN(disksize);
> - zram->meta = zram_meta_alloc(disksize);
> + zram->meta = zram_meta_alloc(zram->ops->workmem_sz, disksize);
So, we don't need zram->ops->workmem_sz.
>
> zram->disksize = disksize;
> set_capacity(zram->disk, zram->disksize >> SECTOR_SHIFT);
> @@ -785,6 +790,7 @@ static int create_device(struct zram *zram, int device_id)
> goto out_free_disk;
> }
>
> + zram->ops = _compressor;
Let's define choose_compressor function with some argument
so the result is following as
zram->comp = choose_compressor("lzo");
> zram->meta = NULL;
> return 0;
>
> diff --git a/drivers/block/zram/zram_drv.h
Re: [PATCH net] tun: handle copy failure in tun_put_user()
On 01/20/2014 11:48 AM, David Miller wrote: > From: Jason Wang > Date: Mon, 20 Jan 2014 11:16:48 +0800 > >> This patch return the error code of copy helpers in tun_put_user() instead of >> ignoring them. >> >> Cc: Michael S. Tsirkin >> Signed-off-by: Jason Wang > If you perform some of the copy successfully, you have to report that > length rather than just an error. > > Otherwise userland has no way to determine how much of the data was > successfully sourced. > > I'm not applying this, sorry. Right, looks like we need more changes in tun to return the accurate length copied in this case. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the tip tree
+static void mwait_idle(void)
+{
+ mwait_idle_with_hints(0, 0);
+}
+
The reason the patch above will crash Core2 machines is because
core2 machines don't support mwait_idle_with_hints().
The calling sequence for old and new MWAIT instructions is different.
The former must be invoked with interrupts enabled,
and the later can be invoked with interrupts disabled,
which is a feature that Linux takes advantage of.
thanks,
-Len
--
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/3] zram: delete zram_init_device() function
Hello Sergey, Looks good to me and I found a bug which had been in there so I rebased this patch on the top. https://git.kernel.org/cgit/linux/kernel/git/minchan/linux.git/commit/?h=zram-next=241e34fc6c3c1a41575fbe6383436be70df300d1 On Fri, Jan 17, 2014 at 02:04:15PM +0300, Sergey Senozhatsky wrote: > allocate new `zram_meta' in disksize_store() only for uninitialised > zram device, saving a number of allocations and deallocations in case > if disksize_store() was called on currently used device. at the same > time zram_meta stack variable is not necessary, because we can set > ->meta directly. there is also no need in setting QUEUE_FLAG_NONROT > queue on every disksize_store(), set it once during device creation. > > Signed-off-by: Sergey Senozhatsky Otherwise, Acked-by: Minchan Kim -- Kind regards, Minchan Kim -- 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: [PATCHv3 0/8] zram stats rework and code cleanup
On Fri, Jan 17, 2014 at 04:09:34PM +0900, Minchan Kim wrote: > On Thu, Jan 16, 2014 at 04:12:08PM +0300, Sergey Senozhatsky wrote: > > This patchset includes zram stats clean up and enhancements. > > > > Sergey Senozhatsky (8): > > zram: drop `init_done' struct zram member > > zram: do not pass rw argument to __zram_make_request() > > zram: remove good and bad compress stats > > zram: use atomic64_t for all zram stats > > zram: remove zram stats code duplication > > zram: report failed read and write stats > > zram: drop not used table `count' member > > zram: move zram size warning to documentation > > > > Documentation/blockdev/zram.txt | 5 ++ > > drivers/block/zram/zram_drv.c | 175 > > +--- > > drivers/block/zram/zram_drv.h | 10 +-- > > 3 files changed, 64 insertions(+), 126 deletions(-) > > Great clean up. > > Sergey, Thanks! > I am looking forward to your next step! Hello Sergey, I guess Andrew wouldn't pick this patchset until closing merge window so I picked up in my zram tree so let's do further work based on it. https://git.kernel.org/cgit/linux/kernel/git/minchan/linux.git/log/?h=zram-next Thanks. -- Kind regards, Minchan Kim -- 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 5/5] ARM: dts: AM43xx-epos-evm: DT entries for ti-usim and phy
- Board specific DT entries for TI's USIM - smart card controller of AM43xx
platfrom.These entries are used by USIM driver for various configurations.
- Shutdown line of NXP phy is maped to GPIO5. So enabling same to have support
for NXP phy.
- i2c2 pinmux configuration - NxP tda8026 phy is connected to i2c2 lines
Signed-off-by: Satish Patel
---
arch/arm/boot/dts/am43x-epos-evm.dts | 43 ++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index fbf9c4c..38ef2b8 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -79,6 +79,24 @@
0x18c (PIN_INPUT_PULLUP | SLEWCTRL_FAST |
MUX_MODE0)/* i2c0_scl.i2c0_scl */
>;
};
+
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins = <
+ 0x1c0 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE8)
/* i2c2_sda.i2c2_sda */
+ 0x1c4 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE8)
/* i2c2_scl.i2c2_scl */
+ >;
+ };
+
+ usim0_default: usim0_default {
+ pinctrl-single,pins = <
+ /* USIM 0 */
+ 0x1B4 (SLEWCTRL_FAST | PULL_DISABLE | MUX_MODE8)
/* CLK0 */
+ 0x1B0 (SLEWCTRL_FAST | PULL_DISABLE | MUX_MODE8)
/* CLK1 */
+ 0x1B8 (SLEWCTRL_FAST | INPUT_EN | PULL_DISABLE |
MUX_MODE8) /* DATA0 */
+ 0x1BC (SLEWCTRL_FAST | INPUT_EN | PULL_DISABLE |
MUX_MODE8) /* DATA1 */
+ 0x1C8 (SLEWCTRL_FAST | INPUT_EN | PULL_UP |
MUX_MODE8) /* IRQn */
+ >;
+ };
};
matrix_keypad: matrix_keypad@0 {
@@ -169,6 +187,27 @@
};
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_default>;
+ phy = <>;
+ phy-slots = <1>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+
+ tda8026: tda8026@48 {
+ compatible = "nxp,tda8026";
+ reg = <0x48>;
+ shutdown-gpio = < 19 GPIO_ACTIVE_HIGH>; /* Bank5, pin19
*/
+ interrupts = ;
+ };
+};
+
{
status = "okay";
};
@@ -184,3 +223,7 @@
{
status = "okay";
};
+
+ {
+ status = "okay";
+};
--
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 v2 4/5] ARM: dts: AM43xx: DT entries added for ti-usim
SoC specific DT entries added for TI's USIM - smart card controller of AM43xx
platfrom.
Signed-off-by: Satish Patel
---
arch/arm/boot/dts/am4372.dtsi | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 974d103..7ed1cd1 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -663,5 +663,15 @@
< 11>;
dma-names = "tx", "rx";
};
+
+ usim0: usim@48034000 {
+ compatible = "ti,usim";
+ reg = <0x48034000 0x1000>;
+ interrupts = ;
+ ti,hwmods = "usim0";
+ clocks = <_opt_fck>, <_opt_fck32>;
+ clock-names = "opt_fck", "opt_fck32";
+ status = "disabled";
+ };
};
};
--
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 v2 1/5] sc_phy:SmartCard(SC) PHY interface to SC controller
SmartCard controller uses this interface to communicate with SmartCard via PHY Some SmartCard PHY has multiple slots for cards. This inerface also enables controller to communicate with one or more SmartCard connected over phy. interface structure includes following APIs - set/get config - activate/deactivate smart card - warm reset - register_notify (for card insert/remove/overheat) - unregister_notify Signed-off-by: Satish Patel --- Documentation/sc_phy.txt | 171 ++ include/linux/sc_phy.h | 132 +++ 2 files changed, 303 insertions(+), 0 deletions(-) create mode 100644 Documentation/sc_phy.txt create mode 100644 include/linux/sc_phy.h diff --git a/Documentation/sc_phy.txt b/Documentation/sc_phy.txt new file mode 100644 index 000..d610e26 --- /dev/null +++ b/Documentation/sc_phy.txt @@ -0,0 +1,171 @@ + SmartCard PHY Interface + Satish Patel + +This document explains the SmartCard interface between SmartCard +controller and SmartCard phy. Document also describes how-to-use. + +1. Why SmartCard PHY Interface? + +The use of smartcard is increasing in embedded industry. As smartcard +not only prevent duplication but also, brings key based authentication +flow into picture. + +SmartCard standards like EMV(EuroPay-Mastercard-Visa) are becoming +mandatory for payment terminals. + +Till date, most of the SmartCard readers are based on USB serial +interface. Which drives its logic within firmware lies on device. +Few are based on FPGA solutions. But now SoCs are coming up with +inbuilt smartcard controller. e.g. TI-AM43x + +Role of SmartCard controller and SmartCard phy: + +Smartcard Phy: +Forms electrical interface between controller and SmartCard. Phy +enables access to more than one smartcard and in addition it provides +fast deactivation logic when card gets removed from the slot. It can +also generate the signals like card insert/remove/overheat etc. + +Smartcard Controller: +In built mechanism to meet EMV L1 specification (e.g. T=0, T=1 +protocol timings, ATR timeout etc..) for SmartCard transaction. In +addition to this, it has FIFO to store tx/rx bytes, internal state +machine for ATR, Tx/Rx, Synchronous/Asynchronous mode, timing +counters etc.. + +Controller can also have direct interface through which SmartCard +can be connected without phy. + +Below is the brief of SmartCard block diagram from user to h/w +layer. + + +--- +|PC/SC App| +--- +--- --- +|PC/SC F/W| | Visa APP| +--- --- +--- +|IFD Hand.| | EMV L1/L2|| Test App | +--- +User Space + + +- +| SmartCard Controller Driver| +- + | | + | | +- | +| Phy Driver | | +- | + | | +Kernel Space | | + + | | + - + | PHY | |Controller IP | + - +| | + +| | + ___ + ||| + VISA card Master Card Custom Card + + +At present in Linux there is no public interface exist which acts as +bridge between controller and phy. Mostly vendors uses proprietary +solution in such cases. + +2. Introduction to SmartCard PHY interface + +SmartCard PHY interface that exposes phy's capabilities to the smart +card controller. SmartCard controller uses this interface to +communicate with SmartCard via phy. + +Such capabilities are: +1) Some SmartCard phy (e.g. TDA8026-NxP) has multiple slots for smart +cards. This interface enables controller to communicate with specific +SmartCard inserted to the specific phy's slot. + +2) Warm reset to SmartCard inserted to phy slot. + +3) Bit banging of SmartCard pins to support vedor specific memory +cards. Mostly when it comes to sychorous SmartCard + +4) Notification of card insert/remove/overheat etc. + + +3. How to use + +SmartCard PHY: +The SmartCard PHY driver, who wants to be interfaced with SmartCard +controller require to follow below step + +- include "sc_phy.h" + +- use "sc_phy" structure as driver(client) data. PHY driver can use +'void
[PATCH v2 2/5] misc: tda8026: Add NXP TDA8026 PHY driver
TDA8026 is a SmartCard PHY from NXP.
The PHY interfaces with the main processor over the
I2C interface and acts as a slave device.
The driver also exposes the phy interface
(defined@include/linux/sc_phy.h) for SmartCard controller.
Controller uses this interface to communicate with smart card
inserted to the phy's slot.
Note: gpio irq is not validated as I do not have device with that.
I have validated interrupt with dedicated interrupt line on my device.
Signed-off-by: Satish Patel
---
Documentation/devicetree/bindings/misc/tda8026.txt | 19 +
drivers/misc/Kconfig |7 +
drivers/misc/Makefile |1 +
drivers/misc/tda8026.c | 1255
4 files changed, 1282 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/misc/tda8026.txt
create mode 100644 drivers/misc/tda8026.c
diff --git a/Documentation/devicetree/bindings/misc/tda8026.txt
b/Documentation/devicetree/bindings/misc/tda8026.txt
new file mode 100644
index 000..f115c9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/tda8026.txt
@@ -0,0 +1,19 @@
+TDA8026 smart card slot interface
+
+This is an i2c based smart card interface device forming the electrical
+interface between a microcontroller and smart cards. This device supports
+asynchronous cards (micro controller-based IC cards) as well as synchronous
+cards (mainly memory cards)
+
+Required properties:
+- compatible: "nxp,tda8026"
+- shutdown-gpio = GPIO pin mapping for SDWNN pin
+- reg = i2c interface address
+
+
+Example:
+tda8026: tda8026@48 {
+compatible = "nxp,tda8026";
+reg = <0x48>;
+shutdown-gpio = < 19 GPIO_ACTIVE_HIGH>;/* Bank5, pin19 */
+};
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index a3e291d..bb94a6f 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -515,6 +515,13 @@ config SRAM
the genalloc API. It is supposed to be used for small on-chip SRAM
areas found on many SoCs.
+config NXP_TDA8026_PHY
+tristate "NXP PHY Driver for Smart Card PHY"
+depends on I2C=y
+help
+ If you say yes here you get support for the TDA8026 Smart card PHY
+ with I2C interface.
+
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index f45473e..24374dd 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -53,3 +53,4 @@ obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o
obj-$(CONFIG_SRAM) += sram.o
obj-y += mic/
+obj-$(CONFIG_NXP_TDA8026_PHY) += tda8026.o
diff --git a/drivers/misc/tda8026.c b/drivers/misc/tda8026.c
new file mode 100644
index 000..6a77686
--- /dev/null
+++ b/drivers/misc/tda8026.c
@@ -0,0 +1,1255 @@
+/*
+ * tda8026.c - TDA8026 PHY driver for NXP Smart card PHY
+ *
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TDA8026_MAX_SLOTS (5)
+#define TDA8026_NUM_SAM_SLOTS (4)
+#define TDA8026_USERCARD_SLOT (1)
+
+#define TDA8026_CSB_ADDR (0x24)
+#define TDA8026_REG0_ADDR (0x20)
+#define TDA8026_REG1_ADDR (0x21)
+#define TDA8026_SLEWRATE_ADDR (0x20)
+#define TDA8026_PRODVER_ADDR (0x20)
+#define TDA8026_INTSTAT_ADDR (0x21)
+
+#define TDA8026_PHY_PRODUCT_VERSION(0xC2)
+
+/* CSB register values */
+#define TDA8026_CSB_PV_INTSTAT_VAL (0x0)
+#define TDA8026_CSB_SLEWRATE_VAL (0x6)
+
+/* Slot REG0 read mode bit fields */
+#define TDA8026_REG0_ACTIVE_MASK (0x80)
+#define TDA8026_REG0_EARLY_MASK(0x40)
+#define TDA8026_REG0_MUTE_MASK (0x20)
+#define TDA8026_REG0_PROT_MASK (0x10)
+#define TDA8026_REG0_SUPL_MASK (0x08)
+#define TDA8026_REG0_CLKSW_MASK(0x04)
+#define TDA8026_REG0_PREL_MASK (0x02)
+#define TDA8026_REG0_PRES_MASK (0x01)
+
+/* Slot REG0 write mode bit fields */
+#define TDA8026_REG0_VCC1V8_MASK (0x80)
+#define TDA8026_REG0_IOEN_MASK (0x40)
+
+#define TDA8026_REG0_REG10_MASK(0x30)
+#define TDA8026_REG0_REG10_SHIFT
[PATCH v2 0/5] Smart Card(SC) interface, TI USIM & NxP SC phy driver
Changes from v1: * RFC(v1) comments are fixed ** removed "gpio_to_irq" as GPIO controller process cell from DT and give it to DT node ** comments on documentation ** few other comments on null checks are resolved * BWT timing configuration is added to ti-usim driver v1 cover letter link# https://lkml.org/lkml/2014/1/6/250 Satish Patel (5): sc_phy:SmartCard(SC) PHY interface to SC controller misc: tda8026: Add NXP TDA8026 PHY driver char: ti-usim: Add driver for USIM module on AM43xx ARM: dts: AM43xx: DT entries added for ti-usim ARM: dts: AM43xx-epos-evm: DT entries for ti-usim and phy Documentation/devicetree/bindings/misc/tda8026.txt | 19 + .../devicetree/bindings/ti-usim/ti-usim.txt| 31 + Documentation/sc_phy.txt | 171 ++ arch/arm/boot/dts/am4372.dtsi | 10 + arch/arm/boot/dts/am43x-epos-evm.dts | 43 + drivers/char/Kconfig |7 + drivers/char/Makefile |1 + drivers/char/ti-usim-hw.h | 863 + drivers/char/ti-usim.c | 1859 drivers/misc/Kconfig |7 + drivers/misc/Makefile |1 + drivers/misc/tda8026.c | 1255 + include/linux/sc_phy.h | 132 ++ include/linux/ti-usim.h| 98 + 14 files changed, 4497 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/misc/tda8026.txt create mode 100644 Documentation/devicetree/bindings/ti-usim/ti-usim.txt create mode 100644 Documentation/sc_phy.txt create mode 100644 drivers/char/ti-usim-hw.h create mode 100644 drivers/char/ti-usim.c create mode 100644 drivers/misc/tda8026.c create mode 100644 include/linux/sc_phy.h create mode 100644 include/linux/ti-usim.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] percpu_ida: Make percpu_ida_alloc accept task state bitmask
On Sun, 2014-01-19 at 18:38 -0800, Linus Torvalds wrote: > On Sun, Jan 19, 2014 at 2:16 AM, Nicholas A. Bellinger > wrote: > > > > This patch changes percpu_ida_alloc() to accept task state bitmask > > for prepare_to_wait() to support interruptible sleep for callers > > that require it. > > This patch-series is not bisectable. Afaik, the first patch will break > the build (or at least cause the end result to not actually work). > > This kind of "split up one large patch into many small patches THAT > DON'T ACTUALLY WORK INDIVIDUALLY" model is pure and utter garbage. > > So a big NAK on this series as being completely broken. > So the late night reasoning was to allow the patches to apply cleanly to stable. That was, indeed, a bad decision. > To fix it, I would suggest: > > - make the first patch change all *existing* users (that only have > the atomic vs uninterruptible semantics) pass in either > TASK_UNINTERRUPTIBLE or TASK_RUNNING depending on whether they had > __GFP_WAIT or not. > >So the first patch would not change *any* semantics or behavior, it > would only change the calling convention. > > - do the cleanup patches to block/blk-mq-tag.c to not have those > "gfp" calling convention, and instead passing in the state natively > > - add the TASK_INTERRUPTIBLE case last (which includes the new > "signal_pending_state()" logic in percpu_ida_alloc()) > > that way, all patches compile cleanly and should each work > individually, and they all do clearly just one thing. And the biggest > patch in the series (the first one) doesn't actually make any semantic > changes. -v2 sent out. Please review. Jens, please review the blk-mq specific changes in patch #1, and let me know if you'd like to pick-up #2 via the block tree, or have it included in target-pending/for-next. Thanks, --nab -- 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 3/3] iscsi-target: Fix connection reset hang with percpu_ida_alloc
From: Nicholas Bellinger
This patch addresses a bug where connection reset would hang
indefinately once percpu_ida_alloc() was starved for tags, due
to the fact that it always assumed uninterruptible sleep mode.
So now make percpu_ida_alloc() check for signal_pending_state() for
making interruptible sleep optional, and convert iscsit_allocate_cmd()
to set TASK_INTERRUPTIBLE for GFP_KERNEL, or TASK_RUNNING for
GFP_ATOMIC.
Reported-by: Linus Torvalds
Cc: Kent Overstreet
Cc: #3.12+
Signed-off-by: Nicholas Bellinger
---
drivers/target/iscsi/iscsi_target_util.c |2 +-
lib/percpu_ida.c |9 +++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/target/iscsi/iscsi_target_util.c
b/drivers/target/iscsi/iscsi_target_util.c
index 9b8e1db..5477eca 100644
--- a/drivers/target/iscsi/iscsi_target_util.c
+++ b/drivers/target/iscsi/iscsi_target_util.c
@@ -156,7 +156,7 @@ struct iscsi_cmd *iscsit_allocate_cmd(struct iscsi_conn
*conn, gfp_t gfp_mask)
{
struct iscsi_cmd *cmd;
struct se_session *se_sess = conn->sess->se_sess;
- int size, tag, state = (gfp_mask & __GFP_WAIT) ? TASK_UNINTERRUPTIBLE :
+ int size, tag, state = (gfp_mask & __GFP_WAIT) ? TASK_INTERRUPTIBLE :
TASK_RUNNING;
tag = percpu_ida_alloc(_sess->sess_tag_pool, state);
diff --git a/lib/percpu_ida.c b/lib/percpu_ida.c
index a48ce2e..a667110 100644
--- a/lib/percpu_ida.c
+++ b/lib/percpu_ida.c
@@ -138,14 +138,14 @@ static inline unsigned alloc_local_tag(struct
percpu_ida_cpu *tags)
* tag_pool_init()), or otherwise -ENOSPC on allocation failure.
*
* Safe to be called from interrupt context (assuming it isn't passed
- * TASK_UNINTERRUPTIBLE, of course).
+ * TASK_UNINTERRUPTIBLE | TASK_INTERRUPTIBLE, of course).
*
* @gfp indicates whether or not to wait until a free id is available (it's not
* used for internal memory allocations); thus if passed __GFP_WAIT we may
sleep
* however long it takes until another thread frees an id (same semantics as a
* mempool).
*
- * Will not fail if passed TASK_UNINTERRUPTIBLE.
+ * Will not fail if passed TASK_UNINTERRUPTIBLE | TASK_INTERRUPTIBLE.
*/
int percpu_ida_alloc(struct percpu_ida *pool, int state)
{
@@ -194,6 +194,11 @@ int percpu_ida_alloc(struct percpu_ida *pool, int state)
if (tag >= 0 || state == TASK_RUNNING)
break;
+ if (signal_pending_state(state, current)) {
+ tag = -ERESTARTSYS;
+ break;
+ }
+
schedule();
local_irq_save(flags);
--
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-v2 0/3] percpu_ida+Co: Make percpu_ida_alloc accept task state bitmask
From: Nicholas Bellinger Hi Linus, Here is the -v2 series for converting percpu_ida_alloc() + consumer usage to accept the task state bitmask parameter, w/o the extra legacy gfp_t wrapper. As requested, the first patch contains only the parameter change to percpu_ida_alloc() + existing consumers, and makes no semantic or behavior change. This patch is CC'ed for stable, and will need some light massaging to apply back to v3.12.y. The second patch is a blk-mq cleanup to propigate the task state bitmask usage up to the blk-mq vs. legacy split in blk_get_request(). The last patch fixes the original iscsi-target session reset bug by passing TASK_INTERRUPTIBLE, and adds the signal_pending_state() bit required in percpu_ida_alloc() code. This is also CC'ed for v3.12.y. CC'ing Ingo + Peter for TASK_RUNNING + prepare_to_wait() bit. Thank you, --nab Kent Overstreet (1): percpu_ida: Make percpu_ida_alloc + callers accept task state bitmask Nicholas Bellinger (2): blk-mq: Convert gfp_t parameters to task state bitmask iscsi-target: Fix connection reset hang with percpu_ida_alloc block/blk-core.c |4 +++- block/blk-flush.c|2 +- block/blk-mq-tag.c | 14 +++--- block/blk-mq-tag.h |2 +- block/blk-mq.c | 28 ++-- drivers/target/iscsi/iscsi_target_util.c |8 ++-- drivers/target/tcm_fc/tfc_cmd.c |2 +- drivers/vhost/scsi.c |2 +- include/linux/blk-mq.h |4 ++-- include/linux/percpu_ida.h |3 ++- lib/percpu_ida.c | 17 +++-- 11 files changed, 49 insertions(+), 37 deletions(-) -- 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-v2 2/3] blk-mq: Convert gfp_t parameters to task state bitmask
From: Nicholas Bellinger
This patch propigates the use of task state bitmask for
percpu_ida_alloc() up the blk-mq callchain, to the point in
blk_get_request() where the blk-mq vs. blk-old split occurs.
Along with the obvious parameters changes, there are two cases
in mq_flush_work() + blk_mq_make_request() where the original
code was using __GFP_WAIT|GFP_ATOMIC that always expect a tag
which have been converted to TASK_UNINTERRUPTIBLE.
Reported-by: Linus Torvalds
Cc: Jens Axboe
Signed-off-by: Nicholas Bellinger
---
block/blk-core.c |4 +++-
block/blk-flush.c |2 +-
block/blk-mq-tag.c | 16 +++-
block/blk-mq-tag.h |2 +-
block/blk-mq.c | 28 ++--
include/linux/blk-mq.h |4 ++--
6 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 8bdd012..ab0dc9a 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1112,7 +1112,9 @@ static struct request *blk_old_get_request(struct
request_queue *q, int rw,
struct request *blk_get_request(struct request_queue *q, int rw, gfp_t
gfp_mask)
{
if (q->mq_ops)
- return blk_mq_alloc_request(q, rw, gfp_mask, false);
+ return blk_mq_alloc_request(q, rw, (gfp_mask & __GFP_WAIT) ?
+ TASK_UNINTERRUPTIBLE : TASK_RUNNING,
+ false);
else
return blk_old_get_request(q, rw, gfp_mask);
}
diff --git a/block/blk-flush.c b/block/blk-flush.c
index fb6f3c0..8dd6ff8 100644
--- a/block/blk-flush.c
+++ b/block/blk-flush.c
@@ -286,7 +286,7 @@ static void mq_flush_work(struct work_struct *work)
/* We don't need set REQ_FLUSH_SEQ, it's for consistency */
rq = blk_mq_alloc_request(q, WRITE_FLUSH|REQ_FLUSH_SEQ,
- __GFP_WAIT|GFP_ATOMIC, true);
+ TASK_UNINTERRUPTIBLE, true);
rq->cmd_type = REQ_TYPE_FS;
rq->end_io = flush_end_io;
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index 5d70edc..20777bd 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -32,19 +32,18 @@ bool blk_mq_has_free_tags(struct blk_mq_tags *tags)
percpu_ida_free_tags(>free_tags, nr_cpu_ids) != 0;
}
-static unsigned int __blk_mq_get_tag(struct blk_mq_tags *tags, gfp_t gfp)
+static unsigned int __blk_mq_get_tag(struct blk_mq_tags *tags, int state)
{
int tag;
- tag = percpu_ida_alloc(>free_tags, (gfp & __GFP_WAIT) ?
- TASK_UNINTERRUPTIBLE : TASK_RUNNING);
+ tag = percpu_ida_alloc(>free_tags, state);
if (tag < 0)
return BLK_MQ_TAG_FAIL;
return tag + tags->nr_reserved_tags;
}
static unsigned int __blk_mq_get_reserved_tag(struct blk_mq_tags *tags,
- gfp_t gfp)
+ int state)
{
int tag;
@@ -53,19 +52,18 @@ static unsigned int __blk_mq_get_reserved_tag(struct
blk_mq_tags *tags,
return BLK_MQ_TAG_FAIL;
}
- tag = percpu_ida_alloc(>reserved_tags, (gfp & __GFP_WAIT) ?
- TASK_UNINTERRUPTIBLE : TASK_RUNNING);
+ tag = percpu_ida_alloc(>reserved_tags, state);
if (tag < 0)
return BLK_MQ_TAG_FAIL;
return tag;
}
-unsigned int blk_mq_get_tag(struct blk_mq_tags *tags, gfp_t gfp, bool reserved)
+unsigned int blk_mq_get_tag(struct blk_mq_tags *tags, int state, bool reserved)
{
if (!reserved)
- return __blk_mq_get_tag(tags, gfp);
+ return __blk_mq_get_tag(tags, state);
- return __blk_mq_get_reserved_tag(tags, gfp);
+ return __blk_mq_get_reserved_tag(tags, state);
}
static void __blk_mq_put_tag(struct blk_mq_tags *tags, unsigned int tag)
diff --git a/block/blk-mq-tag.h b/block/blk-mq-tag.h
index 947ba2c..b3c1487 100644
--- a/block/blk-mq-tag.h
+++ b/block/blk-mq-tag.h
@@ -6,7 +6,7 @@ struct blk_mq_tags;
extern struct blk_mq_tags *blk_mq_init_tags(unsigned int nr_tags, unsigned int
reserved_tags, int node);
extern void blk_mq_free_tags(struct blk_mq_tags *tags);
-extern unsigned int blk_mq_get_tag(struct blk_mq_tags *tags, gfp_t gfp, bool
reserved);
+extern unsigned int blk_mq_get_tag(struct blk_mq_tags *tags, int state, bool
reserved);
extern void blk_mq_wait_for_tags(struct blk_mq_tags *tags);
extern void blk_mq_put_tag(struct blk_mq_tags *tags, unsigned int tag);
extern void blk_mq_tag_busy_iter(struct blk_mq_tags *tags, void (*fn)(void
*data, unsigned long *), void *data);
diff --git a/block/blk-mq.c b/block/blk-mq.c
index c79126e..80bbfbd 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -75,13 +75,13 @@ static void blk_mq_hctx_mark_pending(struct blk_mq_hw_ctx
*hctx,
set_bit(ctx->index_hw, hctx->ctx_map);
}
-static struct request *blk_mq_alloc_rq(struct blk_mq_hw_ctx *hctx, gfp_t
Re: [PATCH v3 16/24] drm/i2c: tda998x: add DT documentation
Hi, On Sun, Jan 19, 2014 at 10:58 AM, Jean-Francois Moine wrote: > Signed-off-by: Jean-Francois Moine > --- > .../devicetree/bindings/drm/i2c/tda998x.txt| 24 > ++ > 1 file changed, 24 insertions(+) > create mode 100644 Documentation/devicetree/bindings/drm/i2c/tda998x.txt Please cc bindings for review to devicet...@vger.kernel.org (cc:d here now) > diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt > b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt > new file mode 100644 > index 000..72da71d > --- /dev/null > +++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt > @@ -0,0 +1,24 @@ > +Device-Tree bindings for the NXP TDA998x HDMI transmitter > + > +Required properties; > + - compatible: must be "nxp,tda998x" > + > +Optional properties: > + - interrupts: interrupt number for HDMI exchanges - default: by polling What are HDMI exchanges, and how do they differ from other interrupts? > + > + - pinctrl-0: pin control group to be used for this controller (IRQ). > + > + - pinctrl-names: must contain a "default" entry. > + > + - video-ports: 24 bits value - default: <0x230145> What is this? -Olof -- 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 1/3] percpu_ida: Make percpu_ida_alloc + callers accept task state bitmask
From: Kent Overstreet
This patch changes percpu_ida_alloc() + callers to accept task state
bitmask for prepare_to_wait() for code like target/iscsi that needs
it for interruptible sleep, that is provided in a subsequent patch.
It now expects TASK_UNINTERRUPTIBLE when the caller is able to sleep
waiting for a new tag, or TASK_RUNNING when the caller cannot sleep,
and is forced to return a negative value when no tags are available.
v2 changes:
- Include blk-mq + tcm_fc + vhost/scsi + target/iscsi changes
- Drop signal_pending_state() call
Reported-by: Linus Torvalds
Cc: Linus Torvalds
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Jens Axboe
Signed-off-by: Kent Overstreet
Cc: #3.12+
Signed-off-by: Nicholas Bellinger
---
block/blk-mq-tag.c |6 --
drivers/target/iscsi/iscsi_target_util.c |8 ++--
drivers/target/tcm_fc/tfc_cmd.c |2 +-
drivers/vhost/scsi.c |2 +-
include/linux/percpu_ida.h |3 ++-
lib/percpu_ida.c | 12 ++--
6 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index d64a02f..5d70edc 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -36,7 +36,8 @@ static unsigned int __blk_mq_get_tag(struct blk_mq_tags
*tags, gfp_t gfp)
{
int tag;
- tag = percpu_ida_alloc(>free_tags, gfp);
+ tag = percpu_ida_alloc(>free_tags, (gfp & __GFP_WAIT) ?
+ TASK_UNINTERRUPTIBLE : TASK_RUNNING);
if (tag < 0)
return BLK_MQ_TAG_FAIL;
return tag + tags->nr_reserved_tags;
@@ -52,7 +53,8 @@ static unsigned int __blk_mq_get_reserved_tag(struct
blk_mq_tags *tags,
return BLK_MQ_TAG_FAIL;
}
- tag = percpu_ida_alloc(>reserved_tags, gfp);
+ tag = percpu_ida_alloc(>reserved_tags, (gfp & __GFP_WAIT) ?
+ TASK_UNINTERRUPTIBLE : TASK_RUNNING);
if (tag < 0)
return BLK_MQ_TAG_FAIL;
return tag;
diff --git a/drivers/target/iscsi/iscsi_target_util.c
b/drivers/target/iscsi/iscsi_target_util.c
index 0819e68..9b8e1db 100644
--- a/drivers/target/iscsi/iscsi_target_util.c
+++ b/drivers/target/iscsi/iscsi_target_util.c
@@ -156,9 +156,13 @@ struct iscsi_cmd *iscsit_allocate_cmd(struct iscsi_conn
*conn, gfp_t gfp_mask)
{
struct iscsi_cmd *cmd;
struct se_session *se_sess = conn->sess->se_sess;
- int size, tag;
+ int size, tag, state = (gfp_mask & __GFP_WAIT) ? TASK_UNINTERRUPTIBLE :
+ TASK_RUNNING;
+
+ tag = percpu_ida_alloc(_sess->sess_tag_pool, state);
+ if (tag < 0)
+ return NULL;
- tag = percpu_ida_alloc(_sess->sess_tag_pool, gfp_mask);
size = sizeof(struct iscsi_cmd) + conn->conn_transport->priv_size;
cmd = (struct iscsi_cmd *)(se_sess->sess_cmd_map + (tag * size));
memset(cmd, 0, size);
diff --git a/drivers/target/tcm_fc/tfc_cmd.c b/drivers/target/tcm_fc/tfc_cmd.c
index 479ec56..8b2c1aa 100644
--- a/drivers/target/tcm_fc/tfc_cmd.c
+++ b/drivers/target/tcm_fc/tfc_cmd.c
@@ -438,7 +438,7 @@ static void ft_recv_cmd(struct ft_sess *sess, struct
fc_frame *fp)
struct se_session *se_sess = sess->se_sess;
int tag;
- tag = percpu_ida_alloc(_sess->sess_tag_pool, GFP_ATOMIC);
+ tag = percpu_ida_alloc(_sess->sess_tag_pool, TASK_RUNNING);
if (tag < 0)
goto busy;
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 84488a8..2d084fb 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -728,7 +728,7 @@ vhost_scsi_get_tag(struct vhost_virtqueue *vq,
}
se_sess = tv_nexus->tvn_se_sess;
- tag = percpu_ida_alloc(_sess->sess_tag_pool, GFP_ATOMIC);
+ tag = percpu_ida_alloc(_sess->sess_tag_pool, TASK_RUNNING);
if (tag < 0) {
pr_err("Unable to obtain tag for tcm_vhost_cmd\n");
return ERR_PTR(-ENOMEM);
diff --git a/include/linux/percpu_ida.h b/include/linux/percpu_ida.h
index 1900bd0..f5cfdd6 100644
--- a/include/linux/percpu_ida.h
+++ b/include/linux/percpu_ida.h
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -61,7 +62,7 @@ struct percpu_ida {
/* Max size of percpu freelist, */
#define IDA_DEFAULT_PCPU_SIZE ((IDA_DEFAULT_PCPU_BATCH_MOVE * 3) / 2)
-int percpu_ida_alloc(struct percpu_ida *pool, gfp_t gfp);
+int percpu_ida_alloc(struct percpu_ida *pool, int state);
void percpu_ida_free(struct percpu_ida *pool, unsigned tag);
void percpu_ida_destroy(struct percpu_ida *pool);
diff --git a/lib/percpu_ida.c b/lib/percpu_ida.c
index 9d054bf..a48ce2e 100644
--- a/lib/percpu_ida.c
+++ b/lib/percpu_ida.c
@@ -132,22 +132,22 @@ static inline unsigned alloc_local_tag(struct
percpu_ida_cpu *tags)
/**
* percpu_ida_alloc - allocate a tag
* @pool: pool to allocate from
- * @gfp: gfp
Re: [PATCH] [PATCH net-next v2] net: stmmac: fix NULL pointer dereference in stmmac_get_tx_hwtstamp
From: Bruce Liu Date: Fri, 17 Jan 2014 23:47:59 +0800 > When timestamping is enabled, stmmac_tx_clean will call > stmmac_get_tx_hwtstamp to get tx TS. > But the skb can be NULL because the last of its tx_skbuff is NULL > if this packet frame is filled in more than one descriptors. > > To fix the issue, change the code: > - Store TX skb to the tx_skbuff[] of frame's last segment. > - Check skb is not NULL in stmmac_get_tx_hwtstamp. > > Signed-off-by: Bruce Liu Looks a lot better, applied, thanks. -- 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 net-next v3 0/8] net: stmmac: Add Allwinner A20 GMAC ethernet
From: Chen-Yu Tsai Date: Fri, 17 Jan 2014 21:24:39 +0800 > This is v3 of the Allwinner A20 GMAC glue layer for stmmac. > I have split the series into stmmac driver changes for net-next, > and clock and DT patches for their respective trees. Series applied, thanks. -- 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 net] net: document accel_priv parameter for __dev_queue_xmit()
From: Jason Wang Date: Mon, 20 Jan 2014 11:25:13 +0800 > To silent "make htmldocs" warning. > > Reported-by: kbuild test robot > Signed-off-by: Jason Wang Applied to net-next. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the tip tree
On Sat, 18 Jan 2014 10:46:06 +0100 Mike Galbraith wrote: > > I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on > Q6600 box. See below for an alternative. > > idle: kill unnecessary mwait_idle() resched IPIs OK, so despite even further discussion, I have applied this as a merge fix patch for today. Let me know when it is all sorted out. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpkZtGGeZ25G.pgp Description: PGP signature
Re: [PATCH net] net: document accel_priv parameter for __dev_queue_xmit()
From: Jason Wang Date: Mon, 20 Jan 2014 11:25:13 +0800 > To silent "make htmldocs" warning. > > Reported-by: kbuild test robot > Signed-off-by: Jason Wang This is certainly not such a catastrophic error that it should be targetted at the 'net' tree. -- 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 net] tun: handle copy failure in tun_put_user()
From: Jason Wang Date: Mon, 20 Jan 2014 11:16:48 +0800 > This patch return the error code of copy helpers in tun_put_user() instead of > ignoring them. > > Cc: Michael S. Tsirkin > Signed-off-by: Jason Wang If you perform some of the copy successfully, you have to report that length rather than just an error. Otherwise userland has no way to determine how much of the data was successfully sourced. I'm not applying this, sorry. -- 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: don't use module_init in non-modular ... (was: Re: [PATCH] m68k: don't use module_init in non-modular mvme16x/rtc.c code)
On Jan 19, 2014, at 7:27 PM, Paul Gortmaker wrote: [Re: don't use module_init in non-modular ... (was: Re: [PATCH] m68k: don't use module_init in non-modular mvme16x/rtc.c code)] On 19/01/2014 (Sun 10:40) Geert Uytterhoeven wrote: The word "module" has different meanings: it can be a "loadable kernel module", or just a "code module". include/linux/init.h seems to agree with this: I think for most people, "module" means an actual "foo.ko" that can be fed to insmod. And it is generated by code that is controlled by a tristate config. Otherwise, sure "init/main.c" is a "code module" and so is every C file, making the distinction meaningless. Further Consider calling the C file a "unit", analogous (and isomorphic) to "translation unit". Josh -- 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 v9 4/5] qrwlock: Use smp_store_release() in write_unlock()
On Tue, Jan 14, 2014 at 11:44:06PM -0500, Waiman Long wrote:
> This patch modifies the queue_write_unlock() function to use the new
> smp_store_release() function (currently in tip). It also removes the
> temporary implementation of smp_load_acquire() and smp_store_release()
> function in qrwlock.c.
>
> This patch will use atomic subtraction instead if the writer field is
> not atomic.
>
> Signed-off-by: Waiman Long
Reviewed-by: Paul E. McKenney
> ---
> include/asm-generic/qrwlock.h | 10 ++
> kernel/locking/qrwlock.c | 34 --
> 2 files changed, 6 insertions(+), 38 deletions(-)
>
> diff --git a/include/asm-generic/qrwlock.h b/include/asm-generic/qrwlock.h
> index 5abb6ca..68f488b 100644
> --- a/include/asm-generic/qrwlock.h
> +++ b/include/asm-generic/qrwlock.h
> @@ -181,11 +181,13 @@ static inline void queue_read_unlock(struct qrwlock
> *lock)
> static inline void queue_write_unlock(struct qrwlock *lock)
> {
> /*
> - * Make sure that none of the critical section will be leaked out.
> + * If the writer field is atomic, it can be cleared directly.
> + * Otherwise, an atomic subtraction will be used to clear it.
>*/
> - smp_mb__before_clear_bit();
> - ACCESS_ONCE(lock->cnts.writer) = 0;
> - smp_mb__after_clear_bit();
> + if (__native_word(lock->cnts.writer))
> + smp_store_release(>cnts.writer, 0);
> + else
> + atomic_sub(_QW_LOCKED, >cnts.rwa);
> }
>
> /*
> diff --git a/kernel/locking/qrwlock.c b/kernel/locking/qrwlock.c
> index 053be4d..2727188 100644
> --- a/kernel/locking/qrwlock.c
> +++ b/kernel/locking/qrwlock.c
> @@ -47,40 +47,6 @@
> # define arch_mutex_cpu_relax() cpu_relax()
> #endif
>
> -#ifndef smp_load_acquire
> -# ifdef CONFIG_X86
> -# define smp_load_acquire(p) \
> - ({ \
> - typeof(*p) ___p1 = ACCESS_ONCE(*p); \
> - barrier(); \
> - ___p1; \
> - })
> -# else
> -# define smp_load_acquire(p) \
> - ({ \
> - typeof(*p) ___p1 = ACCESS_ONCE(*p); \
> - smp_mb(); \
> - ___p1; \
> - })
> -# endif
> -#endif
> -
> -#ifndef smp_store_release
> -# ifdef CONFIG_X86
> -# define smp_store_release(p, v) \
> - do {\
> - barrier(); \
> - ACCESS_ONCE(*p) = v;\
> - } while (0)
> -# else
> -# define smp_store_release(p, v) \
> - do {\
> - smp_mb(); \
> - ACCESS_ONCE(*p) = v;\
> - } while (0)
> -# endif
> -#endif
> -
> /*
> * If an xadd (exchange-add) macro isn't available, simulate one with
> * the atomic_add_return() function.
> --
> 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/
Re: [PATCH 1/2] USB: at91: fix the number of endpoint parameter
Hi J,
On 01/18/2014 01:20 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 10:59 Fri 17 Jan , Bo Shen wrote:
In sama5d3 SoC, there are 16 endpoints. As the USBA_NR_ENDPOINTS
is only 7. So, fix it for sama5d3 SoC using the udc->num_ep.
Signed-off-by: Bo Shen
---
drivers/usb/gadget/atmel_usba_udc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/atmel_usba_udc.c
b/drivers/usb/gadget/atmel_usba_udc.c
index 2cb52e0..7e67a81 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -1670,7 +1670,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
if (ep_status) {
int i;
- for (i = 0; i < USBA_NR_ENDPOINTS; i++)
+ for (i = 0; i < udc->num_ep; i++)
no the limit need to specified in the driver as a checkpoint by the compatible
or platform driver id
You mean, we should not trust the data passed from dt node or platform
data? Or do you think we should do double confirm?
Best Regards,
J.
if (ep_status & (1 << i)) {
if (ep_is_control(>usba_ep[i]))
usba_control_irq(udc, >usba_ep[i]);
--
1.8.5.2
Best Regards,
Bo Shen
--
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] at drivers/md/raid5.c:291! kernel 3.13-rc8
On Mon, 20 Jan 2014 01:49:17 +0100 Ian Kumlien wrote: > On mån, 2014-01-20 at 11:38 +1100, NeilBrown wrote: > > On Sun, 19 Jan 2014 23:00:23 +0100 Ian Kumlien > > wrote: > > > > > Ok, so third try to actually email this... > > > --- > > > > > > Hi, > > > > > > I started testing 3.13-rc8 on another machine since the first one seemed > > > to be working fine... > > > > > > One spontaneous reboot later i'm not so sure ;) > > > > > > Right now i captured a kernel oops in the raid code it seems... > > > > > > (Also attached to avoid mangling) > > > > > > [33411.934672] [ cut here ] > > > [33411.934685] kernel BUG at drivers/md/raid5.c:291! > > > [33411.934690] invalid opcode: [#1] PREEMPT SMP > > > [33411.934696] Modules linked in: bonding btrfs microcode > > > [33411.934705] CPU: 4 PID: 2319 Comm: md2_raid6 Not tainted 3.13.0-rc8 #83 > > > [33411.934709] Hardware name: System manufacturer System Product > > > Name/Crosshair IV Formula, BIOS 302910/09/2012 > > > [33411.934716] task: 880326265880 ti: 880320472000 task.ti: > > > 880320472000 > > > [33411.934720] RIP: 0010:[] [] > > > do_release_stripe+0x18e/0x1a0 > > > [33411.934731] RSP: 0018:880320473d28 EFLAGS: 00010087 > > > [33411.934735] RAX: 8802f0875a60 RBX: 0001 RCX: > > > 8800b0d816b0 > > > [33411.934739] RDX: 88032498 RSI: 8802f0875a40 RDI: > > > 880324eeec00 > > > [33411.934743] RBP: 8802f0875a50 R08: R09: > > > 0001 > > > [33411.934747] R10: R11: R12: > > > 880324eeec00 > > > [33411.934752] R13: 88032458 R14: 880320473e88 R15: > > > > > > [33411.934756] FS: 7fc38654d700() GS:880337d0() > > > knlGS: > > > [33411.934761] CS: 0010 DS: ES: CR0: 8005003b > > > [33411.934765] CR2: 7f0cb28bd000 CR3: 0002ebcf6000 CR4: > > > 000407e0 > > > [33411.934769] Stack: > > > [33411.934771] 8800bba09690 8800b4f16588 880303005a40 > > > 0001 > > > [33411.934779] 8800b33e43d0 81a3a62d 88032458 > > > > > > [33411.934786] 88032458 880326660670 880326265880 > > > 81a41692 > > > [33411.934794] Call Trace: > > > [33411.934798] [] ? release_stripe_list+0x4d/0x70 > > > [33411.934803] [] ? raid5d+0xa2/0x4d0 > > > [33411.934808] [] ? md_thread+0xe6/0x120 > > > [33411.934814] [] ? finish_wait+0x90/0x90 > > > [33411.934818] [] ? md_rdev_init+0x100/0x100 > > > [33411.934823] [] ? kthread+0xbc/0xe0 > > > [33411.934828] [] ? smpboot_park_threads+0x70/0x70Hi, > > > > Thanks for the report. > > Can you provide any more context about the details of the array in question? > > I see it was RAID6. Was it degraded? Was it resyncing? Was it being > > reshaped? > > Was there any way that it was different from the array one the machine where > > it seemed to work? > > Yes, it's a raid6 and no, there is no reshaping or syncing going on... > > Basically everything worked fine before: > reboot system boot 3.13.0-rc8 Sun Jan 19 21:47 - 01:42 (03:55) > reboot system boot 3.13.0-rc8 Sun Jan 19 21:38 - 01:42 (04:04) > reboot system boot 3.13.0-rc8 Sun Jan 19 12:13 - 01:42 (13:29) > reboot system boot 3.13.0-rc8 Sat Jan 18 21:23 - 01:42 (1+04:19) > reboot system boot 3.12.6 Mon Dec 30 16:27 - 22:21 (19+05:53) > > As in, no problems before the 3.13.0-rc8 upgrade... > > cat /proc/mdstat: > Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] > [multipath] > md2 : active raid6 sdf1[2] sdd1[9] sdj1[8] sdg1[4] sde1[5] sdi1[11] sdc1[0] > sdh1[10] > 11721074304 blocks super 1.2 level 6, 64k chunk, algorithm 2 [8/8] > [] > bitmap: 0/15 pages [0KB], 65536KB chunk > > What i do do is: > echo 32768 > /sys/block/*/md/stripe_cache_size > > Which has caused no problems during intense write operations before... > > I find it quite surprising since it only requires ~3 gigabytes of writes > to die and almost assume that it's related to the stripe_cache_size. > (Since all memory is ECC and i doubt it would break, quite literally, > over night i haven't run extensive memory tests) > > I don't quite know what other information you might need... Thanks - that extra info is quite useful. Knowing that nothing else unusual is happening can be quite valuable (and I don't like to assume). I haven't found anything that would clearly cause your crash, but I have found something that looks wrong and conceivably could. Could you please try this patch on top of what you are currently using? By the look of it you get a crash at least every day, often more often. So if this produces a day with no crashes, that would be promising. The important aspect of the patch is that it moves the "atomic_inc" of "sh->count" back under the
Re: don't use module_init in non-modular ... (was: Re: [PATCH] m68k: don't use module_init in non-modular mvme16x/rtc.c code)
[Re: don't use module_init in non-modular ... (was: Re: [PATCH] m68k: don't use
module_init in non-modular mvme16x/rtc.c code)] On 19/01/2014 (Sun 10:40) Geert
Uytterhoeven wrote:
> Hi Paul,
>
> On Thu, Jan 16, 2014 at 11:15 PM, Paul Gortmaker
> wrote:
> > The rtc.o is built for obj-y, i.e. always built in. It will
> > never be modular, so using module_init as an alias for __initcall
> > can be somewhat misleading.
> >
> > Fix this up now, so that we can relocate module_init from
> > init.h into module.h in the future. If we don't do this, we'd
> > have to add module.h to obviously non-modular code, and that
> > would be a worse thing.
>
> The word "module" has different meanings: it can be a "loadable kernel
> module",
> or just a "code module". include/linux/init.h seems to agree with this:
I think for most people, "module" means an actual "foo.ko" that can be
fed to insmod. And it is generated by code that is controlled by a
tristate config. Otherwise, sure "init/main.c" is a "code module" and
so is every C file, making the distinction meaningless. Further
> /**
> * module_init() - driver initialization entry point
> * @x: function to be run at kernel boot time or module insertion
> *
> * module_init() will either be called during do_initcalls() (if
> * builtin) or at module insertion time (if a module). There can only
> * be one per module.
...I don't see how you can use the above comments to imply agreement
with your interpretation. The above refers to what is done with
tristate (i.e. modular) code in the =y case and the =m case. I'd be
reluctant to think it meant anything about non-modular code in general.
Moving this block inside of module.h helps clarify that, as well.
> */
> #define module_init(x) __initcall(x);
>
> I can understand you want to restrict "module_init()" to real loadable
> modules, but "device_initcall()" sounds like a real bad name or this.
It is an existing name, it is part of the infrastructure added to
replace the non-prioritized __initcall, and what is wrong with a
non-modular device driver calling device_initcall()? I don't see the
badness. Seems like quite a good fit, actually. Just like having
non-modular specific arch code calling arch_initcall() etc. etc.
>
> Furthermore, many places that contain always compiled-in code and
> currently only use module_init() should probably start using module_exit()
> as well, to do the proper cleanups to make kexec work.
Always compiled in code that uses module_init() blocks us from ever
properly making use of the prioritied initcall levels, because they
all land in one bucket. See the mm and kernel commits making use of
priority levels in mm/ and kernel/ in akpm's mmotm tree for examples.
kexec: BenH started an interesting thread about it and what it needs for
a new powerpc target; it is an interesting read, but what kexec does in
the future will be largely independent of what I'm trying to do here.
Things like putting a device into a quiescent state vs removing the
actual driver and its associated memory allocations - the former would
be a new kexec specific callback.
Thanks for the feedback, but I'm not sure I'm following or agreeing
with your reservations about making these fairly simple and
straighforward clarifications/cleanups. I'm hoping perhaps in the above
I've had some luck in clarifying why they are useful and sensible.
Paul.
--
>
> So I'm not really convinced this is the way we want to go...
>
> > Note that direct use of __initcall is discouraged, vs. one
> > of the priority categorized subgroups. As __initcall gets
> > mapped onto device_initcall, our use of device_initcall
> > directly in this change means that the runtime impact is
> > zero -- it will remain at level 6 in initcall ordering.
> >
> > Cc: Geert Uytterhoeven
> > Cc: linux-m...@lists.linux-m68k.org
> > Signed-off-by: Paul Gortmaker
> >
> > diff --git a/arch/m68k/mvme16x/rtc.c b/arch/m68k/mvme16x/rtc.c
> > index 6ef7a81a3b12..1755e2f7137d 100644
> > --- a/arch/m68k/mvme16x/rtc.c
> > +++ b/arch/m68k/mvme16x/rtc.c
> > @@ -161,4 +161,4 @@ static int __init rtc_MK48T08_init(void)
> > printk(KERN_INFO "MK48T08 Real Time Clock Driver v%s\n",
> > RTC_VERSION);
> > return misc_register(_dev);
> > }
> > -module_init(rtc_MK48T08_init);
> > +device_initcall(rtc_MK48T08_init);
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
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
[PATCH net] net: document accel_priv parameter for __dev_queue_xmit()
To silent "make htmldocs" warning. Reported-by: kbuild test robot Signed-off-by: Jason Wang --- net/core/dev.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/core/dev.c b/net/core/dev.c index 0ce469e..d78dc62 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -2781,8 +2781,9 @@ int dev_loopback_xmit(struct sk_buff *skb) EXPORT_SYMBOL(dev_loopback_xmit); /** - * dev_queue_xmit - transmit a buffer + * __dev_queue_xmit - transmit a buffer * @skb: buffer to transmit + * @accel_priv: private data used for L2 forwarding offload * * Queue a buffer for transmission to a network device. The caller must * have set the device and priority and built the buffer before calling -- 1.8.3.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: [alsa-devel] [PATCH] ASoC: core: Use devm_kzalloc() instead kzalloc()
Hi Mar, Lars > > I don't like this. I don't think it is a good design pattern to call > > devm function from within (especial non-devm) library functions. It > > creates an asymmetric API. The memory is allocated when > > snd_dmaengine_pcm_register() is called, but it is not freed when > > snd_dmaengine_pcm_unregister() is called. This goes against the > > principle of least surprise. > > Yes, I tend to agree - unless we only support managed registration the > API shouldn't do managed things internally. Got it. Thanks, -- 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 net] tun: handle copy failure in tun_put_user()
This patch return the error code of copy helpers in tun_put_user() instead of
ignoring them.
Cc: Michael S. Tsirkin
Signed-off-by: Jason Wang
---
drivers/net/tun.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index ecec802..4ec8f28 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1185,7 +1185,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
{
struct tun_pi pi = { 0, skb->protocol };
ssize_t total = 0;
- int vlan_offset = 0, copied;
+ int vlan_offset = 0, copied, ret;
if (!(tun->flags & TUN_NO_PI)) {
if ((len -= sizeof(pi)) < 0)
@@ -1254,7 +1254,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
if (!vlan_tx_tag_present(skb)) {
len = min_t(int, skb->len, len);
} else {
- int copy, ret;
+ int copy;
struct {
__be16 h_vlan_proto;
__be16 h_vlan_TCI;
@@ -1282,13 +1282,13 @@ static ssize_t tun_put_user(struct tun_struct *tun,
goto done;
}
- skb_copy_datagram_const_iovec(skb, vlan_offset, iv, copied, len);
+ ret = skb_copy_datagram_const_iovec(skb, vlan_offset, iv, copied, len);
done:
tun->dev->stats.tx_packets++;
tun->dev->stats.tx_bytes += len;
- return total;
+ return ret ? ret : total;
}
static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
--
1.8.3.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/
Linux 3.13
The release got delayed by a week due to travels, but I suspect that's just as well. We had a few fixes come in, and while it wasn't a lot, I think we're better off for it. At least I hope so - I'll be very disappointed if any of them cause more problems than they fix.. Anyway, the patch from rc8 is fairly small, with mainly some small arch updates (arm, mips, powerpc, s390, sparc, x86 all had some minor changes, some of them due to a networking fix for the bpf jit). And drivers (mainly gpu and networking). And some generic networking fixes. The appended shortlog gives more details. Anyway, with this, the merge window for 3.14 is obviously open. Linus --- Aaro Koskinen (1): MIPS: fix blast_icache32 on loongson2 Andreas Rohner (1): nilfs2: fix segctor bug that causes file system corruption Andrew Jones (1): kvm: x86: fix apic_base enable check Ben Skeggs (1): drm/nouveau: fix null ptr dereferences on some boards Benjamin Herrenschmidt (1): powerpc: Check return value of instance-to-package OF call Bjørn Mork (1): net: usbnet: fix SG initialisation Catalin Marinas (1): Revert "arm64: Fix memory shareability attribute for ioremap_wc/cache" Christian Engelmayer (1): ieee802154: Fix memory leak in ieee802154_add_iface() Christoph Paasch (1): tcp: metrics: Avoid duplicate entries with the same destination-IP Dan Carpenter (1): cxgb4: silence shift wrapping static checker warning Dave Airlie (1): Revert "drm: copy mode type in drm_mode_connector_list_update()" Eric Dumazet (2): bpf: do not use reciprocal divide parisc: fix SO_MAX_PACING_RATE typo Eric W. Biederman (3): vfs: In d_path don't call d_dname on a mount point fork: Allow CLONE_PARENT after setns(CLONE_NEWPID) vfs: Fix a regression in mounting proc Gerald Schaefer (1): net: rds: fix per-cpu helper usage Hannes Frederic Sowa (2): net: avoid reference counter overflows on fib_rules in multicast forwarding ipv6: simplify detection of first operational link-local address on interface Heiko Carstens (1): s390/bpf,jit: fix 32 bit divisions, use unsigned divide instructions Huacai Chen (1): MIPS: fix case mismatch in local_r4k_flush_icache_range() Hugh Dickins (1): percpu_counter: unbreak __percpu_counter_add() Ilia Mirkin (1): drm/nouveau/mxm: fix null deref on load Ivan Vecera (1): be2net: add dma_mapping_error() check for dma_map_page() Jan Kara (1): writeback: Fix data corruption on NFS Jean Delvare (1): hwmon: (coretemp) Fix truncated name of alarm attributes Jesse Barnes (1): drm/i915/bdw: make sure south port interrupts are enabled properly v2 Jitendra Kalsaria (1): qlge: Fix vlan netdev features. John Stultz (2): seqlock: Use raw_ prefix instead of _no_lockdep sched_clock: Disable seqlock lockdep usage in sched_clock() Linus Torvalds (2): x86, fpu, amd: Clear exceptions in AMD FXSAVE workaround Linux 3.13 Marek Lindner (1): batman-adv: fix batman-adv header overhead calculation Michael S. Tsirkin (1): MAINTAINERS: add virtio-dev ML for virtio Mika Westerberg (1): e1000e: Fix compilation warning when !CONFIG_PM_SLEEP Mikulas Patocka (1): mm: fix crash when using XFS on loopback Ming Lei (1): lib/percpu_counter.c: fix __percpu_counter_add() Neal Cardwell (1): inet_diag: fix inet_diag_dump_icsk() to use correct state for timewait sockets NeilBrown (6): md/raid5: Fix possible confusion when multiple write errors occur. md/raid10: fix two bugs in handling of known-bad-blocks. md/raid1: fix request counting bug in new 'barrier' code. md/raid5: fix a recently broken BUG_ON(). md/raid10: fix bug when raid10 recovery fails to recover a block. md: fix problem when adding device to read-only array with bitmap. Paulo Zanoni (1): drm/i915: fix DDI PLLs HW state readout code Peter Korsgaard (1): dm9601: add USB IDs for new dm96xx variants Peter Zijlstra (1): x86, mm, perf: Allow recursive faults from interrupts Qais Yousef (1): crash_dump: fix compilation error (on MIPS at least) Rafael J. Wysocki (1): Revert "ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs" Richard Weinberger (1): net,via-rhine: Fix tx_timeout handling Rik van Riel (1): sched: Calculate effective load even if local weight is 0 Robert Richter (1): perf/x86/amd/ibs: Fix waking up from S3 for AMD family 10h Russell King (1): Revert "ARM: 7908/1: mm: Fix the arm_dma_limit calculation" Soren Brinkmann (1): clocksource: cadence_ttc: Fix mutex taken inside interrupt context Stephen Boyd (1): ARM: 7937/1: perf_event: Silence sparse warning Stephen Warren (1): i2c: Re-instate body of i2c_parent_is_i2c_adapter() Steven Rostedt (1): ftrace/x86: Load ftrace_ops in parameter not the variable holding it Sudeep
Re: [discussion] simpler load balance in scheduler
On Mon, Jan 06, 2014 at 09:44:36PM +0800, Alex Shi wrote: > On 12/18/2013 12:32 AM, Paul E. McKenney wrote: > > On Fri, Dec 13, 2013 at 06:09:47PM +0800, Alex Shi wrote: [ . . . ] > > 3. Allow the exported values to become inaccurate, and resample > > the actual values remotely if extrapolated values indicate > > that action is warranted. > > It is a very heuristic idea! Could you give a bit more hints/clues to > get remote cpu load by extrapolated value? I know RCU use this way > wonderfully. but still no much idea to get live cpu load... Well, as long as the CPU continues doing the same thing, for example, being idle or running a user-mode task, the extrapolation should be exact, right? The load value was X the last time the CPU changed state, and T time has passed since then, so you can calculated it exactly. The exact method for detecting inaccuracies depends on how and where you are calculating the load values. If you are calculating them on each state change (as is done for some values for NO_HZ_FULL), then you simply need sufficient synchronization for geting a consistent snapshot of several values. One easy way to do this is via a per-CPU seqlock. The state-change code write-acquires the seqlock, while those doing extrapolation read-acquire it and retry if changes occur. This can have problems if too many values are required and if changes occur too fast, but such problems can be addressed should they occur. Does that help? Thanx, Paul > > There are probably other approaches. I am being quite general here > > because I don't have the full picture of the scheduler statistics > > in my head. It is likely possible to obtain a much better approach > > by considering the scheduler's specifics. > > > >>> BTW, to reduce unnecessary remote info fetching, we can use current > >>> idle_cpus_mask in nohz, we just skip the idle cpu in this cpumask simply. > > [..] > > > > Thanx, Paul > > > >>> 4, From power saving POV, top-down give the whole system cpu topology > >>> info directly. So beside the CS reducing, it can reduce the idle cpu > >>> interfere by a transition task. and let idle cpu sleep better. > > -- > Thanks > Alex > -- 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: ipv4_dst_destroy panic regression after 3.10.15
> On Fri, 2014-01-17 at 17:25 -0800, dormando wrote: > > Hi, > > > > Upgraded a few kernels to the latest 3.10 stable tree while tracking down > > a rare kernel panic, seems to have introduced a much more frequent kernel > > panic. Takes anywhere from 4 hours to 2 days to trigger: > > > > <4>[196727.311203] general protection fault: [#1] SMP > > <4>[196727.311224] Modules linked in: xt_TEE xt_dscp xt_DSCP macvlan bridge > > coretemp crc32_pclmul ghash_clmulni_intel gpio_ich microcode ipmi_watchdog > > ipmi_devintf sb_edac edac_core lpc_ich mfd_core tpm_tis tpm tpm_bios > > ipmi_si ipmi_msghandler isci igb libsas i2c_algo_bit ixgbe ptp pps_core mdio > > <4>[196727.311333] CPU: 17 PID: 0 Comm: swapper/17 Not tainted 3.10.26 #1 > > <4>[196727.311344] Hardware name: Supermicro > > X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0 07/05/2013 > > <4>[196727.311364] task: 885e6f069700 ti: 885e6f072000 task.ti: > > 885e6f072000 > > <4>[196727.311377] RIP: 0010:[] [] > > ipv4_dst_destroy+0x4f/0x80 > > <4>[196727.311399] RSP: 0018:885effd23a70 EFLAGS: 00010282 > > <4>[196727.311409] RAX: dead00200200 RBX: 8854c398ecc0 RCX: > > 0040 > > <4>[196727.311423] RDX: dead00100100 RSI: dead00100100 RDI: > > dead00200200 > > <4>[196727.311437] RBP: 885effd23a80 R08: 815fd9e0 R09: > > 885d5a590800 > > <4>[196727.311451] R10: R11: R12: > > > > <4>[196727.311464] R13: 81c8c280 R14: R15: > > 880e85ee16ce > > <4>[196727.311510] FS: () GS:885effd2() > > knlGS: > > <4>[196727.311554] CS: 0010 DS: ES: CR0: 80050033 > > <4>[196727.311581] CR2: 7a46751eb000 CR3: 005e65688000 CR4: > > 000407e0 > > <4>[196727.311625] DR0: DR1: DR2: > > > > <4>[196727.311669] DR3: DR6: 0ff0 DR7: > > 0400 > > <4>[196727.311713] Stack: > > <4>[196727.311733] 8854c398ecc0 8854c398ecc0 885effd23ab0 > > 815b7f42 > > <4>[196727.311784] 88be6595bc00 8854c398ecc0 > > 8854c398ecc0 > > <4>[196727.311834] 885effd23ad0 815b86c6 885d5a590800 > > 8816827821c0 > > <4>[196727.311885] Call Trace: > > <4>[196727.311907] > > <4>[196727.311912] [] dst_destroy+0x32/0xe0 > > <4>[196727.311959] [] dst_release+0x56/0x80 > > <4>[196727.311986] [] tcp_v4_do_rcv+0x2a5/0x4a0 > > <4>[196727.312013] [] tcp_v4_rcv+0x7da/0x820 > > <4>[196727.312041] [] ? ip_rcv_finish+0x360/0x360 > > <4>[196727.312070] [] ? nf_hook_slow+0x7d/0x150 > > <4>[196727.312097] [] ? ip_rcv_finish+0x360/0x360 > > <4>[196727.312125] [] ip_local_deliver_finish+0xb2/0x230 > > <4>[196727.312154] [] ip_local_deliver+0x4a/0x90 > > <4>[196727.312183] [] ip_rcv_finish+0x119/0x360 > > <4>[196727.312212] [] ip_rcv+0x22b/0x340 > > <4>[196727.312242] [] ? macvlan_broadcast+0x160/0x160 > > [macvlan] > > <4>[196727.312275] [] > > __netif_receive_skb_core+0x512/0x640 > > <4>[196727.312308] [] ? kmem_cache_alloc+0x13b/0x150 > > <4>[196727.312338] [] __netif_receive_skb+0x21/0x70 > > <4>[196727.312368] [] netif_receive_skb+0x31/0xa0 > > <4>[196727.312397] [] napi_gro_receive+0xe8/0x140 > > <4>[196727.312433] [] ixgbe_poll+0x551/0x11f0 [ixgbe] > > <4>[196727.312463] [] ? ip_rcv+0x22b/0x340 > > <4>[196727.312491] [] net_rx_action+0x111/0x210 > > <4>[196727.312521] [] ? __netif_receive_skb+0x21/0x70 > > <4>[196727.312552] [] __do_softirq+0xd0/0x270 > > <4>[196727.312583] [] call_softirq+0x1c/0x30 > > <4>[196727.312613] [] do_softirq+0x55/0x90 > > <4>[196727.312640] [] irq_exit+0x55/0x60 > > <4>[196727.312668] [] do_IRQ+0x63/0xe0 > > <4>[196727.312696] [] common_interrupt+0x6a/0x6a > > <4>[196727.312722] > > <4>[196727.312727] [] ? default_idle+0x20/0xe0 > > <4>[196727.312775] [] arch_cpu_idle+0xf/0x20 > > <4>[196727.312803] [] cpu_startup_entry+0xc0/0x270 > > <4>[196727.312833] [] start_secondary+0x1f9/0x200 > > <4>[196727.312860] Code: 4a 9f e9 81 e8 13 cb 0c 00 48 8b 93 b0 00 00 00 48 > > bf 00 02 20 00 00 00 ad de 48 8b 83 b8 00 00 00 48 be 00 01 10 00 00 00 ad > > de <48> 89 42 08 48 89 10 48 89 bb b8 00 00 00 48 c7 c7 4a 9f e9 81 > > <1>[196727.313071] RIP [] ipv4_dst_destroy+0x4f/0x80 > > <4>[196727.313100] RSP > > <4>[196727.313377] ---[ end trace 64b3f14fae0f2e29 ]--- > > <0>[196727.380908] Kernel panic - not syncing: Fatal exception in interrupt > > > > > > ... bisecting it's going to be a pain... I tried eyeballing the diffs and > > am trying a revert or two. > > > > We've hit it in .25, .26 so far. I have .27 running but not sure if it > > crashed, so the change exists between .15 and .25. > > Please try following fix, thanks for the report ! > > diff --git a/net/ipv4/route.c b/net/ipv4/route.c > index 25071b48921c..78a50a22298a 100644 > --- a/net/ipv4/route.c > +++
Re: [RFC PATCH 3/4] virtio_balloon: add pressure notification via a new virtqueue
Luiz Capitulino writes: > On Fri, 17 Jan 2014 09:10:47 +1030 > Rusty Russell wrote: > >> Luiz Capitulino writes: >> > From: Luiz capitulino >> > >> > This commit adds support to a new virtqueue called message virtqueue. >> >> OK, this needs a lot of thought (especially since reworking the virtio >> balloon is on the TODO list for the OASIS virtio technical committee...) >> >> But AFAICT this is a way of explicitly saying "no" to the host's target >> (vs the implicit method of just not meeting the target). I'm not sure >> that gives enough information to the host. On the other hand, I'm not >> sure what information we *can* give. >> >> Should we instead be counter-proposing a target? > > The problem is how to estimate a target value. I found it simpler > to just try to obey what the host is asking for (and fail if not > possible) than trying to make the guest negotiate with the host. Understood, but we already do this the other way where the host tells the guest how much memory to give up. And is a guest expected to automatically inflate the balloon even if the host doesn't want the memory, or wait to be asked? > >> What does qemu do with this information? > > > > There are two possible scenarios: > > > > 1. The balloon driver is currently inflating when it gets under > > pressure > > > > QEMU resets "num_pages" to the current balloon size. This > > cancels the on-going inflate > > > > 2. The balloon driver is not inflating, eg. it's possibly sleeping > > > >QEMU issues a deflate > > > > But note that those scenarios are not supposed to be used with the > > current device, they are part of the automatic ballooning feature. > > I CC'ed you on the QEMU patch, you can find it here case you didn't > > see it: > > > > http://marc.info/?l=kvm=138988966315690=2 Yes, caught that after I replied; I should have checked first. It seems like we are still figuring out how to do ballooning. The best approach in cases like this is to make it simple, so I don't hate this. But note that Daniel Kiper and I have been discussing a new virtio balloon for draft 2 of the standard. I'll CC you when I post that to one of the OASIS virtio mailing lists. Cheers, Rusty. -- 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] percpu_ida: Make percpu_ida_alloc accept task state bitmask
On Sun, Jan 19, 2014 at 2:16 AM, Nicholas A. Bellinger wrote: > > This patch changes percpu_ida_alloc() to accept task state bitmask > for prepare_to_wait() to support interruptible sleep for callers > that require it. This patch-series is not bisectable. Afaik, the first patch will break the build (or at least cause the end result to not actually work). This kind of "split up one large patch into many small patches THAT DON'T ACTUALLY WORK INDIVIDUALLY" model is pure and utter garbage. So a big NAK on this series as being completely broken. To fix it, I would suggest: - make the first patch change all *existing* users (that only have the atomic vs uninterruptible semantics) pass in either TASK_UNINTERRUPTIBLE or TASK_RUNNING depending on whether they had __GFP_WAIT or not. So the first patch would not change *any* semantics or behavior, it would only change the calling convention. - do the cleanup patches to block/blk-mq-tag.c to not have those "gfp" calling convention, and instead passing in the state natively - add the TASK_INTERRUPTIBLE case last (which includes the new "signal_pending_state()" logic in percpu_ida_alloc()) that way, all patches compile cleanly and should each work individually, and they all do clearly just one thing. And the biggest patch in the series (the first one) doesn't actually make any semantic changes. Linus -- 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 v7 5/6] MCS Lock: allow architectures to hook in to contended paths
On Thu, Jan 16, 2014 at 04:08:31PM -0800, Tim Chen wrote:
> When contended, architectures may be able to reduce the polling overhead
> in ways which aren't expressible using a simple relax() primitive.
>
> This patch allows architectures to hook into the mcs_{lock,unlock}
> functions for the contended cases only.
>
> From: Will Deacon
> Signed-off-by: Will Deacon
Reviewed-by: Paul E. McKenney
> ---
> kernel/locking/mcs_spinlock.c | 47
> +--
> 1 file changed, 27 insertions(+), 20 deletions(-)
>
> diff --git a/kernel/locking/mcs_spinlock.c b/kernel/locking/mcs_spinlock.c
> index 6cdc730..66d8883 100644
> --- a/kernel/locking/mcs_spinlock.c
> +++ b/kernel/locking/mcs_spinlock.c
> @@ -7,19 +7,34 @@
> * It avoids expensive cache bouncings that common test-and-set spin-lock
> * implementations incur.
> */
> -/*
> - * asm/processor.h may define arch_mutex_cpu_relax().
> - * If it is not defined, cpu_relax() will be used.
> - */
> +
> #include
> #include
> #include
> #include
> #include
> +#include
> #include
>
> -#ifndef arch_mutex_cpu_relax
> -# define arch_mutex_cpu_relax() cpu_relax()
> +#ifndef arch_mcs_spin_lock_contended
> +/*
> + * Using smp_load_acquire() provides a memory barrier that ensures
> + * subsequent operations happen after the lock is acquired.
> + */
> +#define arch_mcs_spin_lock_contended(l)
> \
> + while (!(smp_load_acquire(l))) {\
> + arch_mutex_cpu_relax(); \
> + }
> +#endif
> +
> +#ifndef arch_mcs_spin_unlock_contended
> +/*
> + * smp_store_release() provides a memory barrier to ensure all
> + * operations in the critical section has been completed before
> + * unlocking.
> + */
> +#define arch_mcs_spin_unlock_contended(l)\
> + smp_store_release((l), 1)
> #endif
>
> /*
> @@ -43,13 +58,9 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct
> mcs_spinlock *node)
> return;
> }
> ACCESS_ONCE(prev->next) = node;
> - /*
> - * Wait until the lock holder passes the lock down.
> - * Using smp_load_acquire() provides a memory barrier that
> - * ensures subsequent operations happen after the lock is acquired.
> - */
> - while (!(smp_load_acquire(>locked)))
> - arch_mutex_cpu_relax();
> +
> + /* Wait until the lock holder passes the lock down. */
> + arch_mcs_spin_lock_contended(>locked);
> }
> EXPORT_SYMBOL_GPL(mcs_spin_lock);
>
> @@ -71,12 +82,8 @@ void mcs_spin_unlock(struct mcs_spinlock **lock, struct
> mcs_spinlock *node)
> while (!(next = ACCESS_ONCE(node->next)))
> arch_mutex_cpu_relax();
> }
> - /*
> - * Pass lock to next waiter.
> - * smp_store_release() provides a memory barrier to ensure
> - * all operations in the critical section has been completed
> - * before unlocking.
> - */
> - smp_store_release(>locked, 1);
> +
> + /* Pass lock to next waiter. */
> + arch_mcs_spin_unlock_contended(>locked);
> }
> EXPORT_SYMBOL_GPL(mcs_spin_unlock);
> --
> 1.7.11.7
>
>
>
--
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 v7 6/6] MCS Lock: add Kconfig entries to allow arch-specific hooks
On Thu, Jan 16, 2014 at 04:08:36PM -0800, Tim Chen wrote:
> This patch adds Kconfig entries to allow architectures to hook into the
> MCS lock/unlock functions in the contended case.
>
> From: Will Deacon
> Signed-off-by: Will Deacon
Reviewed-by: Paul E. McKenney
> ---
> arch/Kconfig | 3 +++
> include/linux/mcs_spinlock.h | 8
> 2 files changed, 11 insertions(+)
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 80bbb8c..8a2a056 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -303,6 +303,9 @@ config HAVE_CMPXCHG_LOCAL
> config HAVE_CMPXCHG_DOUBLE
> bool
>
> +config HAVE_ARCH_MCS_LOCK
> + bool
> +
> config ARCH_WANT_IPC_PARSE_VERSION
> bool
>
> diff --git a/include/linux/mcs_spinlock.h b/include/linux/mcs_spinlock.h
> index d54bb23..d2c02ad 100644
> --- a/include/linux/mcs_spinlock.h
> +++ b/include/linux/mcs_spinlock.h
> @@ -12,6 +12,14 @@
> #ifndef __LINUX_MCS_SPINLOCK_H
> #define __LINUX_MCS_SPINLOCK_H
>
> +/*
> + * An architecture may provide its own lock/unlock functions for the
> + * contended case.
> + */
> +#ifdef CONFIG_HAVE_ARCH_MCS_LOCK
> +#include
> +#endif
> +
> struct mcs_spinlock {
> struct mcs_spinlock *next;
> int locked; /* 1 if lock acquired */
> --
> 1.7.11.7
>
>
--
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 v7 4/6] MCS Lock: Barrier corrections
On Thu, Jan 16, 2014 at 04:08:28PM -0800, Tim Chen wrote: > This patch corrects the way memory barriers are used in the MCS lock > with smp_load_acquire and smp_store_release fucnction. > It removes ones that are not needed. > > Note that using the smp_load_acquire/smp_store_release pair is not > sufficient to form a full memory barrier across > cpus for many architectures (except x86) for mcs_unlock and mcs_lock. > For applications that absolutely need a full barrier across multiple cpus > with mcs_unlock and mcs_lock pair, smp_mb__after_unlock_lock() should be > used after mcs_lock if a full memory barrier needs to be guaranteed. > > From: Waiman Long > Suggested-by: Michel Lespinasse > Signed-off-by: Waiman Long > Signed-off-by: Jason Low > Signed-off-by: Tim Chen And this fixes my gripes in the first patch in this series, good! Reviewed-by: Paul E. McKenney > --- > kernel/locking/mcs_spinlock.c | 18 +- > 1 file changed, 13 insertions(+), 5 deletions(-) > > diff --git a/kernel/locking/mcs_spinlock.c b/kernel/locking/mcs_spinlock.c > index 44fb092..6cdc730 100644 > --- a/kernel/locking/mcs_spinlock.c > +++ b/kernel/locking/mcs_spinlock.c > @@ -43,9 +43,12 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct > mcs_spinlock *node) > return; > } > ACCESS_ONCE(prev->next) = node; > - smp_wmb(); > - /* Wait until the lock holder passes the lock down */ > - while (!ACCESS_ONCE(node->locked)) > + /* > + * Wait until the lock holder passes the lock down. > + * Using smp_load_acquire() provides a memory barrier that > + * ensures subsequent operations happen after the lock is acquired. > + */ > + while (!(smp_load_acquire(>locked))) > arch_mutex_cpu_relax(); > } > EXPORT_SYMBOL_GPL(mcs_spin_lock); > @@ -68,7 +71,12 @@ void mcs_spin_unlock(struct mcs_spinlock **lock, struct > mcs_spinlock *node) > while (!(next = ACCESS_ONCE(node->next))) > arch_mutex_cpu_relax(); > } > - ACCESS_ONCE(next->locked) = 1; > - smp_wmb(); > + /* > + * Pass lock to next waiter. > + * smp_store_release() provides a memory barrier to ensure > + * all operations in the critical section has been completed > + * before unlocking. > + */ > + smp_store_release(>locked, 1); > } > EXPORT_SYMBOL_GPL(mcs_spin_unlock); > -- > 1.7.11.7 > > > -- 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 v7 3/6] MCS Lock: Move mcs_lock/unlock function into its own file
On Thu, Jan 16, 2014 at 04:08:24PM -0800, Tim Chen wrote:
> The following changes are made:
>
> 1) Create a new mcs_spinlock.c file to contain the
>mcs_spin_lock() and mcs_spin_unlock() function.
> 2) Include a number of prerequisite header files and define
>arch_mutex_cpu_relax(), if not previously defined so the
>mcs functions can be compiled for multiple architecture without
>causing problems.
>
> From: Waiman Long
> Signed-off-by: Waiman Long
> Signed-off-by: Tim Chen
Reviewed-by: Paul E. McKenney
> ---
> include/linux/mcs_spinlock.h | 56
> ++
> kernel/locking/Makefile| 6 +--
> .../locking/mcs_spinlock.c | 33 ++---
> 3 files changed, 24 insertions(+), 71 deletions(-)
> copy include/linux/mcs_spinlock.h => kernel/locking/mcs_spinlock.c (75%)
>
> diff --git a/include/linux/mcs_spinlock.h b/include/linux/mcs_spinlock.h
> index 96f14299..d54bb23 100644
> --- a/include/linux/mcs_spinlock.h
> +++ b/include/linux/mcs_spinlock.h
> @@ -17,57 +17,9 @@ struct mcs_spinlock {
> int locked; /* 1 if lock acquired */
> };
>
> -/*
> - * In order to acquire the lock, the caller should declare a local node and
> - * pass a reference of the node to this function in addition to the lock.
> - * If the lock has already been acquired, then this will proceed to spin
> - * on this node->locked until the previous lock holder sets the node->locked
> - * in mcs_spin_unlock().
> - *
> - * We don't inline mcs_spin_lock() so that perf can correctly account for the
> - * time spent in this lock function.
> - */
> -static noinline
> -void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node)
> -{
> - struct mcs_spinlock *prev;
> -
> - /* Init node */
> - node->locked = 0;
> - node->next = NULL;
> -
> - prev = xchg(lock, node);
> - if (likely(prev == NULL)) {
> - /* Lock acquired */
> - return;
> - }
> - ACCESS_ONCE(prev->next) = node;
> - smp_wmb();
> - /* Wait until the lock holder passes the lock down */
> - while (!ACCESS_ONCE(node->locked))
> - arch_mutex_cpu_relax();
> -}
> -
> -/*
> - * Releases the lock. The caller should pass in the corresponding node that
> - * was used to acquire the lock.
> - */
> -static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock
> *node)
> -{
> - struct mcs_spinlock *next = ACCESS_ONCE(node->next);
> -
> - if (likely(!next)) {
> - /*
> - * Release the lock by setting it to NULL
> - */
> - if (likely(cmpxchg(lock, node, NULL) == node))
> - return;
> - /* Wait until the next pointer is set */
> - while (!(next = ACCESS_ONCE(node->next)))
> - arch_mutex_cpu_relax();
> - }
> - ACCESS_ONCE(next->locked) = 1;
> - smp_wmb();
> -}
> +extern
> +void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node);
> +extern
> +void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node);
>
> #endif /* __LINUX_MCS_SPINLOCK_H */
> diff --git a/kernel/locking/Makefile b/kernel/locking/Makefile
> index baab8e5..20d9d5c 100644
> --- a/kernel/locking/Makefile
> +++ b/kernel/locking/Makefile
> @@ -13,12 +13,12 @@ obj-$(CONFIG_LOCKDEP) += lockdep.o
> ifeq ($(CONFIG_PROC_FS),y)
> obj-$(CONFIG_LOCKDEP) += lockdep_proc.o
> endif
> -obj-$(CONFIG_SMP) += spinlock.o
> -obj-$(CONFIG_PROVE_LOCKING) += spinlock.o
> +obj-$(CONFIG_SMP) += spinlock.o mcs_spinlock.o
> +obj-$(CONFIG_PROVE_LOCKING) += spinlock.o mcs_spinlock.o
> obj-$(CONFIG_RT_MUTEXES) += rtmutex.o
> obj-$(CONFIG_DEBUG_RT_MUTEXES) += rtmutex-debug.o
> obj-$(CONFIG_RT_MUTEX_TESTER) += rtmutex-tester.o
> -obj-$(CONFIG_DEBUG_SPINLOCK) += spinlock.o
> +obj-$(CONFIG_DEBUG_SPINLOCK) += spinlock.o mcs_spinlock.o
> obj-$(CONFIG_DEBUG_SPINLOCK) += spinlock_debug.o
> obj-$(CONFIG_RWSEM_GENERIC_SPINLOCK) += rwsem-spinlock.o
> obj-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem-xadd.o
> diff --git a/include/linux/mcs_spinlock.h b/kernel/locking/mcs_spinlock.c
> similarity index 75%
> copy from include/linux/mcs_spinlock.h
> copy to kernel/locking/mcs_spinlock.c
> index 96f14299..44fb092 100644
> --- a/include/linux/mcs_spinlock.h
> +++ b/kernel/locking/mcs_spinlock.c
> @@ -1,7 +1,5 @@
> /*
> - * MCS lock defines
> - *
> - * This file contains the main data structure and API definitions of MCS
> lock.
> + * MCS lock
> *
> * The MCS lock (proposed by Mellor-Crummey and Scott) is a simple spin-lock
> * with the desirable properties of being fair, and with each cpu trying
> @@ -9,13 +7,20 @@
> * It avoids expensive cache bouncings that common test-and-set spin-lock
> * implementations incur.
> */
> -#ifndef __LINUX_MCS_SPINLOCK_H
> -#define __LINUX_MCS_SPINLOCK_H
> +/*
> + * asm/processor.h may define arch_mutex_cpu_relax().
> + * If it is not defined,
[Patch v1] ACPI, x86: fix bug in associating hot-added CPUs with corresponding NUMA node
Current ACPI cpu hotplug driver fails to associate hot-added CPUs with
corresponding NUMA node when doing socket online. The code path to
associate CPU with NUMA node is as below:
acpi_processor_add()
->acpi_processor_get_info()
->acpi_processor_hotadd_init()
->acpi_map_lsapic()
->_acpi_map_lsapic()
->acpi_map_cpu2node()
cpu_subsys_online()
->try_online_node()
->node_set_online()
When doing socket online, a new NUMA node is introduced in addition to
hot-added CPU and memory device. And the new NUMA node is marked as
online when onlining hot-added CPUs through sysfs interface
/sys/devices/system/cpu/cpuxx/online.
On the other hand, acpi_map_cpu2node() will only build the CPU to node
map if corresponding NUMA node is already online, so it always fails
to associate hot-added CPUs with corresponding NUMA node because the
NUMA node is still in offline state.
For the fix, we could safely remove the "node_online(node)" check in
function acpi_map_cpu2node() because it's only called for hot-added CPUs
by acpi_processor_hotadd_init().
Signed-off-by: Jiang Liu
---
arch/x86/kernel/acpi/boot.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 6c0b43b..7625de9 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -614,10 +614,10 @@ static void acpi_map_cpu2node(acpi_handle handle, int
cpu, int physid)
int nid;
nid = acpi_get_node(handle);
- if (nid == -1 || !node_online(nid))
- return;
- set_apicid_to_node(physid, nid);
- numa_set_node(cpu, nid);
+ if (nid != -1) {
+ set_apicid_to_node(physid, nid);
+ numa_set_node(cpu, nid);
+ }
#endif
}
--
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 v7 2/6] MCS Lock: optimizations and extra comments
On Thu, Jan 16, 2014 at 04:08:20PM -0800, Tim Chen wrote:
> Remove unnecessary operation and make the cmpxchg(lock, node, NULL) == node
> check in mcs_spin_unlock() likely() as it is likely that a race did not occur
> most of the time.
>
> Also add in more comments describing how the local node is used in MCS locks.
>
> From: Jason Low
> Reviewed-by: Tim Chen
> Signed-off-by: Jason Low
Reviewed-by: Paul E. McKenney
> ---
> include/linux/mcs_spinlock.h | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/mcs_spinlock.h b/include/linux/mcs_spinlock.h
> index b5de3b0..96f14299 100644
> --- a/include/linux/mcs_spinlock.h
> +++ b/include/linux/mcs_spinlock.h
> @@ -18,6 +18,12 @@ struct mcs_spinlock {
> };
>
> /*
> + * In order to acquire the lock, the caller should declare a local node and
> + * pass a reference of the node to this function in addition to the lock.
> + * If the lock has already been acquired, then this will proceed to spin
> + * on this node->locked until the previous lock holder sets the node->locked
> + * in mcs_spin_unlock().
> + *
> * We don't inline mcs_spin_lock() so that perf can correctly account for the
> * time spent in this lock function.
> */
> @@ -33,7 +39,6 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct
> mcs_spinlock *node)
> prev = xchg(lock, node);
> if (likely(prev == NULL)) {
> /* Lock acquired */
> - node->locked = 1;
> return;
> }
> ACCESS_ONCE(prev->next) = node;
> @@ -43,6 +48,10 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct
> mcs_spinlock *node)
> arch_mutex_cpu_relax();
> }
>
> +/*
> + * Releases the lock. The caller should pass in the corresponding node that
> + * was used to acquire the lock.
> + */
> static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock
> *node)
> {
> struct mcs_spinlock *next = ACCESS_ONCE(node->next);
> @@ -51,7 +60,7 @@ static void mcs_spin_unlock(struct mcs_spinlock **lock,
> struct mcs_spinlock *nod
> /*
>* Release the lock by setting it to NULL
>*/
> - if (cmpxchg(lock, node, NULL) == node)
> + if (likely(cmpxchg(lock, node, NULL) == node))
> return;
> /* Wait until the next pointer is set */
> while (!(next = ACCESS_ONCE(node->next)))
> --
> 1.7.11.7
>
>
>
--
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 v7 1/6] MCS Lock: Restructure the MCS lock defines and locking code into its own file
On Thu, Jan 16, 2014 at 04:08:16PM -0800, Tim Chen wrote:
> We will need the MCS lock code for doing optimistic spinning for rwsem
> and queue rwlock. Extracting the MCS code from mutex.c and put into
> its own file allow us to reuse this code easily.
>
> Signed-off-by: Tim Chen
> Signed-off-by: Davidlohr Bueso
>From the perspective of correctly moving incorrect code:
Reviewed-by: Paul E. McKenney
Gripes interspersed below. ;-)
> ---
> include/linux/mcs_spinlock.h | 64
>
> include/linux/mutex.h| 5 ++--
> kernel/locking/mutex.c | 60 +
> 3 files changed, 74 insertions(+), 55 deletions(-)
> create mode 100644 include/linux/mcs_spinlock.h
>
> diff --git a/include/linux/mcs_spinlock.h b/include/linux/mcs_spinlock.h
> new file mode 100644
> index 000..b5de3b0
> --- /dev/null
> +++ b/include/linux/mcs_spinlock.h
> @@ -0,0 +1,64 @@
> +/*
> + * MCS lock defines
> + *
> + * This file contains the main data structure and API definitions of MCS
> lock.
> + *
> + * The MCS lock (proposed by Mellor-Crummey and Scott) is a simple spin-lock
> + * with the desirable properties of being fair, and with each cpu trying
> + * to acquire the lock spinning on a local variable.
> + * It avoids expensive cache bouncings that common test-and-set spin-lock
> + * implementations incur.
> + */
> +#ifndef __LINUX_MCS_SPINLOCK_H
> +#define __LINUX_MCS_SPINLOCK_H
> +
> +struct mcs_spinlock {
> + struct mcs_spinlock *next;
> + int locked; /* 1 if lock acquired */
> +};
> +
> +/*
> + * We don't inline mcs_spin_lock() so that perf can correctly account for the
> + * time spent in this lock function.
> + */
> +static noinline
> +void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node)
> +{
> + struct mcs_spinlock *prev;
> +
> + /* Init node */
> + node->locked = 0;
> + node->next = NULL;
> +
> + prev = xchg(lock, node);
> + if (likely(prev == NULL)) {
> + /* Lock acquired */
> + node->locked = 1;
> + return;
> + }
> + ACCESS_ONCE(prev->next) = node;
> + smp_wmb();
The above memory barrier isn't doing anything useful -- there is a write
before it, but no writes after it.
> + /* Wait until the lock holder passes the lock down */
> + while (!ACCESS_ONCE(node->locked))
> + arch_mutex_cpu_relax();
Nothing I can see prevents critical-section loads from happening before
the above ACCESS_ONCE(), thus leaking them out of the critical section.
(Stores cannot be executed speculatively.)
> +}
> +
> +static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock
> *node)
> +{
> + struct mcs_spinlock *next = ACCESS_ONCE(node->next);
> +
> + if (likely(!next)) {
> + /*
> + * Release the lock by setting it to NULL
> + */
> + if (cmpxchg(lock, node, NULL) == node)
> + return;
> + /* Wait until the next pointer is set */
> + while (!(next = ACCESS_ONCE(node->next)))
> + arch_mutex_cpu_relax();
> + }
> + ACCESS_ONCE(next->locked) = 1;
> + smp_wmb();
This memory barrier is also not doing anything. Nothing prevents the
critical section from leaking out.
> +}
> +
> +#endif /* __LINUX_MCS_SPINLOCK_H */
> diff --git a/include/linux/mutex.h b/include/linux/mutex.h
> index d318193..c482e1d 100644
> --- a/include/linux/mutex.h
> +++ b/include/linux/mutex.h
> @@ -46,6 +46,7 @@
> * - detects multi-task circular deadlocks and prints out all affected
> * locks and tasks (and only those tasks)
> */
> +struct mcs_spinlock;
> struct mutex {
> /* 1: unlocked, 0: locked, negative: locked, possible waiters */
> atomic_tcount;
> @@ -55,7 +56,7 @@ struct mutex {
> struct task_struct *owner;
> #endif
> #ifdef CONFIG_MUTEX_SPIN_ON_OWNER
> - void*spin_mlock;/* Spinner MCS lock */
> + struct mcs_spinlock *mcs_lock; /* Spinner MCS lock */
> #endif
> #ifdef CONFIG_DEBUG_MUTEXES
> const char *name;
> @@ -179,4 +180,4 @@ extern int atomic_dec_and_mutex_lock(atomic_t *cnt,
> struct mutex *lock);
> # define arch_mutex_cpu_relax() cpu_relax()
> #endif
>
> -#endif
> +#endif /* __LINUX_MUTEX_H */
> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> index 4dd6e4c..45fe1b5 100644
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * In the DEBUG case we are using the "NULL fastpath" for mutexes,
> @@ -52,7 +53,7 @@ __mutex_init(struct mutex *lock, const char *name, struct
> lock_class_key *key)
> INIT_LIST_HEAD(>wait_list);
> mutex_clear_owner(lock);
> #ifdef CONFIG_MUTEX_SPIN_ON_OWNER
> - lock->spin_mlock = NULL;
> + lock->mcs_lock = NULL;
> #endif
>
>
Re: [PATCHSET 0/5] tracing/uprobes: Support multi buffer and event trigger
Hi Namhyung, On 2014/1/17 16:08, Namhyung Kim wrote: > Hello, > (Resending with LKML CC'ed) > > This patchset tries to add support for recent multi buffer and event > trigger changes to uprobes. The multi buffer support patch is an > updated version of Zovi's previous patch v6 [1]. > > Zovi, please tell me if you have any update and/or issues with this. > No more update on [Patch 3/5] from my side. Thank you for resending this patch! Jovi -- 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: Please confirm your message
On Tue, 2014-01-14 at 17:00 +0100, Gmane Remailer wrote: > This message was created automatically by mail delivery software (TMDA). > > Your message attached below is being held because the address > has not been verified. > > To release your message for delivery, please send an empty message > to the following address, or use your mailer's "Reply" feature. > > > public-linux-kernel-u79uwxl29ty76z2rm5mhxa-confirm-1389715205.8892.b9b...@plane.gmane.org > > This confirmation verifies that your message is legitimate and not > junk-mail. You should only have to confirm your address once. > > If you do not respond to this confirmation request within 14 days, > your message will not be delivered. -- 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] kvm: make KVM_MMU_AUDIT help text more readable
On 01/18/2014 10:02 AM, Randy Dunlap wrote: > From: Randy Dunlap > > Make KVM_MMU_AUDIT kconfig help text readable and collapse > two spaces between words down to one space. > Reviewed-by: Xiao Guangrong -- 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] backlight: Convert from Legacy pm ops to dev_pm_ops
On Monday, January 20, 2014 12:37 AM, Rafael J. Wysocki wrote:
> On Wednesday, November 14, 2040 04:27:17 AM Shuah Khan wrote:
> > Convert drivers/video/backlight/class to use dev_pm_ops for power
> > management and remove Legacy PM ops hooks. With this change, rtc class
> > registers suspend/resume callbacks via class->pm (dev_pm_ops) instead of
> > Legacy class->suspend/resume. When __device_suspend() runs call-backs,
> > it will find class->pm ops for the backlight class.
> >
> > Signed-off-by: Shuah Khan
> > Cc: Shuah Khan
>
> Can you please resend the patches that nobody took with CCs to
> linux...@vger.kernel.org? If the original maintainers don't care, I'll be
> able to pick those patches up then (if they look good).
I already gave the comment, and am waiting v3 patch.
However, Shuah Khan did not send the v3 patch yet.
Currently, backlight subsystem patches go through mm-tree
With my acked-by.
Shuah Khan,
Will you send the v3 patch? As I said, there is the typo in
commit message. Please fix it.
s/rtc class/backlight class
Best regards,
Jingoo Han
> > ---
> >
> > v2: Updated changelog to correct device class.
> >
> > drivers/video/backlight/backlight.c |8 +---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/video/backlight/backlight.c
> > b/drivers/video/backlight/backlight.c
> > index c74e7aa..0ffb251 100644
> > --- a/drivers/video/backlight/backlight.c
> > +++ b/drivers/video/backlight/backlight.c
> > @@ -208,7 +208,7 @@ static ssize_t backlight_show_actual_brightness(struct
> > device *dev,
> >
> > static struct class *backlight_class;
> >
> > -static int backlight_suspend(struct device *dev, pm_message_t state)
> > +static int backlight_suspend(struct device *dev)
> > {
> > struct backlight_device *bd = to_backlight_device(dev);
> >
> > @@ -236,6 +236,9 @@ static int backlight_resume(struct device *dev)
> > return 0;
> > }
> >
> > +static SIMPLE_DEV_PM_OPS(backlight_class_dev_pm_ops, backlight_suspend,
> > +backlight_resume);
> > +
> > static void bl_device_release(struct device *dev)
> > {
> > struct backlight_device *bd = to_backlight_device(dev);
> > @@ -414,8 +417,7 @@ static int __init backlight_class_init(void)
> > }
> >
> > backlight_class->dev_attrs = bl_device_attributes;
> > - backlight_class->suspend = backlight_suspend;
> > - backlight_class->resume = backlight_resume;
> > + backlight_class->pm = _class_dev_pm_ops;
> > return 0;
> > }
> >
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: export simple_dname for drm drivers.
On Mon, Jan 20, 2014 at 10:54:44AM +1000, Dave Airlie wrote:
> David Herrmann's changes to use a pseudo filesystem for drm's shared
> inodes requires this be exported for drm to build as a module.
>
> I'd like to merge this via the drm tree, so please ack.
Having looked through these patches... The problem is that you'll get
your module impossible to unload. Sane solution:
static struct vfsmount *drm_mnt;
static int count;
struct inode *drm_alloc_inode(void)
{
struct inode *res;
int err = simple_pin_fs(_fs, _mnt, );
if (err)
return ERR_PTR(err);
res = alloc_anon_inode(drm_mnt->mnt_sb);
if (IS_ERR(res))
simple_release_fs(_mnt, );
return res;
}
/* call from drm_free_dev() */
void drm_put_anon_inode(struct drm_device *dev)
{
iput(dev->anon_inode);
simple_release_fs(_mnt, );
}
and lose those kern_mount/kern_umount.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the tip tree
On 01/19/2014 05:00 PM, Len Brown wrote:
> On Wed, Jan 15, 2014 at 10:58 PM, Stephen Rothwell
> wrote:
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>> failed like this:
>>
>> arch/x86/kernel/process.c: In function 'mwait_idle':
>> /scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit
>> declaration of function '__monitor' [-Werror=implicit-function-declaration]
>>__monitor((void *)_thread_info()->flags, 0, 0);
>>^
>> arch/x86/kernel/process.c:437:4: error: implicit declaration of function
>> '__sti_mwait' [-Werror=implicit-function-declaration]
>> __sti_mwait(0, 0);
>> ^
>>
>> Caused by commit 16824255394f ("x86, acpi, idle: Restructure the mwait
>> idle routines") interacting with commit 7760518cce95 ("x86 idle: restore
>> mwait_idle()") from the idle tree.
>>
>> I am not sure how to fix this so I just reverted the idle tree commit for
>> now (since it reverted cleanly). Please let me know if there is a better
>> solution.
>
> IMO, a regression fix (restore mwait_idle()) is more important than a clean up
> (restructure mwait routines), and the clean-up should take a back seat;
> in -tip, in -next, upstream, and in -stable.
>
> Also, I'm wondering if that clean-up went too far -- as not all users of mwait
> are necessarily under the same conditions...
>
Sounds like a NAK to me, in which case that bit should probably be
deferred and reintroduced after fixing via the idle tree?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the tip tree
On Wed, Jan 15, 2014 at 10:58 PM, Stephen Rothwell
wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> arch/x86/kernel/process.c: In function 'mwait_idle':
> /scratch/sfr/next/arch/x86/kernel/process.c:434:3: error: implicit
> declaration of function '__monitor' [-Werror=implicit-function-declaration]
>__monitor((void *)_thread_info()->flags, 0, 0);
>^
> arch/x86/kernel/process.c:437:4: error: implicit declaration of function
> '__sti_mwait' [-Werror=implicit-function-declaration]
> __sti_mwait(0, 0);
> ^
>
> Caused by commit 16824255394f ("x86, acpi, idle: Restructure the mwait
> idle routines") interacting with commit 7760518cce95 ("x86 idle: restore
> mwait_idle()") from the idle tree.
>
> I am not sure how to fix this so I just reverted the idle tree commit for
> now (since it reverted cleanly). Please let me know if there is a better
> solution.
IMO, a regression fix (restore mwait_idle()) is more important than a clean up
(restructure mwait routines), and the clean-up should take a back seat;
in -tip, in -next, upstream, and in -stable.
Also, I'm wondering if that clean-up went too far -- as not all users of mwait
are necessarily under the same conditions...
thanks,
Len Brown, Intel Open Source Technology Center
--
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: export simple_dname for drm drivers.
David Herrmann's changes to use a pseudo filesystem for drm's shared inodes requires this be exported for drm to build as a module. I'd like to merge this via the drm tree, so please ack. Signed-off-by: Dave Airlie --- fs/dcache.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/dcache.c b/fs/dcache.c index 6055d61..27d66b8 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -3107,6 +3107,7 @@ char *simple_dname(struct dentry *dentry, char *buffer, int buflen) end = ERR_PTR(-ENAMETOOLONG); return end; } +EXPORT_SYMBOL(simple_dname); /* * Write full pathname from the root of the filesystem into the buffer. -- 1.8.4.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: [PATCH v8 4/4] qrwlock: Use smp_store_release() in write_unlock()
On Sun, Jan 19, 2014 at 11:56:02AM -0800, Linus Torvalds wrote:
> On Sun, Jan 19, 2014 at 12:04 AM, Paul E. McKenney
> wrote:
> >
> > OK, another approach would be to never add "select ARCH_USE_QUEUE_RWLOCK"
> > on Alpha, at least if the queued rwlocks really do want to atomically
> > manipulate bytes. After all, the Alpha systems that I know about don't
> > have enough CPUs to make queued rwlocks necessary anyway.
> >
> > Much simpler solution!
> >
> > Is this what you were getting at, or am I missing your point?
>
> You're missing something.
>
> Just make the "writer" field be an "int" on little-endian archiectures
> (like alpha).
>
> There is no reason for that field to be a "char" to begin with, as far
> as I can tell, since the padding of the structure means that it
> doesn't save any space. But even if that wasn't true, we could make an
> arch-specific type for "minimum type for locking".
On 64-bit systems (which includes Alpha), agreed, the field can be a
32-bit portion of a 64-bit structure that is then manipulated atomically.
Many 32-bit systems need the reader and writer counts to fix in 32 bits
in order to allow things like queue_read_trylock() to correctly account
for both readers and writers.
If there was a 32-bit system running Linux that did not support byte
accesses, there would be a problem, but I don't know of any such system.
> So my *point* was that it should be easy enough to just make sure that
> any data structures used for locking have types that are appropriate
> for that locking.
So something like the following for the qrwlock definition, with
appropriate C-preprocessor wrappers for the atomic-add accesses?
Thanx, Paul
typedef struct qrwlock {
union qrwcnts {
#ifdef CONFIG_64B
struct (
int writer;
int reader;
};
atomic_long_t rwa;
u64 rwc;
#else
struct {
#ifdef __LITTLE_ENDIAN
u8 writer; /* Writer state */
#else
u16 r16;/* Reader count - msb */
u8 r8; /* Reader count - lsb */
u8 writer; /* Writer state */
#endif
};
atomic_trwa;/* Reader/writer atomic */
u32 rwc;/* Reader/writer counts */
} cnts;
#endif
struct mcs_spinlock *waitq; /* Tail of waiting queue */
} arch_rwlock_t;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ping [PATCH v3] WAN: Adding support for Lantiq PEF2256 E1 chipset (FALC56)
On 01/19/14 13:34, Joe Perches wrote:
On Sun, 2014-01-19 at 19:07 +0100, Christophe Leroy wrote:
Pinging this watch as we got no feedback since 22 Nov, although we have taken
into account reviews from v1 and v2.
The patch adds WAN support for Lantiq FALC56 - PEF2256 E1 Chipset.
...
+static ssize_t fs_attr_Tx_TS_store(struct device *dev,
+ struct device_attribute *attr, const char *buf,
+ size_t count)
+{
+ struct net_device *ndev = dev_get_drvdata(dev);
+ struct pef2256_dev_priv *priv = dev_to_hdlc(ndev)->priv;
+ unsigned long value;
+ int ret = kstrtoul(buf, 16, (long int *));
unportable cast
How is that not portable? It's long == pointer on Linux, which supports
LP64 on all targets. (As do BSD, MacOSX, android, and iOS.)
http://www.unix.org/whitepapers/64bit.html
http://www.unix.org/version2/whatsnew/lp64_wp.html
Do you mean it's not portable to Windows?
http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx
Rob
--
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] at drivers/md/raid5.c:291! kernel 3.13-rc8
On mån, 2014-01-20 at 11:38 +1100, NeilBrown wrote: > On Sun, 19 Jan 2014 23:00:23 +0100 Ian Kumlien wrote: > > > Ok, so third try to actually email this... > > --- > > > > Hi, > > > > I started testing 3.13-rc8 on another machine since the first one seemed > > to be working fine... > > > > One spontaneous reboot later i'm not so sure ;) > > > > Right now i captured a kernel oops in the raid code it seems... > > > > (Also attached to avoid mangling) > > > > [33411.934672] [ cut here ] > > [33411.934685] kernel BUG at drivers/md/raid5.c:291! > > [33411.934690] invalid opcode: [#1] PREEMPT SMP > > [33411.934696] Modules linked in: bonding btrfs microcode > > [33411.934705] CPU: 4 PID: 2319 Comm: md2_raid6 Not tainted 3.13.0-rc8 #83 > > [33411.934709] Hardware name: System manufacturer System Product > > Name/Crosshair IV Formula, BIOS 302910/09/2012 > > [33411.934716] task: 880326265880 ti: 880320472000 task.ti: > > 880320472000 > > [33411.934720] RIP: 0010:[] [] > > do_release_stripe+0x18e/0x1a0 > > [33411.934731] RSP: 0018:880320473d28 EFLAGS: 00010087 > > [33411.934735] RAX: 8802f0875a60 RBX: 0001 RCX: > > 8800b0d816b0 > > [33411.934739] RDX: 88032498 RSI: 8802f0875a40 RDI: > > 880324eeec00 > > [33411.934743] RBP: 8802f0875a50 R08: R09: > > 0001 > > [33411.934747] R10: R11: R12: > > 880324eeec00 > > [33411.934752] R13: 88032458 R14: 880320473e88 R15: > > > > [33411.934756] FS: 7fc38654d700() GS:880337d0() > > knlGS: > > [33411.934761] CS: 0010 DS: ES: CR0: 8005003b > > [33411.934765] CR2: 7f0cb28bd000 CR3: 0002ebcf6000 CR4: > > 000407e0 > > [33411.934769] Stack: > > [33411.934771] 8800bba09690 8800b4f16588 880303005a40 > > 0001 > > [33411.934779] 8800b33e43d0 81a3a62d 88032458 > > > > [33411.934786] 88032458 880326660670 880326265880 > > 81a41692 > > [33411.934794] Call Trace: > > [33411.934798] [] ? release_stripe_list+0x4d/0x70 > > [33411.934803] [] ? raid5d+0xa2/0x4d0 > > [33411.934808] [] ? md_thread+0xe6/0x120 > > [33411.934814] [] ? finish_wait+0x90/0x90 > > [33411.934818] [] ? md_rdev_init+0x100/0x100 > > [33411.934823] [] ? kthread+0xbc/0xe0 > > [33411.934828] [] ? smpboot_park_threads+0x70/0x70Hi, > > Thanks for the report. > Can you provide any more context about the details of the array in question? > I see it was RAID6. Was it degraded? Was it resyncing? Was it being > reshaped? > Was there any way that it was different from the array one the machine where > it seemed to work? Yes, it's a raid6 and no, there is no reshaping or syncing going on... Basically everything worked fine before: reboot system boot 3.13.0-rc8 Sun Jan 19 21:47 - 01:42 (03:55) reboot system boot 3.13.0-rc8 Sun Jan 19 21:38 - 01:42 (04:04) reboot system boot 3.13.0-rc8 Sun Jan 19 12:13 - 01:42 (13:29) reboot system boot 3.13.0-rc8 Sat Jan 18 21:23 - 01:42 (1+04:19) reboot system boot 3.12.6 Mon Dec 30 16:27 - 22:21 (19+05:53) As in, no problems before the 3.13.0-rc8 upgrade... cat /proc/mdstat: Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] md2 : active raid6 sdf1[2] sdd1[9] sdj1[8] sdg1[4] sde1[5] sdi1[11] sdc1[0] sdh1[10] 11721074304 blocks super 1.2 level 6, 64k chunk, algorithm 2 [8/8] [] bitmap: 0/15 pages [0KB], 65536KB chunk What i do do is: echo 32768 > /sys/block/*/md/stripe_cache_size Which has caused no problems during intense write operations before... I find it quite surprising since it only requires ~3 gigabytes of writes to die and almost assume that it's related to the stripe_cache_size. (Since all memory is ECC and i doubt it would break, quite literally, over night i haven't run extensive memory tests) I don't quite know what other information you might need... > Thanks, > NeilBrown -- 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] at drivers/md/raid5.c:291! kernel 3.13-rc8
On Sun, 19 Jan 2014 23:00:23 +0100 Ian Kumlien wrote: > Ok, so third try to actually email this... > --- > > Hi, > > I started testing 3.13-rc8 on another machine since the first one seemed > to be working fine... > > One spontaneous reboot later i'm not so sure ;) > > Right now i captured a kernel oops in the raid code it seems... > > (Also attached to avoid mangling) > > [33411.934672] [ cut here ] > [33411.934685] kernel BUG at drivers/md/raid5.c:291! > [33411.934690] invalid opcode: [#1] PREEMPT SMP > [33411.934696] Modules linked in: bonding btrfs microcode > [33411.934705] CPU: 4 PID: 2319 Comm: md2_raid6 Not tainted 3.13.0-rc8 #83 > [33411.934709] Hardware name: System manufacturer System Product > Name/Crosshair IV Formula, BIOS 302910/09/2012 > [33411.934716] task: 880326265880 ti: 880320472000 task.ti: > 880320472000 > [33411.934720] RIP: 0010:[] [] > do_release_stripe+0x18e/0x1a0 > [33411.934731] RSP: 0018:880320473d28 EFLAGS: 00010087 > [33411.934735] RAX: 8802f0875a60 RBX: 0001 RCX: > 8800b0d816b0 > [33411.934739] RDX: 88032498 RSI: 8802f0875a40 RDI: > 880324eeec00 > [33411.934743] RBP: 8802f0875a50 R08: R09: > 0001 > [33411.934747] R10: R11: R12: > 880324eeec00 > [33411.934752] R13: 88032458 R14: 880320473e88 R15: > > [33411.934756] FS: 7fc38654d700() GS:880337d0() > knlGS: > [33411.934761] CS: 0010 DS: ES: CR0: 8005003b > [33411.934765] CR2: 7f0cb28bd000 CR3: 0002ebcf6000 CR4: > 000407e0 > [33411.934769] Stack: > [33411.934771] 8800bba09690 8800b4f16588 880303005a40 > 0001 > [33411.934779] 8800b33e43d0 81a3a62d 88032458 > > [33411.934786] 88032458 880326660670 880326265880 > 81a41692 > [33411.934794] Call Trace: > [33411.934798] [] ? release_stripe_list+0x4d/0x70 > [33411.934803] [] ? raid5d+0xa2/0x4d0 > [33411.934808] [] ? md_thread+0xe6/0x120 > [33411.934814] [] ? finish_wait+0x90/0x90 > [33411.934818] [] ? md_rdev_init+0x100/0x100 > [33411.934823] [] ? kthread+0xbc/0xe0 > [33411.934828] [] ? smpboot_park_threads+0x70/0x70Hi, Thanks for the report. Can you provide any more context about the details of the array in question? I see it was RAID6. Was it degraded? Was it resyncing? Was it being reshaped? Was there any way that it was different from the array one the machine where it seemed to work? Thanks, NeilBrown signature.asc Description: PGP signature
RE: [PATCH v2] Adding hyperv.h to uapi headers
> -Original Message-
> From: gurlige...@gmail.com [mailto:gurlige...@gmail.com] On Behalf Of Bjarke
> Istrup Pedersen
> Sent: Sunday, January 19, 2014 11:46 AM
> To: KY Srinivasan
> Cc: Linux Kernel Mailing List; Haiyang Zhang
> Subject: Re: [PATCH v2] Adding hyperv.h to uapi headers
>
> 2014/1/19 KY Srinivasan :
> >
> >
> >> -Original Message-
> >> From: gurlige...@gmail.com [mailto:gurlige...@gmail.com] On Behalf Of
> Bjarke
> >> Istrup Pedersen
> >> Sent: Sunday, January 19, 2014 2:15 AM
> >> To: KY Srinivasan
> >> Cc: Linux Kernel Mailing List; Haiyang Zhang
> >> Subject: Re: [PATCH v2] Adding hyperv.h to uapi headers
> >>
> >> 2014/1/19 KY Srinivasan :
> >> >
> >> >
> >> >> -Original Message-
> >> >> From: gurlige...@gmail.com [mailto:gurlige...@gmail.com] On Behalf Of
> >> Bjarke
> >> >> Istrup Pedersen
> >> >> Sent: Saturday, January 18, 2014 4:23 PM
> >> >> To: Linux Kernel Mailing List
> >> >> Cc: Haiyang Zhang; KY Srinivasan; Bjarke Istrup Pedersen
> >> >> Subject: Re: [PATCH v2] Adding hyperv.h to uapi headers
> >> >>
> >> >> Could any of you Hyper-V developers take a look at this, and see if
> >> >> this split makes sense to you?
> >> >
> >> > Have you compiled the hyper-v drivers with your change. I briefly looked
> >> > at
> >> your
> >> > latest patch but I did not see an include of the user level hyper-V
> >> > driver in
> the
> >> kernel
> >> > version of the header; or did I miss it. Please compile the drivers and
> >> > the
> >> tools/hv/
> >> > user level daemons to test your patch.
> >>
> >> Hey,
> >>
> >> I have compiled it, and both the drivers and the userspace deamons
> >> builds fine :)
> >> If you look at the patch, on line 134, it includes the uapi header.
> >>
> >> Also, which parts of the uapi version header would you like me to move
> >> to the kernel version? (I'll create a new patch then, with your
> >> suggestions)
> >
> > Which version information are you referring to. I would keep all version
> information
> > in the uapi hyperv.h header file. The kernel needs to handle older versions
> > of
> the daemons.
>
> Sorry, I think I worded it wrong :)
> What I meant is, is the split done in this patch fine with you, or
> should I move more/less to the UAPI header file?
I think this is fine. You want to send these patches to Greg KH
K. Y
>
> http://marc.info/?l=linux-kernel=139008735529658=2
>
> /Bjarke
>
> > Regards,
> >
> > K. Y
> >>
> >> /Bjarke
> >>
> >> > K. Y
> >> >>
> >> >> Thanks :)
> >> >>
> >> >> /Bjarke
> >> >>
> >> >> 2014/1/19 Bjarke Istrup Pedersen :
> >> >> > This patch adds the hyperv.h header to the uapi folder, and adds it
> >> >> > to the
> >> Kbuild
> >> >> file.
> >> >> > Doing this enables compiling userspace Hyper-V tools using the
> >> >> > installed
> >> >> headers.
> >> >> >
> >> >> > Version 2: Split UAPI parts into new header, instead of duplicating.
> >> >> >
> >> >> > Signed-off-by: Bjarke Istrup Pedersen
> >> >> > ---
> >> >> > include/linux/hyperv.h | 321
> >> >> > +
> >> >> > include/uapi/linux/Kbuild | 1 +
> >> >> > include/uapi/linux/hyperv.h | 344
> >> >>
> >> >> > 3 files changed, 347 insertions(+), 319 deletions(-)
> >> >> > create mode 100644 include/uapi/linux/hyperv.h
> >> >> >
> >> >> > diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
> >> >> > index 15da677..167ef47 100644
> >> >> > --- a/include/linux/hyperv.h
> >> >> > +++ b/include/linux/hyperv.h
> >> >> > @@ -25,325 +25,9 @@
> >> >> > #ifndef _HYPERV_H
> >> >> > #define _HYPERV_H
> >> >> >
> >> >> > -#include
> >> >> > -
> >> >> > -/*
> >> >> > - * Framework version for util services.
> >> >> > - */
> >> >> > -#define UTIL_FW_MINOR 0
> >> >> > -
> >> >> > -#define UTIL_WS2K8_FW_MAJOR 1
> >> >> > -#define UTIL_WS2K8_FW_VERSION (UTIL_WS2K8_FW_MAJOR << 16
> |
> >> >> UTIL_FW_MINOR)
> >> >> > -
> >> >> > -#define UTIL_FW_MAJOR 3
> >> >> > -#define UTIL_FW_VERSION (UTIL_FW_MAJOR << 16 |
> UTIL_FW_MINOR)
> >> >> > -
> >> >> > -
> >> >> > -/*
> >> >> > - * Implementation of host controlled snapshot of the guest.
> >> >> > - */
> >> >> > -
> >> >> > -#define VSS_OP_REGISTER 128
> >> >> > -
> >> >> > -enum hv_vss_op {
> >> >> > - VSS_OP_CREATE = 0,
> >> >> > - VSS_OP_DELETE,
> >> >> > - VSS_OP_HOT_BACKUP,
> >> >> > - VSS_OP_GET_DM_INFO,
> >> >> > - VSS_OP_BU_COMPLETE,
> >> >> > - /*
> >> >> > -* Following operations are only supported with IC version >=
> >> >> > 5.0
> >> >> > -*/
> >> >> > - VSS_OP_FREEZE, /* Freeze the file systems in the VM */
> >> >> > - VSS_OP_THAW, /* Unfreeze the file systems */
> >> >> > - VSS_OP_AUTO_RECOVER,
> >> >> > - VSS_OP_COUNT /* Number of operations, must be last */
> >> >> > -};
> >> >> > -
> >> >> > -
> >> >> > -/*
> >> >> > - * Header for all VSS messages.
> >> >> > - */
> >> >> > -struct hv_vss_hdr {
> >> >>
Re: [Resend][GIT PULL] Last minute ACPI fix for v3.13
Hi Linus, On Saturday, January 18, 2014 02:31:00 PM Rafael J. Wysocki wrote: > Hi Linus, > > The original revert commit was missing the Fixes: and Reported-by: tags, so if > you haven't pulled it yet, here it goes again with those tags added. > > Please pull from the git repository at > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git > acpi-3.13-fixup > > to receive a last-minute ACPI fix for 3.13 as commit > 2b844ba79f4a114bd228ad6fee040ffd99a0963d > > Revert "ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs" > > on top of commit 7e22e91102c6b9df7c4ae2168910e19d2bb14cd6 > > Linux 3.13-rc8 > > This reverts a commit that causes the Alan Cox' ASUS T100TA to "crash and > burn" during boot if the Baytrail pinctrl driver is compiled in. Well, that will be a regression in 3.13 if we don't revert this commit, but you apparently don't like the revert. :-) Please let me know if you want me to add the revert to the 3.14-rc1 pull request or just wait with it for the time being. Rafael -- 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/
Apply For A 2% Loan Today
Apply for a loan today at low interest rate for more info fill the form below Full Name: Amount to borrow Duration: Purpose : Country of Residence: Mobile No: -- 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-next: build warning after merge of the arm-soc tree
Hi all,
After merging the arm-soc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/pinctrl/pinconf.c: In function 'pinconf_pins_show':
drivers/pinctrl/pinconf.c:299:28: warning: unused variable 'ops'
[-Wunused-variable]
const struct pinconf_ops *ops = pctldev->desc->confops;
^
drivers/pinctrl/pinconf.c: In function 'pinconf_groups_show':
drivers/pinctrl/pinconf.c:346:28: warning: unused variable 'ops'
[-Wunused-variable]
const struct pinconf_ops *ops = pctldev->desc->confops;
^
Introduced by commit c420619d5177 ("pinctrl: pinconf: remove checks on
ops->pin_config_get").
Sorry, that I did not notice this earlier.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpdwEz2g1Tw7.pgp
Description: PGP signature
Contract Agreement Breach
Dear Attorney, We are a Production, publishing and marketing company in Japan. We have a breach of intellectual property agreement matter in your jurisdiction, we can forward you the agreement and other party information for your review to enable you run a conflict check. Yours Sincerely, Yoshiko Tomoko Manager Shinchosha Publishing Co., Ltd. 71 Yaraicho, Shinjuku-ku, Tokyo 162-8711, Japan Tel: +81333716411 -- 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] at drivers/md/raid5.c:291! kernel 3.13-rc8
On Sun, Jan 19, 2014 at 11:00 PM, Ian Kumlien wrote: > Ok, so third try to actually email this... Let's CC Neil too. > --- > > Hi, > > I started testing 3.13-rc8 on another machine since the first one seemed > to be working fine... > > One spontaneous reboot later i'm not so sure ;) > > Right now i captured a kernel oops in the raid code it seems... > > (Also attached to avoid mangling) > > [33411.934672] [ cut here ] > [33411.934685] kernel BUG at drivers/md/raid5.c:291! > [33411.934690] invalid opcode: [#1] PREEMPT SMP > [33411.934696] Modules linked in: bonding btrfs microcode > [33411.934705] CPU: 4 PID: 2319 Comm: md2_raid6 Not tainted 3.13.0-rc8 #83 > [33411.934709] Hardware name: System manufacturer System Product > Name/Crosshair IV Formula, BIOS 302910/09/2012 > [33411.934716] task: 880326265880 ti: 880320472000 task.ti: > 880320472000 > [33411.934720] RIP: 0010:[] [] > do_release_stripe+0x18e/0x1a0 > [33411.934731] RSP: 0018:880320473d28 EFLAGS: 00010087 > [33411.934735] RAX: 8802f0875a60 RBX: 0001 RCX: > 8800b0d816b0 > [33411.934739] RDX: 88032498 RSI: 8802f0875a40 RDI: > 880324eeec00 > [33411.934743] RBP: 8802f0875a50 R08: R09: > 0001 > [33411.934747] R10: R11: R12: > 880324eeec00 > [33411.934752] R13: 88032458 R14: 880320473e88 R15: > > [33411.934756] FS: 7fc38654d700() GS:880337d0() > knlGS: > [33411.934761] CS: 0010 DS: ES: CR0: 8005003b > [33411.934765] CR2: 7f0cb28bd000 CR3: 0002ebcf6000 CR4: > 000407e0 > [33411.934769] Stack: > [33411.934771] 8800bba09690 8800b4f16588 880303005a40 > 0001 > [33411.934779] 8800b33e43d0 81a3a62d 88032458 > > [33411.934786] 88032458 880326660670 880326265880 > 81a41692 > [33411.934794] Call Trace: > [33411.934798] [] ? release_stripe_list+0x4d/0x70 > [33411.934803] [] ? raid5d+0xa2/0x4d0 > [33411.934808] [] ? md_thread+0xe6/0x120 > [33411.934814] [] ? finish_wait+0x90/0x90 > [33411.934818] [] ? md_rdev_init+0x100/0x100 > [33411.934823] [] ? kthread+0xbc/0xe0 > [33411.934828] [] ? smpboot_park_threads+0x70/0x70Hi, > > I started testing 3.13-rc8 on another machine since the first one seemed to > be working fine... > > One spontaneous reboot later i'm not so sure ;) > > Right now i captured a kernel oops in the raid code it seems... > > (Also attached to avoid mangling) > > [33411.934672] [ cut here ] > [33411.934685] kernel BUG at drivers/md/raid5.c:291! > [33411.934690] invalid opcode: [#1] PREEMPT SMP > [33411.934696] Modules linked in: bonding btrfs microcode > [33411.934705] CPU: 4 PID: 2319 Comm: md2_raid6 Not tainted 3.13.0-rc8 #83 > [33411.934709] Hardware name: System manufacturer System Product > Name/Crosshair IV Formula, BIOS 302910/09/2012 > [33411.934716] task: 880326265880 ti: 880320472000 task.ti: > 880320472000 > [33411.934720] RIP: 0010:[] [] > do_release_stripe+0x18e/0x1a0 > [33411.934731] RSP: 0018:880320473d28 EFLAGS: 00010087 > [33411.934735] RAX: 8802f0875a60 RBX: 0001 RCX: > 8800b0d816b0 > [33411.934739] RDX: 88032498 RSI: 8802f0875a40 RDI: > 880324eeec00 > [33411.934743] RBP: 8802f0875a50 R08: R09: > 0001 > [33411.934747] R10: R11: R12: > 880324eeec00 > [33411.934752] R13: 88032458 R14: 880320473e88 R15: > > [33411.934756] FS: 7fc38654d700() GS:880337d0() > knlGS: > [33411.934761] CS: 0010 DS: ES: CR0: 8005003b > [33411.934765] CR2: 7f0cb28bd000 CR3: 0002ebcf6000 CR4: > 000407e0 > [33411.934769] Stack: > [33411.934771] 8800bba09690 8800b4f16588 880303005a40 > 0001 > [33411.934779] 8800b33e43d0 81a3a62d 88032458 > > [33411.934786] 88032458 880326660670 880326265880 > 81a41692 > [33411.934794] Call Trace: > [33411.934798] [] ? release_stripe_list+0x4d/0x70 > [33411.934803] [] ? raid5d+0xa2/0x4d0 > [33411.934808] [] ? md_thread+0xe6/0x120 > [33411.934814] [] ? finish_wait+0x90/0x90 > [33411.934818] [] ? md_rdev_init+0x100/0x100 > [33411.934823] [] ? kthread+0xbc/0xe0 > [33411.934828] [] ? smpboot_park_threads+0x70/0x70 > [33411.934833] [] ? flush_kthread_worker+0x80/0x80 > [33411.934839] [] ? ret_from_fork+0x7c/0xb0 > [33411.934843] [] ? flush_kthread_worker+0x80/0x80 > [33411.934847] Code: f7 ff ff 66 90 48 8b 43 18 48 8b b8 48 01 00 00 48 89 14 > 24 48 89 74 24 08 e8 af 9a 02 00 48 8b 74 24 08 48 8b 14 24 eb 9f 0f 0b <0f> > 0b 0f 0b 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 f0 ff 4e > [33411.934912] RIP []
[BUG] at drivers/md/raid5.c:291! kernel 3.13-rc8
Ok, so third try to actually email this... --- Hi, I started testing 3.13-rc8 on another machine since the first one seemed to be working fine... One spontaneous reboot later i'm not so sure ;) Right now i captured a kernel oops in the raid code it seems... (Also attached to avoid mangling) [33411.934672] [ cut here ] [33411.934685] kernel BUG at drivers/md/raid5.c:291! [33411.934690] invalid opcode: [#1] PREEMPT SMP [33411.934696] Modules linked in: bonding btrfs microcode [33411.934705] CPU: 4 PID: 2319 Comm: md2_raid6 Not tainted 3.13.0-rc8 #83 [33411.934709] Hardware name: System manufacturer System Product Name/Crosshair IV Formula, BIOS 302910/09/2012 [33411.934716] task: 880326265880 ti: 880320472000 task.ti: 880320472000 [33411.934720] RIP: 0010:[] [] do_release_stripe+0x18e/0x1a0 [33411.934731] RSP: 0018:880320473d28 EFLAGS: 00010087 [33411.934735] RAX: 8802f0875a60 RBX: 0001 RCX: 8800b0d816b0 [33411.934739] RDX: 88032498 RSI: 8802f0875a40 RDI: 880324eeec00 [33411.934743] RBP: 8802f0875a50 R08: R09: 0001 [33411.934747] R10: R11: R12: 880324eeec00 [33411.934752] R13: 88032458 R14: 880320473e88 R15: [33411.934756] FS: 7fc38654d700() GS:880337d0() knlGS: [33411.934761] CS: 0010 DS: ES: CR0: 8005003b [33411.934765] CR2: 7f0cb28bd000 CR3: 0002ebcf6000 CR4: 000407e0 [33411.934769] Stack: [33411.934771] 8800bba09690 8800b4f16588 880303005a40 0001 [33411.934779] 8800b33e43d0 81a3a62d 88032458 [33411.934786] 88032458 880326660670 880326265880 81a41692 [33411.934794] Call Trace: [33411.934798] [] ? release_stripe_list+0x4d/0x70 [33411.934803] [] ? raid5d+0xa2/0x4d0 [33411.934808] [] ? md_thread+0xe6/0x120 [33411.934814] [] ? finish_wait+0x90/0x90 [33411.934818] [] ? md_rdev_init+0x100/0x100 [33411.934823] [] ? kthread+0xbc/0xe0 [33411.934828] [] ? smpboot_park_threads+0x70/0x70Hi, I started testing 3.13-rc8 on another machine since the first one seemed to be working fine... One spontaneous reboot later i'm not so sure ;) Right now i captured a kernel oops in the raid code it seems... (Also attached to avoid mangling) [33411.934672] [ cut here ] [33411.934685] kernel BUG at drivers/md/raid5.c:291! [33411.934690] invalid opcode: [#1] PREEMPT SMP [33411.934696] Modules linked in: bonding btrfs microcode [33411.934705] CPU: 4 PID: 2319 Comm: md2_raid6 Not tainted 3.13.0-rc8 #83 [33411.934709] Hardware name: System manufacturer System Product Name/Crosshair IV Formula, BIOS 302910/09/2012 [33411.934716] task: 880326265880 ti: 880320472000 task.ti: 880320472000 [33411.934720] RIP: 0010:[] [] do_release_stripe+0x18e/0x1a0 [33411.934731] RSP: 0018:880320473d28 EFLAGS: 00010087 [33411.934735] RAX: 8802f0875a60 RBX: 0001 RCX: 8800b0d816b0 [33411.934739] RDX: 88032498 RSI: 8802f0875a40 RDI: 880324eeec00 [33411.934743] RBP: 8802f0875a50 R08: R09: 0001 [33411.934747] R10: R11: R12: 880324eeec00 [33411.934752] R13: 88032458 R14: 880320473e88 R15: [33411.934756] FS: 7fc38654d700() GS:880337d0() knlGS: [33411.934761] CS: 0010 DS: ES: CR0: 8005003b [33411.934765] CR2: 7f0cb28bd000 CR3: 0002ebcf6000 CR4: 000407e0 [33411.934769] Stack: [33411.934771] 8800bba09690 8800b4f16588 880303005a40 0001 [33411.934779] 8800b33e43d0 81a3a62d 88032458 [33411.934786] 88032458 880326660670 880326265880 81a41692 [33411.934794] Call Trace: [33411.934798] [] ? release_stripe_list+0x4d/0x70 [33411.934803] [] ? raid5d+0xa2/0x4d0 [33411.934808] [] ? md_thread+0xe6/0x120 [33411.934814] [] ? finish_wait+0x90/0x90 [33411.934818] [] ? md_rdev_init+0x100/0x100 [33411.934823] [] ? kthread+0xbc/0xe0 [33411.934828] [] ? smpboot_park_threads+0x70/0x70 [33411.934833] [] ? flush_kthread_worker+0x80/0x80 [33411.934839] [] ? ret_from_fork+0x7c/0xb0 [33411.934843] [] ? flush_kthread_worker+0x80/0x80 [33411.934847] Code: f7 ff ff 66 90 48 8b 43 18 48 8b b8 48 01 00 00 48 89 14 24 48 89 74 24 08 e8 af 9a 02 00 48 8b 74 24 08 48 8b 14 24 eb 9f 0f 0b <0f> 0b 0f 0b 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 f0 ff 4e [33411.934912] RIP [] do_release_stripe+0x18e/0x1a0 [33411.934918] RSP [33411.941326] ---[ end trace 42d97d618cc5bfe2 ]--- [33411.941331] [ cut here ] [33411.941337] WARNING: CPU: 4 PID: 2319 at kernel/exit.c:703 do_exit+0x45/0xa40() [33411.941351] Modules linked in: bonding btrfs microcode
[PATCH] gss_krb5: use lcm from kernel lib
Replace hardcoded lowest common multiple algorithm by the lcm()
function in kernel lib.
Signed-off-by: Luis Henriques
---
net/sunrpc/auth_gss/gss_krb5_keys.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/net/sunrpc/auth_gss/gss_krb5_keys.c
b/net/sunrpc/auth_gss/gss_krb5_keys.c
index 76e42e6..a16c5b6 100644
--- a/net/sunrpc/auth_gss/gss_krb5_keys.c
+++ b/net/sunrpc/auth_gss/gss_krb5_keys.c
@@ -59,6 +59,7 @@
#include
#include
#include
+#include
#ifdef RPC_DEBUG
# define RPCDBG_FACILITYRPCDBG_AUTH
@@ -72,7 +73,7 @@
static void krb5_nfold(u32 inbits, const u8 *in,
u32 outbits, u8 *out)
{
- int a, b, c, lcm;
+ unsigned long ulcm;
int byte, i, msbit;
/* the code below is more readable if I make these bytes
@@ -82,17 +83,7 @@ static void krb5_nfold(u32 inbits, const u8 *in,
outbits >>= 3;
/* first compute lcm(n,k) */
-
- a = outbits;
- b = inbits;
-
- while (b != 0) {
- c = b;
- b = a%b;
- a = c;
- }
-
- lcm = outbits*inbits/a;
+ ulcm = lcm(inbits, outbits);
/* now do the real work */
@@ -101,7 +92,7 @@ static void krb5_nfold(u32 inbits, const u8 *in,
/* this will end up cycling through k lcm(k,n)/k times, which
is correct */
- for (i = lcm-1; i >= 0; i--) {
+ for (i = ulcm-1; i >= 0; i--) {
/* compute the msbit in k which gets added into this byte */
msbit = (
/* first, start with the msbit in the first,
--
1.8.3.2
Cheers,
--
Luis
--
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/
Contract Agreement Breach
Dear Attorney, We are a Production, publishing and marketing company in Japan. We have a breach of intellectual property agreement matter in your jurisdiction, we can forward you the agreement and other party information for your review to enable you run a conflict check. Yours Sincerely, Yoshiko Tomoko Manager Shinchosha Publishing Co., Ltd. 71 Yaraicho, Shinjuku-ku, Tokyo 162-8711, Japan Tel: +81333716411 -- 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: math_state_restore and kernel_fpu_end disable interrupts?
> It's credited to Suresh Siddha, whom I've cc'ed (along with others who > signed off). Suresh, if you're still around, could you comment on why > math_state_restore always leaves interrupts disabled, regardless of their > state on entry? Is there a deep reason or is it a bug? What the comments seemed to be implying was that it was a bug to enter this code with interrupts enabled. So the problem may be a little bit more systemic; expert counsel is required. > George, does it help your problem? I'm trying it now. But it takes a while for me to reproduce, and even longer to be sure the problem has gone away. So anything you hear from me within a week will be bad news. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode
Hi On Sun, Jan 19, 2014 at 9:54 PM, Sebastian Reichel wrote: > On Mon, Dec 02, 2013 at 02:45:06AM +0100, Michael Trimarchi wrote: >> On Mon, Dec 2, 2013 at 1:24 AM, Anton Vorontsov wrote: >> > On Mon, Dec 02, 2013 at 01:02:40AM +0100, Michael Trimarchi wrote: >> >> On Sun, Dec 1, 2013 at 11:37 PM, Anton Vorontsov wrote: >> >> > On Mon, Nov 25, 2013 at 08:16:34PM +0100, Michael Trimarchi wrote: >> >> > ... >> >> >> >> So you can read this value without any type of synchronization >> >> >> >> with the power_supply_core >> >> >> >> and sysfs implementation? >> >> > ... >> >> >> https://lists.ubuntu.com/archives/kernel-team/2013-January/025206.html >> >> >> >> >> >> I found and equivalent scenario that I was trying to said >> >> > >> >> > That's a good question, actually. Even though in Pali's case the >> >> > notifier >> >> > is atomic (so that we are pretty confident that the object won't be >> >> > unregistered), there is still a possiblity of a dead lock, for example. >> >> > So >> >> >> >> So if the get_property is a sleeping function it will be a deadlock. >> >> Right? >> > >> > All kind of bad things might happen, yes. But before that I would expect a >> > bunch of warnings from might_sleep() stuff. >> > >> > I would recommend to test the patches using preempt/smp kernels + various >> > DEBUG_ kernel options set. >> > >> >> Is it more simple to make it not atomic and use a mutex in get_property? > > I just built a kernel with CONFIG_DEBUG_ATOMIC_SLEEP to test another > driver and got the following output for bq2415x: > > [7.667449] Workqueue: events power_supply_changed_work > [7.673034] [] (unwind_backtrace+0x0/0xe0) from [] > (show_stack+0x10/0x14) > [7.682098] [] (show_stack+0x10/0x14) from [] > (dump_stack+0x78/0xac) > [7.690704] [] (dump_stack+0x78/0xac) from [] > (__schedule_bug+0x48/0x60) > [7.699645] [] (__schedule_bug+0x48/0x60) from [] > (__schedule+0x74/0x638) > [7.708618] [] (__schedule+0x74/0x638) from [] > (schedule_timeout+0x1dc/0x24c) > [7.718017] [] (schedule_timeout+0x1dc/0x24c) from [] > (wait_for_common+0x138/0x17c) > [7.727966] [] (wait_for_common+0x138/0x17c) from [] > (omap_i2c_xfer+0x340/0x4a0) > [7.737640] [] (omap_i2c_xfer+0x340/0x4a0) from [] > (__i2c_transfer+0x40/0x74) > [7.747039] [] (__i2c_transfer+0x40/0x74) from [] > (i2c_transfer+0x6c/0x90) > [7.756195] [] (i2c_transfer+0x6c/0x90) from [] > (bq2415x_i2c_write+0x48/0x78) > [7.765563] [] (bq2415x_i2c_write+0x48/0x78) from [] > (bq2415x_set_weak_battery_voltage+0x4c/0x50) > [7.776824] [] (bq2415x_set_weak_battery_voltage+0x4c/0x50) from > [] (bq2415x_set_mode+0xdc/0x14c) > [7.788085] [] (bq2415x_set_mode+0xdc/0x14c) from [] > (bq2415x_notifier_call+0xa8/0xb4) > [7.798309] [] (bq2415x_notifier_call+0xa8/0xb4) from > [] (notifier_call_chain+0x38/0x68) > [7.808715] [] (notifier_call_chain+0x38/0x68) from [] > (__atomic_notifier_call_chain+0x2c/0x3c) > [7.819732] [] (__atomic_notifier_call_chain+0x2c/0x3c) from > [] (atomic_notifier_call_chain+0x14/0x18) > [7.831420] [] (atomic_notifier_call_chain+0x14/0x18) from > [] (power_supply_changed_work+0x6c/0xb8) > [7.842864] [] (power_supply_changed_work+0x6c/0xb8) from > [] (process_one_work+0x248/0x440) > [7.853546] [] (process_one_work+0x248/0x440) from [] > (worker_thread+0x208/0x350) > [7.863372] [] (worker_thread+0x208/0x350) from [] > (kthread+0xc8/0xdc) > [7.872131] [] (kthread+0xc8/0xdc) from [] > (ret_from_fork+0x14/0x3c) > > -- Sebastian I have already give my opinion about this problem Michael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode
On Mon, Dec 02, 2013 at 02:45:06AM +0100, Michael Trimarchi wrote: > On Mon, Dec 2, 2013 at 1:24 AM, Anton Vorontsov wrote: > > On Mon, Dec 02, 2013 at 01:02:40AM +0100, Michael Trimarchi wrote: > >> On Sun, Dec 1, 2013 at 11:37 PM, Anton Vorontsov wrote: > >> > On Mon, Nov 25, 2013 at 08:16:34PM +0100, Michael Trimarchi wrote: > >> > ... > >> >> >> So you can read this value without any type of synchronization > >> >> >> with the power_supply_core > >> >> >> and sysfs implementation? > >> > ... > >> >> https://lists.ubuntu.com/archives/kernel-team/2013-January/025206.html > >> >> > >> >> I found and equivalent scenario that I was trying to said > >> > > >> > That's a good question, actually. Even though in Pali's case the notifier > >> > is atomic (so that we are pretty confident that the object won't be > >> > unregistered), there is still a possiblity of a dead lock, for example. > >> > So > >> > >> So if the get_property is a sleeping function it will be a deadlock. Right? > > > > All kind of bad things might happen, yes. But before that I would expect a > > bunch of warnings from might_sleep() stuff. > > > > I would recommend to test the patches using preempt/smp kernels + various > > DEBUG_ kernel options set. > > > > Is it more simple to make it not atomic and use a mutex in get_property? I just built a kernel with CONFIG_DEBUG_ATOMIC_SLEEP to test another driver and got the following output for bq2415x: [7.667449] Workqueue: events power_supply_changed_work [7.673034] [] (unwind_backtrace+0x0/0xe0) from [] (show_stack+0x10/0x14) [7.682098] [] (show_stack+0x10/0x14) from [] (dump_stack+0x78/0xac) [7.690704] [] (dump_stack+0x78/0xac) from [] (__schedule_bug+0x48/0x60) [7.699645] [] (__schedule_bug+0x48/0x60) from [] (__schedule+0x74/0x638) [7.708618] [] (__schedule+0x74/0x638) from [] (schedule_timeout+0x1dc/0x24c) [7.718017] [] (schedule_timeout+0x1dc/0x24c) from [] (wait_for_common+0x138/0x17c) [7.727966] [] (wait_for_common+0x138/0x17c) from [] (omap_i2c_xfer+0x340/0x4a0) [7.737640] [] (omap_i2c_xfer+0x340/0x4a0) from [] (__i2c_transfer+0x40/0x74) [7.747039] [] (__i2c_transfer+0x40/0x74) from [] (i2c_transfer+0x6c/0x90) [7.756195] [] (i2c_transfer+0x6c/0x90) from [] (bq2415x_i2c_write+0x48/0x78) [7.765563] [] (bq2415x_i2c_write+0x48/0x78) from [] (bq2415x_set_weak_battery_voltage+0x4c/0x50) [7.776824] [] (bq2415x_set_weak_battery_voltage+0x4c/0x50) from [] (bq2415x_set_mode+0xdc/0x14c) [7.788085] [] (bq2415x_set_mode+0xdc/0x14c) from [] (bq2415x_notifier_call+0xa8/0xb4) [7.798309] [] (bq2415x_notifier_call+0xa8/0xb4) from [] (notifier_call_chain+0x38/0x68) [7.808715] [] (notifier_call_chain+0x38/0x68) from [] (__atomic_notifier_call_chain+0x2c/0x3c) [7.819732] [] (__atomic_notifier_call_chain+0x2c/0x3c) from [] (atomic_notifier_call_chain+0x14/0x18) [7.831420] [] (atomic_notifier_call_chain+0x14/0x18) from [] (power_supply_changed_work+0x6c/0xb8) [7.842864] [] (power_supply_changed_work+0x6c/0xb8) from [] (process_one_work+0x248/0x440) [7.853546] [] (process_one_work+0x248/0x440) from [] (worker_thread+0x208/0x350) [7.863372] [] (worker_thread+0x208/0x350) from [] (kthread+0xc8/0xdc) [7.872131] [] (kthread+0xc8/0xdc) from [] (ret_from_fork+0x14/0x3c) -- Sebastian signature.asc Description: Digital signature
Good day Dear Friend
Hi, My name is Charles Francis Feeney, a philanthropist and the founder of The Atlantic Philanthropies, one of the largest private foundations in the world. I believe strongly in ‘giving while living.’ I had one idea that never changed in my mind — that you should use your wealth to help people and I have decided to secretly give USD 1.9Million to randomly selected individuals worldwide. On receipt of this email, you should count yourself as the lucky individual. Your email address was chosen online while searching at random. Kindly get back to me at your earliest convenience, so I know your email address is valid. (charles.fee...@yandex.com) Email me. Visit the web page to know more about me: http://en.wikipedia.org/wiki/Chuck_Feeney Merry Christmas and happy new year. Charles F. Feeney charles.fee...@yandex.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: US$200 Million Humanitarian Projects
Good day, This is based on blind trust hoping you can be trusted. The above sum is avaliable for worldwide Humanitarian projects and you will get 20% of the total sum for your involvement if interested. Regards, Mr. William Billington -- 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] media: i2c: mt9v032: Check return value of clk_prepare_enable/clk_set_rate
Hi Prabhakar, Thank you for the patch. On Friday 17 January 2014 14:52:47 Prabhakar Lad wrote: > From: "Lad, Prabhakar" > > clk_set_rate(), clk_prepare_enable() functions can fail, so check the return > values to avoid surprises. > > Signed-off-by: Lad, Prabhakar Acked-by: Laurent Pinchart I've applied the patch to my tree and will send a pull request. > --- > drivers/media/i2c/mt9v032.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c > index 36c504b..40172b8 100644 > --- a/drivers/media/i2c/mt9v032.c > +++ b/drivers/media/i2c/mt9v032.c > @@ -317,8 +317,14 @@ static int mt9v032_power_on(struct mt9v032 *mt9v032) > struct i2c_client *client = v4l2_get_subdevdata(>subdev); > int ret; > > - clk_set_rate(mt9v032->clk, mt9v032->sysclk); > - clk_prepare_enable(mt9v032->clk); > + ret = clk_set_rate(mt9v032->clk, mt9v032->sysclk); > + if (ret < 0) > + return ret; > + > + ret = clk_prepare_enable(mt9v032->clk); > + if (ret) > + return ret; > + > udelay(1); > > /* Reset the chip and stop data read out */ -- Regards, Laurent Pinchart -- 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 v8 4/4] qrwlock: Use smp_store_release() in write_unlock()
On Sun, Jan 19, 2014 at 12:04 AM, Paul E. McKenney wrote: > > OK, another approach would be to never add "select ARCH_USE_QUEUE_RWLOCK" > on Alpha, at least if the queued rwlocks really do want to atomically > manipulate bytes. After all, the Alpha systems that I know about don't > have enough CPUs to make queued rwlocks necessary anyway. > > Much simpler solution! > > Is this what you were getting at, or am I missing your point? You're missing something. Just make the "writer" field be an "int" on little-endian archiectures (like alpha). There is no reason for that field to be a "char" to begin with, as far as I can tell, since the padding of the structure means that it doesn't save any space. But even if that wasn't true, we could make an arch-specific type for "minimum type for locking". So my *point* was that it should be easy enough to just make sure that any data structures used for locking have types that are appropriate for that locking. Linus -- 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] Adding hyperv.h to uapi headers
2014/1/19 KY Srinivasan :
>
>
>> -Original Message-
>> From: gurlige...@gmail.com [mailto:gurlige...@gmail.com] On Behalf Of Bjarke
>> Istrup Pedersen
>> Sent: Sunday, January 19, 2014 2:15 AM
>> To: KY Srinivasan
>> Cc: Linux Kernel Mailing List; Haiyang Zhang
>> Subject: Re: [PATCH v2] Adding hyperv.h to uapi headers
>>
>> 2014/1/19 KY Srinivasan :
>> >
>> >
>> >> -Original Message-
>> >> From: gurlige...@gmail.com [mailto:gurlige...@gmail.com] On Behalf Of
>> Bjarke
>> >> Istrup Pedersen
>> >> Sent: Saturday, January 18, 2014 4:23 PM
>> >> To: Linux Kernel Mailing List
>> >> Cc: Haiyang Zhang; KY Srinivasan; Bjarke Istrup Pedersen
>> >> Subject: Re: [PATCH v2] Adding hyperv.h to uapi headers
>> >>
>> >> Could any of you Hyper-V developers take a look at this, and see if
>> >> this split makes sense to you?
>> >
>> > Have you compiled the hyper-v drivers with your change. I briefly looked at
>> your
>> > latest patch but I did not see an include of the user level hyper-V driver
>> > in the
>> kernel
>> > version of the header; or did I miss it. Please compile the drivers and the
>> tools/hv/
>> > user level daemons to test your patch.
>>
>> Hey,
>>
>> I have compiled it, and both the drivers and the userspace deamons
>> builds fine :)
>> If you look at the patch, on line 134, it includes the uapi header.
>>
>> Also, which parts of the uapi version header would you like me to move
>> to the kernel version? (I'll create a new patch then, with your
>> suggestions)
>
> Which version information are you referring to. I would keep all version
> information
> in the uapi hyperv.h header file. The kernel needs to handle older versions
> of the daemons.
Sorry, I think I worded it wrong :)
What I meant is, is the split done in this patch fine with you, or
should I move more/less to the UAPI header file?
http://marc.info/?l=linux-kernel=139008735529658=2
/Bjarke
> Regards,
>
> K. Y
>>
>> /Bjarke
>>
>> > K. Y
>> >>
>> >> Thanks :)
>> >>
>> >> /Bjarke
>> >>
>> >> 2014/1/19 Bjarke Istrup Pedersen :
>> >> > This patch adds the hyperv.h header to the uapi folder, and adds it to
>> >> > the
>> Kbuild
>> >> file.
>> >> > Doing this enables compiling userspace Hyper-V tools using the installed
>> >> headers.
>> >> >
>> >> > Version 2: Split UAPI parts into new header, instead of duplicating.
>> >> >
>> >> > Signed-off-by: Bjarke Istrup Pedersen
>> >> > ---
>> >> > include/linux/hyperv.h | 321
>> >> > +
>> >> > include/uapi/linux/Kbuild | 1 +
>> >> > include/uapi/linux/hyperv.h | 344
>> >>
>> >> > 3 files changed, 347 insertions(+), 319 deletions(-)
>> >> > create mode 100644 include/uapi/linux/hyperv.h
>> >> >
>> >> > diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
>> >> > index 15da677..167ef47 100644
>> >> > --- a/include/linux/hyperv.h
>> >> > +++ b/include/linux/hyperv.h
>> >> > @@ -25,325 +25,9 @@
>> >> > #ifndef _HYPERV_H
>> >> > #define _HYPERV_H
>> >> >
>> >> > -#include
>> >> > -
>> >> > -/*
>> >> > - * Framework version for util services.
>> >> > - */
>> >> > -#define UTIL_FW_MINOR 0
>> >> > -
>> >> > -#define UTIL_WS2K8_FW_MAJOR 1
>> >> > -#define UTIL_WS2K8_FW_VERSION (UTIL_WS2K8_FW_MAJOR << 16 |
>> >> UTIL_FW_MINOR)
>> >> > -
>> >> > -#define UTIL_FW_MAJOR 3
>> >> > -#define UTIL_FW_VERSION (UTIL_FW_MAJOR << 16 | UTIL_FW_MINOR)
>> >> > -
>> >> > -
>> >> > -/*
>> >> > - * Implementation of host controlled snapshot of the guest.
>> >> > - */
>> >> > -
>> >> > -#define VSS_OP_REGISTER 128
>> >> > -
>> >> > -enum hv_vss_op {
>> >> > - VSS_OP_CREATE = 0,
>> >> > - VSS_OP_DELETE,
>> >> > - VSS_OP_HOT_BACKUP,
>> >> > - VSS_OP_GET_DM_INFO,
>> >> > - VSS_OP_BU_COMPLETE,
>> >> > - /*
>> >> > -* Following operations are only supported with IC version >=
>> >> > 5.0
>> >> > -*/
>> >> > - VSS_OP_FREEZE, /* Freeze the file systems in the VM */
>> >> > - VSS_OP_THAW, /* Unfreeze the file systems */
>> >> > - VSS_OP_AUTO_RECOVER,
>> >> > - VSS_OP_COUNT /* Number of operations, must be last */
>> >> > -};
>> >> > -
>> >> > -
>> >> > -/*
>> >> > - * Header for all VSS messages.
>> >> > - */
>> >> > -struct hv_vss_hdr {
>> >> > - __u8 operation;
>> >> > - __u8 reserved[7];
>> >> > -} __attribute__((packed));
>> >> > -
>> >> > -
>> >> > -/*
>> >> > - * Flag values for the hv_vss_check_feature. Linux supports only
>> >> > - * one value.
>> >> > - */
>> >> > -#define VSS_HBU_NO_AUTO_RECOVERY 0x0005
>> >> > -
>> >> > -struct hv_vss_check_feature {
>> >> > - __u32 flags;
>> >> > -} __attribute__((packed));
>> >> > -
>> >> > -struct hv_vss_check_dm_info {
>> >> > - __u32 flags;
>> >> > -} __attribute__((packed));
>> >> > -
>> >> > -struct hv_vss_msg {
>> >> > - union {
>> >> > - struct hv_vss_hdr vss_hdr;
>> >> > - int error;
>> >> > -
Re: [PATCH] media: i2c: mt9p031: Check return value of clk_prepare_enable/clk_set_rate
Hi Prabhakar,
Thank you for the patch.
On Friday 17 January 2014 14:47:33 Prabhakar Lad wrote:
> From: "Lad, Prabhakar"
>
> clk_set_rate(), clk_prepare_enable() functions can fail, so check the return
> values to avoid surprises.
>
> Signed-off-by: Lad, Prabhakar
> ---
> drivers/media/i2c/mt9p031.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
> index e5ddf47..dbe34d7 100644
> --- a/drivers/media/i2c/mt9p031.c
> +++ b/drivers/media/i2c/mt9p031.c
> @@ -222,12 +222,15 @@ static int mt9p031_clk_setup(struct mt9p031 *mt9p031)
>
> struct i2c_client *client = v4l2_get_subdevdata(>subdev);
> struct mt9p031_platform_data *pdata = mt9p031->pdata;
> + int ret;
>
> mt9p031->clk = devm_clk_get(>dev, NULL);
> if (IS_ERR(mt9p031->clk))
> return PTR_ERR(mt9p031->clk);
>
> - clk_set_rate(mt9p031->clk, pdata->ext_freq);
> + ret = clk_set_rate(mt9p031->clk, pdata->ext_freq);
> + if (ret < 0)
> + return ret;
>
> mt9p031->pll.ext_clock = pdata->ext_freq;
> mt9p031->pll.pix_clock = pdata->target_freq;
> @@ -286,8 +289,11 @@ static int mt9p031_power_on(struct mt9p031 *mt9p031)
> return ret;
>
> /* Emable clock */
> - if (mt9p031->clk)
> - clk_prepare_enable(mt9p031->clk);
> + if (mt9p031->clk) {
> + ret = clk_prepare_enable(mt9p031->clk);
> + if (ret)
> + return ret;
You should call regulator_bulk_disable() in the error path to cancel the
previous regulator_bulk_enable() call.
> + }
>
> /* Now RESET_BAR must be high */
> if (gpio_is_valid(mt9p031->reset)) {
--
Regards,
Laurent Pinchart
--
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: ping [PATCH v3] WAN: Adding support for Lantiq PEF2256 E1 chipset (FALC56)
On Sun, 2014-01-19 at 19:07 +0100, Christophe Leroy wrote:
> Pinging this watch as we got no feedback since 22 Nov, although we have taken
> into account reviews from v1 and v2.
>
> The patch adds WAN support for Lantiq FALC56 - PEF2256 E1 Chipset.
trivia:
> diff -urN a/drivers/net/wan/pef2256.c b/drivers/net/wan/pef2256.c
[]
> +static void config_hdlc_timeslot(struct pef2256_dev_priv *priv, int ts)
> +{
> + static struct {
> + u32 ttr;
> + u32 rtr;
> + } regs[] = {
> + { TTR1, RTR1 },
> + { TTR2, RTR2 },
> + { TTR3, RTR3 },
> + { TTR4, RTR4 },
> + };
const
> + int cfg_bit = 1 << (31 - ts);
> + int reg_bit = 1 << (7 - (ts % 8));
> + int j = ts / 8;
looks endian specific
> +
> + if (j >= 4)
> + return;
> +
> + if (priv->Tx_TS & cfg_bit)
> + pef2256_s8(priv, regs[j].ttr, 1 << reg_bit);
> +
> + if (priv->Rx_TS & cfg_bit)
> + pef2256_s8(priv, regs[j].rtr, 1 << reg_bit);
> +}
> +static void init_falc(struct pef2256_dev_priv *priv)
> +{
a lot of the below looks like it should use
switch/case blocks.
> + /* Clocking rate for FALC56 */
> +
> + /* Nothing to do for clocking rate 2M */
> +
> + /* clocking rate 4M */
> + if (priv->clock_rate == CLOCK_RATE_4M)
> + pef2256_s8(priv, SIC1, SIC1_SSC0);
> +
> + /* clocking rate 8M */
> + if (priv->clock_rate == CLOCK_RATE_8M)
> + pef2256_s8(priv, SIC1, SIC1_SSC1);
> +
> + /* clocking rate 16M */
> + if (priv->clock_rate == CLOCK_RATE_16M) {
> + pef2256_s8(priv, SIC1, SIC1_SSC0);
> + pef2256_s8(priv, SIC1, SIC1_SSC1);
> + }
> +
> + /* data rate for FALC56 */
> +
> + /* Nothing to do for data rate 2M on the system data bus */
> +
> + /* data rate 4M on the system data bus */
> + if (priv->data_rate == DATA_RATE_4M)
> + pef2256_s8(priv, FMR1, FMR1_SSD0);
> +
> + /* data rate 8M on the system data bus */
> + if (priv->data_rate == DATA_RATE_8M)
> + pef2256_s8(priv, SIC1, SIC1_SSD1);
> +
> + /* data rate 16M on the system data bus */
> + if (priv->data_rate == DATA_RATE_16M) {
> + pef2256_s8(priv, FMR1, FMR1_SSD0);
> + pef2256_s8(priv, SIC1, SIC1_SSD1);
> + }
> +
> + /* channel phase for FALC56 */
> +
> + /* Nothing to do for channel phase 1 */
> +
> + if (priv->channel_phase == CHANNEL_PHASE_2)
> + pef2256_s8(priv, SIC2, SIC2_SICS0);
> +
> + if (priv->channel_phase == CHANNEL_PHASE_3)
> + pef2256_s8(priv, SIC2, SIC2_SICS1);
> +
> + if (priv->channel_phase == CHANNEL_PHASE_4) {
> + pef2256_s8(priv, SIC2, SIC2_SICS0);
> + pef2256_s8(priv, SIC2, SIC2_SICS1);
> + }
> +
> + if (priv->channel_phase == CHANNEL_PHASE_5)
> + pef2256_s8(priv, SIC2, SIC2_SICS2);
> +
> + if (priv->channel_phase == CHANNEL_PHASE_6) {
> + pef2256_s8(priv, SIC2, SIC2_SICS0);
> + pef2256_s8(priv, SIC2, SIC2_SICS2);
> + }
> +
> + if (priv->channel_phase == CHANNEL_PHASE_7) {
> + pef2256_s8(priv, SIC2, SIC2_SICS1);
> + pef2256_s8(priv, SIC2, SIC2_SICS2);
> + }
> +
> + if (priv->channel_phase == CHANNEL_PHASE_8) {
> + pef2256_s8(priv, SIC2, SIC2_SICS0);
> + pef2256_s8(priv, SIC2, SIC2_SICS1);
> + pef2256_s8(priv, SIC2, SIC2_SICS2);
> + }
> +static ssize_t fs_attr_mode_store(struct device *dev,
> + struct device_attribute *attr, const char *buf,
> + size_t count)
> +{
> + struct net_device *ndev = dev_get_drvdata(dev);
> + struct pef2256_dev_priv *priv = dev_to_hdlc(ndev)->priv;
> + long int value;
> + int ret = kstrtol(buf, 10, );
> + int reconfigure = (value != priv->mode);
Ugly test and set before determining if the previous
function was successful.
> + if (value != MASTER_MODE && value != SLAVE_MODE)
> + ret = -EINVAL;
> +
> + if (ret < 0)
> + netdev_info(ndev, "Invalid mode (0 or 1 expected\n");
> + else {
> + priv->mode = value;
> + if (reconfigure && netif_carrier_ok(ndev))
> + init_falc(priv);
> + }
> +
> + return strnlen(buf, count);
odd that you set ret and then don't use it.
> +static ssize_t fs_attr_Tx_TS_store(struct device *dev,
> + struct device_attribute *attr, const char *buf,
> + size_t count)
> +{
> + struct net_device *ndev = dev_get_drvdata(dev);
> + struct pef2256_dev_priv *priv = dev_to_hdlc(ndev)->priv;
> + unsigned long value;
> + int ret = kstrtoul(buf, 16, (long int *));
unportable cast
> + int reconfigure = (value != priv->mode);
again with the test/set before determining function success.
--
To unsubscribe from this list: send the line "unsubscribe
Re: math_state_restore and kernel_fpu_end disable interrupts?
[Here's my original message, since George's reply didn't quote or
reference it: https://lkml.org/lkml/2014/1/18/3. Summary:
math_state_restore() always leaves interrupts disabled, and I think this
is a bug.]
On Sun, 19 Jan 2014, George Spelvin wrote:
THANK YOU!
I've been having a problem with ext4 metadata checksums, which use SSE
for large blocks, and traced it to kernel_fpu_end() disabling interrupts,
but had paused to debug this (I assumed well-tested) piece of kernel
code before pushing it harder.
Interesting. I guess it's not surprising this has other effects.
Here's the commit that added the code in question (about 6 years ago):
https://github.com/torvalds/linux/commit/aa283f49276e7d840a40fb01eee6de97eaa7e012
It's credited to Suresh Siddha, whom I've cc'ed (along with others who
signed off). Suresh, if you're still around, could you comment on why
math_state_restore always leaves interrupts disabled, regardless of their
state on entry? Is there a deep reason or is it a bug?
Assuming it's a bug, here's the obvious patch:
--- linux-source-3.11.0/arch/x86/kernel/traps.c 2013-09-02 14:46:10.0
-0600
+++ linux-source-3.11.0-nate/arch/x86/kernel/traps.c2014-01-19
11:25:32.977221476 -0700
@@ -624,6 +624,9 @@
struct task_struct *tsk = current;
if (!tsk_used_math(tsk)) {
+ unsigned long flags;
+
+ local_save_flags(flags);
local_irq_enable();
/*
* does a slab alloc which can sleep
@@ -635,7 +638,7 @@
do_group_exit(SIGKILL);
return;
}
- local_irq_disable();
+ local_irq_restore(flags);
}
__thread_fpu_begin(tsk);
I tested it briefly: the kernel still boots fine, and it fixes the problem
I was seeing (BUG() when core dumping on ecryptfs). George, does it help
your problem?
Thanks everyone!
(Search October-December LKML archives for "3.11.4: kernel BUG at
fs/buffer.c:1268".")
--
Nate Eldredge
n...@thatsmathematics.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 v3 23/24] drm/i2c: tda998x: code optimization
This patch reduces the number of I2C exchanges by setting many bits in one write and removing a useless write. Signed-off-by: Jean-Francois Moine --- drivers/gpu/drm/i2c/tda998x_drv.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index 2fcc432..0716a75 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c +++ b/drivers/gpu/drm/i2c/tda998x_drv.c @@ -702,10 +702,8 @@ tda998x_configure_audio(struct tda998x_priv *priv, } reg_write(priv, REG_AIP_CLKSEL, clksel_aip); - reg_clear(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_LAYOUT); - - /* Enable automatic CTS generation */ - reg_clear(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_ACR_MAN); + reg_clear(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_LAYOUT | + AIP_CNTRL_0_ACR_MAN); /* auto CTS */ reg_write(priv, REG_CTS_N, cts_n); reg_write(priv, REG_ENA_ACLK, aclk); @@ -953,10 +951,10 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder, reg_write(priv, REG_VIP_CNTRL_5, VIP_CNTRL_5_SP_CNT(0)); reg_write(priv, REG_VIP_CNTRL_4, VIP_CNTRL_4_BLANKIT(0) | VIP_CNTRL_4_BLC(0)); - reg_clear(priv, REG_PLL_SERIAL_3, PLL_SERIAL_3_SRL_CCIR); reg_clear(priv, REG_PLL_SERIAL_1, PLL_SERIAL_1_SRL_MAN_IZ); - reg_clear(priv, REG_PLL_SERIAL_3, PLL_SERIAL_3_SRL_DE); + reg_clear(priv, REG_PLL_SERIAL_3, PLL_SERIAL_3_SRL_CCIR | + PLL_SERIAL_3_SRL_DE); reg_write(priv, REG_SERIALIZER, 0); reg_write(priv, REG_HVF_CNTRL_1, HVF_CNTRL_1_VQR(0)); @@ -976,8 +974,6 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder, /* set BIAS tmds value: */ reg_write(priv, REG_ANA_GENERAL, 0x09); - reg_write(priv, REG_TBG_CNTRL_0, 0); - /* * Sync on rising HSYNC/VSYNC */ -- 1.8.5.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 v3 24/24] drm/i2c: tda998x: adjust the audio clock divider for S/PDIF
The S/PDIF input asks for a greater audio clock divider. Signed-off-by: Jean-Francois Moine --- drivers/gpu/drm/i2c/tda998x_drv.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index 0716a75..06c484d 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c +++ b/drivers/gpu/drm/i2c/tda998x_drv.c @@ -707,6 +707,10 @@ tda998x_configure_audio(struct tda998x_priv *priv, reg_write(priv, REG_CTS_N, cts_n); reg_write(priv, REG_ENA_ACLK, aclk); + /* S/PDIF asks for a large divider */ + if (priv->audio_format == AFMT_SPDIF) + adiv = AUDIO_DIV_SERCLK_32; + /* * Audio input somehow depends on HDMI line rate which is * related to pixclk. Testing showed that modes with pixclk @@ -714,7 +718,7 @@ tda998x_configure_audio(struct tda998x_priv *priv, * There is no detailed info in the datasheet, so we just * assume 100MHz requires larger divider. */ - if (mode->clock > 10) + else if (mode->clock > 10) adiv = AUDIO_DIV_SERCLK_16; else adiv = AUDIO_DIV_SERCLK_8; -- 1.8.5.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 v3 22/24] drm/i2c: tda998x: change the frequence in the audio channel
This patch sets the frequence as 'not indicated' instead of '48kHz' and adds some comments. Signed-off-by: Jean-Francois Moine --- drivers/gpu/drm/i2c/tda998x_drv.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index 05713f7..2fcc432 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c +++ b/drivers/gpu/drm/i2c/tda998x_drv.c @@ -745,10 +745,11 @@ tda998x_configure_audio(struct tda998x_priv *priv, reg_clear(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_RST_CTS); /* Write the channel status */ - buf[0] = 0x04; + buf[0] = (1 << 2); /* copyright unprotected */ buf[1] = 0x00; - buf[2] = 0x00; - buf[3] = 0xf1; + buf[2] = 1; /* freq not indicated */ + buf[3] = (0 << 4) | /* orig freq = not indicated */ + 1; /* max word length 24 bits */ reg_write_range(priv, REG_CH_STAT_B(0), buf, 4); tda998x_audio_mute(priv, true); -- 1.8.5.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 v3 21/24] drm/i2c: tda998x: add the active aspect in HDMI AVI frame
Signed-off-by: Jean-Francois Moine --- drivers/gpu/drm/i2c/tda998x_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index a2ad2ac..05713f7 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c +++ b/drivers/gpu/drm/i2c/tda998x_drv.c @@ -649,6 +649,7 @@ tda998x_write_avi(struct tda998x_priv *priv, struct drm_display_mode *mode) buf[HB(1)] = 0x02; buf[HB(2)] = HDMI_AVI_INFOFRAME_SIZE; buf[PB(1)] = HDMI_SCAN_MODE_UNDERSCAN; + buf[PB(2)] = HDMI_ACTIVE_ASPECT_PICTURE; buf[PB(3)] = HDMI_QUANTIZATION_RANGE_FULL << 2; buf[PB(4)] = drm_match_cea_mode(mode); -- 1.8.5.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 v3 18/24] drm/i2c: tda998x: fix the ENABLE_SPACE register
This patch fixes the ENABLE_SPACE register, the value of which was
inverted.
Signed-off-by: Jean-Francois Moine
---
drivers/gpu/drm/i2c/tda998x_drv.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index ea7d1b4..ce832f0 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -220,7 +220,7 @@ struct tda998x_priv {
# define PLL_SERIAL_1_SRL_IZ(x) (((x) & 3) << 1)
# define PLL_SERIAL_1_SRL_MAN_IZ (1 << 6)
#define REG_PLL_SERIAL_2 REG(0x02, 0x01) /* read/write */
-# define PLL_SERIAL_2_SRL_NOSC(x) (((x) & 3) << 0)
+# define PLL_SERIAL_2_SRL_NOSC(x) ((x) << 0)
# define PLL_SERIAL_2_SRL_PR(x) (((x) & 0xf) << 4)
#define REG_PLL_SERIAL_3 REG(0x02, 0x02) /* read/write */
# define PLL_SERIAL_3_SRL_CCIR(1 << 0)
@@ -932,6 +932,11 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
}
div = 148500 / adj_mode->clock;
+ if (div != 0) {
+ div--;
+ if (div > 3)
+ div = 3;
+ }
/* mute the audio FIFO: */
reg_set(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_RST_FIFO);
@@ -1011,7 +1016,7 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
if (priv->rev == TDA19988) {
/* let incoming pixels fill the active space (if any) */
- reg_write(priv, REG_ENABLE_SPACE, 0x01);
+ reg_write(priv, REG_ENABLE_SPACE, 0x00);
}
/*
--
1.8.5.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 v3 17/24] drm/i2c: tda998x: get a better status of the connection
This patch refines the connection status testing both bits RXSENS and HPD of the CEC register giving the connection level. Signed-off-by: Jean-Francois Moine --- drivers/gpu/drm/i2c/tda998x_drv.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index 013a67c..ea7d1b4 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c +++ b/drivers/gpu/drm/i2c/tda998x_drv.c @@ -1050,7 +1050,9 @@ tda998x_encoder_detect(struct drm_encoder *encoder, struct tda998x_priv *priv = to_tda998x_priv(encoder); uint8_t val = cec_read(priv, REG_CEC_RXSHPDLEV); - return (val & CEC_RXSHPDLEV_HPD) ? connector_status_connected : + return (val & (CEC_RXSHPDLEV_RXSENS | CEC_RXSHPDLEV_HPD)) == + (CEC_RXSHPDLEV_RXSENS | CEC_RXSHPDLEV_HPD) ? + connector_status_connected : connector_status_disconnected; } -- 1.8.5.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/
