[PATCH 3/5 v4] Staging: cxt1e1: Fix line length over 80 characters in hwprobe.c

[Daeseok Youn]

clean up checkpatch.pl warnings:
 WARNING: Line length over 80 characters

Signed-off-by: Daeseok Youn 
---
 drivers/staging/cxt1e1/hwprobe.c |   45 --
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/cxt1e1/hwprobe.c b/drivers/staging/cxt1e1/hwprobe.c
index 85040bb..da991a3 100644
--- a/drivers/staging/cxt1e1/hwprobe.c
+++ b/drivers/staging/cxt1e1/hwprobe.c
@@ -37,7 +37,8 @@ extern int  drvr_state;
 
 /* forward references */
 voidc4_stopwd(ci_t *);
-struct net_device * __init c4_add_dev(hdw_info_t *, int, unsigned long, 
unsigned long, int, int);
+struct net_device * __init c4_add_dev(hdw_info_t *, int, unsigned long,
+ unsigned long, int, int);
 
 
 struct s_hdw_info hdw_info[MAX_BOARDS];
@@ -104,24 +105,31 @@ hdw_sn_get(hdw_info_t *hi, int brdno)
addr = (long) hi->addr_mapped[1] + EEPROM_OFFSET;
 
/* read EEPROM with largest known format size... */
-   pmc_eeprom_read_buffer(addr, 0, (char *)hi->mfg_info.data, 
sizeof(FLD_TYPE2));
+   pmc_eeprom_read_buffer(addr, 0, (char *)hi->mfg_info.data,
+  sizeof(FLD_TYPE2));
 
 #if 0
{
unsigned char *ucp = (unsigned char *) >mfg_info.data;
 
pr_info("eeprom[00]:  %02x %02x %02x %02x  %02x %02x %02x 
%02x\n",
-   *(ucp + 0), *(ucp + 1), *(ucp + 2), *(ucp + 3), 
*(ucp + 4), *(ucp + 5), *(ucp + 6), *(ucp + 7));
+   *(ucp + 0), *(ucp + 1), *(ucp + 2), *(ucp + 3),
+   *(ucp + 4), *(ucp + 5), *(ucp + 6), *(ucp + 7));
pr_info("eeprom[08]:  %02x %02x %02x %02x  %02x %02x %02x 
%02x\n",
-   *(ucp + 8), *(ucp + 9), *(ucp + 10), *(ucp + 
11), *(ucp + 12), *(ucp + 13), *(ucp + 14), *(ucp + 15));
+   *(ucp + 8), *(ucp + 9), *(ucp + 10), *(ucp + 11),
+   *(ucp + 12), *(ucp + 13), *(ucp + 14), *(ucp + 15));
pr_info("eeprom[16]:  %02x %02x %02x %02x  %02x %02x %02x 
%02x\n",
-   *(ucp + 16), *(ucp + 17), *(ucp + 18), *(ucp + 
19), *(ucp + 20), *(ucp + 21), *(ucp + 22), *(ucp + 23));
+   *(ucp + 16), *(ucp + 17), *(ucp + 18), *(ucp + 19),
+   *(ucp + 20), *(ucp + 21), *(ucp + 22), *(ucp + 23));
pr_info("eeprom[24]:  %02x %02x %02x %02x  %02x %02x %02x 
%02x\n",
-   *(ucp + 24), *(ucp + 25), *(ucp + 26), *(ucp + 
27), *(ucp + 28), *(ucp + 29), *(ucp + 30), *(ucp + 31));
+   *(ucp + 24), *(ucp + 25), *(ucp + 26), *(ucp + 27),
+   *(ucp + 28), *(ucp + 29), *(ucp + 30), *(ucp + 31));
pr_info("eeprom[32]:  %02x %02x %02x %02x  %02x %02x %02x 
%02x\n",
-   *(ucp + 32), *(ucp + 33), *(ucp + 34), *(ucp + 
35), *(ucp + 36), *(ucp + 37), *(ucp + 38), *(ucp + 39));
+   *(ucp + 32), *(ucp + 33), *(ucp + 34), *(ucp + 35),
+   *(ucp + 36), *(ucp + 37), *(ucp + 38), *(ucp + 39));
pr_info("eeprom[40]:  %02x %02x %02x %02x  %02x %02x %02x 
%02x\n",
-   *(ucp + 40), *(ucp + 41), *(ucp + 42), *(ucp + 
43), *(ucp + 44), *(ucp + 45), *(ucp + 46), *(ucp + 47));
+   *(ucp + 40), *(ucp + 41), *(ucp + 42), *(ucp + 43),
+   *(ucp + 44), *(ucp + 45), *(ucp + 46), *(ucp + 47));
}
 #endif
 #if 0
@@ -230,10 +238,11 @@ c4_hdw_init(struct pci_dev *pdev, int found)
return 0;
}
 
-   if (pdev->bus)  /* obtain bus number */
+   /* obtain bus number */
+   if (pdev->bus)
busno = pdev->bus->number;
else
-   busno = 0;  /* default for system PCI 
inconsistency */
+   busno = 0; /* default for system PCI inconsistency */
slot = pdev->devfn & ~0x07;
 
/*
@@ -246,8 +255,8 @@ c4_hdw_init(struct pci_dev *pdev, int found)
for (i = 0, hi = hdw_info; i < MAX_BOARDS; i++, hi++)
{
/*
-* match with board's first found interface, otherwise this is 
first
-* found
+* match with board's first found interface, otherwise this is
+* first found
 */
