Re: [RFC][PATCH] procfs: Add /proc/pid/mapped_files
On Thu, 15 Jan 2015 00:51:50 +0100 Rasmus Villemoes li...@rasmusvillemoes.dk wrote: There are still several flags unused in vma.vm_flags btw. I'm not sure that we can repurpose vm_pgoff (or vm_private_data) for this: a badly behaved thread could make its sp point at a random vma then trick the kernel into scribbling on that vma's vm_proff? Well, we could still check vm_file for being NULL before writing to vm_pgoff/vm_stack_tid. Yes, I guess that would work. We'd need to check that nobody else is already playing similar games with vm_pgoff. -- 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 RFC] page_writeback: cleanup mess around cancel_dirty_page()
On Thu, 15 Jan 2015 18:57:31 +0300 Konstantin Khebnikov
khlebni...@yandex-team.ru wrote:
This patch replaces cancel_dirty_page() with helper account_page_cleared()
which only updates counters. It's called from delete_from_page_cache()
and from try_to_free_buffers() (hack for ext3). Page is locked in both cases.
Hugetlbfs has no dirty pages accounting, ClearPageDirty() is enough here.
cancel_dirty_page() in nfs_wb_page_cancel() is redundant. This is helper
for nfs_invalidate_page() and it's called only in case complete invalidation.
Open-coded kludge at the end of __delete_from_page_cache() is redundant too.
This mess was started in v2.6.20, after commit 3e67c09 (truncate: clear page
dirtiness before running try_to_free_buffers()) reverted back in v2.6.25
by commit a2b3456 (Fix dirty page accounting leak with ext3 data=journal).
Custom fixes were introduced between them. NFS in in v2.6.23 in commit
1b3b4a1 (NFS: Fix a write request leak in nfs_invalidate_page()).
Kludge __delete_from_page_cache() in v2.6.24, commit 3a692790 (Do dirty
page accounting when removing a page from the page cache).
It seems safe to leave dirty flag set on truncated page, free_pages_check()
will clear it before returning page into buddy allocator.
account_page_cleared() is not a good name - clearing a page means
filling it with zeroes. account_page_cleaned(), perhaps?
I don't think your email cc'ed all the correct people? lustre, nfs,
ext3?
...
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -3243,8 +3243,8 @@ int try_to_free_buffers(struct page *page)
* to synchronise against __set_page_dirty_buffers and prevent the
* dirty bit from being lost.
*/
- if (ret)
- cancel_dirty_page(page, PAGE_CACHE_SIZE);
+ if (ret TestClearPageDirty(page))
+ account_page_cleared(page, mapping);
OK.
spin_unlock(mapping-private_lock);
out:
if (buffers_to_free) {
...
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -1811,11 +1811,6 @@ int nfs_wb_page_cancel(struct inode *inode, struct
page *page)
* request from the inode / page_private pointer and
* release it */
nfs_inode_remove_request(req);
- /*
- * In case nfs_inode_remove_request has marked the
- * page as being dirty
- */
- cancel_dirty_page(page, PAGE_CACHE_SIZE);
hm, if you say so..
nfs_unlock_and_release_request(req);
}
...
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -201,18 +201,6 @@ void __delete_from_page_cache(struct page *page, void
*shadow)
if (PageSwapBacked(page))
__dec_zone_page_state(page, NR_SHMEM);
BUG_ON(page_mapped(page));
-
- /*
- * Some filesystems seem to re-dirty the page even after
- * the VM has canceled the dirty bit (eg ext3 journaling).
- *
- * Fix it up by doing a final dirty accounting check after
- * having removed the page entirely.
- */
- if (PageDirty(page) mapping_cap_account_dirty(mapping)) {
- dec_zone_page_state(page, NR_FILE_DIRTY);
- dec_bdi_stat(mapping-backing_dev_info, BDI_RECLAIMABLE);
- }
}
/**
@@ -230,6 +218,9 @@ void delete_from_page_cache(struct page *page)
BUG_ON(!PageLocked(page));
+ if (PageDirty(page))
+ account_page_cleared(page, mapping);
+
OK, but we lost the important comment - transplant that?
It's strange that we left the dirty bit set after accounting for its
clearing. How does this work? Presumably the offending fs dirtied the
page without accounting for it? I have a bad feeling I wrote that code :(
freepage = mapping-a_ops-freepage;
spin_lock_irq(mapping-tree_lock);
__delete_from_page_cache(page, NULL);
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 4da3cd5..f371522 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -2106,6 +2106,25 @@ void account_page_dirtied(struct page *page, struct
address_space *mapping)
EXPORT_SYMBOL(account_page_dirtied);
/*
+ * Helper function for deaccounting dirty page without doing writeback.
+ * Doing this should *normally* only ever be done when a page
+ * is truncated, and is not actually mapped anywhere at all. However,
+ * fs/buffer.c does this when it notices that somebody has cleaned
+ * out all the buffers on a page without actually doing it through
+ * the VM. Can you say ext3 is horribly ugly? Tought you could.
Thought.
+ */
+void account_page_cleared(struct page *page, struct address_space *mapping)
+{
+ if (mapping_cap_account_dirty(mapping)) {
+ dec_zone_page_state(page, NR_FILE_DIRTY);
+ dec_bdi_stat(mapping-backing_dev_info,
+ BDI_RECLAIMABLE);
+ task_io_account_cancelled_write(PAGE_CACHE_SIZE);
+ }
+}
+EXPORT_SYMBOL(account_page_cleared);
Re: [RFC PATCH 0/5] Remove global locks from epoll
On Thu, 01/15 21:02, Jason Baron wrote: Finally, I'd also like to potentially co-ordinate this series with the recent syscall enhancements from Fam Zheng: http://lwn.net/Articles/628828/ since these patches are somewhat invasive. What I am working on is a new call that can be seen as a list of epoll_ctl operations followed by an wait, which has enriched clockid and timespec flexibility. it will reuse existing calls' implementation, but that ideally should be independent to most of the implementation internals, including locking changes here. Thanks for letting me know! Fam -- 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] ethernet: atheros: Add nss-gmac driver
On Thu, 8 Jan 2015 14:03:46 -0800 Stephen Wang wstep...@codeaurora.org wrote: + uint32_t rx_bytes; /** Number of RX bytes */ + uint32_t rx_packets;/** Number of RX packets */ 32 bit packet stats are a problem with lots of traffic. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] staging: olpc_dcon: fix sparse symbol not declared warning
This patch gets rid of the following sparse warning:
drivers/staging/olpc_dcon/olpc_dcon.c:787:19: warning: symbol 'dcon_driver' was
not declared. Should it be static?
Signed-off-by: Murilo Opsfelder Araujo mopsfel...@gmail.com
---
drivers/staging/olpc_dcon/olpc_dcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/olpc_dcon/olpc_dcon.c
b/drivers/staging/olpc_dcon/olpc_dcon.c
index 3708f1e..4ec2a9c 100644
--- a/drivers/staging/olpc_dcon/olpc_dcon.c
+++ b/drivers/staging/olpc_dcon/olpc_dcon.c
@@ -784,7 +784,7 @@ static const struct i2c_device_id dcon_idtable[] = {
};
MODULE_DEVICE_TABLE(i2c, dcon_idtable);
-struct i2c_driver dcon_driver = {
+static struct i2c_driver dcon_driver = {
.driver = {
.name = olpc_dcon,
.pm = dcon_pm_ops,
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] staging: olpc_dcon: fix sparse warnings and compile errors
These two patches fix sparse warnings and make olpc_dcon.c build again when CONFIG_OLPC is not set. Murilo Opsfelder Araujo (2): staging: olpc_dcon: check for CONFIG_OLPC before calling olpc_board_at_least() staging: olpc_dcon: fix sparse symbol not declared warning drivers/staging/olpc_dcon/olpc_dcon.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] staging: olpc_dcon: check for CONFIG_OLPC before calling olpc_board_at_least()
The following error messages are thrown by sparse when CONFIG_OLPC is
not defined:
drivers/staging/olpc_dcon/olpc_dcon.c:147:17: error: undefined identifier
'olpc_board_at_least'
drivers/staging/olpc_dcon/olpc_dcon.c:208:14: error: undefined identifier
'olpc_board_at_least'
This patch fixes these errors.
Signed-off-by: Murilo Opsfelder Araujo mopsfel...@gmail.com
---
drivers/staging/olpc_dcon/olpc_dcon.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/staging/olpc_dcon/olpc_dcon.c
b/drivers/staging/olpc_dcon/olpc_dcon.c
index 6a9a881..3708f1e 100644
--- a/drivers/staging/olpc_dcon/olpc_dcon.c
+++ b/drivers/staging/olpc_dcon/olpc_dcon.c
@@ -144,7 +144,9 @@ power_up:
}
if (x 0) {
pr_err(unable to stabilize dcon's smbus, reasserting power and
praying.\n);
+#ifdef CONFIG_OLPC
BUG_ON(olpc_board_at_least(olpc_board(0xc2)));
+#endif
pm = 0;
olpc_ec_cmd(EC_DCON_POWER_MODE, pm, 1, NULL, 0);
msleep(100);
@@ -205,8 +207,10 @@ static void dcon_sleep(struct dcon_priv *dcon, bool sleep)
if (dcon-asleep == sleep)
return;
+#ifdef CONFIG_OLPC
if (!olpc_board_at_least(olpc_board(0xc2)))
return;
+#endif
if (sleep) {
u8 pm = 0;
@@ -795,11 +799,14 @@ struct i2c_driver dcon_driver = {
static int __init olpc_dcon_init(void)
{
+#ifdef CONFIG_OLPC
#ifdef CONFIG_FB_OLPC_DCON_1_5
/* XO-1.5 */
if (olpc_board_at_least(olpc_board(0xd0)))
pdata = dcon_pdata_xo_1_5;
#endif
+#endif
+
#ifdef CONFIG_FB_OLPC_DCON_1
if (!pdata)
pdata = dcon_pdata_xo_1;
--
2.1.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/
[ext4:crypto 15/21] fs/ext4/crypto_fname.c:322:5: sparse: symbol 'ext4_fname_decrypt' was not declared. Should it be static?
tree: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git crypto head: e32261a72a3c0c6c59d761820d8ca8b7c90008af commit: 6b8813e5baf3aa99baec11610cc29bc4ed20e671 [15/21] ext4 crypto: filename encryption facilities reproduce: # apt-get install sparse git checkout 6b8813e5baf3aa99baec11610cc29bc4ed20e671 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by ) fs/ext4/crypto_fname.c:322:5: sparse: symbol 'ext4_fname_decrypt' was not declared. Should it be static? fs/ext4/crypto_fname.c:380:5: sparse: symbol 'ext4_fname_encode_digest' was not declared. Should it be static? fs/ext4/crypto_fname.c:479:6: sparse: symbol 'ext4_free_fname_crypto_ctx' was not declared. Should it be static? fs/ext4/crypto_fname.c:532:30: sparse: symbol 'ext4_alloc_fname_crypto_ctx' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation -- 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 ext4] ext4 crypto: ext4_fname_decrypt() can be static
fs/ext4/crypto_fname.c:322:5: sparse: symbol 'ext4_fname_decrypt' was not
declared. Should it be static?
fs/ext4/crypto_fname.c:380:5: sparse: symbol 'ext4_fname_encode_digest' was not
declared. Should it be static?
fs/ext4/crypto_fname.c:479:6: sparse: symbol 'ext4_free_fname_crypto_ctx' was
not declared. Should it be static?
fs/ext4/crypto_fname.c:532:30: sparse: symbol 'ext4_alloc_fname_crypto_ctx' was
not declared. Should it be static?
Signed-off-by: Fengguang Wu fengguang...@intel.com
---
crypto_fname.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/ext4/crypto_fname.c b/fs/ext4/crypto_fname.c
index e1a72d1..4b4b507 100644
--- a/fs/ext4/crypto_fname.c
+++ b/fs/ext4/crypto_fname.c
@@ -319,7 +319,7 @@ static int ext4_fname_encrypt(struct ext4_fname_crypto_ctx
*ctx,
* Errors are returned as negative numbers.
* We trust the caller to allocate sufficient memory to oname string.
*/
-int ext4_fname_decrypt(struct ext4_fname_crypto_ctx *ctx,
+static int ext4_fname_decrypt(struct ext4_fname_crypto_ctx *ctx,
struct ext4_cstr *oname,
const struct ext4_cstr *iname)
{
@@ -377,7 +377,7 @@ int ext4_fname_decrypt(struct ext4_fname_crypto_ctx *ctx,
* Encodes the input digest using characters from the set [a-zA-Z0-9_+].
* The encoded string is roughly 4/3 times the size of the input string.
*/
-int ext4_fname_encode_digest(char *dst, char *src, u32 len)
+static int ext4_fname_encode_digest(char *dst, char *src, u32 len)
{
static const char *lookup_table =
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_+;
@@ -476,7 +476,7 @@ out:
*
* Frees up a crypto context.
*/
-void ext4_free_fname_crypto_ctx(struct ext4_fname_crypto_ctx *ctx)
+static void ext4_free_fname_crypto_ctx(struct ext4_fname_crypto_ctx *ctx)
{
if (ctx == NULL || IS_ERR(ctx))
return;
@@ -529,7 +529,7 @@ static struct ext4_fname_crypto_ctx
*ext4_search_fname_crypto_ctx(
/**
* ext4_alloc_fname_crypto_ctx() -
*/
-struct ext4_fname_crypto_ctx *ext4_alloc_fname_crypto_ctx(
+static struct ext4_fname_crypto_ctx *ext4_alloc_fname_crypto_ctx(
const struct ext4_encryption_key *key)
{
struct ext4_fname_crypto_ctx *ctx;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] x86, fpu: don't abuse -has_fpu in __kernel_fpu_{begin,end}()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/15/2015 02:20 PM, Oleg Nesterov wrote:
Now that we have in_kernel_fpu we can remove
__thread_clear_has_fpu() in __kernel_fpu_begin(). And this allows
to replace the asymmetrical and nontrivial use_eager_fpu +
tsk_used_math check in kernel_fpu_end() with the same
__thread_has_fpu() check.
The logic becomes really simple; if _begin() does save() then
_end() needs restore(), this is controlled by __thread_has_fpu().
Otherwise they do clts/stts unless use_eager_fpu().
Not only this makes begin/end symmetrical and imo more
understandable, potentially this allows to change irq_fpu_usable()
to avoid all other checks except in_kernel_fpu.
Also, with this patch __kernel_fpu_end() does
restore_fpu_checking() and WARNs if it fails instead of
math_state_restore(). I think this looks better because we no
longer need __thread_fpu_begin(), and it would be better to report
the failure in this case.
Signed-off-by: Oleg Nesterov o...@redhat.com ---
arch/x86/kernel/i387.c | 19 ++- 1 files changed,
6 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c index
a815723..12088a3 100644 --- a/arch/x86/kernel/i387.c +++
b/arch/x86/kernel/i387.c @@ -81,9 +81,7 @@ void
__kernel_fpu_begin(void) this_cpu_write(in_kernel_fpu, true);
if (__thread_has_fpu(me)) { - __thread_clear_has_fpu(me);
I will put that line back in the patch series that defers the
loading of FPU state until the switch to user space, but I
guess we can go either way for now...
__save_init_fpu(me); -/* We do 'stts()' in __kernel_fpu_end()
*/
} else if (!use_eager_fpu()) { this_cpu_write(fpu_owner_task,
NULL); clts(); @@ -93,17 +91,12 @@
EXPORT_SYMBOL(__kernel_fpu_begin);
void __kernel_fpu_end(void) { - if (use_eager_fpu()) { -
/* - *
For eager fpu, most the time, tsk_used_math() is true. - *
Restore the user math as we are done with the kernel usage. - *
At few instances during thread exit, signal handling etc, -*
tsk_used_math() is false. Those few places will take proper - *
actions, so we don't need to restore the math here. - */ -
if
(likely(tsk_used_math(current))) -math_state_restore(); -
} else
{ + struct task_struct *me = current; + + if (__thread_has_fpu(me))
{ + if (WARN_ON(restore_fpu_checking(me))) +
drop_init_fpu(me);
+ } else if (!use_eager_fpu()) { stts(); }
- --
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUuHb9AAoJEM553pKExN6DOqAIALCVqEtQ9yZEA6G9a4n4wf2r
2FHhz+H1KXUcFSVQp/KeqPq2ZJ4/1rO/omai49m1isXnjmOOLGF4Ur4E0gg6WM5W
cBgN4HYNaFIr0JMWbMfFo7hnwL7BiQLoMwqxJDxi7HQcGoIkFFDIRtezZz75acey
dKhOUz4p6C8EMgOEc1ssa5Vgo011hIfuB6aCS6NRNDJAlYornhzf0bt7HILw4tFj
1IGR+yBpb7AmlWm6EvY4NluQ3M0KjtWErpBMSMCubVMBSa62e7Twv2K9eDLx+dbz
eScoNZiy0aTgMGlN4hfXoSIwbxUkOaBl+6yAMOLn0OEV00OxxRKOAuZdQS0NUsE=
=M7Fz
-END PGP SIGNATURE-
--
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] coresight: remove the extra spaces
There are some extra spaces, so just remove them from these lines.
Signed-off-by: Kaixu Xia
---
drivers/coresight/coresight-etb10.c | 2 +-
drivers/coresight/coresight.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/coresight/coresight-etb10.c
b/drivers/coresight/coresight-etb10.c
index c922d4a..d0529b5 100644
--- a/drivers/coresight/coresight-etb10.c
+++ b/drivers/coresight/coresight-etb10.c
@@ -454,7 +454,7 @@ static int etb_probe(struct amba_device *adev, const struct
amba_id *id)
if (ret)
return ret;
- drvdata->buffer_depth = etb_get_buffer_depth(drvdata);
+ drvdata->buffer_depth = etb_get_buffer_depth(drvdata);
clk_disable_unprepare(drvdata->clk);
if (drvdata->buffer_depth < 0)
diff --git a/drivers/coresight/coresight.c b/drivers/coresight/coresight.c
index 11968b7..0de0c39 100644
--- a/drivers/coresight/coresight.c
+++ b/drivers/coresight/coresight.c
@@ -498,7 +498,7 @@ static int coresight_orphan_match(struct device *dev, void
*data)
* Circle throuch all the connection of that component. If we find
* an orphan connection whose name matches @csdev, link it.
*/
- for (i = 0; i < i_csdev->nr_outport; i++) {
+ for (i = 0; i < i_csdev->nr_outport; i++) {
conn = _csdev->conns[i];
/* We have found at least one orphan connection */
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v3 1/3] irqchip: vf610-mscm: add support for MSCM interrupt router
This adds support for Vybrid's interrupt router. On VF6xx models,
almost all peripherals can be accessed from either of the two
CPU's, from the Cortex-A5 or from the Cortex-M4. The interrupt
router routes the peripheral interrupts to the configured CPU.
The driver makes use of the irqdomain hierarchy support. The
parent is either the ARM GIC or the ARM NVIC interrupt controller
depending on which CPU the kernel is executed on. Currently only
ARM GIC is supported because the NVIC driver lacks hierarchical
irqdomain support as of now.
Currently, there is no resource control mechnism implemented to
avoid concurrent access of the same peripheral. The user needs
to make sure to use device trees which assign the peripherals
orthogonally. However, this driver warns the user in case the
interrupt is already configured for the other CPU. This provides
a poor man's resource controller.
Signed-off-by: Stefan Agner
---
arch/arm/mach-imx/Kconfig| 1 +
drivers/irqchip/Kconfig | 11 +++
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-vf610-mscm.c | 186 +++
4 files changed, 199 insertions(+)
create mode 100644 drivers/irqchip/irq-vf610-mscm.c
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index e8627e0..3c5859e 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -631,6 +631,7 @@ config SOC_IMX6SX
config SOC_VF610
bool "Vybrid Family VF610 support"
+ select VF610_MSCM
select ARM_GIC
select PINCTRL_VF610
select PL310_ERRATA_769419 if CACHE_L2X0
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index cc79d2a..af5e72a 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -136,6 +136,17 @@ config IRQ_CROSSBAR
a free irq and configures the IP. Thus the peripheral interrupts are
routed to one of the free irqchip interrupt lines.
+config VF610_MSCM
+ bool
+ help
+ Support for MSCM interrupt router available on Vybrid SoC's. The
+ interrupt router is between the CPU's interrupt controller and the
+ peripheral. The router allows to route the peripheral interrupts to
+ one of the two available CPU's on Vybrid VF6xx SoC's (Cortex-A5 or
+ Cortex-M4). The router will be configured transparently on a IRQ
+ request.
+ select IRQ_DOMAIN_HIERARCHY
+
config KEYSTONE_IRQ
tristate "Keystone 2 IRQ controller IP"
depends on ARCH_KEYSTONE
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 9516a32..85651be 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_TB10X_IRQC) += irq-tb10x.o
obj-$(CONFIG_XTENSA) += irq-xtensa-pic.o
obj-$(CONFIG_XTENSA_MX)+= irq-xtensa-mx.o
obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
+obj-$(CONFIG_VF610_MSCM) += irq-vf610-mscm.o
obj-$(CONFIG_BCM7120_L2_IRQ) += irq-bcm7120-l2.o
obj-$(CONFIG_BRCMSTB_L2_IRQ) += irq-brcmstb-l2.o
obj-$(CONFIG_KEYSTONE_IRQ) += irq-keystone.o
diff --git a/drivers/irqchip/irq-vf610-mscm.c b/drivers/irqchip/irq-vf610-mscm.c
new file mode 100644
index 000..7a284d5
--- /dev/null
+++ b/drivers/irqchip/irq-vf610-mscm.c
@@ -0,0 +1,186 @@
+/*
+ * Copyright 2014 Stefan Agner
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "irqchip.h"
+
+#define MSCM_CPxNUM0x4
+#define MSCM_IRSPRC(n) (0x880 + 2 * (n))
+#define MSCM_IRSPRC_CPEN_MASK 0x3
+
+#define MSCM_IRSPRC_NUM112
+
+struct vf610_mscm_chip_data {
+ void __iomem *mscm_base;
+ u16 cpu_mask;
+ u16 saved_irsprc[MSCM_IRSPRC_NUM];
+};
+
+static struct vf610_mscm_chip_data *mscm_data;
+
+static inline void vf610_mscm_save(struct vf610_mscm_chip_data *data)
+{
+ int i;
+
+ for (i = 0; i < MSCM_IRSPRC_NUM; i++)
+ data->saved_irsprc[i] = readw_relaxed(data->mscm_base +
MSCM_IRSPRC(i));
+}
+
+static inline void vf610_mscm_restore(struct vf610_mscm_chip_data *data)
+{
+ int i;
+
+ for (i = 0; i < MSCM_IRSPRC_NUM; i++)
+ writew_relaxed(data->saved_irsprc[i], data->mscm_base +
MSCM_IRSPRC(i));
+}
+
+static int vf610_mscm_notifier(struct notifier_block *self, unsigned long cmd,
+ void *v)
+{
+ switch (cmd) {
+ case CPU_CLUSTER_PM_ENTER:
+ vf610_mscm_save(mscm_data);
+ break;
+ case CPU_CLUSTER_PM_ENTER_FAILED:
+ case CPU_CLUSTER_PM_EXIT:
+
[PATCH RESEND v3 0/3] irqchip: vf610-mscm: add support for MSCM interrupt router
Splitted out version of the MSCM driver. My first driver based on the routeable domain support and was part of the Vybrid Cortex-M4 support patchset. So far the MSCM interrupt router was initialized by the boot loader and configured all interrupts for the Cortex-A5 CPU. There are two use cases where a proper driver is necessary: - To run Linux on the Cortex-M4. When the kernel is running on the non-preconfigured CPU, the interrupt router need to be configured properly. - To support deeper sleep modes: LPSTOP clears the interrupt router configuration, hence a driver needs to restore the configuration on resume. I created a seperate patchset for that driver which hopefully makes it easier to get it into mergeable state. Since I identified some registers likely to be used by other drivers (e.g. CPU ID or the CPU Generate Interrupt Register) I also added the "syscon" compatible string to make the registers available for other drivers in case needed. This resend version of this patchset is rebased on v3.19-rc4. Changes since v2 - Use two cell layout for MSCM interrupt router - Move peripheral interrupt properties to base device tree vfxxx.dtsi - Use generic two cell xlate (irq_domain_xlate_twocell) - Add syscon to compatible string - Remove some line breaks for better readability Changes since v1 (part of Vybrid Cortex-M4 support) - Rewrite with irqdomain hierarchy - Implemented as proper irqchip and move to driver/irqchip/ - Doesn't work on Cortex-M4 anymore (NVIC as parent is not yet implemented) Stefan Agner (3): irqchip: vf610-mscm: add support for MSCM interrupt router irqchip: vf610-mscm: dt-bindings: add MSCM bindings ARM: dts: vf610: add Miscellaneous System Control Module (MSCM) .../bindings/arm/freescale/fsl,vf610-mscm.txt | 19 +++ arch/arm/boot/dts/vf500.dtsi | 128 +- arch/arm/boot/dts/vfxxx.dtsi | 42 + arch/arm/mach-imx/Kconfig | 1 + drivers/irqchip/Kconfig| 11 ++ drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-vf610-mscm.c | 186 + 7 files changed, 264 insertions(+), 124 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt create mode 100644 drivers/irqchip/irq-vf610-mscm.c -- 2.2.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 RESEND v3 2/3] irqchip: vf610-mscm: dt-bindings: add MSCM bindings
Add binding documentation for Miscellaneous System Control Module
found in Freescale Vybrid SoC's.
Signed-off-by: Stefan Agner
---
.../bindings/arm/freescale/fsl,vf610-mscm.txt | 19 +++
1 file changed, 19 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt
b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt
new file mode 100644
index 000..e051b88
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt
@@ -0,0 +1,19 @@
+Freescale Vybrid Miscellaneous System Control Module
+
+The MSCM IP contains Access Control and TrustZone Security hardware,
+CPU Configuration registers and Interrupt Router control.
+
+Required properties:
+- compatible : "fsl,vf610-mscm", "syscon"
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Two cells, interrupt number and flags (IRQ type)
+- reg : the register range of the MSCM module
+
+Example:
+ mscm: mscm@40001000 {
+ compatible = "fsl,vf610-mscm", "syscon";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <>;
+ reg = <0x40001000 0x1000>;
+ }
--
2.2.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 RESEND v3 3/3] ARM: dts: vf610: add Miscellaneous System Control Module (MSCM)
Add the Miscellaneous System Control Module (MSCM) to the base
device tree for Vybrid SoC's. This module contains the peripheral
interrupt router, which handles the routing of the interrupts
for the two CPU cores. Almost all peripheral interrupts are
handled by the router, hence we make the MSCM module as default
interrupt parent for the SoC.
In a earlier commit the interrupt nodes were moved out of the
peripheral nodes and specified in the CPU specific vf500.dtsi
device tree. This allowed to use the base device tree vfxxx.dtsi
also for a Cortex-M4 specific device tree, which uses different
interrupt nodes due to the NVIC interrupt controller. However,
since the interrupt parent for peripherals is the MSCM module
independently which CPU the device tree is used for, we can move
the interrupt nodes into the base device tree vfxxx.dtsi again.
Depending on which CPU this base device tree will used with, the
correct parent interrupt controller has to be assigned to the
MSCM node (GIC or NVIC). The driver takes care of the parent
interrupt controller specific needs (interrupt-cells).
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/vf500.dtsi | 128 ++-
arch/arm/boot/dts/vfxxx.dtsi | 42 ++
2 files changed, 46 insertions(+), 124 deletions(-)
diff --git a/arch/arm/boot/dts/vf500.dtsi b/arch/arm/boot/dts/vf500.dtsi
index de67005..f18 100644
--- a/arch/arm/boot/dts/vf500.dtsi
+++ b/arch/arm/boot/dts/vf500.dtsi
@@ -24,14 +24,13 @@
};
soc {
- interrupt-parent = <>;
-
aips-bus@4000 {
intc: interrupt-controller@40002000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
interrupt-controller;
+ interrupt-parent = <>;
reg = <0x40003000 0x1000>,
<0x40002100 0x100>;
};
@@ -40,132 +39,13 @@
compatible = "arm,cortex-a9-global-timer";
reg = <0x40002200 0x20>;
interrupts = ;
+ interrupt-parent = <>;
clocks = < VF610_CLK_PLATFORM_BUS>;
};
};
};
};
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ,
- ;
- interrupt-names = "edma-tx", "edma-err";
-};
-
- {
- interrupts = ,
- ;
- interrupt-names = "edma-tx", "edma-err";
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
-};
-
- {
- interrupts = ;
+ {
+ interrupt-parent = <>;
};
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 505969a..ccdb268 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -47,6 +47,7 @@
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
+ interrupt-parent = <>;
ranges;
aips0: aips-bus@4000 {
@@ -55,6 +56,13 @@
#size-cells = <1>;
ranges;
+ mscm: mscm@40001000 {
+ compatible = "fsl,vf610-mscm", "syscon";
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ reg = <0x40001000 0x1000>;
+ };
+
edma0: dma-controller@40018000 {
#dma-cells = <2>;
compatible = "fsl,vf610-edma";
@@ -62,6 +70,9 @@
<0x40024000 0x1000>,
<0x40025000 0x1000>;
dma-channels = <32>;
+ interrupts = <8 IRQ_TYPE_LEVEL_HIGH>,
+ <9 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names =
Re: [PATCH 1/3] ftrace: Fix updating of filters for shared global_ops filters
(2015/01/15 0:39), Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)"
>
> As the set_ftrace_filter affects both the function tracer as well as the
> function graph tracer, the ops that represent each have a shared
> ftrace_ops_hash structure. This allows both to be updated when the filter
> files are updated.
>
> But if function graph is enabled and the global_ops (function tracing) ops
> is not, then it is possible that the filter could be changed without the
> update happening for the function graph ops. This will cause the changes
> to not take place and may even cause a ftrace_bug to occur as it could mess
> with the trampoline accounting.
>
> The solution is to check if the ops uses the shared global_ops filter and
> if the ops itself is not enabled, to check if there's another ops that is
> enabled and also shares the global_ops filter. In that case, the
> modification still needs to be executed.
>
Looks good to me.
Reviewed-by: Masami Hiramatsu
Thank you,
> Cc: sta...@vger.kernel.org # 3.17+
> Signed-off-by: Steven Rostedt
> ---
> kernel/trace/ftrace.c | 26 +-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 929a733d302e..2b35d0ba578d 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -4008,8 +4008,32 @@ ftrace_match_addr(struct ftrace_hash *hash, unsigned
> long ip, int remove)
> static void ftrace_ops_update_code(struct ftrace_ops *ops,
> struct ftrace_hash *old_hash)
> {
> - if (ops->flags & FTRACE_OPS_FL_ENABLED && ftrace_enabled)
> + struct ftrace_ops *op;
> +
> + if (!ftrace_enabled)
> + return;
> +
> + if (ops->flags & FTRACE_OPS_FL_ENABLED) {
> ftrace_run_modify_code(ops, FTRACE_UPDATE_CALLS, old_hash);
> + return;
> + }
> +
> + /*
> + * If this is the shared global_ops filter, then we need to
> + * check if there is another ops that shares it, is enabled.
> + * If so, we still need to run the modify code.
> + */
> + if (ops->func_hash != _ops.local_hash)
> + return;
> +
> + do_for_each_ftrace_op(op, ftrace_ops_list) {
> + if (op->func_hash == _ops.local_hash &&
> + op->flags & FTRACE_OPS_FL_ENABLED) {
> + ftrace_run_modify_code(op, FTRACE_UPDATE_CALLS,
> old_hash);
> + /* Only need to do this once */
> + return;
> + }
> + } while_for_each_ftrace_op(op);
> }
>
> static int
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 00/13] ltc2952 modernization and new functionality
On Thu, Jan 15, 2015 at 01:52:49AM +0100, Sebastian Reichel wrote: > Thanks for the cleanup, applied: > > http://git.infradead.org/battery-2.6.git/commit/d84ba07c27fafca3cc77b25a1e204383a4b5af91 Thanks for the heads up. Cheers, Frans -- 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 v6 1/4] phy: qcom-ufs: add support for 20nm phy
Hi,
On Sunday 11 January 2015 06:08 PM, Yaniv Gardi wrote:
> This change adds a support for a 20nm qcom-ufs phy that is required in
> platforms that use ufs-qcom controller.
>
> Signed-off-by: Yaniv Gardi
>
> ---
> drivers/phy/Kconfig | 7 +
> drivers/phy/Makefile| 2 +
> drivers/phy/phy-qcom-ufs-i.h| 159
> drivers/phy/phy-qcom-ufs-qmp-20nm.c | 257 +
> drivers/phy/phy-qcom-ufs-qmp-20nm.h | 235
> drivers/phy/phy-qcom-ufs.c | 745
>
> include/linux/phy/phy-qcom-ufs.h| 59 +++
> 7 files changed, 1464 insertions(+)
> create mode 100644 drivers/phy/phy-qcom-ufs-i.h
> create mode 100644 drivers/phy/phy-qcom-ufs-qmp-20nm.c
> create mode 100644 drivers/phy/phy-qcom-ufs-qmp-20nm.h
> create mode 100644 drivers/phy/phy-qcom-ufs.c
> create mode 100644 include/linux/phy/phy-qcom-ufs.h
I think a single header file should be sufficient here.
It would be helpful if you can split this patch further. First add only the
core ufs layer (Include a documentation on how this layer should be used in
Documentation/phy/) and then use it to add the 14nm and 20nm PHYs.
Thanks
Kishon
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index ccad880..26a7623 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -277,4 +277,11 @@ config PHY_STIH41X_USB
> Enable this to support the USB transceiver that is part of
> STMicroelectronics STiH41x SoC series.
>
> +config PHY_QCOM_UFS
> + tristate "Qualcomm UFS PHY driver"
> + depends on OF && ARCH_MSM
> + select GENERIC_PHY
> + help
> + Support for UFS PHY on QCOM chipsets.
> +
> endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index aa74f96..781b2fa 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -34,3 +34,5 @@ obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)+=
> phy-spear1340-miphy.o
> obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
> obj-$(CONFIG_PHY_STIH407_USB)+= phy-stih407-usb.o
> obj-$(CONFIG_PHY_STIH41X_USB)+= phy-stih41x-usb.o
> +obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
> +obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
> diff --git a/drivers/phy/phy-qcom-ufs-i.h b/drivers/phy/phy-qcom-ufs-i.h
> new file mode 100644
> index 000..a175069
> --- /dev/null
> +++ b/drivers/phy/phy-qcom-ufs-i.h
> @@ -0,0 +1,159 @@
> +/*
> + * Copyright (c) 2013-2015, Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#ifndef UFS_QCOM_PHY_I_H_
> +#define UFS_QCOM_PHY_I_H_
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#define readl_poll_timeout(addr, val, cond, sleep_us, timeout_us) \
> +({ \
> + ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
> + might_sleep_if(timeout_us); \
> + for (;;) { \
> + (val) = readl(addr); \
> + if (cond) \
> + break; \
> + if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
> + (val) = readl(addr); \
> + break; \
> + } \
> + if (sleep_us) \
> + usleep_range(DIV_ROUND_UP(sleep_us, 4), sleep_us); \
> + } \
> + (cond) ? 0 : -ETIMEDOUT; \
> +})
> +
> +#define UFS_QCOM_PHY_CAL_ENTRY(reg, val) \
> + { \
> + .reg_offset = reg, \
> + .cfg_value = val, \
> + }
> +
> +#define UFS_QCOM_PHY_NAME_LEN30
> +
> +enum {
> + MASK_SERDES_START = 0x1,
> + MASK_PCS_READY = 0x1,
> +};
> +
> +enum {
> + OFFSET_SERDES_START = 0x0,
> +};
> +
> +struct ufs_qcom_phy_stored_attributes {
> + u32 att;
> + u32 value;
> +};
> +
> +struct ufs_qcom_phy_calibration {
> + u32 reg_offset;
> + u32 cfg_value;
> +};
> +
> +struct ufs_qcom_phy_vreg {
> + const char *name;
> + struct regulator *reg;
> + int max_uA;
> + int min_uV;
> + int max_uV;
> + bool enabled;
> + bool is_always_on;
> +};
> +
> +struct ufs_qcom_phy {
> + struct list_head list;
> + struct device *dev;
> + void __iomem *mmio;
> + void __iomem *dev_ref_clk_ctrl_mmio;
> + struct clk *tx_iface_clk;
> + struct clk *rx_iface_clk;
> + bool is_iface_clk_enabled;
> + struct clk *ref_clk_src;
> + struct clk *ref_clk_parent;
Re: [PATCH v2 1/2] mm/slub: optimize alloc/free fastpath by removing preemption on/off
On Thu, 15 Jan 2015 16:40:32 +0900
Joonsoo Kim wrote:
[...]
>
> I saw roughly 5% win in a fast-path loop over kmem_cache_alloc/free
> in CONFIG_PREEMPT. (14.821 ns -> 14.049 ns)
>
> Below is the result of Christoph's slab_test reported by
> Jesper Dangaard Brouer.
>
[...]
Acked-by: Jesper Dangaard Brouer
> Acked-by: Christoph Lameter
> Tested-by: Jesper Dangaard Brouer
> Signed-off-by: Joonsoo Kim
> ---
> mm/slub.c | 35 +++
> 1 file changed, 23 insertions(+), 12 deletions(-)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index fe376fe..ceee1d7 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -2398,13 +2398,24 @@ redo:
[...]
>*/
> - preempt_disable();
> - c = this_cpu_ptr(s->cpu_slab);
> + do {
> + tid = this_cpu_read(s->cpu_slab->tid);
> + c = this_cpu_ptr(s->cpu_slab);
> + } while (IS_ENABLED(CONFIG_PREEMPT) && unlikely(tid != c->tid));
> +
> + /*
> + * Irqless object alloc/free alogorithm used here depends on sequence
Spelling of algorithm contains a typo ^^
> + * of fetching cpu_slab's data. tid should be fetched before anything
> + * on c to guarantee that object and page associated with previous tid
> + * won't be used with current tid. If we fetch tid first, object and
> + * page could be one associated with next tid and our alloc/free
> + * request will be failed. In this case, we will retry. So, no problem.
> + */
> + barrier();
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sound/oss: use current->state helpers
At Wed, 14 Jan 2015 23:51:30 -0800, Davidlohr Bueso wrote: > > On Thu, 2015-01-15 at 08:33 +0100, Takashi Iwai wrote: > > At Wed, 14 Jan 2015 23:11:43 -0800, > > Davidlohr Bueso wrote: > > > > > > From: Davidlohr Bueso > > > > > > Call __set_current_state() instead of assigning the new state directly. > > > These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments, keeping > > > track of who changed the state. > > > > > > Signed-off-by: Davidlohr Bueso > > > > The author and sign-off have different addresses. Could you align? > > I don't see a problem with that. All my patches are the same. Well, it's a bit unusual. Why do they need to differ? Is the author another Davidlohr? :) If this form is preferred, I'm willing to apply, but I just wonder... Takashi -- 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] ethernet: atheros: Add nss-gmac driver
Hi Arnd, Francois
The nss-gmac driver is for the internal GMAC IP in the Qualcomm IPQ806x
SoC. There are 2 ARM cores and 2 NSS cores inside the IPQ806x SoC. The
main purpose of these NSS cores is to offload the networking stack from
the ARM cores to achieve high performance at routing/ipsec..etc without
exhausting the ARM core CPU cycles. There is another nss-drv driver for
the NSS cores.
The nss-gmac driver is designed to work standalone or with the nss-drv
driver so the switchable data plane overlay was implemented. When it
worked standalone, the data plane is running on the ARM core as a standard
networking driver. The nss-drv driver can take over the data plane and
offload it to the NSS cores. The STMicro stmmac driver does not have this
kind of overlay design so is not suitable for IPQ806x. This is why we
don't based on the stmmac driver
Thanks,
Stephen
>> diff --git a/drivers/net/ethernet/atheros/nss-gmac/LICENSE.txt
>> b/drivers/net/ethernet/atheros/nss-gmac/LICENSE.txt
>> new file mode 100644
>> index 000..806f2e6
>> --- /dev/null
>> +++ b/drivers/net/ethernet/atheros/nss-gmac/LICENSE.txt
>> @@ -0,0 +1,14 @@
>> +Linux Driver for 3504 DWC Ether MAC 10/100/1000 Universal
>> +Linux Driver for 3507 DWC Ether MAC 10/100 Universal
>> +
>> +IMPORTANT: Synopsys Ethernet MAC Linux Software Drivers and
>> documentation (hereinafter, "Software") are unsupported proprietary
>> works of Synopsys, Inc. unless otherwise expressly agreed to in writing
>> between Synopsys and you.
>> +
>> +The Software uses certain Linux kernel functionality and may therefore
>> be subject to the GNU Public License which is available at:
>> +http://www.gnu.org/licenses/gpl.html
>
> It sounds like this one is related to the dwmac driver in
> drivers/net/ethernet/stmicro/stmmac/. Please move the code into
> the same directory and reuse as much as you can.
>
> If this is a completely unrelated part, it should probably go
> into drivers/net/ethernet/designware or drivers/net/ethernet/synopsys.
>
>> +#ifdef CONFIG_OF
>> +#include
>> +#else
>> +#include
>> +#endif
>
> Drop the non-CONFIG_OF part here and elsewhere, we don't support
> separate platform directories any more, and mach-qcom is already
> DT-only.
>
>> +/**
>> + * GMAC registers Map
>> + * For Pci based system address is BARx + gmac_register_base
>> + * For any other system translation is done accordingly
>> + **/
>> +enum gmac_registers {
>> +gmac_config = 0x, /* Mac config Register*/
>> +gmac_frame_filter = 0x0004, /* Mac frame filtering controls */
>> +gmac_hash_high = 0x0008,/* Multi-cast hash table high */
>> +gmac_hash_low = 0x000c, /* Multi-cast hash table low */
>> +gmac_gmii_addr = 0x0010,/* GMII address Register(ext. Phy)*/
>> +gmac_gmii_data = 0x0014,/* GMII data Register(ext. Phy) */
>> +gmac_flow_control = 0x0018, /* Flow control Register */
>> +gmac_vlan = 0x001c, /* VLAN tag Register (IEEE 802.1Q)*/
>> +gmac_version = 0x0020, /* GMAC Core Version Register */
>> +gmac_wakeup_addr = 0x0028, /* GMAC wake-up frame filter adrress
>> + reg*/
>
> This looks a lot like dwmac1000 as well.
>
>> +if (of_property_read_u32(np, "qcom,id", >macid)
>> +|| of_property_read_u32(np, "qcom,emulation",
>> >emulation)
>> +|| of_property_read_u32(np, "qcom,phy_mii_type",
>> >phy_mii_type)
>> +|| of_property_read_u32(np, "qcom,phy_mdio_addr",
>> >phy_mdio_addr)
>> +|| of_property_read_u32(np, "qcom,rgmii_delay",
>> >rgmii_delay)
>> +|| of_property_read_u32(np, "qcom,poll_required",
>> >poll_required)
>> +|| of_property_read_u32(np, "qcom,forced_speed",
>> >forced_speed)
>> +|| of_property_read_u32(np, "qcom,forced_duplex",
>> >forced_duplex)
>> +|| of_property_read_u32(np, "qcom,irq", >irq)
>> +|| of_property_read_u32(np, "qcom,socver", >socver)) {
>
> This is not an acceptable way to pass data from DT, please use the
> standard properties.
>
>> +if (test_bit(__NSS_GMAC_LINKPOLL, >flags)) {
>> +#if (LINUX_VERSION_CODE <= KERNEL_VERSION(3, 8, 0))
>> +gmacdev->phydev = phy_connect(netdev, (const char *)phy_id,
>> + _gmac_adjust_link, 0, phyif);
>> +#else
>> +gmacdev->phydev = phy_connect(netdev, (const char *)phy_id,
>> + _gmac_adjust_link, phyif);
>> +#endif
>
> Drop all LINUX_VERSION_CODE checks
>
>> +if (IS_ERR_OR_NULL(gmacdev->phydev)) {
>> +netdev_dbg(netdev, "PHY %s attach FAIL", phy_id);
>> +ret = -EIO;
>> +goto
Re: [PATCH 2/2] clk: exynos-audss: Fix memory leak on driver unbind or probe failure
On śro, 2015-01-14 at 14:25 -0800, Mike Turquette wrote:
> Quoting Stephen Boyd (2015-01-08 13:23:13)
> > On 01/05/2015 01:52 AM, Krzysztof Kozlowski wrote:
> > > The memory allocated by basic clock divider/gate/mux (struct clk_gate,
> > > clk_divider and clk_mux) was leaking. During driver unbind or probe
> > > failure the driver only unregistered the clocks.
> > >
> > > Use clk_unregister_{gate,divider,mux} to release all resources.
> > >
> > > Signed-off-by: Krzysztof Kozlowski
> > >
> >
> > Reviewed-by: Stephen Boyd
>
> I've applied both patches to clk-next. Krzysztof, let me know if you
> would prefer to take the audss patch through the samsung clock branch
> instead (to include it in a later pull request).
Thanks! I'm fine with applying them to clk-next.
Best regards,
Krzysztof
>
> Regards,
> Mike
>
> >
> > --
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sound/oss: use current->state helpers
On Thu, 2015-01-15 at 09:11 +0100, Takashi Iwai wrote: > Well, it's a bit unusual. Why do they need to differ? Is the author > another Davidlohr? :) If this form is preferred, I'm willing to > apply, but I just wonder... Personal taste, really. Yes I'd prefer you apply as is. Thanks, Davidlohr -- 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 0/3] mmc: Add dynamic frequency scaling
+ Mike, Stephen (Clock maintainers) On 12 January 2015 at 10:23, Krzysztof Kozlowski wrote: > Hi, > > > I would like to hear some comments about idea of scaling MMC clock > frequency. The basic idea is to lower the clock when device is > completely idle or not busy enough. We already have host drivers that implements runtime PM support. Typically that would mean the clock will be gated once the device becomes runtime PM suspended. Why should we decrease the frequency of an already gated clock? I think this boils done to how DVFS transitions can be triggered from the clock drivers, right? Currently the clock framework supports this through clock rate change notifiers. Should we have clock notifiers for clk_prepare|unprepare() as well? I do remember that someone posted patches for that a while ago, but those were rejected. Mike, Stephen - comments? Kind regards Uffe > > The patchset adds MMC card as a devfreq device and uses simple_ondemand > as governor. In idle this gave benefits (less energy consumed during > idle): > 1. Trats2 (Exynos4412): 2.6% > 2. Rinato (Exynos3250): 1% > > but (especially on Rinato) it had impact on performance (probably > because ondemand triggering a little to late). What is interesting > manually changing the clock (without this patchset) gave slightly > bigger benefits. Maybe the devfreq introduces noticeable overhead? > > > Comments are welcomed. Maybe on other platforms this has bigger impact? > > Best regards, > Krzysztof > > > Krzysztof Kozlowski (3): > mmc: Add dynamic frequency scaling > ARM: dts: Specify MSHC realistic clocks and use frequency scaling > ARM: dts: Use frequency scaling for MSHC > > Documentation/devicetree/bindings/mmc/mmc.txt | 2 + > arch/arm/boot/dts/exynos3250-rinato.dts | 1 + > arch/arm/boot/dts/exynos4412-trats2.dts | 4 +- > drivers/mmc/card/block.c | 247 > ++ > drivers/mmc/core/Kconfig | 16 ++ > drivers/mmc/core/core.h | 1 - > drivers/mmc/core/host.c | 2 + > include/linux/mmc/card.h | 8 + > include/linux/mmc/host.h | 3 + > 9 files changed, 282 insertions(+), 2 deletions(-) > > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf bench: fix order of arguments to memcpy_alloc_mem
This was causing the destination instead of the source to be filled. As a result, the source was typically all mapped to one zero page, and hence very cacheable --- tools/perf/bench/mem-memcpy.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/bench/mem-memcpy.c b/tools/perf/bench/mem-memcpy.c index 6c14afe..db1d3a2 100644 --- a/tools/perf/bench/mem-memcpy.c +++ b/tools/perf/bench/mem-memcpy.c @@ -289,7 +289,7 @@ static u64 do_memcpy_cycle(const struct routine *r, size_t len, bool prefault) memcpy_t fn = r->fn.memcpy; int i; -memcpy_alloc_mem(, , len); +memcpy_alloc_mem(, , len); if (prefault) fn(dst, src, len); @@ -312,7 +312,7 @@ static double do_memcpy_gettimeofday(const struct routine *r, size_t len, void *src = NULL, *dst = NULL; int i; -memcpy_alloc_mem(, , len); +memcpy_alloc_mem(, , len); if (prefault) fn(dst, src, len); -- 1.9.1 -- Bruce Merry Senior Science Processing Developer SKA South Africa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix checkpatch warning in drivers/acpi/nvs.c
On Wednesday, January 14, 2015 11:18:52 AM Moritz Fischer wrote: > Hi, > > attached a simple patch fixing a checkpatch warning about > printk(KERN_INFO vs pr_info. Which is not going to be applied unless it fixes a functional problem. Thanks! -- I speak only for myself. Rafael J. Wysocki, 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/
Re: Reminder about patch sent for the file,xsysace.c
Hi, please send the patch for removing that FIXME. Thanks, Michal On 01/09/2015 09:46 PM, nick wrote: > Greetings Michal and others, > I am wondering about the patch I sent at the beginning of last month for > removing the > comment from the function,ace_probe for hard coding the bus width. In > addition I am > wondering whether I should resend this patch or is it in the queue for the > upcoming > rc releases or the 3.20 release. > Thanks, > Nick > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature
Re: [PATCH] sound/oss: use current->state helpers
At Thu, 15 Jan 2015 00:17:25 -0800, Davidlohr Bueso wrote: > > On Thu, 2015-01-15 at 09:11 +0100, Takashi Iwai wrote: > > Well, it's a bit unusual. Why do they need to differ? Is the author > > another Davidlohr? :) If this form is preferred, I'm willing to > > apply, but I just wonder... > > Personal taste, really. Yes I'd prefer you apply as is. OK, applied now. Thanks. Takashi -- 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] Added PIDs for Actisense USB Devices
From: Mark Glover
Signed-off-by: Mark Glover
---
drivers/usb/serial/ftdi_sio.c | 17 +
drivers/usb/serial/ftdi_sio_ids.h | 21 +
2 files changed, 38 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 1ebb351..a118e5b 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -978,6 +978,23 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE_INTERFACE_NUMBER(INFINEON_VID, INFINEON_TRIBOARD_PID, 1) },
/* GE Healthcare devices */
{ USB_DEVICE(GE_HEALTHCARE_VID, GE_HEALTHCARE_NEMO_TRACKER_PID) },
+ /* Active Research (Actisense) devices */
+ { USB_DEVICE(FTDI_VID, ACTISENSE_NDC_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_USG_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_NGT_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_NGW_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AC_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AD_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AE_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AF_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEAGAUGE_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASWITCH_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_NMEA2000_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_ETHERNET_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_WIFI_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_DISPLAY_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_LITE_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_ANALOG_PID) },
{ } /* Terminating entry */
};
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serials/ftdi_sio_ids.h
index e52409c..8ccd1b6 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -1438,3 +1438,24 @@
*/
#define GE_HEALTHCARE_VID 0x1901
#define GE_HEALTHCARE_NEMO_TRACKER_PID 0x0015
+
+/*
+ * Active Research (Actisense) devices
+ */
+#define ACTISENSE_NDC_PID 0xD9A8 /* NDC USB Serial Adapter */
+#define ACTISENSE_USG_PID 0xD9A9 /* USG USB Serial Adapter */
+#define ACTISENSE_NGT_PID 0xD9AA /* NGT NMEA2000 Interface */
+#define ACTISENSE_NGW_PID 0xD9AB /* NGW NMEA2000 Gateway */
+#define ACTISENSE_D9AC_PID 0xD9AC /* Actisense Reserved */
+#define ACTISENSE_D9AD_PID 0xD9AD /* Actisense Reserved */
+#define ACTISENSE_D9AE_PID 0xD9AE /* Actisense Reserved */
+#define ACTISENSE_D9AF_PID 0xD9AF /* Actisense Reserved */
+#define CHETCO_SEAGAUGE_PID0xA548 /* SeaGauge USB Adapter */
+#define CHETCO_SEASWITCH_PID 0xA549 /* SeaSwitch USB Adapter */
+#define CHETCO_SEASMART_NMEA2000_PID 0xA54A /* SeaSmart NMEA2000 Gateway */
+#define CHETCO_SEASMART_ETHERNET_PID 0xA54B /* SeaSmart Ethernet Gateway */
+#define CHETCO_SEASMART_WIFI_PID 0xA5AC /* SeaSmart Wifi Gateway */
+#define CHETCO_SEASMART_DISPLAY_PID0xA5AD /* SeaSmart NMEA2000 Display */
+#define CHETCO_SEASMART_LITE_PID 0xA5AE /* SeaSmart Lite USB Adapter */
+#define CHETCO_SEASMART_ANALOG_PID 0xA5AF /* SeaSmart Analog Adapter */
+
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm v2] vmscan: move reclaim_state handling to shrink_slab
current->reclaim_state is only used to count the number of slab pages
reclaimed by shrink_slab(). So instead of initializing it before we are
going to call try_to_free_pages() or shrink_zone(), let's set in
directly in shrink_slab().
Note that after this patch try_to_free_mem_cgroup_pages() will count not
only reclaimed user pages, but also slab pages, which is expected,
because it can reclaim kmem from kmem-active sub cgroups.
Signed-off-by: Vladimir Davydov
---
Changes in v2:
- do not change shrink_slab() return value to the number of reclaimed
slab pages, because it can make drop_slab() abort beforehand (Andrew)
mm/page_alloc.c |4
mm/vmscan.c | 43 +--
2 files changed, 17 insertions(+), 30 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e1963ea0684a..f528e4ba91b5 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2448,7 +2448,6 @@ static int
__perform_reclaim(gfp_t gfp_mask, unsigned int order, struct zonelist
*zonelist,
nodemask_t *nodemask)
{
- struct reclaim_state reclaim_state;
int progress;
cond_resched();
@@ -2457,12 +2456,9 @@ __perform_reclaim(gfp_t gfp_mask, unsigned int order,
struct zonelist *zonelist,
cpuset_memory_pressure_bump();
current->flags |= PF_MEMALLOC;
lockdep_set_current_reclaim_state(gfp_mask);
- reclaim_state.reclaimed_slab = 0;
- current->reclaim_state = _state;
progress = try_to_free_pages(zonelist, order, gfp_mask, nodemask);
- current->reclaim_state = NULL;
lockdep_clear_current_reclaim_state();
current->flags &= ~PF_MEMALLOC;
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 16f3e45742d6..26fdcc6c747d 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -367,13 +367,18 @@ static unsigned long do_shrink_slab(struct shrink_control
*shrinkctl,
* the ->seeks setting of the shrink function, which indicates the
* cost to recreate an object relative to that of an LRU page.
*
- * Returns the number of reclaimed slab objects.
+ * Returns the number of reclaimed slab objects. The number of reclaimed slab
+ * pages is added to *@ret_nr_reclaimed.
*/
static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
struct mem_cgroup *memcg,
unsigned long nr_scanned,
-unsigned long nr_eligible)
+unsigned long nr_eligible,
+unsigned long *ret_nr_reclaimed)
{
+ struct reclaim_state reclaim_state = {
+ .reclaimed_slab = 0,
+ };
struct shrinker *shrinker;
unsigned long freed = 0;
@@ -394,6 +399,8 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
goto out;
}
+ current->reclaim_state = _state;
+
list_for_each_entry(shrinker, _list, list) {
struct shrink_control sc = {
.gfp_mask = gfp_mask,
@@ -410,6 +417,9 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
freed += do_shrink_slab(, shrinker, nr_scanned, nr_eligible);
}
+ current->reclaim_state = NULL;
+ *ret_nr_reclaimed += reclaim_state.reclaimed_slab;
+
up_read(_rwsem);
out:
cond_resched();
@@ -419,6 +429,7 @@ out:
void drop_slab_node(int nid)
{
unsigned long freed;
+ unsigned long nr_reclaimed = 0;
do {
struct mem_cgroup *memcg = NULL;
@@ -426,9 +437,9 @@ void drop_slab_node(int nid)
freed = 0;
do {
freed += shrink_slab(GFP_KERNEL, nid, memcg,
-1000, 1000);
+1000, 1000, _reclaimed);
} while ((memcg = mem_cgroup_iter(NULL, memcg, NULL)) != NULL);
- } while (freed > 10);
+ } while (freed);
}
void drop_slab(void)
@@ -2339,7 +2350,6 @@ static inline bool should_continue_reclaim(struct zone
*zone,
static bool shrink_zone(struct zone *zone, struct scan_control *sc,
bool is_classzone)
{
- struct reclaim_state *reclaim_state = current->reclaim_state;
unsigned long nr_reclaimed, nr_scanned;
bool reclaimable = false;
@@ -2371,7 +2381,7 @@ static bool shrink_zone(struct zone *zone, struct
scan_control *sc,
if (memcg && is_classzone)
shrink_slab(sc->gfp_mask, zone_to_nid(zone),
memcg, sc->nr_scanned - scanned,
- lru_pages);
+ lru_pages, >nr_reclaimed);
/*
* Direct reclaim and kswapd have to scan all memory
@@ -2398,12 +2408,7 @@ static bool shrink_zone(struct zone *zone, struct
scan_control *sc,
Re: [PATCH v4 2/3] i2c: iproc: Add Broadcom iProc I2C Driver
Hello,
On Wed, Jan 14, 2015 at 02:23:32PM -0800, Ray Jui wrote:
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
some of them are not needed. I tested on amd64 and efm32 and could drop
linux/device.h, linux/sched.h, linux/clk.h. (BTW, I wonder that you
don't need clk handling.)
> +#define TIM_CFG_OFFSET 0x04
> +#define TIME_CFG_MODE_400_SHIFT 31
Is the register name and the bit name prefix really different or is this
a typo?
> +static int __wait_for_bus_idle(struct bcm_iproc_i2c_dev *iproc_i2c)
A bcm_iproc_i2c prefix would be nice here.
> +static int bcm_iproc_i2c_format_addr(struct bcm_iproc_i2c_dev *iproc_i2c,
> + struct i2c_msg *msg, u8 *addr)
> +{
> +
> + if (msg->flags & I2C_M_TEN) {
> + dev_err(iproc_i2c->device, "no support for 10-bit address\n");
> + return -EINVAL;
> + }
> +
> + *addr = (msg->addr << 1);
You can also drop the parentheses.
> + switch (val) {
> + case M_CMD_STATUS_SUCCESS:
> + return 0;
> +
> + case M_CMD_STATUS_LOST_ARB:
> + dev_err(iproc_i2c->device, "lost bus arbitration\n");
> + return -EREMOTEIO;
> +
> + case M_CMD_STATUS_NACK_ADDR:
> + dev_err(iproc_i2c->device, "NAK addr:0x%02x\n",
> + iproc_i2c->msg->addr);
> + return -EREMOTEIO;
> +
> + case M_CMD_STATUS_NACK_DATA:
> + dev_err(iproc_i2c->device, "NAK data\n");
> + return -EREMOTEIO;
> +
> + case M_CMD_STATUS_TIMEOUT:
> + dev_err(iproc_i2c->device, "bus timeout\n");
> + return -ETIMEDOUT;
> +
> + default:
> + dev_err(iproc_i2c->device, "unknown error code=%d\n", val);
> + return -EREMOTEIO;
> + }
> +
> + return -EREMOTEIO;
This is not reached.
> +}
> +
> +static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
> + struct i2c_msg *msg)
> +{
> + int ret, i;
> + u8 addr;
> + u32 val;
> + unsigned long time_left = msecs_to_jiffies(I2C_TIMEOUT_MESC);
> +
> + if (msg->len < 1 || msg->len > M_TX_RX_FIFO_SIZE - 1) {
Is the < 1 a hardware or a software limitation? That means your driver
doesn't support I2C_SMBUS_QUICK which is used for example by i2cdetect.
> + dev_err(iproc_i2c->device,
> + "supported data length is 1 - %u bytes\n",
> + M_TX_RX_FIFO_SIZE - 1);
> + return -EINVAL;
> + }
> +
> + iproc_i2c->msg = msg;
Can it happen that iproc_i2c->msg still holds an uncompleted message
here or is this serialized by the core? Wolfram? Either here something
like:
if (iproc_i2c->msg)
return -EBUSY;
and
iproc_i2c->msg = NULL;
when a transfer is completed is needed, or the respective code can be
dropped from other drivers (e.g. i2c-efm32).
On the other hand .msg is only used in bcm_iproc_i2c_check_status() to
give a diagnostic message. Maybe you can drop .msg and instead give it
as an additional parameter to bcm_iproc_i2c_check_status().
> + ret = __wait_for_bus_idle(iproc_i2c);
> + if (ret)
> + return ret;
I would still prefer to have something like:
if (bcm_iproc_i2c_bus_busy())
return -EBUSY;
instead of a tight loop here.
> + ret = bcm_iproc_i2c_format_addr(iproc_i2c, msg, );
> + if (ret)
> + return ret;
> +
> + /* load slave address into the TX FIFO */
> + writel(addr, iproc_i2c->base + M_TX_OFFSET);
> +
> + /* for a write transaction, load data into the TX FIFO */
> + if (!(msg->flags & I2C_M_RD)) {
> + for (i = 0; i < msg->len; i++) {
> + val = msg->buf[i];
> +
> + /* mark the last byte */
> + if (i == msg->len - 1)
> + val |= 1 << M_TX_WR_STATUS_SHIFT;
What happens if you don't mark this last byte? Could this be used to
support transfers bigger than the fifo size?
> + /*
> + * Enable the "start busy" interrupt, which will be triggered after
> + * the transaction is done, i.e., the internal start_busy bit
s/\.,/./ I think
> + * transitions from 1 to 0
s/$/./
> + */
> + writel(1 << IE_M_START_BUSY_SHIFT, iproc_i2c->base + IE_OFFSET);
> +
> + /*
> + * Now we can activate the transfer. For a read operation, specify the
> + * number of bytes to read
s/$/./
> + */
> + val = 1 << M_CMD_START_BUSY_SHIFT;
> + if (msg->flags & I2C_M_RD) {
> + val |= (M_CMD_PROTOCOL_BLK_RD << M_CMD_PROTOCOL_SHIFT) |
> +(msg->len << M_CMD_RD_CNT_SHIFT);
> + } else {
> + val |= (M_CMD_PROTOCOL_BLK_WR << M_CMD_PROTOCOL_SHIFT);
> + }
> + writel(val, iproc_i2c->base + M_CMD_OFFSET);
> +
> + time_left =
Re: [PATCH v2 1/8] thermal: Provide stub for thermal_of_cooling_device_register() function
Hi Eduardo,
> On Wed, Jan 14, 2015 at 04:01:06PM +0100, Lukasz Majewski wrote:
> > Hi Eduardo,
> >
> > > On Fri, Jan 02, 2015 at 02:54:28PM -0400, Eduardo Valentin wrote:
> > > > On Mon, Dec 22, 2014 at 05:27:41PM +0100, Lukasz Majewski wrote:
> > > > > Odroid U3 fan can work without being registered as OF cooling
> > > > > device (with CONFIG_THERMAL_OF disabled).
> > > > > In this situation it can be controlled via PWM entry at
> > > > > /sys/class/hwmon/hwmon0/pwm1.
> > > > >
> > > > > Therefore, the thermal_of_cooling_device_register() function
> > > > > needs a stub to allow clean compilation.
> > > > >
> > > > > Signed-off-by: Lukasz Majewski
> > > >
> > > > Acked-by: Eduardo Valentin
> > >
> > > Sorry, too fast,
> > >
> > > This is actually
> > > Nacked-by: Eduardo Valentin
> > >
> > > :-)
> > >
> > > I get this error:
> > > drivers/thermal/thermal_core.c:1210:1: error: redefinition of
> > > ‘thermal_of_cooling_device_register’
> > > thermal_of_cooling_device_register(struct device_node *np,
> > > ^
> > > In file included from drivers/thermal/thermal_core.c:34:0:
> > > include/linux/thermal.h:321:1: note: previous definition of
> > > ‘thermal_of_cooling_device_register’ was here
> > >thermal_of_cooling_device_register(struct device_node *np,
> > > ^
> > >
> > >
> > > We provide the function in thermal core even if CONFIG_THERMAL_OF
> > > is not set.
> >
> > Unfortunately the PWM fan subsystem can work perfectly fine without
> > CONFIG_THERMAL.
> >
>
> Now I understand what you are trying to do.
>
> > I think that it would be enough to make something like this in
> > the ./include/linux/thermal.h:
> >
> > #ifdef CONFIG_THERMAL
> Well, I think it should be the opposite here:
>
> #ifndef CONFIG_THERMAL
>
> that is, if no config thermal, then you provide the stub not the other
> way around.
This seems like a better solution :-).
Thanks.
>
> > static inline struct thermal_cooling_device *
> > thermal_of_cooling_device_register(struct
> > device_node *np, char *type, void *devdata,
> >const struct
> > thermal_cooling_device_ops *ops) {
> > return NULL;
> > }
> > #else
> > [ already present declaration of
> > thermal_of_cooling_device_register() ]
> > #endif /* CONFIG_THERMAL */
>
>
> >
> >
> >
> > > >
> > > > > ---
> > > > > Changes for v2:
> > > > > - None
> > > > > ---
> > > > > include/linux/thermal.h | 14 +++---
> > > > > 1 file changed, 11 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> > > > > index 2de3d9e..871123c 100644
> > > > > --- a/include/linux/thermal.h
> > > > > +++ b/include/linux/thermal.h
> > > > > @@ -328,6 +328,10 @@ thermal_zone_of_sensor_register(struct
> > > > > device *dev, int id, void *data, const struct
> > > > > thermal_zone_of_device_ops *ops); void
> > > > > thermal_zone_of_sensor_unregister(struct device *dev, struct
> > > > > thermal_zone_device *tz); +struct thermal_cooling_device *
> > > > > +thermal_of_cooling_device_register(struct device_node *np,
> > > > > +char *type, void *devdata,
> > > > > +const struct
> > > > > thermal_cooling_device_ops *); #else
> > > > > static inline struct thermal_zone_device *
> > > > > thermal_zone_of_sensor_register(struct device *dev, int id,
> > > > > void *data, @@ -342,6 +346,13 @@ void
> > > > > thermal_zone_of_sensor_unregister(struct device *dev, {
> > > > > }
> > > > >
> > > > > +static inline struct thermal_cooling_device *
> > > > > +thermal_of_cooling_device_register(struct device_node *np,
> > > > > +char *type, void *devdata,
> > > > > +const struct
> > > > > thermal_cooling_device_ops *ops) +{
> > > > > + return NULL;
> > > > > +}
> > > > > #endif
> > > > > struct thermal_zone_device
> > > > > *thermal_zone_device_register(const char *, int, int, void *,
> > > > > struct thermal_zone_device_ops *, @@ -357,9 +368,6 @@ void
> > > > > thermal_zone_device_update(struct thermal_zone_device *);
> > > > > struct thermal_cooling_device
> > > > > *thermal_cooling_device_register(char *, void *, const struct
> > > > > thermal_cooling_device_ops *); -struct thermal_cooling_device
> > > > > * -thermal_of_cooling_device_register(struct device_node *np,
> > > > > char *, void *,
> > > > > -const struct
> > > > > thermal_cooling_device_ops *); void
> > > > > thermal_cooling_device_unregister(struct
> > > > > thermal_cooling_device *); struct thermal_zone_device
> > > > > *thermal_zone_get_zone_by_name(const char *name); int
> > > > > thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned
> > > > > long *temp); -- 2.0.0.rc2
> > > > >
> > >
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> > Lukasz Majewski
> >
> > Samsung R Institute Poland
[PATCH 3/3] ARM: dts: exynos4412-trats2: Switch max77686 regulators to GPIO control
Remove fixed regulators (duplicating what max77686 provides) and
add GPIO enable control to max77686 regulators.
This gives the system full control over those regulators. Previously
the state of such regulators was a mixture of what max77686 driver set
over I2C and what regulator-fixed set through GPIO.
Removal of 'regulator-always-on' from CAM_ISP_CORE_1.2V (buck9) allows
disabling it when it is not used. Previously this regulator was always
enabled because its enable state is a OR of:
- ENB9 GPIO (turned always on by regulator-fixed),
- BUCK9EN field in BUCK9CTRL register (off by max77686 through I2C).
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4412-trats2.dts | 25 +
1 file changed, 5 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index ef05139506e6..8611c07c2e41 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -58,15 +58,6 @@
#address-cells = <1>;
#size-cells = <0>;
- vemmc_reg: regulator-0 {
- compatible = "regulator-fixed";
- regulator-name = "VMEM_VDD_2.8V";
- regulator-min-microvolt = <280>;
- regulator-max-microvolt = <280>;
- gpio = < 2 0>;
- enable-active-high;
- };
-
cam_io_reg: voltage-regulator-1 {
compatible = "regulator-fixed";
regulator-name = "CAM_SENSOR_A";
@@ -94,16 +85,6 @@
enable-active-high;
};
- cam_isp_core_reg: voltage-regulator-4 {
- compatible = "regulator-fixed";
- regulator-name = "CAM_ISP_CORE_1.2V_EN";
- regulator-min-microvolt = <120>;
- regulator-max-microvolt = <120>;
- gpio = < 3 0>;
- enable-active-high;
- regulator-always-on;
- };
-
ps_als_reg: voltage-regulator-5 {
compatible = "regulator-fixed";
regulator-name = "LED_A_3.0V";
@@ -405,6 +386,7 @@
regulator-name = "VTF_2.8V";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
+ maxim,ena-gpios = < 0
GPIO_ACTIVE_HIGH>;
};
ldo22_reg: ldo22 {
@@ -412,6 +394,7 @@
regulator-name = "VMEM_VDD_2.8V";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
+ maxim,ena-gpios = < 2
GPIO_ACTIVE_HIGH>;
};
ldo23_reg: ldo23 {
@@ -518,6 +501,7 @@
regulator-name = "VMEM_VDDF_3.0V";
regulator-min-microvolt = <285>;
regulator-max-microvolt = <285>;
+ maxim,ena-gpios = < 2
GPIO_ACTIVE_HIGH>;
};
buck9_reg: buck9 {
@@ -525,6 +509,7 @@
regulator-name = "CAM_ISP_CORE_1.2V";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <120>;
+ maxim,ena-gpios = < 3
GPIO_ACTIVE_HIGH>;
};
};
};
@@ -587,7 +572,7 @@
broken-cd;
non-removable;
card-detect-delay = <200>;
- vmmc-supply = <_reg>;
+ vmmc-supply = <_reg>;
clock-frequency = <4>;
samsung,dw-mshc-ciu-div = <0>;
samsung,dw-mshc-sdr-timing = <2 3>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] ARM: dts: Regulator changes and fuel gauge for exynos4412-trats2
Hi Kukjin, I grouped into one patchset already posted patches for Trats2 board: 1. Fuel gauge: https://lkml.org/lkml/2015/1/7/167 2. Suspend configuration for max77686 regulators: https://lkml.org/lkml/2014/10/29/262 3. GPIO control for max77686 regulators: https://lkml.org/lkml/2015/1/5/230 The necessary changes in max77686 regulator driver were already applied by Mark Brown. Best regards, Krzysztof Krzysztof Kozlowski (3): ARM: dts: exynos4412-trats2: Add Maxim 77693 fuel gauge node ARM: dts: exynos4412-trats2: Add suspend configuration for max77686 regulators ARM: dts: exynos4412-trats: Switch max77686 regulators to GPIO control arch/arm/boot/dts/exynos4412-trats2.dts | 115 ++-- 1 file changed, 65 insertions(+), 50 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ARM: dts: exynos4412-trats2: Add Maxim 77693 fuel gauge node
Add node for fuel gauge present in Maxim 77693 PMIC. This allows control
over battery charging state on Trats2 board.
The fuel gauge is compatible with max17042 battery driver (Maxim
17042/17047/17050). Although datasheet rev 2.2 for MAX77693 describes
fuel gauge as Maxim 17042-like, the chip on Trats2 board identifies
itself as Maxim 17047-like.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4412-trats2.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 29231b452643..595ad4ba6977 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -15,6 +15,7 @@
/dts-v1/;
#include "exynos4412.dtsi"
#include
+#include
/ {
model = "Samsung Trats 2 based on Exynos4412";
@@ -24,6 +25,7 @@
i2c9 = _ak8975;
i2c10 = _cm36651;
i2c11 = _max77693;
+ i2c12 = _max77693_fuel;
};
memory {
@@ -552,6 +554,22 @@
};
};
+ i2c_max77693_fuel: i2c-gpio-3 {
+ compatible = "i2c-gpio";
+ gpios = < 5 GPIO_ACTIVE_HIGH>, < 4 GPIO_ACTIVE_HIGH>;
+ i2c-gpio,delay-us = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ max77693-fuel-gauge@36 {
+ compatible = "maxim,max17047";
+ interrupt-parent = <>;
+ interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ reg = <0x36>;
+ };
+ };
+
mmc@1255 {
num-slots = <1>;
broken-cd;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ARM: dts: exynos4412-trats2: Add suspend configuration for max77686 regulators
Add suspend to RAM configuration for max77686 regulators. Some LDOs and
bucks are disabled. This reduces energy consumption during S2R,
approximately from 17 mA to 9 mA.
Additionally remove old and not supported bindings:
- regulator-mem-off
- regulator-mem-idle
- regulator-mem-on
The max77686 driver does not parse them and they are not documented
anywere.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Chanwoo Choi
---
Previously this was part of [1] patchset. There were no changes in this
patch since last version (v6) of that patchset.
[1] https://lkml.org/lkml/2014/10/29/261
---
arch/arm/boot/dts/exynos4412-trats2.dts | 72 +++--
1 file changed, 42 insertions(+), 30 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 595ad4ba6977..ef05139506e6 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -227,7 +227,6 @@
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
regulator-always-on;
- regulator-mem-on;
};
ldo2_reg: ldo2 {
@@ -236,7 +235,9 @@
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
regulator-always-on;
- regulator-mem-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
};
ldo3_reg: ldo3 {
@@ -245,7 +246,6 @@
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-always-on;
- regulator-mem-on;
};
ldo4_reg: ldo4 {
@@ -254,7 +254,6 @@
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
regulator-always-on;
- regulator-mem-on;
};
ldo5_reg: ldo5 {
@@ -263,7 +262,6 @@
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-always-on;
- regulator-mem-on;
};
ldo6_reg: ldo6 {
@@ -272,7 +270,9 @@
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
regulator-always-on;
- regulator-mem-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
};
ldo7_reg: ldo7 {
@@ -281,7 +281,9 @@
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
regulator-always-on;
- regulator-mem-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
};
ldo8_reg: ldo8 {
@@ -289,7 +291,9 @@
regulator-name = "VMIPI_1.0V";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
- regulator-mem-off;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
ldo9_reg: ldo9 {
@@ -297,7 +301,6 @@
regulator-name = "CAM_ISP_MIPI_1.2V";
regulator-min-microvolt = <120>;
regulator-max-microvolt =
Re: linux-next: manual merge of the renesas tree with the arm-soc tree
On Thu, Jan 15, 2015 at 1:38 AM, Stephen Rothwell wrote:
> Today's linux-next merge of the renesas tree got a conflict in
> arch/arm/boot/dts/Makefile between commit cb612390e546 ("ARM: dts: Only
> build dtb if associated Arch and/or SoC is enabled") from the arm-soc
> tree and commits 9ccba8abd0a7 ("ARM: shmobile: kzm9g: Build DTS for
> Multiplatform") and 93c9f0228a3d ("ARM: shmobile: kzm9g-reference:
> Remove board C code and DT file") from the renesas tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Your resolution is correct.
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 http://www.tux.org/lkml/
Re: [PATCH v4 3/3] ARM: dts: add I2C device nodes for Broadcom Cygnus
Hello,
On Wed, Jan 14, 2015 at 02:23:33PM -0800, Ray Jui wrote:
> Add I2C device nodes and its properties in bcm-cygnus.dtsi but keep
> them disabled there. Individual I2C devices can be enabled in board
> specific dts file when I2C slave devices are enabled in the future
s/$/./
>
> Signed-off-by: Ray Jui
> Reviewed-by: Scott Branden
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
> b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 5126f9e..f7d6c1d 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -70,6 +70,26 @@
> };
> };
>
> + i2c0: i2c@18008000 {
> + compatible = "brcm,iproc-i2c";
in patch 2 you wrote the driver is for a family of SoCs, right? Then I'd
make this:
compatible = "brcm,$mysoc-iproc-i2c", "brcm,iproc-i2c";
(or maybe s/$mysoc-iproc-i2c/$mysoc-i2c/).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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] kvm: Fix CR3_PCID_INVD type on 32-bit
From: Borislav Petkov arch/x86/kvm/emulate.c: In function ‘check_cr_write’: arch/x86/kvm/emulate.c:3552:4: warning: left shift count >= width of type rsvd = CR3_L_MODE_RESERVED_BITS & ~CR3_PCID_INVD; happens because sizeof(UL) on 32-bit is 4 bytes but we shift it 63 bits to the left. Signed-off-by: Borislav Petkov --- arch/x86/include/asm/kvm_host.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index d89c6b828c96..a8d07a060136 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -51,7 +51,7 @@ | X86_CR0_NW | X86_CR0_CD | X86_CR0_PG)) #define CR3_L_MODE_RESERVED_BITS 0xFF00ULL -#define CR3_PCID_INVD (1UL << 63) +#define CR3_PCID_INVD BIT_64(63) #define CR4_RESERVED_BITS \ (~(unsigned long)(X86_CR4_VME | X86_CR4_PVI | X86_CR4_TSD | X86_CR4_DE\ | X86_CR4_PSE | X86_CR4_PAE | X86_CR4_MCE \ -- 2.2.0.33.gc18b867 -- 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] perf bench: fix order of arguments to memcpy_alloc_mem
On Thu, Jan 15, 2015 at 10:15:34AM +0200, Bruce Merry wrote: > This was causing the destination instead of the source to be filled. > As a result, the source was typically all mapped to one zero page, > and hence very cacheable Almost right ;-) Please have a look at Documentation/SubmittingPatches We require at least a Signed-off-by: tag in order to process patches. 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 v3 3/4] ata: libahci: Allow using multiple regulators
Hi,
On 13-01-15 15:22, Gregory CLEMENT wrote:
The current implementation of the libahci allows using multiple PHYs
but not multiple regulators. This patch adds the support of multiple
regulators. Until now it was mandatory to have a PHY under a subnode,
now a port subnode can contain either a regulator or a PHY (or both).
In order to be able to asociate a port with a regulator the port are
now a platform device in the device tree case.
There was only one driver which used directly the regulator field of
the ahci_host_priv structure. To preserve the bisectability the change
in the ahci_imx driver was done in the same patch.
Signed-off-by: Gregory CLEMENT
Looks good, still needs one more (small) revision though, see comments
inline.
---
drivers/ata/ahci.h | 2 +-
drivers/ata/ahci_imx.c | 14 +--
drivers/ata/libahci_platform.c | 227 +
include/linux/ahci_platform.h | 2 +
4 files changed, 170 insertions(+), 75 deletions(-)
diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index 40f0e34f17af..275358ae0b3f 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -333,7 +333,7 @@ struct ahci_host_priv {
u32 em_msg_type;/* EM message type */
boolgot_runtime_pm; /* Did we do pm_runtime_get? */
struct clk *clks[AHCI_MAX_CLKS]; /* Optional */
- struct regulator*target_pwr;/* Optional */
+ struct regulator**target_pwrs; /* Optional */
/*
* If platform uses PHYs. There is a 1:1 relation between the port
number and
* the PHY position in this array.
diff --git a/drivers/ata/ahci_imx.c b/drivers/ata/ahci_imx.c
index 35d51c59a370..41632e57d46f 100644
--- a/drivers/ata/ahci_imx.c
+++ b/drivers/ata/ahci_imx.c
@@ -221,11 +221,9 @@ static int imx_sata_enable(struct ahci_host_priv *hpriv)
if (imxpriv->no_device)
return 0;
- if (hpriv->target_pwr) {
- ret = regulator_enable(hpriv->target_pwr);
- if (ret)
- return ret;
- }
+ ret = ahci_platform_enable_regulators(hpriv);
+ if (ret)
+ return ret;
ret = clk_prepare_enable(imxpriv->sata_ref_clk);
if (ret < 0)
@@ -270,8 +268,7 @@ static int imx_sata_enable(struct ahci_host_priv *hpriv)
disable_clk:
clk_disable_unprepare(imxpriv->sata_ref_clk);
disable_regulator:
- if (hpriv->target_pwr)
- regulator_disable(hpriv->target_pwr);
+ ahci_platform_disable_regulators(hpriv);
return ret;
}
@@ -291,8 +288,7 @@ static void imx_sata_disable(struct ahci_host_priv *hpriv)
clk_disable_unprepare(imxpriv->sata_ref_clk);
- if (hpriv->target_pwr)
- regulator_disable(hpriv->target_pwr);
+ ahci_platform_disable_regulators(hpriv);
}
static void ahci_imx_error_handler(struct ata_port *ap)
diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index a147aaadca85..1db968ef6ff8 100644
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "ahci.h"
static void ahci_host_stop(struct ata_host *host);
@@ -138,6 +139,59 @@ void ahci_platform_disable_clks(struct ahci_host_priv
*hpriv)
EXPORT_SYMBOL_GPL(ahci_platform_disable_clks);
/**
+ * ahci_platform_enable_regulators - Enable regulators
+ * @hpriv: host private area to store config values
+ *
+ * This function enables all the regulators found in
+ * hpriv->target_pwrs, if any. If a regulator fails to be enabled, it
+ * disables all the regulators already enabled in reverse order and
+ * returns an error.
+ *
+ * RETURNS:
+ * 0 on success otherwise a negative error code
+ */
+int ahci_platform_enable_regulators(struct ahci_host_priv *hpriv)
+{
+ int rc, i;
+
+ for (i = 0; i < hpriv->nports; i++) {
+ if (!hpriv->target_pwrs[i])
+ continue;
+
+ rc = regulator_enable(hpriv->target_pwrs[i]);
+ if (rc)
+ goto disable_target_pwrs;
+ }
+
+ return 0;
+
+disable_target_pwrs:
+ while (--i >= 0)
+ if (hpriv->target_pwrs[i])
+ regulator_disable(hpriv->target_pwrs[i]);
+
+ return rc;
+}
+EXPORT_SYMBOL_GPL(ahci_platform_enable_regulators);
+
+/**
+ * ahci_platform_disable_regulators - Disable regulators
+ * @hpriv: host private area to store config values
+ *
+ * This function disables all regulators found in hpriv->target_pwrs.
+ */
+void ahci_platform_disable_regulators(struct ahci_host_priv *hpriv)
+{
+ int i;
+
+ for (i = 0; i < hpriv->nports; i++) {
+ if (!hpriv->target_pwrs[i])
+ continue;
+ regulator_disable(hpriv->target_pwrs[i]);
+ }
+}
Re: [PATCH v4 00/13] Add ACPI _DSD and unified device properties support
On Wednesday, January 14, 2015 10:42:23 AM David Woodhouse wrote:
>
> --=-3dIl43yXcWwu/nzOqQWw
> Content-Type: multipart/mixed; boundary="=-ca0AFM5hvqL+pJIndiHh"
>
>
> --=-ca0AFM5hvqL+pJIndiHh
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> I'm looking again at updating of_serial to work with ACPI properties.=20
>
> Specifically, I want to support a serial port with a non-standard baud
> rate, something like this:
>
> Device(COM1) {
> Name(_HID, EisaId("PNP0501"))
> Name(_CID, EisaId("PRP0001"))
> Name(_DSD, Package() {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () {"compatible", Package () {"ns16550a"}},
> Package () {"clock-frequency", 2457600},
> }
> })
> ...
> }
>
> Firstly, the of_serial driver doesn't even get *invoked* unless I do
> this:
>
> diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
> index 0d08373..eb1201a 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -2083,6 +2086,8 @@ static int acpi_add_single_object(struct acpi_device =
> **child,
> ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Added %s [%s] parent %s\n",
> dev_name(>dev), (char *) buffer.pointer,
> device->parent ? dev_name(>parent->dev) : "(null)"));
> + if (device->data.of_compatible)
> + acpi_create_platform_device(device);
> kfree(buffer.pointer);
> *child =3D device;
> return 0;
>
> Now it doesn't work because it uses of_match_device() to look the device
> up and find the corresponding *data* for that entry in its match table.
> And without CONFIG_OF, I don't *have* of_match_device().
>
> We've talked about the fact that the platform bus probe function doesn't
> pass you the match ID. Is that something we could potentially fix now
> that things are a little more unified?
We can do that in my view.
> Or do we expect drivers still to have to use something like
> of_match_id() to do the lookup again for themselves... and in that case
> should we make of_match_id() available or produce a new
> device_match_id() that they are expected to switch to?
So far we've been targeting drivers that already have of_match_id() rather
than ones that want to use the unified interface from the start and not
necessarily with CONFIG_OF set. That looks like an overlooked use case to me
to be honest.
--
I speak only for myself.
Rafael J. Wysocki, 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] Documentation: gpio: fix bindings document
Signed-off-by: Masahiro Yamada --- Documentation/devicetree/bindings/gpio/gpio.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index b9bd1d6..f7a158d 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -69,7 +69,8 @@ GPIO pin number, and GPIO flags as accepted by the "qe_pio_e" gpio-controller. -- A gpio-specifier should contain a flag indicating the GPIO polarity; active- -high or active-low. If it does, the follow best practices should be followed: +high or active-low. If it does, the following best practices should be +followed: The gpio-specifier's polarity flag should represent the physical level at the GPIO controller that achieves (or represents, for inputs) a logically asserted @@ -147,7 +148,7 @@ contains information structures as follows: numeric-gpio-range ::= named-gpio-range ::= '<0 0>' - gpio-phandle : phandle to pin controller node. + pinctrl-phandle : phandle to pin controller node gpio-base : Base GPIO ID in the GPIO controller pinctrl-base : Base pinctrl pin ID in the pin controller count : The number of GPIOs/pins in this range -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/6] ARM: at91: pm: use the mmio-sram pool to access SRAM
Hi Alexandre
> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
> On
> Behalf Of Alexandre Belloni
> Sent: Tuesday, January 13, 2015 5:24 AM
> To: Ferre, Nicolas
> Cc: Boris Brezillon; Alexandre Belloni; Jean-Christophe Plagniol-Villard;
> linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: [PATCH 2/6] ARM: at91: pm: use the mmio-sram pool to access SRAM
>
> Now that the SRAM is part of a genpool, use it to allocate memory to use for
> the
> slowclock implementation.
>
> Signed-off-by: Alexandre Belloni
> ---
> arch/arm/mach-at91/Kconfig | 1 +
> arch/arm/mach-at91/pm.c| 46
> +-
> 2 files changed, 46 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig index
> cec0fb5d621a..b7dcef50db23 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -178,6 +178,7 @@ comment "AT91 Feature Selections"
>
> config AT91_SLOW_CLOCK
> bool "Suspend-to-RAM disables main oscillator"
> + select SRAM
Can we move it under config ARCH_AT91 or other place?
It may be used for other purposes, more than pm. I thinks
> depends on SUSPEND
> help
> Select this if you want Suspend-to-RAM to save the most power diff
> --git
> a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c index
> 79aa793d1f00..515791edcc60 100644
> --- a/arch/arm/mach-at91/pm.c
> +++ b/arch/arm/mach-at91/pm.c
> @@ -14,10 +14,12 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -222,10 +224,52 @@ void at91_pm_set_standby(void (*at91_standby)(void))
> }
> }
>
> +#ifdef CONFIG_AT91_SLOW_CLOCK
> +static void __init at91_pm_sram_init(void) {
> + struct gen_pool *sram_pool;
> + phys_addr_t sram_pbase;
> + unsigned long sram_base;
> + struct device_node *node;
> + struct platform_device *pdev;
> +
> + node = of_find_compatible_node(NULL, NULL, "mmio-sram");
> + if (!node) {
> + pr_warn("%s: failed to find sram node!\n", __func__);
> + return;
> + }
> +
> + pdev = of_find_device_by_node(node);
> + if (!pdev) {
> + pr_warn("%s: failed to find sram device!\n", __func__);
> + goto put_node;
> + }
> +
> + sram_pool = dev_get_gen_pool(>dev);
> + if (!sram_pool) {
> + pr_warn("%s: sram pool unavailable!\n", __func__);
> + goto put_node;
> + }
> +
> + sram_base = gen_pool_alloc(sram_pool, at91_slow_clock_sz);
> + if (!sram_base) {
> + pr_warn("%s: unable to alloc ocram!\n", __func__);
> + goto put_node;
> + }
> +
> + sram_pbase = gen_pool_virt_to_phys(sram_pool, sram_base);
> + slow_clock = __arm_ioremap_exec(sram_pbase, at91_slow_clock_sz,
> +false);
> +
> +put_node:
> + of_node_put(node);
> +}
> +#endif
> +
> +
> static int __init at91_pm_init(void)
> {
> #ifdef CONFIG_AT91_SLOW_CLOCK
> - slow_clock = (void *) (AT91_IO_VIRT_BASE - at91_slow_clock_sz);
> + at91_pm_sram_init();
> #endif
>
> pr_info("AT91: Power Management%s\n", (slow_clock ? " (with slow clock
> mode)" : ""));
> --
> 2.1.0
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Best Regards,
Wenyou Yang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/9] hwmon: dts: Doc: Add DTS doc to explain how to use PWM FAN as a cooling device
On Wed, 2015-01-14 at 14:56 +0100, Lukasz Majewski wrote: > Hi Sjoerd, > Could you review v2 of this patch series? > > http://www.spinics.net/lists/devicetree/msg63159.html I skimmed it yesterday, I'll try to find some time to send you my review comments later in the week/start of next. Do you happen to have a git branch with these patches in? That would make it convenient for me to give your patches a spin on my XU3 -- Sjoerd Simons Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
[GIT PULL] MMC fixes for v.3.19, take 3
Hi Linus, Here is one more mmc fix for 3.19, take 3. I expect this to be the last fix for mmc for 3.19. Do note that it's based on your master branch from yesterday and not on an rc which is what I do normally. If you don't like it like this, I can re-base it next week. Details are as usual found in the signed tag. Kind regards Ulf Hansson The following changes since commit 188c901941efd43cbf21e8f4f9e9a276536b989c: Merge branch 'leds-fixes-for-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds (2015-01-14 12:22:56 +1300) are available in the git repository at: git://git.linaro.org/people/ulf.hansson/mmc.git tags/mmc-v3.19-4 for you to fetch changes up to 3cbc6123a93dc91b99b58f7ea37d267fe93e1cad: mmc: sdhci: Set SDHCI_POWER_ON with external vmmc (2015-01-14 09:47:19 +0100) MMC host: - sdhci: Fix regulator regression for Qualcomm and Nvidia boards Tim Kryger (1): mmc: sdhci: Set SDHCI_POWER_ON with external vmmc drivers/mmc/host/sdhci.c | 6 ++ 1 file changed, 6 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] ppc/kvm: Replace ACCESS_ONCE with READ_ONCE
ACCESS_ONCE does not work reliably on non-scalar types. For
example gcc 4.6 and 4.7 might remove the volatile tag for such
accesses during the SRA (scalar replacement of aggregates) step
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145)
Change the ppc/kvm code to replace ACCESS_ONCE with READ_ONCE.
Signed-off-by: Christian Borntraeger
---
arch/powerpc/kvm/book3s_hv_rm_xics.c | 8
arch/powerpc/kvm/book3s_xics.c | 16
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_rm_xics.c
b/arch/powerpc/kvm/book3s_hv_rm_xics.c
index 7b066f6..7c22997 100644
--- a/arch/powerpc/kvm/book3s_hv_rm_xics.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_xics.c
@@ -152,7 +152,7 @@ static void icp_rm_down_cppr(struct kvmppc_xics *xics,
struct kvmppc_icp *icp,
* in virtual mode.
*/
do {
- old_state = new_state = ACCESS_ONCE(icp->state);
+ old_state = new_state = READ_ONCE(icp->state);
/* Down_CPPR */
new_state.cppr = new_cppr;
@@ -211,7 +211,7 @@ unsigned long kvmppc_rm_h_xirr(struct kvm_vcpu *vcpu)
* pending priority
*/
do {
- old_state = new_state = ACCESS_ONCE(icp->state);
+ old_state = new_state = READ_ONCE(icp->state);
xirr = old_state.xisr | (((u32)old_state.cppr) << 24);
if (!old_state.xisr)
@@ -277,7 +277,7 @@ int kvmppc_rm_h_ipi(struct kvm_vcpu *vcpu, unsigned long
server,
* whenever the MFRR is made less favored.
*/
do {
- old_state = new_state = ACCESS_ONCE(icp->state);
+ old_state = new_state = READ_ONCE(icp->state);
/* Set_MFRR */
new_state.mfrr = mfrr;
@@ -352,7 +352,7 @@ int kvmppc_rm_h_cppr(struct kvm_vcpu *vcpu, unsigned long
cppr)
icp_rm_clr_vcpu_irq(icp->vcpu);
do {
- old_state = new_state = ACCESS_ONCE(icp->state);
+ old_state = new_state = READ_ONCE(icp->state);
reject = 0;
new_state.cppr = cppr;
diff --git a/arch/powerpc/kvm/book3s_xics.c b/arch/powerpc/kvm/book3s_xics.c
index 807351f..a4a8d9f 100644
--- a/arch/powerpc/kvm/book3s_xics.c
+++ b/arch/powerpc/kvm/book3s_xics.c
@@ -327,7 +327,7 @@ static bool icp_try_to_deliver(struct kvmppc_icp *icp, u32
irq, u8 priority,
icp->server_num);
do {
- old_state = new_state = ACCESS_ONCE(icp->state);
+ old_state = new_state = READ_ONCE(icp->state);
*reject = 0;
@@ -512,7 +512,7 @@ static void icp_down_cppr(struct kvmppc_xics *xics, struct
kvmppc_icp *icp,
* in virtual mode.
*/
do {
- old_state = new_state = ACCESS_ONCE(icp->state);
+ old_state = new_state = READ_ONCE(icp->state);
/* Down_CPPR */
new_state.cppr = new_cppr;
@@ -567,7 +567,7 @@ static noinline unsigned long kvmppc_h_xirr(struct kvm_vcpu
*vcpu)
* pending priority
*/
do {
- old_state = new_state = ACCESS_ONCE(icp->state);
+ old_state = new_state = READ_ONCE(icp->state);
xirr = old_state.xisr | (((u32)old_state.cppr) << 24);
if (!old_state.xisr)
@@ -634,7 +634,7 @@ static noinline int kvmppc_h_ipi(struct kvm_vcpu *vcpu,
unsigned long server,
* whenever the MFRR is made less favored.
*/
do {
- old_state = new_state = ACCESS_ONCE(icp->state);
+ old_state = new_state = READ_ONCE(icp->state);
/* Set_MFRR */
new_state.mfrr = mfrr;
@@ -679,7 +679,7 @@ static int kvmppc_h_ipoll(struct kvm_vcpu *vcpu, unsigned
long server)
if (!icp)
return H_PARAMETER;
}
- state = ACCESS_ONCE(icp->state);
+ state = READ_ONCE(icp->state);
kvmppc_set_gpr(vcpu, 4, ((u32)state.cppr << 24) | state.xisr);
kvmppc_set_gpr(vcpu, 5, state.mfrr);
return H_SUCCESS;
@@ -721,7 +721,7 @@ static noinline void kvmppc_h_cppr(struct kvm_vcpu *vcpu,
unsigned long cppr)
BOOK3S_INTERRUPT_EXTERNAL_LEVEL);
do {
- old_state = new_state = ACCESS_ONCE(icp->state);
+ old_state = new_state = READ_ONCE(icp->state);
reject = 0;
new_state.cppr = cppr;
@@ -885,7 +885,7 @@ static int xics_debug_show(struct seq_file *m, void
*private)
if (!icp)
continue;
- state.raw = ACCESS_ONCE(icp->state.raw);
+ state.raw = READ_ONCE(icp->state.raw);
seq_printf(m, "cpu server %#lx XIRR:%#x PPRI:%#x CPPR:%#x
MFRR:%#x OUT:%d NR:%d\n",
icp->server_num, state.xisr,
state.pending_pri, state.cppr,
[PATCH 0/8] current ACCESS_ONCE patch queue
Folks, fyi, this is my current patch queue for the next merge window. It does contain a patch that will disallow ACCESS_ONCE on non-scalar types. The tree is part of linux-next and can be found at git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux.git linux-next Christian Borntraeger (7): ppc/kvm: Replace ACCESS_ONCE with READ_ONCE ppc/hugetlbfs: Replace ACCESS_ONCE with READ_ONCE x86/xen/p2m: Replace ACCESS_ONCE with READ_ONCE x86/spinlock: Leftover conversion ACCESS_ONCE->READ_ONCE mm/gup: Replace ACCESS_ONCE with READ_ONCE kernel: tighten rules for ACCESS ONCE kernel: Fix sparse warning for ACCESS_ONCE Guenter Roeck (1): next: sh: Fix compile error arch/powerpc/kvm/book3s_hv_rm_xics.c | 8 arch/powerpc/kvm/book3s_xics.c | 16 arch/powerpc/mm/hugetlbpage.c| 4 ++-- arch/sh/mm/gup.c | 2 +- arch/x86/include/asm/spinlock.h | 2 +- arch/x86/xen/p2m.c | 2 +- include/linux/compiler.h | 21 - mm/gup.c | 2 +- 8 files changed, 34 insertions(+), 23 deletions(-) -- 1.9.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 5/8] mm/gup: Replace ACCESS_ONCE with READ_ONCE
ACCESS_ONCE does not work reliably on non-scalar types. For
example gcc 4.6 and 4.7 might remove the volatile tag for such
accesses during the SRA (scalar replacement of aggregates) step
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145)
Fixup gup_pmd_range.
Signed-off-by: Christian Borntraeger
---
mm/gup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/gup.c b/mm/gup.c
index a900759..bed30efa 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -926,7 +926,7 @@ static int gup_pmd_range(pud_t pud, unsigned long addr,
unsigned long end,
pmdp = pmd_offset(, addr);
do {
- pmd_t pmd = ACCESS_ONCE(*pmdp);
+ pmd_t pmd = READ_ONCE(*pmdp);
next = pmd_addr_end(addr, end);
if (pmd_none(pmd) || pmd_trans_splitting(pmd))
--
1.9.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 8/8] kernel: Fix sparse warning for ACCESS_ONCE
Commit a91ed664749c ("kernel: tighten rules for ACCESS ONCE") results in
sparse warnings like "Using plain integer as NULL pointer" - Let's add a
type cast to the dummy assignment.
To avoid warnings lik "sparse: warning: cast to restricted __hc32" we also
use __force on that cast.
Fixes: a91ed664749c ("kernel: tighten rules for ACCESS ONCE")
Signed-off-by: Christian Borntraeger
---
include/linux/compiler.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 5e186bf..7bebf05 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -461,7 +461,7 @@ static __always_inline void __assign_once_size(volatile
void *p, void *res, int
* If possible use READ_ONCE/ASSIGN_ONCE instead.
*/
#define __ACCESS_ONCE(x) ({ \
-__maybe_unused typeof(x) __var = 0; \
+__maybe_unused typeof(x) __var = (__force typeof(x)) 0; \
(volatile typeof(x) *)&(x); })
#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
--
1.9.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 6/8] kernel: tighten rules for ACCESS ONCE
Now that all non-scalar users of ACCESS_ONCE have been converted
to READ_ONCE or ASSIGN once, lets tighten ACCESS_ONCE to only
work on scalar types.
This variant was proposed by Alexei Starovoitov.
Signed-off-by: Christian Borntraeger
Reviewed-by: Paul E. McKenney
---
include/linux/compiler.h | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index a1c81f8..5e186bf 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -447,12 +447,23 @@ static __always_inline void __assign_once_size(volatile
void *p, void *res, int
* to make the compiler aware of ordering is to put the two invocations of
* ACCESS_ONCE() in different C statements.
*
- * This macro does absolutely -nothing- to prevent the CPU from reordering,
- * merging, or refetching absolutely anything at any time. Its main intended
- * use is to mediate communication between process-level code and irq/NMI
- * handlers, all running on the same CPU.
+ * ACCESS_ONCE will only work on scalar types. For union types, ACCESS_ONCE
+ * on a union member will work as long as the size of the member matches the
+ * size of the union and the size is smaller than word size.
+ *
+ * The major use cases of ACCESS_ONCE used to be (1) Mediating communication
+ * between process-level code and irq/NMI handlers, all running on the same
CPU,
+ * and (2) Ensuring that the compiler does not fold, spindle, or otherwise
+ * mutilate accesses that either do not require ordering or that interact
+ * with an explicit memory barrier or atomic instruction that provides the
+ * required ordering.
+ *
+ * If possible use READ_ONCE/ASSIGN_ONCE instead.
*/
-#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
+#define __ACCESS_ONCE(x) ({ \
+__maybe_unused typeof(x) __var = 0; \
+ (volatile typeof(x) *)&(x); })
+#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
/* Ignore/forbid kprobes attach on very low level functions marked by this
attribute: */
#ifdef CONFIG_KPROBES
--
1.9.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/
Re: [RFC PATCH] gpio: support for GPIO forwarding
On Thursday, January 08, 2015 10:25:10 AM Heikki Krogerus wrote: > On Thu, Dec 18, 2014 at 10:23:18AM +0200, Heikki Krogerus wrote: > > This makes it possible to assign GPIOs at runtime. The > > motivation for it is because of need to forward GPIOs from > > one device to an other. That feature may be useful for > > example with some mfd devices, but initially it is needed > > because on some Intel Braswell based ACPI platforms the GPIO > > resources controlling signals of the USB PHY are given to > > the controller device object for whatever reason, so the > > driver of that controller needs be able to pass them to the > > PHY device somehow. > > > > So basically this is meant to allow patching of bad (bad > > from Linux kernels point of view) hardware descriptions > > provided by system fw in the drivers. > > > > Signed-off-by: Heikki Krogerus > > --- > > > > Hi, > > > > I'm sending this first as a RFC in case you guys have some better > > idea how to solve our problem. I actually already have couple > > platforms where the GPIO resources are given to the "wrong" device > > objects now. > > > > Originally we were thinking about simply handling our problem with > > hacks to the PHY drivers, basically also checking if the parent has > > GPIOs. That would only work if the controller is always the parent, > > which it's not, but even if it was, it would be too risky. The PHY > > drivers don't know which controller they are attached to, so what is > > to say that the GPIOs aren't really attached to the controller. > > > > So the safest way to handle our problem is to deal with it in quirks > > in the controller drivers. Solving it by bouncing the GPIOs did not > > feel ideal there doesn't seem to be any other way. The API is copied > > from clkdev (clk_register_clkdev). In the end it's really only one > > function for adding the lookups and one for removing them. > > > > The way it's implemented is by modifying the current style of handling > > the lookups a little bit. The per device lookup table is basically > > reverted back to the single linked-list format since it seems that > > these lookups may have to be assigned from several sources. > > > > Thanks, > > Gentle ping on this. Please CC patches involving ACPI in *any* *way* way to linux-a...@vger.kernel.org. Thanks! -- I speak only for myself. Rafael J. Wysocki, 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 3/8] x86/xen/p2m: Replace ACCESS_ONCE with READ_ONCE
ACCESS_ONCE does not work reliably on non-scalar types. For
example gcc 4.6 and 4.7 might remove the volatile tag for such
accesses during the SRA (scalar replacement of aggregates) step
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145)
Change the p2m code to replace ACCESS_ONCE with READ_ONCE.
Signed-off-by: Christian Borntraeger
---
arch/x86/xen/p2m.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index edbc7a6..cb71016 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -554,7 +554,7 @@ static bool alloc_p2m(unsigned long pfn)
mid_mfn = NULL;
}
- p2m_pfn = pte_pfn(ACCESS_ONCE(*ptep));
+ p2m_pfn = pte_pfn(READ_ONCE(*ptep));
if (p2m_pfn == PFN_DOWN(__pa(p2m_identity)) ||
p2m_pfn == PFN_DOWN(__pa(p2m_missing))) {
/* p2m leaf page is missing */
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] ppc/hugetlbfs: Replace ACCESS_ONCE with READ_ONCE
ACCESS_ONCE does not work reliably on non-scalar types. For
example gcc 4.6 and 4.7 might remove the volatile tag for such
accesses during the SRA (scalar replacement of aggregates) step
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145)
Change the ppc/hugetlbfs code to replace ACCESS_ONCE with READ_ONCE.
Signed-off-by: Christian Borntraeger
---
arch/powerpc/mm/hugetlbpage.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 5ff4e07..620d0ec 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -978,7 +978,7 @@ pte_t *find_linux_pte_or_hugepte(pgd_t *pgdir, unsigned
long ea, unsigned *shift
*/
pdshift = PUD_SHIFT;
pudp = pud_offset(, ea);
- pud = ACCESS_ONCE(*pudp);
+ pud = READ_ONCE(*pudp);
if (pud_none(pud))
return NULL;
@@ -990,7 +990,7 @@ pte_t *find_linux_pte_or_hugepte(pgd_t *pgdir, unsigned
long ea, unsigned *shift
else {
pdshift = PMD_SHIFT;
pmdp = pmd_offset(, ea);
- pmd = ACCESS_ONCE(*pmdp);
+ pmd = READ_ONCE(*pmdp);
/*
* A hugepage collapse is captured by pmd_none, because
* it mark the pmd none and do a hpte invalidate.
--
1.9.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 7/8] next: sh: Fix compile error
From: Guenter Roeck
Commit a91ed664749c ("kernel: tighten rules for ACCESS ONCE") results in a
compile failure for sh builds with CONFIG_X2TLB enabled.
arch/sh/mm/gup.c: In function 'gup_get_pte':
arch/sh/mm/gup.c:20:2: error: invalid initializer
make[1]: *** [arch/sh/mm/gup.o] Error 1
Replace ACCESS_ONCE with READ_ONCE to fix the problem.
Fixes: a91ed664749c ("kernel: tighten rules for ACCESS ONCE")
Cc: Paul E. McKenney
Cc: Christian Borntraeger
Signed-off-by: Guenter Roeck
Reviewed-by: Paul E. McKenney
Signed-off-by: Christian Borntraeger
---
arch/sh/mm/gup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sh/mm/gup.c b/arch/sh/mm/gup.c
index 37458f3..e113bb4 100644
--- a/arch/sh/mm/gup.c
+++ b/arch/sh/mm/gup.c
@@ -17,7 +17,7 @@
static inline pte_t gup_get_pte(pte_t *ptep)
{
#ifndef CONFIG_X2TLB
- return ACCESS_ONCE(*ptep);
+ return READ_ONCE(*ptep);
#else
/*
* With get_user_pages_fast, we walk down the pagetables without
--
1.9.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 4/8] x86/spinlock: Leftover conversion ACCESS_ONCE->READ_ONCE
commit 78bff1c8684f ("x86/ticketlock: Fix spin_unlock_wait() livelock")
introduced another ACCESS_ONCE case in x86 spinlock.h.
Change that as well.
Signed-off-by: Christian Borntraeger
Cc: Oleg Nesterov
---
arch/x86/include/asm/spinlock.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index 625660f..9264f0f 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -186,7 +186,7 @@ static inline void arch_spin_unlock_wait(arch_spinlock_t
*lock)
__ticket_t head = ACCESS_ONCE(lock->tickets.head);
for (;;) {
- struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets);
+ struct __raw_tickets tmp = READ_ONCE(lock->tickets);
/*
* We need to check "unlocked" in a loop, tmp.head == head
* can be false positive because of overflow.
--
1.9.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/
Re: [PATCH] Use dwfl_report_elf() instead of offline
On Wed, Jan 14, 2015 at 02:10:45PM -0800, Sukadev Bhattiprolu wrote: > > From 8e6fb4c58d0d9f4798c191d840e32084b1217cc3 Mon Sep 17 00:00:00 2001 > From: Sukadev Bhattiprolu > Date: Fri, 21 Nov 2014 20:33:53 -0500 > Subject: [PATCH 1/1] Use dwfl_report_elf() instead of offline. > > dwfl_report_offline() works only when libraries are prelinked. > > Replace dwfl_report_offline() with dwfl_report_elf() so we correctly > extract debug info even from libraries that are not prelinked. > > Reported-by: Jiri Olsa hi, this is related to the powerpc issue I was just testing right? looks like this patch is different from what I was testing.. thanks, jirka -- 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-nics] [PATCHv4 net] i40e: Implement ndo_gso_check()
On Wed, 2015-01-14 at 18:24 -0800, Jesse Gross wrote:
> On Fri, Dec 26, 2014 at 3:58 PM, Jesse Gross wrote:
> > On Fri, Dec 5, 2014 at 2:12 PM, Jeff Kirsher
> > wrote:
> >> On Fri, 2014-12-05 at 10:41 -0800, Joe Stringer wrote:
> >>> ndo_gso_check() was recently introduced to allow NICs to report the
> >>> offloading support that they have on a per-skb basis. Add an
> >>> implementation for this driver which checks for IPIP, GRE, UDP
> >>> tunnels.
> >>>
> >>> Signed-off-by: Joe Stringer
> >>> ---
> >>> v4: Simplify the check to just do tunnel header length.
> >>> Fix #define style issue.
> >>> v3: Drop IPIP and GRE (no driver support even though hw supports it).
> >>> Check for UDP outer protocol for UDP tunnels.
> >>> v2: Expand to include IP in IP and IPv4/IPv6 inside GRE/UDP tunnels.
> >>> Add MAX_INNER_LENGTH (as 80).
> >>> ---
> >>> drivers/net/ethernet/intel/i40e/i40e_main.c | 12
> >>> 1 file changed, 12 insertions(+)
> >>
> >> Thanks Joe, I will update the patch in my queue with your latest
> >> version.
> >
> > Jeff, as a heads-up, this patch and the corresponding one for fm10k
> > will no longer apply now that the ndo has changed. This was changed by
> > 5f35227e ("net: Generalize ndo_gso_check to ndo_features_check"). The
> > update needed is trivial and is just due to the change in the function
> > signature but I'm not sure where you are in the testing process with
> > this.
>
> Jeff - just wanted to check if you had seen this.
Yeah, I have the updated patch in my queue. I was hoping to get this
patch pushed later this week. It did not make the series of i40e
patches I am preparing to send out in the next couple of hours, but
should be in the next series or the series following the next. Holidays
put a damper on things unfortunately.
signature.asc
Description: This is a digitally signed message part
Re: [RFC PATCH] gpio: support for GPIO forwarding
On Wednesday, January 14, 2015 08:32:12 AM Darren Hart wrote: > > On 1/14/15 4:58 AM, Linus Walleij wrote: > > On Thu, Dec 18, 2014 at 9:23 AM, Heikki Krogerus > > wrote: > > > >> This makes it possible to assign GPIOs at runtime. The > >> motivation for it is because of need to forward GPIOs from > >> one device to an other. That feature may be useful for > >> example with some mfd devices, but initially it is needed > > +Samuel Ortiz for his thoughts on applicability to MFD. > > >> because on some Intel Braswell based ACPI platforms the GPIO > >> resources controlling signals of the USB PHY are given to > >> the controller device object for whatever reason, so the > >> driver of that controller needs be able to pass them to the > >> PHY device somehow. > >> > >> So basically this is meant to allow patching of bad (bad > >> from Linux kernels point of view) hardware descriptions > >> provided by system fw in the drivers. > >> > >> Signed-off-by: Heikki Krogerus > >> --- > >> > >> Hi, > >> > >> I'm sending this first as a RFC in case you guys have some better > >> idea how to solve our problem. I actually already have couple > >> platforms where the GPIO resources are given to the "wrong" device > >> objects now. > >> > >> Originally we were thinking about simply handling our problem with > >> hacks to the PHY drivers, basically also checking if the parent has > >> GPIOs. That would only work if the controller is always the parent, > >> which it's not, but even if it was, it would be too risky. The PHY > >> drivers don't know which controller they are attached to, so what is > >> to say that the GPIOs aren't really attached to the controller. > >> > >> So the safest way to handle our problem is to deal with it in quirks > >> in the controller drivers. Solving it by bouncing the GPIOs did not > >> feel ideal there doesn't seem to be any other way. The API is copied > >> from clkdev (clk_register_clkdev). In the end it's really only one > >> function for adding the lookups and one for removing them. > >> > >> The way it's implemented is by modifying the current style of handling > >> the lookups a little bit. The per device lookup table is basically > >> reverted back to the single linked-list format since it seems that > >> these lookups may have to be assigned from several sources. > > > > Oh ain't that great. > > > > So now we start patching around the kernel because the ACPI > > tables are erroneous for GPIOs. I'd like some feedback from > > Rafael &| Darren on this patch, i.e. if you two think this is a good > > way of accounting for bad GPIO descriptions in ACPI tables then > > ACK this patch. > > > > I guess the other option would be to fix up the ACPI DSDT > > itself to put resources right, correct? Is this not possible? > > This is my gut reaction as well. Pretty much agreed. > Heikki, why can't we correct the firmware tables? That needs to be made clear > before we start adding hacks to the kernel. We need to start working in that direction really. Fixing problems in ACPI tables via kernel code is not going to scale sufficiently IMO. > You said, "Bad for Linux", why is this not a problem for other operating > systems? Good question. :-) -- I speak only for myself. Rafael J. Wysocki, 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] ASoC: sirf: fix platform_no_drv_owner.cocci warnings
sound/soc/sirf/sirf-atlas7-cs42xx8.c:192:3-8: No need to set .owner here. The
core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
CC: Yibo Cai
Signed-off-by: Fengguang Wu
---
sirf-atlas7-cs42xx8.c |1 -
1 file changed, 1 deletion(-)
--- a/sound/soc/sirf/sirf-atlas7-cs42xx8.c
+++ b/sound/soc/sirf/sirf-atlas7-cs42xx8.c
@@ -189,7 +189,6 @@ MODULE_DEVICE_TABLE(of, sirf_hdmi_card_o
static struct platform_driver sirf_hdmi_card_driver = {
.driver = {
.name = "sirf-hdmi-card",
- .owner = THIS_MODULE,
.pm = _soc_pm_ops,
.of_match_table = sirf_hdmi_card_of_match,
},
--
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 12/14] x86: perf: intel_pt: Intel PT PMU driver
On Wed, Jan 14, 2015 at 02:18:21PM +0200, Alexander Shishkin wrote:
> +static __init int pt_init(void)
> +{
> + pt_pmu.pmu.attr_groups = pt_attr_groups;
> + pt_pmu.pmu.task_ctx_nr = perf_hw_context;
I just noticed this one, how can this ever work? We want the PT thing to
always get programmed, right? -- because we disallow creating more than
1?
Which reminds me; does that exclusive thing you did not allow you to
create one cpu wide and one per task (they're separate contexts) events?
At which point we're not schedulable at all.
By sticking it on the HW context list it can end up not being programed
because its stuck after a bunch of hardware events that don't all fit on
the PMU.
Would not the SW list be more appropriate; the SW list is a list of
events that's guaranteed to be schedulable.
> + pt_pmu.pmu.event_init = pt_event_init;
> + pt_pmu.pmu.add = pt_event_add;
> + pt_pmu.pmu.del = pt_event_del;
> + pt_pmu.pmu.start= pt_event_start;
> + pt_pmu.pmu.stop = pt_event_stop;
> + pt_pmu.pmu.read = pt_event_read;
> + pt_pmu.pmu.setup_aux= pt_buffer_setup_aux;
> + pt_pmu.pmu.free_aux = pt_buffer_free_aux;
> + ret = perf_pmu_register(_pmu.pmu, "intel_pt", -1);
> +
> + return ret;
> +}
--
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 1/5] irqchip: add dumb demultiplexer implementation
On Wed, 14 Jan 2015, Rob Herring wrote: > On Wed, Jan 14, 2015 at 4:36 AM, Thomas Gleixner wrote: > > All attempts to work around that have resulted in horrible bandaids so > > far. That's why I guided Boris to implement this dummy demultiplexing > > mechanism. It solves the problem at hand nicely without adding nasty > > hackarounds into the suspend/resume code and inflicting platform > > knowledge on multi-platform device drivers. > > This change will break on old kernels with a new dtb. Would you be > happy if a BIOS update required a new kernel? Fixing this for any > platform requires a dtb update which may not be possible on some > platforms. I don't have a problem with this breakage for 1 platform > and the at91 guys may not care, but we'd ultimately be changing how > all shared irqs are specified for all DT. Maybe we decide that this is > how we want to describe things, but that needs much wider discussion > and agreement. We do not change shared interrupts in any way. We provide an alternative mechanism for braindead hardware. And if the at91 folks are fine with the DT change, then it's their decision. Nothing forces this on everyone. > > If you have a proper solution for the problem at hand which > > > >- avoids the demux dummy > > > >- works straight forward with suspend/resume/wakeup > > > >- does not add horrible new APIs > > > >- does not add conditionals to the interrupt hotpath > > > >- does not inflict platform knowledge about interrupt chip details > > on drivers > > > > then I'm happy to take it. > > > > But as long as you can't come up with anything sane, the demux dummy > > is the best solution for this problem we've seen so far. > > What if during suspend you move all actions w/o IRQF_NO_SUSPEND to a > suspended action list? This would leave only the actions with > IRQF_NO_SUSPEND set in the active action list. The cost would be a > pointer in irq_desc and moving the actions during suspend and resume. That's exactly what we want NOT. Because it prevents us to do proper sanity checks for IRQF_NO_SUSPEND. We've been there and I rejected it for that very reason. > There are probably ways to do this demux irqchip without a DT change. What's the problem with a DT change for a single platform, if the maintainers are willing to take it and deal with the fallout? And in case of AT91 the new kernel will simply work with the old DT and just emit the same warning vs. the IRQF_NO_SUSPEND mismatch. Older kernels won't work with a new DT, but that's about it. Aside of that, I'm quite amused about your DT update worries. DTs break with every kernel version on very popular platforms in very weird and subtle ways. Thanks, tglx -- 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: sirf: fix platform_no_drv_owner.cocci warnings
2015-01-15 17:05 GMT+08:00 kbuild test robot :
> sound/soc/sirf/sirf-atlas7-cs42xx8.c:192:3-8: No need to set .owner here. The
> core will do it.
>
> Remove .owner field if calls are used which set it automatically
>
> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
>
> CC: Yibo Cai
> Signed-off-by: Fengguang Wu
applied to my tree. thanks, fengguang.
this patch doesn't apply to alsa tree as previous patches are not ready.
> ---
>
> sirf-atlas7-cs42xx8.c |1 -
> 1 file changed, 1 deletion(-)
>
> --- a/sound/soc/sirf/sirf-atlas7-cs42xx8.c
> +++ b/sound/soc/sirf/sirf-atlas7-cs42xx8.c
> @@ -189,7 +189,6 @@ MODULE_DEVICE_TABLE(of, sirf_hdmi_card_o
> static struct platform_driver sirf_hdmi_card_driver = {
> .driver = {
> .name = "sirf-hdmi-card",
> - .owner = THIS_MODULE,
> .pm = _soc_pm_ops,
> .of_match_table = sirf_hdmi_card_of_match,
> },
-barry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] ARM: at91: pm: use the mmio-sram pool to access SRAM
Hi, Thank you for your review. On 15/01/2015 at 08:53:54 +, Yang, Wenyou wrote : > > config AT91_SLOW_CLOCK > > bool "Suspend-to-RAM disables main oscillator" > > + select SRAM > Can we move it under config ARCH_AT91 or other place? > > It may be used for other purposes, more than pm. I thinks > I believe it is better if every SRAM user selects SRAM so that when you don't have any of those, it is not automatically selected and it reduces the kernel size. Regards, -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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 V4 0/2] i2c-designware: Add Intel Baytrail pmic i2c bus support
V4: - Added bus lock to i2c_dw_init() as suggested by Jarrko Nikula . Addresses infrequent hang that was seen occuring during probe. - Added label in i2c_dw_xfer() to bypass unnecessary lock release when acquire fails. Suggested by Mika. - Changed make to build driver as composite addition to i2c-designware-platform. Driver can be module or built-in following the platform driver selection. Tested as both. - Added EPROBE_DEFER return to baytrail definition of i2c_dw_eval_lock() to defer probe if iosf_mbi driver (required for acquring bus lock) is not available. V3: - Split lock support and driver into separate patches - Change module build to bool. Platforms running without this driver cannot perform critical functions such as charging. Furthermore attempts by other drivers to access the i2c bus without a lock will hang the platform. - Replaced has_hw_lock flag with acquire/release function pointers. - Replaced acquire/release ifdef code with single i2c_dw_eval_lock_support() test for cleaner (if still undesirable) compile time scalability. Future Intel platforms will however continue to use the Baytrail driver. V2: - Moved semaphore detection out of dw platform driver - Replaced function pointers with defined acquire/release functions in dw core. This helps eliminate the ifdefery in the dw platform driver. - Use new has_hw_lock flag to check if the lock exists on a given bus. - Use new pm_runtime_disabled flag to conditionally turnoff runtime pm in the dw platform driver. David E. Box (2): i2c-designware: Add i2c bus locking support i2c-designware: Add Intel Baytrail PMIC I2C bus support drivers/i2c/busses/Kconfig | 11 ++ drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-designware-baytrail.c | 160 +++ drivers/i2c/busses/i2c-designware-core.c | 26 + drivers/i2c/busses/i2c-designware-core.h | 12 ++ drivers/i2c/busses/i2c-designware-platdrv.c | 20 +++- 6 files changed, 225 insertions(+), 5 deletions(-) create mode 100644 drivers/i2c/busses/i2c-designware-baytrail.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LSF/MM TOPIC] userfaultfd
On 01/15/2015 02:01 AM, Andrea Arcangeli wrote: > Hello, > > I would like to attend this year (2015) LSF/MM summit. I'm > particularly interested about the MM track, in order to get help in > finalizing the userfaultfd feature I've been working on lately. I'd like the +1 this. I'm also interested in this topic, especially in the item 5 below. > 5) postcopy live migration of binaries inside linux containers >(provided there is a userfaultfd command [not an external syscall >like the original implementation] that allows to copy memory >atomically in the userfaultfd "mm" and not in the manager "mm", >hence the main reason the external syscalls are going away, and in >turn MADV_USERFAULT fd-less is going away as well). We've started to play with the userfaultfd in the CRIU project [1] to do the post-copy live migration of whole containers (and their parts). One more use case I've seen on CRIU mailing list is the restore of container from on-disk images w/o getting the whole memory in at the restore time. The memory is to be put into tasks' address space in n-demand manner later. It's claimed that such restore decreases the restore time significantly. One more thing that userfaultfd can help with is restoring COW areas. Right now, if we have two tasks, that share a phys page, but have one RO mapped to do the COW later we do complex tricks with restoring the page in common ancestor, then inheriting one on fork()-s and mremap-ing it. Probably it's an API misuse, but it seems to be much simpler if the page could be just "sent" to the remote mm via userfaultfd. [1] http://criu.org/Main_Page Thanks, Pavel -- 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 V4 1/2] i2c-designware: Add i2c bus locking support
Adds support for acquiring and releasing a hardware bus lock in the i2c
designware core transfer function. This is needed for i2c bus controllers
that are shared with but not controlled by the kernel.
Signed-off-by: David E. Box
---
drivers/i2c/busses/i2c-designware-core.c | 26 ++
drivers/i2c/busses/i2c-designware-core.h | 6 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/i2c/busses/i2c-designware-core.c
b/drivers/i2c/busses/i2c-designware-core.c
index 3c20e4b..3d3ac4d 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -289,6 +289,15 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
u32 hcnt, lcnt;
u32 reg;
u32 sda_falling_time, scl_falling_time;
+ int ret;
+
+ if (dev->acquire_lock) {
+ ret = dev->acquire_lock(dev);
+ if (ret) {
+ dev_err(dev->dev, "couldn't acquire bus ownership\n");
+ return ret;
+ }
+ }
input_clock_khz = dev->get_clk_rate_khz(dev);
@@ -302,6 +311,8 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
} else if (reg != DW_IC_COMP_TYPE_VALUE) {
dev_err(dev->dev, "Unknown Synopsys component type: "
"0x%08x\n", reg);
+ if (dev->release_lock)
+ dev->release_lock(dev);
return -ENODEV;
}
@@ -368,6 +379,9 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
/* configure the i2c master */
dw_writel(dev, dev->master_cfg , DW_IC_CON);
+
+ if (dev->release_lock)
+ dev->release_lock(dev);
return 0;
}
EXPORT_SYMBOL_GPL(i2c_dw_init);
@@ -631,6 +645,14 @@ i2c_dw_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
dev->abort_source = 0;
dev->rx_outstanding = 0;
+ if (dev->acquire_lock) {
+ ret = dev->acquire_lock(dev);
+ if (ret) {
+ dev_err(dev->dev, "couldn't acquire bus ownership\n");
+ goto done_nolock;
+ }
+ }
+
ret = i2c_dw_wait_bus_not_busy(dev);
if (ret < 0)
goto done;
@@ -676,6 +698,10 @@ i2c_dw_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
ret = -EIO;
done:
+ if (dev->release_lock)
+ dev->release_lock(dev);
+
+done_nolock:
pm_runtime_mark_last_busy(dev->dev);
pm_runtime_put_autosuspend(dev->dev);
mutex_unlock(>lock);
diff --git a/drivers/i2c/busses/i2c-designware-core.h
b/drivers/i2c/busses/i2c-designware-core.h
index d66b6cb..a472c91 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -65,6 +65,9 @@
* @ss_lcnt: standard speed LCNT value
* @fs_hcnt: fast speed HCNT value
* @fs_lcnt: fast speed LCNT value
+ * @acquire_lock: function to acquire a hardware lock on the bus
+ * @release_lock: function to release a hardware lock on the bus
+ * @pm_runtime_disabled: true if pm runtime is disabled
*
* HCNT and LCNT parameters can be used if the platform knows more accurate
* values than the one computed based only on the input clock frequency.
@@ -105,6 +108,9 @@ struct dw_i2c_dev {
u16 ss_lcnt;
u16 fs_hcnt;
u16 fs_lcnt;
+ int (*acquire_lock)(struct dw_i2c_dev *dev);
+ void(*release_lock)(struct dw_i2c_dev *dev);
+ boolpm_runtime_disabled;
};
#define ACCESS_SWAP0x0001
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 2/2] i2c-designware: Add Intel Baytrail PMIC I2C bus support
This patch implements an I2C bus sharing mechanism between the host and platform
hardware on select Intel BayTrail SoC platforms using the X-Powers AXP288 PMIC.
On these platforms access to the PMIC must be shared with platform hardware. The
hardware unit assumes full control of the I2C bus and the host must request
access through a special semaphore. Hardware control of the bus also makes it
necessary to disable runtime pm to avoid interfering with hardware transactions.
Signed-off-by: David E. Box
---
drivers/i2c/busses/Kconfig | 11 ++
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-designware-baytrail.c | 160 +++
drivers/i2c/busses/i2c-designware-core.h | 6 +
drivers/i2c/busses/i2c-designware-platdrv.c | 20 +++-
5 files changed, 193 insertions(+), 5 deletions(-)
create mode 100644 drivers/i2c/busses/i2c-designware-baytrail.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 917c358..9a83c46 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -464,6 +464,17 @@ config I2C_DESIGNWARE_PCI
This driver can also be built as a module. If so, the module
will be called i2c-designware-pci.
+config I2C_DESIGNWARE_BAYTRAIL
+ bool "Intel Baytrail I2C semaphore support"
+ depends on I2C_DESIGNWARE_PLATFORM
+ select IOSF_MBI
+ help
+ This driver enables managed host access to the PMIC I2C bus on select
+ Intel BayTrail platforms using the X-Powers AXP288 PMIC. It allows
+ the host to request uninterrupted access to the PMIC's I2C bus from
+ the platform firmware controlling it. You should say Y if running on
+ a BayTrail system using the AXP288.
+
config I2C_EFM32
tristate "EFM32 I2C controller"
depends on ARCH_EFM32 || COMPILE_TEST
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 78d56c5..15b2965 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_I2C_DAVINCI) += i2c-davinci.o
obj-$(CONFIG_I2C_DESIGNWARE_CORE) += i2c-designware-core.o
obj-$(CONFIG_I2C_DESIGNWARE_PLATFORM) += i2c-designware-platform.o
i2c-designware-platform-objs := i2c-designware-platdrv.o
+i2c-designware-platform-$(CONFIG_I2C_DESIGNWARE_BAYTRAIL) +=
i2c-designware-baytrail.o
obj-$(CONFIG_I2C_DESIGNWARE_PCI) += i2c-designware-pci.o
i2c-designware-pci-objs := i2c-designware-pcidrv.o
obj-$(CONFIG_I2C_EFM32)+= i2c-efm32.o
diff --git a/drivers/i2c/busses/i2c-designware-baytrail.c
b/drivers/i2c/busses/i2c-designware-baytrail.c
new file mode 100644
index 000..5f1ff4c
--- /dev/null
+++ b/drivers/i2c/busses/i2c-designware-baytrail.c
@@ -0,0 +1,160 @@
+/*
+ * Intel BayTrail PMIC I2C bus semaphore implementaion
+ * Copyright (c) 2014, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "i2c-designware-core.h"
+
+#define SEMAPHORE_TIMEOUT 100
+#define PUNIT_SEMAPHORE0x7
+
+static unsigned long acquired;
+
+static int get_sem(struct device *dev, u32 *sem)
+{
+ u32 reg_val;
+ int ret;
+
+ ret = iosf_mbi_read(BT_MBI_UNIT_PMC, BT_MBI_BUNIT_READ, PUNIT_SEMAPHORE,
+ _val);
+ if (ret) {
+ dev_err(dev, "iosf failed to read punit semaphore\n");
+ return ret;
+ }
+
+ *sem = reg_val & 0x1;
+
+ return 0;
+}
+
+static void reset_semaphore(struct device *dev)
+{
+ u32 data;
+
+ if (iosf_mbi_read(BT_MBI_UNIT_PMC, BT_MBI_BUNIT_READ,
+ PUNIT_SEMAPHORE, )) {
+ dev_err(dev, "iosf failed to reset punit semaphore during
read\n");
+ return;
+ }
+
+ data = data & 0xfffe;
+ if (iosf_mbi_write(BT_MBI_UNIT_PMC, BT_MBI_BUNIT_WRITE,
+PUNIT_SEMAPHORE, data))
+ dev_err(dev, "iosf failed to reset punit semaphore during
write\n");
+}
+
+int baytrail_i2c_acquire(struct dw_i2c_dev *dev)
+{
+ u32 sem = 0;
+ int ret;
+ unsigned long start, end;
+
+ if (!dev || !dev->dev)
+ return -ENODEV;
+
+ if (!dev->acquire_lock)
+ return 0;
+
+ /* host driver writes 0x2 to side band semaphore register */
+ ret = iosf_mbi_write(BT_MBI_UNIT_PMC, BT_MBI_BUNIT_WRITE,
+PUNIT_SEMAPHORE, 0x2);
Re: [RFC 0/3] mmc: Add dynamic frequency scaling
On czw, 2015-01-15 at 09:20 +0100, Ulf Hansson wrote: > + Mike, Stephen (Clock maintainers) > > On 12 January 2015 at 10:23, Krzysztof Kozlowski > wrote: > > Hi, > > > > > > I would like to hear some comments about idea of scaling MMC clock > > frequency. The basic idea is to lower the clock when device is > > completely idle or not busy enough. > > We already have host drivers that implements runtime PM support. > Typically that would mean the clock will be gated once the device > becomes runtime PM suspended. > > Why should we decrease the frequency of an already gated clock? In case of idle state you're right that clkgate would be better. But what about finding a compromise between high performance (high frequency) and energy saving for different loads on MMC? The frequency scaling could help in that case. Anyway I should prepare some more benchmarks for such conditions. Best regards, Krzysztof > I think this boils done to how DVFS transitions can be triggered from > the clock drivers, right? > > Currently the clock framework supports this through clock rate change > notifiers. Should we have clock notifiers for clk_prepare|unprepare() > as well? I do remember that someone posted patches for that a while > ago, but those were rejected. > > Mike, Stephen - comments? > > Kind regards > Uffe > > > > > The patchset adds MMC card as a devfreq device and uses simple_ondemand > > as governor. In idle this gave benefits (less energy consumed during > > idle): > > 1. Trats2 (Exynos4412): 2.6% > > 2. Rinato (Exynos3250): 1% > > > > but (especially on Rinato) it had impact on performance (probably > > because ondemand triggering a little to late). What is interesting > > manually changing the clock (without this patchset) gave slightly > > bigger benefits. Maybe the devfreq introduces noticeable overhead? > > > > > > Comments are welcomed. Maybe on other platforms this has bigger impact? > > > > Best regards, > > Krzysztof > > > > > > Krzysztof Kozlowski (3): > > mmc: Add dynamic frequency scaling > > ARM: dts: Specify MSHC realistic clocks and use frequency scaling > > ARM: dts: Use frequency scaling for MSHC > > > > Documentation/devicetree/bindings/mmc/mmc.txt | 2 + > > arch/arm/boot/dts/exynos3250-rinato.dts | 1 + > > arch/arm/boot/dts/exynos4412-trats2.dts | 4 +- > > drivers/mmc/card/block.c | 247 > > ++ > > drivers/mmc/core/Kconfig | 16 ++ > > drivers/mmc/core/core.h | 1 - > > drivers/mmc/core/host.c | 2 + > > include/linux/mmc/card.h | 8 + > > include/linux/mmc/host.h | 3 + > > 9 files changed, 282 insertions(+), 2 deletions(-) > > > > -- > > 1.9.1 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] perf bench: fix order of arguments to memcpy_alloc_mem
This was causing the destination instead of the source to be filled. As a result, the source was typically all mapped to one zero page, and hence very cacheable. Signed-off-by: Bruce Merry --- tools/perf/bench/mem-memcpy.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/bench/mem-memcpy.c b/tools/perf/bench/mem-memcpy.c index 6c14afe..db1d3a2 100644 --- a/tools/perf/bench/mem-memcpy.c +++ b/tools/perf/bench/mem-memcpy.c @@ -289,7 +289,7 @@ static u64 do_memcpy_cycle(const struct routine *r, size_t len, bool prefault) memcpy_t fn = r->fn.memcpy; int i; - memcpy_alloc_mem(, , len); + memcpy_alloc_mem(, , len); if (prefault) fn(dst, src, len); @@ -312,7 +312,7 @@ static double do_memcpy_gettimeofday(const struct routine *r, size_t len, void *src = NULL, *dst = NULL; int i; - memcpy_alloc_mem(, , len); + memcpy_alloc_mem(, , len); if (prefault) fn(dst, src, len); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] PCI / PM: Avoid resuming PCI devices during system suspend
On Monday, January 12, 2015 11:39:18 AM Alan Stern wrote: > On Mon, 12 Jan 2015, Rafael J. Wysocki wrote: > > > On Thursday, January 08, 2015 10:51:06 AM Alan Stern wrote: > > > On Thu, 8 Jan 2015, Rafael J. Wysocki wrote: > > > > > > > From: Rafael J. Wysocki > > > > > > > > Commit f25c0ae2b4c4 (ACPI / PM: Avoid resuming devices in ACPI PM > > > > domain during system suspend) modified the ACPI PM domain's system > > > > suspend callbacks to allow devices attached to it to be left in the > > > > runtime-suspended state during system suspend so as to optimize > > > > the suspend process. > > > > > > > > This was based on the general mechanism introduced by commit > > > > aae4518b3124 (PM / sleep: Mechanism to avoid resuming runtime-suspended > > > > devices unnecessarily). > > > > > > > > Extend that approach to PCI devices by modifying the PCI bus type's > > > > ->prepare callback to return 1 for devices that are runtime-suspended > > > > when it is being executed and that are in a suitable power state and > > > > need not be resumed going forward. > > > > > > Does this correctly handle PCI devices that aren't included in the ACPI > > > tables? For example, add-on PCI cards? > > > > Well, it would if it took the case when a device was configured for remote > > wakeup at run time but was not supposed to wakeup the system from sleep into > > account. > > > > That needs to be checked in pci_dev_keep_suspended() rather than in the > > platform > > callback to cover all devices. > > > > Updated patch follows. > > > > Rafael > > This looks better, thank you. Well, it still has the problem that the current ACPI wakeup setting may not be suitable depending on the PM_QOS_FLAG_REMOTE_WAKEUP value which I overlooked before. I need to restore the check against adev->wakeup.prepare_count in acpi_pci_need_resume() to cover that I think. Will post a v2 with that fixed. -- I speak only for myself. Rafael J. Wysocki, 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] The count field of counter_show() function should be an unsigned value
The count field is an unsigned 32bit value, and the counter_show() function should also treat it as a unsigned value. Signed-off-by: Nan Li --- drivers/acpi/sysfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c index 13e577c..0876d77 100644 --- a/drivers/acpi/sysfs.c +++ b/drivers/acpi/sysfs.c @@ -527,7 +527,7 @@ static ssize_t counter_show(struct kobject *kobj, acpi_irq_not_handled; all_counters[num_gpes + ACPI_NUM_FIXED_EVENTS + COUNT_GPE].count = acpi_gpe_count; - size = sprintf(buf, "%8d", all_counters[index].count); + size = sprintf(buf, "%8u", all_counters[index].count); /* "gpe_all" or "sci" */ if (index >= num_gpes + ACPI_NUM_FIXED_EVENTS) -- 1.7.12.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v2 07/16] x86/apic: Refine enable_IR_x2apic() and related functions
On Wed, 7 Jan 2015, Jiang Liu wrote: > Refine enable_IR_x2apic() and related functions for better readability. > > It also changes the way to handle IR in XAPIC mode when enabling X2APIC. > Previously it just skips X2APIC initialization without checking max CPU > APIC ID in system, which may cause problem if system has CPU with APIC > ID bigger than 255. So treat IR in XAPIC mode as same as IR is disabled > when enabling CPU X2APIC. Please don't do that. This wants to be two patches: 1) reordering the code 2) changing the operation I've split it already, so no need to resend. Thanks, tglx -- 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/8] x86/xen/p2m: Replace ACCESS_ONCE with READ_ONCE
On 01/15/2015 09:58 AM, Christian Borntraeger wrote:
ACCESS_ONCE does not work reliably on non-scalar types. For
example gcc 4.6 and 4.7 might remove the volatile tag for such
accesses during the SRA (scalar replacement of aggregates) step
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145)
Change the p2m code to replace ACCESS_ONCE with READ_ONCE.
Signed-off-by: Christian Borntraeger
Reviewed-by: Juergen Gross
---
arch/x86/xen/p2m.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index edbc7a6..cb71016 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -554,7 +554,7 @@ static bool alloc_p2m(unsigned long pfn)
mid_mfn = NULL;
}
- p2m_pfn = pte_pfn(ACCESS_ONCE(*ptep));
+ p2m_pfn = pte_pfn(READ_ONCE(*ptep));
if (p2m_pfn == PFN_DOWN(__pa(p2m_identity)) ||
p2m_pfn == PFN_DOWN(__pa(p2m_missing))) {
/* p2m leaf page is missing */
--
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 1/5] irqchip: add dumb demultiplexer implementation
Le 15/01/2015 10:11, Thomas Gleixner a écrit : > On Wed, 14 Jan 2015, Rob Herring wrote: >> On Wed, Jan 14, 2015 at 4:36 AM, Thomas Gleixner wrote: >>> All attempts to work around that have resulted in horrible bandaids so >>> far. That's why I guided Boris to implement this dummy demultiplexing >>> mechanism. It solves the problem at hand nicely without adding nasty >>> hackarounds into the suspend/resume code and inflicting platform >>> knowledge on multi-platform device drivers. >> >> This change will break on old kernels with a new dtb. Would you be >> happy if a BIOS update required a new kernel? Fixing this for any >> platform requires a dtb update which may not be possible on some >> platforms. I don't have a problem with this breakage for 1 platform >> and the at91 guys may not care, but we'd ultimately be changing how >> all shared irqs are specified for all DT. Maybe we decide that this is >> how we want to describe things, but that needs much wider discussion >> and agreement. > > We do not change shared interrupts in any way. We provide an > alternative mechanism for braindead hardware. And if the at91 folks Let me add subtle details: "Old braindead hardware, with possibility to use alternative set of timers which doesn't have shared interrupt lines" ;-) > are fine with the DT change, then it's their decision. Nothing forces > this on everyone. Yes I do agree to change DT. >>> If you have a proper solution for the problem at hand which >>> >>>- avoids the demux dummy >>> >>>- works straight forward with suspend/resume/wakeup >>> >>>- does not add horrible new APIs >>> >>>- does not add conditionals to the interrupt hotpath >>> >>>- does not inflict platform knowledge about interrupt chip details >>> on drivers >>> >>> then I'm happy to take it. >>> >>> But as long as you can't come up with anything sane, the demux dummy >>> is the best solution for this problem we've seen so far. >> >> What if during suspend you move all actions w/o IRQF_NO_SUSPEND to a >> suspended action list? This would leave only the actions with >> IRQF_NO_SUSPEND set in the active action list. The cost would be a >> pointer in irq_desc and moving the actions during suspend and resume. > > That's exactly what we want NOT. Because it prevents us to do proper > sanity checks for IRQF_NO_SUSPEND. We've been there and I rejected it > for that very reason. > >> There are probably ways to do this demux irqchip without a DT change. > > What's the problem with a DT change for a single platform, if the > maintainers are willing to take it and deal with the fallout? > > And in case of AT91 the new kernel will simply work with the old DT > and just emit the same warning vs. the IRQF_NO_SUSPEND mismatch. Older > kernels won't work with a new DT, but that's about it. > > Aside of that, I'm quite amused about your DT update worries. DTs > break with every kernel version on very popular platforms in very > weird and subtle ways. DT on AT91 is a Work In Progress (for 3.5 years) and the facts have told us that DT updates were absolutely necessary. So, for now, I agree to change DT as far as AT91 is concerned. Bye, -- Nicolas Ferre -- 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 mtd] mtd:devices: Add Altera EPCQ Driver
On Tue, Jan 13, 2015 at 11:33 AM, Brian Norris
wrote:
> On Thu, Dec 18, 2014 at 12:23:16AM -0800, vn...@altera.com wrote:
>> From: Viet Nga Dao
>>
>> Altera EPCQ Controller is a soft IP which enables access to Altera EPCQ and
>> EPCS flash chips. This patch adds driver for these devices.
>>
>> Signed-off-by: Viet Nga Dao
>
> This drivers seems awfully similar to (and so I infer it is likely
> copy-and-pasted from) m25p80.c / spi-nor.c. Do you think it can be
> rewritten as a SPI NOR driver, under drivers/mtd/spi-nor/ ? It looks
> like these flash share most (all?) the same basic opcodes.
>
For Altera EPCQ flashes, almost operations are performed underline
hardware. Software only able to perform the following through
registers:
- read status register
- read id
- write status registers bit SR_BP0,SR_BP1, SR_BP2,SR_BP3, SR_TB
(http://www.altera.com.my/literature/hb/cfg/cfg_cf52012.pdf)
For read/write data: all the operations like QUAD_READ/WRITE,
FAST_READ/WRITE are handled by hardware as well. From software point
of view, there is no difference between these 2 modes.
That is why if rewrite the drivers to follow spi-nor structure, it
will require extra decoding works for the only few used opcodes.
>> ---
>> .../devicetree/bindings/mtd/altera_epcq.txt| 45 ++
>> drivers/mtd/devices/Kconfig| 12 +
>> drivers/mtd/devices/Makefile |2 +-
>> drivers/mtd/devices/altera_epcq.c | 804
>>
>> drivers/mtd/devices/altera_epcq.h | 130
>> 5 files changed, 992 insertions(+), 1 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mtd/altera_epcq.txt
>> create mode 100644 drivers/mtd/devices/altera_epcq.c
>> create mode 100644 drivers/mtd/devices/altera_epcq.h
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/altera_epcq.txt
>> b/Documentation/devicetree/bindings/mtd/altera_epcq.txt
>> new file mode 100644
>> index 000..d14f50e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/altera_epcq.txt
>> @@ -0,0 +1,45 @@
>> +* MTD Altera EPCQ driver
>> +
>> +Required properties:
>> +- compatible: Should be "altr,epcq-1.0"
>> +- reg: Address and length of the register set for the device. It contains
>> + the information of registers in the same order as described by reg-names
>> +- reg-names: Should contain the reg names
>> + "csr_base": Should contain the register configuration base address
>> + "data_base": Should contain the data base address
>> +- is-epcs: boolean type.
>> + If present, the device contains EPCS flashes.
>> + Otherwise, it contains EPCQ flashes.
>> +- #address-cells: Must be <1>.
>> +- #size-cells: Must be <0>.
>> +- flash device tree subnode, there must be a node with the following fields:
>
> These subnodes definitely require a 'compatible' string. Perhaps they
> should be used to differentiate EPCS vs. EPCQ. Does "is-epcs" really
> need to be in the top-level controller node?
>
>> + - reg: Should contain the flash id
>
> Should, or must? (This question is relevant, because you seem to make it
> optional in your code.) And what does the "flash ID" mean? It seems like
> you're using as a chip-select or bank index.
>
>> + - #address-cells: please refer to /mtd/partition.txt
>> + - #size-cells: please refer to /mtd/partition.txt
>> + For partitions inside each flash, please refer to /mtd/partition.txt
>> +
>> +Example:
>> +
>> + epcq_controller_0: epcq@0x0 {
>> + compatible = "altr,epcq-1.0";
>> + reg = <0x0001 0x 0x0020>,
>> + <0x 0x 0x0200>;
>> + reg-names = "csr_base", "data_base";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + flash0: epcq256@0 {
>> + reg = <0>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + partition@0 {
>> + /* 16 MB for raw data. */
>> + label = "EPCQ Flash 0 raw
>> data";
>> + reg = <0x0 0x100>;
>> + };
>> + partition@100 {
>> + /* 16 MB for jffs2 data. */
>> + label = "EPCQ Flash 0 JFFS 2";
>> + reg = <0x100 0x100>;
>> + };
>> + };
>> + }; //end epcq@0x0 (epcq_controller_0)
>> diff --git
Re: [GIT PULL] x86/entry changes for 3.20, round 1
On Wed, Jan 14, 2015 at 05:59:26PM -0800, Andy Lutomirski wrote: > Hi Ingo and Thomas, > > At Linus' suggestion, I'm trying out some maintainerish stuff for x86 > entry code. Please consider pulling to an appropriate branch *after > Paul sends his RCU pull request*, only if 734d16801349 is included in > that pull request. If this goes well, maybe I'll submit a MAINTAINERS > patch, too. > > IMPORTANT: This is based on an RCU change that you don't have yet. I > think that Paul is planning on sending a pull request with that change > fairly soon. The code in here would compile without that fix, but it > would introduce a nasty regression, so, to avoid breaking bisection, I > based this off of the relevant change in Paul's tree. (It's the very > first change for 3.20 in his current queue.) Yep, should happen by early next week, if it survives this weekend's testing. ;-) Thanx, Paul > If you want me to structure this differently, let me know. > > I may have one more entry pull request before the merge window if I > can get my sysret stuff reviewed in time. Not sure yet. I may also > be comfortable with some more of Denys' cleanups in time. > > The following changes since commit 734d16801349fbe951d2f780191d32c5b8a892d1: > > rcu: Make rcu_nmi_enter() handle nesting (2014-12-30 17:40:16 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git > tags/pr-20150114-x86-entry > > for you to fetch changes up to f6f64681d9d87ded48a90b644b2991c6ee05da2d: > > x86: entry_64.S: fold SAVE_ARGS_IRQ macro into its sole user > (2015-01-13 14:18:08 -0800) > > > This is my accumulated x86 entry work, part 1, for 3.20. The meat > of this is an IST rework. When an IST exception interrupts user > space, we will handle it on the per-thread kernel stack instead of > on the IST stack. This sounds messy, but it actually simplifies the > IST entry/exit code, because it eliminates some ugly games we used > to play in order to handle rescheduling, signal delivery, etc on the > way out of an IST exception. > > The IST rework introduces proper context tracking to IST exception > handlers. I haven't seen any bug reports, but the old code could > have incorrectly treated an IST exception handler as an RCU extended > quiescent state. > > The memory failure change (included in this pull request with > Borislav and Tony's permission) eliminates a bunch of code that > is no longer needed now that user memory failure handlers are > called in process context. > > Finally, this includes a few on Denys' uncontroversial and Obviously > Correct (tm) cleanups. > > The IST and memory failure changes have been in -next for a while. > > LKML references: > > IST rework: > http://lkml.kernel.org/r/cover.1416604491.git.l...@amacapital.net > > Memory failure change: > http://lkml.kernel.org/r/54ab2ffa301102c...@agluck-desk.sc.intel.com > > Denys' cleanups: > http://lkml.kernel.org/r/1420927210-19738-1-git-send-email-dvlas...@redhat.com > > > Andy Lutomirski (4): > x86, entry: Switch stacks on a paranoid entry from userspace > x86, traps: Track entry into and exit from IST context > x86: Clean up current_stack_pointer > x86, traps: Add ist_begin_non_atomic and ist_end_non_atomic > > Denys Vlasenko (3): > x86: entry_64.S: delete unused code > x86: ia32entry.S: fix wrong symbolic constant usage: R11->ARGOFFSET > x86: entry_64.S: fold SAVE_ARGS_IRQ macro into its sole user > > Tony Luck (1): > x86, mce: Get rid of TIF_MCE_NOTIFY and associated mce tricks > > Documentation/x86/entry_64.txt | 18 ++- > Documentation/x86/x86_64/kernel-stacks | 8 +- > arch/x86/ia32/ia32entry.S | 4 +- > arch/x86/include/asm/calling.h | 1 - > arch/x86/include/asm/mce.h | 1 - > arch/x86/include/asm/thread_info.h | 15 ++- > arch/x86/include/asm/traps.h | 6 + > arch/x86/kernel/cpu/mcheck/mce.c | 114 +- > arch/x86/kernel/cpu/mcheck/p5.c| 6 + > arch/x86/kernel/cpu/mcheck/winchip.c | 5 + > arch/x86/kernel/entry_64.S | 208 > ++--- > arch/x86/kernel/irq_32.c | 13 +-- > arch/x86/kernel/signal.c | 6 - > arch/x86/kernel/traps.c| 108 + > 14 files changed, 252 insertions(+), 261 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] jbd: drop jbd_ENOSYS debug
On Wed 14-01-15 22:59:13, Davidlohr Bueso wrote:
> A quick search shows that there are no users, drop the
> macro for both jbd and jbd2.
>
> Signed-off-by: Davidlohr Bueso
> Cc: Jan Kara
Thanks. I've added the patch to my tree.
Honza
> ---
> My goal here was to just change how we set current state, however
> I realized that the function is not used.
>
> include/linux/jbd.h | 9 -
> include/linux/jbd2.h | 9 -
> 2 files changed, 18 deletions(-)
>
> diff --git a/include/linux/jbd.h b/include/linux/jbd.h
> index 31229e0..d326152 100644
> --- a/include/linux/jbd.h
> +++ b/include/linux/jbd.h
> @@ -956,15 +956,6 @@ void __log_wait_for_space(journal_t *journal);
> extern void __journal_drop_transaction(journal_t *, transaction_t *);
> extern int cleanup_journal_tail(journal_t *);
>
> -/* Debugging code only: */
> -
> -#define jbd_ENOSYS() \
> -do {\
> - printk (KERN_ERR "JBD unimplemented function %s\n", __func__); \
> - current->state = TASK_UNINTERRUPTIBLE; \
> - schedule();\
> -} while (1)
> -
> /*
> * is_journal_abort
> *
> diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h
> index 704b9a5..20e7f78 100644
> --- a/include/linux/jbd2.h
> +++ b/include/linux/jbd2.h
> @@ -1251,15 +1251,6 @@ void __jbd2_log_wait_for_space(journal_t *journal);
> extern void __jbd2_journal_drop_transaction(journal_t *, transaction_t *);
> extern int jbd2_cleanup_journal_tail(journal_t *);
>
> -/* Debugging code only: */
> -
> -#define jbd_ENOSYS() \
> -do {\
> - printk (KERN_ERR "JBD unimplemented function %s\n", __func__); \
> - current->state = TASK_UNINTERRUPTIBLE; \
> - schedule();\
> -} while (1)
> -
> /*
> * is_journal_abort
> *
> --
> 2.1.2
>
--
Jan Kara
SUSE Labs, CR
--
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 RFC] audit: move the tree pruning to a dedicated thread
On 01/13/15 02:47, Paul Moore wrote:
> On Monday, January 12, 2015 09:11:21 AM Imre Palik wrote:
>> On 01/08/15 22:53, Paul Moore wrote:
>>> On Tuesday, January 06, 2015 03:51:20 PM Imre Palik wrote:
From: "Palik, Imre"
When file auditing is enabled, during a low memory situation, a memory
allocation with __GFP_FS can lead to pruning the inode cache. Which can,
in turn lead to audit_tree_freeing_mark() being called. This can call
audit_schedule_prune(), that tries to fork a pruning thread, and
waits until the thread is created. But forking needs memory, and the
memory allocations there are done with __GFP_FS.
So we are waiting merrily for some __GFP_FS memory allocations to
complete,
while holding some filesystem locks. This can take a while ...
This patch creates a single thread for pruning the tree from
audit_add_tree_rule(), and thus avoids the deadlock that the on-demand
thread creation can cause.
Reported-by: Matt Wilson
Cc: Matt Wilson
Signed-off-by: Imre Palik
>>>
>>> Thanks for sticking with this and posting a revised patch, my comments are
>>> inline with the patch below ... also as a FYI, when sending a revised
>>> patch it is often helpful to put a revision indicator in the subject
>>> line, as an>
>>> example:
>>> "[RFC PATCH v2] audit: make audit less awful"
>>>
>>> It's not strictly necessary, but it makes my life just a little bit
>>> easier.
>>
>> Sorry for that. I realised that I botched the subject immediately after
>> sending the mail :-(
>
> No worries, you'll take care of it next time.
>
diff --git a/kernel/audit_tree.c b/kernel/audit_tree.c
index 0caf1f8..0ada577 100644
--- a/kernel/audit_tree.c
+++ b/kernel/audit_tree.c
>>>
>>> ...
>>>
+static int launch_prune_thread(void)
+{
+ prune_thread = kthread_create(prune_tree_thread, NULL,
+ "audit_prune_tree");
+ if (IS_ERR(prune_thread)) {
+ audit_panic("cannot start thread audit_prune_tree");
>>>
>>> I'm not certain audit_panic() is warranted here, pr_err() might be a
>>> better choice. What is the harm if the thread doesn't start and we return
>>> an error code?
>>
>> I thought disabling the bigger part of the file auditing would warrant a
>> bigger bang than pr_err(). If you think, it is an overkill, then I can
>> change it.
>>
>> But see my comment below in audit_schedule_prune()
>
> My concern with audit_panic() is that it only generates a panic() in the
> *very* rare circumstance that someone has configured it that way. While
> there
> are some users who do configure their systems with AUDIT_FAIL_PANIC, I think
> it is safe to say that most do not. Further, audit_panic() can be rate
> limited or even silenced in the case of AUDIT_FAIL_SILENT.
>
> The choice of pr_err() is not perfect for all scenarios, but I think it is
> the
> better choice for most of the common scenarios.
Ok. so pr_err() is the one with reliably the bigger bang.
+ prune_thread = NULL;
+ return -ENOSYS;
>>>
>>> Out of curiosity, why ENOSYS?
>>
>> I thought it is a bit less confusing than ESRCH.
>
> Originally I was thinking about -ENOMEM, thoughts?
That might be better in the sense that the application programmer's response
to that case might be the one we want here.
>
+ } else {
+ wake_up_process(prune_thread);
+ return 0;
+ }
+}
>>>
>>> See my comments below in audit_schedule_prune().
>>>
/* called with audit_filter_mutex */
int audit_add_tree_rule(struct audit_krule *rule)
{
@@ -663,6 +713,12 @@ int audit_add_tree_rule(struct audit_krule *rule)
/* do not set rule->tree yet */
mutex_unlock(_filter_mutex);
+ if (unlikely(!prune_thread)) {
+ err = launch_prune_thread();
+ if (err)
+ goto Err;
+ }
+
>>>
>>> Why not put this at the top of audit_add_tree_rule()?
>>
>> I would like to do this without holding audit_filter_mutex.
>
> Sorry, I forgot that audit_add_tree_rule() is called with the
> audit_filter_mutex locked.
>
err = kern_path(tree->pathname, 0, );
if (err)
goto Err;
@@ -713,6 +769,9 @@ int audit_tag_tree(char *old, char *new)
struct vfsmount *tagged;
int err;
+ if (!prune_thread)
+ return -ENOSYS;
>>>
>>> Help me out - why?
>
> Still, why?
You are right, it is not needed.
The codepath I was worried about is impossible.
err = kern_path(new, 0, );
if (err)
return err;
@@ -800,36 +859,11 @@ int audit_tag_tree(char *old, char *new)
return failed;
}
-/*
- * That gets run when evict_chunk() ends up needing to kill audit_tree.
- * Runs from a separate thread.
Re: [PATCH 1/2 v2] ftrace: don't allow IPMODIFY without proper compiler support
On Thu, 15 Jan 2015, Masami Hiramatsu wrote: > Hmm, if this binary doesn't support IPMODIFY, it should return -ENOTSUPP. Good poing, will send v3. > And also, IMHO, we'd better reject registering ftrace_ops with IPMODIFY > in this situation before updating hash table. That would happen automatically if we return -ENOTSUPP, right? Because the check in ftrace_hash_move() would cause freeing of the new_hash and the error value would get propagated out to ftrace_hash_move() callers. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] gpio: support for GPIO forwarding
On Thu, Jan 15, 2015 at 10:28:03AM +0100, Rafael J. Wysocki wrote: > On Wednesday, January 14, 2015 08:32:12 AM Darren Hart wrote: > > > > On 1/14/15 4:58 AM, Linus Walleij wrote: > > > On Thu, Dec 18, 2014 at 9:23 AM, Heikki Krogerus > > > wrote: > > > > > >> This makes it possible to assign GPIOs at runtime. The > > >> motivation for it is because of need to forward GPIOs from > > >> one device to an other. That feature may be useful for > > >> example with some mfd devices, but initially it is needed > > > > +Samuel Ortiz for his thoughts on applicability to MFD. > > > > >> because on some Intel Braswell based ACPI platforms the GPIO > > >> resources controlling signals of the USB PHY are given to > > >> the controller device object for whatever reason, so the > > >> driver of that controller needs be able to pass them to the > > >> PHY device somehow. > > >> > > >> So basically this is meant to allow patching of bad (bad > > >> from Linux kernels point of view) hardware descriptions > > >> provided by system fw in the drivers. > > >> > > >> Signed-off-by: Heikki Krogerus > > >> --- > > >> > > >> Hi, > > >> > > >> I'm sending this first as a RFC in case you guys have some better > > >> idea how to solve our problem. I actually already have couple > > >> platforms where the GPIO resources are given to the "wrong" device > > >> objects now. > > >> > > >> Originally we were thinking about simply handling our problem with > > >> hacks to the PHY drivers, basically also checking if the parent has > > >> GPIOs. That would only work if the controller is always the parent, > > >> which it's not, but even if it was, it would be too risky. The PHY > > >> drivers don't know which controller they are attached to, so what is > > >> to say that the GPIOs aren't really attached to the controller. > > >> > > >> So the safest way to handle our problem is to deal with it in quirks > > >> in the controller drivers. Solving it by bouncing the GPIOs did not > > >> feel ideal there doesn't seem to be any other way. The API is copied > > >> from clkdev (clk_register_clkdev). In the end it's really only one > > >> function for adding the lookups and one for removing them. > > >> > > >> The way it's implemented is by modifying the current style of handling > > >> the lookups a little bit. The per device lookup table is basically > > >> reverted back to the single linked-list format since it seems that > > >> these lookups may have to be assigned from several sources. > > > > > > Oh ain't that great. > > > > > > So now we start patching around the kernel because the ACPI > > > tables are erroneous for GPIOs. I'd like some feedback from > > > Rafael &| Darren on this patch, i.e. if you two think this is a good > > > way of accounting for bad GPIO descriptions in ACPI tables then > > > ACK this patch. > > > > > > I guess the other option would be to fix up the ACPI DSDT > > > itself to put resources right, correct? Is this not possible? > > > > This is my gut reaction as well. > > Pretty much agreed. > > > Heikki, why can't we correct the firmware tables? That needs to be made > > clear > > before we start adding hacks to the kernel. > > We need to start working in that direction really. Fixing problems in ACPI > tables via kernel code is not going to scale sufficiently IMO. Fixing the DSDT produced by the firmware was my first suggesting for this, but it just does not seem to be happening. These products are already out on the market (this is one of them [1]) and what I have understood is that the firmware just is what it is. It's almost as if there is nobody even developing it for these products anymore. Even fixes would not go in and this is not even considered a fix. Things work just find for them with their hacked kernel. So the firmware and the ACPI tables it provides are not going to be fixed. What else can we do? Can we expect the users to always use custom DSDT, or maybe somekind of custom AML snipped (is something like that even possible), when using these products? > > You said, "Bad for Linux", why is this not a problem for other operating > > systems? > > Good question. :-) I would imagine certain operating systems consider a component like PHY as something that should always be handled by the controller driver. It does not seem to be a problem for them even if every second product using the same SoC happens to have different PHY. All of them will have a custom controller driver in any case. Even though the example product below is an Android tablet, to me it looks like the style of writing software comes straight from those "other" operation systems. At least it seems clear that these guys don't understand that it's not possible to do things like write a new driver for every product using the same SoC in Linux. [1] http://www.trekstor.de/detail-surftabs-en/product/surftab-xintron-i-70.html Cheers, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the
Re: [PATCH v2 1/5] irqchip: add dumb demultiplexer implementation
Le 14/01/2015 23:55, Boris Brezillon a écrit : > Hi Rob, > > On Wed, 14 Jan 2015 16:24:32 -0600 > Rob Herring wrote: > >> On Wed, Jan 14, 2015 at 4:36 AM, Thomas Gleixner wrote: >>> On Tue, 13 Jan 2015, Rob Herring wrote: On Tue, Jan 13, 2015 at 12:46 PM, Boris Brezillon wrote: > Some interrupt controllers are multiplexing several peripheral IRQs on > a single interrupt line. > While this is not a problem for most IRQs (as long as all peripherals > request the interrupt with IRQF_SHARED flag set), multiplexing timers and > other type of peripherals will generate a WARNING (mixing IRQF_NO_SUSPEND > and !IRQF_NO_SUSPEND is prohibited). > > Create a dumb irq demultiplexer which simply forwards interrupts to all > peripherals (exactly what's happening with IRQ_SHARED) but keep a unique > irq number for each peripheral, thus preventing the IRQF_NO_SUSPEND > and !IRQF_NO_SUSPEND mix on a given interrupt. This really seems like a work-around for how IRQF_SHARED works. It >>> >>> It's a workaround for a short coming of IRQF_SHARED. >>> >>> IRQF_SHARED has a massive short coming versus suspend and wakeup >>> interrupts. If one of the demultiplexed interrupts is a valid wakeup >>> source then we have no sane way to express this with IRQF_SHARED >>> simply because the drivers need to be aware whether they run on stupid >>> or well designed hardware. >> >> Unfortunately, the drivers will still have to know this. They cannot >> assume that they can call disable_irq and their device irq state does >> not matter. >> >> Perhaps we need a debug feature such that disable_irq/enable_irq are >> nops with IRQF_SHARED? >> seems like what is really desired is just per handler disabling. It is >>> >>> So you want a magic API like disable/enable_irq_action()? >>> >>> Certainly not. >> >> Agreed. >> >>> You'd open just another can of worms which will bring us abuse and >>> hard to debug problems because driver writers think it's a good idea >>> to use it for random purposes. >>> >>> Aside of that it would add another conditional into the interrupt >>> delivery hotpath which is not desired either. >>> fragile in that devices can deadlock the system if the drivers don't disable the interrupt source before calling disable_irq. But unlike >>> >>> Any misdesigned driver can do that for you. >>> IRQF_SHARED, there is nothing explicit in the driver indicating it is designed to work properly with a shared interrupt line. >>> >>> IRQF_SHARED is a pretty bad indicator. Look at all the drivers which >>> slap this flag onto request_irq() and have no single line of code >>> which makes sure that the driver would ever work on a shared line. >>> >>> If it's just for annotational purposes, we can add a new IRQF flag, >>> which is required to request such a interrupt line. >>> I see no reason to accept this into DT either. We already can support shared lines and modeling an OR gate as an interrupt controller is pointless. >>> >>> It's absolutely not pointless. >>> >>> All attempts to work around that have resulted in horrible bandaids so >>> far. That's why I guided Boris to implement this dummy demultiplexing >>> mechanism. It solves the problem at hand nicely without adding nasty >>> hackarounds into the suspend/resume code and inflicting platform >>> knowledge on multi-platform device drivers. >> >> This change will break on old kernels with a new dtb. Would you be >> happy if a BIOS update required a new kernel? Fixing this for any >> platform requires a dtb update which may not be possible on some >> platforms. I don't have a problem with this breakage for 1 platform >> and the at91 guys may not care, but we'd ultimately be changing how >> all shared irqs are specified for all DT. Maybe we decide that this is >> how we want to describe things, but that needs much wider discussion >> and agreement. > > I tried really hard on finding a DT representation that would not break > the DT ABI, but didn't find any easy solution. > How about keeping all platforms with the shared irq pattern, except for > those that really have an irq line shared by a timer and several other > devices (not sure yet, but at91 seems to be the only impacted platform > so far). > >> >>> If you have a proper solution for the problem at hand which >>> >>>- avoids the demux dummy >>> >>>- works straight forward with suspend/resume/wakeup >>> >>>- does not add horrible new APIs >>> >>>- does not add conditionals to the interrupt hotpath >>> >>>- does not inflict platform knowledge about interrupt chip details >>> on drivers >>> >>> then I'm happy to take it. >>> >>> But as long as you can't come up with anything sane, the demux dummy >>> is the best solution for this problem we've seen so far. >> >> What if during suspend you move all actions w/o IRQF_NO_SUSPEND to a >> suspended action list? This would leave only the actions with >>
Re: [PATCH] ARM: clk: add clk-asm9260 driver
Am 15.01.2015 um 00:02 schrieb Mike Turquette:
> Quoting Oleksij Rempel (2015-01-08 00:59:27)
>> diff --git a/drivers/clk/clk-asm9260.c b/drivers/clk/clk-asm9260.c
>> new file mode 100644
>> index 000..6b1c220
>> --- /dev/null
>> +++ b/drivers/clk/clk-asm9260.c
>
>
>
>> +static const char *clk_names[] = {
>> + [REFCLK]= "oscillator",
>> + [SYSPLL]= "pll",
>> + [I2S0_MCLK] = "i2s0_mclk",
>> + [I2S1_MCLK] = "i2s1_mclk",
>> + [RTC_OSC] = "rtc_osc",
>> + [USB_PLL] = "usb_pll",
>> +};
>
> Why keep this list of names? Only clk_names[REFCLK] is used below and it
> is overwritten by the name supplied by DT.
Ok.
>
>
>> +static void __init asm9260_acc_init(struct device_node *np)
>> +{
>> + struct clk *clk;
>> + u32 rate;
>> + int n;
>> + u32 accuracy = 0;
>> +
>> + base = of_io_request_and_map(np, 0, np->name);
>> + if (!base)
>> + panic("%s: unable to map resource", np->name);
>> +
>> + /* register pll */
>> + rate = (ioread32(base + HW_SYSPLLCTRL) & 0x) * 100;
>> +
>> + clk_names[REFCLK] = of_clk_get_parent_name(np, 0);
>> + accuracy = clk_get_accuracy(__clk_lookup(clk_names[REFCLK]));
>> + clk = clk_register_fixed_rate_with_accuracy(NULL, clk_names[SYSPLL],
>> + clk_names[REFCLK], 0, rate, accuracy);
>
> This is different. Why do the PLLs inherit REFCLKs accuracy? Please see
> __clk_recalc_accuracies in drivers/clk/clk.c if you haven't already. We
> propagate accuracy through the clock tree already.
clk_register_fixed_rate overwrite accuracy to 0. If i use
clk_register_fixed_rate, then half of my clocks has accuracy = 0.
>> +
>> + if (IS_ERR(clk))
>> + panic("%s: can't register REFCLK. Check DT!", np->name);
>> +
>> +
>> + /* register clk-provider */
>> + clk_data.clks = clks;
>> + clk_data.clk_num = MAX_CLKS;
>> + of_clk_add_provider(np, of_clk_src_onecell_get, _data);
>> + return;
>> +fail:
>> + iounmap(base);
>> +}
>> +CLK_OF_DECLARE(asm9260_acc, "alphascale,asm9260-clock-controller",
>> + asm9260_acc_init);
>
> Where is the DT binding definition for this clock provider?
>
> Thanks,
> Mike
>
do you mean this patch?
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/293147.html
(probably not last version)
Should i resend it to you?
--
Regards,
Oleksij
signature.asc
Description: OpenPGP digital signature
Re: [PATCHv5 1/2] gpio: sch: Consolidate similar algorithms
On Mon, Dec 8, 2014 at 10:38 AM, Chang Rebecca Swee Fun
wrote:
> Consolidating similar algorithms into common functions to make
> GPIO SCH simpler and manageable.
>
> Signed-off-by: Chang Rebecca Swee Fun
> Reviewed-by: Mika Westerberg
> Reviewed-by: Alexandre Courbot
I have removed this patch from the tree. It breaks completely
in build and looks strange:
> +static void sch_gpio_reg_set(struct gpio_chip *gc, unsigned gpio, unsigned
> reg,
> +int val)
Takes struct gpio_chip * as argument...
> +static int sch_gpio_direction_in(struct gpio_chip *gc, unsigned gpio_num)
> +{
> + struct sch_gpio *sch = to_sch_gpio(gc);
>
> + spin_lock(>lock);
> + sch_gpio_reg_set(sch, gpio_num, GIO, 1);
Passes something else as argument.
> static void sch_gpio_set(struct gpio_chip *gc, unsigned gpio_num, int val)
> {
> struct sch_gpio *sch = to_sch_gpio(gc);
> - u8 curr_vals;
> - unsigned short offset, bit;
>
> spin_lock(>lock);
> -
> - offset = sch_gpio_offset(sch, gpio_num, GLV);
> - bit = sch_gpio_bit(sch, gpio_num);
> -
> - curr_vals = inb(sch->iobase + offset);
> -
> - if (val)
> - outb(curr_vals | (1 << bit), sch->iobase + offset);
> - else
> - outb((curr_vals & ~(1 << bit)), sch->iobase + offset);
> -
> + sch_gpio_reg_set(gc, gpio_num, GLV, val);
Here it is correct.
> @@ -139,18 +123,9 @@ static int sch_gpio_direction_out(struct gpio_chip *gc,
> unsigned gpio_num,
> int val)
> {
> struct sch_gpio *sch = to_sch_gpio(gc);
> - u8 curr_dirs;
> - unsigned short offset, bit;
>
> spin_lock(>lock);
> -
> - offset = sch_gpio_offset(sch, gpio_num, GIO);
> - bit = sch_gpio_bit(sch, gpio_num);
> -
> - curr_dirs = inb(sch->iobase + offset);
> - if (curr_dirs & (1 << bit))
> - outb(curr_dirs & ~(1 << bit), sch->iobase + offset);
> -
> + sch_gpio_reg_set(sch, gpio_num, GIO, 0);
Wrong again. Etc.
Makes me suspect that this patch is not tested at all, so dropped.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2 v3] kprobes: compile out IPMODIFY support if ftrace doesn't support it
If ftrace doesn't claim to support IPMODIFY support, there is no need to
compile IPMODIFY support in kprobes either.
Suggested-by: Masami Hiramatsu
Acked-by: Masami Hiramatsu
Signed-off-by: Jiri Kosina
---
v1 -> v2: nothing
v2 -> v3: add Masami's ack and remove superfluous '== 1' comparsions
kernel/kprobes.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 06f5830..dfb296c 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -912,7 +912,7 @@ static struct kprobe *alloc_aggr_kprobe(struct kprobe *p)
}
#endif /* CONFIG_OPTPROBES */
-#ifdef CONFIG_KPROBES_ON_FTRACE
+#if defined(CONFIG_KPROBES_ON_FTRACE) && (ftrace_ipmodify_supported)
static struct ftrace_ops kprobe_ftrace_ops __read_mostly = {
.func = kprobe_ftrace_handler,
.flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_IPMODIFY,
@@ -957,7 +957,7 @@ static void disarm_kprobe_ftrace(struct kprobe *p)
(unsigned long)p->addr, 1, 0);
WARN(ret < 0, "Failed to disarm kprobe-ftrace at %p (%d)\n", p->addr,
ret);
}
-#else /* !CONFIG_KPROBES_ON_FTRACE */
+#else /* !CONFIG_KPROBES_ON_FTRACE || !ftrace_ipmodify_supported */
#define prepare_kprobe(p) arch_prepare_kprobe(p)
#define arm_kprobe_ftrace(p) do {} while (0)
#define disarm_kprobe_ftrace(p)do {} while (0)
@@ -1416,12 +1416,12 @@ int __weak arch_check_ftrace_location(struct kprobe *p)
ftrace_addr = ftrace_location((unsigned long)p->addr);
if (ftrace_addr) {
-#ifdef CONFIG_KPROBES_ON_FTRACE
+#if defined(CONFIG_KPROBES_ON_FTRACE) && (ftrace_ipmodify_supported)
/* Given address is not on the instruction boundary */
if ((unsigned long)p->addr != ftrace_addr)
return -EILSEQ;
p->flags |= KPROBE_FLAG_FTRACE;
-#else /* !CONFIG_KPROBES_ON_FTRACE */
+#else /* !CONFIG_KPROBES_ON_FTRACE || !ftrace_ipmodify_supported */
return -EINVAL;
#endif
}
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2 v3] ftrace: don't allow IPMODIFY without proper compiler support
Using IPMODIFY needs to be allowed only with compilers which are
guaranteed to generate function prologues compatible with function
redirection through changing instruction pointer in saved regs.
For example changing regs->ip on x86_64 in cases when gcc is using mcount
(and not fentry) is not allowed, because at the time mcount call is
issued, the original function's prologue has already been executed, which
leads to all kinds of inconsistent havoc.
There is currently no way to express dependency on gcc features in
Kconfig, (CC_USING_FENTRY is defined only during build, so it's not
possible for Kconfig symbol to depend on it) so this needs to be checked
in runtime.
Mark x86_64 with fentry supported for now. Other archs can be added
gradually.
Signed-off-by: Jiri Kosina
---
v1 -> v2: turn macro function into a plain macro
v2 -> v3: return ENOTSUPP and reject registering ftrace_ops in
ftrace_hash_move() already
arch/x86/include/asm/ftrace.h | 2 ++
include/linux/ftrace.h| 5 +
kernel/trace/ftrace.c | 5 +
3 files changed, 12 insertions(+)
diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index f45acad..f84eaaf 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -4,8 +4,10 @@
#ifdef CONFIG_FUNCTION_TRACER
#ifdef CC_USING_FENTRY
# define MCOUNT_ADDR ((long)(__fentry__))
+# define ftrace_ipmodify_supported 1
#else
# define MCOUNT_ADDR ((long)(mcount))
+# define ftrace_ipmodify_supported 0
#endif
#define MCOUNT_INSN_SIZE 5 /* sizeof mcount call */
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 1da6029..837153a 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -244,6 +244,11 @@ static inline int ftrace_function_local_disabled(struct
ftrace_ops *ops)
extern void ftrace_stub(unsigned long a0, unsigned long a1,
struct ftrace_ops *op, struct pt_regs *regs);
+#ifndef ftrace_ipmodify_supported
+/* let's not make any implicit assumptions about profiling call placement */
+# define ftrace_ipmodify_supported 0
+
+#endif
#else /* !CONFIG_FUNCTION_TRACER */
/*
* (un)register_ftrace_function must be a macro since the ops parameter
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 929a733..3c1261c 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -1378,6 +1378,11 @@ ftrace_hash_move(struct ftrace_ops *ops, int enable,
if (ops->flags & FTRACE_OPS_FL_IPMODIFY && !enable)
return -EINVAL;
+ if ((ops->flags & FTRACE_OPS_FL_IPMODIFY) &&
!ftrace_ipmodify_supported) {
+ WARN(1, "Your compiler doesn't support features necessary for
IPMODIFY");
+ return -ENOTSUPP;
+ }
+
/*
* If the new source is empty, just free dst and assign it
* the empty_hash.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux 3.12.36
I'm announcing the release of the 3.12.36 kernel. All users of the 3.12 kernel series must upgrade. The updated 3.12.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.12.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary Alexander Kochetkov (2): i2c: omap: fix NACK and Arbitration Lost irq handling i2c: omap: fix i207 errata handling Andreas Müller (1): mac80211: fix multicast LED blinking and counter Andrew Morton (1): mm/vmpressure.c: fix race in vmpressure_work_fn() Andy Lutomirski (4): x86/tls: Validate TLS entries to protect espfix x86/tls: Disallow unusual TLS segments x86, kvm: Clear paravirt_enabled on KVM guests for espfix32's benefit x86/tls: Don't validate lm in set_thread_area() after all Anton Blanchard (1): powerpc: 32 bit getcpu VDSO function uses 64 bit instructions Baruch Siach (1): mmc: block: add newline to sysfs display of force_ro Dan Carpenter (1): dm space map metadata: fix sm_bootstrap_get_nr_blocks() Daniel Borkmann (1): net: sctp: use MAX_HEADER for headroom reserve in output path Daniel Forrest (1): mm: fix anon_vma_clone() error treatment Daniel Vetter (2): drm/i915: More cautious with pch fifo underruns drm/i915: Unlock panel even when LVDS is disabled Darrick J. Wong (1): dm bufio: fix memleak when using a dm_buffer's inline bio Devin Ryles (1): AHCI: Add DeviceIDs for Sunrise Point-LP SATA controller Dmitry Eremin-Solenikov (1): mfd: tc6393xb: Fail ohci suspend if full state restore is required Dmitry Torokhov (1): sata_fsl: fix error handling of irq_of_parse_and_map Eric Dumazet (1): net: mvneta: fix race condition in mvneta_tx() Eric W. Biederman (13): mnt: Implicitly add MNT_NODEV on remount when it was implicitly added by mount mnt: Update unprivileged remount test umount: Disallow unprivileged mount force groups: Consolidate the setgroups permission checks userns: Document what the invariant required for safe unprivileged mappings. userns: Don't allow setgroups until a gid mapping has been setablished userns: Don't allow unprivileged creation of gid mappings userns: Check euid no fsuid when establishing an unprivileged uid mapping userns: Only allow the creator of the userns unprivileged mappings userns: Rename id_map_mutex to userns_state_mutex userns: Add a knob to disable setgroups on a per user namespace basis userns: Allow setting gid_maps without privilege when setgroups is disabled userns: Unbreak the unprivileged remount tests Filipe Manana (1): Btrfs: fix fs corruption on transaction abort if device supports discard Francesco Ruggeri (1): tty: Fix pty master poll() after slave closes v2 Grygorii Strashko (1): i2c: davinci: generate STP always when NACK is received Hannes Reinecke (1): scsi: correct return values for .eh_abort_handler implementations Hugh Dickins (2): mm: fix swapoff hang after page migration and fork mm: let mm_find_pmd fix buggy race with THP fault Jack Morgenstein (1): net/mlx4_core: Limit count field to 24 bits in qp_alloc_res Jan Kara (4): isofs: Fix infinite looping over CE entries isofs: Fix unchecked printing of ER records ncpfs: return proper error from NCP_IOC_SETROOT ioctl udf: Verify symlink size before loading it Jiri Slaby (1): Linux 3.12.36 Johan Hovold (1): mfd: viperboard: Fix platform-device id collision Johannes Berg (1): mac80211: free management frame keys when removing station Josef Bacik (1): Btrfs: do not move em to modified list when unpinning Kan Liang (1): perf/x86/intel: Protect LBR and extra_regs against KVM lying Kirill A. Shutemov (1): thp: close race between split and zap huge pages Linus Walleij (1): mfd: stmpe: Fix STMPE24xx GPMR LSB Luis Henriques (1): thermal: Fix error path in thermal_init() Marcelo Leitner (1): Fix race condition between vxlan_sock_add and vxlan_sock_release Martin Schwidefsky (2): s390/3215: fix hanging console issue s390/3215: fix tty output containing tabs Mathias Nyman (1): USB: xhci: Reset a halted endpoint immediately when we encounter a stall. Michael Halcrow (1): eCryptfs: Remove buggy and unnecessary write in file name decode routine Nicolas Dichtel (1): rtnetlink: release net refcnt on error in do_setlink() Oleg Nesterov (1): exit: pidns: alloc_pid() leaks pid_namespace if child_reaper is exiting Peng Tao (1): nfs41: fix nfs4_proc_layoutget error handling Peter Zijlstra (1): perf/x86: Correctly use FEATURE_PDCM Petr Mladek (1): drm/radeon: kernel
[PATCH] coresight: fix the debug AMBA bus name
The right debug AMBA bus name should be APB(Advanced Peripheral Bus), so just fix it. Signed-off-by: Kaixu Xia --- Documentation/trace/coresight.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt index bba7dbf..0236155 100644 --- a/Documentation/trace/coresight.txt +++ b/Documentation/trace/coresight.txt @@ -46,7 +46,7 @@ At typical coresight system would look like this: | | .| ! | | .| ! | !. | | SWD/ | | .| ! | | .| ! | !. | | JTAG *<-| - *** AMBA Debug ABP + *** AMBA Debug APB * |. ! . !!.| |. * . **.| @@ -79,7 +79,7 @@ At typical coresight system would look like this: To trace port TPIU= Trace Port Interface Unit SWD = Serial Wire Debug -While on target configuration of the components is done via the ABP bus, +While on target configuration of the components is done via the APB bus, all trace data are carried out-of-band on the ATB bus. The CTM provides a way to aggregate and distribute signals between CoreSight components. -- 1.8.5.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/3] mmc: Add dynamic frequency scaling
On 15 January 2015 at 10:20, Krzysztof Kozlowski wrote: > On czw, 2015-01-15 at 09:20 +0100, Ulf Hansson wrote: >> + Mike, Stephen (Clock maintainers) >> >> On 12 January 2015 at 10:23, Krzysztof Kozlowski >> wrote: >> > Hi, >> > >> > >> > I would like to hear some comments about idea of scaling MMC clock >> > frequency. The basic idea is to lower the clock when device is >> > completely idle or not busy enough. >> >> We already have host drivers that implements runtime PM support. >> Typically that would mean the clock will be gated once the device >> becomes runtime PM suspended. >> >> Why should we decrease the frequency of an already gated clock? > > In case of idle state you're right that clkgate would be better. But > what about finding a compromise between high performance (high > frequency) and energy saving for different loads on MMC? I guess a compromise could be beneficial for some SOC and use cases. At least I remember, ST-Ericsson's UX500 SOC had such an out of tree hack to track MMC load. > > The frequency scaling could help in that case. Anyway I should prepare > some more benchmarks for such conditions. Seems reasonable and please do! Kind regards Uffe -- 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 1/2] fixup! net/macb: Adding comments to various #defs to make interpretation easier
Le 14/01/2015 23:20, Xander Huff a écrit : > Put #define comments into a single line. It seems that correction is not done for all the entries modified: @ 0x0100 to 0x01b0 Can you please consider correcting this? Thanks, bye. > Signed-off-by: Xander Huff > --- > drivers/net/ethernet/cadence/macb.h | 107 > +--- > 1 file changed, 26 insertions(+), 81 deletions(-) > > diff --git a/drivers/net/ethernet/cadence/macb.h > b/drivers/net/ethernet/cadence/macb.h > index 378b218..d7b93d0 100644 > --- a/drivers/net/ethernet/cadence/macb.h > +++ b/drivers/net/ethernet/cadence/macb.h > @@ -275,9 +275,7 @@ > #define MACB_THALT_SIZE 1 > #define MACB_NCR_TPF_OFFSET 11 /* Transmit pause frame */ > #define MACB_NCR_TPF_SIZE1 > -#define MACB_TZQ_OFFSET 12 /* Transmit zero > quantum > - * pause frame > - */ > +#define MACB_TZQ_OFFSET 12 /* Transmit zero > quantum pause frame */ > #define MACB_TZQ_SIZE1 > > /* Bitfields in NCFGR */ > @@ -299,9 +297,7 @@ > #define MACB_UNI_SIZE1 > #define MACB_BIG_OFFSET 8 /* Receive 1536 byte > frames */ > #define MACB_BIG_SIZE1 > -#define MACB_EAE_OFFSET 9 /* External address > match > -* enable > -*/ > +#define MACB_EAE_OFFSET 9 /* External address > match enable */ > #define MACB_EAE_SIZE1 > #define MACB_CLK_OFFSET 10 > #define MACB_CLK_SIZE2 > @@ -313,9 +309,7 @@ > #define MACB_RM9200_RMII_SIZE1 /* AT91RM9200 only */ > #define MACB_RBOF_OFFSET 14 /* Receive buffer offset */ > #define MACB_RBOF_SIZE 2 > -#define MACB_RLCE_OFFSET 16 /* Length field error frame > - * discard > - */ > +#define MACB_RLCE_OFFSET 16 /* Length field error frame > discard */ > #define MACB_RLCE_SIZE 1 > #define MACB_DRFCS_OFFSET17 /* FCS remove */ > #define MACB_DRFCS_SIZE 1 > @@ -335,41 +329,22 @@ > #define GEM_RXCOEN_SIZE 1 > > /* Constants for data bus width. */ > -#define GEM_DBW320 /* 32 bit AMBA AHB data bus > -* width > -*/ > -#define GEM_DBW641 /* 64 bit AMBA AHB data bus > -* width > -*/ > -#define GEM_DBW128 2 /* 128 bit AMBA AHB data bus > -* width > -*/ > +#define GEM_DBW320 /* 32 bit AMBA AHB data bus > width */ > +#define GEM_DBW641 /* 64 bit AMBA AHB data bus > width */ > +#define GEM_DBW128 2 /* 128 bit AMBA AHB data bus > width */ > > /* Bitfields in DMACFG. */ > -#define GEM_FBLDO_OFFSET 0 /* AHB fixed burst length for > -* DMA data operations > -*/ > +#define GEM_FBLDO_OFFSET 0 /* AHB fixed burst length for > DMA data operations */ > #define GEM_FBLDO_SIZE 5 > -#define GEM_ENDIA_OFFSET 7 /* AHB endian swap mode enable > -* for packet data accesses > -*/ > +#define GEM_ENDIA_OFFSET 7 /* AHB endian swap mode > enable for packet data accesses */ > #define GEM_ENDIA_SIZE 1 > -#define GEM_RXBMS_OFFSET 8 /* Receiver packet buffer > -* memory size select > -*/ > +#define GEM_RXBMS_OFFSET 8 /* Receiver packet buffer > memory size select */ > #define GEM_RXBMS_SIZE 2 > -#define GEM_TXPBMS_OFFSET10 /* Transmitter packet buffer > - * memory size select > - */ > +#define GEM_TXPBMS_OFFSET
[PATCH] mac80211: Fix typo in mac80211.h
This patch fix spelling typo found in Documentation/DocBook/80211.xml.
It is because this file was generated from comments in source,
I had to fix in include/net/mac80211.h
Signed-off-by: Masanari Iida
---
include/net/mac80211.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 29c7be8..a9a6213 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1292,7 +1292,7 @@ struct ieee80211_vif *wdev_to_ieee80211_vif(struct
wireless_dev *wdev);
* %IEEE80211_KEY_FLAG_SW_MGMT_TX flag to encrypt such frames in SW.
* @IEEE80211_KEY_FLAG_GENERATE_IV_MGMT: This flag should be set by the
* driver for a CCMP key to indicate that is requires IV generation
- * only for managment frames (MFP).
+ * only for management frames (MFP).
*/
enum ieee80211_key_flags {
IEEE80211_KEY_FLAG_GENERATE_IV_MGMT = BIT(0),
@@ -4894,7 +4894,7 @@ static inline int rate_supported(struct ieee80211_sta
*sta,
* @sta: ieee80211_sta pointer to the target destination. Note
* that this may be null.
* @priv_sta: private rate control structure. This may be null.
- * @txrc: rate control information we sholud populate for mac80211.
+ * @txrc: rate control information we should populate for mac80211.
*/
bool rate_control_send_low(struct ieee80211_sta *sta,
void *priv_sta,
--
2.3.0.rc0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] ARM: sa1100: add platform functions to handle PWER settings
PWER settings logically belongs neither to GPIO nor to system IRQ code.
Add special functions to handle PWER (for GPIO and for system IRQs)
from platform code.
Signed-off-by: Dmitry Eremin-Solenikov
---
arch/arm/mach-sa1100/generic.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/mach-sa1100/generic.c b/arch/arm/mach-sa1100/generic.c
index 40e0d86..022e451 100644
--- a/arch/arm/mach-sa1100/generic.c
+++ b/arch/arm/mach-sa1100/generic.c
@@ -416,3 +416,24 @@ void sa1110_mb_enable(void)
local_irq_restore(flags);
}
+int sa11x0_gpio_set_wake(unsigned int gpio, unsigned int on)
+{
+ if (on)
+ PWER |= BIT(gpio);
+ else
+ PWER &= ~BIT(gpio);
+
+ return 0;
+}
+
+int sa11x0_sc_set_wake(unsigned int irq, unsigned int on)
+{
+ if (BIT(irq) != IC_RTCAlrm)
+ return -EINVAL;
+
+ if (on)
+ PWER |= PWER_RTC;
+ else
+ PWER &= ~PWER_RTC;
+ return 0;
+}
--
2.1.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 2/5] ARM: sa1100: use sa11x0_sc_set_wake() in irq driver
Use new function controlling PWER register in IRQ driver.
Signed-off-by: Dmitry Eremin-Solenikov
---
arch/arm/mach-sa1100/irq.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/arm/mach-sa1100/irq.c b/arch/arm/mach-sa1100/irq.c
index 65aebfa..7a5aa56 100644
--- a/arch/arm/mach-sa1100/irq.c
+++ b/arch/arm/mach-sa1100/irq.c
@@ -40,19 +40,9 @@ static void sa1100_unmask_irq(struct irq_data *d)
ICMR |= BIT(d->hwirq);
}
-/*
- * Apart form GPIOs, only the RTC alarm can be a wakeup event.
- */
static int sa1100_set_wake(struct irq_data *d, unsigned int on)
{
- if (BIT(d->hwirq) == IC_RTCAlrm) {
- if (on)
- PWER |= PWER_RTC;
- else
- PWER &= ~PWER_RTC;
- return 0;
- }
- return -EINVAL;
+ return sa11x0_sc_set_wake(d->hwirq, on);
}
static struct irq_chip sa1100_normal_chip = {
--
2.1.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 4/5] irqchip: add sa1100 driver
Add an irqchip driver for Intel StrongARM SA-11x0 family of chips. For
now it is just a copy of the current arch/arm/mach-sa1100/irq.c driver.
Signed-off-by: Dmitry Eremin-Solenikov
---
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-sa11x0.c | 185 +
include/linux/irqchip/irq-sa11x0.h | 18
3 files changed, 204 insertions(+)
create mode 100644 drivers/irqchip/irq-sa11x0.c
create mode 100644 include/linux/irqchip/irq-sa11x0.h
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 9516a32..b0d1dde 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -42,3 +42,4 @@ obj-$(CONFIG_BRCMSTB_L2_IRQ) += irq-brcmstb-l2.o
obj-$(CONFIG_KEYSTONE_IRQ) += irq-keystone.o
obj-$(CONFIG_MIPS_GIC) += irq-mips-gic.o
obj-$(CONFIG_ARCH_MEDIATEK)+= irq-mtk-sysirq.o
+obj-$(CONFIG_ARCH_SA1100) += irq-sa11x0.o
diff --git a/drivers/irqchip/irq-sa11x0.c b/drivers/irqchip/irq-sa11x0.c
new file mode 100644
index 000..c840187
--- /dev/null
+++ b/drivers/irqchip/irq-sa11x0.c
@@ -0,0 +1,185 @@
+/*
+ * drivers/irqchip/irq-sa11x0.c
+ *
+ * Copyright (C) 1999-2001 Nicolas Pitre
+ *
+ * Generic IRQ handling for the SA11x0.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define ICIP 0x00 /* IC IRQ Pending reg. */
+#define ICMR 0x04 /* IC Mask Reg.*/
+#define ICLR 0x08 /* IC Level Reg. */
+#define ICCR 0x0C /* IC Control Reg. */
+#define ICFP 0x10 /* IC FIQ Pending reg. */
+#define ICPR 0x20 /* IC Pending Reg. */
+
+static void __iomem *iobase;
+static DEFINE_RAW_SPINLOCK(lock);
+
+/*
+ * We don't need to ACK IRQs on the SA1100 unless they're GPIOs
+ * this is for internal IRQs i.e. from IRQ LCD to RTCAlrm.
+ */
+static void sa1100_mask_irq(struct irq_data *d)
+{
+ u32 reg;
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(, flags);
+
+ reg = readl_relaxed(iobase + ICMR);
+ reg &= ~BIT(d->hwirq);
+ writel_relaxed(reg, iobase + ICMR);
+
+ raw_spin_unlock_irqrestore(, flags);
+}
+
+static void sa1100_unmask_irq(struct irq_data *d)
+{
+ u32 reg;
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(, flags);
+
+ reg = readl_relaxed(iobase + ICMR);
+ reg |= BIT(d->hwirq);
+ writel_relaxed(reg, iobase + ICMR);
+
+ raw_spin_unlock_irqrestore(, flags);
+}
+
+static int sa1100_set_wake(struct irq_data *d, unsigned int on)
+{
+ return sa11x0_sc_set_wake(d->hwirq, on);
+}
+
+static struct irq_chip sa1100_normal_chip = {
+ .name = "SC",
+ .irq_ack= sa1100_mask_irq,
+ .irq_mask = sa1100_mask_irq,
+ .irq_unmask = sa1100_unmask_irq,
+ .irq_set_wake = sa1100_set_wake,
+};
+
+static int sa1100_normal_irqdomain_map(struct irq_domain *d,
+ unsigned int irq, irq_hw_number_t hwirq)
+{
+ irq_set_chip_and_handler(irq, _normal_chip,
+handle_level_irq);
+ set_irq_flags(irq, IRQF_VALID);
+
+ return 0;
+}
+
+static struct irq_domain_ops sa1100_normal_irqdomain_ops = {
+ .map = sa1100_normal_irqdomain_map,
+ .xlate = irq_domain_xlate_onetwocell,
+};
+
+static struct irq_domain *sa1100_normal_irqdomain;
+
+static struct sa1100irq_state {
+ unsigned intsaved;
+ unsigned inticmr;
+ unsigned inticlr;
+ unsigned inticcr;
+} sa1100irq_state;
+
+static int sa1100irq_suspend(void)
+{
+ struct sa1100irq_state *st = _state;
+
+ st->saved = 1;
+ st->icmr = readl_relaxed(iobase + ICMR);
+ st->iclr = readl_relaxed(iobase + ICLR);
+ st->iccr = readl_relaxed(iobase + ICCR);
+
+ /*
+* Disable all GPIO-based interrupts.
+*/
+ writel_relaxed(st->icmr & 0xf000, iobase + ICMR);
+
+ return 0;
+}
+
+static void sa1100irq_resume(void)
+{
+ struct sa1100irq_state *st = _state;
+
+ if (st->saved) {
+ writel_relaxed(st->iccr, iobase + ICCR);
+ writel_relaxed(st->iclr, iobase + ICLR);
+
+ writel_relaxed(st->icmr, iobase + ICMR);
+ }
+}
+
+static struct syscore_ops sa1100irq_syscore_ops = {
+ .suspend= sa1100irq_suspend,
+ .resume = sa1100irq_resume,
+};
+
+static int __init sa1100irq_init_devicefs(void)
+{
+ register_syscore_ops(_syscore_ops);
+ return 0;
+}
+
+device_initcall(sa1100irq_init_devicefs);
+
+static asmlinkage void __exception_irq_entry
+sa1100_handle_irq(struct pt_regs *regs)
+{
+ uint32_t icip, icmr, mask;
+
+ do {
+ icip = readl_relaxed(iobase + ICIP);
+ icmr =
[PATCH 3/5] ARM: sa1100: use ioremapped memory to access SC registers
Use ioremap() and readl/writel_relaxed() to access IRQ controller
registers.
Signed-off-by: Dmitry Eremin-Solenikov
---
arch/arm/mach-sa1100/irq.c | 63 +-
1 file changed, 45 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-sa1100/irq.c b/arch/arm/mach-sa1100/irq.c
index 7a5aa56..66464fd 100644
--- a/arch/arm/mach-sa1100/irq.c
+++ b/arch/arm/mach-sa1100/irq.c
@@ -18,13 +18,20 @@
#include
#include
-#include
#include
-#include
#include
#include "generic.h"
+#define ICIP 0x00 /* IC IRQ Pending reg. */
+#define ICMR 0x04 /* IC Mask Reg.*/
+#define ICLR 0x08 /* IC Level Reg. */
+#define ICCR 0x0C /* IC Control Reg. */
+#define ICFP 0x10 /* IC FIQ Pending reg. */
+#define ICPR 0x20 /* IC Pending Reg. */
+
+static void __iomem *iobase;
+static DEFINE_RAW_SPINLOCK(lock);
/*
* We don't need to ACK IRQs on the SA1100 unless they're GPIOs
@@ -32,12 +39,30 @@
*/
static void sa1100_mask_irq(struct irq_data *d)
{
- ICMR &= ~BIT(d->hwirq);
+ u32 reg;
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(, flags);
+
+ reg = readl_relaxed(iobase + ICMR);
+ reg &= ~BIT(d->hwirq);
+ writel_relaxed(reg, iobase + ICMR);
+
+ raw_spin_unlock_irqrestore(, flags);
}
static void sa1100_unmask_irq(struct irq_data *d)
{
- ICMR |= BIT(d->hwirq);
+ u32 reg;
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(, flags);
+
+ reg = readl_relaxed(iobase + ICMR);
+ reg |= BIT(d->hwirq);
+ writel_relaxed(reg, iobase + ICMR);
+
+ raw_spin_unlock_irqrestore(, flags);
}
static int sa1100_set_wake(struct irq_data *d, unsigned int on)
@@ -85,16 +110,14 @@ static int sa1100irq_suspend(void)
struct sa1100irq_state *st = _state;
st->saved = 1;
- st->icmr = ICMR;
- st->iclr = ICLR;
- st->iccr = ICCR;
+ st->icmr = readl_relaxed(iobase + ICMR);
+ st->iclr = readl_relaxed(iobase + ICLR);
+ st->iccr = readl_relaxed(iobase + ICCR);
/*
* Disable all GPIO-based interrupts.
*/
- ICMR &= ~(IC_GPIO11_27|IC_GPIO10|IC_GPIO9|IC_GPIO8|IC_GPIO7|
- IC_GPIO6|IC_GPIO5|IC_GPIO4|IC_GPIO3|IC_GPIO2|
- IC_GPIO1|IC_GPIO0);
+ writel_relaxed(st->icmr & 0xf000, iobase + ICMR);
return 0;
}
@@ -104,10 +127,10 @@ static void sa1100irq_resume(void)
struct sa1100irq_state *st = _state;
if (st->saved) {
- ICCR = st->iccr;
- ICLR = st->iclr;
+ writel_relaxed(st->iccr, iobase + ICCR);
+ writel_relaxed(st->iclr, iobase + ICLR);
- ICMR = st->icmr;
+ writel_relaxed(st->icmr, iobase + ICMR);
}
}
@@ -130,8 +153,8 @@ sa1100_handle_irq(struct pt_regs *regs)
uint32_t icip, icmr, mask;
do {
- icip = (ICIP);
- icmr = (ICMR);
+ icip = readl_relaxed(iobase + ICIP);
+ icmr = readl_relaxed(iobase + ICMR);
mask = icip & icmr;
if (mask == 0)
@@ -146,17 +169,21 @@ void __init sa1100_init_irq(void)
{
request_resource(_resource, _resource);
+ iobase = ioremap(irq_resource.start, SZ_64K);
+ if (WARN_ON(!iobase))
+ return;
+
/* disable all IRQs */
- ICMR = 0;
+ writel_relaxed(0, iobase + ICMR);
/* all IRQs are IRQ, not FIQ */
- ICLR = 0;
+ writel_relaxed(0, iobase + ICLR);
/*
* Whatever the doc says, this has to be set for the wait-on-irq
* instruction to work... on a SA1100 rev 9 at least.
*/
- ICCR = 1;
+ writel_relaxed(1, iobase + ICCR);
sa1100_normal_irqdomain = irq_domain_add_simple(NULL,
32, IRQ_GPIO0_SC,
--
2.1.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 5/5] ARM: sa1100: drop irq driver
Drop irq driver for sa1100 in favour of irqchip driver replacement.
Signed-off-by: Dmitry Eremin-Solenikov
---
arch/arm/mach-sa1100/Makefile | 2 +-
arch/arm/mach-sa1100/generic.c | 13 +++
arch/arm/mach-sa1100/irq.c | 195 -
3 files changed, 14 insertions(+), 196 deletions(-)
delete mode 100644 arch/arm/mach-sa1100/irq.c
diff --git a/arch/arm/mach-sa1100/Makefile b/arch/arm/mach-sa1100/Makefile
index 61ff91e..ebc4d58 100644
--- a/arch/arm/mach-sa1100/Makefile
+++ b/arch/arm/mach-sa1100/Makefile
@@ -3,7 +3,7 @@
#
# Common support
-obj-y := clock.o generic.o irq.o #nmi-oopser.o
+obj-y := clock.o generic.o #nmi-oopser.o
# Specific board support
obj-$(CONFIG_SA1100_ASSABET) += assabet.o
diff --git a/arch/arm/mach-sa1100/generic.c b/arch/arm/mach-sa1100/generic.c
index 022e451..3fdc16b 100644
--- a/arch/arm/mach-sa1100/generic.c
+++ b/arch/arm/mach-sa1100/generic.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
@@ -375,6 +376,18 @@ void __init sa1100_timer_init(void)
pxa_timer_nodt_init(IRQ_OST0, io_p2v(0x9000), 3686400);
}
+static struct resource irq_resource =
+ DEFINE_RES_MEM_NAMED(0x9005, SZ_64K, "irqs");
+
+void __init sa1100_init_irq(void)
+{
+ request_resource(_resource, _resource);
+
+ sa11x0_init_irq_nodt(IRQ_GPIO0_SC, irq_resource.start);
+
+ sa1100_init_gpio();
+}
+
/*
* Disable the memory bus request/grant signals on the SA1110 to
* ensure that we don't receive spurious memory requests. We set
diff --git a/arch/arm/mach-sa1100/irq.c b/arch/arm/mach-sa1100/irq.c
deleted file mode 100644
index 66464fd..000
--- a/arch/arm/mach-sa1100/irq.c
+++ /dev/null
@@ -1,195 +0,0 @@
-/*
- * linux/arch/arm/mach-sa1100/irq.c
- *
- * Copyright (C) 1999-2001 Nicolas Pitre
- *
- * Generic IRQ handling for the SA11x0, GPIO 11-27 IRQ demultiplexing.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-
-#include "generic.h"
-
-#define ICIP 0x00 /* IC IRQ Pending reg. */
-#define ICMR 0x04 /* IC Mask Reg.*/
-#define ICLR 0x08 /* IC Level Reg. */
-#define ICCR 0x0C /* IC Control Reg. */
-#define ICFP 0x10 /* IC FIQ Pending reg. */
-#define ICPR 0x20 /* IC Pending Reg. */
-
-static void __iomem *iobase;
-static DEFINE_RAW_SPINLOCK(lock);
-
-/*
- * We don't need to ACK IRQs on the SA1100 unless they're GPIOs
- * this is for internal IRQs i.e. from IRQ LCD to RTCAlrm.
- */
-static void sa1100_mask_irq(struct irq_data *d)
-{
- u32 reg;
- unsigned long flags;
-
- raw_spin_lock_irqsave(, flags);
-
- reg = readl_relaxed(iobase + ICMR);
- reg &= ~BIT(d->hwirq);
- writel_relaxed(reg, iobase + ICMR);
-
- raw_spin_unlock_irqrestore(, flags);
-}
-
-static void sa1100_unmask_irq(struct irq_data *d)
-{
- u32 reg;
- unsigned long flags;
-
- raw_spin_lock_irqsave(, flags);
-
- reg = readl_relaxed(iobase + ICMR);
- reg |= BIT(d->hwirq);
- writel_relaxed(reg, iobase + ICMR);
-
- raw_spin_unlock_irqrestore(, flags);
-}
-
-static int sa1100_set_wake(struct irq_data *d, unsigned int on)
-{
- return sa11x0_sc_set_wake(d->hwirq, on);
-}
-
-static struct irq_chip sa1100_normal_chip = {
- .name = "SC",
- .irq_ack= sa1100_mask_irq,
- .irq_mask = sa1100_mask_irq,
- .irq_unmask = sa1100_unmask_irq,
- .irq_set_wake = sa1100_set_wake,
-};
-
-static int sa1100_normal_irqdomain_map(struct irq_domain *d,
- unsigned int irq, irq_hw_number_t hwirq)
-{
- irq_set_chip_and_handler(irq, _normal_chip,
-handle_level_irq);
- set_irq_flags(irq, IRQF_VALID);
-
- return 0;
-}
-
-static struct irq_domain_ops sa1100_normal_irqdomain_ops = {
- .map = sa1100_normal_irqdomain_map,
- .xlate = irq_domain_xlate_onetwocell,
-};
-
-static struct irq_domain *sa1100_normal_irqdomain;
-
-static struct resource irq_resource =
- DEFINE_RES_MEM_NAMED(0x9005, SZ_64K, "irqs");
-
-static struct sa1100irq_state {
- unsigned intsaved;
- unsigned inticmr;
- unsigned inticlr;
- unsigned inticcr;
-} sa1100irq_state;
-
-static int sa1100irq_suspend(void)
-{
- struct sa1100irq_state *st = _state;
-
- st->saved = 1;
- st->icmr = readl_relaxed(iobase + ICMR);
- st->iclr = readl_relaxed(iobase + ICLR);
- st->iccr = readl_relaxed(iobase + ICCR);
-
- /*
-* Disable all GPIO-based interrupts.
-*/
- writel_relaxed(st->icmr & 0xf000, iobase + ICMR);
-
- return 0;
-}
-
-static void sa1100irq_resume(void)
-{
-
Re: [PATCHv5 1/2] gpio: sch: Consolidate similar algorithms
On Thu, Jan 15, 2015 at 6:49 PM, Linus Walleij wrote:
> On Mon, Dec 8, 2014 at 10:38 AM, Chang Rebecca Swee Fun
> wrote:
>
>> Consolidating similar algorithms into common functions to make
>> GPIO SCH simpler and manageable.
>>
>> Signed-off-by: Chang Rebecca Swee Fun
>> Reviewed-by: Mika Westerberg
>> Reviewed-by: Alexandre Courbot
>
> I have removed this patch from the tree. It breaks completely
> in build and looks strange:
>
>> +static void sch_gpio_reg_set(struct gpio_chip *gc, unsigned gpio, unsigned
>> reg,
>> +int val)
>
> Takes struct gpio_chip * as argument...
>
>> +static int sch_gpio_direction_in(struct gpio_chip *gc, unsigned gpio_num)
>> +{
>> + struct sch_gpio *sch = to_sch_gpio(gc);
>>
>> + spin_lock(>lock);
>> + sch_gpio_reg_set(sch, gpio_num, GIO, 1);
>
> Passes something else as argument.
>
>> static void sch_gpio_set(struct gpio_chip *gc, unsigned gpio_num, int val)
>> {
>> struct sch_gpio *sch = to_sch_gpio(gc);
>> - u8 curr_vals;
>> - unsigned short offset, bit;
>>
>> spin_lock(>lock);
>> -
>> - offset = sch_gpio_offset(sch, gpio_num, GLV);
>> - bit = sch_gpio_bit(sch, gpio_num);
>> -
>> - curr_vals = inb(sch->iobase + offset);
>> -
>> - if (val)
>> - outb(curr_vals | (1 << bit), sch->iobase + offset);
>> - else
>> - outb((curr_vals & ~(1 << bit)), sch->iobase + offset);
>> -
>> + sch_gpio_reg_set(gc, gpio_num, GLV, val);
>
> Here it is correct.
>
>> @@ -139,18 +123,9 @@ static int sch_gpio_direction_out(struct gpio_chip *gc,
>> unsigned gpio_num,
>> int val)
>> {
>> struct sch_gpio *sch = to_sch_gpio(gc);
>> - u8 curr_dirs;
>> - unsigned short offset, bit;
>>
>> spin_lock(>lock);
>> -
>> - offset = sch_gpio_offset(sch, gpio_num, GIO);
>> - bit = sch_gpio_bit(sch, gpio_num);
>> -
>> - curr_dirs = inb(sch->iobase + offset);
>> - if (curr_dirs & (1 << bit))
>> - outb(curr_dirs & ~(1 << bit), sch->iobase + offset);
>> -
>> + sch_gpio_reg_set(sch, gpio_num, GIO, 0);
>
> Wrong again. Etc.
>
> Makes me suspect that this patch is not tested at all, so dropped.
IIRC at least one of the previous versions had the same issue and at
that time I already pointed out that *compiling and testing* patches
before sending them in the wild is common sense.
Ironically the cover letter says "The patches has been verifed and
tested working on Galileo Board". One may wonder...
--
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 RESEND v9 09/10] sched: add SD_PREFER_SIBLING for SMT level
Add the SD_PREFER_SIBLING flag for SMT level in order to ensure that
the scheduler will put at least 1 task per core.
Signed-off-by: Vincent Guittot
Reviewed-by: Preeti U. Murthy
---
kernel/sched/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 37fb92c..731f2ad 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6165,6 +6165,7 @@ sd_init(struct sched_domain_topology_level *tl, int cpu)
*/
if (sd->flags & SD_SHARE_CPUCAPACITY) {
+ sd->flags |= SD_PREFER_SIBLING;
sd->imbalance_pct = 110;
sd->smt_gain = 1178; /* ~15% */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v9 07/10] sched: get CPU's usage statistic
Monitor the usage level of each group of each sched_domain level. The usage is
the portion of cpu_capacity_orig that is currently used on a CPU or group of
CPUs. We use the utilization_load_avg to evaluate the usage level of each
group.
The utilization_load_avg only takes into account the running time of the CFS
tasks on a CPU with a maximum value of SCHED_LOAD_SCALE when the CPU is fully
utilized. Nevertheless, we must cap utilization_load_avg which can be temporaly
greater than SCHED_LOAD_SCALE after the migration of a task on this CPU and
until the metrics are stabilized.
The utilization_load_avg is in the range [0..SCHED_LOAD_SCALE] to reflect the
running load on the CPU whereas the available capacity for the CFS task is in
the range [0..cpu_capacity_orig]. In order to test if a CPU is fully utilized
by CFS tasks, we have to scale the utilization in the cpu_capacity_orig range
of the CPU to get the usage of the latter. The usage can then be compared with
the available capacity (ie cpu_capacity) to deduct the usage level of a CPU.
The frequency scaling invariance of the usage is not taken into account in this
patch, it will be solved in another patch which will deal with frequency
scaling invariance on the running_load_avg.
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 4782733..884578e 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4559,6 +4559,33 @@ static int select_idle_sibling(struct task_struct *p,
int target)
done:
return target;
}
+/*
+ * get_cpu_usage returns the amount of capacity of a CPU that is used by CFS
+ * tasks. The unit of the return value must capacity so we can compare the
+ * usage with the capacity of the CPU that is available for CFS task (ie
+ * cpu_capacity).
+ * cfs.utilization_load_avg is the sum of running time of runnable tasks on a
+ * CPU. It represents the amount of utilization of a CPU in the range
+ * [0..SCHED_LOAD_SCALE]. The usage of a CPU can't be higher than the full
+ * capacity of the CPU because it's about the running time on this CPU.
+ * Nevertheless, cfs.utilization_load_avg can be higher than SCHED_LOAD_SCALE
+ * because of unfortunate rounding in avg_period and running_load_avg or just
+ * after migrating tasks until the average stabilizes with the new running
+ * time. So we need to check that the usage stays into the range
+ * [0..cpu_capacity_orig] and cap if necessary.
+ * Without capping the usage, a group could be seen as overloaded (CPU0 usage
+ * at 121% + CPU1 usage at 80%) whereas CPU1 has 20% of available capacity/
+ */
+static int get_cpu_usage(int cpu)
+{
+ unsigned long usage = cpu_rq(cpu)->cfs.utilization_load_avg;
+ unsigned long capacity = capacity_orig_of(cpu);
+
+ if (usage >= SCHED_LOAD_SCALE)
+ return capacity;
+
+ return (usage * capacity) >> SCHED_LOAD_SHIFT;
+}
/*
* select_task_rq_fair: Select target runqueue for the waking task in domains
@@ -5688,6 +5715,7 @@ struct sg_lb_stats {
unsigned long sum_weighted_load; /* Weighted load of group's tasks */
unsigned long load_per_task;
unsigned long group_capacity;
+ unsigned long group_usage; /* Total usage of the group */
unsigned int sum_nr_running; /* Nr tasks running in the group */
unsigned int group_capacity_factor;
unsigned int idle_cpus;
@@ -6036,6 +6064,7 @@ static inline void update_sg_lb_stats(struct lb_env *env,
load = source_load(i, load_idx);
sgs->group_load += load;
+ sgs->group_usage += get_cpu_usage(i);
sgs->sum_nr_running += rq->cfs.h_nr_running;
if (rq->nr_running > 1)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v9 04/10] sched: Make sched entity usage tracking scale-invariant
From: Morten Rasmussen
Apply frequency scale-invariance correction factor to usage tracking.
Each segment of the running_load_avg geometric series is now scaled by the
current frequency so the utilization_avg_contrib of each entity will be
invariant with frequency scaling. As a result, utilization_load_avg which is
the sum of utilization_avg_contrib, becomes invariant too. So the usage level
that is returned by get_cpu_usage, stays relative to the max frequency as the
cpu_capacity which is is compared against.
Then, we want the keep the load tracking values in a 32bits type, which implies
that the max value of {runnable|running}_avg_sum must be lower than
2^32/88761=48388 (88761 is the max weigth of a task). As LOAD_AVG_MAX = 47742,
arch_scale_freq_capacity must return a value less than
(48388/47742) << SCHED_CAPACITY_SHIFT = 1037 (SCHED_SCALE_CAPACITY = 1024).
So we define the range to [0..SCHED_SCALE_CAPACITY] in order to avoid overflow.
cc: Paul Turner
cc: Ben Segall
Signed-off-by: Morten Rasmussen
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index a96affd..a5039da 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2266,6 +2266,8 @@ static u32 __compute_runnable_contrib(u64 n)
return contrib + runnable_avg_yN_sum[n];
}
+unsigned long __weak arch_scale_freq_capacity(struct sched_domain *sd, int
cpu);
+
/*
* We can represent the historical contribution to runnable average as the
* coefficients of a geometric series. To do this we sub-divide our runnable
@@ -2294,7 +2296,7 @@ static u32 __compute_runnable_contrib(u64 n)
* load_avg = u_0` + y*(u_0 + u_1*y + u_2*y^2 + ... )
*= u_0 + u_1*y + u_2*y^2 + ... [re-labeling u_i --> u_{i+1}]
*/
-static __always_inline int __update_entity_runnable_avg(u64 now,
+static __always_inline int __update_entity_runnable_avg(u64 now, int cpu,
struct sched_avg *sa,
int runnable,
int running)
@@ -2302,6 +2304,7 @@ static __always_inline int
__update_entity_runnable_avg(u64 now,
u64 delta, periods;
u32 runnable_contrib;
int delta_w, decayed = 0;
+ unsigned long scale_freq = arch_scale_freq_capacity(NULL, cpu);
delta = now - sa->last_runnable_update;
/*
@@ -2337,7 +2340,8 @@ static __always_inline int
__update_entity_runnable_avg(u64 now,
if (runnable)
sa->runnable_avg_sum += delta_w;
if (running)
- sa->running_avg_sum += delta_w;
+ sa->running_avg_sum += delta_w * scale_freq
+ >> SCHED_CAPACITY_SHIFT;
sa->avg_period += delta_w;
delta -= delta_w;
@@ -2358,7 +2362,8 @@ static __always_inline int
__update_entity_runnable_avg(u64 now,
if (runnable)
sa->runnable_avg_sum += runnable_contrib;
if (running)
- sa->running_avg_sum += runnable_contrib;
+ sa->running_avg_sum += runnable_contrib * scale_freq
+ >> SCHED_CAPACITY_SHIFT;
sa->avg_period += runnable_contrib;
}
@@ -2366,7 +2371,8 @@ static __always_inline int
__update_entity_runnable_avg(u64 now,
if (runnable)
sa->runnable_avg_sum += delta;
if (running)
- sa->running_avg_sum += delta;
+ sa->running_avg_sum += delta * scale_freq
+ >> SCHED_CAPACITY_SHIFT;
sa->avg_period += delta;
return decayed;
@@ -2474,8 +2480,8 @@ static inline void __update_group_entity_contrib(struct
sched_entity *se)
static inline void update_rq_runnable_avg(struct rq *rq, int runnable)
{
- __update_entity_runnable_avg(rq_clock_task(rq), >avg, runnable,
- runnable);
+ __update_entity_runnable_avg(rq_clock_task(rq), cpu_of(rq), >avg,
+ runnable, runnable);
__update_tg_runnable_avg(>avg, >cfs);
}
#else /* CONFIG_FAIR_GROUP_SCHED */
@@ -2553,6 +2559,7 @@ static inline void update_entity_load_avg(struct
sched_entity *se,
{
struct cfs_rq *cfs_rq = cfs_rq_of(se);
long contrib_delta, utilization_delta;
+ int cpu = cpu_of(rq_of(cfs_rq));
u64 now;
/*
@@ -2564,7 +2571,7 @@ static inline void update_entity_load_avg(struct
sched_entity *se,
else
now = cfs_rq_clock_task(group_cfs_rq(se));
- if (!__update_entity_runnable_avg(now, >avg, se->on_rq,
+ if (!__update_entity_runnable_avg(now, cpu, >avg, se->on_rq,
cfs_rq->curr == se))
return;
--
