Re: [PATCH v2 1/2] debugfs: Export bool read/write functions

[Greg KH]

On Tue, Jun 23, 2015 at 02:32:54PM +0100, Richard Fitzgerald wrote:
> The file read/write functions for bools have no special dependencies
> on debugfs internals and are sufficiently non-trivial to be worth
> exporting so clients can re-use the implementation.
> 
> Signed-off-by: Richard Fitzgerald 

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

Re: [PATCH 1/3] zpool: add zpool_has_pool()

[Andrew Morton]

On Wed,  5 Aug 2015 09:46:41 -0400 Dan Streetman  wrote:

> Add zpool_has_pool() function, indicating if the specified type of zpool
> is available (i.e. zsmalloc or zbud).  This allows checking if a pool is
> available, without actually trying to allocate it, similar to
> crypto_has_alg().
> 
> This is used by a following patch to zswap that enables the dynamic
> runtime creation of zswap zpools.
> 
> ...
>
>  /**
> + * zpool_has_pool() - Check if the pool driver is available
> + * @type The type of the zpool to check (e.g. zbud, zsmalloc)
> + *
> + * This checks if the @type pool driver is available.
> + *
> + * Returns: true if @type pool is available, false if not
> + */
> +bool zpool_has_pool(char *type)
> +{
> + struct zpool_driver *driver = zpool_get_driver(type);
> +
> + if (!driver) {
> + request_module("zpool-%s", type);
> + driver = zpool_get_driver(type);
> + }
> +
> + if (!driver)
> + return false;
> +
> + zpool_put_driver(driver);
> + return true;
> +}

This looks racy: after that zpool_put_driver() has completed, an rmmod
will invalidate zpool_has_pool()'s return value.

If there's some reason why this can't happen, can we please have a code
comment which reveals that reason?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv5 3/5] Staging: most: hdm-usb/hdm_usb.c. Fix "missing static keyword" warnings

[Christian Gromm]

On Tue, 4 Aug 2015 20:44:53 +0200
Adrian Remonda  wrote:

> This is a patch to the most/hdm-usb/hdm_usb.c file. It
> makes several local functions and structures static to prevent global
> visibility.
> 
> Signed-off-by: Adrian Remonda 
> ---
>  drivers/staging/most/hdm-usb/hdm_usb.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/staging/most/hdm-usb/hdm_usb.c 
> b/drivers/staging/most/hdm-usb/hdm_usb.c
> index 514ce3529b7a..db92b2ba423d 100644
> --- a/drivers/staging/most/hdm-usb/hdm_usb.c
> +++ b/drivers/staging/most/hdm-usb/hdm_usb.c
> @@ -290,7 +290,7 @@ static unsigned int get_stream_frame_size(struct 
> most_channel_config *cfg)
>   *
>   * Returns 0 on success or error code otherwise.
>   */
> -int hdm_poison_channel(struct most_interface *iface, int channel)
> +static int hdm_poison_channel(struct most_interface *iface, int channel)
>  {
>   struct most_dev *mdev;
>  
> @@ -328,7 +328,7 @@ int hdm_poison_channel(struct most_interface *iface, int 
> channel)
>   * This inserts the INIC hardware specific padding bytes into a streaming
>   * channel's buffer
>   */
> -int hdm_add_padding(struct most_dev *mdev, int channel, struct mbo *mbo)
> +static int hdm_add_padding(struct most_dev *mdev, int channel, struct mbo 
> *mbo)
>  {
>   struct most_channel_config *conf = &mdev->conf[channel];
>   unsigned int j, num_frames, frame_size;
> @@ -365,7 +365,7 @@ int hdm_add_padding(struct most_dev *mdev, int channel, 
> struct mbo *mbo)
>   * This takes the INIC hardware specific padding bytes off a streaming
>   * channel's buffer.
>   */
> -int hdm_remove_padding(struct most_dev *mdev, int channel, struct mbo *mbo)
> +static int hdm_remove_padding(struct most_dev *mdev, int channel, struct mbo 
> *mbo)
>  {
>   unsigned int j, num_frames, frame_size;
>   struct most_channel_config *const conf = &mdev->conf[channel];
> @@ -644,7 +644,7 @@ static void hdm_read_completion(struct urb *urb)
>   *
>   * Context: Could in _some_ cases be interrupt!
>   */
> -int hdm_enqueue(struct most_interface *iface, int channel, struct mbo *mbo)
> +static int hdm_enqueue(struct most_interface *iface, int channel, struct mbo 
> *mbo)
>  {
>   struct most_dev *mdev;
>   struct buf_anchor *anchor;
> @@ -743,8 +743,8 @@ _error:
>   * @channel: channel ID
>   * @conf: structure that holds the configuration information
>   */
> -int hdm_configure_channel(struct most_interface *iface, int channel,
> -   struct most_channel_config *conf)
> +static int hdm_configure_channel(struct most_interface *iface, int channel,
> + struct most_channel_config *conf)
This is still not aligned.

regards,
Chris   

>  {
>   unsigned int num_frames;
>   unsigned int frame_size;
> @@ -824,7 +824,7 @@ exit:
>   * This triggers the USB vendor requests to read the hardware address and
>   * the current link status of the attached device.
>   */
> -int hdm_update_netinfo(struct most_dev *mdev)
> +static int hdm_update_netinfo(struct most_dev *mdev)
>  {
>   struct device *dev = &mdev->usb_device->dev;
>   int i;
> @@ -873,7 +873,7 @@ int hdm_update_netinfo(struct most_dev *mdev)
>   * polls for the NI state of the INIC every 2 seconds.
>   *
>   */
> -void hdm_request_netinfo(struct most_interface *iface, int channel)
> +static void hdm_request_netinfo(struct most_interface *iface, int channel)
>  {
>   struct most_dev *mdev;
>  

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

Re: [PATCH V4 (was V6)] audit: use macros for unset inode and device values

[Steve Grubb]

On Wednesday, August 05, 2015 03:16:58 PM Paul Moore wrote:
> On Wednesday, August 05, 2015 02:30:14 AM Richard Guy Briggs wrote:
> > On 15/08/04, Paul Moore wrote:
> > > On Saturday, August 01, 2015 03:42:23 PM Richard Guy Briggs wrote:
> > > > Signed-off-by: Richard Guy Briggs 
> > > > ---
> > > > 
> > > >  include/uapi/linux/audit.h |2 ++
> > > >  kernel/audit.c |2 +-
> > > >  kernel/audit_watch.c   |8 
> > > >  kernel/auditsc.c   |6 +++---
> > > >  4 files changed, 10 insertions(+), 8 deletions(-)
> > > 
> > > Yipee, less magic numbers!
> > > 
> > > However, one question for you ... are we ever going to see a device or
> > > inode set to -1 in the userspace facing API?  In other words, should the
> > > new #defines go in the uapi headers or simply in kernel/audit.h?  Unless
> > > it is part of the API, let's leave it out of uapi as we have to be very
> > > careful about that stuff and I'd prefer to keep it minimal.
> > 
> > This is a good point.  I did briefly thing about this at one point.
> > Perhaps Steve can answer this.  It would be trivial to move it back to
> > uapi if needed.  Would you be ok with it in include/linux/audit.h for
> > now?
> 
> I have no problem with it in include/linux/audit.h, that is a kernel-only
> include that we can change at anytime.  My concern is putting it into a uapi
> header which makes it very hard to change.
> 
> I'm thinking we should just go ahead and put it in include/linux/audit.h for
> now as I can't think of a reason why userspace should be passing in an
> invalid dev/inode value, it just doesn't make sense.  If the invalid tokens
> prove to be valuable for userspace, we can always move the #defines.

I can't imagine anyone auditing against a specific device or inode. Its like 
auditing a pid when you really want the program name. Its much more useful to 
audit by filename or directory and not inode/device. So, do whatever you want. 
The only unset value that people actually use is the auid because deamons have 
it unset.

-Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] can: xilinx: fix RX FIFO overflow error handling

[Andrea Scian - DAVE Embedded Systems]

Michal,
Kedar,

Any feedback regarding my patch?
Have you ever experienced such a problem?

Andrea SCIAN

*DAVE Embedded Systems*
via Talponedo 29/A 33080 Porcia (PN) - Italy
Telephone: +39.0434.921215
Telefax: +39.0434.1994030
web: www.dave.eu 


Il 24/07/2015 06:15, Michal Simek ha scritto:

+ Kedar

On 07/23/2015 11:13 PM, Andrea Scian wrote:

Simply resetting the peripheral on RX FIFO overflow in not enough,
because we also need to re-initialize the whole device.
Also always enable RX FIFO overflow interrupt otherwise we may hang
until another interrupt arrives (this happens if FIFO overrun and just
read from CAN bus with candump)

Signed-off-by: Andrea Scian 
---

You can reproduce the problem with the following test-bed
* connect a Zynq based board to a PC with a CAN bus adapter (e.g. PCAN USB)
* start sending lots of CAN messages to Zynq system
* configure and start xilinx CAN driver
** canconfig can0 bitrate 100
** canconfig can0 start
* try to send/receive messages (cansend/candump)
* if you send a CAN message you'll get the RX FIFO error and additional messages
will not be received
* if you try to get messages you simple don't receive them (no interrupt 
triggered)
* with canconfig stop/start the hang goes away (if the others peers stop sending
send lots of messages ;-) )

I tested the patch over xilinx-2014.04 kernel, but the patch applies cleanly to
mainline too.

If someone has a better understanding of Xilinx CAN driver, please let me know 
if
it's better to handle the error in a different manner.

Maybe the bus off handler need the same threadment too.

TIA,

Andrea Scian

---
  drivers/net/can/xilinx_can.c |5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index 5e8b560..c278177 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -100,6 +100,7 @@ enum xcan_reg {
  #define XCAN_INTR_ALL (XCAN_IXR_TXOK_MASK | XCAN_IXR_BSOFF_MASK |\
 XCAN_IXR_WKUP_MASK | XCAN_IXR_SLP_MASK | \
 XCAN_IXR_RXNEMP_MASK | XCAN_IXR_ERROR_MASK | \
+XCAN_IXR_RXOFLW_MASK | \
 XCAN_IXR_ARBLST_MASK | XCAN_IXR_RXOK_MASK)

  /* CAN register bit shift - XCAN___SHIFT */
@@ -526,6 +527,7 @@ static int xcan_rx(struct net_device *ndev)
return 1;
  }

+static void xcan_chip_stop(struct net_device *ndev);
  /**
   * xcan_err_interrupt - error frame Isr
   * @ndev: net_device pointer
@@ -597,7 +599,8 @@ static void xcan_err_interrupt(struct net_device *ndev, u32 
isr)
if (isr & XCAN_IXR_RXOFLW_MASK) {
stats->rx_over_errors++;
stats->rx_errors++;
-   priv->write_reg(priv, XCAN_SRR_OFFSET, XCAN_SRR_RESET_MASK);
+   xcan_chip_stop(ndev);
+   xcan_chip_start(ndev);
if (skb) {
cf->can_id |= CAN_ERR_CRTL;
cf->data[1] |= CAN_ERR_CRTL_RX_OVERFLOW;




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ioatdma: fix overflow of u16 in ring_reshape

[Dan Williams]

On Wed, Aug 5, 2015 at 7:55 AM, Allen Hubbe  wrote:
> If the allocation order is 16, then the u16 index will overflow and wrap
> to zero instead of being equal or greater than 1 << 16.  The loop
> condition will always be true, and the loop will run until all the
> memory resources are depleted.
>
> Change the type of index 'i' to u32, so that it is large enough to store
> a value equal or greater than 1 << 16.
>
> Signed-off-by: Allen Hubbe 
> ---
>
> Version Two: rebased the fix on top of Dave Jiang's work.
>

Hmm, I think we should instead limit the max order to 15 instead
because there are other usages of u16 throughout the driver.  In fact
I thought that was already enforced, but seems I'm mistaken.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 0/8] Allow GFP_NOFS allocation to fail

[Andreas Dilger]

On Aug 5, 2015, at 3:51 AM, mho...@kernel.org wrote:
> Hi,
> small GFP_NOFS, like GFP_KERNEL, allocations have not been not failing
> traditionally even though their reclaim capabilities are restricted
> because the VM code cannot recurse into filesystems to clean dirty
> pages. At the same time these allocation requests do not allow to
> trigger the OOM killer because that would lead to pre-mature OOM killing
> during heavy fs metadata workloads.
> 
> This leaves the VM code in an unfortunate situation where GFP_NOFS
> requests is looping inside the allocator relying on somebody else to
> make a progress on its behalf. This is prone to deadlocks when the
> request is holding resources which are necessary for other task to make
> a progress and release memory (e.g. OOM victim is blocked on the lock
> held by the NONFS request). Another drawback is that the caller of
> the allocator cannot define any fallback strategy because the request
> doesn't fail.
> 
> As the VM cannot do much about these requests we should face the reality
> and allow those allocations to fail. Johannes has already posted the
> patch which does that (http://marc.info/?l=linux-mm&m=142726428514236&w=2)
> but the discussion died pretty quickly.
> 
> I was playing with this patch and xfs, ext[34] and btrfs for a while
> to see what is the effect under heavy memory pressure. As expected
> this led to some fallouts.
> 
> My test consisted of a simple memory hog which allocates a lot of
> anonymous memory and writes to a fs mainly to trigger a fs activity on
> exit. In parallel there is a parallel fs metadata load (multiple tasks
> creating thousands of empty files and directories). All is running
> in a VM with small amount of memory to emulate an under provisioned
> system. The metadata load is triggering a sufficient load to invoke
> the direct reclaim even without the memory hog. The memory hog forks
> several tasks sharing the VM and OOM killer manages to kill it without 
> locking up the system (this was based on the test case from Tetsuo
> Handa - http://www.spinics.net/lists/linux-fsdevel/msg82958.html -
> I just didn't want to kill my machine ;)).
> 
> With all the patches applied none of the 4 filesystems gets aborted
> transactions and RO remount (well xfs didn't need any special
> treatment). This is obviously not sufficient to claim that failing
> GFP_NOFS is OK now but I think it is a good start for the further
> discussion. I would be grateful if FS people could have a look at
> those patches.  I have simply used __GFP_NOFAIL in the critical paths. 
> This might be not the best strategy but it sounds like a good first
> step.
> 
> The first patch in the series also allows __GFP_NOFAIL allocations to
> access memory reserves when the system is OOM which should help those
> requests to make a forward progress - especially in combination with
> GFP_NOFS.
> 
> The second patch tries to address a potential pre-mature OOM killer
> from the page fault path. I have posted it separately but it didn't
> get much traction.
> 
> The third patch allows GFP_NOFS to fail and I believe it should see
> much more testing coverage. It would be really great if it could sit
> in the mmotm tree for few release cycles so that we can catch more
> fallouts.
> 
> The rest are the FS specific patches to fortify allocations
> requests which are really needed to finish transactions without RO
> remounts. There might be more needed but my test case survives with
> these in place.

Wouldn't it make more sense to order the fs-specific patches _before_
the "GFP_NOFS can fail" patch (#3), so that once that patch is applied
all known failures have already been fixed?  Otherwise it could show
test failures during bisection that would be confusing.

Cheers, Andreas

> They would obviously need some rewording if they are going to be
> applied even without Patch3 and I will do that if respective
> maintainers will take them. Ext3 and JBD are going away soon so they
> might be dropped but they have been in the tree while I was testing
> so I've kept them.
> 
> Thoughts? Opinions?
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers, Andreas





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ioatdma: fix overflow of u16 in ring_reshape

[Allen Hubbe]

If the allocation order is 16, then the u16 index will overflow and wrap
to zero instead of being equal or greater than 1 << 16.  The loop
condition will always be true, and the loop will run until all the
memory resources are depleted.

Change the type of index 'i' to u32, so that it is large enough to store
a value equal or greater than 1 << 16.

Signed-off-by: Allen Hubbe 
---

Version Two: rebased the fix on top of Dave Jiang's work.

 drivers/dma/ioat/dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/ioat/dma.c b/drivers/dma/ioat/dma.c
index a5630966834e..7435585dbbd6 100644
--- a/drivers/dma/ioat/dma.c
+++ b/drivers/dma/ioat/dma.c
@@ -372,7 +372,7 @@ static bool reshape_ring(struct ioatdma_chan *ioat_chan, 
int order)
const u16 active = ioat_ring_active(ioat_chan);
const u32 new_size = 1 << order;
struct ioat_ring_ent **ring;
-   u16 i;
+   u32 i;
 
if (order > ioat_get_max_alloc_order())
return false;
-- 
2.5.0.rc1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] watchdog: Add support for keepalives triggered by infrastructure

[David Teigland]

On Wed, Aug 05, 2015 at 12:01:38PM -0700, Guenter Roeck wrote:
> I think I can understand why Wim was reluctant to accept your patch;
> I must admit I don't understand your use case either.

Very breifly, sanlock is a shared storage based lease manager, and the
expiration of a lease is tied to the expiration of the watchdog.  I have
to ensure that the watchdog expires at or before the time that the lease
expires.  This means that I cannot allow a watchdog heartbeat apart from a
corresponding lease renewal on the shared storage.  Otherwise, the
calculation by other hosts of the time of the hard reset will be wrong,
and the data on shared storage could be corrupted.

> I wonder if you are actually mis-using the watchdog subsystem to generate
> hard resets.

I am indeed using it to generate hard resets.

> After all, you could avoid the unexpected close situation with
> an exit handler in your application. That handler could catch anything but
> SIGKILL, but anyone using SIGKILL doesn't really deserve better.

I avoid the unexpected close situation by prematurely closing the device
to generate the heartbeat from close, and then reopening if needed.  That
covers the SIGKILL case.  So, I have a work around, but the patch would
still be nice.

> If the intent is to reset the system after the application closes,
> executing "/sbin/restart -f" might be a safer approach than just killing
> the watchdog.

I need to reset the system if the application crashes, or if the
application is running but can't renew its lease.  In the former case,
executing something doesn't work.  In the later case, I have done similar
(with /proc/sysrq-trigger), but it doesn't always apply and I'd still want
the hardware reset as redundancy.

> In addition to that, I don't think it is a good idea to rely on the assumption
> that the watchdog will expire exactly after the configured timeout.
> Many watchdog drivers implement a soft timeout on top of the hardware timeout,
> and thus already implement the internal heartbeat. Most of those drivers
> will stop sending internal heartbeats if user space did not send a heartbeat
> within the configured timeout period. The actual reset will then occur later,
> after the actual hardware watchdog timed out. This can be as much as the
> hardware timeout period, which may be substantial.

OK, thanks, I'll look into this in more detail.  Is there a way I can
identify which cases these are, or do you know an example I can look at?
In the worst case I'd have to extend the lease expiration time by a full
timeout period when the dubious drivers are used.

Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] timer: Improve itimers scalability

[Jason Low]

On Wed, 2015-08-05 at 11:37 +0200, Peter Zijlstra wrote:
> On Tue, Aug 04, 2015 at 05:29:44PM -0700, Jason Low wrote:
> 
> > @@ -1137,6 +1148,13 @@ static inline int fastpath_timer_check(struct 
> > task_struct *tsk)
> > if (READ_ONCE(sig->cputimer.running)) {
> 
> Maybe make that:
> 
>   if (READ_ONCE(sig->cputimer.running) &&
>   !READ_ONCE(sig->cputimer.is_checking_timer)) {

Yes, I think it would be better if the check is done here.

And perhaps the comment can be modified to:

/*
 * Check if thread group timers expired. This is skipped if the cputimer
 * is not running or if another thread in the group is already checking
 * for thread group cputimers.
 */

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT PULL] nfsd bugfixes for 4.2

[J. Bruce Fields]

On Wed, Aug 05, 2015 at 11:01:53AM +0200, Linus Torvalds wrote:
> On Tue, Aug 4, 2015 at 11:09 PM, J. Bruce Fields  wrote:
> > Please pull a few nfsd bugfixes for 4.2 from:
> 
> Pulled. However, I wonder if you could start making signed tag pull
> requests. I don't know how linux-nfs.org is maintained, and it's
> probably all really good and private, but it still makes me go
> "Wouldn't it be nice if..."

OK!  Apologies, I did at least get a key generated and signed by people
a few years ago, then I was too lazy to figure out how to use it.  I'll
give it a go for the next pull request.

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

Re: [PATCH] intel_pstate: append more Oracle OEM table id to vendor bypass list

[Kristen Carlson Accardi]

On Wed,  5 Aug 2015 09:28:50 +0900
Ethan Zhao  wrote:

> Append more Oracle X86 servers that have their own power management,
> 
> SUN FIRE X4275 M3
> SUN FIRE X4170 M3
> and
> SUN FIRE X6-2
> 
> Signed-off-by: Ethan Zhao 
> ---
>  drivers/cpufreq/intel_pstate.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index c45d274..c57b011 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -1156,6 +1156,10 @@ static struct hw_vendor_info vendor_info[] = {
>   {1, "ORACLE", "X4270M3 ", PPC},
>   {1, "ORACLE", "X4270M2 ", PPC},
>   {1, "ORACLE", "X4170M2 ", PPC},
> + {1, "ORACLE", "X4170 M3", PPC},
> + {1, "ORACLE", "X4275 M3", PPC},
> + {1, "ORACLE", "X6-2", PPC},
> + {1, "ORACLE", "Sudbury ", PPC},
>   {0, "", ""},
>  };
>  

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

Re: [PATCH 2/2] gpio/mxc: implement reading output gpio value

[Eduardo Valentin]

On Wed, Aug 05, 2015 at 03:11:40PM -0300, Fabio Estevam wrote:
> Hi Eduardo,
> 
> On Wed, Aug 5, 2015 at 3:02 PM, Eduardo Valentin  wrote:
> >
> > Hello Fabio,
> >
> > On Wed, Aug 05, 2015 at 02:43:05PM -0300, Fabio Estevam wrote:
> >> Hi Eduardo,
> >>
> >> On Wed, Aug 5, 2015 at 2:23 PM, Eduardo Valentin  
> >> wrote:
> >> > In current implementation, reading the value of an output gpio
> >> > always return 0. The reason is because when a gpio is configured
> >>
> >> Have you tried setting the SION bit for the pad?
> >
> > No, I haven't. From the bit description, it looks like it does a
> > different thing of what we would achieve with this patch. The SION bit
> > is a overwrite to the pad configuration. That is, the pin will be INPUT
> > always.
> >
> > We don't want to force it to be input. We simply want to be able to read
> > the value of an output GPIO. That is achievable by reading a different
> > register. In case the GPIO is configured as output, the GPIO block
> > documentation states its value can be read from GPIO_PSR.
> > This approach works fine, as the GPIO will be output and we can still
> > read its value.
> 
> Setting the SION bit allows you to do exactly that. Please see:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/271774.html

OK. Then, what is the recommendation? Do we set this by default in the
driver code or this is left for DTS pinmux configuration?

To me seams like a bug in the gpio driver still, as the possibility to
read the value of an output gpio is missing/inconsistent.

> 
> Regards,
> 
> Fabio Estevam


signature.asc
Description: Digital signature

Re: [RFCv3 1/4] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings.

[Moritz Fischer]

Michal,

On Tue, Aug 4, 2015 at 8:10 AM, Philipp Zabel  wrote:
> Hi Moritz,
>
> Am Dienstag, den 04.08.2015, 08:05 -0700 schrieb Moritz Fischer:
>> Hi Philip,
>>
>> On Tue, Aug 4, 2015 at 1:09 AM, Philipp Zabel  wrote:
>> > Hi Moritz,
>> >
>> > Am Donnerstag, den 30.07.2015, 18:13 -0700 schrieb Moritz Fischer:
> [...]
>> >> +Required properties:
>> >> +- compatible: "xlnx,zynq-reset"
>> >> +- reg: SLCR offset and size taken via syscon <0x200 0x48>
>> >> +- syscon: <&slcr>
>> >> +  This should be a phandle to the Zynq's SLCR register.
>> >
>> >  ^ register singular?
>> Do you want me to resend the entire set, or are you cool with just git
>> amending the 's' for registers?
>
> Amended and applied, thanks.

Will you take 4/4 and 2/4 via your tree?
>
> regards
> Philipp
>

Thanks,

Moritz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] user_ns: use correct check for single-threadedness

[Kees Cook]

On Wed, Aug 5, 2015 at 11:13 AM, Eric W. Biederman
 wrote:
> Kees Cook  writes:
>
>> On Tue, Jul 28, 2015 at 1:55 PM, Ricky Zhou  wrote:
>>> On Tue, Jul 28, 2015 at 11:17 AM, Eric W. Biederman
>>>  wrote:
 Kees Cook  writes:

> From: Ricky Zhou 
>
> Checking mm_users > 1 does not mean a process is multithreaded. For
> example, reading /proc/PID/maps temporarily increments mm_users, allowing
> other processes to (accidentally) interfere with unshare() calls.
>
> This fixes observed failures of unshare(CLONE_NEWUSER) incorrectly
> returning EINVAL if another processes happened to be simultaneously
> reading the maps file.
>
> Signed-off-by: Ricky Zhou 
> Signed-off-by: Kees Cook 
> Cc: sta...@vger.kernel.org

 This looks like a good fix.  Any chance you can drudge up the commit where
 this hack came in so that Greg & Company know how far to back port this?
>>>
>>> userns_install in user_namespace.c (affects setns of a user
>>> namespace): cde1975bc242f3e1072bde623ef378e547b73f91.
>>>
>>> The check in check_unshare_flags is a little more complex. The
>>> incorrect check was added in
>>> cf2e340f4249b781b3d2beb41e891d08581f0e10 but I don't think it would
>>> have triggered under any supported combination of flags at that point.
>>>
>>> From 50804fe3737ca6a5942fdc2057a18a8141d00141 until
>>> 6e556ce209b09528dbf1931cbfd5d323e1345926, the bug affected
>>> unshare(CLONE_NEWPID).
>>
>> That's back to v3.8, so this goes quite a way, it seems.
>
> This patch was marked as CC' stable.  The question I am asking is this
> problem bad enough that backporting this change to stable makes sense?

I have no problem dropping the CC. At the time it seemed like a clear
bug fix appropriate for stable. If you feel differently, please remove
the CC. :)