if ((hi->pci_slot == 0xff) ||   /* new board */
((hi->pci_slot == slot) && (hi->bus == pdev->bus)))
@@ -256,13 +265,14 @@ c4_hdw_init(struct pci_dev *pdev, int found)
if (i == MAX_BOARDS)/* no match in above loop means MAX
 * exceeded */
{
-   pr_warning("exceeded number of allowed devices (>%d)?\n", 
MAX_BOARDS);
+   pr_warning("exceeded number of allowed devices (>%d)?\n",
+  MAX_BOARDS);

Re: [RFC][PATCH] clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()

[Henrik Austad]

On Tue, Mar 04, 2014 at 08:36:28AM +0100, Mike Galbraith wrote:
> (boing boing boing... hell with it, today doesn't exist;)

you lost me at boing.. :)

> On Tue, 2014-03-04 at 08:31 +0100, Mike Galbraith wrote: 
> > On Tue, 2014-03-04 at 08:20 +0100, Henrik Austad wrote: 
> > > On Tue, Mar 04, 2014 at 06:20:09AM +0100, Mike Galbraith wrote:
> > > > Greetings,
> > > > 
> > > > While rummaging around looking for HTH a gaggle of weird a$$ machines
> > > > can manage to timewarp back and forth by exactly 208 days, I stumbled
> > > > across $subject which looks like it may want to borrow Salman's fix.
> > > > 
> > > > clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()
> > > > 
> > > > As per 4cecf6d401a "sched, x86: Avoid unnecessary overflow in 
> > > > sched_clock",
> > > > cycles * mult >> shift is overflow prone. so give it the same treatment.
> > > > 
> > > > Cc: Salman Qazi 
> > > > Cc: John Stultz 
> > > > Signed-off-by: Mike Galbraith 
> > > > ---
> > > >  include/linux/clocksource.h |   11 ---
> > > >  1 file changed, 8 insertions(+), 3 deletions(-)
> > > > 
> > > > --- a/include/linux/clocksource.h
> > > > +++ b/include/linux/clocksource.h
> > > > @@ -77,13 +77,18 @@ struct timecounter {
> > > >   *
> > > >   * XXX - This could use some mult_lxl_ll() asm optimization. Same code
> > > >   * as in cyc2ns, but with unsigned result.
> > > > + *
> > > > + * Because it is the same as x86 __cycles_2_ns, give it the same 
> > > > treatment as
> > > > + * commit 4cecf6d401a "sched, x86: Avoid unnecessary overflow in 
> > > > sched_clock"
> > > > + * to avoid a potential cycles * mult overflow.
> > > 
> > > Do we normally reference a particular commit in a comment? Why not just 
> > > grab the same comment and add a "this is grabbed from arch/x86/... ?
> > 
> > Fewer '+' signs?  History doesn't go away, so seems fine to me.

I wasn't thinking about the number of +'s in the code, but rather 
referencing other parts of the code from the code and particular commits in 
the commit-msg itself. It was the code<->commitmsg interface I was 
pondering.

Besides, it wasn't meant as "you shouldn't do that", but more "is it ok to 
do that?" :)

-- 
Henrik Austad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the mfd-lj tree

[Lee Jones]

> > After merging the mfd-lj tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > drivers/mfd/tps65218: struct i2c_device_id is 32 bytes.  The last of 1 is:
> > 0x74 0x70 0x73 0x36 0x35 0x32 0x31 0x38 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
> > 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0x00 0x00 0x00 0x00 0x00 
> > 0x00 0x00 
> > FATAL: drivers/mfd/tps65218: struct i2c_device_id is not terminated with a 
> > NULL entry!
> > 
> > Caused by commit cc493e30e3a1 ("mfd: tps65218: Add driver for the
> > TPS65218 PMIC").

-rw-r--r-- 1 lee lee   6320 Mar  4 15:20 tps65218.o

Hmmm... I'm having trouble reproducing the error. My toolchain
doesn't complain about the lack of a terminating entry. I have fixed
the problem and re-pushed the branch though. Would you be kind enough
to re-test it please?

> Now that the otherproblem is fixed, I am getting this one again :-(
> 
> > I have used the mfd-lj tree from next-20140210 for today.
> 
> Again.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/11] perf: add PMU_FORMAT_RANGE() helper for use by sw-like pmus

[Cody P Schafer]

On 03/03/2014 09:19 PM, Michael Ellerman wrote:

On Thu, 2014-27-02 at 21:04:55 UTC, Cody P Schafer wrote:

Add PMU_FORMAT_RANGE() and PMU_FORMAT_RANGE_RESERVED() (for reserved
areas) which generate functions to extract the relevent bits from
event->attr.config{,1,2} for use by sw-like pmus where the
'config{,1,2}' values don't map directly to hardware registers.

Signed-off-by: Cody P Schafer 
---
  include/linux/perf_event.h | 17 +
  1 file changed, 17 insertions(+)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index e56b07f..3da5081 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -871,4 +871,21 @@ _name##_show(struct device *dev,   
\
\
  static struct device_attribute format_attr_##_name = __ATTR_RO(_name)

+#define PMU_FORMAT_RANGE(name, attr_var, bit_start, bit_end)   \
+PMU_FORMAT_ATTR(name, #attr_var ":" #bit_start "-" #bit_end);  \
+PMU_FORMAT_RANGE_RESERVED(name, attr_var, bit_start, bit_end)


I really think these should have event in the name.

Someone looking at the code is going to see event_get_foo() and wonder where
that is defined. Grep won't find a definition, tags won't find a definition,
the least you can do is have the macro name give some hint.



That is a good point (grep-ability). Let me think about this. There is 
also the possibility that I could adjust the event_get_*() naming to 
something else. format_get_*()? event_get_format_*()? (these names keep 
growing...)



+#define PMU_FORMAT_RANGE_RESERVED(name, attr_var, bit_start, bit_end)  \


It doesn't generate a format attribute.


This was done with the idea that the term "format" didn't just refer to 
the attribute exposed in sysfs, it referred to "some subset of bits 
extractable from attr.config{,1,2}". Which is also the reasoning for the 
above naming.



+static u64 event_get_##name##_max(void)
\
+{  \
+   int bits = (bit_end) - (bit_start) + 1; \
+   return ((0x1ULL << (bits - 1ULL)) - 1ULL) |   \
+   (0xFULL << (bits - 4ULL));\


What's wrong with:

(0x1ULL << ((bit_end) - (bit_start) + 1)) - 1ULL;


Overflowing the << when bit_end = 63 and bit_start = 0 results in max(0, 
63) = 0.
That said, the current implementation is wrong when (bits < 4). Here's 
one that actually works (without overflowing):


return (((1ull << (bit_end - bit_start)) - 1) << 1) + 1;

And an examination of the problematic case:

#if 0
typedef unsigned long long ull;
ull a = bits - 1; /* 63 */
ull b = 1 << a;   /* 0x8000 */
ull c = b - 1;/* 0x7fff */
ull d = b << 1;   /* 0xfffe */
ull e = d + 1;/* 0x */
return e;
#endif

Small number of valid inputs, so I also tested it for all of them using

unsigned bits = (bit_end) - (bit_start) + 1;
return (bits < (sizeof(0ULL) * CHAR_BIT))
? ((1ULL << bits) - 1ULL)
: ~0ULL;

As the baseline correct one.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] fs/quota/Kconfig: Update filesystems

[Fabian Frederick]

Update Kconfig with a complete list of supported filesystems.

Signed-off-by: Fabian Frederick 
---
 fs/quota/Kconfig | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/quota/Kconfig b/fs/quota/Kconfig
index 880fd98..c51df1d 100644
--- a/fs/quota/Kconfig
+++ b/fs/quota/Kconfig
@@ -8,9 +8,10 @@ config QUOTA
help
  If you say Y here, you will be able to set per user limits for disk
  usage (also called disk quotas). Currently, it works for the
- ext2, ext3, and reiserfs file system. ext3 also supports journalled
- quotas for which you don't need to run quotacheck(8) after an unclean
- shutdown.
+ ext2, ext3, ext4, jfs, ocfs2 and reiserfs file systems.
+ Note that gfs2 and xfs use their own quota system.
+ Ext3, ext4 and reiserfs also support journaled quotas for which
+ you don't need to run quotacheck(8) after an unclean shutdown.
  For further details, read the Quota mini-HOWTO, available from
  , or the documentation provided
  with the quota tools. Probably the quota support is only useful for
-- 
1.8.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/

Re: [PATCH 4/6] android: convert sync to fence api, v4

[Daniel Vetter]

On Tue, Mar 04, 2014 at 08:50:38AM +0100, Maarten Lankhorst wrote:
> op 03-03-14 22:11, Daniel Vetter schreef:
> >On Mon, Feb 17, 2014 at 04:57:19PM +0100, Maarten Lankhorst wrote:
> >>Android syncpoints can be mapped to a timeline. This removes the need
> >>to maintain a separate api for synchronization. I've left the android
> >>trace events in place, but the core fence events should already be
> >>sufficient for debugging.
> >>
> >>v2:
> >>- Call fence_remove_callback in sync_fence_free if not all fences have 
> >>fired.
> >>v3:
> >>- Merge Colin Cross' bugfixes, and the android fence merge optimization.
> >>v4:
> >>- Merge with the upstream fixes.
> >>
> >>Signed-off-by: Maarten Lankhorst 
> >>---
> >Snipped everything but headers - Ian Lister from our android team is
> >signed up to have a more in-depth look at proper integration with android
> >syncpoints. Adding him to cc.
> >
> >>diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
> >>index 62e2255b1c1e..6036dbdc8e6f 100644
> >>--- a/drivers/staging/android/sync.h
> >>+++ b/drivers/staging/android/sync.h
> >>@@ -21,6 +21,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >>+#include 
> >>
> >>  struct sync_timeline;
> >>  struct sync_pt;
> >>@@ -40,8 +41,6 @@ struct sync_fence;
> >>   * -1 if a will signal before b
> >>   * @free_pt: called before sync_pt is freed
> >>   * @release_obj: called before sync_timeline is freed
> >>- * @print_obj: deprecated
> >>- * @print_pt: deprecated
> >>   * @fill_driver_data: write implementation specific driver data to data.
> >>   *  should return an error if there is not enough room
> >>   *  as specified by size.  This information is returned
> >>@@ -67,13 +66,6 @@ struct sync_timeline_ops {
> >>   /* optional */
> >>   void (*release_obj)(struct sync_timeline *sync_timeline);
> >>
> >>- /* deprecated */
> >>- void (*print_obj)(struct seq_file *s,
> >>-  struct sync_timeline *sync_timeline);
> >>-
> >>- /* deprecated */
> >>- void (*print_pt)(struct seq_file *s, struct sync_pt *sync_pt);
> >>-
> >>   /* optional */
> >>   int (*fill_driver_data)(struct sync_pt *syncpt, void *data, int size);
> >>
> >>@@ -104,42 +96,48 @@ struct sync_timeline {
> >>
> >>   /* protected by child_list_lock */
> >>   bool destroyed;
> >>+ int context, value;
> >>
> >>   struct list_head child_list_head;
> >>   spinlock_t child_list_lock;
> >>
> >>   struct list_head active_list_head;
> >>- spinlock_t active_list_lock;
> >>
> >>+#ifdef CONFIG_DEBUG_FS
> >>   struct list_head sync_timeline_list;
> >>+#endif
> >>  };
> >>
> >>  /**
> >>   * struct sync_pt - sync point
> >>- * @parent: sync_timeline to which this sync_pt belongs
> >>+ * @fence: base fence class
> >>   * @child_list: membership in sync_timeline.child_list_head
> >>   * @active_list: membership in sync_timeline.active_list_head
> >>+<<< current
> >>   * @signaled_list: membership in temporary signaled_list on stack
> >>   * @fence: sync_fence to which the sync_pt belongs
> >>   * @pt_list: membership in sync_fence.pt_list_head
> >>   * @status: 1: signaled, 0:active, <0: error
> >>   * @timestamp: time which sync_pt status transitioned from active to
> >>   *  signaled or error.
> >>+===
> >>+>>> patched
> >Conflict markers ...
> Oops.
> >>   */
> >>  struct sync_pt {
> >>- struct sync_timeline *parent;
> >>- struct list_head child_list;
> >>+ struct fence base;
> >Hm, embedding feels wrong, since that still means that I'll need to
> >implement two kinds of fences in i915 - one using the seqno fence to make
> >dma-buf sync work, and one to implmenent sync_pt to make the android folks
> >happy.
> >
> >If I can dream I think we should have a pointer to an underlying fence
> >here, i.e. a struct sync_pt would just be a userspace interface wrapper to
> >do explicit syncing using native fences, instead of implicit syncing like
> >with dma-bufs. But this is all drive-by comments from a very cursory
> >high-level look. I might be full of myself again ;-)
> >-Daniel
> >
> No, the idea is that because android syncpoint is simply another type of
> dma-fence, that if you deal with normal fences then android can
> automatically be handled too. The userspace fence api android exposes
> could be very easily made to work for dma-fence, just pass a dma-fence
> to sync_fence_create.
> So exposing dma-fence would probably work for android too.

Hm, then why do we still have struct sync_pt around? Since it's just the
internal bit, with the userspace facing object being struct sync_fence,
I'd opt to shuffle any useful features into the core struct fence.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI / hotplug / PCI: Use pci_device_is_present()

[Mika Westerberg]

On Mon, Mar 03, 2014 at 01:19:25AM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Make the ACPI-based PCI hotplug (ACPIPHP) code use
> pci_device_is_present() for checking if devices are present instead
> of open coding the same thing.
> 
> Signed-off-by: Rafael J. Wysocki 

Reviewed-by: Mika Westerberg 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Drivers:net:wireless:ti:wl1251: Fixed Sparse invalid assignment warning

[Surendra Patil]

Sparse warns about invalid assignment in
drivers/net/wireless/ti/wl1251/cmd.c:451:42: warning: invalid assignment: |=
drivers/net/wireless/ti/wl1251/cmd.c:451:42:left side has type restricted 
__le16
drivers/net/wireless/ti/wl1251/cmd.c:451:42:right side has type int
Hence type converted right side to __le16.

Signed-off-by: Surendra Patil 
---
 drivers/net/wireless/ti/wl1251/cmd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ti/wl1251/cmd.c 
b/drivers/net/wireless/ti/wl1251/cmd.c
index 223649b..bf1fa18 100644
--- a/drivers/net/wireless/ti/wl1251/cmd.c
+++ b/drivers/net/wireless/ti/wl1251/cmd.c
@@ -448,7 +448,7 @@ int wl1251_cmd_scan(struct wl1251 *wl, u8 *ssid, size_t 
ssid_len,
 * Note: This bug may be caused by the fw's DTIM handling.
 */
if (is_zero_ether_addr(wl->bssid))
-   cmd->params.scan_options |= WL1251_SCAN_OPT_PRIORITY_HIGH;
+   cmd->params.scan_options |= 
cpu_to_le16(WL1251_SCAN_OPT_PRIORITY_HIGH);
cmd->params.num_channels = n_channels;
cmd->params.num_probe_requests = n_probes;
cmd->params.tx_rate = cpu_to_le16(1 << 1); /* 2 Mbps */
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] android: convert sync to fence api, v4

[Maarten Lankhorst]

op 04-03-14 09:14, Daniel Vetter schreef:

On Tue, Mar 04, 2014 at 08:50:38AM +0100, Maarten Lankhorst wrote:

op 03-03-14 22:11, Daniel Vetter schreef:

On Mon, Feb 17, 2014 at 04:57:19PM +0100, Maarten Lankhorst wrote:

Android syncpoints can be mapped to a timeline. This removes the need
to maintain a separate api for synchronization. I've left the android
trace events in place, but the core fence events should already be
sufficient for debugging.

v2:
- Call fence_remove_callback in sync_fence_free if not all fences have fired.
v3:
- Merge Colin Cross' bugfixes, and the android fence merge optimization.
v4:
- Merge with the upstream fixes.

Signed-off-by: Maarten Lankhorst 
---

Snipped everything but headers - Ian Lister from our android team is
signed up to have a more in-depth look at proper integration with android
syncpoints. Adding him to cc.


diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index 62e2255b1c1e..6036dbdc8e6f 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -21,6 +21,7 @@
  #include 
  #include 
  #include 
+#include 

  struct sync_timeline;
  struct sync_pt;
@@ -40,8 +41,6 @@ struct sync_fence;
   * -1 if a will signal before b
   * @free_pt: called before sync_pt is freed
   * @release_obj: called before sync_timeline is freed
- * @print_obj: deprecated
- * @print_pt: deprecated
   * @fill_driver_data: write implementation specific driver data to data.
   *  should return an error if there is not enough room
   *  as specified by size.  This information is returned
@@ -67,13 +66,6 @@ struct sync_timeline_ops {
   /* optional */
   void (*release_obj)(struct sync_timeline *sync_timeline);

- /* deprecated */
- void (*print_obj)(struct seq_file *s,
-  struct sync_timeline *sync_timeline);
-
- /* deprecated */
- void (*print_pt)(struct seq_file *s, struct sync_pt *sync_pt);
-
   /* optional */
   int (*fill_driver_data)(struct sync_pt *syncpt, void *data, int size);

@@ -104,42 +96,48 @@ struct sync_timeline {

   /* protected by child_list_lock */
   bool destroyed;
+ int context, value;

   struct list_head child_list_head;
   spinlock_t child_list_lock;

   struct list_head active_list_head;
- spinlock_t active_list_lock;

+#ifdef CONFIG_DEBUG_FS
   struct list_head sync_timeline_list;
+#endif
  };

  /**
   * struct sync_pt - sync point
- * @parent: sync_timeline to which this sync_pt belongs
+ * @fence: base fence class
   * @child_list: membership in sync_timeline.child_list_head
   * @active_list: membership in sync_timeline.active_list_head
+<<< current
   * @signaled_list: membership in temporary signaled_list on stack
   * @fence: sync_fence to which the sync_pt belongs
   * @pt_list: membership in sync_fence.pt_list_head
   * @status: 1: signaled, 0:active, <0: error
   * @timestamp: time which sync_pt status transitioned from active to
   *  signaled or error.
+===
+>>> patched

Conflict markers ...

Oops.

   */
  struct sync_pt {
- struct sync_timeline *parent;
- struct list_head child_list;
+ struct fence base;

Hm, embedding feels wrong, since that still means that I'll need to
implement two kinds of fences in i915 - one using the seqno fence to make
dma-buf sync work, and one to implmenent sync_pt to make the android folks
happy.

If I can dream I think we should have a pointer to an underlying fence
here, i.e. a struct sync_pt would just be a userspace interface wrapper to
do explicit syncing using native fences, instead of implicit syncing like
with dma-bufs. But this is all drive-by comments from a very cursory
high-level look. I might be full of myself again ;-)
-Daniel


No, the idea is that because android syncpoint is simply another type of
dma-fence, that if you deal with normal fences then android can
automatically be handled too. The userspace fence api android exposes
could be very easily made to work for dma-fence, just pass a dma-fence
to sync_fence_create.
So exposing dma-fence would probably work for android too.

Hm, then why do we still have struct sync_pt around? Since it's just the
internal bit, with the userspace facing object being struct sync_fence,
I'd opt to shuffle any useful features into the core struct fence.
-Daniel

To keep compatibility with the android api. I think that gradually converting 
them is going to be
more useful than to force all drivers to use a new api all at once. They could 
keep android
syncpoint api for exporting, as long as they accept dma-fence for 
importing/waiting.

~Maarten
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tile: avoid overflow in ns2cycles

[Henrik Austad]

In commit 4cecf6d401a ("sched, x86: Avoid unnecessary overflow in
sched_clock") and in recent patch "clocksource: avoid unnecessary
overflow in cyclecounter_cyc2ns()" https://lkml.org/lkml/2014/3/4/17,
the mult-shift approach is replaced by 2 steps to avoid storing a large,
intermediate value that could overflow.

arch/tile/kernel/time.c has a similar pattern in cycles2ns, and this
copies the same pattern in this function

CC: John Stultz 
CC: Mike Galbraith 
CC: Salman Qazi 
Signed-off-by: Henrik Austad 
---
 arch/tile/kernel/time.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/tile/kernel/time.c b/arch/tile/kernel/time.c
index 5d10642..9e74733 100644
--- a/arch/tile/kernel/time.c
+++ b/arch/tile/kernel/time.c
@@ -236,7 +236,15 @@ cycles_t ns2cycles(unsigned long nsecs)
 * clock frequency.
 */
struct clock_event_device *dev = &__raw_get_cpu_var(tile_timer);
-   return ((u64)nsecs * dev->mult) >> dev->shift;
+
+   /*
+* as in clocksource.h and x86's timer.h, we split the calculation into 
 2
+* parts to avoid unecessary overflow of the intermediate value. This 
will
+* not lead to any loss of precision.
+*/
+   u64 quot = (u64)nsecs >> dev->shift;
+   u64 rem  = (u64)nsecs & ((1ULL << dev->shift)-1);
+   return quot * dev->mult + ((rem * dev->mult) >> dev->shift);
 }
 
 void update_vsyscall_tz(void)
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()

[Mike Galbraith]

On Tue, 2014-03-04 at 09:02 +0100, Henrik Austad wrote: 
> On Tue, Mar 04, 2014 at 08:36:28AM +0100, Mike Galbraith wrote:
> > (boing boing boing... hell with it, today doesn't exist;)
> 
> you lost me at boing.. :)

Mail bounces due to dead addresses.  Bad hair day in progress.  Now my
shiny new address, which is the result of _every damn address_ I tried
at gmail saying "sorry, taken, try again endlessly", has escaped.

> > On Tue, 2014-03-04 at 08:31 +0100, Mike Galbraith wrote: 
> > > On Tue, 2014-03-04 at 08:20 +0100, Henrik Austad wrote: 
> > > > On Tue, Mar 04, 2014 at 06:20:09AM +0100, Mike Galbraith wrote:
> > > > > Greetings,
> > > > > 
> > > > > While rummaging around looking for HTH a gaggle of weird a$$ machines
> > > > > can manage to timewarp back and forth by exactly 208 days, I stumbled
> > > > > across $subject which looks like it may want to borrow Salman's fix.
> > > > > 
> > > > > clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()
> > > > > 
> > > > > As per 4cecf6d401a "sched, x86: Avoid unnecessary overflow in 
> > > > > sched_clock",
> > > > > cycles * mult >> shift is overflow prone. so give it the same 
> > > > > treatment.
> > > > > 
> > > > > Cc: Salman Qazi 
> > > > > Cc: John Stultz 
> > > > > Signed-off-by: Mike Galbraith 
> > > > > ---
> > > > >  include/linux/clocksource.h |   11 ---
> > > > >  1 file changed, 8 insertions(+), 3 deletions(-)
> > > > > 
> > > > > --- a/include/linux/clocksource.h
> > > > > +++ b/include/linux/clocksource.h
> > > > > @@ -77,13 +77,18 @@ struct timecounter {
> > > > >   *
> > > > >   * XXX - This could use some mult_lxl_ll() asm optimization. Same 
> > > > > code
> > > > >   * as in cyc2ns, but with unsigned result.
> > > > > + *
> > > > > + * Because it is the same as x86 __cycles_2_ns, give it the same 
> > > > > treatment as
> > > > > + * commit 4cecf6d401a "sched, x86: Avoid unnecessary overflow in 
> > > > > sched_clock"
> > > > > + * to avoid a potential cycles * mult overflow.
> > > > 
> > > > Do we normally reference a particular commit in a comment? Why not just 
> > > > grab the same comment and add a "this is grabbed from arch/x86/... ?
> > > 
> > > Fewer '+' signs?  History doesn't go away, so seems fine to me.
> 
> I wasn't thinking about the number of +'s in the code, but rather 
> referencing other parts of the code from the code and particular commits in 
> the commit-msg itself. It was the code<->commitmsg interface I was 
> pondering.
> 
> Besides, it wasn't meant as "you shouldn't do that", but more "is it ok to 
> do that?" :)

It's perfectly fine until the maintainer says "NAK" :)  If he does, I'll
go generate '+' signs.. that he can then whack when he gets around to
what he said was likely to happen to that code.

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] regulator fixes for v3.14

[Mark Brown]

The following changes since commit acc3d5cec84f82ebea535fa0bd9500ac3df2aee9:

  regulator: core: Change dummy supplies error message to a warning (2014-02-21 
08:35:31 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 
tags/regulator-v3.14-rc5

for you to fetch changes up to 66fda75f47dc583f1c187556e9a2c082dd64f8c6:

  regulator: core: Replace direct ops->disable usage (2014-02-25 10:31:45 +0900)


regulator: Fixes for v3.14-rc5

A couple of fixes here which ensure that regulators using the core
support for GPIO enables work in all cases by ensuring that helpers are
used consistently rather than open coding in places and hence not having
GPIO support in some of them.


Markus Pargmann (2):
  regulator: core: Replace direct ops->enable usage
  regulator: core: Replace direct ops->disable usage

 drivers/regulator/core.c | 48 
 1 file changed, 20 insertions(+), 28 deletions(-)


signature.asc
Description: Digital signature

Re: [PATCH v2] regulator: pfuze100: add pfuze200 support

[Mark Brown]

On Tue, Mar 04, 2014 at 02:46:42PM +0800, Mark Brown wrote:
> On Tue, Mar 04, 2014 at 01:45:33PM +0800, Robin Gong wrote:
> > support pfuze200 chip which remove SW1C and SW4 based on pfuze100.
> 
> Applied, thanks - however I just noticed that you forgot to add the
> compatible string for the new part to the DT binding, please send a
> followup doing that.

I've dropped this patch since it fails to build.  Please fix and resend
(along with adding the compatible string to the DT binding).


signature.asc
Description: Digital signature

Re: [PATCH V3 4/5] mfd: palmas: support IRQ inversion at the board level

[Lee Jones]

> From: Stephen Warren 
> 
> Implement the new DT property ti,irq-externally-inverted, and add an
> equivalent platform data field to match. This allows the driver to
> correctly automatically configure the IRQ output polarity when the board
> or SoC contains an inverter between the Palmas IRQ output and IRQ
> controller input.
> 
> Signed-off-by: Stephen Warren 
> ---
> v3:
> * Use an IRQD flag to represent the data, rather than a custom DT property.
> v2:
> * Split V1's patch 1/2 into separate patches 1/3 and 2/3.
> ---
>  drivers/mfd/palmas.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Looks good to me. Let me know how you want to deal with this. I'm
happy to create an immutable branch for everyone to pull from.

Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] fs/quota/Kconfig: Update filesystems

[Jan Kara]

On Tue 04-03-14 08:11:07, Fabian Frederick wrote:
> Update Kconfig with a complete list of supported filesystems.
  Thanks. I have added the patch to my tree.

Honza

> 
> Signed-off-by: Fabian Frederick 
> ---
>  fs/quota/Kconfig | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/quota/Kconfig b/fs/quota/Kconfig
> index 880fd98..c51df1d 100644
> --- a/fs/quota/Kconfig
> +++ b/fs/quota/Kconfig
> @@ -8,9 +8,10 @@ config QUOTA
>   help
> If you say Y here, you will be able to set per user limits for disk
> usage (also called disk quotas). Currently, it works for the
> -   ext2, ext3, and reiserfs file system. ext3 also supports journalled
> -   quotas for which you don't need to run quotacheck(8) after an unclean
> -   shutdown.
> +   ext2, ext3, ext4, jfs, ocfs2 and reiserfs file systems.
> +   Note that gfs2 and xfs use their own quota system.
> +   Ext3, ext4 and reiserfs also support journaled quotas for which
> +   you don't need to run quotacheck(8) after an unclean shutdown.
> For further details, read the Quota mini-HOWTO, available from
> , or the documentation provided
> with the quota tools. Probably the quota support is only useful for
> -- 
> 1.8.1.4
> 
-- 
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: 3.13 i915 brightness settings broken when going from docked -> undocked

[Paul Bolle]

On Tue, 2014-02-25 at 10:05 +0200, Jani Nikula wrote:
> On Thu, 20 Feb 2014, Paul Bolle  wrote:
> > On an (rather old) ThinkPad X41, which also uses i915, brightness
> > adjustments stopped working altogether in v3.14-rc1 (I haven't used its
> > docking station in the v3.14 release cycle). In v3.13.y things behave as
> > expected. So perhaps there's actually a more general problem here.
> 
> I presume different problems. Does the ThinkPad X41 have gen3 graphics?
> (See e.g. /sys/kernel/debug/dri/0/i915_capabilities) If yes, it might be
> https://bugs.freedesktop.org/show_bug.cgi?id=75001

Yes, it has "gen3" graphics (a 915GM). And applying your patch
"drm/i915: use backlight legacy combination mode also for
i915gm/i945/gm" on top of v3.14-rc5 fixes the issue on that ThinkPad
X41.

Thanks,


Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: What is wrong?

[Brian Norris]

On Mon, Mar 03, 2014 at 03:13:36PM -0600, Andrew Ruder wrote:
> On Thu, Feb 27, 2014 at 01:22:08PM -0800, Brian Norris wrote:
> > Perhaps Richard or Andrew can comment on whether this patch should help
> > you. But I think JFFS2 on NAND uses write-buffered support which can be
> > affected by this bug.
> 
> Definitely sounds like the same issue and I'm kind of glad to see it
> crop up in another filesystem.

We haven't confirmed that the *patch* actually affects Leon's problem;
just that if he runs an additional 'sync' it solves his problem. Leon,
did you get to try the patch?

Anyway, should commit 807612db2f9940b9fa6deaef054eb16d51bd3e00 be marked
for -stable? 

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] new Page: isalpha__3(3)

[walter harms]

Hi List,
The ctype macros like  isalpha(3) have a locale specific counterpart.
This page was missing.

re,
 wh


Signed-off-by: wha...@bfs.de 


.\" Copyright (c) 2013 by Walter Harms
.\"
.\" %%%LICENSE_START(VERBATIM)
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one.
.\"
.\" Since the Linux kernel and libraries are constantly changing, this
.\" manual page may be incorrect or out-of-date.  The author(s) assume no
.\" responsibility for errors or omissions, or for damages resulting from
.\" the use of the information contained herein.  The author(s) may not
.\" have taken the same level of care in the production of this manual,
.\" which is licensed free of charge, as they might when working
.\" professionally.
.\"
.\" Formatted or processed versions of this manual, if unaccompanied by
.\" the source, must acknowledge the copyright and authors of this work.
.\" %%%LICENSE_END
.\"
.\"
.TH ISALPHA_L 3 2013-09-20 "GNU" "Linux Programmer's Manual"
.SH NAME
isalnum_l, isalpha_l, isblank_l, iscntrl_l, isdigit_l, isgraph_l, islower_l,
isprint_l, ispunct_l, isspace_l, isupper_l, isxdigit_l \- character
classification routines
.SH SYNOPSIS
.nf
.B #include 
.sp
.BI "int isalnum_l(int " "c" ", locale_t " loc );
.br
.BI "int isalpha_l(int " "c" ", locale_t " loc );
.br
.BI "int isascii_l(int " "c" ", locale_t " loc );
.br
.BI "int isblank_l(int " "c" ", locale_t " loc );
.br
.BI "int iscntrl_l(int " "c" ", locale_t " loc );
.br
.BI "int isdigit_l(int " "c" ", locale_t " loc );
.br
.BI "int isgraph_l(int " "c" ", locale_t " loc );
.br
.BI "int islower_l(int " "c" ", locale_t " loc );
.br
.BI "int isprint_l(int " "c" ", locale_t " loc );
.br
.BI "int ispunct_l(int " "c" ", locale_t " loc );
.br
.BI "int isspace_l(int " "c" ", locale_t " loc );
.br
.BI "int isupper_l(int " "c" ", locale_t " loc );
.br
.BI "int isxdigit_l(int " "c" ", locale_t " loc );
.fi
.sp
.SH DESCRIPTION
These functions check whether
.IR c ,
which must have the value of an
.I unsigned char
or
.BR EOF ,
falls into a certain character class according to the current locale.
.TP
.BR isalnum_l ()
checks for an alphanumeric character; it is equivalent to
.BI "(isalpha(" c ") || isdigit(" c "))" \fR.
.TP
.BR isalpha_l ()
checks for an alphabetic character; in the standard \fB"C"\fP
locale, it is equivalent to
.BI "(isupper_l(" c ") || islower_l(" c "))" \fR.
In some locales, there may be additional characters for which
.BR isalpha ()
is true\(emletters which are neither upper case nor lower
case.
.TP
.BR isascii_l ()
checks whether \fIc\fP is a 7-bit
.I unsigned char
value that fits into
the ASCII character set.
.TP
.BR isblank_l ()
checks for a blank character; that is, a space or a tab.
.TP
.BR iscntrl_l ()
checks for a control character.
.TP
.BR isdigit_l ()
checks for a digit (0 through 9).
.TP
.BR isgraph_l ()
checks for any printable character except space.
.TP
.BR islower_l ()
checks for a lower-case character.
.TP
.BR isprint_l ()
checks for any printable character including space.
.TP
.BR ispunct_l ()
checks for any printable character which is not a space or an
alphanumeric character.
.TP
.BR isspace_l ()
checks for white-space characters.
In the
.B """C"""
and
.B """POSIX"""
locales, these are: space, form-feed
.RB ( \(aq\ef\(aq ),
newline
.RB ( \(aq\en\(aq ),
carriage return
.RB ( \(aq\er\(aq ),
horizontal tab
.RB ( \(aq\et\(aq ),
and vertical tab
.RB ( \(aq\ev\(aq ).
.TP
.BR isupper_l ()
checks for an uppercase letter.
.TP
.BR isxdigit_l ()
checks for a hexadecimal digits, that is, one of
.br
.BR "0 1 2 3 4 5 6 7 8 9 a b c d e f A B C D E F" .
.SH RETURN VALUE
The values returned are nonzero if the character
.I c
falls into the tested class, and a zero value
if not.
.SH CONFORMING TO
POSIX.1-2008 specifies all of these functions.
.SH NOTES
The details of what characters belong into which class depend on the current
locale.
.sp
from
.IR locale.h :
The concept of one static locale per category is not very well
thought out.  Many applications will need to process its data using
information from several different locales.  Another application is
the implementation of the internationalization handling in the
upcoming ISO C++ standard library.  To support this another set of
the functions using locale data exist which have an additional
argument.

For example,
.BR isupper ()
will not recognize an A-umlaut (\(:A) as an uppercase letter in the default
.B "C"
locale.
.SH EXAMPLE
The following example takes a locale abbreviation like "de_DE" as argument.
Is no argument is supplied it will use "C". With "de_DE" the code will
identify the O-Umlaut correctly as alphanumeric 

Re: [PATCHv2 2/2] of: fix of_update_property()

[Grant Likely]

On Wed, 22 Jan 2014 13:57:40 +0800, Xiubo Li  wrote:
> The of_update_property() is intented to update a property in a node
> and if the property does not exist, will add it.
> 
> The second search of the property is possibly won't be found, that
> maybe removed by other thread just before the second search begain.
> 
> Using the __of_find_property() and __of_add_property() instead and
> move them into lock operations.
> 
> Signed-off-by: Xiubo Li 
> Cc: Pantelis Antoniou 

I've had to revert this patch. See below...

> ---
>  drivers/of/base.c | 36 ++--
>  1 file changed, 14 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index b86b77a..458072d 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1573,7 +1573,7 @@ int of_update_property(struct device_node *np, struct 
> property *newprop)
>  {
>   struct property **next, *oldprop;
>   unsigned long flags;
> - int rc, found = 0;
> + int rc = 0;
>  
>   rc = of_property_notify(OF_RECONFIG_UPDATE_PROPERTY, np, newprop);
>   if (rc)
> @@ -1582,36 +1582,28 @@ int of_update_property(struct device_node *np, struct 
> property *newprop)
>   if (!newprop->name)
>   return -EINVAL;
>  
> - oldprop = of_find_property(np, newprop->name, NULL);
> - if (!oldprop)
> - return of_add_property(np, newprop);
> -
>   raw_spin_lock_irqsave(_lock, flags);
> - next = >properties;
> - while (*next) {
> - if (*next == oldprop) {
> - /* found the node */
> - newprop->next = oldprop->next;
> - *next = newprop;
> - oldprop->next = np->deadprops;
> - np->deadprops = oldprop;
> - found = 1;
> - break;
> - }
> - next = &(*next)->next;
> + oldprop = __of_find_property(np, newprop->name, NULL);
> + if (!oldprop) {
> + /* add the node */
> + rc = __of_add_property(np, newprop);
> + } else {
> + /* replace the node */
> + next = 

Ugh. I just looked closer and the above line is completely broken.
 is the address of 'oldprop' on the stack, *not* the address of
the previous item in the list. The while loop is still required to find it.

g.

> + newprop->next = oldprop->next;
> + *next = newprop;
> + oldprop->next = np->deadprops;
> + np->deadprops = oldprop;
>   }
>   raw_spin_unlock_irqrestore(_lock, flags);
>  
> - if (!found)
> - return -ENODEV;
> -
>  #ifdef CONFIG_PROC_DEVICETREE
>   /* try to add to proc as well if it was initialized */
> - if (np->pde)
> + if (!rc && np->pde)
>   proc_device_tree_update_prop(np->pde, newprop, oldprop);
>  #endif /* CONFIG_PROC_DEVICETREE */
>  
> - return 0;
> + return rc;
>  }
>  
>  #if defined(CONFIG_OF_DYNAMIC)
> -- 
> 1.8.4
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/2] Staging: comedi: convert while loops to timeouts in s626.c

[Chase Southwood]

This patch changes a handful of while loops to timeouts to prevent
infinite looping on hardware failure.  A couple such loops are in a
function (s626_debi_transfer()) which is called from critical sections,
so comedi_timeout() is unusable for them, and an iterative timeout is
used instead.  For the while loops in a context where comedi_timeout() is
allowed, a new callback function, s626_send_dac_eoc(), has been defined
to evaluate the conditions that the while loops are testing.  The new
callback employs a switch statement based on the register offset values
that the status is to be checked from, as this information is enough to
recreate the entire readl() call, and is passed in the 'context'
parameter.  A couple of additional macros have been defined where this
method is not completely sufficient.  The proper comedi_timeout() calls
are then used.

Signed-off-by: Chase Southwood 
---
Ian, my idea for the callback function here is a bit iffy, I'd love to
hear your feedback.  I've created the ret variable because patch 2/2
propogates all errors upwards.

2: Now using comedi_timeout() where allowable.

 drivers/staging/comedi/drivers/s626.c | 81 +--
 1 file changed, 69 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 5ba4b4a..5a7e1c0 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -209,6 +209,8 @@ static const struct comedi_lrange s626_range_table = {
 static void s626_debi_transfer(struct comedi_device *dev)
 {
struct s626_private *devpriv = dev->private;
+   static const int timeout = 1;
+   int i;
 
/* Initiate upload of shadow RAM to DEBI control register */
s626_mc_enable(dev, S626_MC2_UPLD_DEBI, S626_P_MC2);
@@ -217,12 +219,22 @@ static void s626_debi_transfer(struct comedi_device *dev)
 * Wait for completion of upload from shadow RAM to
 * DEBI control register.
 */
-   while (!s626_mc_test(dev, S626_MC2_UPLD_DEBI, S626_P_MC2))
-   ;
+   for (i = 0; i < timeout; i++) {
+   if (s626_mc_test(dev, S626_MC2_UPLD_DEBI, S626_P_MC2))
+   break;
+   udelay(1);
+   }
+   if (i == timeout)
+   comedi_error(dev, "Timeout while uploading to DEBI control 
register.");
 
/* Wait until DEBI transfer is done */
-   while (readl(devpriv->mmio + S626_P_PSR) & S626_PSR_DEBI_S)
-   ;
+   for (i = 0; i < timeout; i++) {
+   if (!(readl(devpriv->mmio + S626_P_PSR) & S626_PSR_DEBI_S))
+   break;
+   udelay(1);
+   }
+   if (i == timeout)
+   comedi_error(dev, "DEBI transfer timeout.");
 }
 
 /*
@@ -351,6 +363,44 @@ static const uint8_t s626_trimadrs[] = {
0x40, 0x41, 0x42, 0x50, 0x51, 0x52, 0x53, 0x60, 0x61, 0x62, 0x63
 };
 
+#define S626_P_FB_BUFFER2_MSB_00   0
+#define S626_P_FB_BUFFER2_MSB_FF   1
+
+static int s626_send_dac_eoc(struct comedi_device *dev,
+   struct comedi_subdevice 
*s,
+   struct comedi_insn 
*insn,
+   unsigned long context)
+{
+   struct s626_private *devpriv = dev->private;
+   unsigned int status;
+
+   switch (context) {
+   case S626_P_MC1:
+   status = readl(devpriv->mmio + S626_P_MC1);
+   if (!(status & S626_MC1_A2OUT))
+   return 0;
+   break;
+   case S626_P_SSR:
+   status = readl(devpriv->mmio + S626_P_SSR);
+   if (status & S626_SSR_AF2_OUT)
+   return 0;
+   break;
+   case S626_P_FB_BUFFER2_MSB_00:
+   status = readl(devpriv->mmio + S626_P_FB_BUFFER2);
+   if (!(status & 0xff00))
+   return 0;
+   break;
+   case S626_P_FB_BUFFER2_MSB_FF:
+   status = readl(devpriv->mmio + S626_P_FB_BUFFER2);
+   if (status & 0xff00)
+   return 0;
+   break;
+   default:
+   return -EINVAL;
+   }
+   return -EBUSY;
+}
+
 /*
  * Private helper function: Transmit serial data to DAC via Audio
  * channel 2.  Assumes: (1) TSL2 slot records initialized, and (2)
@@ -359,6 +409,7 @@ static const uint8_t s626_trimadrs[] = {
 static void s626_send_dac(struct comedi_device *dev, uint32_t val)
 {
struct s626_private *devpriv = dev->private;
+   int ret;
 
/* START THE SERIAL CLOCK RUNNING - */
 
@@ -404,8 +455,9 @@ static void s626_send_dac(struct comedi_device *dev, 
uint32_t val)
 * Done by polling the DMAC enable flag; this flag is automatically
 * cleared when the transfer has finished.
 */
-   while 

[PATCH v2 2/2] Staging: comedi: propagate timeout errors in s626.c

[Chase Southwood]

This patch for s626.c propagates the errors from the newly introduced
calls to comedi_timeout() as far as possible.

Signed-off-by: Chase Southwood 
---
Compile tested only.

 drivers/staging/comedi/drivers/s626.c | 63 +--
 1 file changed, 45 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 5a7e1c0..c6486b0 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -406,7 +406,7 @@ static int s626_send_dac_eoc(struct comedi_device *dev,
  * channel 2.  Assumes: (1) TSL2 slot records initialized, and (2)
  * dacpol contains valid target image.
  */
-static void s626_send_dac(struct comedi_device *dev, uint32_t val)
+static int s626_send_dac(struct comedi_device *dev, uint32_t val)
 {
struct s626_private *devpriv = dev->private;
int ret;
@@ -456,8 +456,10 @@ static void s626_send_dac(struct comedi_device *dev, 
uint32_t val)
 * cleared when the transfer has finished.
 */
ret = comedi_timeout(dev, NULL, NULL, s626_send_dac_eoc, S626_P_MC1);
-   if (ret)
+   if (ret) {
comedi_error(dev, "DMA transfer timeout.");
+   return ret;
+   }
 
/* START THE OUTPUT STREAM TO THE TARGET DAC  */
 
@@ -478,8 +480,10 @@ static void s626_send_dac(struct comedi_device *dev, 
uint32_t val)
 * to the output buffer register.
 */
ret = comedi_timeout(dev, NULL, NULL, s626_send_dac_eoc, S626_P_SSR);
-   if (ret)
+   if (ret) {
comedi_error(dev, "TSL timeout waiting for slot 1 to execute.");
+   return ret;
+   }
 
/*
 * Set up to trap execution at slot 0 when the TSL sequencer cycles
@@ -521,8 +525,10 @@ static void s626_send_dac(struct comedi_device *dev, 
uint32_t val)
 */
ret = comedi_timeout(dev, NULL, NULL, s626_send_dac_eoc,

S626_P_FB_BUFFER2_MSB_00);
-   if (ret)
+   if (ret) {
comedi_error(dev, "TSL timeout waiting for slot 0 to 
execute.");
+   return ret;
+   }
}
/*
 * Either (1) we were too late setting the slot 0 trap; the TSL
@@ -543,14 +549,17 @@ static void s626_send_dac(struct comedi_device *dev, 
uint32_t val)
 */
ret = comedi_timeout(dev, NULL, NULL, s626_send_dac_eoc,
S626_P_FB_BUFFER2_MSB_FF);
-   if (ret)
+   if (ret) {
comedi_error(dev, "TSL timeout waiting for slot 0 to execute.");
+   return ret;
+   }
+   return 0;
 }
 
 /*
  * Private helper function: Write setpoint to an application DAC channel.
  */
-static void s626_set_dac(struct comedi_device *dev, uint16_t chan,
+static int s626_set_dac(struct comedi_device *dev, uint16_t chan,
 int16_t dacdata)
 {
struct s626_private *devpriv = dev->private;
@@ -613,10 +622,10 @@ static void s626_set_dac(struct comedi_device *dev, 
uint16_t chan,
val |= ((uint32_t)(chan & 1) << 15);/* Address the DAC channel
 * within the device. */
val |= (uint32_t)dacdata;   /* Include DAC setpoint data. */
-   s626_send_dac(dev, val);
+   return s626_send_dac(dev, val);
 }
 
-static void s626_write_trim_dac(struct comedi_device *dev, uint8_t 
logical_chan,
+static int s626_write_trim_dac(struct comedi_device *dev, uint8_t logical_chan,
uint8_t dac_data)
 {
struct s626_private *devpriv = dev->private;
@@ -663,17 +672,22 @@ static void s626_write_trim_dac(struct comedi_device 
*dev, uint8_t logical_chan,
 * Address the DAC channel within the trimdac device.
 * Include DAC setpoint data.
 */
-   s626_send_dac(dev, (chan << 8) | dac_data);
+   return s626_send_dac(dev, (chan << 8) | dac_data);
 }
 
-static void s626_load_trim_dacs(struct comedi_device *dev)
+static int s626_load_trim_dacs(struct comedi_device *dev)
 {
uint8_t i;
+   int ret;
 
/* Copy TrimDac setpoint values from EEPROM to TrimDacs. */
-   for (i = 0; i < ARRAY_SIZE(s626_trimchan); i++)
-   s626_write_trim_dac(dev, i,
+   for (i = 0; i < ARRAY_SIZE(s626_trimchan); i++) {
+   ret = s626_write_trim_dac(dev, i,
s626_i2c_read(dev, s626_trimadrs[i]));
+   if (ret)
+   return ret;
+   }
+   return 0;
 }
 
 /* **  COUNTER FUNCTIONS  *** */
@@ -2372,6 +2386,7 @@ static int s626_ao_winsn(struct comedi_device *dev, 
struct comedi_subdevice *s,
 {
struct s626_private *devpriv = dev->private;
int i;
+   int ret;
uint16_t chan = CR_CHAN(insn->chanspec);
 

Re: [PATCH 3/7] staging: cxt1e1: Fix line length over 80 characters in linux.c

[Dan Carpenter]

On Tue, Mar 04, 2014 at 11:08:46AM +0900, Daeseok Youn wrote:
> 
> clean up checkpatch.pl warnings:
>  WARNING: Line length over 80 characters
> 
> Signed-off-by: Daeseok Youn 
> ---
>  drivers/staging/cxt1e1/linux.c |   48 +--
>  1 files changed, 31 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/staging/cxt1e1/linux.c b/drivers/staging/cxt1e1/linux.c
> index 17d73f4..579e68e 100644
> --- a/drivers/staging/cxt1e1/linux.c
> +++ b/drivers/staging/cxt1e1/linux.c
> @@ -31,7 +31,7 @@
>  #include "pmcc4_private.h"
>  #include "sbeproc.h"
>  
> -/*
> +/***

This should just be:

/*
 *
 *

Not ** etc.

Fix in a later patch if you want.

regards,
dan carpenter


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.13 i915 brightness settings broken when going from docked -> undocked

[Jani Nikula]

On Tue, 04 Mar 2014, Paul Bolle  wrote:
> On Tue, 2014-02-25 at 10:05 +0200, Jani Nikula wrote:
>> On Thu, 20 Feb 2014, Paul Bolle  wrote:
>> > On an (rather old) ThinkPad X41, which also uses i915, brightness
>> > adjustments stopped working altogether in v3.14-rc1 (I haven't used its
>> > docking station in the v3.14 release cycle). In v3.13.y things behave as
>> > expected. So perhaps there's actually a more general problem here.
>> 
>> I presume different problems. Does the ThinkPad X41 have gen3 graphics?
>> (See e.g. /sys/kernel/debug/dri/0/i915_capabilities) If yes, it might be
>> https://bugs.freedesktop.org/show_bug.cgi?id=75001
>
> Yes, it has "gen3" graphics (a 915GM). And applying your patch
> "drm/i915: use backlight legacy combination mode also for
> i915gm/i945/gm" on top of v3.14-rc5 fixes the issue on that ThinkPad
> X41.

Thanks for confirming this on i915gm too.

BR,
Jani.


-- 
Jani Nikula, 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: [PATCH v5 5/7] [media] of: move common endpoint parsing to drivers/of

[Tomi Valkeinen]

Hi Philipp,

On 27/02/14 19:35, Philipp Zabel wrote:
> This patch adds a new struct of_endpoint which is then embedded in struct
> v4l2_of_endpoint and contains the endpoint properties that are not V4L2
> (or even media) specific: the port number, endpoint id, local device tree
> node and remote endpoint phandle. of_graph_parse_endpoint parses those
> properties and is used by v4l2_of_parse_endpoint, which just adds the
> V4L2 MBUS information to the containing v4l2_of_endpoint structure.



> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 8ecca7a..ba3cfca 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1985,6 +1985,37 @@ struct device_node *of_find_next_cache_node(const 
> struct device_node *np)
>  }
>  
>  /**
> + * of_graph_parse_endpoint() - parse common endpoint node properties
> + * @node: pointer to endpoint device_node
> + * @endpoint: pointer to the OF endpoint data structure
> + *
> + * All properties are optional. If none are found, we don't set any flags.
> + * This means the port has a static configuration and no properties have
> + * to be specified explicitly.
> + * The caller should hold a reference to @node.
> + */
> +int of_graph_parse_endpoint(const struct device_node *node,
> + struct of_endpoint *endpoint)
> +{
> + struct device_node *port_node = of_get_parent(node);

Can port_node be NULL? Probably only if something is quite wrong, but
maybe it's safer to return error in that case.

> + memset(endpoint, 0, sizeof(*endpoint));
> +
> + endpoint->local_node = node;
> + /*
> +  * It doesn't matter whether the two calls below succeed.
> +  * If they don't then the default value 0 is used.
> +  */
> + of_property_read_u32(port_node, "reg", >port);
> + of_property_read_u32(node, "reg", >id);

If the endpoint does not have 'port' as parent (i.e. the shortened
format), the above will return the 'reg' of the device node (with
'device node' I mean the main node, with 'compatible' property).

And generally speaking, if struct of_endpoint is needed, maybe it would
be better to return the struct of_endpoint when iterating the ports and
endpoints. That way there's no need to do parsing "afterwards", trying
to figure out if there's a parent port node, but the information is
already at hand.

> +
> + of_node_put(port_node);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(of_graph_parse_endpoint);
> +
> +/**
>   * of_graph_get_next_endpoint() - get next endpoint node
>   * @parent: pointer to the parent device node
>   * @prev: previous endpoint node, or NULL to get first
> diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
> index 3bbeb60..2b233db 100644
> --- a/include/linux/of_graph.h
> +++ b/include/linux/of_graph.h
> @@ -14,7 +14,21 @@
>  #ifndef __LINUX_OF_GRAPH_H
>  #define __LINUX_OF_GRAPH_H
>  
> +/**
> + * struct of_endpoint - the OF graph endpoint data structure
> + * @port: identifier (value of reg property) of a port this endpoint belongs 
> to
> + * @id: identifier (value of reg property) of this endpoint
> + * @local_node: pointer to device_node of this endpoint
> + */
> +struct of_endpoint {
> + unsigned int port;
> + unsigned int id;
> + const struct device_node *local_node;
> +};

A few thoughts about the iteration, and the API in general.

In the omapdss version I separated iterating ports and endpoints, for
the two reasons:

1) I think there are cases where you may want to have properties in the
port node, for things that are common for all the port's endpoints.

2) if there are multiple ports, I think the driver code is cleaner if
you first take the port, decide what port that is and maybe call a
sub-function, and then iterate the endpoints for that port only.

Both of those are possible with the API in the series, but not very cleanly.

Also, if you just want to iterate the endpoints, it's easy to implement
a helper using the separate port and endpoint iterations.


Then, about the get_remote functions: I think there should be only one
function for that purpose, one that returns the device node that
contains the remote endpoint.

My reasoning is that the ports and endpoints, and their contents, should
be private to the device. So the only use to get the remote is to get
the actual device, to see if it's been probed, or maybe get some video
API for that device.

If the driver model used has some kind of master-driver, which goes
through all the display entities, I think the above is still valid. When
the master-driver follows the remote-link, it still needs to first get
the main device node, as the ports and endpoints make no sense without
the context of the main device node.

 Tomi




signature.asc
Description: OpenPGP digital signature

[PATCH 0/5] drivers: bus: omap_l3: Conversion to devm_*

[Peter Ujfalusi]

Hi,

Cleanup of platform probe and remove (removing the remove function at the end)
with converting the driver to use the devm_* versions kzalloc, ioremap and
request_irq. 

This is a resend of an old series which I found when doing some spring cleanup
on my HDD:
http://www.spinics.net/lists/linux-omap/msg90531.html

Regards,
Peter
---
Peter Ujfalusi (5):
  drivers: bus: omap_l3: Convert to use devm_kzalloc
  drivers: bus: omap_l3: Convert to use devm_request_and_ioremap()
  drivers: bus: omap_l3: Convert to use devm_request_irq()
  drivers: bus: omap_l3: Remove the platform driver's remove function
  drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request
fails

 drivers/bus/omap_l3_noc.c | 106 +++---
 1 file changed, 24 insertions(+), 82 deletions(-)

-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/5] drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request fails

[Peter Ujfalusi]

Use dev_err() which will going to print the driver's name as well and the
KERN_ERR level is sufficient in this case (we also print via dev_err when
there is an error with the mem resources)

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Santosh Shilimkar 
---
 drivers/bus/omap_l3_noc.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index ed428ada44f7..3a36e3ebcb57 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -162,8 +162,8 @@ static int omap4_l3_probe(struct platform_device *pdev)
ret = devm_request_irq(>dev, l3->debug_irq, l3_interrupt_handler,
   IRQF_DISABLED, "l3-dbg-irq", l3);
if (ret) {
-   pr_crit("L3: request_irq failed to register for 0x%x\n",
-   l3->debug_irq);
+   dev_err(>dev, "request_irq failed for %d\n",
+   l3->debug_irq);
return ret;
}
 
@@ -171,8 +171,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
ret = devm_request_irq(>dev, l3->app_irq, l3_interrupt_handler,
   IRQF_DISABLED, "l3-app-irq", l3);
if (ret)
-   pr_crit("L3: request_irq failed to register for 0x%x\n",
-   l3->app_irq);
+   dev_err(>dev, "request_irq failed for %d\n", l3->app_irq);
 
return ret;
 }
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] drivers: bus: omap_l3: Convert to use devm_request_and_ioremap()

[Peter Ujfalusi]

We can then remove the iounmap() calls from probe and remove.
Since the driver requests the resources via index we can do the mem resource
request within a for loop.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Santosh Shilimkar 
---
 drivers/bus/omap_l3_noc.c | 63 +++
 1 file changed, 15 insertions(+), 48 deletions(-)

diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index d25d727e7cfb..ca95d3db5055 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -131,52 +131,28 @@ static irqreturn_t l3_interrupt_handler(int irq, void 
*_l3)
 static int omap4_l3_probe(struct platform_device *pdev)
 {
static struct omap4_l3 *l3;
-   struct resource *res;
-   int ret;
+   int ret, i;
 
l3 = devm_kzalloc(>dev, sizeof(*l3), GFP_KERNEL);
if (!l3)
return -ENOMEM;
 
platform_set_drvdata(pdev, l3);
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res) {
-   dev_err(>dev, "couldn't find resource 0\n");
-   return -ENODEV;
-   }
-
-   l3->l3_base[0] = ioremap(res->start, resource_size(res));
-   if (!l3->l3_base[0]) {
-   dev_err(>dev, "ioremap failed\n");
-   return -ENOMEM;
-   }
-
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-   if (!res) {
-   dev_err(>dev, "couldn't find resource 1\n");
-   ret = -ENODEV;
-   goto err1;
-   }
 
-   l3->l3_base[1] = ioremap(res->start, resource_size(res));
-   if (!l3->l3_base[1]) {
-   dev_err(>dev, "ioremap failed\n");
-   ret = -ENOMEM;
-   goto err1;
-   }
-
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
-   if (!res) {
-   dev_err(>dev, "couldn't find resource 2\n");
-   ret = -ENODEV;
-   goto err2;
-   }
+   /* Get mem resources */
+   for (i = 0; i < 3; i++) {
+   struct resource *res = platform_get_resource(pdev,
+IORESOURCE_MEM, i);
+   if (!res) {
+   dev_err(>dev, "couldn't find resource %d\n", i);
+   return -ENODEV;
+   }
 
-   l3->l3_base[2] = ioremap(res->start, resource_size(res));
-   if (!l3->l3_base[2]) {
-   dev_err(>dev, "ioremap failed\n");
-   ret = -ENOMEM;
-   goto err2;
+   l3->l3_base[i] = devm_request_and_ioremap(>dev, res);
+   if (!l3->l3_base[i]) {
+   dev_err(>dev, "ioremap %d failed\n", i);
+   return -ENOMEM;
+   }
}
 
/*
@@ -189,7 +165,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
if (ret) {
pr_crit("L3: request_irq failed to register for 0x%x\n",
l3->debug_irq);
-   goto err3;
+   return ret;
}
 
l3->app_irq = platform_get_irq(pdev, 1);
@@ -206,12 +182,6 @@ static int omap4_l3_probe(struct platform_device *pdev)
 
 err4:
free_irq(l3->debug_irq, l3);
-err3:
-   iounmap(l3->l3_base[2]);
-err2:
-   iounmap(l3->l3_base[1]);
-err1:
-   iounmap(l3->l3_base[0]);
return ret;
 }
 
@@ -221,9 +191,6 @@ static int omap4_l3_remove(struct platform_device *pdev)
 
free_irq(l3->app_irq, l3);
free_irq(l3->debug_irq, l3);
-   iounmap(l3->l3_base[0]);
-   iounmap(l3->l3_base[1]);
-   iounmap(l3->l3_base[2]);
 
return 0;
 }
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/5] drivers: bus: omap_l3: Remove the platform driver's remove function

[Peter Ujfalusi]

It is NOP after the devm_* conversion.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Santosh Shilimkar 
---
 drivers/bus/omap_l3_noc.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 2bbc87bdea2b..ed428ada44f7 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -177,11 +177,6 @@ static int omap4_l3_probe(struct platform_device *pdev)
return ret;
 }
 
-static int omap4_l3_remove(struct platform_device *pdev)
-{
-   return 0;
-}
-
 #if defined(CONFIG_OF)
 static const struct of_device_id l3_noc_match[] = {
{.compatible = "ti,omap4-l3-noc", },
@@ -194,7 +189,6 @@ MODULE_DEVICE_TABLE(of, l3_noc_match);
 
 static struct platform_driver omap4_l3_driver = {
.probe  = omap4_l3_probe,
-   .remove = omap4_l3_remove,
.driver = {
.name   = "omap_l3_noc",
.owner  = THIS_MODULE,
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/7] staging: cxt1e1: fix checkpatch error 'assignment in if condition'

[Dan Carpenter]

On Tue, Mar 04, 2014 at 11:09:39AM +0900, Daeseok Youn wrote:
> @@ -1174,7 +1179,8 @@ cleanup_hdlc(void)
>   ci = (ci_t *)(netdev_priv(hi->ndev));
>   for (j = 0; j < ci->max_port; j++)
>   for (k = 0; k < MUSYCC_NCHANS; k++)
> - if ((ndev = ci->port[j].chan[k]->user))
> + ndev = ci->port[j].chan[k]->user;
> + if (ndev)
>   {
>   do_deluser(ndev, 0);
>   }


This patch introduces a bug here because the inner for loop now has two
statement but no curly braces.

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] bridge: multicast: add sanity check for query source addresses

[Hannes Frederic Sowa]

On Tue, Mar 04, 2014 at 03:57:35AM +0100, Linus Lüssing wrote:
> MLD queries are supposed to have an IPv6 link-local source address
> according to RFC2710, section 4 and RFC3810, section 5.1.14. This patch
> adds a sanity check to ignore such broken MLD queries.
> 
> Without this check, such malformed MLD queries can result in a
> denial of service: The queries are ignored by any MLD listener
> therefore they will not respond with an MLD report. However,
> without this patch these malformed MLD queries would enable the
> snooping part in the bridge code, potentially shutting down the
> according ports towards these hosts for multicast traffic as the
> bridge did not learn about these listeners.
> 
> Reported-by: Jan Stancek 
> Signed-off-by: Linus Lüssing 
> ---
>  net/bridge/br_multicast.c |6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> index ef66365..fb0e36f 100644
> --- a/net/bridge/br_multicast.c
> +++ b/net/bridge/br_multicast.c
> @@ -1235,6 +1235,12 @@ static int br_ip6_multicast_query(struct net_bridge 
> *br,
>   (port && port->state == BR_STATE_DISABLED))
>   goto out;
>  
> + /* RFC2710+RFC3810 (MLDv1+MLDv2) require link-local source addresses */
> + if (!(ipv6_addr_type(>saddr) & IPV6_ADDR_LINKLOCAL)) {
> + err = -EINVAL;
> + goto out;
> + }
> +

Shouldn't we allow empty source address, here?

Routers are supposed to drop them but bridges care. Linux uses ::
as source address as long as no valid LL addresses are available,
e.g. at boot-up (RFC3810 5.2.13.).

Greetings,

  Hannes

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 6/7] of: Implement simplified graph binding for single port devices

[Tomi Valkeinen]

On 27/02/14 19:35, Philipp Zabel wrote:
> For simple devices with only one port, it can be made implicit.
> The endpoint node can be a direct child of the device node.



> @@ -2105,9 +2112,11 @@ struct device_node *of_graph_get_remote_port_parent(
>   /* Get remote endpoint node. */
>   np = of_parse_phandle(node, "remote-endpoint", 0);
>  
> - /* Walk 3 levels up only if there is 'ports' node. */
> + /* Walk 3 levels up only if there is 'ports' node */
>   for (depth = 3; depth && np; depth--) {
>   np = of_get_next_parent(np);
> + if (depth == 3 && of_node_cmp(np->name, "port"))
> + break;
>   if (depth == 2 && of_node_cmp(np->name, "ports"))
>   break;
>   }

This function becomes a bit funny. Would it be clearer just to do
something like:

np = of_parse_phandle(node, "remote-endpoint", 0);

np = of_get_next_parent(np);
if (of_node_cmp(np->name, "port") != 0)
return np;

np = of_get_next_parent(np);
if (of_node_cmp(np->name, "ports") != 0)
return np;

np = of_get_next_parent(np);
return np;

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: Ethernet controller not starting

[Christian Riesch]

[cc'ed netdev and davinci-linux-open-source]

--On March 03, 2014 19:39 -0500 Jon Ringle  wrote:


On Mon, Mar 3, 2014 at 6:43 PM, Rafael J. Wysocki 
wrote:

On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote:

I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now
the latest LTS kernel).
I found that Ethernet controller on the board no longer comes up on
linux-3.12. I was able to bisect the issue I'm having to the following
commit:

>   45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit
>   commit 45f0a85c8258741d11bda25c0a5669c06267204a
>   Author: Rafael J. Wysocki 
>   Date:   Mon Jun 3 21:49:52 2013 +0200
>
>   PM / Runtime: Rework the "runtime idle" helper routine
>
>   The "runtime idle" helper routine, rpm_idle(), currently ignores
>   return values from .runtime_idle() callbacks executed by it.
>   However, it turns out that many subsystems use
>   pm_generic_runtime_idle() which checks the return value of the
>   driver's callback and executes pm_runtime_suspend() for the
>   device unless that value is not 0.  If that logic is moved to
>   rpm_idle() instead, pm_generic_runtime_idle() can be dropped
>   and its users will not need any .runtime_idle() callbacks any
>   more.
>
>   Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
>   routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
>   ata_port_runtime_idle(), respectively, as well as a few drivers'
>   ones may be simplified if rpm_idle() calls rpm_suspend() after
>   0 has been returned by the .runtime_idle() callback executed by
>   it.
>
>   To reduce overall code bloat, make the changes described above.
>
>   Tested-by: Mika Westerberg 
>   Tested-by: Kevin Hilman 
>   Signed-off-by: Rafael J. Wysocki 
>   Acked-by: Kevin Hilman 
>   Reviewed-by: Ulf Hansson 
>   Acked-by: Alan Stern 

Can anyone offer any suggestions on what I should be looking for to
fix this on my board?


Any pointers to the driver in question?


drivers/net/ethernet/ti/davinci_emac.c



Hi Jon,
I have successfully used the davinci_emac driver on a custom board with an 
AM1808 SoC with Kernel 3.13 a few weeks ago. So at least 3.13 should work. 
Did you try more recent kernel versions than 3.12?



I also get the following output:

 Starting Network Manager Wait Online...
[   30.946509] davinci_mdio davinci_mdio.0: resetting idled controller
[   30.953220] net net0: attached PHY driver [Generic PHY]
(mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1)
[   30.962938] IPv6: ADDRCONF(NETDEV_UP): net0: link is not ready
[   31.082087] genirq: Flags mismatch irq 33.  (net0) vs.
 (net0)


Is it correct that this warning can only appear in case of shared 
interrupts? See kernel/irq/manage.c. Since we don't use shared interrupts 
here: Are you sure your board configuration is correct with regard to emac 
interrupts? Is your configuration using device tree or not (my 
configuration is a none-devicetree one)? I also wonder why your network 
device is net0, on my board it's eth0, maybe this triggers some bug?


Christian



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] drivers: bus: omap_l3: Convert to use devm_kzalloc

[Peter Ujfalusi]

On 03/04/2014 11:01 AM, Peter Ujfalusi wrote:
> We can remove the kfree() calls from probe and remove.
> 
> Signed-off-by: Peter Ujfalusi 
> Reviewed-by: Santosh Shilimkar 

Where did the ".com" went from Santosh's email address??
I'll resend it in a minute with a fixed commit message.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] drivers: bus: omap_l3: Convert to use devm_request_irq()

[Peter Ujfalusi]

With this we can remove the free_irq() calls from probe and remove.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Santosh Shilimkar 
---
 drivers/bus/omap_l3_noc.c | 23 +--
 1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index ca95d3db5055..2bbc87bdea2b 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -159,9 +159,8 @@ static int omap4_l3_probe(struct platform_device *pdev)
 * Setup interrupt Handlers
 */
l3->debug_irq = platform_get_irq(pdev, 0);
-   ret = request_irq(l3->debug_irq,
-   l3_interrupt_handler,
-   IRQF_DISABLED, "l3-dbg-irq", l3);
+   ret = devm_request_irq(>dev, l3->debug_irq, l3_interrupt_handler,
+  IRQF_DISABLED, "l3-dbg-irq", l3);
if (ret) {
pr_crit("L3: request_irq failed to register for 0x%x\n",
l3->debug_irq);
@@ -169,29 +168,17 @@ static int omap4_l3_probe(struct platform_device *pdev)
}
 
l3->app_irq = platform_get_irq(pdev, 1);
-   ret = request_irq(l3->app_irq,
-   l3_interrupt_handler,
-   IRQF_DISABLED, "l3-app-irq", l3);
-   if (ret) {
+   ret = devm_request_irq(>dev, l3->app_irq, l3_interrupt_handler,
+  IRQF_DISABLED, "l3-app-irq", l3);
+   if (ret)
pr_crit("L3: request_irq failed to register for 0x%x\n",
l3->app_irq);
-   goto err4;
-   }
-
-   return 0;
 
-err4:
-   free_irq(l3->debug_irq, l3);
return ret;
 }
 
 static int omap4_l3_remove(struct platform_device *pdev)
 {
-   struct omap4_l3 *l3 = platform_get_drvdata(pdev);
-
-   free_irq(l3->app_irq, l3);
-   free_irq(l3->debug_irq, l3);
-
return 0;
 }
 
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/5] drivers: bus: omap_l3: Convert to use devm_request_irq()

[Peter Ujfalusi]

With this we can remove the free_irq() calls from probe and remove.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Santosh Shilimkar 
---
 drivers/bus/omap_l3_noc.c | 23 +--
 1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index ca95d3db5055..2bbc87bdea2b 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -159,9 +159,8 @@ static int omap4_l3_probe(struct platform_device *pdev)
 * Setup interrupt Handlers
 */
l3->debug_irq = platform_get_irq(pdev, 0);
-   ret = request_irq(l3->debug_irq,
-   l3_interrupt_handler,
-   IRQF_DISABLED, "l3-dbg-irq", l3);
+   ret = devm_request_irq(>dev, l3->debug_irq, l3_interrupt_handler,
+  IRQF_DISABLED, "l3-dbg-irq", l3);
if (ret) {
pr_crit("L3: request_irq failed to register for 0x%x\n",
l3->debug_irq);
@@ -169,29 +168,17 @@ static int omap4_l3_probe(struct platform_device *pdev)
}
 
l3->app_irq = platform_get_irq(pdev, 1);
-   ret = request_irq(l3->app_irq,
-   l3_interrupt_handler,
-   IRQF_DISABLED, "l3-app-irq", l3);
-   if (ret) {
+   ret = devm_request_irq(>dev, l3->app_irq, l3_interrupt_handler,
+  IRQF_DISABLED, "l3-app-irq", l3);
+   if (ret)
pr_crit("L3: request_irq failed to register for 0x%x\n",
l3->app_irq);
-   goto err4;
-   }
-
-   return 0;
 
-err4:
-   free_irq(l3->debug_irq, l3);
return ret;
 }
 
 static int omap4_l3_remove(struct platform_device *pdev)
 {
-   struct omap4_l3 *l3 = platform_get_drvdata(pdev);
-
-   free_irq(l3->app_irq, l3);
-   free_irq(l3->debug_irq, l3);
-
return 0;
 }
 
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] regulator fixes for v3.14

[Mark Brown]

The following changes since commit acc3d5cec84f82ebea535fa0bd9500ac3df2aee9:

  regulator: core: Change dummy supplies error message to a warning (2014-02-21 
08:35:31 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 
tags/regulator-v3.14-rc5

for you to fetch changes up to 66fda75f47dc583f1c187556e9a2c082dd64f8c6:

  regulator: core: Replace direct ops->disable usage (2014-02-25 10:31:45 +0900)


regulator: Fixes for v3.14-rc5

A couple of fixes here which ensure that regulators using the core
support for GPIO enables work in all cases by ensuring that helpers are
used consistently rather than open coding in places and hence not having
GPIO support in some of them.


Markus Pargmann (2):
  regulator: core: Replace direct ops->enable usage
  regulator: core: Replace direct ops->disable usage

 drivers/regulator/core.c | 48 
 1 file changed, 20 insertions(+), 28 deletions(-)


signature.asc
Description: Digital signature

[PATCH v2 5/5] drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request fails

[Peter Ujfalusi]

Use dev_err() which will going to print the driver's name as well and the
KERN_ERR level is sufficient in this case (we also print via dev_err when
there is an error with the mem resources)

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Santosh Shilimkar 
---
 drivers/bus/omap_l3_noc.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index ed428ada44f7..3a36e3ebcb57 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -162,8 +162,8 @@ static int omap4_l3_probe(struct platform_device *pdev)
ret = devm_request_irq(>dev, l3->debug_irq, l3_interrupt_handler,
   IRQF_DISABLED, "l3-dbg-irq", l3);
if (ret) {
-   pr_crit("L3: request_irq failed to register for 0x%x\n",
-   l3->debug_irq);
+   dev_err(>dev, "request_irq failed for %d\n",
+   l3->debug_irq);
return ret;
}
 
@@ -171,8 +171,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
ret = devm_request_irq(>dev, l3->app_irq, l3_interrupt_handler,
   IRQF_DISABLED, "l3-app-irq", l3);
if (ret)
-   pr_crit("L3: request_irq failed to register for 0x%x\n",
-   l3->app_irq);
+   dev_err(>dev, "request_irq failed for %d\n", l3->app_irq);
 
return ret;
 }
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] trace: module: Maintain a valid user count

[Romain Izard]

The replacement of the 'count' variable by two variables 'incs' and
'decs' to resolve some race conditions during module unloading was done
in parallel with some cleanup in the trace subsystem, and was integrated
as a merge.

Unfortunately, the formula for this replacement was wrong in the tracing
code, and the refcount in the traces was not usable as a result.

Use 'count = incs - decs' to compute the user count.

Signed-off-by: Romain Izard 
---
 include/trace/events/module.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/trace/events/module.h b/include/trace/events/module.h
index 161932737416..ca298c7157ae 100644
--- a/include/trace/events/module.h
+++ b/include/trace/events/module.h
@@ -78,7 +78,7 @@ DECLARE_EVENT_CLASS(module_refcnt,
 
TP_fast_assign(
__entry->ip = ip;
-   __entry->refcnt = __this_cpu_read(mod->refptr->incs) + 
__this_cpu_read(mod->refptr->decs);
+   __entry->refcnt = __this_cpu_read(mod->refptr->incs) - 
__this_cpu_read(mod->refptr->decs);
__assign_str(name, mod->name);
),
 
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/5] drivers: bus: omap_l3: Convert to use devm_request_and_ioremap()

[Peter Ujfalusi]

We can then remove the iounmap() calls from probe and remove.
Since the driver requests the resources via index we can do the mem resource
request within a for loop.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Santosh Shilimkar 
---
 drivers/bus/omap_l3_noc.c | 63 +++
 1 file changed, 15 insertions(+), 48 deletions(-)

diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index d25d727e7cfb..ca95d3db5055 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -131,52 +131,28 @@ static irqreturn_t l3_interrupt_handler(int irq, void 
*_l3)
 static int omap4_l3_probe(struct platform_device *pdev)
 {
static struct omap4_l3 *l3;
-   struct resource *res;
-   int ret;
+   int ret, i;
 
l3 = devm_kzalloc(>dev, sizeof(*l3), GFP_KERNEL);
if (!l3)
return -ENOMEM;
 
platform_set_drvdata(pdev, l3);
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res) {
-   dev_err(>dev, "couldn't find resource 0\n");
-   return -ENODEV;
-   }
-
-   l3->l3_base[0] = ioremap(res->start, resource_size(res));
-   if (!l3->l3_base[0]) {
-   dev_err(>dev, "ioremap failed\n");
-   return -ENOMEM;
-   }
-
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-   if (!res) {
-   dev_err(>dev, "couldn't find resource 1\n");
-   ret = -ENODEV;
-   goto err1;
-   }
 
-   l3->l3_base[1] = ioremap(res->start, resource_size(res));
-   if (!l3->l3_base[1]) {
-   dev_err(>dev, "ioremap failed\n");
-   ret = -ENOMEM;
-   goto err1;
-   }
-
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
-   if (!res) {
-   dev_err(>dev, "couldn't find resource 2\n");
-   ret = -ENODEV;
-   goto err2;
-   }
+   /* Get mem resources */
+   for (i = 0; i < 3; i++) {
+   struct resource *res = platform_get_resource(pdev,
+IORESOURCE_MEM, i);
+   if (!res) {
+   dev_err(>dev, "couldn't find resource %d\n", i);
+   return -ENODEV;
+   }
 
-   l3->l3_base[2] = ioremap(res->start, resource_size(res));
-   if (!l3->l3_base[2]) {
-   dev_err(>dev, "ioremap failed\n");
-   ret = -ENOMEM;
-   goto err2;
+   l3->l3_base[i] = devm_request_and_ioremap(>dev, res);
+   if (!l3->l3_base[i]) {
+   dev_err(>dev, "ioremap %d failed\n", i);
+   return -ENOMEM;
+   }
}
 
/*
@@ -189,7 +165,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
if (ret) {
pr_crit("L3: request_irq failed to register for 0x%x\n",
l3->debug_irq);
-   goto err3;
+   return ret;
}
 
l3->app_irq = platform_get_irq(pdev, 1);
@@ -206,12 +182,6 @@ static int omap4_l3_probe(struct platform_device *pdev)
 
 err4:
free_irq(l3->debug_irq, l3);
-err3:
-   iounmap(l3->l3_base[2]);
-err2:
-   iounmap(l3->l3_base[1]);
-err1:
-   iounmap(l3->l3_base[0]);
return ret;
 }
 
@@ -221,9 +191,6 @@ static int omap4_l3_remove(struct platform_device *pdev)
 
free_irq(l3->app_irq, l3);
free_irq(l3->debug_irq, l3);
-   iounmap(l3->l3_base[0]);
-   iounmap(l3->l3_base[1]);
-   iounmap(l3->l3_base[2]);
 
return 0;
 }
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 4/5] drivers: bus: omap_l3: Remove the platform driver's remove function

[Peter Ujfalusi]

It is NOP after the devm_* conversion.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Santosh Shilimkar 
---
 drivers/bus/omap_l3_noc.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 2bbc87bdea2b..ed428ada44f7 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -177,11 +177,6 @@ static int omap4_l3_probe(struct platform_device *pdev)
return ret;
 }
 
-static int omap4_l3_remove(struct platform_device *pdev)
-{
-   return 0;
-}
-
 #if defined(CONFIG_OF)
 static const struct of_device_id l3_noc_match[] = {
{.compatible = "ti,omap4-l3-noc", },
@@ -194,7 +189,6 @@ MODULE_DEVICE_TABLE(of, l3_noc_match);
 
 static struct platform_driver omap4_l3_driver = {
.probe  = omap4_l3_probe,
-   .remove = omap4_l3_remove,
.driver = {
.name   = "omap_l3_noc",
.owner  = THIS_MODULE,
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/5] drivers: bus: omap_l3: Conversion to devm_*

[Peter Ujfalusi]

Hi,

Changes since v1:
- Fixed Santosh's email address in the commit messages.

Cleanup of platform probe and remove (removing the remove function at the end)
with converting the driver to use the devm_* versions kzalloc, ioremap and
request_irq. 

This is a resend of an old series which I found when doing some spring cleanup
on my HDD:
http://www.spinics.net/lists/linux-omap/msg90531.html

Regards,
Peter
---
Peter Ujfalusi (5):
  drivers: bus: omap_l3: Convert to use devm_kzalloc
  drivers: bus: omap_l3: Convert to use devm_request_and_ioremap()
  drivers: bus: omap_l3: Convert to use devm_request_irq()
  drivers: bus: omap_l3: Remove the platform driver's remove function
  drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request
fails

 drivers/bus/omap_l3_noc.c | 106 +++---
 1 file changed, 24 insertions(+), 82 deletions(-)

-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/5] drivers: bus: omap_l3: Convert to use devm_kzalloc

[Peter Ujfalusi]

We can remove the kfree() calls from probe and remove.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Santosh Shilimkar 
---
 drivers/bus/omap_l3_noc.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index feeecae623f6..d25d727e7cfb 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -134,7 +134,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
struct resource *res;
int ret;
 
-   l3 = kzalloc(sizeof(*l3), GFP_KERNEL);
+   l3 = devm_kzalloc(>dev, sizeof(*l3), GFP_KERNEL);
if (!l3)
return -ENOMEM;
 
@@ -142,15 +142,13 @@ static int omap4_l3_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(>dev, "couldn't find resource 0\n");
-   ret = -ENODEV;
-   goto err0;
+   return -ENODEV;
}
 
l3->l3_base[0] = ioremap(res->start, resource_size(res));
if (!l3->l3_base[0]) {
dev_err(>dev, "ioremap failed\n");
-   ret = -ENOMEM;
-   goto err0;
+   return -ENOMEM;
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
@@ -214,8 +212,6 @@ err2:
iounmap(l3->l3_base[1]);
 err1:
iounmap(l3->l3_base[0]);
-err0:
-   kfree(l3);
return ret;
 }
 
@@ -228,7 +224,6 @@ static int omap4_l3_remove(struct platform_device *pdev)
iounmap(l3->l3_base[0]);
iounmap(l3->l3_base[1]);
iounmap(l3->l3_base[2]);
-   kfree(l3);
 
return 0;
 }
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: What is wrong?

[Leon Pollak]

Hello, all.

I am really sorry for the silence - I was on the business trip and 
returned today.

I will recheck everything and try. Meanwhile, the news are not good: our 
guys say that it appears that the additional sync DOES NOT SOLVE the 
issue.
I ask for excuse, but as I did not know the exact processing, I was 
mistaken and, probably, used already gc-ted unit for tests.

Sorry, again.

BR

On Tuesday 04 March 2014 00:33:25 Brian Norris wrote:
> On Mon, Mar 03, 2014 at 03:13:36PM -0600, Andrew Ruder wrote:
> > On Thu, Feb 27, 2014 at 01:22:08PM -0800, Brian Norris wrote:
> > > Perhaps Richard or Andrew can comment on whether this patch should
> > > help you. But I think JFFS2 on NAND uses write-buffered support
> > > which can be affected by this bug.
> > 
> > Definitely sounds like the same issue and I'm kind of glad to see it
> > crop up in another filesystem.
> 
> We haven't confirmed that the *patch* actually affects Leon's problem;
> just that if he runs an additional 'sync' it solves his problem.
> Leon, did you get to try the patch?
> 
> Anyway, should commit 807612db2f9940b9fa6deaef054eb16d51bd3e00 be
> marked for -stable?
> 
> Brian

-- 
Leon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] CNS3xxx: Fix PCIe early iotable_init().

[Krzysztof Hałasa]

khal...@piap.pl (Krzysztof Hałasa) writes:

> This patch fixes the following BUG:
>
>> kernel BUG at mm/vmalloc.c:1132!
>> PC is at vm_area_add_early+0x20/0x84
>> LR is at add_static_vm_early+0xc/0x60
>>
>> The problem is cns3xxx_pcie_init() (device_initcall) calls the "early"
>> iotable_init().

That's obviously:

Signed-off-by: Krzysztof Hałasa 

-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] drivers: bus: omap_l3: Convert to use devm_request_and_ioremap()

[Alexander Shiyan]

Вторник,  4 марта 2014, 11:01 +02:00 от Peter Ujfalusi :
> We can then remove the iounmap() calls from probe and remove.
> Since the driver requests the resources via index we can do the mem resource
> request within a for loop.
> 
> Signed-off-by: Peter Ujfalusi 
> Reviewed-by: Santosh Shilimkar 
> ---

> + /* Get mem resources */
> + for (i = 0; i < 3; i++) {
> + struct resource *res = platform_get_resource(pdev,
> +  IORESOURCE_MEM, i);
> + if (!res) {
> + dev_err(>dev, "couldn't find resource %d\n", i);
> + return -ENODEV;
> + }

No need to check "res". devm_request_and_ioremap() do all for us.

> - l3->l3_base[2] = ioremap(res->start, resource_size(res));
> - if (!l3->l3_base[2]) {
> - dev_err(>dev, "ioremap failed\n");
> - ret = -ENOMEM;
> - goto err2;
> + l3->l3_base[i] = devm_request_and_ioremap(>dev, res);
> + if (!l3->l3_base[i]) {

if (IS_ERR(l3->l3_base[i]))

> + dev_err(>dev, "ioremap %d failed\n", i);

Unnecessary.

> + return -ENOMEM;

return PTR_ERR(l3->l3_base[i]);

---
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH] drivers:staging:ozwpan Replaced wrapper functions with actual spin lock function

[Dan Carpenter]

On Mon, Mar 03, 2014 at 11:57:47PM -0800, Surendra Patil wrote:
> * Replaced all the spin lock/unlock wrappers from oz_polling_lock_bh()
> and oz_polllin_unlock_bh() with spin_lock_bh(_polling_lock) and
> spin_unlock_bh(_polling_lock).Completely erased the wrappers defination
> and declaration.
> * declared g_polling_lock as global variable in header file and added 
> comments to it.
> Module builded successfully with sparse without warnings.
> 
> Signed-off-by: Surendra Patil 

Looks good, thanks.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/5] drivers: bus: omap_l3: Convert to use devm_kzalloc

[Peter Ujfalusi]

We can remove the kfree() calls from probe and remove.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Santosh Shilimkar 
---
 drivers/bus/omap_l3_noc.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index feeecae623f6..d25d727e7cfb 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -134,7 +134,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
struct resource *res;
int ret;
 
-   l3 = kzalloc(sizeof(*l3), GFP_KERNEL);
+   l3 = devm_kzalloc(>dev, sizeof(*l3), GFP_KERNEL);
if (!l3)
return -ENOMEM;
 
@@ -142,15 +142,13 @@ static int omap4_l3_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(>dev, "couldn't find resource 0\n");
-   ret = -ENODEV;
-   goto err0;
+   return -ENODEV;
}
 
l3->l3_base[0] = ioremap(res->start, resource_size(res));
if (!l3->l3_base[0]) {
dev_err(>dev, "ioremap failed\n");
-   ret = -ENOMEM;
-   goto err0;
+   return -ENOMEM;
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
@@ -214,8 +212,6 @@ err2:
iounmap(l3->l3_base[1]);
 err1:
iounmap(l3->l3_base[0]);
-err0:
-   kfree(l3);
return ret;
 }
 
@@ -228,7 +224,6 @@ static int omap4_l3_remove(struct platform_device *pdev)
iounmap(l3->l3_base[0]);
iounmap(l3->l3_base[1]);
iounmap(l3->l3_base[2]);
-   kfree(l3);
 
return 0;
 }
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 02/12] phy: omap-control: Update DT binding information

[Roger Quadros]

Hi Tony,

On 03/03/2014 09:02 PM, Tony Lindgren wrote:
> * Roger Quadros  [140303 07:10]:
>> Move omap-control binding information to the right location.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  Documentation/devicetree/bindings/phy/ti-phy.txt   | 25 
>> ++
>>  Documentation/devicetree/bindings/usb/omap-usb.txt | 24 
>> -
>>  2 files changed, 25 insertions(+), 24 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
>> b/Documentation/devicetree/bindings/phy/ti-phy.txt
>> index 207e14c..41dc132 100644
>> --- a/Documentation/devicetree/bindings/phy/ti-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
>> @@ -1,5 +1,30 @@
>>  TI PHY: DT DOCUMENTATION FOR PHYs in TI PLATFORMs
>>  
>> +OMAP CONTROL PHY
>> +
>> +Required properties:
>> + - compatible: Should be one of
>> + "ti,control-phy-otghs" - if it has otghs_control mailbox register as on 
>> OMAP4.
>> + "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf 
>> register
>> +e.g. USB2_PHY on OMAP5.
>> + "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power 
>> control
>> +e.g. USB3 PHY and SATA PHY on OMAP5.
>> + "ti,control-phy-dra7usb2" - if it has power down register like USB2 PHY on
>> +DRA7 platform.
>> + "ti,control-phy-am437usb2" - if it has power down register like USB2 PHY on
>> +AM437 platform.
> 
> To me it seems that you can leave out all the above. You can set these falgs
> flags directly in the driver based on the compatible flag. Then just 
> initialize
> the .data in the driver based on the compatible flag.

I'm not sure if I got you. A single platform can have different type of phys.

e.g. OMAP5 has both usb2 and pipe3 PHYs,
DRA7 has both pipe3 and usb2 PHYs, but this usb2 PHY is not compatible with 
OMAP5 one
so we need a new compatible id for that.

To add to the woes, the designers were creative enough to make another mutation 
to
the USB2 PHY for AM437x, :(

What do you suggest the compatible ids should look like for these 5 types of 
PHY control?
OTGHS   (OMAP4 & 5)
USB2(OMAP5)
PIPE3   (OMAP5 & DRA7)
USB2x   (DRA7)
USB2y   (AM437)

cheers,
-roger

> 
>> + - reg : Address and length of the register set for the device. It contains
>> +   the address of "otghs_control" for control-phy-otghs or "power" register
>> +   for other types.
>> + - reg-names: should be "otghs_control" control-phy-otghs and "power" for
>> +   other types.
>> +
>> +omap_control_usb: omap-control-usb@4a002300 {
>> +compatible = "ti,control-phy-otghs";
>> +reg = <0x4a00233c 0x4>;
>> +reg-names = "otghs_control";
>> +};
> 
> Then you would instead have something like this:
> 
>   compatible = "ti,am347-control-phy-otghs";
> 
> That way you can initialize things without a need for custom bindings.
> 
> Regards,
> 
> Tony
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 06/12] phy: omap: Select OMAP_OCP2SCP bus driver

[Roger Quadros]

On 03/03/2014 08:52 PM, Tony Lindgren wrote:
> * Roger Quadros  [140303 07:11]:
>> The OMAP_USB2 and OMAP_PIP3 phy devices will not be
>> detected if the OMAP_OCP2SCP driver is not present.
>> So select it.
> 
> Selecting drivers like this will easily lead into missing
> dependencies. Especially it's bad for tristate driver
> options that people may want to have as loadable modules.
> 
> How about instead depends on OMAP_OCP2SCP?

OK, 'depends' seems fine.

cheers,
-roger

> 
>  
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/phy/Kconfig | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 2f02ec8..afdab3e 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -44,6 +44,7 @@ config OMAP_USB2
>>  depends on USB_PHY
>>  select GENERIC_PHY
>>  select OMAP_CONTROL_PHY
>> +select OMAP_OCP2SCP
>>  help
>>Enable this to support the transceiver that is part of SOC. This
>>driver takes care of all the PHY functionality apart from comparator.
>> @@ -55,6 +56,7 @@ config TI_PIPE3
>>  depends on ARCH_OMAP2PLUS || COMPILE_TEST
>>  select GENERIC_PHY
>>  select OMAP_CONTROL_PHY
>> +select OMAP_OCP2SCP
>>  help
>>Enable this to support the PIPE3 PHY that is part of TI SOCs. This
>>driver takes care of all the PHY functionality apart from comparator.
>> -- 
>> 1.8.3.2
>>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] drivers: bus: omap_l3: Convert to use devm_request_and_ioremap()

[Alexander Shiyan]

Вторник,  4 марта 2014, 13:12 +04:00 от Alexander Shiyan :
> Вторник,  4 марта 2014, 11:01 +02:00 от Peter Ujfalusi 
> :
> > We can then remove the iounmap() calls from probe and remove.
> > Since the driver requests the resources via index we can do the mem resource
> > request within a for loop.
> > 
> > Signed-off-by: Peter Ujfalusi 
> > Reviewed-by: Santosh Shilimkar 
> > ---
> 
> > +   /* Get mem resources */
> > +   for (i = 0; i < 3; i++) {
> > +   struct resource *res = platform_get_resource(pdev,
> > +IORESOURCE_MEM, i);
> > +   if (!res) {
> > +   dev_err(>dev, "couldn't find resource %d\n", i);
> > +   return -ENODEV;
> > +   }
> 
> No need to check "res". devm_request_and_ioremap() do all for us.
> 
> > -   l3->l3_base[2] = ioremap(res->start, resource_size(res));
> > -   if (!l3->l3_base[2]) {
> > -   dev_err(>dev, "ioremap failed\n");
> > -   ret = -ENOMEM;
> > -   goto err2;
> > +   l3->l3_base[i] = devm_request_and_ioremap(>dev, res);
> > +   if (!l3->l3_base[i]) {
> 
> if (IS_ERR(l3->l3_base[i]))

Ahh, I messed up this with devm_ioremap_resource().
However, if there is reason to use devm_request_and_ioremap() here?

---

Re: [PATCH V2] support Thinkpad X1 Carbon's adaptive keyboard

[Tobias Klauser]

On 2014-03-03 at 17:31:08 +0100, Shuduo Sang  wrote:
[...]
> +/* press Fn key a while second, it will switch to Function Mode. Then
> + * release Fn key, previous mode be restored.
> + */
> +bool adaptive_keyboard_mode_is_saved;
> +int adaptive_keybarod_prev_mode;

These should probably be made static, since they're only used inside the
module.

> +static int adaptive_keyboard_get_next_mode(int mode)
> +{
> + int i;
> + int max_mode = ARRAY_SIZE(adaptive_keyboard_modes) - 1;

sizeof and thus ARRAY_SIZE returns a size_t, so i and max_mode could be
of type size_t as well.

> +
> + for (i = 0; i <= max_mode; i++) {
> + if (adaptive_keyboard_modes[i] == mode)
> + break;
> + }
> +
> + if (i >= max_mode)
> + i = 0;
> + else
> + i++;
> +
> + return adaptive_keyboard_modes[i];
> +}
> +
> +static bool adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
> +{
> + u32 current_mode = 0;
> + int new_mode = 0;
> +
> + switch (scancode) {
> + case DFR_CHANGE_ROW:
> + if (adaptive_keyboard_mode_is_saved) {
> + new_mode = adaptive_keybarod_prev_mode;
> + adaptive_keyboard_mode_is_saved = false;
> + } else {
> + if (!acpi_evalf(
> + hkey_handle, _mode,
> + "GTRW", "dd", 0)) {
> + pr_err("Cannot read adaptive keyboard mode\n");
> + return false;
> + } else {
> + new_mode = adaptive_keyboard_get_next_mode(
> + current_mode);
> + }
> + }
> +
> + if (!acpi_evalf(hkey_handle, NULL, "STRW", "vd", new_mode)) {
> + pr_err("Cannot set adaptive keyboard mode\n");
> + return false;
> + }
> +
> + return true;
> +
> + case DFR_SHOW_QUICKVIEW_ROW:
> + if (!acpi_evalf(hkey_handle,
> + _keybarod_prev_mode,
> + "GTRW", "dd", 0)) {
> + pr_err("Cannot read adaptive keyboard mode\n");
> + return false;
> + } else {
> + adaptive_keyboard_mode_is_saved = true;
> +
> + if (!acpi_evalf(hkey_handle,
> + NULL, "STRW", "vd", FUNCTION_MODE)) {
> + pr_err("Cannot set adaptive keyboard mode\n");
> + return false;
> + }
> + }
> + return true;
> +
> + default:
> + return false;
> + }
> +}
> +
>  static bool hotkey_notify_hotkey(const u32 hkey,
>bool *send_acpi_ev,
>bool *ignore_acpi_ev)
> @@ -3456,6 +3556,8 @@ static bool hotkey_notify_hotkey(const u32 hkey,
>   *ignore_acpi_ev = true;
>   }
>   return true;
> + } else {
> + return adaptive_keyboard_hotkey_notify_hotkey(scancode);
>   }
>   return false;
>  }
> -- 
> 1.9.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Andrew Lunn]

> I could have sworn this was discussed with this particular patchset, but
> I'm unable to find the conversation in my archives.  Neither during the
> patch submission process, nor the (long) pull request thread.
> 
> Perhaps it was an irc conversation?  Andrew, Sebastian, can you find a
> link?  iirc, one of the DT maintainers (Mark Rutland?) raised the same
> concern and I thought we answered that sufficiently...

Hi Jason

It was the cpufreq driver which caused the discussion. I looked at it
for a while, and then task swapped onto the kirkwood move into
mach-mvebu.

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/12] phy: rename struct omap_control_usb to struct omap_control_phy

[Kishon Vijay Abraham I]

Roger,

On Monday 03 March 2014 08:37 PM, Roger Quadros wrote:

From: Kishon Vijay Abraham I 

Rename struct omap_control_usb to struct omap_control_phy since it can
be used to control PHY of USB, SATA and PCIE. Also move the driver and
include files under *phy* and made the corresponding changes in the users
of phy-omap-control.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Roger Quadros 
---
  drivers/phy/Kconfig  |  14 +-
  drivers/phy/Makefile |   1 +
  drivers/phy/phy-omap-control.c   | 320 +++
  drivers/phy/phy-omap-usb2.c  |   8 +-
  drivers/phy/phy-ti-pipe3.c   |   8 +-
  drivers/usb/musb/omap2430.c  |   2 +-
  drivers/usb/phy/Kconfig  |  10 --
  drivers/usb/phy/Makefile |   1 -
  drivers/usb/phy/phy-omap-control.c   | 319 --
  include/linux/phy/omap_control_phy.h |  89 ++
  include/linux/usb/omap_control_usb.h |  89 --
  11 files changed, 431 insertions(+), 430 deletions(-)
  create mode 100644 drivers/phy/phy-omap-control.c
  delete mode 100644 drivers/usb/phy/phy-omap-control.c
  create mode 100644 include/linux/phy/omap_control_phy.h
  delete mode 100644 include/linux/usb/omap_control_usb.h


you can use git format-patch -M if a file is moved from one place to 
another. The diff count will be less in that case and reviewing will be 
easier ;-)


Cheers
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 03/12] phy: ti-pipe3: cleanup clock handling

[Kishon Vijay Abraham I]

Hi,

On Monday 03 March 2014 08:37 PM, Roger Quadros wrote:

As this driver is no longer USB specific, use generic clock names.
- Fix PLL_SD_SHIFT from 9 to 10
- As optclk and wkupclk may not be always required, don't bail out
if they aren't available.


I think here too we face the same problem as for PHY. What if a 
particular platform needs a clock but is not available. I don't want 
this to be blocking though.


Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC][PATCH 0/3] Remove set_cache_io entirely from ASoC probe

[Xiubo Li]

Xiubo Li (3):
  ASoC: core: Move the default regmap I/O setting to
snd_soc_register_codec()
  ASoc: codec: remove the set_cache_io() entirely from CODEC ASoC probe.
  ASoC: core: remove the default regmap I/O setting up from
soc_probe_codec()

 include/sound/soc.h|  3 +++
 sound/soc/codecs/cq93vc.c  |  6 --
 sound/soc/codecs/mc13783.c | 10 ++
 sound/soc/codecs/wm5102.c  |  6 ++
 sound/soc/codecs/wm5110.c  |  6 ++
 sound/soc/codecs/wm8350.c  |  6 --
 sound/soc/codecs/wm8400.c  |  6 --
 sound/soc/codecs/wm8994.c  |  4 ++--
 sound/soc/codecs/wm8997.c  |  7 ++-
 sound/soc/soc-core.c   | 21 +++--
 10 files changed, 36 insertions(+), 39 deletions(-)

-- 
1.8.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/

[RFC][PATCH 2/3] ASoc: codec: remove the set_cache_io() entirely from CODEC ASoC probe.

[Xiubo Li]

As we can set the CODEC I/O while snd_soc_register_codec(), so the
calling of set_cache_io() from CODEC ASoC probe could be removed
entirely.

Signed-off-by: Xiubo Li 
---
 sound/soc/codecs/cq93vc.c  |  6 --
 sound/soc/codecs/mc13783.c | 10 ++
 sound/soc/codecs/wm5102.c  |  6 ++
 sound/soc/codecs/wm5110.c  |  6 ++
 sound/soc/codecs/wm8350.c  |  6 --
 sound/soc/codecs/wm8400.c  |  6 --
 sound/soc/codecs/wm8994.c  |  4 ++--
 sound/soc/codecs/wm8997.c  |  7 ++-
 8 files changed, 22 insertions(+), 29 deletions(-)

diff --git a/sound/soc/codecs/cq93vc.c b/sound/soc/codecs/cq93vc.c
index 1e25c7a..27e2b7e 100644
--- a/sound/soc/codecs/cq93vc.c
+++ b/sound/soc/codecs/cq93vc.c
@@ -139,8 +139,6 @@ static int cq93vc_probe(struct snd_soc_codec *codec)
 
davinci_vc->cq93vc.codec = codec;
 
-   snd_soc_codec_set_cache_io(codec, davinci_vc->regmap);
-
/* Off, with power on */
cq93vc_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
 
@@ -165,6 +163,10 @@ static struct snd_soc_codec_driver soc_codec_dev_cq93vc = {
 
 static int cq93vc_platform_probe(struct platform_device *pdev)
 {
+   struct davinci_vc *davinci_vc = codec->dev->platform_data;
+
+   soc_codec_dev_cq93vc.regmap = davinci_vc->regmap;
+
return snd_soc_register_codec(>dev,
_codec_dev_cq93vc, _dai, 1);
 }
diff --git a/sound/soc/codecs/mc13783.c b/sound/soc/codecs/mc13783.c
index 3331cc7..63b4dcb 100644
--- a/sound/soc/codecs/mc13783.c
+++ b/sound/soc/codecs/mc13783.c
@@ -612,14 +612,6 @@ static struct snd_kcontrol_new mc13783_control_list[] = {
 static int mc13783_probe(struct snd_soc_codec *codec)
 {
struct mc13783_priv *priv = snd_soc_codec_get_drvdata(codec);
-   int ret;
-
-   ret = snd_soc_codec_set_cache_io(codec,
-   dev_get_regmap(codec->dev->parent, NULL));
-   if (ret != 0) {
-   dev_err(codec->dev, "Failed to set cache I/O: %d\n", ret);
-   return ret;
-   }
 
/* these are the reset values */
mc13xxx_reg_write(priv->mc13xxx, MC13783_AUDIO_RX0, 0x25893);
@@ -770,6 +762,8 @@ static int __init mc13783_codec_probe(struct 
platform_device *pdev)
dev_set_drvdata(>dev, priv);
priv->mc13xxx = dev_get_drvdata(pdev->dev.parent);
 
+   soc_codec_dev_mc13783.regmap = dev_get_regmap(pdev->dev->parent, NULL);
+
if (priv->adc_ssi_port == priv->dac_ssi_port)
ret = snd_soc_register_codec(>dev, _codec_dev_mc13783,
mc13783_dai_sync, ARRAY_SIZE(mc13783_dai_sync));
diff --git a/sound/soc/codecs/wm5102.c b/sound/soc/codecs/wm5102.c
index 01b6ee4..4c3ebfd 100644
--- a/sound/soc/codecs/wm5102.c
+++ b/sound/soc/codecs/wm5102.c
@@ -1760,10 +1760,6 @@ static int wm5102_codec_probe(struct snd_soc_codec 
*codec)
struct wm5102_priv *priv = snd_soc_codec_get_drvdata(codec);
int ret;
 
-   ret = snd_soc_codec_set_cache_io(codec, priv->core.arizona->regmap);
-   if (ret != 0)
-   return ret;
-
ret = snd_soc_add_codec_controls(codec, wm_adsp2_fw_controls, 2);
if (ret != 0)
return ret;
@@ -1874,6 +1870,8 @@ static int wm5102_probe(struct platform_device *pdev)
pm_runtime_enable(>dev);
pm_runtime_idle(>dev);
 
+   soc_codec_dev_wm5102.regmap = arizona->regmap;
+
return snd_soc_register_codec(>dev, _codec_dev_wm5102,
  wm5102_dai, ARRAY_SIZE(wm5102_dai));
 }
diff --git a/sound/soc/codecs/wm5110.c b/sound/soc/codecs/wm5110.c
index cf5d828f..bfb4597 100644
--- a/sound/soc/codecs/wm5110.c
+++ b/sound/soc/codecs/wm5110.c
@@ -1589,10 +1589,6 @@ static int wm5110_codec_probe(struct snd_soc_codec 
*codec)
 
priv->core.arizona->dapm = >dapm;
 
-   ret = snd_soc_codec_set_cache_io(codec, priv->core.arizona->regmap);
-   if (ret != 0)
-   return ret;
-
arizona_init_spk(codec);
arizona_init_gpio(codec);
 
@@ -1710,6 +1706,8 @@ static int wm5110_probe(struct platform_device *pdev)
pm_runtime_enable(>dev);
pm_runtime_idle(>dev);
 
+   soc_codec_dev_wm5110.regmap = arizona->regmap;
+
return snd_soc_register_codec(>dev, _codec_dev_wm5110,
  wm5110_dai, ARRAY_SIZE(wm5110_dai));
 }
diff --git a/sound/soc/codecs/wm8350.c b/sound/soc/codecs/wm8350.c
index 757256b..9a8f4d4 100644
--- a/sound/soc/codecs/wm8350.c
+++ b/sound/soc/codecs/wm8350.c
@@ -1505,8 +1505,6 @@ static  int wm8350_codec_probe(struct snd_soc_codec 
*codec)
if (ret != 0)
return ret;
 
-   snd_soc_codec_set_cache_io(codec, wm8350->regmap);
-
/* Put the codec into reset if it wasn't already */
wm8350_clear_bits(wm8350, WM8350_POWER_MGMT_5, WM8350_CODEC_ENA);
 
@@ -1625,6 +1623,10 @@ static struct snd_soc_codec_driver soc_codec_dev_wm8350 
= {
 
 static int wm8350_probe(struct platform_device *pdev)
 {
+   struct 

[RFC][PATCH 3/3] ASoC: core: remove the default regmap I/O setting up from soc_probe_codec()

[Xiubo Li]

Since all the CODEC drivers has using the snd_soc_register_codec()
to set up the CODEC I/O while the CODEC probing, so this could be
removed entirely.

Signed-off-by: Xiubo Li 
---
 sound/soc/soc-core.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 0fb502f..bc3a930 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1137,16 +1137,6 @@ static int soc_probe_codec(struct snd_soc_card *card,
 
codec->dapm.idle_bias_off = driver->idle_bias_off;
 
-   if (!codec->write && dev_get_regmap(codec->dev, NULL)) {
-   /* Set the default I/O up try regmap */
-   ret = snd_soc_codec_set_cache_io(codec, NULL);
-   if (ret < 0) {
-   dev_err(codec->dev,
-   "Failed to set cache I/O: %d\n", ret);
-   goto err_probe;
-   }
-   }
-
if (driver->probe) {
ret = driver->probe(codec);
if (ret < 0) {
-- 
1.8.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/

[RFC][PATCH 1/3] ASoC: core: Move the default regmap I/O setting to snd_soc_register_codec()

[Xiubo Li]

Add the default regmap I/O setting to snd_soc_register_codec() while
the CODEC is initialising, which will be called by CODEC driver device
probe(), and then we can make set_cache_io() go away entirely from each
CODEC ASoC probe.

Signed-off-by: Xiubo Li 
---
 include/sound/soc.h  |  3 +++
 sound/soc/soc-core.c | 11 +++
 2 files changed, 14 insertions(+)

diff --git a/include/sound/soc.h b/include/sound/soc.h
index 4c4d7e1..94bc1c4 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -749,6 +749,9 @@ struct snd_soc_codec_driver {
int (*set_pll)(struct snd_soc_codec *codec, int pll_id, int source,
unsigned int freq_in, unsigned int freq_out);
 
+   /* codec regmap */
+   struct regmap *regmap;
+
/* codec IO */
unsigned int (*read)(struct snd_soc_codec *, unsigned int);
int (*write)(struct snd_soc_codec *, unsigned int, unsigned int);
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index a14155b..0fb502f 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -4443,6 +4443,17 @@ int snd_soc_register_codec(struct device *dev,
codec->num_dai = num_dai;
mutex_init(>mutex);
 
+   if (!codec->write && (codec_drv->regmap ||
+ dev_get_regmap(codec->dev, NULL))) {
+   /* Set the default I/O up try regmap */
+   ret = snd_soc_codec_set_cache_io(codec, codec_drv->regmap);
+   if (ret < 0 && ret != -ENOTSUPP) {
+   dev_err(codec->dev,
+   "Failed to set cache I/O: %d\n", ret);
+   goto fail_codec_name;
+   }
+   }
+
for (i = 0; i < num_dai; i++) {
fixup_codec_formats(_drv[i].playback);
fixup_codec_formats(_drv[i].capture);
-- 
1.8.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 03/12] phy: ti-pipe3: cleanup clock handling

[Roger Quadros]

On 03/04/2014 11:29 AM, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Monday 03 March 2014 08:37 PM, Roger Quadros wrote:
>> As this driver is no longer USB specific, use generic clock names.
>> - Fix PLL_SD_SHIFT from 9 to 10
>> - As optclk and wkupclk may not be always required, don't bail out
>> if they aren't available.
> 
> I think here too we face the same problem as for PHY. What if a particular 
> platform needs a clock but is not available. I don't want this to be blocking 
> though.

Since we know for sure what clocks the different TI PHYs need, we could do the 
checks based on compatible id and always fail on clock error.

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drm/radeon: silence GCC warning on 32 bit

[Paul Bolle]

Building radeon_ttm.o on 32 bit x86 triggers a warning:
In file included from include/asm-generic/bug.h:13:0,
 from [...]/arch/x86/include/asm/bug.h:38,
 from include/linux/bug.h:4,
 from include/drm/drm_mm.h:39,
 from include/drm/drm_vma_manager.h:26,
 from include/drm/ttm/ttm_bo_api.h:35,
 from drivers/gpu/drm/radeon/radeon_ttm.c:32:
drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_gtt_read':
include/linux/kernel.h:712:17: warning: comparison of distinct pointer 
types lacks a cast [enabled by default]
  (void) (&_min1 == &_min2);  \
 ^
drivers/gpu/drm/radeon/radeon_ttm.c:938:22: note: in expansion of macro 
'min'
   ssize_t cur_size = min(size, PAGE_SIZE - off);
  ^

Silence this warning by using min_t(). Since cur_size will never be
negative and its upper bound is PAGE_SIZE, we can change its type to
size_t and use min_t(size_t, [...]) here.

Signed-off-by: Paul Bolle 
---
v2: use min_t() as Ilia suggested, and convert cur_size to size_t, as
Thierry suggested.

Still compile tested only (on 32 and 64 bit x86).

 drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 77f5b0c..1ce6ba6 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -935,7 +935,7 @@ static ssize_t radeon_ttm_gtt_read(struct file *f, char 
__user *buf,
while (size) {
loff_t p = *pos / PAGE_SIZE;
unsigned off = *pos & ~PAGE_MASK;
-   ssize_t cur_size = min(size, PAGE_SIZE - off);
+   size_t cur_size = min_t(size_t, size, PAGE_SIZE - off);
struct page *page;
void *ptr;
 
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] regulator: pfuze100: add pfuze200 support

[Robin Gong]

support pfuze200 chip which remove SW1C and SW4 based on pfuze100.

Signed-off-by: Robin Gong 
---
v3:
  1. add device tree binding doc for PFUZE200
  2. fix building error for non-devicetree case.
---
 .../devicetree/bindings/regulator/pfuze100.txt |   96 ++-
 drivers/regulator/pfuze100-regulator.c |  196 ++--
 include/linux/regulator/pfuze100.h |   14 ++
 3 files changed, 251 insertions(+), 55 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt 
b/Documentation/devicetree/bindings/regulator/pfuze100.txt
index fc989b2..34ef5d1 100644
--- a/Documentation/devicetree/bindings/regulator/pfuze100.txt
+++ b/Documentation/devicetree/bindings/regulator/pfuze100.txt
@@ -1,7 +1,7 @@
 PFUZE100 family of regulators
 
 Required properties:
-- compatible: "fsl,pfuze100"
+- compatible: "fsl,pfuze100" or "fsl,pfuze200"
 - reg: I2C slave address
 
 Required child node:
@@ -10,11 +10,14 @@ Required child node:
   Documentation/devicetree/bindings/regulator/regulator.txt.
 
   The valid names for regulators are:
+  --PFUZE100
   sw1ab,sw1c,sw2,sw3a,sw3b,sw4,swbst,vsnvs,vrefddr,vgen1~vgen6
+  --PFUZE200
+  sw1ab,sw2,sw3a,sw3b,swbst,vsnvs,vrefddr,vgen1~vgen6
 
 Each regulator is defined using the standard binding for regulators.
 
-Example:
+Example 1: PFUZE100
 
pmic: pfuze100@08 {
compatible = "fsl,pfuze100";
@@ -113,3 +116,92 @@ Example:
};
};
};
+
+
+Example 2: PFUZE200
+
+   pmic: pfuze200@08 {
+   compatible = "fsl,pfuze200";
+   reg = <0x08>;
+
+   regulators {
+   sw1a_reg: sw1ab {
+   regulator-min-microvolt = <30>;
+   regulator-max-microvolt = <1875000>;
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-ramp-delay = <6250>;
+   };
+
+   sw2_reg: sw2 {
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   sw3a_reg: sw3a {
+   regulator-min-microvolt = <40>;
+   regulator-max-microvolt = <1975000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   sw3b_reg: sw3b {
+   regulator-min-microvolt = <40>;
+   regulator-max-microvolt = <1975000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   swbst_reg: swbst {
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <515>;
+   };
+
+   snvs_reg: vsnvs {
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <300>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   vref_reg: vrefddr {
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   vgen1_reg: vgen1 {
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <155>;
+   };
+
+   vgen2_reg: vgen2 {
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <155>;
+   };
+
+   vgen3_reg: vgen3 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   };
+
+   vgen4_reg: vgen4 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+
+   vgen5_reg: vgen5 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+
+   vgen6_reg: vgen6 {
+   regulator-min-microvolt = <180>;
+   

[PATCH v2] NVMe: silence GCC warning on 32 bit

[Paul Bolle]

Building nvme-core.o on 32 bit x86 triggers a rather impressive set of
GCC warnings:
In file included from drivers/block/nvme-core.c:20:0:
drivers/block/nvme-core.c: In function 'nvme_submit_bio_queue':
include/linux/bio.h:154:55: warning: 'bvprv.bv_offset' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
 #define bvec_to_phys(bv) (page_to_phys((bv)->bv_page) + (unsigned long) 
(bv)->bv_offset)
   ^
drivers/block/nvme-core.c:498:23: note: 'bvprv.bv_offset' was declared here
  struct bio_vec bvec, bvprv;
   ^
In file included from drivers/block/nvme-core.c:20:0:
include/linux/bio.h:154:55: warning: 'bvprv.bv_len' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
 #define bvec_to_phys(bv) (page_to_phys((bv)->bv_page) + (unsigned long) 
(bv)->bv_offset)
   ^
drivers/block/nvme-core.c:498:23: note: 'bvprv.bv_len' was declared here
  struct bio_vec bvec, bvprv;
   ^
In file included from [...]/arch/x86/include/asm/page.h:70:0,
 from [...]/arch/x86/include/asm/processor.h:17,
 from [...]/arch/x86/include/asm/atomic.h:6,
 from include/linux/atomic.h:4,
 from include/linux/mutex.h:18,
 from include/linux/kernfs.h:13,
 from include/linux/sysfs.h:15,
 from include/linux/kobject.h:21,
 from include/linux/pci.h:28,
 from include/linux/nvme.h:23,
 from drivers/block/nvme-core.c:19:
include/asm-generic/memory_model.h:31:53: warning: 'bvprv.bv_page' may be 
used uninitialized in this function [-Wmaybe-uninitialized]
 #define __page_to_pfn(page) ((unsigned long)((page) - mem_map) + \
 ^
drivers/block/nvme-core.c:498:23: note: 'bvprv.bv_page' was declared here
  struct bio_vec bvec, bvprv;
   ^

These are false positives. Apparently GCC can't determine that bvprv
will only be used if first is false and has, therefore, been
initialized. It turned out hard to reorganize the code to help GCC
understand the flow of this code. So take the easy way out and
initialize bvprv to { NULL }.

And, since we're touching this code, make first a bool.

Signed-off-by: Paul Bolle 
---
v2: redone, as required by Keith's review. Note that initializing bvprv
to { NULL } is already done twice in block/blk-merge.c, which inspired
me to take the easy way out here.

Also note that it's actually not clear to me why these warnings only
trigger on 32 bit. I guess there's some int/long conversion lurking
somewhere. I haven't found it. 

bvprv? Would that mean bio_vec private? But it looks like some temporary
variable, so something like tmp may make more sense. Anyhow, still
compile tested only (on 32 and 64 bit x86).

 drivers/block/nvme-core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/block/nvme-core.c b/drivers/block/nvme-core.c
index 51824d1..60f98be 100644
--- a/drivers/block/nvme-core.c
+++ b/drivers/block/nvme-core.c
@@ -495,11 +495,11 @@ static int nvme_split_and_submit(struct bio *bio, struct 
nvme_queue *nvmeq,
 static int nvme_map_bio(struct nvme_queue *nvmeq, struct nvme_iod *iod,
struct bio *bio, enum dma_data_direction dma_dir, int psegs)
 {
-   struct bio_vec bvec, bvprv;
+   struct bio_vec bvec, bvprv = { NULL };
struct bvec_iter iter;
struct scatterlist *sg = NULL;
int length = 0, nsegs = 0, split_len = bio->bi_iter.bi_size;
-   int first = 1;
+   bool first = true;
 
if (nvmeq->dev->stripe_size)
split_len = nvmeq->dev->stripe_size -
@@ -525,7 +525,7 @@ static int nvme_map_bio(struct nvme_queue *nvmeq, struct 
nvme_iod *iod,
return nvme_split_and_submit(bio, nvmeq, split_len);
length += bvec.bv_len;
bvprv = bvec;
-   first = 0;
+   first = false;
}
iod->nents = nsegs;
sg_mark_end(sg);
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Is there any list for newbie bugs?

[Gideon D'souza]

Hey All,

In my quest for work in the linux kernel I was looking at bugs.

While I have a general idea of the kernel (including KDB) most of the
bugs I've seen (under process management and drivers) are very
contrived to me.

I was wondering if there is anything like a good_first_bug or
newbie_bug list anywhere?

If not, anyone out there know any bugs a kernel toddler can try and attack?

Thanks so much,
Gideon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] regulator: pfuze100: add pfuze200 support

[Mark Brown]

On Tue, Mar 04, 2014 at 05:40:36PM +0800, Robin Gong wrote:
> support pfuze200 chip which remove SW1C and SW4 based on pfuze100.

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH 2/5] drivers: bus: omap_l3: Convert to use devm_request_and_ioremap()

[Peter Ujfalusi]

On 03/04/2014 11:23 AM, Alexander Shiyan wrote:
>>> -   l3->l3_base[2] = ioremap(res->start, resource_size(res));
>>> -   if (!l3->l3_base[2]) {
>>> -   dev_err(>dev, "ioremap failed\n");
>>> -   ret = -ENOMEM;
>>> -   goto err2;
>>> +   l3->l3_base[i] = devm_request_and_ioremap(>dev, res);
>>> +   if (!l3->l3_base[i]) {
>>
>> if (IS_ERR(l3->l3_base[i]))
> 
> Ahh, I messed up this with devm_ioremap_resource().
> However, if there is reason to use devm_request_and_ioremap() here?

devm_request_and_ioremap() is just a wrapper for devm_ioremap_resource(). It
returns NULL in case of error (eats up the error code at the same time).
I don't have strong preference on this so I can change it to
devm_ioremap_resource()

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] drivers: bus: omap_l3: Convert to use devm_request_and_ioremap()

[Peter Ujfalusi]

On 03/04/2014 11:12 AM, Alexander Shiyan wrote:
> Вторник,  4 марта 2014, 11:01 +02:00 от Peter Ujfalusi 
> :
>> We can then remove the iounmap() calls from probe and remove.
>> Since the driver requests the resources via index we can do the mem resource
>> request within a for loop.
>>
>> Signed-off-by: Peter Ujfalusi 
>> Reviewed-by: Santosh Shilimkar 
>> ---
> 
>> +/* Get mem resources */
>> +for (i = 0; i < 3; i++) {
>> +struct resource *res = platform_get_resource(pdev,
>> + IORESOURCE_MEM, i);
>> +if (!res) {
>> +dev_err(>dev, "couldn't find resource %d\n", i);
>> +return -ENODEV;
>> +}
> 
> No need to check "res". devm_request_and_ioremap() do all for us.

True.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/19] perf c2c: Shared data analyser

[Peter Zijlstra]

On Mon, Mar 03, 2014 at 10:36:25PM +0100, Andi Kleen wrote:
> > Heh.  I never thought about that.  And sure enough a quick test with
> > mem-stores commented out produced the same results (minus the stores).
> > 
> > One would just have to 'figure' out what cacheline offsets are causing the
> > HITMs.
> 
> Often that can be determined statically from the instruction (register-offset)
> 
> However keep in mind that there is some skid so the instruction may not
> be correct.

Even with the real_ip pebs field? I thought the whole purpose of that
was to tag the actual instruction matching the event.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] support Thinkpad X1 Carbon's adaptive keyboard

[Shuduo Sang]

Hi Tobias,

Thanks for your comments.

Shuduo

On 03/04/2014 05:19 PM, Tobias Klauser wrote:
> On 2014-03-03 at 17:31:08 +0100, Shuduo Sang  
> wrote:
> [...]
>> +/* press Fn key a while second, it will switch to Function Mode. Then
>> + * release Fn key, previous mode be restored.
>> + */
>> +bool adaptive_keyboard_mode_is_saved;
>> +int adaptive_keybarod_prev_mode;
> 
> These should probably be made static, since they're only used inside the
> module.
> 

Yes. Let me fix it in V3.

>> +static int adaptive_keyboard_get_next_mode(int mode)
>> +{
>> +int i;
>> +int max_mode = ARRAY_SIZE(adaptive_keyboard_modes) - 1;
> 
> sizeof and thus ARRAY_SIZE returns a size_t, so i and max_mode could be
> of type size_t as well.
> 

Agree. Will fix in V3.

>> +
>> +for (i = 0; i <= max_mode; i++) {
>> +if (adaptive_keyboard_modes[i] == mode)
>> +break;
>> +}
>> +
>> +if (i >= max_mode)
>> +i = 0;
>> +else
>> +i++;
>> +
>> +return adaptive_keyboard_modes[i];
>> +}
>> +
>> +static bool adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
>> +{
>> +u32 current_mode = 0;
>> +int new_mode = 0;
>> +
>> +switch (scancode) {
>> +case DFR_CHANGE_ROW:
>> +if (adaptive_keyboard_mode_is_saved) {
>> +new_mode = adaptive_keybarod_prev_mode;
>> +adaptive_keyboard_mode_is_saved = false;
>> +} else {
>> +if (!acpi_evalf(
>> +hkey_handle, _mode,
>> +"GTRW", "dd", 0)) {
>> +pr_err("Cannot read adaptive keyboard mode\n");
>> +return false;
>> +} else {
>> +new_mode = adaptive_keyboard_get_next_mode(
>> +current_mode);
>> +}
>> +}
>> +
>> +if (!acpi_evalf(hkey_handle, NULL, "STRW", "vd", new_mode)) {
>> +pr_err("Cannot set adaptive keyboard mode\n");
>> +return false;
>> +}
>> +
>> +return true;
>> +
>> +case DFR_SHOW_QUICKVIEW_ROW:
>> +if (!acpi_evalf(hkey_handle,
>> +_keybarod_prev_mode,
>> +"GTRW", "dd", 0)) {
>> +pr_err("Cannot read adaptive keyboard mode\n");
>> +return false;
>> +} else {
>> +adaptive_keyboard_mode_is_saved = true;
>> +
>> +if (!acpi_evalf(hkey_handle,
>> +NULL, "STRW", "vd", FUNCTION_MODE)) {
>> +pr_err("Cannot set adaptive keyboard mode\n");
>> +return false;
>> +}
>> +}
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>>  static bool hotkey_notify_hotkey(const u32 hkey,
>>   bool *send_acpi_ev,
>>   bool *ignore_acpi_ev)
>> @@ -3456,6 +3556,8 @@ static bool hotkey_notify_hotkey(const u32 hkey,
>>  *ignore_acpi_ev = true;
>>  }
>>  return true;
>> +} else {
>> +return adaptive_keyboard_hotkey_notify_hotkey(scancode);
>>  }
>>  return false;
>>  }
>> -- 
>> 1.9.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] mfd: vexpress: Staticize vexpress_config_bridges

[Sachin Kamat]

vexpress_config_bridges is local to this file.

Signed-off-by: Sachin Kamat 
---
 drivers/mfd/vexpress-config.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/vexpress-config.c b/drivers/mfd/vexpress-config.c
index 84ce6b9daa3d..0876de04ed4d 100644
--- a/drivers/mfd/vexpress-config.c
+++ b/drivers/mfd/vexpress-config.c
@@ -27,7 +27,7 @@
 
 #define VEXPRESS_CONFIG_MAX_BRIDGES 2
 
-struct vexpress_config_bridge {
+static struct vexpress_config_bridge {
struct device_node *node;
struct vexpress_config_bridge_info *info;
struct list_head transactions;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/9] drivers: staging: rtl8187se: various code cleanups

[Dan Carpenter]

Seems ok.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [alsa-devel] [RFC][PATCH 1/3] ASoC: core: Move the default regmap I/O setting to snd_soc_register_codec()

[Lars-Peter Clausen]

On 03/04/2014 09:25 AM, Xiubo Li wrote:

Add the default regmap I/O setting to snd_soc_register_codec() while
the CODEC is initialising, which will be called by CODEC driver device
probe(), and then we can make set_cache_io() go away entirely from each
CODEC ASoC probe.

Signed-off-by: Xiubo Li 
---
  include/sound/soc.h  |  3 +++
  sound/soc/soc-core.c | 11 +++
  2 files changed, 14 insertions(+)

diff --git a/include/sound/soc.h b/include/sound/soc.h
index 4c4d7e1..94bc1c4 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -749,6 +749,9 @@ struct snd_soc_codec_driver {
int (*set_pll)(struct snd_soc_codec *codec, int pll_id, int source,
unsigned int freq_in, unsigned int freq_out);

+   /* codec regmap */
+   struct regmap *regmap;
+


Nope. The driver struct is globally shared between all device instances, the 
regmap struct is device instance specific. The proper way to solve this is 
to have a function like snd_soc_register_codec_with_io() which takes a 
pointer to the regmap struct.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv12] video: backlight: gpio-backlight: Add DT support.

[Jingoo Han]

On Friday, February 28, 2014 12:22 AM, Lee Jones wrote:
> On Thu, 27 Feb 2014, Denis Carikli wrote:
> 
> > Signed-off-by: Denis Carikli 
> > ---
> > ChangeLog v11-resend->v12:
> > - Moved the Cc from the commit message to the "email patch".
> > - The documentation is now more clear.
> > - The unnecessary default_on variable was removed.
> > - gbl->fbdev was already NULL and didn't need to be re-assigned,
> >   so the re-assignement was removed.
> > - The of_device_id struct and .of_match_table are now guarded
> >   against the driver beeing compiled without CONFIG_OF.
> >
> > ChangeLog v11->v11-resend:
> > - Removed the Cc list because it's only one patch.
> >
> > ChangeLog v10->v11:
> > - Shrinked the Cc list.
> > - Fixed the of_match_table warning.
> >
> > ChangeLog v9->v10:
> > - Only the respective maintainers, or people who responded to the patch
> >   were kept in the Cc.
> > - The unnecessary of_match_ptr in of_match_table was removed.
> >
> > ChangeLog v8->v9:
> > - Added Shawn Guo in the Cc list.
> > - The default-brightness-level is now a boolean default-on property,
> >   the gpio is only touched if the gpio-backlight driver instance probes.
> > - The code and documentation was updated accordingly.
> >
> > ChangeLog v7->v8:
> > - The default-state was renamed to default-brightness-level.
> > - default-brightness-level is now mandatory, like for backlight-pwm,
> >   That way we avoid having to handle the case where it's not set,
> >   which means that we would need not to set the gpio, but still
> >   report a brightness value for sysfs, when not all gpio controllers are
> >   able to read the gpio value.
> > - switched the default-brightness-level to boolean values (0 or 1) instead
> >   of using strings ("on", "off", "keep").
> > - The documentation was updated accordingly.
> > - The example in the documentation now uses the dts gpio defines.
> > - The "backlight: gpio_backlight: Use a default state enum." patch was then
> >   dropped, becuase it is not necessary anymore.
> >
> > ChangeLog v6->v7:
> > - removed a compilation warning with the removal of the useless ret 
> > declaration.
> >
> > ChangeLog v5->v6:
> > - The default state handling was reworked:
> >   - it's now called default-state, and looks like the gpio-leds 
> > default-state.
> >   - it now has a "keep" option, like for the gpio-leds.
> >   - that "keep" option is the default when the default-state property is 
> > not set.
> > - The documentation was updated accordingly.
> >
> > ChangeLog v4->v5:
> > - The default-brightness property now defaults to 0 in the driver.
> > - def_value int becomes a bool.
> > - The check for the gpio validity has been reworked.
> > ---
> >  .../bindings/video/backlight/gpio-backlight.txt|   16 ++
> >  drivers/video/backlight/gpio_backlight.c   |   58 
> > +---
> >  2 files changed, 67 insertions(+), 7 deletions(-)
> >  create mode 100644 
> > Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt
> 
> Patch looks good to me now, I just want to see if Jingoo and/or Bryan
> with to add anything. If they don't respond within the next couple of
> days I'll apply the patch.
> 
> Acked-by: Lee Jones 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> 
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/2] ARM hibernation / suspend-to-disk

[Sebastian Capella]

Quoting Sebastian Capella (2014-02-28 15:38:54)
> Quoting Lorenzo Pieralisi (2014-02-28 14:49:33)
> > On Fri, Feb 28, 2014 at 08:15:57PM +, Sebastian Capella wrote:
> > > > 
> > > > This does not guarantee your stack is 8-byte aligned, that's not AAPCS
> > > > compliant and might buy you trouble.
> > > > 
> > > > Either you align the stack or you align the pointer you are passing.
> > > > 
> > > > Please have a look at kernel/process.c
> > > 
> > > I've added this for now, do you see any issues?
> > > 
> > > -static u8 resume_stack[PAGE_SIZE/2] __nosavedata;
> > > +static u64 resume_stack[PAGE_SIZE/2/sizeof(u64)] __nosavedata;
> > > -   resume_stack + sizeof(resume_stack));
> > > +   resume_stack + ARRAY_SIZE(resume_stack));
> > 
> > I do not see why the stack depends on the PAGE_SIZE. I would be surprised
> > if you need more than a few bytes (given that soft_restart switches stack
> > again...), go through it with a debugger, it is easy to check the stack
> > usage and allow for some extra buffer (but half a page is not needed).
> 
> I assuming this is becase the no-save region is one page anyway (we skip
> restoring the no-save region physical page).  So maybe 1/2 is a way to
> leave some room for whatever else may need to be here, but in any case
> the 4k is used for nosave.  I think you're right that it can be much less.

Hi Lorenzo,

Are you ok with this just being half a page?  Or do you want me to try
to reduce the stack size?  I am at Connect without my debugger, so in
that case it would have to wait until next week.

The change for alignment is in as discussed.

Thanks!

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/6] android: convert sync to fence api, v4

[Daniel Vetter]

On Tue, Mar 04, 2014 at 09:20:58AM +0100, Maarten Lankhorst wrote:
> op 04-03-14 09:14, Daniel Vetter schreef:
> >On Tue, Mar 04, 2014 at 08:50:38AM +0100, Maarten Lankhorst wrote:
> >>op 03-03-14 22:11, Daniel Vetter schreef:
> >>>On Mon, Feb 17, 2014 at 04:57:19PM +0100, Maarten Lankhorst wrote:
> Android syncpoints can be mapped to a timeline. This removes the need
> to maintain a separate api for synchronization. I've left the android
> trace events in place, but the core fence events should already be
> sufficient for debugging.
> 
> v2:
> - Call fence_remove_callback in sync_fence_free if not all fences have 
> fired.
> v3:
> - Merge Colin Cross' bugfixes, and the android fence merge optimization.
> v4:
> - Merge with the upstream fixes.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
> >>>Snipped everything but headers - Ian Lister from our android team is
> >>>signed up to have a more in-depth look at proper integration with android
> >>>syncpoints. Adding him to cc.
> >>>
> diff --git a/drivers/staging/android/sync.h 
> b/drivers/staging/android/sync.h
> index 62e2255b1c1e..6036dbdc8e6f 100644
> --- a/drivers/staging/android/sync.h
> +++ b/drivers/staging/android/sync.h
> @@ -21,6 +21,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
> 
>   struct sync_timeline;
>   struct sync_pt;
> @@ -40,8 +41,6 @@ struct sync_fence;
>    * -1 if a will signal before b
>    * @free_pt: called before sync_pt is freed
>    * @release_obj: called before sync_timeline is freed
> - * @print_obj: deprecated
> - * @print_pt: deprecated
>    * @fill_driver_data: write implementation specific driver data to data.
>    *  should return an error if there is not enough room
>    *  as specified by size.  This information is returned
> @@ -67,13 +66,6 @@ struct sync_timeline_ops {
>    /* optional */
>    void (*release_obj)(struct sync_timeline *sync_timeline);
> 
> - /* deprecated */
> - void (*print_obj)(struct seq_file *s,
> -  struct sync_timeline *sync_timeline);
> -
> - /* deprecated */
> - void (*print_pt)(struct seq_file *s, struct sync_pt *sync_pt);
> -
>    /* optional */
>    int (*fill_driver_data)(struct sync_pt *syncpt, void *data, int size);
> 
> @@ -104,42 +96,48 @@ struct sync_timeline {
> 
>    /* protected by child_list_lock */
>    bool destroyed;
> + int context, value;
> 
>    struct list_head child_list_head;
>    spinlock_t child_list_lock;
> 
>    struct list_head active_list_head;
> - spinlock_t active_list_lock;
> 
> +#ifdef CONFIG_DEBUG_FS
>    struct list_head sync_timeline_list;
> +#endif
>   };
> 
>   /**
>    * struct sync_pt - sync point
> - * @parent: sync_timeline to which this sync_pt belongs
> + * @fence: base fence class
>    * @child_list: membership in sync_timeline.child_list_head
>    * @active_list: membership in sync_timeline.active_list_head
> +<<< current
>    * @signaled_list: membership in temporary signaled_list on stack
>    * @fence: sync_fence to which the sync_pt belongs
>    * @pt_list: membership in sync_fence.pt_list_head
>    * @status: 1: signaled, 0:active, <0: error
>    * @timestamp: time which sync_pt status transitioned from active to
>    *  signaled or error.
> +===
> +>>> patched
> >>>Conflict markers ...
> >>Oops.
>    */
>   struct sync_pt {
> - struct sync_timeline *parent;
> - struct list_head child_list;
> + struct fence base;
> >>>Hm, embedding feels wrong, since that still means that I'll need to
> >>>implement two kinds of fences in i915 - one using the seqno fence to make
> >>>dma-buf sync work, and one to implmenent sync_pt to make the android folks
> >>>happy.
> >>>
> >>>If I can dream I think we should have a pointer to an underlying fence
> >>>here, i.e. a struct sync_pt would just be a userspace interface wrapper to
> >>>do explicit syncing using native fences, instead of implicit syncing like
> >>>with dma-bufs. But this is all drive-by comments from a very cursory
> >>>high-level look. I might be full of myself again ;-)
> >>>-Daniel
> >>>
> >>No, the idea is that because android syncpoint is simply another type of
> >>dma-fence, that if you deal with normal fences then android can
> >>automatically be handled too. The userspace fence api android exposes
> >>could be very easily made to work for dma-fence, just pass a dma-fence
> >>to sync_fence_create.
> >>So exposing dma-fence would probably work for android too.
> >Hm, then why do we still have struct sync_pt around? Since it's just the
> >internal bit, with the userspace facing object being struct sync_fence,
> >I'd opt to shuffle any useful features into the core struct fence.
> >-Daniel
> To keep compatibility with the 

Re: [PATCH v4 net-next 1/3] Extended BPF interpreter and converter

[Daniel Borkmann]

On 03/04/2014 06:18 AM, Alexei Starovoitov wrote:

Extended BPF extends old BPF in the following ways:
- from 2 to 10 registers
   Original BPF has two registers (A and X) and hidden frame pointer.
   Extended BPF has ten registers and read-only frame pointer.
- from 32-bit registers to 64-bit registers
   semantics of old 32-bit ALU operations are preserved via 32-bit
   subregisters
- if (cond) jump_true; else jump_false;
   old BPF insns are replaced with:
   if (cond) jump_true; /* else fallthrough */
- adds signed > and >= insns
- 16 4-byte stack slots for register spill-fill replaced with
   up to 512 bytes of multi-use stack space
- introduces bpf_call insn and register passing convention for zero
   overhead calls from/to other kernel functions (not part of this patch)
- adds arithmetic right shift insn
- adds swab32/swab64 insns
- adds atomic_add insn
- old tax/txa insns are replaced with 'mov dst,src' insn

Extended BPF is designed to be JITed with one to one mapping, which
allows GCC/LLVM backends to generate optimized BPF code that performs
almost as fast as natively compiled code

sk_convert_filter() remaps old style insns into extended:
'sock_filter' instructions are remapped on the fly to
'sock_filter_ext' extended instructions when
sysctl net.core.bpf_ext_enable=1

Old filter comes through sk_attach_filter() or sk_unattached_filter_create()
  if (bpf_ext_enable) {
 convert to new
 sk_chk_filter() - check old bpf
 use sk_run_filter_ext() - new interpreter
  } else {
 sk_chk_filter() - check old bpf
 if (bpf_jit_enable)
 use old jit
 else
 use sk_run_filter() - old interpreter
  }

sk_run_filter_ext() interpreter is noticeably faster
than sk_run_filter() for two reasons:

1.fall-through jumps
   Old BPF jump instructions are forced to go either 'true' or 'false'
   branch which causes branch-miss penalty.
   Extended BPF jump instructions have one branch and fall-through,
   which fit CPU branch predictor logic better.
   'perf stat' shows drastic difference for branch-misses.

2.jump-threaded implementation of interpreter vs switch statement
   Instead of single tablejump at the top of 'switch' statement, GCC will
   generate multiple tablejump instructions, which helps CPU branch predictor

Performance of two BPF filters generated by libpcap was measured
on x86_64, i386 and arm32.

fprog #1 is taken from Documentation/networking/filter.txt:
tcpdump -i eth0 port 22 -dd

fprog #2 is taken from 'man tcpdump':
tcpdump -i eth0 'tcp port 22 and (((ip[2:2] - ((ip[0]&0xf)<<2)) -
((tcp[12]&0xf0)>>2)) != 0)' -dd

Other libpcap programs have similar performance differences.

Raw performance data from BPF micro-benchmark:
SK_RUN_FILTER on same SKB (cache-hit) or 10k SKBs (cache-miss)
time in nsec per call, smaller is better
--x86_64--
  fprog #1  fprog #1   fprog #2  fprog #2
  cache-hit cache-miss cache-hit cache-miss
old BPF 90   101   192   202
ext BPF 3171   47 97
old BPF jit 1234   17 44
ext BPF jit TBD

--i386--
  fprog #1  fprog #1   fprog #2  fprog #2
  cache-hit cache-miss cache-hit cache-miss
old BPF107136  227   252
ext BPF 40119   69   172

--arm32--
  fprog #1  fprog #1   fprog #2  fprog #2
  cache-hit cache-miss cache-hit cache-miss
old BPF202300  475   540
ext BPF139270  296   470
old BPF jit 26182   37   202
new BPF jit TBD

Tested with trinify BPF fuzzer

Future work:

0. seccomp

1. add extended BPF JIT for x86_64

2. add inband old/new demux and extended BPF verifier, so that new programs
can be loaded through old sk_attach_filter() and 
sk_unattached_filter_create()
interfaces

3. tracing filters systemtap-like with extended BPF

4. OVS with extended BPF

5. nftables with extended BPF

Signed-off-by: Alexei Starovoitov 


Looks great, imho, some comments/questions inline:

Nit: subject line of your patches should be, e.g.

 "filter: add Extended BPF interpreter and converter"
 "doc: filter: add Extended BPF documentation"
 ...

so first ": ".


---
  include/linux/filter.h  |8 +-
  include/linux/netdevice.h   |1 +
  include/uapi/linux/filter.h |   34 +-
  net/core/filter.c   |  802 ++-
  net/core/sysctl_net_core.c  |7 +
  5 files changed, 830 insertions(+), 22 deletions(-)

diff --git a/include/linux/filter.h b/include/linux/filter.h
index e568c8ef896b..0e84ff6e991b 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -52,7 +52,13 @@ extern int sk_detach_filter(struct sock *sk);
  extern int sk_chk_filter(struct sock_filter *filter, unsigned int flen);
  extern int sk_get_filter(struct sock *sk, struct sock_filter __user *filter, 
unsigned len);
  extern void sk_decode_filter(struct sock_filter *filt, struct sock_filter 
*to);
+/* function remaps 

Re: [PATCH v5 6/7] of: Implement simplified graph binding for single port devices

[Philipp Zabel]

Am Dienstag, den 04.03.2014, 11:06 +0200 schrieb Tomi Valkeinen:
> On 27/02/14 19:35, Philipp Zabel wrote:
> > For simple devices with only one port, it can be made implicit.
> > The endpoint node can be a direct child of the device node.
> 
> 
> 
> > @@ -2105,9 +2112,11 @@ struct device_node *of_graph_get_remote_port_parent(
> > /* Get remote endpoint node. */
> > np = of_parse_phandle(node, "remote-endpoint", 0);
> >  
> > -   /* Walk 3 levels up only if there is 'ports' node. */
> > +   /* Walk 3 levels up only if there is 'ports' node */
> > for (depth = 3; depth && np; depth--) {
> > np = of_get_next_parent(np);
> > +   if (depth == 3 && of_node_cmp(np->name, "port"))
> > +   break;
> > if (depth == 2 && of_node_cmp(np->name, "ports"))
> > break;
> > }
> 
> This function becomes a bit funny. Would it be clearer just to do
> something like:
> 
>   np = of_parse_phandle(node, "remote-endpoint", 0);
> 
>   np = of_get_next_parent(np);
>   if (of_node_cmp(np->name, "port") != 0)
>   return np;
> 
>   np = of_get_next_parent(np);
>   if (of_node_cmp(np->name, "ports") != 0)
>   return np;
> 
>   np = of_get_next_parent(np);
>   return np;

I'm not sure if this was initially crafted to reduce the number of
function calls, but rolled out it certainly is easier to read. I'll
change this as you suggest.

thanks
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V3 1/5] genirq: define flag IRQ_SRC_DST_INVERTED, and accessors

[Thomas Gleixner]

On Mon, 3 Mar 2014, Stephen Warren wrote:

> From: Stephen Warren 
> 
> Some devices have configurable IRQ output polarities. Software might
> use IRQ_TYPE_* to determine how to configure such a device's IRQ
> output polarity in order to match how the IRQ controller input is
> configured. If the board or SoC inverts the signal between the
> device's IRQ output and controller's IRQ output, software must be
> aware of this fact, in order to program the IRQ output to the correct
> (i.e. opposite) polarity. This flag provides that information.

So what you're saying is:

Device IRQ output --> [Optional Inverter Logic] --> IRQ controller input.

And you're storing the information about the presence of the inverter
logic in the irq itself, but the core does not make any use of it and
you let the device driver deal with the outcome.

This sucks as all affected drivers have to implement the same sanity
logic for this.

Why don't you implement a core function which tells the driver which
polarity to select? That requires a few more changes, but I think it's
worth it for other reasons.

Right now the set_type logic requires the irq chip drivers to
implement sanity checking and default selections for TYPE_NONE. We can
be more clever about that and add this information to the irq chip
flags.

enum {
 IRQ_CHIP_TYPES_MASK= 0x0f,
 IRQ_CHIP_DEFAULT_MASK  = 0xf0,
 IRQ_CHIP_EXISTING_FLAGS
}

Now the irq_chip setup tells the core which types are available and
which one is the default fallback for TYPE_NONE.

So the core can do the sanity checks and we can kill quite some
repeated stuff from the irq chip implementations. For the inverted
logic case you can handle the inversion in the core as well, i.e. if a
driver requests IRQ_TYPE_LEVEL_HIGH you select IRQ_TYPE_LEVEL_LOW for
the chip, if possible.

For the case where the irq chip can only handle a single polarity you
can provide a core function to figure out to which polarity the driver
should set the device IRQ output line.

int irq_get_device_irq_polarity(int irq, int device_types)
{
/*
 * Handle the inversion logic and select a proper
 * device irq polarity from irq_chip(@irq)->flags and
 * @device_types.
 *
 * Return a proper error code if no match.
 */
}

Let's look at an example:

  irq_chip.flags = IRQ_TYPE_LEVEL_HIGH;
  device_types = IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW;

Now for the non inverted case, this returns IRQ_TYPE_LEVEL_HIGH, for
the inverted case it returns IRQ_TYPE_LEVEL_LOW.

In both cases the irq_set_type() logic handles this correctly:

Non-Inverted case:
 irq_set_type(irq, IRQ_TYPE_LEVEL_HIGH);
 -> Success

Inverted case:
 irq_set_type(irq, IRQ_TYPE_LEVEL_LOW);
 invert -> IRQ_TYPE_LEVEL_HIGH
 -> Success

To make this work for interrupt chips which have no set_type callback
we can do the following in irq_set_type():

   if (irq_is_inverted(irq))
  type = invert(type);

   ret = irq_check_type(chip, );
   if (ret < 0 || !chip->irq_settype)
  return ret;

   return chip->irq_settype();

And irq_check_type() does:

   if (!(chip->flags & IRQ_CHIP_TYPES_MASK))
  return chip->irq_settype ? 0 : -ENOTSUP;

   if (*type == IRQ_TYPE_NONE)
  *type == (chip->flags & IRQ_CHIP_DEFAULT_MASK) >> 4;

   return type_supported(chip->flags, *type);

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] PM / devfreq: Rewrite devfreq_update_status() to fix multiple bugs

[MyungJoo Ham]

> The current devfreq_update_status() has the following bugs:
> - If previous frequency doesn't have a valid level, it does an out of bounds
>   access into the trans_table and causes memory corruption.
> - When the new frequency doesn't have a valid level, the time spent in the
>   new frequency is counted towards the next valid frequency switch instead of
>   being ignored.
> - The time spent on the previous frequency is added to the new frequency's
>   stats instead of the previous frequency's stats.
> 
> This patch fixes all of this.
> 
> Signed-off-by: Saravana Kannan 

Merged.

It appears to be Greg's LTS material as well.


Cheers,
MyungJoo

N떑꿩�r툤y鉉싕b쾊Ф푤v�^�)頻{.n�+돴쪐{콗喩zX㎍썳變}찠꼿쟺�:+v돣�쳭喩zZ+€�+zf＂톒쉱�~넮녬i鎬z�췿ⅱ�?솳鈺�&�)刪f뷌^j푹y쬶끷@A첺뛴
0띠h��뭝

Re: [PATCH v5 5/7] [media] of: move common endpoint parsing to drivers/of

[Philipp Zabel]

Am Freitag, den 28.02.2014, 22:09 +0100 schrieb Sylwester Nawrocki:
[...]
> > --- a/drivers/of/base.c
> > +++ b/drivers/of/base.c
> > @@ -1985,6 +1985,37 @@ struct device_node *of_find_next_cache_node(const 
> > struct device_node *np)
> >   }
> >
> >   /**
> > + * of_graph_parse_endpoint() - parse common endpoint node properties
> > + * @node: pointer to endpoint device_node
> > + * @endpoint: pointer to the OF endpoint data structure
> > + *
> > + * All properties are optional. If none are found, we don't set any flags.
> > + * This means the port has a static configuration and no properties have
> > + * to be specified explicitly.
> 
> I don't think these two sentences are needed, it's all described in the
> DT binding documentation. And struct of_endpoint doesn't contain any
> "flags" field.

Thanks, I'll remove them.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] staging: cxt1e1: Fix line length over 80 characters in linux.c

[DaeSeok Youn]

Thanks for review.
Ok. I Will fix later.

Daeseok Youn
2014-03-04 17:45 GMT+09:00, Dan Carpenter :
> On Tue, Mar 04, 2014 at 11:08:46AM +0900, Daeseok Youn wrote:
>>
>> clean up checkpatch.pl warnings:
>>  WARNING: Line length over 80 characters
>>
>> Signed-off-by: Daeseok Youn 
>> ---
>>  drivers/staging/cxt1e1/linux.c |   48
>> +--
>>  1 files changed, 31 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/staging/cxt1e1/linux.c
>> b/drivers/staging/cxt1e1/linux.c
>> index 17d73f4..579e68e 100644
>> --- a/drivers/staging/cxt1e1/linux.c
>> +++ b/drivers/staging/cxt1e1/linux.c
>> @@ -31,7 +31,7 @@
>>  #include "pmcc4_private.h"
>>  #include "sbeproc.h"
>>
>> -/*
>> +/***
>
> This should just be:
>
> /*
>  *
>  *
>
> Not ** etc.
>
> Fix in a later patch if you want.
>
> regards,
> dan carpenter
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Is there any list for newbie bugs?

[Henrik Austad]

On Tue, Mar 04, 2014 at 03:10:54PM +0530, Gideon D'souza wrote:
> Hey All,
> 
> In my quest for work in the linux kernel I was looking at bugs.
> 
> While I have a general idea of the kernel (including KDB) most of the
> bugs I've seen (under process management and drivers) are very
> contrived to me.
> 
> I was wondering if there is anything like a good_first_bug or
> newbie_bug list anywhere?
> 
> If not, anyone out there know any bugs a kernel toddler can try and attack?

As with anything, the simple bugs tend to be removed quite quickly, I don't 
think many kernelhackers leave the easy bugs "just to be nice to newbies" -
whenever a bug is discovered they are fixed.

However, I discovered http://eudyptula-challenge.org/ a little while ago.
Be warned, I haven't tested it, not sure what the challenge is like, but 
might as well be a good place to start.

Good luck!

-- 
Henrik Austad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 3/7] of: Warn if of_graph_get_next_endpoint is called with the root node

[Philipp Zabel]

Am Freitag, den 28.02.2014, 22:09 +0100 schrieb Sylwester Nawrocki:
> On 02/27/2014 06:35 PM, Philipp Zabel wrote:
> > If of_graph_get_next_endpoint is given a parentless node instead of an
> > endpoint node, it is clearly a bug.
> >
> > Signed-off-by: Philipp Zabel
> > ---
> >   drivers/of/base.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/of/base.c b/drivers/of/base.c
> > index b2f223f..6e650cf 100644
> > --- a/drivers/of/base.c
> > +++ b/drivers/of/base.c
> > @@ -2028,8 +2028,8 @@ struct device_node *of_graph_get_next_endpoint(const 
> > struct device_node *parent,
> > of_node_put(node);
> > } else {
> > port = of_get_parent(prev);
> > -   if (!port)
> > -   /* Hm, has someone given us the root node ?... */
> > +   if (WARN_ONCE(!port, "%s(): endpoint has no parent node\n",
> > + __func__))
> 
> Perhaps we can add more information to this error log, e.g.
>
>   if (WARN_ONCE(!port, "%s(): endpoint %s has no parent node\n",
> __func__, prev->full_name))
> ?

Yes, I'll include this change next time.

thanks
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] zram: move comp allocation out of init_lock

[Sergey Senozhatsky]

While fixing lockdep spew of ->init_lock reported by Sasha Levin [1], Minchan
Kim noted [2] that it's better to move compression backend allocation (using
GPF_KERNEL) out of the ->init_lock lock, same way as with zram_meta_alloc(),
in order to prevent the same lockdep spew.

[1] https://lkml.org/lkml/2014/2/27/337
[2] https://lkml.org/lkml/2014/3/3/32

Cc: Sasha Levin 
Reported-by: Minchan Kim 
Signed-off-by: Sergey Senozhatsky 
---
 drivers/block/zram/zram_drv.c | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 15d46f2..e4d536b 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -580,9 +580,10 @@ static ssize_t disksize_store(struct device *dev,
struct device_attribute *attr, const char *buf, size_t len)
 {
u64 disksize;
+   struct zcomp *comp;
struct zram_meta *meta;
struct zram *zram = dev_to_zram(dev);
-   int err;
+   int err = -EINVAL;
 
disksize = memparse(buf, NULL);
if (!disksize)
@@ -593,30 +594,32 @@ static ssize_t disksize_store(struct device *dev,
if (!meta)
return -ENOMEM;
 
+   comp = zcomp_create(zram->compressor, zram->max_comp_streams);
+   if (!comp) {
+   pr_info("Cannot initialise %s compressing backend\n",
+   zram->compressor);
+   goto out_cleanup;
+   }
+
down_write(>init_lock);
if (init_done(zram)) {
+   up_write(>init_lock);
pr_info("Cannot change disksize for initialized device\n");
err = -EBUSY;
-   goto out_free_meta;
-   }
-
-   zram->comp = zcomp_create(zram->compressor, zram->max_comp_streams);
-   if (!zram->comp) {
-   pr_info("Cannot initialise %s compressing backend\n",
-   zram->compressor);
-   err = -EINVAL;
-   goto out_free_meta;
+   goto out_cleanup;
}
 
zram->meta = meta;
+   zram->comp = comp;
zram->disksize = disksize;
set_capacity(zram->disk, zram->disksize >> SECTOR_SHIFT);
up_write(>init_lock);
 
return len;
 
-out_free_meta:
-   up_write(>init_lock);
+out_cleanup:
+   if (comp)
+   zcomp_destroy(comp);
zram_meta_free(meta);
return err;
 }
-- 
1.9.0.382.g7f3562c

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:irq/core] Revert irqchip: irq-dove: Add PMU interrupt controller

[tip-bot for Jason Cooper]

Commit-ID:  eb9cf4e8ec646a553f3b561d7a9e81acf044d876
Gitweb: http://git.kernel.org/tip/eb9cf4e8ec646a553f3b561d7a9e81acf044d876
Author: Jason Cooper 
AuthorDate: Tue, 4 Mar 2014 05:32:40 +
Committer:  Thomas Gleixner 
CommitDate: Tue, 4 Mar 2014 11:10:17 +0100

Revert irqchip: irq-dove: Add PMU interrupt controller

This reverts commit 40b367d95fb3d60fc1edb9ba8f6ef52272e48936.

Russell King has raised the idea of creating a proper PMU driver for
this SoC that would incorporate the functionality currently in this
driver. It would also cover the use case for the graphics subsystem on
this SoC.

To prevent having to maintain the devicetree ABI for this limited
interrupt-handler driver, we revert the driver before it hits a mainline
tagged release (eg v3.15).

Signed-off-by: Jason Cooper 
Cc: linux-arm-ker...@lists.infradead.org
Cc: Andrew Lunn 
Cc: Sebastian Hesselbarth 
Cc: Gregory CLEMENT 
Cc: Russell King - ARM Linux 
Link: 
http://lkml.kernel.org/r/1393911160-7688-1-git-send-email-ja...@lakedaemon.net
Signed-off-by: Thomas Gleixner 
---
 .../interrupt-controller/marvell,dove-pmu-intc.txt |  17 ---
 drivers/irqchip/Makefile   |   1 -
 drivers/irqchip/irq-dove.c | 126 -
 3 files changed, 144 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/marvell,dove-pmu-intc.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/marvell,dove-pmu-intc.txt
deleted file mode 100644
index 1feb582..000
--- 
a/Documentation/devicetree/bindings/interrupt-controller/marvell,dove-pmu-intc.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Marvell Dove Power Management Unit interrupt controller
-
-Required properties:
-- compatible: shall be "marvell,dove-pmu-intc"
-- reg: base address of PMU interrupt registers starting with CAUSE register
-- interrupts: PMU interrupt of the main interrupt controller
-- interrupt-controller: identifies the node as an interrupt controller
-- #interrupt-cells: number of cells to encode an interrupt source, shall be 1
-
-Example:
-   pmu_intc: pmu-interrupt-ctrl@d0050 {
-   compatible = "marvell,dove-pmu-intc";
-   interrupt-controller;
-   #interrupt-cells = <1>;
-   reg = <0xd0050 0x8>;
-   interrupts = <33>;
-   };
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 98589e7..5194afb 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -1,7 +1,6 @@
 obj-$(CONFIG_IRQCHIP)  += irqchip.o
 
 obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o
-obj-$(CONFIG_ARCH_DOVE)+= irq-dove.o
 obj-$(CONFIG_ARCH_EXYNOS)  += exynos-combiner.o
 obj-$(CONFIG_ARCH_MMP) += irq-mmp.o
 obj-$(CONFIG_ARCH_MVEBU)   += irq-armada-370-xp.o
diff --git a/drivers/irqchip/irq-dove.c b/drivers/irqchip/irq-dove.c
deleted file mode 100644
index 788acd8..000
--- a/drivers/irqchip/irq-dove.c
+++ /dev/null
@@ -1,126 +0,0 @@
-/*
- * Marvell Dove SoCs PMU IRQ chip driver.
- *
- * Andrew Lunn 
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "irqchip.h"
-
-#define DOVE_PMU_IRQ_CAUSE 0x00
-#define DOVE_PMU_IRQ_MASK  0x04
-
-static void dove_pmu_irq_handler(unsigned int irq, struct irq_desc *desc)
-{
-   struct irq_domain *d = irq_get_handler_data(irq);
-   struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, 0);
-   u32 stat = readl_relaxed(gc->reg_base + DOVE_PMU_IRQ_CAUSE) &
-  gc->mask_cache;
-
-   while (stat) {
-   u32 hwirq = ffs(stat) - 1;
-
-   generic_handle_irq(irq_find_mapping(d, gc->irq_base + hwirq));
-   stat &= ~(1 << hwirq);
-   }
-}
-
-static void pmu_irq_ack(struct irq_data *d)
-{
-   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
-   struct irq_chip_type *ct = irq_data_get_chip_type(d);
-   u32 mask = ~d->mask;
-
-   /*
-* The PMU mask register is not RW0C: it is RW.  This means that
-* the bits take whatever value is written to them; if you write
-* a '1', you will set the interrupt.
-*
-* Unfortunately this means there is NO race free way to clear
-* these interrupts.
-*
-* So, let's structure the code so that the window is as small as
-* possible.
-*/
-   irq_gc_lock(gc);
-   mask &= irq_reg_readl(gc->reg_base +  ct->regs.ack);
-   irq_reg_writel(mask, gc->reg_base +  ct->regs.ack);
-   irq_gc_unlock(gc);
-}
-
-static int __init dove_pmu_irq_init(struct device_node *np,
-   struct device_node *parent)
-{
-   unsigned int clr = 

Re: [PATCH v5 2/7] Documentation: of: Document graph bindings

[Philipp Zabel]

Hi Sylwester,

Am Freitag, den 28.02.2014, 22:08 +0100 schrieb Sylwester Nawrocki:
> Hi Philipp,
> 
> Just couple minor comments...

Thanks, I'll fix all of those.

> On 02/27/2014 06:35 PM, Philipp Zabel wrote:
> > The device tree graph bindings as used by V4L2 and documented in
> > Documentation/device-tree/bindings/media/video-interfaces.txt contain
> > generic parts that are not media specific but could be useful for any
> > subsystem with data flow between multiple devices. This document
> > describe the generic bindings.
> 
> s/describe/describes/

[...]

> > +These common bindings do not contain any information about the direction of
> 
> s/of/or/ ?

[...]

> > +device_1 {
> > +port {
> > +device_1_output: endpoint {
> > +remote-endpoint =<_2_input>;
> > +};
> > +};
> > +};
> > +
> > +device_1 {
> 
> s/device_1/device_2/
> But it might be better to use dashes instead of underscores
> for the node names.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/7] staging: cxt1e1: fix checkpatch error 'assignment in if condition'

[DaeSeok Youn]

Yes, it need to add brace in inner loop.
I will send again.

Thanks for review.
Daeseok Youn

2014-03-04 18:04 GMT+09:00, Dan Carpenter :
> On Tue, Mar 04, 2014 at 11:09:39AM +0900, Daeseok Youn wrote:
>> @@ -1174,7 +1179,8 @@ cleanup_hdlc(void)
>>  ci = (ci_t *)(netdev_priv(hi->ndev));
>>  for (j = 0; j < ci->max_port; j++)
>>  for (k = 0; k < MUSYCC_NCHANS; k++)
>> -if ((ndev = ci->port[j].chan[k]->user))
>> +ndev = ci->port[j].chan[k]->user;
>> +if (ndev)
>>  {
>>  do_deluser(ndev, 0);
>>  }
>
>
> This patch introduces a bug here because the inner for loop now has two
> statement but no curly braces.
>
> regards,
> dan carpenter
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] regulator: pfuze100: Add terminate entry for [i2c|of]_device_id tables

[Axel Lin]

Also remove PFUZE_NUM to avoid below build warnings:

  CC [M]  drivers/regulator/pfuze100-regulator.o
drivers/regulator/pfuze100-regulator.c:86:2: warning: excess elements in array 
initializer [enabled by default]
drivers/regulator/pfuze100-regulator.c:86:2: warning: (near initialization for 
'pfuze_device_id') [enabled by default]
drivers/regulator/pfuze100-regulator.c:93:2: warning: excess elements in array 
initializer [enabled by default]
drivers/regulator/pfuze100-regulator.c:93:2: warning: (near initialization for 
'pfuze_dt_ids') [enabled by default]

Signed-off-by: Axel Lin 
---
 drivers/regulator/pfuze100-regulator.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/regulator/pfuze100-regulator.c 
b/drivers/regulator/pfuze100-regulator.c
index 44075f8..f87ec70 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -56,7 +56,7 @@
 #define PFUZE100_VGEN5VOL  0x70
 #define PFUZE100_VGEN6VOL  0x71
 
-enum chips {PFUZE100, PFUZE200, PFUZE_NUM};
+enum chips { PFUZE100, PFUZE200 };
 
 struct pfuze_regulator {
struct regulator_desc desc;
@@ -80,15 +80,17 @@ static const int pfuze100_vsnvs[] = {
100, 110, 120, 130, 150, 180, 300,
 };
 
-static const struct i2c_device_id pfuze_device_id[PFUZE_NUM] = {
+static const struct i2c_device_id pfuze_device_id[] = {
{.name = "pfuze100", .driver_data = PFUZE100},
{.name = "pfuze200", .driver_data = PFUZE200},
+   { }
 };
 MODULE_DEVICE_TABLE(i2c, pfuze_device_id);
 
-static const struct of_device_id pfuze_dt_ids[PFUZE_NUM] = {
+static const struct of_device_id pfuze_dt_ids[] = {
{ .compatible = "fsl,pfuze100", .data = (void *)PFUZE100},
{ .compatible = "fsl,pfuze200", .data = (void *)PFUZE200},
+   { }
 };
 MODULE_DEVICE_TABLE(of, pfuze_dt_ids);
 
-- 
1.8.1.2



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MAINTAINERS: add maintainers for arm64 acpi

[Catalin Marinas]

On Tue, Mar 04, 2014 at 02:15:45AM +, Graeme Gregory wrote:
> +ACPI ARM64

That's a pretty broad statement for a single file. Is it core support,
architected peripherals, SoC?

> +M:   Hanjun Guo 
> +M:   Graeme Gregory 
> +S:   Supported
> +L:   linux-a...@vger.kernel.org
> +F:   drivers/acpi/plat/arm-core.c

This patch should be part of the series introducing the arm-core.c file
and it will be ACKed (or NAKed) following review. We can't really commit
maintainers to a file which does not exist in mainline and while there is
still feedback to be addressed. It's like a blank cheque.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86/xen: Disable APIC PM for Xen PV guests

[David Vrabel]

On 04/03/14 02:40, Boris Ostrovsky wrote:
> Xen PV guests support only few APIC registers and writes to
> unsupported registers result in WARN_ONs. Most APIC accesses in these
> guests  have been eliminated; however, lapic_suspend/resume are still
> called (on 32-bit kernels).
> 
> We can disable APIC power management in xen_smp_prepare_boot_cpu()
> (which is called after APIC has been initialized).

Having looked at another APIC related problem recently, I wonder if Xen
would be better served by having its own APIC driver instead of trying
to piggy-back of some hardware one which doesn't do what we want.

David

> 
> Signed-off-by: Boris Ostrovsky 
> ---
>  arch/x86/include/asm/apic.h |2 ++
>  arch/x86/kernel/apic/apic.c |6 ++
>  arch/x86/xen/smp.c  |4 
>  3 files changed, 12 insertions(+)
> 
> 
> An alternative could be to add another op to stuct apic. The advantage would 
> be
> the fact that we never have a window of time when APIC PM is enabled. The 
> downside
> is having yet another op (of which there are already plenty).
> 
> We could also avoid loading lapic_syscore_ops but I couldn't think of a good 
> way
> to figure out when not to do it.
> 
> 
> 
> diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
> index 1d2091a..1f100f2 100644
> --- a/arch/x86/include/asm/apic.h
> +++ b/arch/x86/include/asm/apic.h
> @@ -687,6 +687,8 @@ extern int default_cpu_present_to_apicid(int mps_cpu);
>  extern int default_check_phys_apicid_present(int phys_apicid);
>  #endif
>  
> +extern void apic_pm_deactivate(void);
> +
>  #endif /* CONFIG_X86_LOCAL_APIC */
>  extern void irq_enter(void);
>  extern void irq_exit(void);
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index 7f26c9a..60607b3 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -2424,6 +2424,11 @@ static void apic_pm_activate(void)
>   apic_pm_state.active = 1;
>  }
>  
> +void apic_pm_deactivate(void)
> +{
> + apic_pm_state.active = 0;
> +}
> +
>  static int __init init_lapic_sysfs(void)
>  {
>   /* XXX: remove suspend/resume procs if !apic_pm_state.active? */
> @@ -2439,6 +2444,7 @@ core_initcall(init_lapic_sysfs);
>  #else/* CONFIG_PM */
>  
>  static void apic_pm_activate(void) { }
> +void apic_pm_deactivate(void) { }
>  
>  #endif   /* CONFIG_PM */
>  
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index a18eadd..33115d8 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -298,6 +298,10 @@ static void __init xen_smp_prepare_boot_cpu(void)
>  
>   xen_filter_cpu_maps();
>   xen_setup_vcpu_info_placement();
> +
> +#ifdef CONFIG_X86_LOCAL_APIC
> + apic_pm_deactivate();
> +#endif
>   }
>   /*
>* The alternative logic (which patches the unlock/lock) runs before

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Despite this patch set is working and applicable on top of 3.14-rc5, 
please regard it solely as a pure RFC.

This patch provides support for LAB governor build on top of ondemand.
Previous version of LAB can be found here:
http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq

LAB short reminder:

LAB uses information about how many cores are in "idle" state (the core 
idleness is represented as the value between 0 and 100) and the overall 
load of the system (from 0 to 100) to decide about frequency to be set.
It is extremely useful with SoCs like Exynos4412, which can set only one
frequency for all cores.

Important design decisions:

- Reuse well established ondemand governor's internal code. To do this
  I had to expose some previously static internal ondemand code. 
  This allowed smaller LAB code when compared to previous version.

- LAB works on top of ondemand, which means that one via device tree
  attributes can specify if and when e.g. BOOST shall be enabled or if 
  any particular frequency shall be imposed. For situation NOT important 
  from the power consumption reduction viewpoint the ondemand is used to 
  set proper frequency.

- It is only possible to either compile in or not the LAB into the kernel. 
  There is no "M" option for Kconfig. It is done on purpose, since ondemand 
  itself can be also compiled as a module and then it would be possible to
  remove ondemand when LAB is working on top of it.

- The LAB operation is specified (and thereof extendable) via device tree
  lab-ctrl-freq attribute defined at /cpus/cpu0.


Problems:
- How the governor will work for big.LITTLE systems (especially Global Task
  Scheduling).
- Will there be agreement to expose internal ondemand code to be reused for
  more specialized governors.

Test HW:
Exynos4412 - Trats2 board.
Above patches were posted on top of Linux 3.14-rc5
(SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)

Lukasz Majewski (5):
  cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods
  cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to support
LAB
  cpufreq:LAB:lab Add LAB governor code
  cpufreq:LAB:Kconfig Add LAB definitions to Kconfig
  cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor

 arch/arm/boot/dts/exynos4412-trats2.dts |   29 ++
 drivers/cpufreq/Kconfig |   28 ++
 drivers/cpufreq/Makefile|1 +
 drivers/cpufreq/cpufreq_governor.c  |7 +
 drivers/cpufreq/cpufreq_governor.h  |   12 +
 drivers/cpufreq/cpufreq_lab.c   |  457 +++
 drivers/cpufreq/cpufreq_ondemand.c  |   24 +-
 7 files changed, 550 insertions(+), 8 deletions(-)
 create mode 100644 drivers/cpufreq/cpufreq_lab.c

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC v3 1/5] cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods

[Lukasz Majewski]

Ondemand code needed to be slightly adjusted to allow its reusage.
Mostly one needed to remove static qualifiers and provide some hacks to
allow its working with LAB.

Signed-off-by: Lukasz Majewski 
Signed-off-by: MyungJoo Ham 
---
 drivers/cpufreq/cpufreq_governor.h |   10 ++
 drivers/cpufreq/cpufreq_ondemand.c |   24 
 2 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_governor.h 
b/drivers/cpufreq/cpufreq_governor.h
index bfb9ae1..34b1cf2 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -270,4 +270,14 @@ void od_register_powersave_bias_handler(unsigned int (*f)
(struct cpufreq_policy *, unsigned int, unsigned int),
unsigned int powersave_bias);
 void od_unregister_powersave_bias_handler(void);
+
+/* COMMON CODE FOR DEMAND BASED SWITCHING */
+void od_dbs_timer(struct work_struct *work);
+int od_init(struct dbs_data *dbs_data);
+void od_exit(struct dbs_data *dbs_data);
+void od_check_cpu(int cpu, unsigned int load_freq);
+void update_sampling_rate(struct dbs_data *dbs_data,
+ unsigned int new_rate);
+
+extern struct od_ops od_ops;
 #endif /* _CPUFREQ_GOVERNOR_H */
diff --git a/drivers/cpufreq/cpufreq_ondemand.c 
b/drivers/cpufreq/cpufreq_ondemand.c
index 18d4091..a27326d 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -27,9 +27,9 @@
 #define MIN_FREQUENCY_UP_THRESHOLD (11)
 #define MAX_FREQUENCY_UP_THRESHOLD (100)
 
-static DEFINE_PER_CPU(struct od_cpu_dbs_info_s, od_cpu_dbs_info);
+DEFINE_PER_CPU(struct od_cpu_dbs_info_s, od_cpu_dbs_info);
 
-static struct od_ops od_ops;
+struct od_ops od_ops;
 
 #ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
 static struct cpufreq_governor cpufreq_gov_ondemand;
@@ -152,7 +152,7 @@ static void dbs_freq_increase(struct cpufreq_policy 
*policy, unsigned int freq)
  * (default), then we try to increase frequency. Else, we adjust the frequency
  * proportional to load.
  */
-static void od_check_cpu(int cpu, unsigned int load)
+void od_check_cpu(int cpu, unsigned int load)
 {
struct od_cpu_dbs_info_s *dbs_info = _cpu(od_cpu_dbs_info, cpu);
struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
@@ -188,7 +188,7 @@ static void od_check_cpu(int cpu, unsigned int load)
}
 }
 
-static void od_dbs_timer(struct work_struct *work)
+void od_dbs_timer(struct work_struct *work)
 {
struct od_cpu_dbs_info_s *dbs_info =
container_of(work, struct od_cpu_dbs_info_s, cdbs.work.work);
@@ -233,6 +233,9 @@ max_delay:
 /** sysfs interface /
 static struct common_dbs_data od_dbs_cdata;
 
+#ifdef CONFIG_CPU_FREQ_GOV_LAB
+extern struct cpufreq_governor cpufreq_gov_lab;
+#endif
 /**
  * update_sampling_rate - update sampling rate effective immediately if needed.
  * @new_rate: new sampling rate
@@ -246,7 +249,7 @@ static struct common_dbs_data od_dbs_cdata;
  * reducing the sampling rate, we need to make the new value effective
  * immediately.
  */
-static void update_sampling_rate(struct dbs_data *dbs_data,
+void update_sampling_rate(struct dbs_data *dbs_data,
unsigned int new_rate)
 {
struct od_dbs_tuners *od_tuners = dbs_data->tuners;
@@ -263,7 +266,12 @@ static void update_sampling_rate(struct dbs_data *dbs_data,
policy = cpufreq_cpu_get(cpu);
if (!policy)
continue;
+#ifdef CONFIG_CPU_FREQ_GOV_LAB
+   if (policy->governor != _gov_ondemand &&
+   policy->governor != _gov_lab) {
+#else
if (policy->governor != _gov_ondemand) {
+#endif
cpufreq_cpu_put(policy);
continue;
}
@@ -472,7 +480,7 @@ static struct attribute_group od_attr_group_gov_pol = {
 
 /** sysfs end /
 
-static int od_init(struct dbs_data *dbs_data)
+int od_init(struct dbs_data *dbs_data)
 {
struct od_dbs_tuners *tuners;
u64 idle_time;
@@ -514,14 +522,14 @@ static int od_init(struct dbs_data *dbs_data)
return 0;
 }
 
-static void od_exit(struct dbs_data *dbs_data)
+void od_exit(struct dbs_data *dbs_data)
 {
kfree(dbs_data->tuners);
 }
 
 define_get_cpu_dbs_routines(od_cpu_dbs_info);
 
-static struct od_ops od_ops = {
+struct od_ops od_ops = {
.powersave_bias_init_cpu = ondemand_powersave_bias_init_cpu,
.powersave_bias_target = generic_powersave_bias_target,
.freq_increase = dbs_freq_increase,
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC v3 4/5] cpufreq:LAB:Kconfig Add LAB definitions to Kconfig

[Lukasz Majewski]

Provide support for LAB governor for the Kbuild.

It is important to note, that LAB is not possible to be compiled in as
a module since we cannot assure (in the kernel) that backing ondemand
module will not be removed without notice to LAB.

For this reason the LAB can be only compiled into the kernel without
possibility to be compiled as a module.

Signed-off-by: Lukasz Majewski 
Signed-off-by: MyungJoo Ham 
---
 drivers/cpufreq/Kconfig |   28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 4b029c0..3a870ea 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -102,6 +102,18 @@ config CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
  Be aware that not all cpufreq drivers support the conservative
  governor. If unsure have a look at the help section of the
  driver. Fallback governor will be the performance governor.
+
+config CPU_FREQ_DEFAULT_GOV_LAB
+   bool "lab"
+   select CPU_FREQ_GOV_LAB
+   select CPU_FREQ_GOV_PERFORMANCE
+   help
+ Use the CPUFreq governor 'lab' as default. This allows
+ you to get a full dynamic frequency capable system by simply
+ loading your cpufreq low-level hardware driver.
+ Be aware that not all cpufreq drivers support the lab governor.
+ If unsure have a look at the help section of the driver.
+ Fallback governor will be the performance governor.
 endchoice
 
 config CPU_FREQ_GOV_PERFORMANCE
@@ -183,6 +195,22 @@ config CPU_FREQ_GOV_CONSERVATIVE
 
  If in doubt, say N.
 
+config CPU_FREQ_GOV_LAB
+   bool "'lab' cpufreq policy governor - ONDEMAND extension"
+   select CPU_FREQ_TABLE
+   select CPU_FREQ_GOV_COMMON
+   select CPU_FREQ_GOV_ONDEMAND
+   help
+ 'lab' - This driver adds a dynamic cpufreq policy governor.
+
+ LAB governor shall be regarded as an extension of the ONDEMAND on
+ platforms with very weak HW support for power management.
+
+ LAB governor can be either compiled in or not. It is not possible to
+ compile it as module because of explicit ONDEMAND dependency.
+
+ If in doubt, say N.
+
 config GENERIC_CPUFREQ_CPU0
tristate "Generic CPU0 cpufreq driver"
depends on HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] regulator: pfuze100: Add terminate entry for [i2c|of]_device_id tables

[Yibin Gong]

Acked-by: Robin Gong 

-Original Message-
From: Axel Lin [mailto:axel@ingics.com] 
Sent: Tuesday, March 04, 2014 6:20 PM
To: Mark Brown
Cc: Gong Yibin-B38343; Liam Girdwood; linux-kernel@vger.kernel.org
Subject: [PATCH] regulator: pfuze100: Add terminate entry for 
[i2c|of]_device_id tables

Also remove PFUZE_NUM to avoid below build warnings:

  CC [M]  drivers/regulator/pfuze100-regulator.o
drivers/regulator/pfuze100-regulator.c:86:2: warning: excess elements in array 
initializer [enabled by default]
drivers/regulator/pfuze100-regulator.c:86:2: warning: (near initialization for 
'pfuze_device_id') [enabled by default]
drivers/regulator/pfuze100-regulator.c:93:2: warning: excess elements in array 
initializer [enabled by default]
drivers/regulator/pfuze100-regulator.c:93:2: warning: (near initialization for 
'pfuze_dt_ids') [enabled by default]

Signed-off-by: Axel Lin 
---
 drivers/regulator/pfuze100-regulator.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/regulator/pfuze100-regulator.c 
b/drivers/regulator/pfuze100-regulator.c
index 44075f8..f87ec70 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -56,7 +56,7 @@
 #define PFUZE100_VGEN5VOL  0x70
 #define PFUZE100_VGEN6VOL  0x71
 
-enum chips {PFUZE100, PFUZE200, PFUZE_NUM};
+enum chips { PFUZE100, PFUZE200 };
 
 struct pfuze_regulator {
struct regulator_desc desc;
@@ -80,15 +80,17 @@ static const int pfuze100_vsnvs[] = {
100, 110, 120, 130, 150, 180, 300,  };
 
-static const struct i2c_device_id pfuze_device_id[PFUZE_NUM] = {
+static const struct i2c_device_id pfuze_device_id[] = {
{.name = "pfuze100", .driver_data = PFUZE100},
{.name = "pfuze200", .driver_data = PFUZE200},
+   { }
 };
 MODULE_DEVICE_TABLE(i2c, pfuze_device_id);
 
-static const struct of_device_id pfuze_dt_ids[PFUZE_NUM] = {
+static const struct of_device_id pfuze_dt_ids[] = {
{ .compatible = "fsl,pfuze100", .data = (void *)PFUZE100},
{ .compatible = "fsl,pfuze200", .data = (void *)PFUZE200},
+   { }
 };
 MODULE_DEVICE_TABLE(of, pfuze_dt_ids);
 
--
1.8.1.2





N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

[RFC v3 5/5] cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor

[Lukasz Majewski]

Adds LAB attributes to proper CPU0 node.
The lab-num-of-states attribute shows how many compartments will be used.
The LAB code is prepared to be more fine grained.

The lab-ctrl-freq defines how the LAB governor will be controlled:
- 0xFFFE- use the minimal frequency
- 0x- enable boost
- non zero  - set the frequency specified
- zero  - use ondemand to specify output frequency

Signed-off-by: Lukasz Majewski 
Signed-off-by: MyungJoo Ham 
---
 arch/arm/boot/dts/exynos4412-trats2.dts |   29 +
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 4f851cc..9eeeb38 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -511,6 +511,35 @@
};
};
 
+   cpus {
+   cpu@0 {
+   compatible = "arm,cortex-a9";
+   device_type = "cpu";
+   lab-num-of-states = <5>;
+   lab-ctrl-freq = < 0  0  0  
130120
+ 0  0  0  0
  130
+ 0  0  0  0
  0x
+ 0  0  0  
0x 0x
+ 0xFFFE 0xFFFE 0xFFFE 
0xFFFE 0xFFFE
+   >;
+   };
+
+   cpu@1 {
+   compatible = "arm,cortex-a9";
+   device_type = "cpu";
+   };
+
+   cpu@2 {
+   compatible = "arm,cortex-a9";
+   device_type = "cpu";
+   };
+
+   cpu@3 {
+   compatible = "arm,cortex-a9";
+   device_type = "cpu";
+   };
+   };
+
camera {
pinctrl-0 = <_port_b_clk_active>;
pinctrl-names = "default";
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC v3 2/5] cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to support LAB

[Lukasz Majewski]

Some minor adjustments were needed to support LAB operation in the
cpufreq_governor.[h|c] files.

Most notably, code for proper estimation of the idle time for each CPU is
added here.

Signed-off-by: Lukasz Majewski 
Signed-off-by: MyungJoo Ham 
---
 drivers/cpufreq/cpufreq_governor.c |7 +++
 drivers/cpufreq/cpufreq_governor.h |2 ++
 2 files changed, 9 insertions(+)

diff --git a/drivers/cpufreq/cpufreq_governor.c 
b/drivers/cpufreq/cpufreq_governor.c
index ba43991..99fc3e8 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -98,6 +98,13 @@ void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
 
load = 100 * (wall_time - idle_time) / wall_time;
 
+   if (dbs_data->cdata->governor == GOV_LAB) {
+   struct od_cpu_dbs_info_s *od_dbs_info =
+   dbs_data->cdata->get_cpu_dbs_info_s(j);
+
+   od_dbs_info->idle_time = (100 * idle_time) / wall_time;
+   }
+
if (load > max_load)
max_load = load;
}
diff --git a/drivers/cpufreq/cpufreq_governor.h 
b/drivers/cpufreq/cpufreq_governor.h
index 34b1cf2..82a519f 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -152,6 +152,7 @@ struct od_cpu_dbs_info_s {
unsigned int freq_lo_jiffies;
unsigned int freq_hi_jiffies;
unsigned int rate_mult;
+   unsigned int idle_time;
unsigned int sample_type:1;
 };
 
@@ -187,6 +188,7 @@ struct common_dbs_data {
/* Common across governors */
#define GOV_ONDEMAND0
#define GOV_CONSERVATIVE1
+   #define GOV_LAB 2
int governor;
struct attribute_group *attr_group_gov_sys; /* one governor - system */
struct attribute_group *attr_group_gov_pol; /* one governor - policy */
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC v3 3/5] cpufreq:LAB:lab Add LAB governor code

[Lukasz Majewski]

This patch adds code for LAB governor. It shall be noted, that it reuses
a lot of ondemand code.

The main difference is that it works on top of ondemand, and this code is
able to "call" ondemand when needed. This means that all ondemand "backing"
data are properly updated.

Such approach has one major advantage - with LAB we can focus on saving
energy and leave the "normal" cpufreq management to well tested ondemand.

Signed-off-by: Lukasz Majewski 
Signed-off-by: MyungJoo Ham 
---
 drivers/cpufreq/Makefile  |1 +
 drivers/cpufreq/cpufreq_lab.c |  457 +
 2 files changed, 458 insertions(+)
 create mode 100644 drivers/cpufreq/cpufreq_lab.c

diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 7494565..64bff8dc 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_CPU_FREQ_GOV_POWERSAVE)+= cpufreq_powersave.o
 obj-$(CONFIG_CPU_FREQ_GOV_USERSPACE)   += cpufreq_userspace.o
 obj-$(CONFIG_CPU_FREQ_GOV_ONDEMAND)+= cpufreq_ondemand.o
 obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE)+= cpufreq_conservative.o
+obj-$(CONFIG_CPU_FREQ_GOV_LAB) += cpufreq_lab.o
 obj-$(CONFIG_CPU_FREQ_GOV_COMMON)  += cpufreq_governor.o
 
 obj-$(CONFIG_GENERIC_CPUFREQ_CPU0) += cpufreq-cpu0.o
diff --git a/drivers/cpufreq/cpufreq_lab.c b/drivers/cpufreq/cpufreq_lab.c
new file mode 100644
index 000..153c06b
--- /dev/null
+++ b/drivers/cpufreq/cpufreq_lab.c
@@ -0,0 +1,457 @@
+/*
+ * Copyright (c) 2013-2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Jonghwa Lee 
+ * Lukasz Majewski 
+ *
+ * LAB (Legacy Application Boost) cpufreq governor
+ *
+ * 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 
+#include 
+#include 
+#include 
+
+#include "cpufreq_governor.h"
+
+#define MAX_HIST   5
+
+#define LB_BOOST_ENABLE~0UL
+#define LB_MIN_FREQ~1UL
+#define LB_ONDEMAND 0
+
+/*
+ * Pre-calculated summation of weight, 0.5
+ * 1
+ * 1 + 0.5^1 = 1.5
+ * 1 + 0.5^1 + 0.5^2 = 1.75
+ * 1 + 0.5^1 + 0.5^2 + 0.5^3 = 1.87
+ * 1 + 0.5^1 + 0.5^2 + 0.5^3 + 0.5^4 = 1.93
+ */
+static int history_weight_sum[] = { 100, 150, 175, 187, 193 };
+
+static unsigned int *idle_avg;
+static unsigned int *idle_hist;
+static int idle_cpus, lb_threshold = 90;
+static unsigned int *lb_ctrl_table, lb_load;
+static int lb_ctrl_table_size, lb_num_of_states;
+static bool boost_init_state;
+
+static DECLARE_BITMAP(boost_hist, MAX_HIST);
+DECLARE_PER_CPU(struct od_cpu_dbs_info_s, od_cpu_dbs_info);
+
+struct cpufreq_governor cpufreq_gov_lab;
+
+
+static struct lb_wq_boost_data {
+   bool state;
+   struct work_struct work;
+} lb_boost_data;
+
+/*
+ * Calculate average of idle time with weighting 50% less to older one.
+ * With weight, average can be affected by current phase more rapidly than
+ * normal average. And it also has tolerance for temporary fluctuation of
+ * idle time as normal average has.
+ *
+ * Weigted average = sum(ai * wi) / sum(wi)
+ */
+static inline int cpu_idle_calc_avg(unsigned int *p, int size)
+{
+   int i, sum;
+
+   for (i = 0, sum = 0; i < size; p++, i++) {
+   sum += *p;
+   *p >>= 1;
+   }
+   sum *= 100;
+
+   return (int) (sum / history_weight_sum[size - 1]);
+}
+
+static unsigned int lb_chose_freq(unsigned int load, int idle_cpus)
+{
+   unsigned int p, q = 100 / lb_num_of_states;
+   int idx;
+
+   for (idx = 0, p = q; idx < lb_num_of_states; idx++, p += q)
+   if (load <= p)
+   break;
+
+   return *(lb_ctrl_table + (lb_num_of_states * idle_cpus) + idx);
+}
+
+static void lb_cpufreq_boost_work(struct work_struct *work)
+{
+   struct lb_wq_boost_data *d = container_of(work,
+ struct lb_wq_boost_data,
+ work);
+   cpufreq_boost_trigger_state(d->state);
+}
+
+static struct common_dbs_data lb_dbs_cdata;
+/*
+ * LAB governor policy adjustement
+ */
+static void lb_check_cpu(int cpu, unsigned int load)
+{
+   struct od_cpu_dbs_info_s *dbs_info = _cpu(od_cpu_dbs_info, cpu);
+   struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
+   unsigned int freq = 0, op;
+   static int cnt;
+   int i, idx, bs;
+
+   idle_cpus = 0;
+   lb_load = load;
+   idx = cnt++ % MAX_HIST;
+
+   for_each_possible_cpu(i) {
+   struct od_cpu_dbs_info_s *dbs_cpu_info =
+   _cpu(od_cpu_dbs_info, i);
+
+   idle_hist[i * MAX_HIST + idx] = dbs_cpu_info->idle_time;
+   idle_avg[i] = 

Re: [PATCH v2 1/5] ASoC: kirkwood: prepare new Dove DT Kconfig variable

[Sebastian Hesselbarth]

On 03/04/2014 05:03 AM, Mark Brown wrote:

On Sat, Mar 01, 2014 at 09:33:17AM +0100, Sebastian Hesselbarth wrote:

DT-enabled Dove will move over from ARCH_DOVE in mach-dove to MACH_DOVE in
mach-mvebu. As non-DT ARCH_DOVE will stay to rot for a while, add a new
DT-only MACH_DOVE Kconfig.


This doesn't apply against current ASoC, please check and resend.


Mark,

actually looking at what that specific Kconfig will look like in
asoc/for-next, I guess the current version is sufficient already.

It already says:

depends on ARCH_KIRKWOOD || ARCH_DOVE || ARCH_MVEBU || COMPILE_TEST

and MACH_DOVE will be part of ARCH_MVEBU.

Thanks for pointing this out, please ignore this patch.

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V3 1/5] genirq: define flag IRQ_SRC_DST_INVERTED, and accessors

[Thomas Gleixner]

On Tue, 4 Mar 2014, Thomas Gleixner wrote:

> On Mon, 3 Mar 2014, Stephen Warren wrote:
> 
> > From: Stephen Warren 
> > 
> > Some devices have configurable IRQ output polarities. Software might
> > use IRQ_TYPE_* to determine how to configure such a device's IRQ
> > output polarity in order to match how the IRQ controller input is
> > configured. If the board or SoC inverts the signal between the
> > device's IRQ output and controller's IRQ output, software must be
> > aware of this fact, in order to program the IRQ output to the correct
> > (i.e. opposite) polarity. This flag provides that information.
> 
> So what you're saying is:
> 
> Device IRQ output --> [Optional Inverter Logic] --> IRQ controller input.
> 
> And you're storing the information about the presence of the inverter
> logic in the irq itself, but the core does not make any use of it and
> you let the device driver deal with the outcome.
> 
> This sucks as all affected drivers have to implement the same sanity
> logic for this.
> 
> Why don't you implement a core function which tells the driver which
> polarity to select? That requires a few more changes, but I think it's
> worth it for other reasons.
> 
> Right now the set_type logic requires the irq chip drivers to
> implement sanity checking and default selections for TYPE_NONE. We can
> be more clever about that and add this information to the irq chip
> flags.
> 
> enum {
>  IRQ_CHIP_TYPES_MASK  = 0x0f,
>  IRQ_CHIP_DEFAULT_MASK= 0xf0,
>  IRQ_CHIP_EXISTING_FLAGS  
> }

We need to extend the mask to indicate whether the chip supports
BOTH_EDGES. A chip can support FALLING and RISING, but not both at the
same time. For the set_type side the current BOTH = FALLING | RISING
is fine, but for checking the supported type it's not sufficient.

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/

[PATCH2] CNS3xxx: Fix a WARN() related to IRQ allocation.

[Krzysztof Hałasa]

WARNING: at drivers/irqchip/irq-gic.c:952 gic_init_bases+0xe4/0x2b8()
Cannot allocate irq_descs @ IRQ16, assuming pre-allocated
Backtrace:
gic_init_basesfrom cns3xxx_init_irq+0x24/0x34
cns3xxx_init_irq  from init_IRQ+0x24/0x2c
init_IRQ  from start_kernel+0x1a8/0x338
start_kernel  from 0x2000806c

The problem is that 64 CNS3xxx CPU interrupts, starting at 32, are
allocated by the ARM platform-independent code (as requested by
machine_desc->nr_irqs = 96), and then the GIC code tries to allocate
them again.

Tested on Gateworks Laguna board, masqueraded as CNS3420VB.

Signed-off-by: Krzysztof Hałasa 
-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] perf tools: Add libdw DWARF post unwind support for ARM

[Jiri Olsa]

On Tue, Mar 04, 2014 at 02:24:37AM +0100, Jean Pihet wrote:
> Hi,
> 
> Here are some notes about the performance improvement and the test usage.
> 
> Jiri, do you need these notes in the one of commit description?
> 
> 1. Using libdw vs libunwind on ARMv7
> 
> The performance gain is (more than) significant: >800%.

I dont mind.. but 800% would look just great in changelog ;-)

jirka

> 
> I did not profile perf itself ;-p just did a timing measurement.
> The benchmark has been run multiple times with different perf.data
> sizes. The results are consistent across the tests runs.
> 
> Usage:
> ./tools/perf/perf record --call-graph dwarf --
> ../../libunwind/test_app/stress_bt
> time ./tools/perf/perf report --stdio > /dev/null 2>&1
> 
> Platform:
> Quad-core marvell XP370. perf runs on 1 cpu
> 
> Perf data size:
> 304MBlibunwindlibdwimprovement
> real9m31.577s1m13.052s782%
> user5m33.020s1m2.910s529%
> sys3m57.770s0m10.090s2356%
> 
> 2. unwind test usage
> perf test list gives the list of supported tests. In this case the
> test #23 is dwarf unwinding:
> 
> ./tools/perf/perf test 23
> 23: Test dwarf unwind  : Ok
> 
> 
> Regards,
> Jean
> 
> 
> On 3 March 2014 10:53, Jean Pihet  wrote:
> > Adding libdw DWARF post unwind support, which is part
> > of elfutils-devel/libdw-dev package from version 0.158.
> >
> > Also includes the test suite for dwarf unwinding, by adding the
> > arch specific test code and the perf_regs_load function.
> >
> > Jean Pihet (3):
> >   perf tests: Introduce perf_regs_load function on ARM
> >   perf tests: Add dwarf unwind test on ARM
> >   perf tools: Add libdw DWARF post unwind support for ARM
> >
> >  tools/perf/Makefile.perf |  2 +-
> >  tools/perf/arch/arm/Makefile |  7 
> >  tools/perf/arch/arm/include/perf_regs.h  |  5 +++
> >  tools/perf/arch/arm/tests/dwarf-unwind.c | 59 
> > 
> >  tools/perf/arch/arm/tests/regs_load.S| 51 +++
> >  tools/perf/arch/arm/util/unwind-libdw.c  | 36 +++
> >  tools/perf/tests/builtin-test.c  |  2 +-
> >  tools/perf/tests/tests.h |  2 +-
> >  8 files changed, 161 insertions(+), 3 deletions(-)
> >  create mode 100644 tools/perf/arch/arm/tests/dwarf-unwind.c
> >  create mode 100644 tools/perf/arch/arm/tests/regs_load.S
> >  create mode 100644 tools/perf/arch/arm/util/unwind-libdw.c
> >
> > ---
> >
> > - Rebased on latest acme/perf/core git tree,
> > - Tested on quad-core ARMv7 machine
> >
> > --
> > 1.7.11.7
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/