-Kees

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

Re: [PATCH V4 (was V6)] audit: use macros for unset inode and device values

[Richard Guy Briggs]

On 15/08/05, William Roberts wrote:
> On Aug 1, 2015 12:44 PM, "Richard Guy Briggs"  wrote:
> >
> > Signed-off-by: Richard Guy Briggs 
> > ---
> >  include/uapi/linux/audit.h |2 ++
> >  kernel/audit.c |2 +-
> >  kernel/audit_watch.c   |8 
> >  kernel/auditsc.c   |6 +++---
> >  4 files changed, 10 insertions(+), 8 deletions(-)
> >
> > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> > index d3475e1..971df22 100644
> > --- a/include/uapi/linux/audit.h
> > +++ b/include/uapi/linux/audit.h
> > @@ -440,6 +440,8 @@ struct audit_tty_status {
> >  };
> >
> >  #define AUDIT_UID_UNSET (unsigned int)-1
> > +#define AUDIT_INO_UNSET (unsigned long)-1
> > +#define AUDIT_DEV_UNSET (unsigned)-1
> 
> Why unsigned int in one but unsigned in the other?

It was based on one of the instances it was originally replacing (I
can't find it now).  It could be dev_t if it was moved out of uapi as
Paul preferred, but I prefer unsigned int now that you point it out.

> >  /* audit_rule_data supports filter rules with both integer and string
> >   * fields.  It corresponds with AUDIT_ADD_RULE, AUDIT_DEL_RULE and
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 1c13e42..d546003 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -1761,7 +1761,7 @@ void audit_log_name(struct audit_context *context,
> struct audit_names *n,
> > } else
> > audit_log_format(ab, " name=(null)");
> >
> > -   if (n->ino != (unsigned long)-1)
> > +   if (n->ino != AUDIT_INO_UNSET)
> > audit_log_format(ab, " inode=%lu"
> >  " dev=%02x:%02x mode=%#ho"
> >  " ouid=%u ogid=%u rdev=%02x:%02x",
> > diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
> > index 8f123d7..c668bfc 100644
> > --- a/kernel/audit_watch.c
> > +++ b/kernel/audit_watch.c
> > @@ -138,7 +138,7 @@ char *audit_watch_path(struct audit_watch *watch)
> >
> >  int audit_watch_compare(struct audit_watch *watch, unsigned long ino,
> dev_t dev)
> >  {
> > -   return (watch->ino != (unsigned long)-1) &&
> > +   return (watch->ino != AUDIT_INO_UNSET) &&
> > (watch->ino == ino) &&
> > (watch->dev == dev);
> >  }
> > @@ -179,8 +179,8 @@ static struct audit_watch *audit_init_watch(char
> *path)
> > INIT_LIST_HEAD(&watch->rules);
> > atomic_set(&watch->count, 1);
> > watch->path = path;
> > -   watch->dev = (dev_t)-1;
> > -   watch->ino = (unsigned long)-1;
> > +   watch->dev = AUDIT_DEV_UNSET;
> > +   watch->ino = AUDIT_INO_UNSET;
> >
> > return watch;
> >  }
> > @@ -493,7 +493,7 @@ static int audit_watch_handle_event(struct
> fsnotify_group *group,
> > if (mask & (FS_CREATE|FS_MOVED_TO) && inode)
> > audit_update_watch(parent, dname, inode->i_sb->s_dev,
> inode->i_ino, 0);
> > else if (mask & (FS_DELETE|FS_MOVED_FROM))
> > -   audit_update_watch(parent, dname, (dev_t)-1, (unsigned
> long)-1, 1);
> > +   audit_update_watch(parent, dname, AUDIT_DEV_UNSET,
> AUDIT_INO_UNSET, 1);
> > else if (mask & (FS_DELETE_SELF|FS_UNMOUNT|FS_MOVE_SELF))
> > audit_remove_parent_watches(parent);
> >
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index 9fb9d1c..701ea5c 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -180,7 +180,7 @@ static int audit_match_filetype(struct audit_context
> *ctx, int val)
> > return 0;
> >
> > list_for_each_entry(n, &ctx->names_list, list) {
> > -   if ((n->ino != -1) &&
> > +   if ((n->ino != AUDIT_INO_UNSET) &&
> > ((n->mode & S_IFMT) == mode))
> > return 1;
> > }
> > @@ -1683,7 +1683,7 @@ static struct audit_names *audit_alloc_name(struct
> audit_context *context,
> > aname->should_free = true;
> > }
> >
> > -   aname->ino = (unsigned long)-1;
> > +   aname->ino = AUDIT_INO_UNSET;
> > aname->type = type;
> > list_add_tail(&aname->list, &context->names_list);
> >
> > @@ -1925,7 +1925,7 @@ void __audit_inode_child(const struct inode *parent,
> > if (inode)
> > audit_copy_inode(found_child, dentry, inode);
> > else
> > -   found_child->ino = (unsigned long)-1;
> > +   found_child->ino = AUDIT_INO_UNSET;
> >  }
> >  EXPORT_SYMBOL_GPL(__audit_inode_child);
> >
> > --
> > 1.7.1
> >
> > --
> > Linux-audit mailing list
> > linux-au...@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit

> --
> Linux-audit mailing list
> linux-au...@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit


- RGB

--
Richard Guy Briggs 
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red 
Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP

[Benjamin Tissoires]

On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:
> 
> 
> On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:
> >On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
> >>why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
> >>identify both lane count and reversal state without touching anything in the
> >>link training code. i am yet to upstream my changes for CHT that i can share
> >>if required that does the same in intel_dp_detect without touching any line
> >>in link training path.
> >With my current limited knowledge of the dp hotplug (and i915 driver) I
> >am not sure we could detect the reversed state without trying to train 1
> >lane only. I'd be glad to look at your changes and test them on my
> >system if you think that could help having a cleaner solution.
> >
> >Cheers,
> >Benjamin
> No, what i recommended was to do link training but in intel_dp_detect. Since
> USB Type C cable
> also has its own lane count restriction (it can have different lane count
> than the one supported
> by panel) you might have to figure that out as well. so both reversal and
> lane count detection
> can be done outside the modeset path and keep the code free of type C
> changes outside
> detection path.
> 
> Please find below the code to do the same. Do not waste time trying to apply
> this directly on
> nightly since this is based on a local tree and because this is pre- atomic
> changes code, so you
> might have to modify chv_upfront_link_train to work on top of the latest
> nightly code. we
> are supposed to upstream this and is in my todo list.
> 

[original patch snipped...]

Hi Sivakumar,

So I managed to manually re-apply your patch on top of
drm-intel-nightly, and tried to port it to make Broadwell working too.
It works OK if the system is already boot without any external DP used.
In this case, the detection works and I can see my external monitor
working properly.

However, if the monitor is cold plugged, the cpu/GPU hangs and I can not
understand why. I think I enabled all that is mentioned in the PRM to be
able to train the DP link, but I am obviously missing something else.
Can you have a look?

My patch is now:

>From 11e9c42f55ae27bd6e7b0168bf24d15082c7d517 Mon Sep 17 00:00:00 2001
From: Durgadoss R 
Date: Mon, 3 Aug 2015 11:51:16 -0400
Subject: [PATCH] drm/i915: Enable Upfront link training for type-C DP support

To support USB type C alternate DP mode, the display driver needs to know the
number of lanes required by DP panel as well as number of lanes that can be
supported by the type-C cable. Sometimes, the type-C cable may limit the
bandwidth even if Panel can support more lanes. To address these scenarios,
the display driver will start link training with max lanes, and if the link
training fails, the driver then falls back to x2 lanes.

* Since link training is done before modeset, planes are not enabled. Only
  encoder and the its associated PLLs are enabled.
* Once link training is done, the encoder and its PLLs are disabled; so that
  the subsequent modeset is not aware of these changes.
* As of now, this is tested only on CHV.

Signed-off-by: Durgadoss R 
[BT: add broadwell support and USB-C reverted state detection]
Signed-off-by: Benjamin Tissoires 
---
 drivers/gpu/drm/i915/intel_display.c | 163 +++
 drivers/gpu/drm/i915/intel_dp.c  |  22 -
 drivers/gpu/drm/i915/intel_drv.h |   7 ++
 3 files changed, 190 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 818f3a3..e8ddba0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15799,3 +15799,166 @@ void intel_modeset_preclose(struct drm_device *dev, 
struct drm_file *file)
spin_unlock_irq(&dev->event_lock);
}
 }
+
+static bool
+intel_upfront_link_train_config(struct drm_device *dev,
+   struct intel_dp *intel_dp,
+   struct intel_crtc *crtc,
+   uint8_t link_bw,
+   uint8_t lane_count)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_connector *connector = intel_dp->attached_connector;
+   struct intel_encoder *encoder = connector->encoder;
+   bool success;
+
+   intel_dp->link_bw = link_bw;
+   intel_dp->lane_count = lane_count;
+
+   /* Find port clock from link_bw */
+   crtc->config->port_clock = 
drm_dp_bw_code_to_link_rate(intel_dp->link_bw);
+
+   /* Enable PLL followed by port */
+   if (IS_BROADWELL(dev)) {
+   hsw_dp_set_ddi_pll_sel(crtc->config, intel_dp->link_bw);
+   if (intel_crtc_to_shared_dpll(crtc))
+   intel_enable_shared_dpll(crtc);
+
+   intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe, 
true);
+
+   } else if (IS_CHERRYVIEW(dev)) {
+   intel_dp

[PATCH] drm/msm/mdp: Clear pending interrupt status before enable interrupt

[Jilai Wang]

Pending interrupt status needs to be cleared before enable the
interrupt. Otherwise it's possible to get a pending interrupt instead
of an incoming interrupt.

Signed-off-by: Jilai Wang 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c | 10 +++---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h |  3 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 10 +++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |  3 ++-
 drivers/gpu/drm/msm/mdp/mdp_kms.c   |  3 ++-
 drivers/gpu/drm/msm/mdp/mdp_kms.h   |  4 +++-
 6 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c
index 7369ee7f..b6d491c 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c
@@ -19,8 +19,11 @@
 #include "msm_drv.h"
 #include "mdp4_kms.h"
 
-void mdp4_set_irqmask(struct mdp_kms *mdp_kms, uint32_t irqmask)
+void mdp4_set_irqmask(struct mdp_kms *mdp_kms, uint32_t irqmask,
+   uint32_t old_irqmask)
 {
+   mdp4_write(to_mdp5_kms(mdp_kms), REG_MDP4_INTR_CLEAR,
+   irqmask ^ (irqmask & old_irqmask));
mdp4_write(to_mdp4_kms(mdp_kms), REG_MDP4_INTR_ENABLE, irqmask);
 }
 
@@ -68,9 +71,10 @@ irqreturn_t mdp4_irq(struct msm_kms *kms)
struct drm_device *dev = mdp4_kms->dev;
struct msm_drm_private *priv = dev->dev_private;
unsigned int id;
-   uint32_t status;
+   uint32_t status, enable;
 
-   status = mdp4_read(mdp4_kms, REG_MDP4_INTR_STATUS);
+   enable = mdp4_read(mdp4_kms, REG_MDP4_INTR_ENABLE);
+   status = mdp4_read(mdp4_kms, REG_MDP4_INTR_STATUS) & enable;
mdp4_write(mdp4_kms, REG_MDP4_INTR_CLEAR, status);
 
VERB("status=%08x", status);
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
index 1aaedad..0cdf777 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
@@ -167,7 +167,8 @@ static inline uint32_t mixercfg(uint32_t mixer_cfg, int 
mixer,
 int mdp4_disable(struct mdp4_kms *mdp4_kms);
 int mdp4_enable(struct mdp4_kms *mdp4_kms);
 
-void mdp4_set_irqmask(struct mdp_kms *mdp_kms, uint32_t irqmask);
+void mdp4_set_irqmask(struct mdp_kms *mdp_kms, uint32_t irqmask,
+   uint32_t old_irqmask);
 void mdp4_irq_preinstall(struct msm_kms *kms);
 int mdp4_irq_postinstall(struct msm_kms *kms);
 void mdp4_irq_uninstall(struct msm_kms *kms);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
index 33bd4c6..7115043 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
@@ -21,8 +21,11 @@
 #include "msm_drv.h"
 #include "mdp5_kms.h"
 
-void mdp5_set_irqmask(struct mdp_kms *mdp_kms, uint32_t irqmask)
+void mdp5_set_irqmask(struct mdp_kms *mdp_kms, uint32_t irqmask,
+   uint32_t old_irqmask)
 {
+   mdp5_write(to_mdp5_kms(mdp_kms), REG_MDP5_MDP_INTR_CLEAR(0),
+   irqmask ^ (irqmask & old_irqmask));
mdp5_write(to_mdp5_kms(mdp_kms), REG_MDP5_MDP_INTR_EN(0), irqmask);
 }
 
@@ -71,9 +74,10 @@ static void mdp5_irq_mdp(struct mdp_kms *mdp_kms)
struct drm_device *dev = mdp5_kms->dev;
struct msm_drm_private *priv = dev->dev_private;
unsigned int id;
-   uint32_t status;
+   uint32_t status, enable;
 
-   status = mdp5_read(mdp5_kms, REG_MDP5_MDP_INTR_STATUS(0));
+   enable = mdp5_read(mdp5_kms, REG_MDP5_MDP_INTR_EN(0));
+   status = mdp5_read(mdp5_kms, REG_MDP5_MDP_INTR_STATUS(0)) & enable;
mdp5_write(mdp5_kms, REG_MDP5_MDP_INTR_CLEAR(0), status);
 
VERB("status=%08x", status);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
index 8542b30..403a6f5 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
@@ -186,7 +186,8 @@ static inline uint32_t lm2ppdone(int lm)
 int mdp5_disable(struct mdp5_kms *mdp5_kms);
 int mdp5_enable(struct mdp5_kms *mdp5_kms);
 
-void mdp5_set_irqmask(struct mdp_kms *mdp_kms, uint32_t irqmask);
+void mdp5_set_irqmask(struct mdp_kms *mdp_kms, uint32_t irqmask,
+   uint32_t old_irqmask);
 void mdp5_irq_preinstall(struct msm_kms *kms);
 int mdp5_irq_postinstall(struct msm_kms *kms);
 void mdp5_irq_uninstall(struct msm_kms *kms);
diff --git a/drivers/gpu/drm/msm/mdp/mdp_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp_kms.c
index 1988c24..6428730 100644
--- a/drivers/gpu/drm/msm/mdp/mdp_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp_kms.c
@@ -39,7 +39,8 @@ static void update_irq(struct mdp_kms *mdp_kms)
list_for_each_entry(irq, &mdp_kms->irq_list, node)
irqmask |= irq->irqmask;
 
-   mdp_kms->funcs->set_irqmask(mdp_kms, irqmask);
+   mdp_kms->funcs->set_irqmask(mdp_kms, irqmask, mdp_kms->cur_irq_mask);
+   mdp_kms->cur_irq_mask = irqmask;
 }
 
 /* if an mdp_irq's irqmask has changed, such as when mdp5 crtc<->encoder
diff --git 

[PATCH V6] audit: save signal match info in case entry passed in is the one deleted

[Richard Guy Briggs]

Move the access to the entry for audit_match_signal() to earlier in the
function in case the entry found is the same one passed in.  This will enable
it to be used by audit_remove_mark_rule().

Signed-off-by: Richard Guy Briggs 
---
Revision history:
v6:
Fix a rebase manual merge error that mixed parts of two patches.

v4 -> v5:
Move mutex_unlock after out label.
Move list_del group after test for signal to remove temp variable.

---
This patch was split out from the audit by executable path patch set due to the
potential to use it elsewhere.

In particular, some questions came up while assessing the potential for code
reuse:

Why does audit_remove_parent_watches() not call audit_del_rule() for
each entry found?
Is audit_signals not properly decremented?
Is audit_n_rules not properly decremented?

Why does kill_rules() not call audit_del_rule() for each entry found?
Is audit_signals not properly decremented?
Is audit_n_rules not properly decremented?
 kernel/auditfilter.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index 4cb9b44..018719a 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -953,7 +953,6 @@ static inline int audit_del_rule(struct audit_entry *entry)
mutex_lock(&audit_filter_mutex);
e = audit_find_rule(entry, &list);
if (!e) {
-   mutex_unlock(&audit_filter_mutex);
ret = -ENOENT;
goto out;
}
@@ -964,10 +963,6 @@ static inline int audit_del_rule(struct audit_entry *entry)
if (e->rule.tree)
audit_remove_tree_rule(&e->rule);
 
-   list_del_rcu(&e->list);
-   list_del(&e->rule.list);
-   call_rcu(&e->rcu, audit_free_rule_rcu);
-
 #ifdef CONFIG_AUDITSYSCALL
if (!dont_count)
audit_n_rules--;
@@ -975,9 +970,14 @@ static inline int audit_del_rule(struct audit_entry *entry)
if (!audit_match_signal(entry))
audit_signals--;
 #endif
-   mutex_unlock(&audit_filter_mutex);
+
+   list_del_rcu(&e->list);
+   list_del(&e->rule.list);
+   call_rcu(&e->rcu, audit_free_rule_rcu);
 
 out:
+   mutex_unlock(&audit_filter_mutex);
+
if (tree)
audit_put_tree(tree);   /* that's the temporary one */
 
-- 
1.7.1

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

Re: [PATCH 2/7] tty: core: Add tty_debug() for printk(KERN_DEBUG) messages

[Greg Kroah-Hartman]

On Wed, Aug 05, 2015 at 02:33:37PM -0400, Peter Hurley wrote:
> On 07/23/2015 09:35 PM, Greg Kroah-Hartman wrote:
> > On Sun, Jul 12, 2015 at 10:49:08PM -0400, Peter Hurley wrote:
> >> Introduce tty_debug() macro to output uniform debug information for
> >> tty core debug messages (function name and tty name).
> >>
> >> Note: printk(KERN_DEBUG) is retained here over pr_debug() since
> >> messages can be enabled in non-DEBUG builds.
> > 
> > But pr_debug() is the "standard" way to enable/disable debugging
> > messages, so I'd really like to see that be used here.
> 
> Ok, I can do that; I'll roll Joe's suggestions in at that time.
> 
> > Even better, this is a tty device, so it should be using dev_dbg(),
> > which gives us tons of good information built-in for the tty and can
> > properly be parsed by userspace tools to know exactly what device caused
> > what message at what point in time.
> > 
> > So I'll take this for now, but moving it to use dev_dbg() would be best
> > eventually.
> 
> The issue with using dev_dbg is that (SysV) ptys are not devices.

True :(

> However,
> if you'd prefer, I could rework this macro to format output like dev_dbg;
> ie.,  : 

That would be good, as that's what userspace is expecting the messages
to look like.

thanks,

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

Re: [PATCH V5] audit: save signal match info in case entry passed in is the one deleted

[Richard Guy Briggs]

On 15/08/05, Paul Moore wrote:
> On Wednesday, August 05, 2015 05:23:10 AM Richard Guy Briggs wrote:
> > Move the access to the entry for audit_match_signal() to the beginning of
> > the function in case the entry found is the same one passed in.  This will
> > enable it to be used by audit_remove_mark_rule().
> > 
> > Signed-off-by: Richard Guy Briggs 
> > 
> > Revision history:
> > v4 -> v5:
> > Move mutex_unlock after out label.
> > Move list_del group after test for signal to remove temp variable.
> > 
> > ---
> > This patch was split out from the audit by executable path patch set due to
> > the potential to use it elsewhere.
> > 
> > In particular, some questions came up while assessing the potential for code
> > reuse:
> > 
> > Why does audit_remove_parent_watches() not call audit_del_rule() for
> > each entry found?
> > Is audit_signals not properly decremented?
> > Is audit_n_rules not properly decremented?
> > 
> > Why does kill_rules() not call audit_del_rule() for each entry
> > found? Is audit_signals not properly decremented?
> > Is audit_n_rules not properly decremented?
> > 
> >  kernel/auditfilter.c |   13 -
> >  1 files changed, 8 insertions(+), 5 deletions(-)
> > 
> > diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
> > index 4cb9b44..1b110fb 100644
> > --- a/kernel/auditfilter.c
> > +++ b/kernel/auditfilter.c
> > @@ -953,7 +953,6 @@ static inline int audit_del_rule(struct audit_entry
> > *entry) mutex_lock(&audit_filter_mutex);
> > e = audit_find_rule(entry, &list);
> > if (!e) {
> > -   mutex_unlock(&audit_filter_mutex);
> > ret = -ENOENT;
> > goto out;
> > }
> > @@ -964,9 +963,8 @@ static inline int audit_del_rule(struct audit_entry
> > *entry) if (e->rule.tree)
> > audit_remove_tree_rule(&e->rule);
> > 
> > -   list_del_rcu(&e->list);
> > -   list_del(&e->rule.list);
> > -   call_rcu(&e->rcu, audit_free_rule_rcu);
> > +   if (e->rule.exe)
> > +   audit_remove_mark_rule(&e->rule);
> 
> What?

Wow, whoops!  I had to stare at it a while to see what was wrong...
Those last two lines belong in a different patch set...

> I think you munged a cut n' paste somehow.  This code doesn't even compile.

That was a local git tree rebase merge conflict manual fix error...

Not a bisect, but with the other patch set, it does.  :)
Re-generating audit-by-executable patchset too...

> >  #ifdef CONFIG_AUDITSYSCALL
> > if (!dont_count)
> > @@ -975,9 +973,14 @@ static inline int audit_del_rule(struct audit_entry
> > *entry) if (!audit_match_signal(entry))
> > audit_signals--;
> >  #endif
> > -   mutex_unlock(&audit_filter_mutex);
> > +
> > +   list_del_rcu(&e->list);
> > +   list_del(&e->rule.list);
> > +   call_rcu(&e->rcu, audit_free_rule_rcu);
> > 
> >  out:
> > +   mutex_unlock(&audit_filter_mutex);
> > +
> > if (tree)
> > audit_put_tree(tree);   /* that's the temporary one */
> 
> paul moore

- RGB

--
Richard Guy Briggs 
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red 
Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sb_edac: fix TAD presence check for sbridge_mci_bind_devs()

[Luck, Tony]

> In 7d375bff, NUM_CHANNELS was changed to 8 and the channel space was
> renumerated to handle EN, EP, and EX configurations.
>
> The *_mci_bind_devs functions, except for sbridge_mci_bind_devs(), got a
> new device presence check in the form of saw_chan_mask.  However,
> sbridge_mci_bind_devs() still uses the NUM_CHANNELS for loop.

> This patch adapts the saw_chan_mask logic for sbridge_mci_bind_devs() as
> well.

Oops. Sorry I missed that.  Looks good.

Acked-by: Tony Luck 

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

Re: [PATCH] tty: serial: men_z135_uart.c: Fix race between IRQ and set_termios()

[Peter Hurley]

On 08/05/2015 04:06 AM, Johannes Thumshirn wrote:
> Peter Hurley  writes:
> 
>> On 08/04/2015 03:02 AM, Johannes Thumshirn wrote:
>>> Peter Hurley  writes:
 On 08/03/2015 09:58 AM, Johannes Thumshirn wrote:
> Fix panic caused by a race between men_z135_intr() and 
> men_z135_set_termios().
>
> men_z135_intr() and men_z135_set_termios() both hold the struct 
> uart_port::lock
> spinlock, but men_z135_intr() does a spin_lock_irqsave() and
> men_z135_set_termios() does a normal spin_lock(), which can lead to a 
> deadlock
> when an interrupt is called while the lock is being helt by
> men_z135_set_termios().


 The irq handler can and should use normal spin_lock()/unlock().
>>>
>>> I always thought an irq handler _must_ use the irqsave versions. Good to
>>> know that.
>>
>> Your irq handler does not need to protect itself from re-entrancy (by using
>> the same irq handler for different irqs) and your serial driver doesn't 
>> support
>> console (so can't be deadlocked by printk() usage either).
>>
> 
> So once we have console support (I don't know if this is planned at
> all), we must go back to the irqsave variant?

Depends on if the platform for this hardware always disables irqs for interrupt
handlers. If it does, then the irqsave variant _in the interrupt handler_ is
not required.


> But looking at the driver
> again I have the feeling that the locking could be made more fine
> grained (if this makes sense) and I saw two possible races, please
> correct me if I'm wrong.
> 
> men_z135_intr() reads the status register and saves a copy in struct
> men_z135_port::stat_reg. The men_z135_handle_lsr() and
> men_z135_handle_modem_status() functions use this stat_reg value to get
> to the LSR and MSR registers. But in the meanwhile the content of the
> registers could have been changed by men_z135_intr() again. Is this a
> problem or am I on the wrong track here?

The irq handler itself can _never_ be re-entered (as long as the handler only
handles one irq # for a given device). So the race(s) outlined above can never
happen _regardless of which flavor spinlock is used_.

Regards,
Peter Hurley


 The set_termios() method should used spin_lock_irq(); there's no need to 
 save the
 interrupt state because that method will never be called from interrupt 
 context.

 So the 'flags' local can be dropped from the patch.
>>>
>>> Given that the irqsave variant isn't needed that sounds reasonable.
>>
>> It's for a different reason; irqs will _always_ be on when your driver's
>> set_termios() method is called. So you don't see to save the irq state, 
>> because
>> you know it's always on. That's why you can use the 
>> spin_lock_irq()/spin_unlock_irq()
>> version here.
>>
 Also, the port lock is already initialized in uart_add_one_port() and 
 should
 not be initialized by the probe() function.
>>>
>>> OK, do you prefer (or better Greg and Jiri) prefer that change folded
>>> into this patch or an extra patch?
>>
>> Separate patch please.
> 
> OK.
> 
>>
>> I assume this deadlock fix will need to be pushed to -stable as well,
>> yes?
> 
> I wasn't quite sure about this, I 1st had a CC stable for v4.0+ but
> then removed it again before sending the patch. So I'll put it back in.
> 
> Thanks,
> Johannes
> 

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

Re: [PATCH V4 (was V6)] audit: use macros for unset inode and device values

[Paul Moore]

On Wednesday, August 05, 2015 02:30:14 AM Richard Guy Briggs wrote:
> On 15/08/04, Paul Moore wrote:
> > On Saturday, August 01, 2015 03:42:23 PM Richard Guy Briggs wrote:
> > > Signed-off-by: Richard Guy Briggs 
> > > ---
> > > 
> > >  include/uapi/linux/audit.h |2 ++
> > >  kernel/audit.c |2 +-
> > >  kernel/audit_watch.c   |8 
> > >  kernel/auditsc.c   |6 +++---
> > >  4 files changed, 10 insertions(+), 8 deletions(-)
> > 
> > Yipee, less magic numbers!
> > 
> > However, one question for you ... are we ever going to see a device or
> > inode set to -1 in the userspace facing API?  In other words, should the
> > new #defines go in the uapi headers or simply in kernel/audit.h?  Unless
> > it is part of the API, let's leave it out of uapi as we have to be very
> > careful about that stuff and I'd prefer to keep it minimal.
> 
> This is a good point.  I did briefly thing about this at one point.
> Perhaps Steve can answer this.  It would be trivial to move it back to
> uapi if needed.  Would you be ok with it in include/linux/audit.h for
> now?

I have no problem with it in include/linux/audit.h, that is a kernel-only 
include that we can change at anytime.  My concern is putting it into a uapi 
header which makes it very hard to change.

I'm thinking we should just go ahead and put it in include/linux/audit.h for 
now as I can't think of a reason why userspace should be passing in an invalid 
dev/inode value, it just doesn't make sense.  If the invalid tokens prove to 
be valuable for userspace, we can always move the #defines.

-- 
paul moore
security @ redhat

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] i2c: pxa: Add ILCR (tLow & tHigh) configuration support

[Robert Jarzmik]

Vaibhav Hiremath  writes:

> Robert,
>
> It would be helpful if you can test this patch-series and confirm that
> it now fixes the NULL pointer deference issue.
>
> Thanks,
> Vaibhav
Hi Vaibhav,

My next slot is probably this comming Sunday. I'll do the test and report.

Cheers.

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

Re: [PATCH 3/4] arm64: Juno: Add HDLCD support to the Juno boards.

[Liviu Dudau]

On Wed, Aug 05, 2015 at 06:53:03PM +0100, Russell King - ARM Linux wrote:
> On Wed, Aug 05, 2015 at 03:28:11PM +0100, Liviu Dudau wrote:
> > +   hdmi-transmitter@71 {
> > compatible = "nxp,tda998x";
> > reg = <0x71>;
> > +   port {
> > +   tda998x_1_input: endpoint@0 {
> > +   remote-endpoint = <&hdlcd1_output>;
> > +   };
> > +
> > +   tda998x_1_output: endpoint@1 {
> > +   remote-endpoint = 
> > <&hdmi1_connector_output>;
> > +   };
> > +   };

Hi Russell,

Thanks for reviewing this, I will integrate your comments in the
next revision.

> 
> This isn't compliant with the TDA998x binding, and is very likely to
> screw Jean's work on adding audio support.  See emails on lakml and
> Documentation/devicetree/bindings/drm/i2c/tda998x.txt (which looks
> like it needs updating to include the ports stuff.)

I have to confess that I am not entirely up to speed with the TDA19988
situation at the moment. Andrew Jackson was dealing with that and
working with Jean to get that in the upstream, but his contract has
ended and he has moved to other things. While I did get through a
(limited) set of patches that Jean has sent around, I'm a bit confused
about the latest state of play. Is there an authoritative source from
where I can grab the patches that are going to be in 4.3? Otherwise,
as far as the current patchset base (4.2-rc2) is concerned, I am
compliant with the bindings if you ignore the port subnode (see further
below). I am happy to update the patchset to match what is going into
mainline, but just reading the emails in the mailing list I'm not
exactly sure on the sequencing of things here.

> 
> Also, the whole question of representing connectors in a DRM model is
> yet to be established.  Yes, DT should describe the hardware, but we
> don't yet know _how_ to describe physical connectors with stuff
> implemented on top of DRM yet, and we have nothing that makes use of
> this.

Please help me understand the current situation: you have added
support for components that the video drivers can use and the bindings
for that are described in 
Documentation/devicetree/bindings/media/video-interfaces.txt.
According to that document my patch should be compliant once I add the
reg= property. Is that something that cannot be used with tda998x driver
or is there any other reason why you think the patch is not compliant?

If you are referring to connecting an encoder with a HDMI connector, I
have tested that and it seems to work, although my situation is simple
because there are no options in my setup: one HDLCD connects to one TDA19988
which connects to one HDMI output.

> 
> Also note that ePAPR requires a reg= property if you specify a
> unit-address (the bit after the @ sign) so the above is non-compliant
> with ePAPR as well.

Thanks, I will add the reg property.

Best regards,
Liviu

> 
> -- 
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

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

Re: [PATCHv2] serial: don't register CIR serial ports

[Peter Hurley]

On 08/05/2015 11:43 AM, Maciej S. Szmigiero wrote:
> CIR type serial ports aren't real serial ports.
> 
> This is just a way to prevent legacy 8250 serial
> driver from probing and eventually binding some
> resources.
> 
> Since in current state such ports aren't providing
> any real functionality and it is not possible
> to change their type via setserial/ioctl(TIOCSSERIAL)
> (due to UPF_FIXED_PORT flag set on them)
> it is simpler and cleaner to not register them at all
> with serial core.


The only thing I think this patch is missing is either a comment
or specific code in serial8250_register_ports() regarding not
adding PORT_8250_CIR-type ports.

Like either:

static void __init
serial8250_register_ports(struct uart_driver *drv, struct device *dev)
{
int i;

for (i = 0; i < nr_uarts; i++) {
struct uart_8250_port *up = &serial8250_ports[i];

+   /* PORT_8250_CIR-type ports must have non-NULL dev */
if (up->port.dev)
continue;

up->port.dev = dev;

or:

static void __init
serial8250_register_ports(struct uart_driver *drv, struct device *dev)
{
int i;

for (i = 0; i < nr_uarts; i++) {
struct uart_8250_port *up = &serial8250_ports[i];

+   if (up->port.type == PORT_8250_CIR)
+   continue;

if (up->port.dev)
continue;

up->port.dev = dev;

Regards,
Peter Hurley

> Print a short message in this case so it is known
> to user what has happened.
> 
> This way checks for PORT_8250_CIR in serial port
> callbacks can be removed too, since they won't
> ever be called.
> 
> Signed-off-by: Maciej Szmigiero 
> ---
> This replaces "serial: don't announce CIR serial ports"
> submission.
> 
> Changes from v1: print message using dev_info()
> 
>  drivers/tty/serial/8250/8250_core.c |   37 
> +--
>  1 files changed, 18 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_core.c 
> b/drivers/tty/serial/8250/8250_core.c
> index 37fff12..145b0b37 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -2129,9 +2129,6 @@ int serial8250_do_startup(struct uart_port *port)
>   unsigned char lsr, iir;
>   int retval;
>  
> - if (port->type == PORT_8250_CIR)
> - return -ENODEV;
> -
>   if (!port->fifosize)
>   port->fifosize = uart_config[port->type].fifo_size;
>   if (!up->tx_loadsz)
> @@ -2858,14 +2855,8 @@ static void serial8250_release_port(struct uart_port 
> *port)
>  static int serial8250_request_port(struct uart_port *port)
>  {
>   struct uart_8250_port *up = up_to_u8250p(port);
> - int ret;
> -
> - if (port->type == PORT_8250_CIR)
> - return -ENODEV;
> -
> - ret = serial8250_request_std_resource(up);
>  
> - return ret;
> + return serial8250_request_std_resource(up);
>  }
>  
>  static int fcr_get_rxtrig_bytes(struct uart_8250_port *up)
> @@ -3013,9 +3004,6 @@ static void serial8250_config_port(struct uart_port 
> *port, int flags)
>   struct uart_8250_port *up = up_to_u8250p(port);
>   int ret;
>  
> - if (port->type == PORT_8250_CIR)
> - return;
> -
>   /*
>* Find the region that we can probe for.  This in turn
>* tells us whether we can probe for the type of port.
> @@ -3889,13 +3877,24 @@ int serial8250_register_8250_port(struct 
> uart_8250_port *up)
>   if (up->dl_write)
>   uart->dl_write = up->dl_write;
>  
> - if (serial8250_isa_config != NULL)
> - serial8250_isa_config(0, &uart->port,
> - &uart->capabilities);
> + if (uart->port.type != PORT_8250_CIR) {
> + if (serial8250_isa_config != NULL)
> + serial8250_isa_config(0, &uart->port,
> + &uart->capabilities);
>  
> - ret = uart_add_one_port(&serial8250_reg, &uart->port);
> - if (ret == 0)
> - ret = uart->port.line;
> + ret = uart_add_one_port(&serial8250_reg,
> + &uart->port);
> + if (ret == 0)
> + ret = uart->port.line;
> + } else {
> + dev_info(uart->port.dev,
> + "skipping CIR port at 0x%lx / 0x%llx, IRQ %d\n",
> + uart->port.iobase,
> + (unsigned long long)uart->port.mapbase,
> + uart->port.irq);
> +
> + ret = 0;
> + }
>   }
>   mutex_unlock(&serial_mutex);
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.

[PATCH] Input: elan_i2c - enable asynchronous probing

[Dmitry Torokhov]

It takes a bit of time to go through controller power up sequence and
initialization. To not stall the overall boot progress let's probe the
controller asynchronously, given that userspace is usually prepared for
hot-plugging of input devices and thus does not rely on particular
ordering.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/mouse/elan_i2c_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/mouse/elan_i2c_core.c 
b/drivers/input/mouse/elan_i2c_core.c
index 0a076d3..67388f4 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -1185,6 +1185,7 @@ static struct i2c_driver elan_driver = {
.pm = &elan_pm_ops,
.acpi_match_table = ACPI_PTR(elan_acpi_id),
.of_match_table = of_match_ptr(elan_of_match),
+   .probe_type = PROBE_PREFER_ASYNCHRONOUS,
},
.probe  = elan_probe,
.id_table   = elan_id,
-- 
2.5.0.rc2.392.g76e840b


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

Re: [PATCH] staging: sm750fb: fix sparse warning for lock

[Greg KH]

On Wed, Aug 05, 2015 at 09:26:44PM +0800, Peng Fan wrote:
> Use __acquire() and __release() in the right place to silence the sparse
> lock checking warning.
> 
> drivers/staging/sm750fb/sm750.c:177:13: warning: context imbalance in 
> 'lynxfb_ops_fillrect' - different lock contexts for basic block
> drivers/staging/sm750fb/sm750.c:243:9: warning: context imbalance in 
> 'lynxfb_ops_copyarea' - different lock contexts for basic block
> drivers/staging/sm750fb/sm750.c:247:13: warning: context imbalance in 
> 'lynxfb_ops_imageblit' - different lock contexts for basic block
> 
> Signed-off-by: Peng Fan 
> Cc: Sudip Mukherjee 
> Cc: Teddy Wang 
> Cc: Greg Kroah-Hartman 
> ---
>  drivers/staging/sm750fb/sm750.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index 8e201f1..5ba1c06 100644
> --- a/drivers/staging/sm750fb/sm750.c
> +++ b/drivers/staging/sm750fb/sm750.c
> @@ -203,6 +203,8 @@ static void lynxfb_ops_fillrect(struct fb_info *info,
>*/
>   if (share->dual)
>   spin_lock(&share->slock);
> + else
> + __acquire(&share->slock);

That's horrid, please don't do stuff like this just to make a static
checker "quiet".

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

Re: [PATCH 0/8] watchdog: Add support for keepalives triggered by infrastructure

[Guenter Roeck]

Hi David,

On 08/05/2015 10:51 AM, David Teigland wrote:

On Wed, Aug 05, 2015 at 10:41:51AM -0700, Guenter Roeck wrote:

Not really. The heartbeats will be generated such that the watchdog expires
no later that . I discussed
this already with Uwe; he had the same concern. This isn't in the current
version of the patch set, but it will be in the next version. That means
that nothing will change from user space perspective.


Sounds good, thanks.


A related issue from some years ago is the unfortunate fact that closing
the watchdog device also generates a heartbeat.  I'd like to disable that
also, and submitted a patch for it here:
http://www.spinics.net/lists/linux-watchdog/msg01477.html



That is a different issue, though, and unrelated to this patch set.
Wim had a good point there: Presumably the problem you are trying to solve
applies to the entire system, not to a specific watchdog. What you are looking
for looks more like a system parameter, not like something to set with an ioctl
message. The reason here is that you'd still want to be able to use standard
applications such as systemd or watchdogd to trigger heartbeats, and not depend
on your own.


I'd need this behavior when the system is running my program (sanlock with
wdmd), which uses /dev/watchdog.  No other programs (systemd or watchdogd)
could be using /dev/watchdog at the same time.



I think I can understand why Wim was reluctant to accept your patch;
I must admit I don't understand your use case either.

I wonder if you are actually mis-using the watchdog subsystem to generate
hard resets. After all, you could avoid the unexpected close situation with
an exit handler in your application. That handler could catch anything but
SIGKILL, but anyone using SIGKILL doesn't really deserve better. If the intent
is to reset the system after the application closes, executing "/sbin/restart 
-f"
might be a safer approach than just killing the watchdog.

In addition to that, I don't think it is a good idea to rely on the assumption
that the watchdog will expire exactly after the configured timeout.
Many watchdog drivers implement a soft timeout on top of the hardware timeout,
and thus already implement the internal heartbeat. Most of those drivers
will stop sending internal heartbeats if user space did not send a heartbeat
within the configured timeout period. The actual reset will then occur later,
after the actual hardware watchdog timed out. This can be as much as the
hardware timeout period, which may be substantial.

Thanks,
Guenter

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

Re: [PATCH] user_ns: use correct check for single-threadedness

[Eric W. Biederman]

Hmm.

On closer inspection this patch touches on a greater inconsistency then
the test to see if the task is the only task using the mm_struct.

We currently allow tasks created with clone to have a different user
namespace and to share a mm_struct, and I don't think that is wrong.

What we actually care about are the uid and gid values that show up in
signals that are reported to a process, and for that what we care about
is the question do the tasks share signal handling state, which is
controlled by the flags CLONE_SIGHAND and CLONE_THREAD.

As such current_is_single_threaded() is wrong because it tests to see if
there is someone else sharing an mm_struct.

So I have to ask.  Is it possible to rework these checks such that we
look at the sighand struct and signal sharing handling sharing instead
of the count on the mm_struct?

I suspect we could do that more cheaply, as well as making the code more
correct.

Eric

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

Re: [PATCH 02/27] ASN.1: Copy string names to tokens in ASN.1 compiler [ver #7]

[Mimi Zohar]

On Wed, 2015-08-05 at 19:26 +0100, David Howells wrote:
> Mimi Zohar  wrote:
> 
> > This patch isn't applying properly against linux-security/next.  The
> > rest seem to be fine.
> 
> Did you apply the asn1-fixes-20150805 first and patch 1?
> 
> Note that the branch is based on security/next, with my asn1-fixes-20150805
> tag merged on top - so it *ought* to apply.

Yes, that works.

Thanks!

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Input: elants_i2c - wire up regulator support

[Dmitry Torokhov]

Elan touchscreen controllers use two power supplies, vcc33 and vccio,
and we need to enable them before trying to access the device. On X86
firmware usually does this, but on ARM it is usually left to the kernel.

Signed-off-by: Dmitry Torokhov 
Reviewed-by: Benson Leung 
Signed-off-by: Dmitry Torokhov 
---
 .../devicetree/bindings/input/elants_i2c.txt   |   3 +
 drivers/input/touchscreen/elants_i2c.c | 184 ++---
 2 files changed, 165 insertions(+), 22 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/elants_i2c.txt 
b/Documentation/devicetree/bindings/input/elants_i2c.txt
index a765232..8a71038 100644
--- a/Documentation/devicetree/bindings/input/elants_i2c.txt
+++ b/Documentation/devicetree/bindings/input/elants_i2c.txt
@@ -13,6 +13,9 @@ Optional properties:
 - pinctrl-names: should be "default" (see pinctrl binding [1]).
 - pinctrl-0: a phandle pointing to the pin settings for the device (see
   pinctrl binding [1]).
+- reset-gpios: reset gpio the chip is connected to.
+- vcc33-supply: a phandle for the regulator supplying 3.3V power.
+- vccio-supply: a phandle for the regulator supplying IO power.
 
 [0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 [1]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
diff --git a/drivers/input/touchscreen/elants_i2c.c 
b/drivers/input/touchscreen/elants_i2c.c
index 42e43f1..1912265 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -38,6 +38,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 /* Device, Driver information */
@@ -102,6 +104,9 @@
 /* calibration timeout definition */
 #define ELAN_CALI_TIMEOUT_MSEC 1
 
+#define ELAN_POWERON_DELAY_USEC500
+#define ELAN_RESET_DELAY_MSEC  20
+
 enum elants_state {
ELAN_STATE_NORMAL,
ELAN_WAIT_QUEUE_HEADER,
@@ -118,6 +123,10 @@ struct elants_data {
struct i2c_client *client;
struct input_dev *input;
 
+   struct regulator *vcc33;
+   struct regulator *vccio;
+   struct gpio_desc *reset_gpio;
+
u16 fw_version;
u8 test_version;
u8 solution_version;
@@ -141,6 +150,7 @@ struct elants_data {
u8 buf[MAX_PACKET_SIZE];
 
bool wake_irq_enabled;
+   bool keep_power_in_suspend;
 };
 
 static int elants_i2c_send(struct i2c_client *client,
@@ -1058,6 +1068,67 @@ static void elants_i2c_remove_sysfs_group(void *_data)
sysfs_remove_group(&ts->client->dev.kobj, &elants_attribute_group);
 }
 
+static int elants_i2c_power_on(struct elants_data *ts)
+{
+   int error;
+
+   /*
+* If we do not have reset gpio assume platform firmware
+* controls regulators and does power them on for us.
+*/
+   if (IS_ERR_OR_NULL(ts->reset_gpio))
+   return 0;
+
+   gpiod_set_value_cansleep(ts->reset_gpio, 1);
+
+   error = regulator_enable(ts->vcc33);
+   if (error) {
+   dev_err(&ts->client->dev,
+   "failed to enable vcc33 regulator: %d\n",
+   error);
+   goto release_reset_gpio;
+   }
+
+   error = regulator_enable(ts->vccio);
+   if (error) {
+   dev_err(&ts->client->dev,
+   "failed to enable vccio regulator: %d\n",
+   error);
+   regulator_disable(ts->vcc33);
+   goto release_reset_gpio;
+   }
+
+   /*
+* We need to wait a bit after powering on controller before
+* we are allowed to release reset GPIO.
+*/
+   udelay(ELAN_POWERON_DELAY_USEC);
+
+release_reset_gpio:
+   gpiod_set_value_cansleep(ts->reset_gpio, 0);
+   if (error)
+   return error;
+
+   msleep(ELAN_RESET_DELAY_MSEC);
+
+   return 0;
+}
+
+static void elants_i2c_power_off(void *_data)
+{
+   struct elants_data *ts = _data;
+
+   if (!IS_ERR_OR_NULL(ts->reset_gpio)) {
+   /*
+* Activate reset gpio to prevent leakage through the
+* pin once we shut off power to the controller.
+*/
+   gpiod_set_value_cansleep(ts->reset_gpio, 1);
+   regulator_disable(ts->vccio);
+   regulator_disable(ts->vcc33);
+   }
+}
+
 static int elants_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
 {
@@ -1072,13 +1143,6 @@ static int elants_i2c_probe(struct i2c_client *client,
return -ENXIO;
}
 
-   /* Make sure there is something at this address */
-   if (i2c_smbus_xfer(client->adapter, client->addr, 0,
-   I2C_SMBUS_READ, 0, I2C_SMBUS_BYTE, &dummy) < 0) {
-   dev_err(&client->dev, "nothing at this address\n");
-   return -ENXIO;
-   }
-
ts = devm_kzalloc(&client->dev, sizeof(struct elants_data), GFP_KERNEL);
if (!ts)
  

[PATCH] Input: elants_i2c - enable asynchronous probing

[Dmitry Torokhov]

It takes a bit of time to go through controller power up sequence and
initialization. To not stall the overall boot progress let's probe the
controller asynchronously, given that userspace is usually prepared for
hot-plugging of input devices and thus does not rely on particular
ordering.

Signed-off-by: Dmitry Torokhov 
Reviewed-by: Benson Leung 
Signed-off-by: Dmitry Torokhov 
---
 drivers/input/touchscreen/elants_i2c.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/touchscreen/elants_i2c.c 
b/drivers/input/touchscreen/elants_i2c.c
index 1912265..6f71556 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -1410,6 +1410,7 @@ static struct i2c_driver elants_i2c_driver = {
.pm = &elants_i2c_pm_ops,
.acpi_match_table = ACPI_PTR(elants_acpi_id),
.of_match_table = of_match_ptr(elants_of_match),
+   .probe_type = PROBE_PREFER_ASYNCHRONOUS,
},
 };
 module_i2c_driver(elants_i2c_driver);
-- 
2.5.0.rc2.392.g76e840b


-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging: android: lowmemorykiller: imporve lmk to avoid deadlock issue

[gre...@linuxfoundation.org]

On Mon, Aug 03, 2015 at 08:26:40AM +, Wang, Biao wrote:
> Consider the following case:
> Task A trigger lmk with a lock held, while task B try to get this lock, but 
> unfortunately B is the very culprit task lmk select to kill. Then B will 
> never be killed, and A will forever select B to kill.
> Such dead lock will trigger softlock up issue.
> 
> This patch try to pick the next task to break this loop.
> 
> Signed-off-by: Wang Biao 
> Reviewed-by: Zhang Di 
> ---
>  drivers/staging/android/lowmemorykiller.c |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

Please address Dave's review comments, I'll not take this as-is, sorry.

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

Re: [PATCH] thermal: remove power allocator from list of default governors

[Eduardo Valentin]

On Wed, Aug 05, 2015 at 09:35:39AM -0700, Dmitry Torokhov wrote:
> On Wed, Aug 05, 2015 at 09:37:55AM +0100, Javi Merino wrote:
> > On Tue, Aug 04, 2015 at 05:39:21PM +0100, Dmitry Torokhov wrote:
> > > As it currently stands the power allocator governor can not handle
> > > thermal zones that are not specifically crafted and therefore can not be
> > > used as a default governor.
> > > 
> > > Users need to explicitly enable this governor for thermal zones that do
> > > have enough information for its operation.
> > > 
> > > Signed-off-by: Dmitry Torokhov 
> > > ---
> > >  drivers/thermal/Kconfig | 8 
> > >  1 file changed, 8 deletions(-)
> > > 
> > > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> > > index 0390044..34d05d3 100644
> > > --- a/drivers/thermal/Kconfig
> > > +++ b/drivers/thermal/Kconfig
> > > @@ -82,14 +82,6 @@ config THERMAL_DEFAULT_GOV_USER_SPACE
> > > Select this if you want to let the user space manage the
> > > platform thermals.
> > >  
> > > -config THERMAL_DEFAULT_GOV_POWER_ALLOCATOR
> > > - bool "power_allocator"
> > > - select THERMAL_GOV_POWER_ALLOCATOR
> > > - help
> > > -   Select this if you want to control temperature based on
> > > -   system and device power allocation. This governor can only
> > > -   operate on cooling devices that implement the power API.
> > > -
> > 
> > Currently the only way we have for a thermal zone configured from
> > device tree to use a governor from the kernel boot is by using
> > THERMAL_DEFAULT_GOV_*.  If we remove this option some devices won't
> > have a workable thermal framework until userspace is up and running.
> 
> Why would step wise, or fair share be not workable (even if not optimal)
> thermal frameworks? It doe snot take that long to get to [early]
> userspace. Half of the boot time the thermal framework is not working
> anyway because half of the devices that can act as colling devices are
> not yet logically there.
> 
> > 
> > Would you rather have the power allocator governor accept every
> > thermal zone?
> 
> If it is to be one of default governors then yes, it needs to be able to
> manage all thermal zones, the same way as the other 3 governors can, as
> far as I know.

I believe fairshare also relies on platform data to be properly set,
otherwise, it would not be functional. That's probably why I overlooked
this point. That said, I would say, if we follow this logic, a similar
patch is needed for fairshare.

Javi, ideally, the governor would need to have a workable
default settings for any thermal zone that miss the platform settings.
Do you think it would be doable for power allocator?

BR,

> 
> Thanks.
> 
> -- 
> Dmitry


signature.asc
Description: Digital signature

Re: [PATCH] thermal: power_allocator: do not use devm* interfaces

[Eduardo Valentin]

On Wed, Aug 05, 2015 at 06:29:03PM +0100, Javi Merino wrote:
> On Wed, Aug 05, 2015 at 05:50:20PM +0100, Dmitry Torokhov wrote:
> > On Wed, Aug 05, 2015 at 09:29:11AM +0100, Javi Merino wrote:
> > > On Tue, Aug 04, 2015 at 05:33:40PM +0100, Dmitry Torokhov wrote:
> > > > The code in question is called outside of standard driver
> > > > probe()/remove() callbacks and thus will not benefit from use of devm*
> > > > infrastructure.
> > > > 
> > > > Signed-off-by: Dmitry Torokhov 
> > > 
> > > We added the devm* calls because Eduardo asked for them in the review.
> > > I don't have a strong opinion regarding this, I'll leave the decision
> > > to Eduardo.
> > 
> > I tried to look for his reasons, if any, but even in earliest posted
> > versions use devm* for allocating memory
> 
> http://thread.gmane.org/gmane.linux.power-management.general/45000/focus=45265
> http://thread.gmane.org/gmane.linux.power-management.general/46064/focus=1722858
> 
> He didn't give reasons and I didn't ask for them.  He insisted on it so I 
> just added
> it across the board.

Yeah, that's my bad.

I believe I had in mind getting the thermal core in a better shape by
having proper driver/device matching. But still, looking at the code
now, I must agree with Dmitry. As of now, it does not make sense.


BR,

Eduardo

> 
> Cheers,
> Javi


signature.asc
Description: Digital signature

Re: [PATCH v3 0/5] Add SMP bringup support for mt65xx socs

[Matthias Brugger]

On Tuesday, July 14, 2015 01:18:26 PM Yingjoe Chen wrote:
> This series add SMP brinup support for MediaTek SoCs. This is based
> on v4.2-rc1 and Matthias' next branch (for dts parts).
> 
> There are similar but different SMP bringup up methods on MediaTek
> mt65xx and mt81xx. On MT8135 & MT8127, system boots with a trustzone
> firmware. Others, like MT6589, doesn't have trustzone, and run kernel
> directly in secure world.
> 
> Patch 1 enable arch timer support.
> Patch 2,3 add support for cpu enable-method "mediatek,mt6589-smp" and
> "mediatek,mt81xx-tz-smp", which support Mediatek SMP bringup for non-TZ
> and TZ platform.
> Patch 4,5 finally enable SMP bringup for mt8135 and mt8127.
> 
> Changes in v3:
> - The first 2 patches in v2 are merged in v4.2-rc1.
> - Patch 3~4 in v2 are moved to another series [1]
> - platsmp.c changes based on Stephen's suggestion
> - Change cpu enable-method name to "mediatek,mt6589-smp"
> 
> Changes in v2:
> - Fix boot issue for THUMB2 kernel.
> - Not enable GPT_CLK_EVT when setup to fix GPT spurious interrupt issue
> - Change platsmp.c according to Matthias' suggestion
> http://lists.infradead.org/pipermail/linux-mediatek/2015-May/000714.html
> 
> v1:
> http://lists.infradead.org/pipermail/linux-mediatek/2015-May/000528.html
> 
> [1]
> http://lists.infradead.org/pipermail/linux-mediatek/2015-July/001544.html
> 
> Matthias Brugger (1):
>   ARM: mediatek: enable gpt6 on boot up to make arch timer working
> 
> Yingjoe Chen (4):
>   devicetree: bindings: add new SMP enable method Mediatek SoC
>   ARM: mediatek: add smp bringup code
>   ARM: dts: mt8135: enable basic SMP bringup for mt8135
>   ARM: dts: mt8127: enable basic SMP bringup for mt8127
> 
>  Documentation/devicetree/bindings/arm/cpus.txt |   2 +
>  arch/arm/boot/dts/mt8127.dtsi  |  16 +++
>  arch/arm/boot/dts/mt8135.dtsi  |  16 +++
>  arch/arm/mach-mediatek/Makefile|   3 +
>  arch/arm/mach-mediatek/mediatek.c  |  27 +
>  arch/arm/mach-mediatek/platsmp.c   | 144
> + 6 files changed, 208 insertions(+)
>  create mode 100644 arch/arm/mach-mediatek/platsmp.c

Applied to v4.2-next/soc-2 and v4.2-next/dts-2 

Thanks,
Matthias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.

[vikasm]

Hi Graham,

On 07/28/2015 10:38 AM, Graham Moore wrote:
> Signed-off-by: Graham Moore 
> ---
> V2: use NULL instead of modalias in spi_nor_scan call
> V3: Use existing property is-decoded-cs instead of creating duplicate.
> V4: Support Micron quad mode by snooping command stream for EVCR command
> and subsequently configuring Cadence controller for quad mode.
> V5: Clean up sparse and smatch complaints.  Remove snooping of Micron
> quad mode.  Add comment on XIP mode bit and dummy clock cycles.  Set
> up SRAM partition at 1:1 during init.
> V6: Remove dts patch that was included by mistake.  Incorporate Vikas's
> comments regarding fifo width, SRAM partition setting, and trigger
> address.  Trigger address was added as an unsigned int, as it is not
> an IO resource per se, and does not need to be mapped. Also add
> Marek Vasut's workaround for picking up OF properties on subnodes.

I am still not able to apply this patch to master. It seems to be rebased on 
master for ..spi-nor/Kconfig & spi-nor/makefile.
Also I still see spaces are still not replaced by tabs in this version.

> ---
>  drivers/mtd/spi-nor/Kconfig   |6 +
>  drivers/mtd/spi-nor/Makefile  |1 +
>  drivers/mtd/spi-nor/cadence-quadspi.c | 1276 
> +
>  3 files changed, 1283 insertions(+)
>  create mode 100644 drivers/mtd/spi-nor/cadence-quadspi.c
>
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index 64a4f0e..9485481 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -28,4 +28,10 @@ config SPI_FSL_QUADSPI
>   This enables support for the Quad SPI controller in master mode.
>   We only connect the NOR to this controller now.
>
> +config SPI_CADENCE_QUADSPI
> +   tristate "Cadence Quad SPI controller"
> +   depends on ARCH_SOCFPGA
> +   help
> + This enables support for the Cadence Quad SPI controller and NOR 
> flash.
> +
>  endif # MTD_SPI_NOR
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> index 6a7ce14..372628c 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -1,2 +1,3 @@
>  obj-$(CONFIG_MTD_SPI_NOR)  += spi-nor.o
> +obj-$(CONFIG_SPI_CADENCE_QUADSPI)  += cadence-quadspi.o
>  obj-$(CONFIG_SPI_FSL_QUADSPI)  += fsl-quadspi.o
> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
> b/drivers/mtd/spi-nor/cadence-quadspi.c
> new file mode 100644
> index 000..076e9c9
> --- /dev/null
> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
> @@ -0,0 +1,1276 @@
> +/*
> + * Driver for Cadence QSPI Controller
> + *
> + * Copyright Altera Corporation (C) 2012-2014. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define CQSPI_NAME "cadence-qspi"
> +#define CQSPI_MAX_CHIPSELECT   16
> +
> +struct cqspi_flash_pdata {
> +   struct mtd_info mtd;
> +   struct spi_nor nor;
> +   u32 clk_rate;
> +   unsigned int read_delay;
> +   unsigned int tshsl_ns;
> +   unsigned int tsd2d_ns;
> +   unsigned int tchsh_ns;
> +   unsigned int tslch_ns;
> +};
> +
> +struct cqspi_st {
> +   struct platform_device *pdev;
> +
> +   struct clk *clk;
> +   unsigned int sclk;
> +
> +   void __iomem *iobase;
> +   void __iomem *ahb_base;
> +   struct completion transfer_complete;
> +   unsigned int irq_mask;
> +   int current_cs;
> +   unsigned int ahb_phy_addr;
> +   unsigned int master_ref_clk_hz;
> +   u32 is_decoded_cs;
> +   unsigned int fifo_depth;
> +   unsigned int fifo_width;
> +   unsigned int trigger_address;
> +   struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
> +};
> +
> +/* Operation timeout value */
> +#define CQSPI_TIMEOUT_MS   500
> +#define CQSPI_READ_TIMEOUT_MS  10
> +#define CQSPI_POLL_IDLE_RETRY  3
> +
> +#define CQSPI_REG_SRAM_RESV_WORDS  2
> +#define CQSPI_REG_SRAM_PARTITION_WR1
> +#define CQSPI_REG_SRAM_THRESHOLD_BYTES 50
> +
> +/* Instruction type */
> +#define CQSPI_INST_TYPE_SINGLE 

Re: [PATCH 2/7] tty: core: Add tty_debug() for printk(KERN_DEBUG) messages

[Peter Hurley]

On 07/23/2015 09:35 PM, Greg Kroah-Hartman wrote:
> On Sun, Jul 12, 2015 at 10:49:08PM -0400, Peter Hurley wrote:
>> Introduce tty_debug() macro to output uniform debug information for
>> tty core debug messages (function name and tty name).
>>
>> Note: printk(KERN_DEBUG) is retained here over pr_debug() since
>> messages can be enabled in non-DEBUG builds.
> 
> But pr_debug() is the "standard" way to enable/disable debugging
> messages, so I'd really like to see that be used here.

Ok, I can do that; I'll roll Joe's suggestions in at that time.

> Even better, this is a tty device, so it should be using dev_dbg(),
> which gives us tons of good information built-in for the tty and can
> properly be parsed by userspace tools to know exactly what device caused
> what message at what point in time.
> 
> So I'll take this for now, but moving it to use dev_dbg() would be best
> eventually.

The issue with using dev_dbg is that (SysV) ptys are not devices. However,
if you'd prefer, I could rework this macro to format output like dev_dbg;
ie.,  : 

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

Re: [PATCH 1/3] x86/entry/64: Refactor IRQ stacks and make then NMI-safe

[Andy Lutomirski]

On Wed, Aug 5, 2015 at 11:27 AM, Steven Rostedt  wrote:
> On Wed, 5 Aug 2015 11:24:54 -0700
> Andy Lutomirski  wrote:
>
>> On Wed, Aug 5, 2015 at 1:59 AM, Ingo Molnar  wrote:
>> >
>> > * Andy Lutomirski  wrote:
>> >
>> >> --- a/arch/x86/kernel/process_64.c
>> >> +++ b/arch/x86/kernel/process_64.c
>> >> @@ -280,6 +280,10 @@ __switch_to(struct task_struct *prev_p, struct 
>> >> task_struct *next_p)
>> >>   unsigned fsindex, gsindex;
>> >>   fpu_switch_t fpu_switch;
>> >>
>> >> +#ifdef CONFIG_DEBUG_ENTRY
>> >> + WARN_ON(this_cpu_read(irq_count));
>> >> +#endif
>> >
>> > Please introduce a less noisy (to the eyes) version of this, something 
>> > like:
>> >
>> > WARN_ON_DEBUG_ENTRY(this_cpu_read(irq_count));
>> >
>> > or so, similar to WARN_ON_FPU().
>>
>> I can do that (or "DEBUG_ENTRY_WARN_ON"?  we seem to be inconsistent
>> about ordering).
>>
>> Or would if (IS_ENABLED(CONFIG_DEBUG_ENTRY)) WARN_ON(...) be better?
>>
>
> Does WARN_ON(IS_ENABLED(CONFIG_DEBUG_ENTRY) && this_cpu_read(irq_count))
> work?

I'd be okay with it.  Ingo?

(Except that that line of code is from v1, and v2 looks slightly
different here, but that's beside the point.)

--Andy

>
> -- Steve



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

Re: [PATCH 1/3] x86/entry/64: Refactor IRQ stacks and make then NMI-safe

[Steven Rostedt]

On Wed, 5 Aug 2015 11:24:54 -0700
Andy Lutomirski  wrote:

> On Wed, Aug 5, 2015 at 1:59 AM, Ingo Molnar  wrote:
> >
> > * Andy Lutomirski  wrote:
> >
> >> --- a/arch/x86/kernel/process_64.c
> >> +++ b/arch/x86/kernel/process_64.c
> >> @@ -280,6 +280,10 @@ __switch_to(struct task_struct *prev_p, struct 
> >> task_struct *next_p)
> >>   unsigned fsindex, gsindex;
> >>   fpu_switch_t fpu_switch;
> >>
> >> +#ifdef CONFIG_DEBUG_ENTRY
> >> + WARN_ON(this_cpu_read(irq_count));
> >> +#endif
> >
> > Please introduce a less noisy (to the eyes) version of this, something like:
> >
> > WARN_ON_DEBUG_ENTRY(this_cpu_read(irq_count));
> >
> > or so, similar to WARN_ON_FPU().
> 
> I can do that (or "DEBUG_ENTRY_WARN_ON"?  we seem to be inconsistent
> about ordering).
> 
> Or would if (IS_ENABLED(CONFIG_DEBUG_ENTRY)) WARN_ON(...) be better?
> 

Does WARN_ON(IS_ENABLED(CONFIG_DEBUG_ENTRY) && this_cpu_read(irq_count))
work?

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/27] ASN.1: Copy string names to tokens in ASN.1 compiler [ver #7]

[David Howells]

Mimi Zohar  wrote:

> This patch isn't applying properly against linux-security/next.  The
> rest seem to be fine.

Did you apply the asn1-fixes-20150805 first and patch 1?

Note that the branch is based on security/next, with my asn1-fixes-20150805
tag merged on top - so it *ought* to apply.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] vDSO,test: Add vdso_test as an additional target with add-assign

[Andy Lutomirski]

On Tue, Aug 4, 2015 at 4:09 PM, Yuyang Du  wrote:
> Simply adding the vdso_test target by removing the comment sign won't
> work unless the targets are added correctly.

Jon, is this yours or mine?

--Andy

>
> Signed-off-by: Yuyang Du 
> ---
>  Documentation/vDSO/Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/vDSO/Makefile b/Documentation/vDSO/Makefile
> index b12e987..6ea13ef 100644
> --- a/Documentation/vDSO/Makefile
> +++ b/Documentation/vDSO/Makefile
> @@ -1,7 +1,7 @@
>  ifndef CROSS_COMPILE
> -# vdso_test won't build for glibc < 2.16, so disable it
> -# hostprogs-y := vdso_test
>  hostprogs-$(CONFIG_X86) := vdso_standalone_test_x86
> +# vdso_test won't build for glibc < 2.16, so disable it
> +# hostprogs-y += vdso_test
>  vdso_standalone_test_x86-objs := vdso_standalone_test_x86.o parse_vdso.o
>  vdso_test-objs := parse_vdso.o vdso_test.o
>
> --
> 1.9.1
>



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

Re: [PATCH 1/3] x86/entry/64: Refactor IRQ stacks and make then NMI-safe

[Andy Lutomirski]

On Wed, Aug 5, 2015 at 1:59 AM, Ingo Molnar  wrote:
>
> * Andy Lutomirski  wrote:
>
>> --- a/arch/x86/kernel/process_64.c
>> +++ b/arch/x86/kernel/process_64.c
>> @@ -280,6 +280,10 @@ __switch_to(struct task_struct *prev_p, struct 
>> task_struct *next_p)
>>   unsigned fsindex, gsindex;
>>   fpu_switch_t fpu_switch;
>>
>> +#ifdef CONFIG_DEBUG_ENTRY
>> + WARN_ON(this_cpu_read(irq_count));
>> +#endif
>
> Please introduce a less noisy (to the eyes) version of this, something like:
>
> WARN_ON_DEBUG_ENTRY(this_cpu_read(irq_count));
>
> or so, similar to WARN_ON_FPU().

I can do that (or "DEBUG_ENTRY_WARN_ON"?  we seem to be inconsistent
about ordering).

Or would if (IS_ENABLED(CONFIG_DEBUG_ENTRY)) WARN_ON(...) be better?

--Andy

>
> Thanks,
>
> Ingo



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: correct fpu emulation access to ldt

[Andy Lutomirski]

On Wed, Aug 5, 2015 at 2:11 AM, Juergen Gross  wrote:
> On 08/04/2015 08:01 PM, Andy Lutomirski wrote:
>>
>> On Tue, Aug 4, 2015 at 8:02 AM, Juergen Gross  wrote:
>>>
>>> Commit 14805442532c ("x86/ldt: Make modify_ldt synchronous") introduced
>>> a new struct ldt_struct anchored at mm->context.ldt.
>>>
>>> Adapt the x86 fpu emulation to use that new structure.
>>>
>>> Signed-off-by: Juergen Gross 
>>
>>
>> Whoops!
>>
>> Does this need to Cc: stable?
>
>
> Probably.
>
>> Also, want to make it slightly fancier so we can drop the dependency
>> on CONFIG_MODIFY_LDT_SYSCALL?
>
>
> Something like:
>
> -#define LDT_DESCRIPTOR(s) (((struct desc_struct
> *)current->mm->context.ldt)[(s) >> 3])
> +#ifdef CONFIG_MODIFY_LDT_SYSCALL
> +#define LDT_DESCRIPTOR(s) (current->mm->context.ldt->entries[(s) >> 3])
> +#else
> +#define LDT_DESCRIPTOR(s) ((struct desc_struct){{{ .a = 0, .b = 0, }}})

Careful!  I think that akpm uses some ancient gcc version that can't
compile that.  Maybe have a global empty segment somewhere that this
returns, or just ifdef out the two call sites.

Also, I don't believe this for a second:

/* s is always from a cpu register, and the cpu does bounds checking
 * during register load --> no further bounds checks needed */
#define LDT_DESCRIPTOR(s)(((struct desc_struct
*)current->mm->context.ldt)[(s) >> 3])

"What the comment means is that s always came from a cpu register at
some point in the recent past (assuming that no lazy segment save
logic is in effect) and we cross our fingers and hope that we never
end up accessing out of bounds if the LDT isn't the same as it was at
the time of the fault we're handling."

Sigh.

Maybe the best approach would be to replace LDT_DESCRIPTOR with an
actual function that returns a struct desc_struct.  If it's out of
bounds or !CONFIG_MODIFY_LDT_SYSCALL, return zeros.  Otherwise return
the descriptor.

> +#endif
>
> I'd need to specify the corresponding patch as a prerequisite for stable
> I guess? How to do this before it is picked by Linus?

Send a v2 with Cc: sta...@vger.kernel.org # [commit hash you depend
on].  Presumably Ingo will pick it up, not Linus.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ioatdma: fix overflow of u16 in ring_reshape

[Allen Hubbe]

If the allocation order is 16, then the u16 index will overflow and wrap
to zero instead of being equal or greater than 1 << 16.  The loop
condition will always be true, and the loop will run until all the
memory resources are depleted.

Change the type of index 'i' to u32, so that it is large enough to store
a value equal or greater than 1 << 16.

Signed-off-by: Allen Hubbe 
---
 drivers/dma/ioat/dma_v2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/ioat/dma_v2.c b/drivers/dma/ioat/dma_v2.c
index 69c7dfcad023..13fbd9d5b5b9 100644
--- a/drivers/dma/ioat/dma_v2.c
+++ b/drivers/dma/ioat/dma_v2.c
@@ -588,7 +588,7 @@ bool reshape_ring(struct ioat2_dma_chan *ioat, int order)
const u16 active = ioat2_ring_active(ioat);
const u32 new_size = 1 << order;
struct ioat_ring_ent **ring;
-   u16 i;
+   u32 i;
 
if (order > ioat_get_max_alloc_order())
return false;
-- 
2.5.0.rc1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 19/23] power/reset: at91-poweroff: get and use slow clock

[Sebastian Reichel]

Hi,

On Fri, Jul 31, 2015 at 11:39:55AM +0200, Alexandre Belloni wrote:
> Commit dca1a4b5ff6e ("clk: at91: keep slow clk enabled to prevent system
> hang") added a workaround for the slow clock as it is not properly handled
> by its users.
> 
> Get and use the slow clock as it is necessary for the at91 shutdown
> controller.

You call clk_prepare_enable during probe without a matching
clk_disable_unprepare on module removal.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 18/23] power/reset: at91-reset: get and use slow clock

[Sebastian Reichel]

Hi,

On Fri, Jul 31, 2015 at 11:39:54AM +0200, Alexandre Belloni wrote:
> Commit dca1a4b5ff6e ("clk: at91: keep slow clk enabled to prevent system
> hang") added a workaround for the slow clock as it is not properly handled
> by its users.
> 
> Get and use the slow clock as it is necessary for the at91 reset
> controller.

You call clk_prepare_enable during probe without a matching
clk_disable_unprepare on module removal.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH] sb_edac: fix TAD presence check for sbridge_mci_bind_devs()

[Aristeu Rozanski]

On Wed, Aug 05, 2015 at 01:16:01PM -0500, Seth Jennings wrote:
> In 7d375bff, NUM_CHANNELS was changed to 8 and the channel space was
> renumerated to handle EN, EP, and EX configurations.
> 
> The *_mci_bind_devs functions, except for sbridge_mci_bind_devs(), got a
> new device presence check in the form of saw_chan_mask.  However,
> sbridge_mci_bind_devs() still uses the NUM_CHANNELS for loop.
> 
> With the increase in NUM_CHANNELS, this loop fails at index 4 since
> SB only has 4 TADs.  This results in the following error on SB machines:
> 
> EDAC sbridge: Some needed devices are missing
> EDAC sbridge: Couldn't find mci handler
> EDAC sbridge: Couldn't find mci handle
> 
> This patch adapts the saw_chan_mask logic for sbridge_mci_bind_devs() as
> well.
> 
> After this patch:
> 
> EDAC MC0: Giving out device to module sbridge_edac.c controller Sandy Bridge 
> Socket#0: DEV :3f:0e.0 (POLLED)
> EDAC MC1: Giving out device to module sbridge_edac.c controller Sandy Bridge 
> Socket#1: DEV :7f:0e.0 (POLLED)

Acked-by: Aristeu Rozanski 

> 
> Signed-off-by: Seth Jennings 
> ---
>  drivers/edac/sb_edac.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
> index ca78311..91cf710 100644
> --- a/drivers/edac/sb_edac.c
> +++ b/drivers/edac/sb_edac.c
> @@ -1648,6 +1648,7 @@ static int sbridge_mci_bind_devs(struct mem_ctl_info 
> *mci,
>  {
>   struct sbridge_pvt *pvt = mci->pvt_info;
>   struct pci_dev *pdev;
> + u8 saw_chan_mask = 0;
>   int i;
>  
>   for (i = 0; i < sbridge_dev->n_devs; i++) {
> @@ -1681,6 +1682,7 @@ static int sbridge_mci_bind_devs(struct mem_ctl_info 
> *mci,
>   {
>   int id = pdev->device - 
> PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD0;
>   pvt->pci_tad[id] = pdev;
> + saw_chan_mask |= 1 << id;
>   }
>   break;
>   case PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_DDRIO:
> @@ -1701,10 +1703,8 @@ static int sbridge_mci_bind_devs(struct mem_ctl_info 
> *mci,
>   !pvt-> pci_tad || !pvt->pci_ras  || !pvt->pci_ta)
>   goto enodev;
>  
> - for (i = 0; i < NUM_CHANNELS; i++) {
> - if (!pvt->pci_tad[i])
> - goto enodev;
> - }
> + if (saw_chan_mask != 0x0f)
> + goto enodev;
>   return 0;
>  
>  enodev:
> -- 
> 2.4.3
> 

-- 
Aristeu

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] user_ns: use correct check for single-threadedness

[Eric W. Biederman]

Kees Cook  writes:

> On Tue, Jul 28, 2015 at 1:55 PM, Ricky Zhou  wrote:
>> On Tue, Jul 28, 2015 at 11:17 AM, Eric W. Biederman
>>  wrote:
>>> Kees Cook  writes:
>>>
 From: Ricky Zhou 

 Checking mm_users > 1 does not mean a process is multithreaded. For
 example, reading /proc/PID/maps temporarily increments mm_users, allowing
 other processes to (accidentally) interfere with unshare() calls.

 This fixes observed failures of unshare(CLONE_NEWUSER) incorrectly
 returning EINVAL if another processes happened to be simultaneously
 reading the maps file.

 Signed-off-by: Ricky Zhou 
 Signed-off-by: Kees Cook 
 Cc: sta...@vger.kernel.org
>>>
>>> This looks like a good fix.  Any chance you can drudge up the commit where
>>> this hack came in so that Greg & Company know how far to back port this?
>>
>> userns_install in user_namespace.c (affects setns of a user
>> namespace): cde1975bc242f3e1072bde623ef378e547b73f91.
>>
>> The check in check_unshare_flags is a little more complex. The
>> incorrect check was added in
>> cf2e340f4249b781b3d2beb41e891d08581f0e10 but I don't think it would
>> have triggered under any supported combination of flags at that point.
>>
>> From 50804fe3737ca6a5942fdc2057a18a8141d00141 until
>> 6e556ce209b09528dbf1931cbfd5d323e1345926, the bug affected
>> unshare(CLONE_NEWPID).
>
> That's back to v3.8, so this goes quite a way, it seems.

This patch was marked as CC' stable.  The question I am asking is this
problem bad enough that backporting this change to stable makes sense?

And even more if this patch can wait for the merge window to be merged
or if there this needs to be expidited, and get in before 4.2 -final.

It sounds like this is one of those rare bugs someone hit once or twice,
just often enough for this to be tracked down, and the important thing
is that this fix get into the kernel's code base.

So unless I am otherwise informed I will assume that this is a change
that can stand to wait until the merge window to be merged (so it has a
full development cycle of review and discussion).  But that is worth
backporting after that because it actually causes problems that people
actually hit.

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

[PATCH] sb_edac: fix TAD presence check for sbridge_mci_bind_devs()

[Seth Jennings]

In 7d375bff, NUM_CHANNELS was changed to 8 and the channel space was
renumerated to handle EN, EP, and EX configurations.

The *_mci_bind_devs functions, except for sbridge_mci_bind_devs(), got a
new device presence check in the form of saw_chan_mask.  However,
sbridge_mci_bind_devs() still uses the NUM_CHANNELS for loop.

With the increase in NUM_CHANNELS, this loop fails at index 4 since
SB only has 4 TADs.  This results in the following error on SB machines:

EDAC sbridge: Some needed devices are missing
EDAC sbridge: Couldn't find mci handler
EDAC sbridge: Couldn't find mci handle

This patch adapts the saw_chan_mask logic for sbridge_mci_bind_devs() as
well.

After this patch:

EDAC MC0: Giving out device to module sbridge_edac.c controller Sandy Bridge 
Socket#0: DEV :3f:0e.0 (POLLED)
EDAC MC1: Giving out device to module sbridge_edac.c controller Sandy Bridge 
Socket#1: DEV :7f:0e.0 (POLLED)

Signed-off-by: Seth Jennings 
---
 drivers/edac/sb_edac.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
index ca78311..91cf710 100644
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -1648,6 +1648,7 @@ static int sbridge_mci_bind_devs(struct mem_ctl_info *mci,
 {
struct sbridge_pvt *pvt = mci->pvt_info;
struct pci_dev *pdev;
+   u8 saw_chan_mask = 0;
int i;
 
for (i = 0; i < sbridge_dev->n_devs; i++) {
@@ -1681,6 +1682,7 @@ static int sbridge_mci_bind_devs(struct mem_ctl_info *mci,
{
int id = pdev->device - 
PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_TAD0;
pvt->pci_tad[id] = pdev;
+   saw_chan_mask |= 1 << id;
}
break;
case PCI_DEVICE_ID_INTEL_SBRIDGE_IMC_DDRIO:
@@ -1701,10 +1703,8 @@ static int sbridge_mci_bind_devs(struct mem_ctl_info 
*mci,
!pvt-> pci_tad || !pvt->pci_ras  || !pvt->pci_ta)
goto enodev;
 
-   for (i = 0; i < NUM_CHANNELS; i++) {
-   if (!pvt->pci_tad[i])
-   goto enodev;
-   }
+   if (saw_chan_mask != 0x0f)
+   goto enodev;
return 0;
 
 enodev:
-- 
2.4.3

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

[PATCH 2/2] clocksource: sanity check watchdog clocksource

[Shaohua Li]

Add a sanity check to make sure watchdog clocksource doesn't wrap too
quickly.

Cc: John Stultz 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Signed-off-by: Shaohua Li 
---
 kernel/time/clocksource.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 8417c83..64e4629 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -327,7 +327,8 @@ static void clocksource_enqueue_watchdog(struct clocksource 
*cs)
if (cs->flags & CLOCK_SOURCE_IS_CONTINUOUS)
cs->flags |= CLOCK_SOURCE_VALID_FOR_HRES;
/* Pick the best watchdog. */
-   if (!watchdog || cs->rating > watchdog->rating) {
+   if (cs->max_idle_ns > WATCHDOG_MAX_INTERVAL_NS &&
+   (!watchdog || cs->rating > watchdog->rating)) {
watchdog = cs;
/* Reset watchdog cycles */
clocksource_reset_watchdog();
-- 
1.8.5.6

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

[PATCH 1/2] clocksource: improve unstable clocksource detection

[Shaohua Li]

>From time to time we saw TSC is marked as unstable in our systems, while
the CPUs declare to have stable TSC. Looking at the clocksource unstable
detection, there are two problems:
- watchdog clock source wrap. HPET is the most common watchdog clock
  source. It's 32-bit and runs in 14.3Mhz. That means the hpet counter
  can wrap in about 5 minutes.
- threshold isn't scaled against interval. The threshold is 0.0625s in
  0.5s interval. What if the actual interval is bigger than 0.5s?

The watchdog runs in a timer bh, so hard/soft irq can defer its running.
Heavy network stack softirq can hog a cpu. IPMI driver can disable
interrupt for a very long time. The first problem is mostly we are
suffering I think.

Here is a simple patch to fix the issues. If the waterdog doesn't run
for a long time, we ignore the detection. This should work for the two
problems. For the second one, we probably doen't need to scale if the
interval isn't very long.

Cc: John Stultz 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Signed-off-by: Shaohua Li 
---
 kernel/time/clocksource.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 841b72f..8417c83 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -122,9 +122,10 @@ static int clocksource_watchdog_kthread(void *data);
 static void __clocksource_change_rating(struct clocksource *cs, int rating);
 
 /*
- * Interval: 0.5sec Threshold: 0.0625s
+ * Interval: 0.5sec MaxInterval: 1s Threshold: 0.0625s
  */
 #define WATCHDOG_INTERVAL (HZ >> 1)
+#define WATCHDOG_MAX_INTERVAL_NS (NSEC_PER_SEC)
 #define WATCHDOG_THRESHOLD (NSEC_PER_SEC >> 4)
 
 static void clocksource_watchdog_work(struct work_struct *work)
@@ -217,7 +218,9 @@ static void clocksource_watchdog(unsigned long data)
continue;
 
/* Check the deviation from the watchdog clocksource. */
-   if ((abs(cs_nsec - wd_nsec) > WATCHDOG_THRESHOLD)) {
+   if ((abs(cs_nsec - wd_nsec) > WATCHDOG_THRESHOLD) &&
+   cs_nsec < WATCHDOG_MAX_INTERVAL_NS &&
+   wd_nsec < WATCHDOG_MAX_INTERVAL_NS) {
pr_warn("timekeeping watchdog: Marking clocksource '%s' 
as unstable because the skew is too large:\n",
cs->name);
pr_warn("  '%s' wd_now: %llx 
wd_last: %llx mask: %llx\n",
-- 
1.8.5.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/27] ASN.1: Copy string names to tokens in ASN.1 compiler [ver #7]

[Mimi Zohar]

Hi David,

This patch isn't applying properly against linux-security/next.  The
rest seem to be fine.

Mimi

On Wed, 2015-08-05 at 14:43 +0100, David Howells wrote:
> Copy string names to tokens in ASN.1 compiler rather than storing a pointer
> into the source text.  This means we don't have to use "%*.*s" all over the
> place.
> 
> Signed-off-by: David Howells 
> Reviewed-by: David Woodhouse 
> ---
> 
>  scripts/asn1_compiler.c |  155 
> ++-
>  1 file changed, 73 insertions(+), 82 deletions(-)
> 
> diff --git a/scripts/asn1_compiler.c b/scripts/asn1_compiler.c
> index 6e4ba992a51f..e000f44e37b8 100644
> --- a/scripts/asn1_compiler.c
> +++ b/scripts/asn1_compiler.c
> @@ -294,8 +294,8 @@ static const char *const directives[NR__DIRECTIVES] = {
> 
>  struct action {
>   struct action   *next;
> + char*name;
>   unsigned char   index;
> - charname[];
>  };
> 
>  static struct action *action_list;
> @@ -306,7 +306,7 @@ struct token {
>   enum token_type token_type : 8;
>   unsigned char   size;
>   struct action   *action;
> - const char  *value;
> + char*content;
>   struct type *type;
>  };
> 
> @@ -328,11 +328,9 @@ static int directive_compare(const void *_key, const 
> void *_pdir)
>   dlen = strlen(dir);
>   clen = (dlen < token->size) ? dlen : token->size;
> 
> - //debug("cmp(%*.*s,%s) = ",
> - //   (int)token->size, (int)token->size, token->value,
> - //   dir);
> + //debug("cmp(%s,%s) = ", token->content, dir);
> 
> - val = memcmp(token->value, dir, clen);
> + val = memcmp(token->content, dir, clen);
>   if (val != 0) {
>   //debug("%d [cmp]\n", val);
>   return val;
> @@ -352,7 +350,7 @@ static int directive_compare(const void *_key, const void 
> *_pdir)
>  static void tokenise(char *buffer, char *end)
>  {
>   struct token *tokens;
> - char *line, *nl, *p, *q;
> + char *line, *nl, *start, *p, *q;
>   unsigned tix, lineno;
> 
>   /* Assume we're going to have half as many tokens as we have
> @@ -411,11 +409,11 @@ static void tokenise(char *buffer, char *end)
>   break;
> 
>   tokens[tix].line = lineno;
> - tokens[tix].value = p;
> + start = p;
> 
>   /* Handle string tokens */
>   if (isalpha(*p)) {
> - const char **dir;
> + const char **dir, *start = p;
> 
>   /* Can be a directive, type name or element
>* name.  Find the end of the name.
> @@ -426,10 +424,18 @@ static void tokenise(char *buffer, char *end)
>   tokens[tix].size = q - p;
>   p = q;
> 
> + tokens[tix].content = malloc(tokens[tix].size + 
> 1);
> + if (!tokens[tix].content) {
> + perror(NULL);
> + exit(1);
> + }
> + memcpy(tokens[tix].content, start, 
> tokens[tix].size);
> + tokens[tix].content[tokens[tix].size] = 0;
> + 
>   /* If it begins with a lowercase letter then
>* it's an element name
>*/
> - if (islower(tokens[tix].value[0])) {
> + if (islower(tokens[tix].content[0])) {
>   tokens[tix++].token_type = 
> TOKEN_ELEMENT_NAME;
>   continue;
>   }
> @@ -458,6 +464,13 @@ static void tokenise(char *buffer, char *end)
>   q++;
>   tokens[tix].size = q - p;
>   p = q;
> + tokens[tix].content = malloc(tokens[tix].size + 
> 1);
> + if (!tokens[tix].content) {
> + perror(NULL);
> + exit(1);
> + }
> + memcpy(tokens[tix].content, start, 
> tokens[tix].size);
> + tokens[tix].content[tokens[tix].size] = 0;
>   tokens[tix++].token_type = TOKEN_NUMBER;
>   continue;
>   }
> @@ -466,6 +479,7 @@ static void tokenise(char *buffer, char *end)
>   if (memcmp(p, "::=", 3) == 0) {
>   p += 3;
>   tokens[tix].size = 3;
> + tokens[tix].content = "::=";
>

Re: [PATCH 01/23] Documentation: dt: atmel-at91: add clocks to system timer, rstc and shdwc

[Sebastian Reichel]

Hi,

On Fri, Jul 31, 2015 at 11:39:37AM +0200, Alexandre Belloni wrote:
> The system timer (at91rm9200), the reset controller and the shutdown
> controller need an input clock. This is the slow clock and they will not
> function without it.
> 
> Also fix the shutdown controller example.

Acked-By: Sebastian Reichel 

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 2/2] gpio/mxc: implement reading output gpio value

[Fabio Estevam]

Hi Eduardo,

On Wed, Aug 5, 2015 at 3:02 PM, Eduardo Valentin  wrote:
>
> Hello Fabio,
>
> On Wed, Aug 05, 2015 at 02:43:05PM -0300, Fabio Estevam wrote:
>> Hi Eduardo,
>>
>> On Wed, Aug 5, 2015 at 2:23 PM, Eduardo Valentin  wrote:
>> > In current implementation, reading the value of an output gpio
>> > always return 0. The reason is because when a gpio is configured
>>
>> Have you tried setting the SION bit for the pad?
>
> No, I haven't. From the bit description, it looks like it does a
> different thing of what we would achieve with this patch. The SION bit
> is a overwrite to the pad configuration. That is, the pin will be INPUT
> always.
>
> We don't want to force it to be input. We simply want to be able to read
> the value of an output GPIO. That is achievable by reading a different
> register. In case the GPIO is configured as output, the GPIO block
> documentation states its value can be read from GPIO_PSR.
> This approach works fine, as the GPIO will be output and we can still
> read its value.

Setting the SION bit allows you to do exactly that. Please see:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/271774.html

Regards,

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

RE: [PATCH] staging: comedi: improve comedi_check_chanlist() documentation

[Hartley Sweeten]

On Wednesday, August 05, 2015 10:13 AM, Ian Abbott wrote:
>
> Signed-off-by: Ian Abbott 
> ---
>  drivers/staging/comedi/range.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/comedi/range.c b/drivers/staging/comedi/range.c
> index 6a393b2..ce3a58a 100644
> --- a/drivers/staging/comedi/range.c
> +++ b/drivers/staging/comedi/range.c
> @@ -102,7 +102,18 @@ int do_rangeinfo_ioctl(struct comedi_device *dev,
>   * @s: comedi_subdevice struct
>   * @n: number of elements in the chanlist
>   * @chanlist: the chanlist to validate
> -*/
> + *
> + * Each element consists of a channel number, a range index, an analog
> + * reference type and some flags, all packed into an unsigned int.
> + *
> + * This checks that the channel number and range index are supported by
> + * the comedi subdevice.  It does not check whether the analog reference
> + * type and the flags are supported.  Drivers that care should check those
> + * themselves.
> + *
> + * Return: %0 if all @chanlist elements are valid (success),
> + * %-EINVAL if one or more elements are invalid.
> + */
>  int comedi_check_chanlist(struct comedi_subdevice *s, int n,
> unsigned int *chanlist)
>  {

Thanks,

Reviewed-by: H Hartley Sweeten 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] Input - elantech: Add special check for fw_version 0x470f01 touchpad

[Dmitry Torokhov]

Hi Ulrik,

On Sun, Aug 02, 2015 at 12:16:41PM +0800, duson wrote:
> It is no need to check the packet[0] for sanity check when doing
> elantech_packet_check_v4() function for fw_version = 0x470f01 touchpad.
>

Are you OK with this version?

Thanks!

> Signed-off by: Duson Lin 
> ---
>  drivers/input/mouse/elantech.c |   28 +---
>  drivers/input/mouse/elantech.h |1 +
>  2 files changed, 26 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index 22b9ca9..5bc3d55 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -785,6 +785,9 @@ static int elantech_packet_check_v4(struct psmouse 
> *psmouse)
>   unsigned char packet_type = packet[3] & 0x03;
>   bool sanity_check;
> 
> + /* This represents the version of IC body. */
> + int ver = (etd->fw_version & 0x0f) >> 16;
> +
>   if (etd->tp_dev && (packet[3] & 0x0f) == 0x06)
>   return PACKET_TRACKPOINT;
> 
> @@ -796,9 +799,17 @@ static int elantech_packet_check_v4(struct psmouse 
> *psmouse)
>*/
>   if (etd->crc_enabled)
>   sanity_check = ((packet[3] & 0x08) == 0x00);
> - else
> - sanity_check = ((packet[0] & 0x0c) == 0x04 &&
> - (packet[3] & 0x1c) == 0x10);
> + else {
> + /*
> +  * The sanity check only need to check packet[3]
> +  * when IC_body = 7 and PID = 0x2A
> +  */
> + if (ver == 7 && etd->samples[1] == 0x2A)
> + sanity_check = ((packet[3] & 0x1c) == 0x10);
> + else
> + sanity_check = ((packet[0] & 0x0c) == 0x04 &&
> + (packet[3] & 0x1c) == 0x10);
> + }

I'd write this as:

if (etd->crc_enabled)
sanity_check = ((packet[3] & 0x08) == 0x00);
else if (ver == 7 && etd->samples[1] == 0x2A)
sanity_check = ((packet[3] & 0x1c) == 0x10);
else
sanity_check = ((packet[0] & 0x0c) == 0x04 &&
(packet[3] & 0x1c) == 0x10);

> 
>   if (!sanity_check)
>   return PACKET_UNKNOWN;
> @@ -1116,6 +1127,7 @@ static int elantech_get_resolution_v4(struct psmouse 
> *psmouse,
>   * Avatar AVIU-145A2   0x361f00?   clickpad
>   * Fujitsu LIFEBOOK E544   0x470f00d0, 12, 09  2 hw buttons
>   * Fujitsu LIFEBOOK E554   0x570f0140, 14, 0c  2 hw buttons
> + * Fujitsu T725 0x470f0105, 12, 09  2 hw buttons
>   * Fujitsu H7300x570f00c0, 14, 0c  3 hw buttons (**)
>   * Gigabyte U2442  0x450f0158, 17, 0c  2 hw buttons
>   * Lenovo L430 0x350f02b9, 15, 0c  2 hw buttons (*)
> @@ -1651,6 +1663,16 @@ int elantech_init(struct psmouse *psmouse)
>etd->capabilities[0], etd->capabilities[1],
>etd->capabilities[2]);
> 
> + if (etd->hw_version != 1) {
> + if (etd->send_cmd(psmouse, ETP_SAMPLE_QUERY, etd->samples)) {
> + psmouse_err(psmouse, "failed to query sample data\n");
> + goto init_fail;
> + }
> + psmouse_info(psmouse,
> + "Elan sample query result %02x, %02x, %02x\n",
> + etd->samples[0], etd->samples[1], etd->samples[2]);
> + }
> +
>   if (elantech_set_absolute_mode(psmouse)) {
>   psmouse_err(psmouse,
>   "failed to put touchpad into absolute mode.\n");
> diff --git a/drivers/input/mouse/elantech.h b/drivers/input/mouse/elantech.h
> index f965d15..e1cbf40 100644
> --- a/drivers/input/mouse/elantech.h
> +++ b/drivers/input/mouse/elantech.h
> @@ -129,6 +129,7 @@ struct elantech_data {
>   unsigned char reg_26;
>   unsigned char debug;
>   unsigned char capabilities[3];
> + unsigned char samples[3];
>   bool paritycheck;
>   bool jumpy_cursor;
>   bool reports_pressure;
> --
> 

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] user_ns: use correct check for single-threadedness

[Eric W. Biederman]

Oleg Nesterov  writes:

> On 07/29, Kirill A. Shutemov wrote:
>>
>> On Tue, Jul 28, 2015 at 02:35:04PM -0700, Andrew Morton wrote:
>> > On Tue, 28 Jul 2015 10:15:00 -0700 Kees Cook  wrote:
>> >
>> > > From: Ricky Zhou 
>> > >
>> > > Checking mm_users > 1 does not mean a process is multithreaded. For
>> > > example, reading /proc/PID/maps temporarily increments mm_users, allowing
>> > > other processes to (accidentally) interfere with unshare() calls.
>> > >
>> > > This fixes observed failures of unshare(CLONE_NEWUSER) incorrectly
>> > > returning EINVAL if another processes happened to be simultaneously
>> > > reading the maps file.
>> >
>> > Yikes.  current_is_single_threaded() is expensive.  Are we sure this
>> > isn't going to kill someone's workload?
>>
>> It's expensive only if mm_users > 1. We will go to for_each_process() only
>> if somebody outside of the process grabs mm_users references (like reading
>> /proc/PID/maps).
>
> Yes,
>
>> Or if it called it from multithreaded application.
>
> Not really, please note the "negative fast-path" check:
>
>   if (atomic_read(&task->signal->live) != 1)  
>   return false;
>
>> Acked-by: Kirill A. Shutemov 
>
> Same here, I think the patch is fine.
>
> I don't think that sys_setns() is performance critical, and Eric seems
> to agree with this change too.

I do and I am about to merge it into my userns tree.  It is clearly an
issue that is affecting users in the real world, which fundamentally
makes the current implementation buggy.

That said the performance of sys_setns does matter.  Removing the
possibility of calling synchronize_rcu from switch_task_namespaces
happened because the performance of sys_setns was a problem.

Looking at the implementation of current_is_single_threaded() it appears
that the data structures dealing with threads could stand some
improvement so current_is_single_threaded() could become a constant time
function.

The class of application that is likely to call setns and be strongly
affected by it's performance are container management applications or
applications that are deliberately using more than one namespace at a
time.  There might be advantages to using current_is_single_threaded()
as currently written to slow down an application.  That slow down could
expand a race condition enough to make another bug exploitable.

So if we could figure out how to make current_is_single_threaded()
faster or at least have the slow path not triggerable by users playing
with proc I would very much be in favor of it.

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

Re: [PATCH v2 1/2] power: reset: at91: add sama5d3 reset function

[Sebastian Reichel]

Hi Nicolas,

On Tue, Jul 28, 2015 at 09:27:38AM +0200, Nicolas Ferre wrote:
> >> This patch introduces a new compatible string: "atmel,sama5d3-rstc" and
> >> new reset function for sama5d3 and later chips.
> > 
> > queued.
> 
> As my Device Tree changes depend on this modification,
> we can synchronize in tree ways:

Sorry for the delay.

> 1/ you provide me a stable branch so that I can pull it before applying
> my changes that can go through arm-soc.
> 
> 2/ you let me take the driver's modifications with me and the two
> patches of the series would go through arm-soc.
>
> 3/ you take the second patch of my series with my Acked-by tag and carry
> both of them up to Linus' tree.

I would be fine with all solutions, but 2/ would also require
you handling another patch. I think your option 4/ is the best:

> Okay, so to ease synchronization, I take this one with me through
> arm-soc and add the old compatibility string as a fallback => the
> newer will be used when merged...

FWIW:

Acked-By: Sebastian Reichel 

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Daniel Kurtz]

On Wed, Aug 5, 2015 at 8:25 PM, Sascha Hauer  wrote:
> This adds support for the Mediatek thermal controller found on MT8173
> and likely other SoCs.
> The controller is a bit special. It does not have its own ADC, instead
> it controls the on-SoC AUXADC via AHB bus accesses. For this reason
> we need the physical address of the AUXADC. Also it controls a mux
> using AHB bus accesses, so we need the APMIXEDSYS physical address aswell.
>
> Signed-off-by: Sascha Hauer 
> ---
>  drivers/thermal/Kconfig   |   8 +
>  drivers/thermal/Makefile  |   1 +
>  drivers/thermal/mtk_thermal.c | 581 
> ++
>  3 files changed, 590 insertions(+)
>  create mode 100644 drivers/thermal/mtk_thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 118938e..07ad114 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -340,6 +340,14 @@ config ACPI_THERMAL_REL
> tristate
> depends on ACPI
>
> +config MTK_THERMAL
> +   tristate "Temperature sensor driver for mediatek SoCs"
> +   depends on ARCH_MEDIATEK || COMPILE_TEST
> +   default y
> +   help
> + Enable this option if you want to have support for thermal 
> management
> + controller present in Mediatek SoCs
> +
>  menu "Texas Instruments thermal drivers"
>  source "drivers/thermal/ti-soc-thermal/Kconfig"
>  endmenu
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 535dfee..cc1cab3 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -44,3 +44,4 @@ obj-$(CONFIG_INT340X_THERMAL)  += int340x_thermal/
>  obj-$(CONFIG_ST_THERMAL)   += st/
>  obj-$(CONFIG_TEGRA_SOCTHERM)   += tegra_soctherm.o
>  obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
> +obj-$(CONFIG_MTK_THERMAL)  += mtk_thermal.o
> diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> new file mode 100644
> index 000..0f859b9
> --- /dev/null
> +++ b/drivers/thermal/mtk_thermal.c
> @@ -0,0 +1,581 @@
> +/*
> + * Copyright (c) 2014 MediaTek Inc.
> + * Author: Hanyi.Wu 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* AUXADC Registers */
> +#define AUXADC_CON0_V  0x000
> +#define AUXADC_CON1_V  0x004
> +#define AUXADC_CON1_SET_V  0x008
> +#define AUXADC_CON1_CLR_V  0x00c
> +#define AUXADC_CON2_V  0x010
> +#define AUXADC_DATA(channel)   (0x14 + (channel) * 4)
> +#define AUXADC_MISC_V  0x094
> +
> +#define AUXADC_CON1_CHANNEL(x) BIT(x)
> +
> +#define APMIXED_SYS_TS_CON10x604
> +
> +/* Thermal Controller Registers */
> +#define TEMP_MONCTL0   0x000
> +#define TEMP_MONCTL1   0x004
> +#define TEMP_MONCTL2   0x008
> +#define TEMP_MONINT0x00c
> +#define TEMP_MONINTSTS 0x010
> +#define TEMP_MONIDET0  0x014
> +#define TEMP_MONIDET1  0x018
> +#define TEMP_MONIDET2  0x01c
> +#define TEMP_H2NTHRE   0x024
> +#define TEMP_HTHRE 0x028
> +#define TEMP_CTHRE 0x02c
> +#define TEMP_OFFSETH   0x030
> +#define TEMP_OFFSETL   0x034
> +#define TEMP_MSRCTL0   0x038
> +#define TEMP_MSRCTL1   0x03c
> +#define TEMP_AHBPOLL   0x040
> +#define TEMP_AHBTO 0x044
> +#define TEMP_ADCPNP0   0x048
> +#define TEMP_ADCPNP1   0x04c
> +#define TEMP_ADCPNP2   0x050
> +#define TEMP_ADCPNP3   0x0b4
> +
> +#define TEMP_ADCMUX0x054
> +#define TEMP_ADCEXT0x058
> +#define TEMP_ADCEXT1   0x05c
> +#define TEMP_ADCEN 0x060
> +#define TEMP_PNPMUXADDR0x064
> +#define TEMP_ADCMUXADDR0x068
> +#define TEMP_ADCEXTADDR0x06c
> +#define TEMP_ADCEXT1ADDR   0x070
> +#define TEMP_ADCENADDR 0x074
> +#define TEMP_ADCVALIDADDR  0x078
> +#define TEMP_ADCVOLTADDR   0x07c
> +#define TEMP_RDCTRL0x080
> +#define TEMP_ADCVALIDMASK  0x084
> +#define TEMP_ADCVOLTAGESHIFT   0x088
> +#define TEMP_ADCWRITECTRL  0x08c
> +#define TEMP_MSR0  0x090
> +#define TEMP_MSR1  0x094
> +#define TEMP_MSR2  0x098
> +#define TEMP_MSR3  0x0B8
> +
> +#define TEMP_IMMD0 0x0a0
> +#define TEMP_IMMD1 0x0a4
> +#define TEMP_IMMD2 0x0a8
> +
> +#define TEMP_

Re: [PATCH 2/2] gpio/mxc: implement reading output gpio value

[Eduardo Valentin]

Hello Fabio,

On Wed, Aug 05, 2015 at 02:43:05PM -0300, Fabio Estevam wrote:
> Hi Eduardo,
> 
> On Wed, Aug 5, 2015 at 2:23 PM, Eduardo Valentin  wrote:
> > In current implementation, reading the value of an output gpio
> > always return 0. The reason is because when a gpio is configured
> 
> Have you tried setting the SION bit for the pad?

No, I haven't. From the bit description, it looks like it does a
different thing of what we would achieve with this patch. The SION bit
is a overwrite to the pad configuration. That is, the pin will be INPUT
always.

We don't want to force it to be input. We simply want to be able to read
the value of an output GPIO. That is achievable by reading a different
register. In case the GPIO is configured as output, the GPIO block
documentation states its value can be read from GPIO_PSR.
This approach works fine, as the GPIO will be output and we can still
read its value.

Spotting this is very simple. A quick try on /sys/class/gpio/export on
a spare gpio would do it:

# echo $SPARE_GPIO > /sys/class/gpio/export
# echo out > /sys/class/gpio/gpio$SPARE_GPIO/direction
# echo 1 > /sys/class/gpio/gpio$SPARE_GPIO/value
# cat /sys/class/gpio/gpio$SPARE_GPIO/value

without the patch it would always return 0. With the patch in, you see
the read value corresponding the output of that pin (checked on scope,
for instance).



> 
> This should fix the problem.
> 
> Regards,
> 
> Fabio Estevam

BR,

Eduardo Valentin


signature.asc
Description: Digital signature

Re: [PATCH 07/13] arm64: KVM: VHE: Patch out use of HVC

[Catalin Marinas]

On Wed, Jul 08, 2015 at 05:19:10PM +0100, Marc Zyngier wrote:
> --- /dev/null
> +++ b/arch/arm64/kvm/vhe-macros.h
> @@ -0,0 +1,36 @@
> +/*
> + * Copyright (C) 2015 - ARM Ltd
> + * Author: Marc Zyngier 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#ifndef __ARM64_VHE_MACROS_H__
> +#define __ARM64_VHE_MACROS_H__
> +
> +#include 
> +#include 
> +
> +#ifdef __ASSEMBLY__
> +
> +/* Hack to allow stringification of macros... */
> +#define __S__(a,args...) __stringify(a, ##args)
> +#define _S_(a,args...)   __S__(a, args)
> +
> +.macro ifnvhe nonvhe vhe
> + alternative_insn"\nonvhe", "\vhe", ARM64_HAS_VIRT_HOST_EXTN
> +.endm

I always found the alternative_insn tricks hard to read but with
Daniel's patch queued in -next it gets slightly better. If you are not
targeting 4.3, could you do something like (untested):

.macro  vhe_if_not
alternative_if_not ARM64_HAS_VIRT_HOST_EXTN
.endm

.macro  vhe_else
alternative_else CONFIG_ARM64_VHE
.endm

.macro  vhe_endif
alternative_endif CONFIG_ARM64_VHE
.endm


The kvm_call_hyp, for example, would become:

ENTRY(kvm_call_hyp)
vhe_if_not
hvc #0
ret
vhe_else
nop
pushlr, xzr
vhe_endif


Or you can even ignore defining new vhe_* macros altogether and just use
"alternative_if_not ARM64_HAS_VIRT_HOST_EXTN" directly (more to type)
but you may be able to avoid a vhe-macros.h file.

-- 
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 1/3] clk: versatile: Switch to assigned clock parents

[Stephen Boyd]

On 08/05/2015 03:29 AM, Pawel Moll wrote:


Right, that's probably my fault. The sp810 nodes appeared in the VE
trees very early (in terms of the "DT era"), when we weren't so strict
about documentation. So far, it would be fairly simple, something like
the text below - feel free to take it, mend it, extend it with your
changes and include in the series:

Thanks!


Great! Can you please provide your signed-off-by? I can make it up into 
a patch with some commit text that either you or I provide and throw it 
into the series.


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [PATCH v6 4/8] usb: gadget: move find_ep() from epautoconf to gadget.h

[Felipe Balbi]

On Wed, Aug 05, 2015 at 10:30:54AM -0400, Alan Stern wrote:
> On Wed, 5 Aug 2015, Robert Baldyga wrote:
> 
> > Move find_ep() function to gadget.h, rename it to gadget_find_ep_by_name()
> > and make it static inline. It can be used in UDC drivers, especially in
> > 'match_ep' callback after moving chip-specific endpoint matching logic from
> > epautoconf to UDC drivers.
> 
> > --- a/include/linux/usb/gadget.h
> > +++ b/include/linux/usb/gadget.h
> > @@ -639,6 +639,24 @@ static inline struct usb_gadget 
> > *dev_to_usb_gadget(struct device *dev)
> >  #define gadget_for_each_ep(tmp, gadget) \
> > list_for_each_entry(tmp, &(gadget)->ep_list, ep_list)
> >  
> > +/**
> > + * gadget_find_ep_by_name - returns ep whose name is the same as sting 
> > passed
> > + * in second parameter or NULL if searched endpoint not found
> > + * @g: controller to check for quirk
> > + * @name: name of searched endpoint
> > + */
> > +static inline struct usb_ep *
> > +gadget_find_ep_by_name(struct usb_gadget *g, const char *name)
> > +{
> > +   struct usb_ep *ep;
> > +
> > +   gadget_for_each_ep(ep, g) {
> > +   if (!strcmp(ep->name, name))
> > +   return ep;
> > +   }
> > +
> > +   return NULL;
> > +}
> 
> Minor point: Is this function short enough to be worth inlining?  My 
> general feeling has been that anything containing a nontrivial loop 
> probably shouldn't be inlined, but I could be wrong.

makes sense. Looks like moving it to udc-core.c and making it
EXPORT_SYMBOL_GPL() would be the way to go ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 3/4] arm64: Juno: Add HDLCD support to the Juno boards.

[Russell King - ARM Linux]

On Wed, Aug 05, 2015 at 03:28:11PM +0100, Liviu Dudau wrote:
> + hdmi-transmitter@71 {
>   compatible = "nxp,tda998x";
>   reg = <0x71>;
> + port {
> + tda998x_1_input: endpoint@0 {
> + remote-endpoint = <&hdlcd1_output>;
> + };
> +
> + tda998x_1_output: endpoint@1 {
> + remote-endpoint = 
> <&hdmi1_connector_output>;
> + };
> + };

This isn't compliant with the TDA998x binding, and is very likely to
screw Jean's work on adding audio support.  See emails on lakml and
Documentation/devicetree/bindings/drm/i2c/tda998x.txt (which looks
like it needs updating to include the ports stuff.)

Also, the whole question of representing connectors in a DRM model is
yet to be established.  Yes, DT should describe the hardware, but we
don't yet know _how_ to describe physical connectors with stuff
implemented on top of DRM yet, and we have nothing that makes use of
this.

Also note that ePAPR requires a reg= property if you specify a
unit-address (the bit after the @ sign) so the above is non-compliant
with ePAPR as well.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] watchdog: Add support for keepalives triggered by infrastructure

[David Teigland]

On Wed, Aug 05, 2015 at 10:41:51AM -0700, Guenter Roeck wrote:
> Not really. The heartbeats will be generated such that the watchdog expires
> no later that . I 
> discussed
> this already with Uwe; he had the same concern. This isn't in the current
> version of the patch set, but it will be in the next version. That means
> that nothing will change from user space perspective.

Sounds good, thanks.

> >A related issue from some years ago is the unfortunate fact that closing
> >the watchdog device also generates a heartbeat.  I'd like to disable that
> >also, and submitted a patch for it here:
> >http://www.spinics.net/lists/linux-watchdog/msg01477.html
> >
> 
> That is a different issue, though, and unrelated to this patch set.
> Wim had a good point there: Presumably the problem you are trying to solve
> applies to the entire system, not to a specific watchdog. What you are looking
> for looks more like a system parameter, not like something to set with an 
> ioctl
> message. The reason here is that you'd still want to be able to use standard
> applications such as systemd or watchdogd to trigger heartbeats, and not 
> depend
> on your own.

I'd need this behavior when the system is running my program (sanlock with
wdmd), which uses /dev/watchdog.  No other programs (systemd or watchdogd)
could be using /dev/watchdog at the same time.

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

Re: [BUG] net/ipv4: inconsistent routing table

[Alexander Duyck]

On 08/05/2015 02:06 AM, Daniel Borkmann wrote:

[ please cc netdev ]

On 08/05/2015 10:56 AM, Zang MingJie wrote:

Hi:

I found a bug when remove an ip address which is referenced by a 
routing entry.


step to reproduce:

ip li add type dummy
ip li set dummy0 up
ip ad add 10.0.0.1/24 dev dummy0
ip ad add 10.0.0.2/24 dev dummy0


Okay, so up to this point you have 2 addresses on the same subnet that 
are now on dummy0.



ip ro add default via 10.0.0.2/24


This makes the default route go through 10.0.0.2.


ip ad del 10.0.0.2/24 dev dummy0


Then you remove 10.0.0.2 from the local system, however since 10.0.0.1 
is on the same subnet dummy0 would still be the correct interface to 
access 10.0.0.2 it is just no longer local to the system.



after deleting the secondary ip address, the routing entry still
pointing to 10.0.0.2


You didn't delete the default routing entry so why would you expect it 
to change?  All you did is remove 10.0.0.2 from the local system.  I 
believe the assumption is that 10.0.0.2 is still out there somewhere, it 
just isn't on the local system anymore.



# ip ro
default via 10.0.0.2 dev dummy0
10.0.0.0/24 dev dummy0  proto kernel  scope link  src 10.0.0.1


This matches up with what I would expect.  10.0.0.2 is the default 
gateway and it is accessible from dummy0 since 10.0.0.0/24 is accessible 
from dummy0.



but actually, kernel considers the default route is directly connected.

# ip ro get 1.1.1.1
1.1.1.1 dev dummy0  src 10.0.0.1
 cache


I'm not sure how you came to the "directly connected" conclusion. It is 
still routing things out through 10.0.0.2 from 10.0.0.1.


Maybe your example would work better if you used 10.0.0.1 and 10.0.1.1 
instead.  Then I think you might be able to better see that when you 
delete the second address the route would be broken.


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

Re: [PATCH 2/2] gpio/mxc: implement reading output gpio value

[Fabio Estevam]

Hi Eduardo,

On Wed, Aug 5, 2015 at 2:23 PM, Eduardo Valentin  wrote:
> In current implementation, reading the value of an output gpio
> always return 0. The reason is because when a gpio is configured

Have you tried setting the SION bit for the pad?

This should fix the problem.

Regards,

Fabio Estevam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] watchdog: Add support for keepalives triggered by infrastructure

[Guenter Roeck]

Hi David,

On 08/05/2015 10:13 AM, David Teigland wrote:

On Mon, Aug 03, 2015 at 07:13:26PM -0700, Guenter Roeck wrote:

- Some watchdogs have a very short maximum timeout, in the range of just a few
   seconds. Such low timeouts are difficult if not impossible to support from
   user space. Drivers supporting such watchdog hardware need to implement
   a timer function to augment heartbeats from user space.



- A new status flag, WDOG_RUNNING, informs the watchdog subsystem that a
   watchdog is running, and that the watchdog subsystem needs to generate
   heartbeat requests while the associated watchdog device is closed.



Patch #2 adds timer functionality to the watchdog core. It solves the problem
of short maximum hardware timeouts by augmenting heartbeats triggered from
user space with internally triggered heartbeats.

Patch #3 adds functionality to generate heartbeats while the watchdog device is
closed. It handles situation where where the watchdog is running after
the driver has been instantiated, but the device is not yet opened,
and post-close situations necessary if a watchdog can not be stopped.


These sound concerning because it seems that heartbeats could be generated
outside of the direct control of userspace.  I have a program that depends
on having direct control over whether heartbeats are generated (or more
specifically, *not* generated.)  If these new features introduce a new way
for heartbeats to be generated, is there a way I can detect or disable
that behavior from userspace?  Unwanted heartbeats could break my program
and may lead to data corruption.



Not really. The heartbeats will be generated such that the watchdog expires
no later that . I discussed
this already with Uwe; he had the same concern. This isn't in the current
version of the patch set, but it will be in the next version. That means
that nothing will change from user space perspective.


A related issue from some years ago is the unfortunate fact that closing
the watchdog device also generates a heartbeat.  I'd like to disable that
also, and submitted a patch for it here:
http://www.spinics.net/lists/linux-watchdog/msg01477.html



That is a different issue, though, and unrelated to this patch set.
Wim had a good point there: Presumably the problem you are trying to solve
applies to the entire system, not to a specific watchdog. What you are looking
for looks more like a system parameter, not like something to set with an ioctl
message. The reason here is that you'd still want to be able to use standard
applications such as systemd or watchdogd to trigger heartbeats, and not depend
on your own.

Thanks,
Guenter

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

Re: [PATCH] Fix data loss in cdc-acm

[Peter Hurley]

On 07/22/2015 06:53 PM, Sven Brauch wrote:
> Hi,
> 
> On 23/07/15 00:12, Peter Hurley wrote:
>> The premature unthrottle actually leads to the data loss but the throttling
>> with a mere 2K left is _way too late_.
> Ok, yes, I think so too.
> 
>> 10ms is a _really_ long time for a cpu not to attend to a kworker.

I haven't forgotten about this problem and I still plan to look into why
the long delay, particularly focusing on the scheduling latency from
tty_flip_buffer_push() => flush_to_ldisc().

Regards,
Peter Hurley

>> Which raises 2 questions:
>> 1. What are the termios settings of the tty receiving input? Is it 'raw'
>>mode or typical terminal mode (icanon, echo, etc.) or something else?
> In my test code, I open the tty like
>   fd = open("/dev/ttyACM0", O_RDWR | O_NOCTTY | O_NONBLOCK);
> I don't make any other changes to the default settings. To be honest,
> I'm not sure in which mode it is operating then (I was assuming raw, but
> I might be wrong?).
> 
>> 2. Are there RT threads that are hogging cpu time?
> I can't see any, I think the only thing which occasionally goes to RT is
> pulseaudio (but during at least some of the tests I wasn't even playing
> audio, so that sounds very unplausible to me). I also cannot see a
> correlation between failure rate and CPU load.
> 
> Best regards,
> Sven
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] thermal: power_allocator: do not use devm* interfaces

[Javi Merino]

On Wed, Aug 05, 2015 at 05:50:20PM +0100, Dmitry Torokhov wrote:
> On Wed, Aug 05, 2015 at 09:29:11AM +0100, Javi Merino wrote:
> > On Tue, Aug 04, 2015 at 05:33:40PM +0100, Dmitry Torokhov wrote:
> > > The code in question is called outside of standard driver
> > > probe()/remove() callbacks and thus will not benefit from use of devm*
> > > infrastructure.
> > > 
> > > Signed-off-by: Dmitry Torokhov 
> > 
> > We added the devm* calls because Eduardo asked for them in the review.
> > I don't have a strong opinion regarding this, I'll leave the decision
> > to Eduardo.
> 
> I tried to look for his reasons, if any, but even in earliest posted
> versions use devm* for allocating memory

http://thread.gmane.org/gmane.linux.power-management.general/45000/focus=45265
http://thread.gmane.org/gmane.linux.power-management.general/46064/focus=1722858

He didn't give reasons and I didn't ask for them.  He insisted on it so I just 
added
it across the board.

Cheers,
Javi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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, property: Export acpi_dev_prop_read_single call.

[David Daney]

On 08/05/2015 06:43 AM, Tomasz Nowicki wrote:

On 05.08.2015 15:48, Rafael J. Wysocki wrote:

On Tuesday, August 04, 2015 04:01:59 PM David Daney wrote:

From: Tomasz Nowicki 

Fixes the following build error when building drivers as modules:

  ERROR: "acpi_dev_prop_read_single" [drivers/net/phy/mdio-octeon.ko]
undefined!
  ERROR: "acpi_dev_prop_read_single"
[drivers/net/ethernet/cavium/thunder/thunder_bgx.ko] undefined!


Can you please tell me why the drivers in question use that function
directly, although they aren't supposed to?

Clearly, their authors had not tried to build them as modules or they
would have noticed the problem at the development stage already.

What would be wrong with using the generic device properties API instead?


Yes, you are right. We should use:
int device_property_read_u64_array(struct device *dev, const char
*propname, u64 *val, size_t nval);



Thanks all, for the review and suggestions.  We we try the suggested 
approach and see how it goes...



Thanks again,
David Daney

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] user_ns: use correct check for single-threadedness

[Oleg Nesterov]

On 07/29, Kirill A. Shutemov wrote:
>
> On Tue, Jul 28, 2015 at 02:35:04PM -0700, Andrew Morton wrote:
> > On Tue, 28 Jul 2015 10:15:00 -0700 Kees Cook  wrote:
> >
> > > From: Ricky Zhou 
> > >
> > > Checking mm_users > 1 does not mean a process is multithreaded. For
> > > example, reading /proc/PID/maps temporarily increments mm_users, allowing
> > > other processes to (accidentally) interfere with unshare() calls.
> > >
> > > This fixes observed failures of unshare(CLONE_NEWUSER) incorrectly
> > > returning EINVAL if another processes happened to be simultaneously
> > > reading the maps file.
> >
> > Yikes.  current_is_single_threaded() is expensive.  Are we sure this
> > isn't going to kill someone's workload?
>
> It's expensive only if mm_users > 1. We will go to for_each_process() only
> if somebody outside of the process grabs mm_users references (like reading
> /proc/PID/maps).

Yes,

> Or if it called it from multithreaded application.

Not really, please note the "negative fast-path" check:

if (atomic_read(&task->signal->live) != 1)  
return false;

> Acked-by: Kirill A. Shutemov 

Same here, I think the patch is fine.

I don't think that sys_setns() is performance critical, and Eric seems
to agree with this change too.

Oleg.

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

Re: [PATCH] ARM64: dts: mt6795: enable basic SMP bringup for MT6795

[Matthias Brugger]

On Tuesday, August 04, 2015 10:47:37 AM Scott Shu wrote:
> This patch adds support SMP on MediaTek MT6795 Cortex-A53 Octa-core SoC.

applied to v4.2-next/arm64-2

> 
> The patch is based on v4.2-rc1 and following patch series:
> (1) Mars Cheng's "Add mt6795 basic chip support" [1]
> 
> [1] https://lkml.org/lkml/2015/7/14/63

Please this extra information below the "---" as this should not show up in 
the commit message.

Thanks,
Matthias

> 
> Signed-off-by: Scott Shu 
> ---
>  arch/arm64/boot/dts/mediatek/mt6795.dtsi |   13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt6795.dtsi
> b/arch/arm64/boot/dts/mediatek/mt6795.dtsi index da200e7..c85659d 100644
> --- a/arch/arm64/boot/dts/mediatek/mt6795.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
> @@ -20,6 +20,11 @@
>   #address-cells = <2>;
>   #size-cells = <2>;
> 
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
>   cpus {
>   #address-cells = <1>;
>   #size-cells = <0>;
> @@ -27,48 +32,56 @@
>   cpu0: cpu@0 {
>   device_type = "cpu";
>   compatible = "arm,cortex-a53";
> + enable-method = "psci";
>   reg = <0x000>;
>   };
> 
>   cpu1: cpu@1 {
>   device_type = "cpu";
>   compatible = "arm,cortex-a53";
> + enable-method = "psci";
>   reg = <0x001>;
>   };
> 
>   cpu2: cpu@2 {
>   device_type = "cpu";
>   compatible = "arm,cortex-a53";
> + enable-method = "psci";
>   reg = <0x002>;
>   };
> 
>   cpu3: cpu@3 {
>   device_type = "cpu";
>   compatible = "arm,cortex-a53";
> + enable-method = "psci";
>   reg = <0x003>;
>   };
> 
>   cpu4: cpu@100 {
>   device_type = "cpu";
>   compatible = "arm,cortex-a53";
> + enable-method = "psci";
>   reg = <0x100>;
>   };
> 
>   cpu5: cpu@101 {
>   device_type = "cpu";
>   compatible = "arm,cortex-a53";
> + enable-method = "psci";
>   reg = <0x101>;
>   };
> 
>   cpu6: cpu@102 {
>   device_type = "cpu";
>   compatible = "arm,cortex-a53";
> + enable-method = "psci";
>   reg = <0x102>;
>   };
> 
>   cpu7: cpu@103 {
>   device_type = "cpu";
>   compatible = "arm,cortex-a53";
> + enable-method = "psci";
>   reg = <0x103>;
>   };
>   };

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

[PATCH 2/2] gpio/mxc: implement reading output gpio value

[Eduardo Valentin]

In current implementation, reading the value of an output gpio
always return 0. The reason is because when a gpio is configured
as output, its output status can be read from the GPIO_DR register,
and when it is configure as input, its value can be read from
GPIO_PSR. With current implementation of basic mmio gpio driver,
we can only read the value from one single register.

Therefore, to workaround the basic mmio gpio driver limitation,
this patch changes the gpio-mxc driver to provide its own .get
callback. In the callback, we check the current status of the
gpio direction, and read the correct register based on its
current gpio direction status.

Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: linux-g...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ulises Brindis 
Signed-off-by: Eduardo Valentin 
---
 drivers/gpio/gpio-mxc.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
index 9e5bdbd..8822823 100644
--- a/drivers/gpio/gpio-mxc.c
+++ b/drivers/gpio/gpio-mxc.c
@@ -401,6 +401,18 @@ static int mxc_gpio_to_irq(struct gpio_chip *gc, unsigned 
offset)
return irq_find_mapping(port->domain, offset);
 }
 
+static int mxc_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+   struct bgpio_chip *bgc = to_bgpio_chip(gc);
+
+   if (!!(bgc->read_reg(bgc->reg_dir) & bgc->pin2mask(bgc, gpio)))
+   return !!(bgc->read_reg(bgc->reg_set) &
+   bgc->pin2mask(bgc, gpio));
+   else
+   return !!(bgc->read_reg(bgc->reg_dat) &
+   bgc->pin2mask(bgc, gpio));
+}
+
 static int mxc_gpio_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
@@ -455,6 +467,7 @@ static int mxc_gpio_probe(struct platform_device *pdev)
if (err)
goto out_bgio;
 
+   port->bgc.gc.get = mxc_gpio_get;
port->bgc.gc.to_irq = mxc_gpio_to_irq;
port->bgc.gc.base = (pdev->id < 0) ? of_alias_get_id(np, "gpio") * 32 :
 pdev->id * 32;
-- 
2.5.0

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

[PATCH 1/2] gpio/mxc: mask gpio interrupts in suspend

[Eduardo Valentin]

From: Ulises Brindis 

Currently in the FSL platform all GPIO interrupts in a bank are muxed
into two GPIO lines to the GPC interrupt controller. In each GPIO bank
GPIOs 0-15 are OR'ed into one GPC interrupt controller interrupt and 16-31
are OR'ed into another. With the current code, if any of the 0-15 or
16-31 interrupts are marked as wakeup capable, all interrupts belonging
to that sub-bank (either 0-15 or 16-31) will wake up the device. This is
because interrupts are only being masked at the interrupt controller
and not at the GPIO controller.

This patch allows masking of GPIO interrupts at the GPIO controller during
suspend if they have not been labeled wakeup capable. This patch uses
preexisting IRQCHIP_MASK_ON_SUSPEND flag while initializing the GPIO
interrupts to get the desired behavior.

Cc: Linus Walleij 
Cc: Alexandre Courbot 
Cc: linux-g...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
Signed-off-by: Ulises Brindis 
---
 drivers/gpio/gpio-mxc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
index ec1eb1b..9e5bdbd 100644
--- a/drivers/gpio/gpio-mxc.c
+++ b/drivers/gpio/gpio-mxc.c
@@ -354,6 +354,7 @@ static void __init mxc_gpio_init_gc(struct mxc_gpio_port 
*port, int irq_base)
ct->chip.irq_unmask = irq_gc_mask_set_bit;
ct->chip.irq_set_type = gpio_set_irq_type;
ct->chip.irq_set_wake = gpio_set_wake_irq;
+   ct->chip.flags = IRQCHIP_MASK_ON_SUSPEND;
ct->regs.ack = GPIO_ISR;
ct->regs.mask = GPIO_IMR;
 
-- 
2.5.0

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

[PATCH 0/2] couple of fixes on IMX gpio driver

[Eduardo Valentin]

Hello all,

Here are two fixes on IMX GPIO driver. One is on
the way we handle GPIO irqs while going into suspend.
Another one is to be able to read the value
of an output GPIO.

Eduardo Valentin (1):
  gpio/mxc: implement reading output gpio value

Ulises Brindis (1):
  gpio/mxc: mask gpio interrupts in suspend

 drivers/gpio/gpio-mxc.c | 14 ++
 1 file changed, 14 insertions(+)

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

Enquiry

[Jin Alex Du]

Hello,
I will be in country with a couple of my co-workers and during our stay we will 
be needing your Scuba Diving lessons.. what are the various ways u charges for 
your service, is it hourly or daily?.

I await your reply.

Thanks
Jin Du.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 cgroup/for-4.3 3/3] cgroup: replace __DEVEL__sane_behavior with cgroup2 fs type

[Tejun Heo]

With major controllers - cpu, memory and io - shaping up for the
unified hierarchy, cgroup2 is about ready to be, gradually, released
into the wild.  Replace __DEVEL__sane_behavior flag which was used to
select the unified hierarchy with a separate filesystem type "cgroup2"
so that unified hierarchy can be mounted as follows.

  mount -t cgroup2 none $MOUNT_POINT

Signed-off-by: Tejun Heo 
Cc: Li Zefan 
Cc: Johannes Weiner 
---
 Documentation/cgroups/unified-hierarchy.txt |6 +--
 include/linux/cgroup-defs.h |1 
 kernel/cgroup.c |   43 +---
 3 files changed, 22 insertions(+), 28 deletions(-)

--- a/Documentation/cgroups/unified-hierarchy.txt
+++ b/Documentation/cgroups/unified-hierarchy.txt
@@ -94,11 +94,9 @@ the process.
 
 2-1. Mounting
 
-Currently, unified hierarchy can be mounted with the following mount
-command.  Note that this is still under development and scheduled to
-change soon.
+Unified hierarchy can be mounted with the following mount command.
 
- mount -t cgroup -o __DEVEL__sane_behavior cgroup $MOUNT_POINT
+ mount -t cgroup2 none $MOUNT_POINT
 
 All controllers which support the unified hierarchy and are not bound
 to other hierarchies are automatically bound to unified hierarchy and
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -66,7 +66,6 @@ enum {
 
 /* cgroup_root->flags */
 enum {
-   CGRP_ROOT_SANE_BEHAVIOR = (1 << 0), /* __DEVEL__sane_behavior specified 
*/
CGRP_ROOT_NOPREFIX  = (1 << 1), /* mounted subsystems have no named 
prefix */
CGRP_ROOT_XATTR = (1 << 2), /* supports extended attributes */
 };
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -183,6 +183,7 @@ static unsigned long have_exit_callback
 /* Ditto for the can_fork callback. */
 static unsigned long have_canfork_callback __read_mostly;
 
+static struct file_system_type cgroup2_fs_type;
 static struct cftype cgroup_dfl_base_files[];
 static struct cftype cgroup_legacy_base_files[];
 
@@ -1391,10 +1392,6 @@ static int parse_cgroupfs_options(char *
all_ss = true;
continue;
}
-   if (!strcmp(token, "__DEVEL__sane_behavior")) {
-   opts->flags |= CGRP_ROOT_SANE_BEHAVIOR;
-   continue;
-   }
if (!strcmp(token, "noprefix")) {
opts->flags |= CGRP_ROOT_NOPREFIX;
continue;
@@ -1461,15 +1458,6 @@ static int parse_cgroupfs_options(char *
return -ENOENT;
}
 
-   if (opts->flags & CGRP_ROOT_SANE_BEHAVIOR) {
-   pr_warn("sane_behavior: this is still under development and its 
behaviors will change, proceed at your own risk\n");
-   if (nr_opts != 1) {
-   pr_err("sane_behavior: no other mount options 
allowed\n");
-   return -EINVAL;
-   }
-   return 0;
-   }
-
/*
 * If the 'all' option was specified select all the subsystems,
 * otherwise if 'none', 'name=' and a subsystem name options were
@@ -1765,6 +1753,17 @@ static struct dentry *cgroup_mount(struc
if (!use_task_css_set_links)
cgroup_enable_task_cg_lists();
 
+   if (fs_type == &cgroup2_fs_type) {
+   if (data) {
+   pr_err("cgroup2: unknown option \"%s\"\n", (char 
*)data);
+   return ERR_PTR(-EINVAL);
+   }
+   cgrp_dfl_root_visible = true;
+   root = &cgrp_dfl_root;
+   cgroup_get(&root->cgrp);
+   goto out_mount;
+   }
+
mutex_lock(&cgroup_mutex);
 
/* First find the desired set of subsystems */
@@ -1772,15 +1771,6 @@ static struct dentry *cgroup_mount(struc
if (ret)
goto out_unlock;
 
-   /* look for a matching existing root */
-   if (opts.flags & CGRP_ROOT_SANE_BEHAVIOR) {
-   cgrp_dfl_root_visible = true;
-   root = &cgrp_dfl_root;
-   cgroup_get(&root->cgrp);
-   ret = 0;
-   goto out_unlock;
-   }
-
/*
 * Destruction of cgroup root is asynchronous, so subsystems may
 * still be dying after the previous unmount.  Let's drain the
@@ -1891,7 +1881,7 @@ out_free:
 
if (ret)
return ERR_PTR(ret);
-
+out_mount:
dentry = kernfs_mount(fs_type, flags, root->kf_root,
CGROUP_SUPER_MAGIC, &new_sb);
if (IS_ERR(dentry) || !new_sb)
@@ -1936,6 +1926,12 @@ static struct file_system_type cgroup_fs
.kill_sb = cgroup_kill_sb,
 };
 
+static struct file_system_type cgroup2_fs_type = {
+   .name = "cgroup2",
+   .mount = cgroup_mount,
+   .kill_sb = cgroup_kill_sb,
+};
+
 /**
  * task_cgroup_path - cgroup path of a task in the first cgroup hierarchy
  * @task:

Re: [PATCH cgroup/for-4.3 2/3] cgroup: drop cgroup__DEVEL__legacy_files_on_dfl

[Tejun Heo]

Now that interfaces for the major three controllers - cpu, memory, io
- are shaping up, there's no reason to have an option to force legacy
files to show up on the unified hierarchy for testing.  Drop it.

Signed-off-by: Tejun Heo 
Cc: Li Zefan 
Cc: Johannes Weiner 
---
 Documentation/cgroups/unified-hierarchy.txt |6 -
 kernel/cgroup.c |   30 +---
 2 files changed, 2 insertions(+), 34 deletions(-)

--- a/Documentation/cgroups/unified-hierarchy.txt
+++ b/Documentation/cgroups/unified-hierarchy.txt
@@ -107,12 +107,6 @@ root of unified hierarchy can be bound t
 allows mixing unified hierarchy with the traditional multiple
 hierarchies in a fully backward compatible way.
 
-For development purposes, the following boot parameter makes all
-controllers to appear on the unified hierarchy whether supported or
-not.
-
- cgroup__DEVEL__legacy_files_on_dfl
-
 A controller can be moved across hierarchies only after the controller
 is no longer referenced in its current hierarchy.  Because per-cgroup
 controller states are destroyed asynchronously and controllers may
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -152,12 +152,6 @@ struct cgroup_root cgrp_dfl_root;
  */
 static bool cgrp_dfl_root_visible;
 
-/*
- * Set by the boot param of the same name and makes subsystems with NULL
- * ->dfl_files to use ->legacy_files on the default hierarchy.
- */
-static bool cgroup_legacy_files_on_dfl;
-
 /* some controllers are not supported in the default hierarchy */
 static unsigned long cgrp_dfl_root_inhibit_ss_mask;
 
@@ -3340,17 +3334,8 @@ int cgroup_add_legacy_cftypes(struct cgr
 {
struct cftype *cft;
 
-   /*
-* If legacy_flies_on_dfl, we want to show the legacy files on the
-* dfl hierarchy but iff the target subsystem hasn't been updated
-* for the dfl hierarchy yet.
-*/
-   if (!cgroup_legacy_files_on_dfl ||
-   ss->dfl_cftypes != ss->legacy_cftypes) {
-   for (cft = cfts; cft && cft->name[0] != '\0'; cft++)
-   cft->flags |= __CFTYPE_NOT_ON_DFL;
-   }
-
+   for (cft = cfts; cft && cft->name[0] != '\0'; cft++)
+   cft->flags |= __CFTYPE_NOT_ON_DFL;
return cgroup_add_cftypes(ss, cfts);
 }
 
@@ -5055,9 +5040,6 @@ int __init cgroup_init(void)
 
cgrp_dfl_root.subsys_mask |= 1 << ss->id;
 
-   if (cgroup_legacy_files_on_dfl && !ss->dfl_cftypes)
-   ss->dfl_cftypes = ss->legacy_cftypes;
-
if (!ss->dfl_cftypes)
cgrp_dfl_root_inhibit_ss_mask |= 1 << ss->id;
 
@@ -5474,14 +5456,6 @@ static int __init cgroup_disable(char *s
 }
 __setup("cgroup_disable=", cgroup_disable);
 
-static int __init cgroup_set_legacy_files_on_dfl(char *str)
-{
-   printk("cgroup: using legacy files on the default hierarchy\n");
-   cgroup_legacy_files_on_dfl = true;
-   return 0;
-}
-__setup("cgroup__DEVEL__legacy_files_on_dfl", cgroup_set_legacy_files_on_dfl);
-
 /**
  * css_tryget_online_from_dir - get corresponding css from a cgroup dentry
  * @dentry: directory dentry of interest
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 cgroup/for-4.3 1/3] cgroup: replace error handling in cgroup_init() with WARN_ON()s

[Tejun Heo]

The init sequence shouldn't fail short of bugs and even when it does
it's better to continue with the rest of initialization and we were
silently ignoring /proc/cgroups creation failure.

Drop the explicit error handling and wrap sysfs_create_mount_point(),
register_filesystem() and proc_create() with WARN_ON()s.

Signed-off-by: Tejun Heo 
Cc: Li Zefan 
Cc: Johannes Weiner 
---
 kernel/cgroup.c |   15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -5014,7 +5014,7 @@ int __init cgroup_init(void)
 {
struct cgroup_subsys *ss;
unsigned long key;
-   int ssid, err;
+   int ssid;
 
BUG_ON(percpu_init_rwsem(&cgroup_threadgroup_rwsem));
BUG_ON(cgroup_init_cftypes(NULL, cgroup_dfl_base_files));
@@ -5072,17 +5072,10 @@ int __init cgroup_init(void)
ss->bind(init_css_set.subsys[ssid]);
}
 
-   err = sysfs_create_mount_point(fs_kobj, "cgroup");
-   if (err)
-   return err;
-
-   err = register_filesystem(&cgroup_fs_type);
-   if (err < 0) {
-   sysfs_remove_mount_point(fs_kobj, "cgroup");
-   return err;
-   }
+   WARN_ON(sysfs_create_mount_point(fs_kobj, "cgroup"));
+   WARN_ON(register_filesystem(&cgroup_fs_type));
+   WARN_ON(!proc_create("cgroups", 0, NULL, &proc_cgroupstats_operations));
 
-   proc_create("cgroups", 0, NULL, &proc_cgroupstats_operations);
return 0;
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] writeback: fix initial dirty limit

[Tejun Heo]

On Wed, Aug 05, 2015 at 07:08:40PM +0200, Rabin Vincent wrote:
> The initial value of global_wb_domain.dirty_limit set by
> writeback_set_ratelimit() is zeroed out by the memset in
> wb_domain_init().
> 
> Signed-off-by: Rabin Vincent 

Acked-by: Tejun Heo 

Thanks.

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

Re: [PATCH 2/2] MAINTAINERS: Explicitly add linux-arm-kernel for bcm2835

[Florian Fainelli]

On 22/07/15 12:55, Eric Anholt wrote:
> get_maintainers.pl would list linux-arm-kernel for most bcm2835
> changes because it's under arch/arm, but might not for other bcm2835
> drivers.  Most ARM architectures appear to list linux-arm-kernel as an
> appropriate list as well.
> 
> Signed-off-by: Eric Anholt 
> Suggested-by: Stephen Warren 

Also applied, thanks!
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sky2: Add module parameter for passing the MAC address

[Liviu Dudau]

On Wed, Aug 05, 2015 at 06:15:37PM +0100, Ryan Harkin wrote:
>On 5 August 2015 at 16:50, Liviu Dudau <[1]liviu.du...@arm.com> wrote:
> 
>  For designs where EEPROMs are not connected to PCI Yukon2
>  chips we need to get the MAC address from the firmware.
>  Add a module parameter called 'mac_address' for this. It
>  will be used if no DT node can be found and the B2_MAC
>  register holds an invalid value.
> 
>  Signed-off-by: Liviu Dudau <[2]liviu.du...@arm.com>
> 
>Looks good to me.  FWIW, you can have a tested or reviewed-by at your 
> preference:
>Tested-by: Ryan Harkin <[3]ryan.har...@linaro.org>
>Reviewed-by: Ryan Harkin <[4]ryan.har...@linaro.org>
> 

Thanks Ryan, I think one can provide both tags, so I will use them together.

Best regards,
Liviu

> 
> 
>  ---
>   drivers/net/ethernet/marvell/sky2.c | 14 +-
>   1 file changed, 13 insertions(+), 1 deletion(-)
> 
>  diff --git a/drivers/net/ethernet/marvell/sky2.c 
> b/drivers/net/ethernet/marvell/sky2.c
>  index d9f4498..a977d95 100644
>  --- a/drivers/net/ethernet/marvell/sky2.c
>  +++ b/drivers/net/ethernet/marvell/sky2.c
>  @@ -101,6 +101,10 @@ static int legacy_pme = 0;
>   module_param(legacy_pme, int, 0);
>   MODULE_PARM_DESC(legacy_pme, "Legacy power management");
> 
>  +/* Ugh!  Let the firmware tell us the hardware address */
>  +static int mac_address[ETH_ALEN] = { 0, };
>  +module_param_array(mac_address, int, NULL, 0);
>  +
>   static const struct pci_device_id sky2_id_table[] = {
>          { PCI_DEVICE(PCI_VENDOR_ID_SYSKONNECT, 0x9000) }, /* SK-9Sxx */
>          { PCI_DEVICE(PCI_VENDOR_ID_SYSKONNECT, 0x9E00) }, /* SK-9Exx */
>  @@ -4811,13 +4815,21 @@ static struct net_device 
> *sky2_init_netdev(struct sky2_hw *hw, unsigned port,
>          /* try to get mac address in the following order:
>           * 1) from device tree data
>           * 2) from internal registers set by bootloader
>  +        * 3) from the command line parameter
>           */
>          iap = of_get_mac_address(hw->pdev->dev.of_node);
>          if (iap)
>                  memcpy(dev->dev_addr, iap, ETH_ALEN);
>  -       else
>  +       else {
>                  memcpy_fromio(dev->dev_addr, hw->regs + B2_MAC_1 + port 
> * 8,
>                                ETH_ALEN);
>  +               if (!is_valid_ether_addr(&dev->dev_addr[0])) {
>  +                       int i;
>  +
>  +                       for (i = 0; i < ETH_ALEN; i++)
>  +                               dev->dev_addr[i] = mac_address[i];
>  +               }
>  +       }
> 
>          return dev;
>   }
>  --
>  2.4.6
> 
> References
> 
>Visible links
>1. mailto:liviu.du...@arm.com
>2. mailto:liviu.du...@arm.com
>3. mailto:ryan.har...@linaro.org
>4. mailto:ryan.har...@linaro.org

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

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

Re: [PATCH 1/2] MAINTAINERS: Add myself as a bcm2835 co-maintainer.

[Florian Fainelli]

On 22/07/15 12:55, Eric Anholt wrote:
> The current maintainers have limited free time to work on the
> architecture, and I'm motivated to do so for my work on graphics for
> Broadcom.  Arnd and Florian suggested to me that this might be the way
> forward.
> 
> Signed-off-by: Eric Anholt 

Applied to maintainers/next with Stephen's Ack at
github.com/Broadcom/stblinux, will submit this shortly with other
Broadcom SoC changes, thanks!

> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2d3d55c..1c51379 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2217,6 +2217,7 @@ F:  drivers/clocksource/bcm_kona_timer.c
>  BROADCOM BCM2835 ARM ARCHITECTURE
>  M:   Stephen Warren 
>  M:   Lee Jones 
> +M:   Eric Anholt 
>  L:   linux-rpi-ker...@lists.infradead.org (moderated for non-subscribers)
>  T:   git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
>  S:   Maintained
> 


-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sky2: Add module parameter for passing the MAC address

[Liviu Dudau]

On Wed, Aug 05, 2015 at 05:40:57PM +0100, Stephen Hemminger wrote:
> On Wed,  5 Aug 2015 16:50:54 +0100
> Liviu Dudau  wrote:
> 
> > For designs where EEPROMs are not connected to PCI Yukon2
> > chips we need to get the MAC address from the firmware.
> > Add a module parameter called 'mac_address' for this. It
> > will be used if no DT node can be found and the B2_MAC
> > register holds an invalid value.
> > 
> > Signed-off-by: Liviu Dudau 
> 
> Yes, I can see that this can be a real problem, and other drivers
> solve the problem. The standard method is to assign a random mac address
> (and then let scripts overwrite) rather than introducing module parameter.
> Module parameters are discouraged because they are device specific.
> 

I agree. However, in my case, the boards people have assigned MAC addresses
to the chip, they just didn't built the board in such a way as to allow one
to store that MAC address in a permanent way :( And no, I can't use the DT
because the chip is actually on the PCIe bus.

Even with the generation of a random address, it still needs to be copied
into the device, so I would guess that a version of the patch I've sent is
still relevant?

Best regards,
Liviu

>  
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

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

Re: [RFC V2 PATCH 0/1] kexec: crash_kexec_post_notifiers boot option related fixes

[Eric W. Biederman]

"河合英宏 / KAWAI，HIDEHIRO"   writes:

> Hello,
>
> Thanks for the reply.
>
>> From: Eric W. Biederman [mailto:ebied...@xmission.com]
> [...]
>> A specific hook for a very specific purpose when there is no other way
>> we can consider.
>
> So, is kmsg_dump like feature admissible?
>
>> If you don't have something that generalises well into a general purpose
>> operation that it makes sense for everyone to call you can always use
>> the world's largest aka you can run code before the new kernel starts
>> that is loaded with kexec_load.
>
> One of our purposes, notifying "I'm dying", would be achieved by purgatory
> code provided by kexec command as I stated before.  Since the way of the
> notification will differ from each vendor, I think we need to modify
> the purgatory codes pluggable.  Also, I think we need some parameter
> passing mechanism to the purgatory code.  For example, passing the panic
> message via boot parameter to save it to SEL.  Although I'm not sure
> we can do that (I've not investigated well yet).  Is that acceptable?

I think the address of panic message is available in crash notes.  If
not that is very reasonable to add.

Updating the SEL from purgatory after purgatory has validated the
checksums of the crash handling code is acceptable.

All that is desired is to run as little code as possible in a kernel
that is known broken.  Once the checksums have verified things in
purgatory you should be in good shape, and there is no possibility of
relying on broken infrastructure because that code simply is not present
in purgatory.

We already have a few early_printk style drivers in purgatory and I
don't the code to update the SEL would be much worse.

On the flip side there are enough firmware bugs that I personally would
not want to rely on firmware code running properly when the machine is
in a known broken state, so I don't want the SEL update to be
unconditional.

Eric


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

[PATCH] staging: comedi: improve comedi_check_chanlist() documentation

[Ian Abbott]

Signed-off-by: Ian Abbott 
---
 drivers/staging/comedi/range.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/range.c b/drivers/staging/comedi/range.c
index 6a393b2..ce3a58a 100644
--- a/drivers/staging/comedi/range.c
+++ b/drivers/staging/comedi/range.c
@@ -102,7 +102,18 @@ int do_rangeinfo_ioctl(struct comedi_device *dev,
  * @s: comedi_subdevice struct
  * @n: number of elements in the chanlist
  * @chanlist: the chanlist to validate
-*/
+ *
+ * Each element consists of a channel number, a range index, an analog
+ * reference type and some flags, all packed into an unsigned int.
+ *
+ * This checks that the channel number and range index are supported by
+ * the comedi subdevice.  It does not check whether the analog reference
+ * type and the flags are supported.  Drivers that care should check those
+ * themselves.
+ *
+ * Return: %0 if all @chanlist elements are valid (success),
+ * %-EINVAL if one or more elements are invalid.
+ */
 int comedi_check_chanlist(struct comedi_subdevice *s, int n,
  unsigned int *chanlist)
 {
-- 
2.4.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] watchdog: Add support for keepalives triggered by infrastructure

[David Teigland]

On Mon, Aug 03, 2015 at 07:13:26PM -0700, Guenter Roeck wrote:
> - Some watchdogs have a very short maximum timeout, in the range of just a few
>   seconds. Such low timeouts are difficult if not impossible to support from
>   user space. Drivers supporting such watchdog hardware need to implement
>   a timer function to augment heartbeats from user space.

> - A new status flag, WDOG_RUNNING, informs the watchdog subsystem that a
>   watchdog is running, and that the watchdog subsystem needs to generate
>   heartbeat requests while the associated watchdog device is closed.

> Patch #2 adds timer functionality to the watchdog core. It solves the problem
> of short maximum hardware timeouts by augmenting heartbeats triggered from
> user space with internally triggered heartbeats.
> 
> Patch #3 adds functionality to generate heartbeats while the watchdog device 
> is
> closed. It handles situation where where the watchdog is running after
> the driver has been instantiated, but the device is not yet opened,
> and post-close situations necessary if a watchdog can not be stopped.

These sound concerning because it seems that heartbeats could be generated
outside of the direct control of userspace.  I have a program that depends
on having direct control over whether heartbeats are generated (or more
specifically, *not* generated.)  If these new features introduce a new way
for heartbeats to be generated, is there a way I can detect or disable
that behavior from userspace?  Unwanted heartbeats could break my program
and may lead to data corruption.

A related issue from some years ago is the unfortunate fact that closing
the watchdog device also generates a heartbeat.  I'd like to disable that
also, and submitted a patch for it here:
http://www.spinics.net/lists/linux-watchdog/msg01477.html

(Without the patch, I have to work around it by closing the device
prematurely as a way to generate the potentially final heartbeat, and then
reopen it again if I want to continue the heartbeats.)

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

Re: [PATCH] ARM: BCM: Enable ARM erratum 798181 for BRCMSTB

[Florian Fainelli]

On 04/08/15 18:43, Gregory Fong wrote:
> Commit 04fcab32d3fa1d3f6afe97e0ab431c5572e07a2c ("ARM: 8111/1: Enable
> erratum 798181 for Broadcom Brahma-B15") enables this erratum for
> affected Broadcom Brahma-B15 CPUs when CONFIG_ARM_ERRATA_798181=y.
> Let's make sure that config option is actually set.
> 
> Signed-off-by: Gregory Fong 

Applied, to soc/next, thanks!
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] kmod: Cleanups, simplifications, and make isolation friendly v3

[Oleg Nesterov]

On 07/27, Frederic Weisbecker wrote:
>
> Hence those two debatable changes:
>
> _ We would like to use generic workqueues. System unbound workqueues are
>   a very good candidate but they are not wide affine, only node affine.
>   Now probably a node is enough to perform many parallel kmod jobs.
>
> _ We would like to remove the wait_for_helper kernel thread (UMH_WAIT_PROC
>   handler) to use the workqueue. It means that if the workqueue blocks,
>   and no other worker can take pending kmod request, we can be screwed.
>   Now if we have 512 threads, this should be enough.

I think this series is fine. Feel free to add my reviewed-by.

Oleg.

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

Re: [GIT PULL 0/3] phy: for 4.2 -rc

[Greg KH]

On Tue, Aug 04, 2015 at 10:17:41PM +0530, Kishon Vijay Abraham I wrote:
> Hi Greg,
> 
> Got a couple of more fixes for this -rc cycle. One fixes a compiler
> error when the driver is built as module and the other fixes a
> SATA lockup. The fix also requires a dts patch which I've included
> in this series after Tony's ACK. Please find the pull request below and
> consider merging in this -rc cycle.
> 
> Let me know If I have to modify something.
> 
> Cheers
> Kishon
> 
> The following changes since commit dcb54fcb3483862e993abdae99cec22fb3ae4099:
> 
>   phy: berlin-usb: fix divider for BG2 (2015-07-15 20:02:09 +0530)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
> tags/phy-for-4.2-rc6

Pulled and pushed out, thanks.

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

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

[Varun Sethi]

Hi Mark
Thanks for the patch. Please find my comment inline.

Regards
Varun

> -Original Message-
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of Mark Rutland
> Sent: Thursday, July 23, 2015 10:23 PM
> To: devicet...@vger.kernel.org
> Cc: Mark Rutland; lorenzo.pieral...@arm.com; a...@arndb.de;
> marc.zyng...@arm.com; will.dea...@arm.com; linux-
> ker...@vger.kernel.org; dda...@caviumnetworks.com; iommu@lists.linux-
> foundation.org; tirumalesh.chalama...@caviumnetworks.com;
> laurent.pinch...@ideasonboard.com; thunder.leiz...@huawei.com;
> tred...@nvidia.com; linux-arm-ker...@lists.infradead.org;
> majun...@huawei.com
> Subject: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings
> 
> Currently msi-parent is used by a few bindings to describe the relationship
> between a PCI root complex and a single MSI controller, but this property
> does not have a generic binding document.
> 
> Additionally, msi-parent is insufficient to describe more complex
> relationships between MSI controllers and devices under a root complex,
> where devices may be able to target multiple MSI controllers, or where MSI
> controllers use (non-probeable) sideband information to distinguish devices.
> 
> This patch adds a generic binding for mapping PCI devices to MSI controllers.
> This document covers msi-parent, and a new msi-map property (specific to
> PCI*) which may be used to map devices (identified by their Requester ID) to
> sideband data for each MSI controller that they may target.
> 
> Signed-off-by: Mark Rutland 
> ---
>  Documentation/devicetree/bindings/pci/pci-msi.txt | 220
> ++
>  1 file changed, 220 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/pci-msi.txt
> 
> diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt
> b/Documentation/devicetree/bindings/pci/pci-msi.txt
> new file mode 100644
> index 000..9b3cc81
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/pci-msi.txt
> @@ -0,0 +1,220 @@
> +This document describes the generic device tree binding for describing
> +the relationship between PCI devices and MSI controllers.
> +
> +Each PCI device under a root complex is uniquely identified by its
> +Requester ID (AKA RID). A Requester ID is a triplet of a Bus number,
> +Device number, and Function number.
> +
> +For the purpose of this document, when treated as a numeric value, a
> +RID is formatted such that:
> +
> +* Bits [15:8] are the Bus number.
> +* Bits [7:3] are the Device number.
> +* Bits [2:0] are the Function number.
> +* Any other bits required for padding must be zero.
> +
> +MSIs may be distinguished in part through the use of sideband data
> +accompanying writes. In the case of PCI devices, this sideband data may
> +be derived from the Requester ID. A mechanism is required to associate
> +a device with both the MSI controllers it can address, and the sideband
> +data that will be associated with its writes to those controllers.
> +
> +For generic MSI bindings, see
> +Documentation/devicetree/bindings/interrupt-controller/msi.txt.
> +
> +
> +PCI root complex
> +
> +
> +Optional properties
> +---
> +
> +- msi-map: Maps a Requester ID to an MSI controller and associated
> +  msi-specifier data. The property is an arbitrary number of tuples of
> +  (rid-base,msi-controller,msi-base,length), where:
[varun] How would we account for hot plug PCI devices and SR-IOV use cases, 
with the rid base and length?  How do we take in to account for a PCIe bridge, 
while setting up the requestor ID base and length?

> +
> +  * rid-base is a single cell describing the first RID matched by the entry.
> +
> +  * msi-controller is a single phandle to an MSI controller
> +
> +  * msi-base is an msi-specifier describing the msi-specifier produced for 
> the
> +first RID matched by the entry.
> +
> +  * length is a single cell describing how many consecutive RIDs are matched
> +following the rid-base.
> +
> +  Any RID r in the interval [rid-base, rid-base + length) is associated
> + with  the listed msi-controller, with the msi-specifier (r - rid-base + msi-
> base).
> +
> +- msi-map-mask: A mask to be applied to each Requester ID prior to
> +being mapped
> +  to an msi-specifier per the msi-map property.
> +
[varun] Can you please elaborate on a use case, where this would help. 



> +- msi-parent: Describes the MSI parent of the root complex itself.
> +Where
> +  the root complex and MSI controller do not pass sideband data with
> +MSI
> +  writes, this property may be used to describe the MSI controller(s)
> +  used by PCI devices under the root complex, if defined as such in the
> +  binding for the root complex.
> +
> +
> +Example (1)
> +===
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + msi: msi-controller@a {
> + reg = <0xa 0x1>;
> + compatible = "vendor,some-controller";
> +

[PATCH] iio: Documentation: Add trigger name attribute ABI documentation

[Cristina Opriceana]

This patch adds an entry in the ABI Documentation for the
name attribute issued when a trigger is created.

Signed-off-by: Cristina Opriceana 
---
 Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs 
b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
index 5235e6c..85c8e4d 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
+++ b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
@@ -9,3 +9,12 @@ Description:
automated testing or in situations, where other trigger methods
are not applicable. For example no RTC or spare GPIOs.
X is the IIO index of the trigger.
+
+What:  /sys/bus/iio/devices/triggerX/name
+KernelVersion: 2.6.39
+Contact:   linux-...@vger.kernel.org
+Description:
+   The name attribute holds a description string for the current
+   trigger. A device should write this name string to
+   /sys/bus/iio/devices/iio:deviceX/trigger/current_trigger
+   in order to use this trigger.
-- 
1.9.1

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

[PATCH] writeback: fix initial dirty limit

[Rabin Vincent]

The initial value of global_wb_domain.dirty_limit set by
writeback_set_ratelimit() is zeroed out by the memset in
wb_domain_init().

Signed-off-by: Rabin Vincent 
---
 mm/page-writeback.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 22cddd3..512 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -2063,10 +2063,10 @@ static struct notifier_block ratelimit_nb = {
  */
 void __init page_writeback_init(void)
 {
+   BUG_ON(wb_domain_init(&global_wb_domain, GFP_KERNEL));
+
writeback_set_ratelimit();
register_cpu_notifier(&ratelimit_nb);
-
-   BUG_ON(wb_domain_init(&global_wb_domain, GFP_KERNEL));
 }
 
 /**
-- 
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] kvm:arm:Fix error handling in the function vgic_v3_probe

[Paolo Bonzini]

On 05/08/2015 18:48, Nicholas Krause wrote:
> This fixes the error handling in the function vgic_v3_probe
> for when calling the function kvm_register_device_ops to check
> if the call to this function has returned a error code and if
> so jump to the label out with goto to cleanup no longer required
> resources used by the function vgic_v3_probe before returning the
> error code from the call to kvm_register_device_ops to the caller
> of the function vgic_v3_probe.
> 
> Signed-off-by: Nicholas Krause 
> ---
>  virt/kvm/arm/vgic-v3.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/virt/kvm/arm/vgic-v3.c b/virt/kvm/arm/vgic-v3.c
> index dff0602..5102aa2 100644
> --- a/virt/kvm/arm/vgic-v3.c
> +++ b/virt/kvm/arm/vgic-v3.c
> @@ -264,12 +264,16 @@ int vgic_v3_probe(struct device_node *vgic_node,
>   } else {
>   vgic->vcpu_base = vcpu_res.start;
>   vgic->can_emulate_gicv2 = true;
> - kvm_register_device_ops(&kvm_arm_vgic_v2_ops,
> - KVM_DEV_TYPE_ARM_VGIC_V2);
> + ret = kvm_register_device_ops(&kvm_arm_vgic_v2_ops,
> +   KVM_DEV_TYPE_ARM_VGIC_V2);
> + if (ret)
> + goto out;
>   }
>   if (vgic->vcpu_base == 0)
>   kvm_info("disabling GICv2 emulation\n");
> - kvm_register_device_ops(&kvm_arm_vgic_v3_ops, KVM_DEV_TYPE_ARM_VGIC_V3);
> + ret = kvm_register_device_ops(&kvm_arm_vgic_v3_ops, 
> KVM_DEV_TYPE_ARM_VGIC_V3);
> + if (ret)
> + goto out;
>  
>   vgic->vctrl_base = NULL;
>   vgic->type = VGIC_V3;
> 

This really should never happen.  Perhaps kvm_register_device_ops should
instead return void, and WARN() when it currently returns an error.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clocksource: sh_cmt: Only perform clocksource suspend/resume if enabled

[Daniel Lezcano]

On 08/05/2015 03:56 PM, Geert Uytterhoeven wrote:

Hi Daniel,

On Thu, Jul 16, 2015 at 4:03 PM, Geert Uytterhoeven
 wrote:

On Thu, Jul 16, 2015 at 3:41 PM, Daniel Lezcano
 wrote:

do you mean to test if the patch [1] solves your problem.

   -- Daniel

[1] https://lkml.org/lkml/2015/1/16/81


I'll give it a try after my holidays...


Apparently that patch was integrated in v4.2-rc1, while I still see the problem
on recent kernels.

Furthermore, that patch handles clockevents, not clocksources.
struct clocksource doesn't seem to have a way to check if it's enabled,
so I still need my patch.


Hmm, I see. I will take this patch as a fix then.

Thanks.
  -- Daniel


--
  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: [Consult] cris: arch-v10: About $dtp0 register

[Hans-Peter Nilsson]

> From: Chen Gang 
> Date: Wed, 5 Aug 2015 16:39:00 +0200

> On 8/5/15 12:32, Hans-Peter Nilsson wrote:
> >> From: Chen Gang 
> >> Date: Mon, 20 Jul 2015 23:32:52 +0200
> > 
> >> On 7/9/15 08:44, Chen Gang wrote:
> >> The latest upstream cris gcc will cause issue for next-20150720 with
> >> allmodconfig (although it can let next-20150702 pass allmodconfig):
> >>
> >> CC [M]  kernel/rcu/rcutorture.o
> > [...]
> >>   include/linux/rcutiny.h:55:20: internal compiler error: Segmentation 
> >> fault
> >>static inline void rcu_barrier_sched(void)
> >>   ^
> >>   0xad879f crash_signal
> >> ../../gcc/gcc/toplev.c:352
> >>   0xbf0fb8 tree_check(tree_node*, char const*, int, char const*, tree_code)
> >> ../../gcc/gcc/tree.h:2857
> >>   0xbf0fb8 fold_builtin_alloca_with_align
> >> ../../gcc/gcc/tree-ssa-ccp.c:2110
> > [...]
> > 
> >> If no any additional response, I shall try to fix it in the next month.
> > 
> > No need to enter a new bug report, this appears to be
> > .  It is also observed for other
> > ports, at least with the original C++ test-case there.  I added
> > a reduced rcutorture.c to the bug-report.  Thanks.
> > 
> 
> OK, thanks. :-)
> 
> And next, I shall try to cross compile kernel for another archs, hope I
> can start in 2015-08-15 -- during these days I am trying tilegx qemu for
> gcc testsuite (mainly for floating point insns and pending issues).

(Hopefully on-topic as the bug is likely to appear for multiple targets:)

Or pick up any gcc-6.0 snapshot later than or equal to r226616,
as a fix is now committed.  I just verified that the fix covers
the original and reduced kernel test-cases.  The fix is not on
the 5.x branch yet but I believe it is likely to be back-ported
in time for 5.3.

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