Re: [PATCH v2 1/9] llist: Provide a safe version for llist_for_each

[Byungchul Park]

On Mon, Feb 13, 2017 at 03:52:44PM +0800, Huang, Ying wrote:
> Byungchul Park  writes:
> 
> > On Mon, Feb 13, 2017 at 03:36:33PM +0800, Huang, Ying wrote:
> >> Byungchul Park  writes:
> >> 
> >> > Sometimes we have to dereference next field of llist node before entering
> >> > loop becasue the node might be deleted or the next field might be
> >> > modified within the loop. So this adds the safe version of 
> >> > llist_for_each,
> >> > that is, llist_for_each_safe.
> >> >
> >> > Signed-off-by: Byungchul Park 
> >> > ---
> >> >  include/linux/llist.h | 19 +++
> >> >  1 file changed, 19 insertions(+)
> >> >
> >> > diff --git a/include/linux/llist.h b/include/linux/llist.h
> >> > index fd4ca0b..4c508a5 100644
> >> > --- a/include/linux/llist.h
> >> > +++ b/include/linux/llist.h
> >> > @@ -105,6 +105,25 @@ static inline void init_llist_head(struct 
> >> > llist_head *list)
> >> >  for ((pos) = (node); pos; (pos) = (pos)->next)
> >> >  
> >> >  /**
> >> > + * llist_for_each_safe - iterate over some deleted entries of a 
> >> > lock-less list
> >> > + *   safe against removal of list entry
> >> > + * @pos:the &struct llist_node to use as a loop cursor
> >> > + * @n:  another type * to use as temporary storage
> >> 
> >> s/type */&struct llist_node/
> >
> > Yes.
> >
> >> 
> >> > + * @node:   the first entry of deleted list entries
> >> > + *
> >> > + * In general, some entries of the lock-less list can be traversed
> >> > + * safely only after being deleted from list, so start with an entry
> >> > + * instead of list head.
> >> > + *
> >> > + * If being used on entries deleted from lock-less list directly, the
> >> > + * traverse order is from the newest to the oldest added entry.  If
> >> > + * you want to traverse from the oldest to the newest, you must
> >> > + * reverse the order by yourself before traversing.
> >> > + */
> >> > +#define llist_for_each_safe(pos, n, node)   \
> >> > +for ((pos) = (node); (pos) && ((n) = (pos)->next, true); (pos) 
> >> > = (n))
> >> > +
> >> 
> >> Following the style of other xxx_for_each_safe,
> >> 
> >> #define llist_for_each_safe(pos, n, node)  \
> >>for (pos = (node), (pos && (n = pos->next)); pos; pos = n, n = 
> >> pos->next)
> >
> > Do you think it should be modified? I think mine is simpler. No?
> 
> Personally I prefer the style of other xxx_for_each_safe().

Yes, I will modify it as you recommand.

Thank you very much.

> 
> Best Regards,
> Huang, Ying
> 
> >> 
> >> Best Regards,
> >> Huang, Ying
> >> 
> >> > +/**
> >> >   * llist_for_each_entry - iterate over some deleted entries of 
> >> > lock-less list of given type
> >> >   * @pos:the type * to use as a loop cursor.
> >> >   * @node:   the fist entry of deleted list entries.

Re: [PATCH v3 1/2] mtd: ifc: Update dependency of IFC for LS1021A

[Boris Brezillon]

On Mon, 13 Feb 2017 07:39:41 +
Alison Wang  wrote:

> Hi, Boris,
> 
>   Sorry, I forgot to change them. Should I resend them or you help to fix 
> that when applying?

I can fix that when applying, no need to resend.
Note that you missed 4.11 (already sent my PR to Brian), I'll queue it
for 4.12.

Regards,

Boris

> 
> 
> Best Regards,
> Alison Wang
> 
> > 
> > Hi Alison,
> > 
> > The subject prefix is still wrong, should be 'memory: ifc: '.
> > 
> > On Mon, 13 Feb 2017 14:46:55 +0800
> > Alison Wang  wrote:
> >   
> > > As Freescale/NXP IFC controller is available on LS1021A, the
> > > dependency for LS1021A is added.
> > >
> > > LS1021A is an earlier product and is not compatible with later
> > > LayerScape architecture. So ARCH_LAYERSCAPE can't cover LS1021A.
> > >
> > > Signed-off-by: Alison Wang 
> > > ---
> > > Changes in v3:
> > > - Update the commit message.
> > >
> > > Changes in v2:
> > > - New patch
> > >
> > >  drivers/memory/Kconfig | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index
> > > ec80e35..fff8345 100644
> > > --- a/drivers/memory/Kconfig
> > > +++ b/drivers/memory/Kconfig
> > > @@ -115,7 +115,7 @@ config FSL_CORENET_CF
> > >
> > >  config FSL_IFC
> > >   bool
> > > - depends on FSL_SOC || ARCH_LAYERSCAPE
> > > + depends on FSL_SOC || ARCH_LAYERSCAPE || SOC_LS1021A
> > >
> > >  config JZ4780_NEMC
> > >   bool "Ingenic JZ4780 SoC NEMC driver"  
> 

Re: [PATCH V4 2/2] Move stack parameters for sed_ioctl to prevent oversized stack with CONFIG_KASAN

[Christoph Hellwig]

>  int sed_ioctl(struct opal_dev *dev, unsigned int cmd, unsigned long ptr)
>  {
> + void *ioctl_ptr;
> + int ret = -ENOTTY;
>   void __user *arg = (void __user *)ptr;

Can we use this opportunity to clean up the usual ioctl argument mess.
Id say pass the "void __user *argp" argument already (nvme_ioctl should
have a local variable for it anyway), and then just rename ioctl_ptr
variable to the usual short p.

> + unsigned int cmd_size = _IOC_SIZE(cmd);
>  

> + ioctl_ptr = memdup_user(arg, cmd_size);

cmd_size is only used once, so why not opencode the expression in the
argument to memdup_user.

Re: [PATCH] spi-nor: use ERR_CAST in return

[Boris Brezillon]

On Mon, 13 Feb 2017 07:35:52 +
Nicholas Mc Guire  wrote:

> On Sun, Feb 12, 2017 at 11:04:10PM +0100, Boris Brezillon wrote:
> > +Mika
> > 
> > On Sun, 12 Feb 2017 22:45:43 +0100
> > Boris Brezillon  wrote:
> >   
> > > On Sun, 12 Feb 2017 17:43:43 +0100
> > > Nicholas Mc Guire  wrote:
> > >   
> > > > This fixes a sparse warning about 
> > > 
> > > Your commit message seems to be incomplete.  
> > 
> > And here too, please change the prefix to "mtd: spi-nor: intel: ".
> >  
> 
> What Im doing for checking prefix is:
> hofrat@debian:~/git/linux-next$ git log --oneline 
> drivers/mtd/spi-nor/intel-spi.c
> 8afda8b spi-nor: Add support for Intel SPI serial flash controller
> 
> is the method of checking the commit prefix with git log --oneline 
> inapropriate ?

It's appropriate, except in this case. You're referring to the commit
introducing a new driver, so this is expected to not find the
'intel:' suffix, but you have 'Add support for Intel SPI serial flash
controller' to clarify the scope.

Regarding the "mtd: " prefix, I think it's better to have it, but
apparently Cyrille is not enforcing that.

> How would I have found the "mtd: spi-nor: intel:" in this case ?

Well, it's a mix of common sense and 'git log --oneline' use :-). Here
you're only modifying the intel driver, but nothing in your subject
mentions it.

Re: [PATCH v2 1/9] llist: Provide a safe version for llist_for_each

[Huang, Ying]

Byungchul Park  writes:

> On Mon, Feb 13, 2017 at 03:36:33PM +0800, Huang, Ying wrote:
>> Byungchul Park  writes:
>> 
>> > Sometimes we have to dereference next field of llist node before entering
>> > loop becasue the node might be deleted or the next field might be
>> > modified within the loop. So this adds the safe version of llist_for_each,
>> > that is, llist_for_each_safe.
>> >
>> > Signed-off-by: Byungchul Park 
>> > ---
>> >  include/linux/llist.h | 19 +++
>> >  1 file changed, 19 insertions(+)
>> >
>> > diff --git a/include/linux/llist.h b/include/linux/llist.h
>> > index fd4ca0b..4c508a5 100644
>> > --- a/include/linux/llist.h
>> > +++ b/include/linux/llist.h
>> > @@ -105,6 +105,25 @@ static inline void init_llist_head(struct llist_head 
>> > *list)
>> >for ((pos) = (node); pos; (pos) = (pos)->next)
>> >  
>> >  /**
>> > + * llist_for_each_safe - iterate over some deleted entries of a lock-less 
>> > list
>> > + * safe against removal of list entry
>> > + * @pos:  the &struct llist_node to use as a loop cursor
>> > + * @n:another type * to use as temporary storage
>> 
>> s/type */&struct llist_node/
>
> Yes.
>
>> 
>> > + * @node: the first entry of deleted list entries
>> > + *
>> > + * In general, some entries of the lock-less list can be traversed
>> > + * safely only after being deleted from list, so start with an entry
>> > + * instead of list head.
>> > + *
>> > + * If being used on entries deleted from lock-less list directly, the
>> > + * traverse order is from the newest to the oldest added entry.  If
>> > + * you want to traverse from the oldest to the newest, you must
>> > + * reverse the order by yourself before traversing.
>> > + */
>> > +#define llist_for_each_safe(pos, n, node) \
>> > +  for ((pos) = (node); (pos) && ((n) = (pos)->next, true); (pos) = (n))
>> > +
>> 
>> Following the style of other xxx_for_each_safe,
>> 
>> #define llist_for_each_safe(pos, n, node)\
>>  for (pos = (node), (pos && (n = pos->next)); pos; pos = n, n = 
>> pos->next)
>
> Do you think it should be modified? I think mine is simpler. No?

Personally I prefer the style of other xxx_for_each_safe().

Best Regards,
Huang, Ying

>> 
>> Best Regards,
>> Huang, Ying
>> 
>> > +/**
>> >   * llist_for_each_entry - iterate over some deleted entries of lock-less 
>> > list of given type
>> >   * @pos:  the type * to use as a loop cursor.
>> >   * @node: the fist entry of deleted list entries.

Re: [PATCH V4 1/2] uapi: sed-opal fix IOW for activate lsp to use correct struct

[Christoph Hellwig]

Looks fine,

Reviewed-by: Christoph Hellwig 

Re: [PATCH v6 7/8] uapi: export all headers under uapi directories

[Christoph Hellwig]

> linux/genwqe/..install.cmd
> linux/genwqe/.install

Third time:  NAK on exporting internal kbuild metadata.

RE: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

[Dexuan Cui]

> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Saturday, February 11, 2017 02:02
>  ...
> That's important if the stuff happens cross CPU. If the update happens on
> the same CPU then this is a different story and as there are VMexits
> involved they might provide the required ordering already. But I can't tell
> as I have no idea how that host side thing is done.
> 
>   tglx

IMO Hyper-V TSC page clocksource here seems pretty similar to KVM's pvclock,
So I would guess "the structure is only updated just before reentering the guest
after some VM event" (https://rwmj.wordpress.com/2010/10/15/kvm-pvclock/),
that is, the update should happen on the same CPU, I guess.

Thanks,
-- Dexuan

Re: [PATCH v2 5/6] drm: convert drivers to use drm_of_find_panel_or_bridge

[Boris Brezillon]

On Thu,  9 Feb 2017 13:05:57 -0600
Rob Herring  wrote:

> Similar to the previous commit, convert drivers open coding OF graph
> parsing to use drm_of_find_panel_or_bridge instead.
> 
> This changes some error messages to debug messages (in the graph core).
> Graph connections are often "no connects" depending on the particular
> board, so we want to avoid spurious messages. Plus the kernel is not a
> DT validator.
> 
> Signed-off-by: Rob Herring 
> ---
> v2:
> - fix wrong node ptr in imx-ldb
> - build fixes in kirin and imx drivers
> 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 64 -
>  drivers/gpu/drm/bridge/nxp-ptn3460.c | 16 ++---
>  drivers/gpu/drm/bridge/parade-ps8622.c   | 16 ++---
>  drivers/gpu/drm/bridge/tc358767.c| 27 +--
>  drivers/gpu/drm/exynos/exynos_dp.c   | 35 -
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 49 -
>  drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 27 ++-
>  drivers/gpu/drm/imx/imx-ldb.c| 27 ++-
>  drivers/gpu/drm/imx/parallel-display.c   | 36 ++
>  drivers/gpu/drm/mediatek/mtk_dsi.c   | 23 ++
>  drivers/gpu/drm/mxsfb/mxsfb_out.c| 36 ++
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c  | 26 ++-
>  drivers/gpu/drm/sun4i/sun4i_rgb.c| 13 ++--
>  drivers/gpu/drm/sun4i/sun4i_tcon.c   | 90 
> ++--
>  14 files changed, 88 insertions(+), 397 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> index 6119b5085501..4614048a4935 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> @@ -22,7 +22,7 @@
>  #include 
> 
>  #include 
> -#include 
> +#include 
> 
>  #include "atmel_hlcdc_dc.h"
> 
> @@ -152,29 +152,11 @@ static const struct drm_connector_funcs 
> atmel_hlcdc_panel_connector_funcs = {
>   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>  };
> 
> -static int atmel_hlcdc_check_endpoint(struct drm_device *dev,
> -   const struct of_endpoint *ep)
> -{
> - struct device_node *np;
> - void *obj;
> -
> - np = of_graph_get_remote_port_parent(ep->local_node);
> -
> - obj = of_drm_find_panel(np);
> - if (!obj)
> - obj = of_drm_find_bridge(np);
> -
> - of_node_put(np);
> -
> - return obj ? 0 : -EPROBE_DEFER;
> -}
> -
>  static int atmel_hlcdc_attach_endpoint(struct drm_device *dev,
> -const struct of_endpoint *ep)
> +const struct device_node *np)
>  {
>   struct atmel_hlcdc_dc *dc = dev->dev_private;
>   struct atmel_hlcdc_rgb_output *output;
> - struct device_node *np;
>   struct drm_panel *panel;
>   struct drm_bridge *bridge;
>   int ret;
> @@ -195,13 +177,11 @@ static int atmel_hlcdc_attach_endpoint(struct 
> drm_device *dev,
> 
>   output->encoder.possible_crtcs = 0x1;
> 
> - np = of_graph_get_remote_port_parent(ep->local_node);
> -
> - ret = -EPROBE_DEFER;
> + ret = drm_of_find_panel_or_bridge(np, 0, 0, &panel, &bridge);
> + if (ret)
> + return ret;
> 
> - panel = of_drm_find_panel(np);
>   if (panel) {
> - of_node_put(np);
>   output->connector.dpms = DRM_MODE_DPMS_OFF;
>   output->connector.polled = DRM_CONNECTOR_POLL_CONNECT;
>   drm_connector_helper_add(&output->connector,
> @@ -226,9 +206,6 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
> *dev,
>   return 0;
>   }
> 
> - bridge = of_drm_find_bridge(np);
> - of_node_put(np);
> -
>   if (bridge) {
>   output->encoder.bridge = bridge;
>   bridge->encoder = &output->encoder;
> @@ -245,31 +222,14 @@ static int atmel_hlcdc_attach_endpoint(struct 
> drm_device *dev,
> 
>  int atmel_hlcdc_create_outputs(struct drm_device *dev)
>  {
> - struct device_node *ep_np = NULL;
> - struct of_endpoint ep;
> + struct device_node *remote;
>   int ret;
> 
> - for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
> - ret = of_graph_parse_endpoint(ep_np, &ep);
> - if (!ret)
> - ret = atmel_hlcdc_check_endpoint(dev, &ep);
> -
> - if (ret) {
> - of_node_put(ep_np);
> - return ret;
> - }
> - }
> -
> - for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
> - ret = of_graph_parse_endpoint(ep_np, &ep);
> - if (!ret)
> - ret = atmel_hlcdc_attach_endpoint(dev, &ep);
> -
> - if (ret) {
> - of_node_put(ep_np);
> - return ret;
> - }
> - }
> + remote = of_graph_get_remote_node(dev->dev

Re: [PATCH v2] gpio: return NULL from gpiod_get_optional when GPIOLIB is disabled

[Uwe Kleine-König]

Hello,

On Sun, Feb 12, 2017 at 05:15:01PM -0800, Dmitry Torokhov wrote:
> On Sun, Feb 12, 2017 at 05:13:55PM -0800, Dmitry Torokhov wrote:
> > Given the intent behind gpiod_get_optional() and friends it does not make
> > sense to return -ENOSYS when GPIOLIB is disabled: the driver is expected to
> > work just fine without gpio so let's behave as if gpio was not found.
> > Otherwise we have to special-case -ENOSYS in drivers.
> > 
> > Note that there was objection that someone might forget to enable GPIOLIB
> > when dealing with a platform that has device that actually specifies
> > optional gpio and we'll break it. I find this unconvincing as that would
> > have to be the *only GPIO* in the system, which is extremely unlikely.
> > 
> > Suggested-by: Uwe Kleine-König 

I don't like this patch and so I wonder what I wrote that could be
interpreted as suggesting this patch. For now I'd say only

Nacked-by: Uwe Kleine-König 

is justified.

My concern is still there. This might break some setups. IMHO it's not
ok to request that a device in a certain configuration only works when
the (optional) Kconfig option GPIOLIB is enabled and silently breaks if
it's not. And you cannot rely on the person who configured the kernel.

When accepting this you will burn debug time of others who see their
device breaking with no or unrelated error messages.

The only reliable way out here is to enable enough of GPIOLIB to only
return NULL in ..._optional when there is no gpio required. You can have
a suggested-by for that.

The semantic of gpiod_get_optional is:

if there is a gpio:
give it to me
else:
give me a dummy

If the kernel is configured to be unable to answer the question "is
there a gpio?" that is worth a -ENOSYS.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [PATCH v2 1/9] llist: Provide a safe version for llist_for_each

[Byungchul Park]

On Mon, Feb 13, 2017 at 03:36:33PM +0800, Huang, Ying wrote:
> Byungchul Park  writes:
> 
> > Sometimes we have to dereference next field of llist node before entering
> > loop becasue the node might be deleted or the next field might be
> > modified within the loop. So this adds the safe version of llist_for_each,
> > that is, llist_for_each_safe.
> >
> > Signed-off-by: Byungchul Park 
> > ---
> >  include/linux/llist.h | 19 +++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/include/linux/llist.h b/include/linux/llist.h
> > index fd4ca0b..4c508a5 100644
> > --- a/include/linux/llist.h
> > +++ b/include/linux/llist.h
> > @@ -105,6 +105,25 @@ static inline void init_llist_head(struct llist_head 
> > *list)
> > for ((pos) = (node); pos; (pos) = (pos)->next)
> >  
> >  /**
> > + * llist_for_each_safe - iterate over some deleted entries of a lock-less 
> > list
> > + *  safe against removal of list entry
> > + * @pos:   the &struct llist_node to use as a loop cursor
> > + * @n: another type * to use as temporary storage
> 
> s/type */&struct llist_node/

Yes.

> 
> > + * @node:  the first entry of deleted list entries
> > + *
> > + * In general, some entries of the lock-less list can be traversed
> > + * safely only after being deleted from list, so start with an entry
> > + * instead of list head.
> > + *
> > + * If being used on entries deleted from lock-less list directly, the
> > + * traverse order is from the newest to the oldest added entry.  If
> > + * you want to traverse from the oldest to the newest, you must
> > + * reverse the order by yourself before traversing.
> > + */
> > +#define llist_for_each_safe(pos, n, node)  \
> > +   for ((pos) = (node); (pos) && ((n) = (pos)->next, true); (pos) = (n))
> > +
> 
> Following the style of other xxx_for_each_safe,
> 
> #define llist_for_each_safe(pos, n, node) \
>   for (pos = (node), (pos && (n = pos->next)); pos; pos = n, n = 
> pos->next)

Do you think it should be modified? I think mine is simpler. No?

> 
> Best Regards,
> Huang, Ying
> 
> > +/**
> >   * llist_for_each_entry - iterate over some deleted entries of lock-less 
> > list of given type
> >   * @pos:   the type * to use as a loop cursor.
> >   * @node:  the fist entry of deleted list entries.

Re: [PATCH RFC] spi-nor: provide a range for poll_timout

[Nicholas Mc Guire]

On Sun, Feb 12, 2017 at 10:59:23PM +0100, Boris Brezillon wrote:
> +Mika
> 
> On Sun, 12 Feb 2017 17:42:57 +0100
> Nicholas Mc Guire  wrote:
> 
> > The overall poll time here is INTEL_SPI_TIMEOUT * 1000 which is 
> > 5000 * 1000 - so 5seconds and it is coded as a tight loop here delay_us
> > to readl_poll_timeout() is set to 0. As this is never called in an atomic
> > context sleeping should be no issue and there is no reasons for the
> > tight-loop here.
> 
> Hm, let's wait for Mika's feedback on this one. BTW, can you please Cc
> him on you other spi-nor/intel patches and prefix your patches with the
> driver name ('mtd: spi-nor: intel: ') so that we know where the changes
> are made (without this prefix it looks like you're touching core files)?
>

will do - just saw that his email shows up in git plame which I normally also 
include along with what scripts/get_maintainer.pl -f shows - sorry for the 
ommision.

thx!
hofrat
 
> 
> > 
> > Signed-off-by: Nicholas Mc Guire 
> > ---
> > 
> > Problem located by experimental coccinelle script:
> > ./drivers/mtd/spi-nor/intel-spi.c:265:8-26: WARNING: usleep_range min=0 for 
> > delay INTEL_SPI_TIMEOUT * 1000
> > ./drivers/mtd/spi-nor/intel-spi.c:274:8-26: WARNING: usleep_range min=0 for 
> > delay INTEL_SPI_TIMEOUT * 1000
> > 
> > The rational for setting the delay_us here to 40 is that 
> > readx_poll_timeout()
> > will take delay_us >> 2 + 1 as min value and that should be at least 10us 
> > (see
> > Documentation/timers/timers-howto.txt). Ideally the delay would be made
> > even larger to keep the load on the hrtimer subsystem low as these delays
> > here do not seem to be critical. Someone that knows the details of this 
> > device
> > would need to check if a larger delay would be ok here.
> > 
> > Patch was compile tested with: multi_v7_defconfig (implies 
> > CONFIG_MTD_SPI_NOR=y)
> > one coccicheck finding reported and one spars finding (in separate patches)
> > 
> > Patch is against 4.10-rc6 (localversion-next is next-20170210)
> > 
> >  drivers/mtd/spi-nor/intel-spi.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/mtd/spi-nor/intel-spi.c 
> > b/drivers/mtd/spi-nor/intel-spi.c
> > index a10f602..371bcf9 100644
> > --- a/drivers/mtd/spi-nor/intel-spi.c
> > +++ b/drivers/mtd/spi-nor/intel-spi.c
> > @@ -263,7 +263,7 @@ static int intel_spi_wait_hw_busy(struct intel_spi 
> > *ispi)
> > u32 val;
> >  
> > return readl_poll_timeout(ispi->base + HSFSTS_CTL, val,
> > - !(val & HSFSTS_CTL_SCIP), 0,
> > + !(val & HSFSTS_CTL_SCIP), 40,
> >   INTEL_SPI_TIMEOUT * 1000);
> >  }
> >  
> > @@ -272,7 +272,7 @@ static int intel_spi_wait_sw_busy(struct intel_spi 
> > *ispi)
> > u32 val;
> >  
> > return readl_poll_timeout(ispi->sregs + SSFSTS_CTL, val,
> > - !(val & SSFSTS_CTL_SCIP), 0,
> > + !(val & SSFSTS_CTL_SCIP), 40,
> >   INTEL_SPI_TIMEOUT * 1000);
> >  }
> >  
> 

RE: [PATCH v3 1/2] mtd: ifc: Update dependency of IFC for LS1021A

[Alison Wang]

Hi, Boris,

Sorry, I forgot to change them. Should I resend them or you help to fix 
that when applying?


Best Regards,
Alison Wang

> 
> Hi Alison,
> 
> The subject prefix is still wrong, should be 'memory: ifc: '.
> 
> On Mon, 13 Feb 2017 14:46:55 +0800
> Alison Wang  wrote:
> 
> > As Freescale/NXP IFC controller is available on LS1021A, the
> > dependency for LS1021A is added.
> >
> > LS1021A is an earlier product and is not compatible with later
> > LayerScape architecture. So ARCH_LAYERSCAPE can't cover LS1021A.
> >
> > Signed-off-by: Alison Wang 
> > ---
> > Changes in v3:
> > - Update the commit message.
> >
> > Changes in v2:
> > - New patch
> >
> >  drivers/memory/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index
> > ec80e35..fff8345 100644
> > --- a/drivers/memory/Kconfig
> > +++ b/drivers/memory/Kconfig
> > @@ -115,7 +115,7 @@ config FSL_CORENET_CF
> >
> >  config FSL_IFC
> > bool
> > -   depends on FSL_SOC || ARCH_LAYERSCAPE
> > +   depends on FSL_SOC || ARCH_LAYERSCAPE || SOC_LS1021A
> >
> >  config JZ4780_NEMC
> > bool "Ingenic JZ4780 SoC NEMC driver"

Re: [PATCH v3 2/2] gpio: mockup: implement event injecting over debugfs

[Linus Walleij]

On Mon, Feb 6, 2017 at 3:11 PM, Bartosz Golaszewski
 wrote:

> Create a debugfs directory for every mockup chip and a single file
> for every line. Writing (0 or 1) to these files allows the user to
> inject line events (falling or rising edge respectively).
>
> Signed-off-by: Bartosz Golaszewski 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH] spi-nor: use true/false for bool

[Nicholas Mc Guire]

On Sun, Feb 12, 2017 at 11:01:44PM +0100, Boris Brezillon wrote:
> +Mika
> 
> On Sun, 12 Feb 2017 22:50:44 +0100
> Boris Brezillon  wrote:
> 
> > On Sun, 12 Feb 2017 17:43:31 +0100
> > Nicholas Mc Guire  wrote:
> > 
> > > writeable in struct intel_spi is a boolean and assignment should be to 
> > > true/false not 1/0 as recommended by boolinit.cocci.
> > > 
> > > Signed-off-by: Nicholas Mc Guire   
> > 
> > Acked-by: Boris Brezillon 
> 
> As asked in my other review, please use the 'mtd: spi-nor: intel'
> prefix (or anything that would clarify the scope of this patch, like
> 'mtd: spi-nor/intel: ').
>

yup - will fix it up - just not yet clear how
to find the proper prefix next time - the method I
had been using seems insufficient.

thx!
hofrat
 
> 
> > 
> > > ---
> > > 
> > > make coccicheck complained with:
> > >  ./drivers/mtd/spi-nor/intel-spi.c:707:3-18: WARNING: Assignment of bool 
> > > to 0/1
> > > 
> > > Patch was compile tested with: multi_v7_defconfig (implies 
> > > CONFIG_MTD_SPI_NOR=y)
> > > 
> > > Patch is against 4.10-rc6 (localversion-next is next-20170210)
> > > 
> > >  drivers/mtd/spi-nor/intel-spi.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/mtd/spi-nor/intel-spi.c 
> > > b/drivers/mtd/spi-nor/intel-spi.c
> > > index a10f602..e43ce63 100644
> > > --- a/drivers/mtd/spi-nor/intel-spi.c
> > > +++ b/drivers/mtd/spi-nor/intel-spi.c
> > > @@ -704,7 +704,7 @@ static void intel_spi_fill_partition(struct intel_spi 
> > > *ispi,
> > >* whole partition read-only to be on the safe side.
> > >*/
> > >   if (intel_spi_is_protected(ispi, base, limit))
> > > - ispi->writeable = 0;
> > > + ispi->writeable = false;
> > >  
> > >   end = (limit << 12) + 4096;
> > >   if (end > part->size)  
> > 
> 

Re: [PATCH v3 1/2] gpio: mockup: add a dummy irqchip

[Linus Walleij]

On Mon, Feb 6, 2017 at 3:11 PM, Bartosz Golaszewski
 wrote:

> Setup a dummy irqchip that will allow us to inject line events for
> testing purposes.
>
> Signed-off-by: Bartosz Golaszewski 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH] spi-nor: use ERR_CAST in return

[Nicholas Mc Guire]

On Sun, Feb 12, 2017 at 11:04:10PM +0100, Boris Brezillon wrote:
> +Mika
> 
> On Sun, 12 Feb 2017 22:45:43 +0100
> Boris Brezillon  wrote:
> 
> > On Sun, 12 Feb 2017 17:43:43 +0100
> > Nicholas Mc Guire  wrote:
> > 
> > > This fixes a sparse warning about   
> > 
> > Your commit message seems to be incomplete.
> 
> And here too, please change the prefix to "mtd: spi-nor: intel: ".
>

What Im doing for checking prefix is:
hofrat@debian:~/git/linux-next$ git log --oneline 
drivers/mtd/spi-nor/intel-spi.c
8afda8b spi-nor: Add support for Intel SPI serial flash controller

is the method of checking the commit prefix with git log --oneline inapropriate 
? How would I have found the "mtd: spi-nor: intel:" in this case ?

thx!
ohfrat
 
> > 
> > Once fixed,
> > 
> > Acked-by: Boris Brezillon 
> > 
> > > 
> > > Signed-off-by: Nicholas Mc Guire 
> > > ---
> > > 
> > > sparse complained about:
> > > drivers/mtd/spi-nor/intel-spi.c:731:28: warning: incorrect type in return 
> > > expression (different address spaces)
> > > drivers/mtd/spi-nor/intel-spi.c:731:28:expected struct intel_spi *
> > > drivers/mtd/spi-nor/intel-spi.c:731:28:got void [noderef] *base
> > > 
> > > Patch was compile tested with: multi_v7_defconfig (implies 
> > > CONFIG_MTD_SPI_NOR=y)
> > > 
> > > Patch is against 4.10-rc6 (localversion-next is next-20170210)
> > > 
> > >  drivers/mtd/spi-nor/intel-spi.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/mtd/spi-nor/intel-spi.c 
> > > b/drivers/mtd/spi-nor/intel-spi.c
> > > index e43ce63..986a3d0 100644
> > > --- a/drivers/mtd/spi-nor/intel-spi.c
> > > +++ b/drivers/mtd/spi-nor/intel-spi.c
> > > @@ -728,7 +728,7 @@ struct intel_spi *intel_spi_probe(struct device *dev,
> > >  
> > >   ispi->base = devm_ioremap_resource(dev, mem);
> > >   if (IS_ERR(ispi->base))
> > > - return ispi->base;
> > > + return ERR_CAST(ispi->base);
> > >  
> > >   ispi->dev = dev;
> > >   ispi->info = info;  
> > 
> 

Re: [PATCH v2 1/9] llist: Provide a safe version for llist_for_each

[Huang, Ying]

Byungchul Park  writes:

> Sometimes we have to dereference next field of llist node before entering
> loop becasue the node might be deleted or the next field might be
> modified within the loop. So this adds the safe version of llist_for_each,
> that is, llist_for_each_safe.
>
> Signed-off-by: Byungchul Park 
> ---
>  include/linux/llist.h | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/include/linux/llist.h b/include/linux/llist.h
> index fd4ca0b..4c508a5 100644
> --- a/include/linux/llist.h
> +++ b/include/linux/llist.h
> @@ -105,6 +105,25 @@ static inline void init_llist_head(struct llist_head 
> *list)
>   for ((pos) = (node); pos; (pos) = (pos)->next)
>  
>  /**
> + * llist_for_each_safe - iterate over some deleted entries of a lock-less 
> list
> + *safe against removal of list entry
> + * @pos: the &struct llist_node to use as a loop cursor
> + * @n:   another type * to use as temporary storage

s/type */&struct llist_node/

> + * @node:the first entry of deleted list entries
> + *
> + * In general, some entries of the lock-less list can be traversed
> + * safely only after being deleted from list, so start with an entry
> + * instead of list head.
> + *
> + * If being used on entries deleted from lock-less list directly, the
> + * traverse order is from the newest to the oldest added entry.  If
> + * you want to traverse from the oldest to the newest, you must
> + * reverse the order by yourself before traversing.
> + */
> +#define llist_for_each_safe(pos, n, node)\
> + for ((pos) = (node); (pos) && ((n) = (pos)->next, true); (pos) = (n))
> +

Following the style of other xxx_for_each_safe,

#define llist_for_each_safe(pos, n, node)   \
for (pos = (node), (pos && (n = pos->next)); pos; pos = n, n = 
pos->next)

Best Regards,
Huang, Ying

> +/**
>   * llist_for_each_entry - iterate over some deleted entries of lock-less 
> list of given type
>   * @pos: the type * to use as a loop cursor.
>   * @node:the fist entry of deleted list entries.

Re: [PATCH v3 1/2] mtd: ifc: Update dependency of IFC for LS1021A

[Boris Brezillon]

Hi Alison,

The subject prefix is still wrong, should be 'memory: ifc: '.

On Mon, 13 Feb 2017 14:46:55 +0800
Alison Wang  wrote:

> As Freescale/NXP IFC controller is available on LS1021A, the dependency
> for LS1021A is added.
> 
> LS1021A is an earlier product and is not compatible with later
> LayerScape architecture. So ARCH_LAYERSCAPE can't cover LS1021A.
> 
> Signed-off-by: Alison Wang 
> ---
> Changes in v3:
> - Update the commit message.
> 
> Changes in v2:
> - New patch
> 
>  drivers/memory/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index ec80e35..fff8345 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -115,7 +115,7 @@ config FSL_CORENET_CF
>  
>  config FSL_IFC
>   bool
> - depends on FSL_SOC || ARCH_LAYERSCAPE
> + depends on FSL_SOC || ARCH_LAYERSCAPE || SOC_LS1021A
>  
>  config JZ4780_NEMC
>   bool "Ingenic JZ4780 SoC NEMC driver"

[PATCH v2 1/9] llist: Provide a safe version for llist_for_each

[Byungchul Park]

Sometimes we have to dereference next field of llist node before entering
loop becasue the node might be deleted or the next field might be
modified within the loop. So this adds the safe version of llist_for_each,
that is, llist_for_each_safe.

Signed-off-by: Byungchul Park 
---
 include/linux/llist.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/linux/llist.h b/include/linux/llist.h
index fd4ca0b..4c508a5 100644
--- a/include/linux/llist.h
+++ b/include/linux/llist.h
@@ -105,6 +105,25 @@ static inline void init_llist_head(struct llist_head *list)
for ((pos) = (node); pos; (pos) = (pos)->next)
 
 /**
+ * llist_for_each_safe - iterate over some deleted entries of a lock-less list
+ *  safe against removal of list entry
+ * @pos:   the &struct llist_node to use as a loop cursor
+ * @n: another type * to use as temporary storage
+ * @node:  the first entry of deleted list entries
+ *
+ * In general, some entries of the lock-less list can be traversed
+ * safely only after being deleted from list, so start with an entry
+ * instead of list head.
+ *
+ * If being used on entries deleted from lock-less list directly, the
+ * traverse order is from the newest to the oldest added entry.  If
+ * you want to traverse from the oldest to the newest, you must
+ * reverse the order by yourself before traversing.
+ */
+#define llist_for_each_safe(pos, n, node)  \
+   for ((pos) = (node); (pos) && ((n) = (pos)->next, true); (pos) = (n))
+
+/**
  * llist_for_each_entry - iterate over some deleted entries of lock-less list 
of given type
  * @pos:   the type * to use as a loop cursor.
  * @node:  the fist entry of deleted list entries.
-- 
1.9.1

[PATCH v2 6/9] namespace.c: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 fs/namespace.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index b5b1259..5cb2229 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1082,12 +1082,10 @@ static void __cleanup_mnt(struct rcu_head *head)
 static void delayed_mntput(struct work_struct *unused)
 {
struct llist_node *node = llist_del_all(&delayed_mntput_list);
-   struct llist_node *next;
+   struct mount *m, *t;
 
-   for (; node; node = next) {
-   next = llist_next(node);
-   cleanup_mnt(llist_entry(node, struct mount, mnt_llist));
-   }
+   llist_for_each_entry_safe(m, t, node, mnt_llist)
+   cleanup_mnt(m);
 }
 static DECLARE_DELAYED_WORK(delayed_mntput_work, delayed_mntput);
 
@@ -1615,7 +1613,7 @@ void __detach_mounts(struct dentry *dentry)
namespace_unlock();
 }
 
-/* 
+/*
  * Is the caller allowed to modify his namespace?
  */
 static inline bool may_mount(void)
@@ -2159,7 +2157,7 @@ static int do_loopback(struct path *path, const char 
*old_name,
 
err = -EINVAL;
if (mnt_ns_loop(old_path.dentry))
-   goto out; 
+   goto out;
 
mp = lock_mount(path);
err = PTR_ERR(mp);
-- 
1.9.1

[PATCH v2 0/9] Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Change from v1
- split one patch to several ones, one for each subsystem.
- replace for_each with the safe version where it's necessary.

Byungchul Park (9):
  llist: Provide a safe version for llist_for_each
  bcache: Don't reinvent the wheel but use existing llist API
  raid5: Don't reinvent the wheel but use existing llist API
  vhost/scsi: Don't reinvent the wheel but use existing llist API
  fput: Don't reinvent the wheel but use existing llist API
  namespace.c: Don't reinvent the wheel but use existing llist API
  irq_work: Don't reinvent the wheel but use existing llist API
  sched: Don't reinvent the wheel but use existing llist API
  mm: Don't reinvent the wheel but use existing llist API

 drivers/md/bcache/closure.c | 17 +++--
 drivers/md/raid5.c  |  6 ++
 drivers/vhost/scsi.c| 11 +++
 fs/file_table.c | 12 +---
 fs/namespace.c  | 12 +---
 include/linux/llist.h   | 19 +++
 kernel/irq_work.c   |  6 +-
 kernel/sched/core.c | 13 ++---
 mm/vmalloc.c| 10 --
 9 files changed, 44 insertions(+), 62 deletions(-)

-- 
1.9.1

[PATCH v2 9/9] mm: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 mm/vmalloc.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 3ca82d4..8c0eb45 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -49,12 +49,10 @@ struct vfree_deferred {
 static void free_work(struct work_struct *w)
 {
struct vfree_deferred *p = container_of(w, struct vfree_deferred, wq);
-   struct llist_node *llnode = llist_del_all(&p->list);
-   while (llnode) {
-   void *p = llnode;
-   llnode = llist_next(llnode);
-   __vunmap(p, 1);
-   }
+   struct llist_node *t, *llnode;
+
+   llist_for_each_safe(llnode, t, llist_del_all(&p->list))
+   __vunmap((void *)llnode, 1);
 }
 
 /*** Page table manipulation functions ***/
-- 
1.9.1

[PATCH v2 7/9] irq_work: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 kernel/irq_work.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/kernel/irq_work.c b/kernel/irq_work.c
index bcf107c..e2ebe8c 100644
--- a/kernel/irq_work.c
+++ b/kernel/irq_work.c
@@ -138,11 +138,7 @@ static void irq_work_run_list(struct llist_head *list)
return;
 
llnode = llist_del_all(list);
-   while (llnode != NULL) {
-   work = llist_entry(llnode, struct irq_work, llnode);
-
-   llnode = llist_next(llnode);
-
+   llist_for_each_entry(work, llnode, llnode) {
/*
 * Clear the PENDING bit, after this point the @work
 * can be re-used.
-- 
1.9.1

[PATCH v2 2/9] bcache: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 drivers/md/bcache/closure.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/md/bcache/closure.c b/drivers/md/bcache/closure.c
index 864e673..1841d03 100644
--- a/drivers/md/bcache/closure.c
+++ b/drivers/md/bcache/closure.c
@@ -64,27 +64,16 @@ void closure_put(struct closure *cl)
 void __closure_wake_up(struct closure_waitlist *wait_list)
 {
struct llist_node *list;
-   struct closure *cl;
+   struct closure *cl, *t;
struct llist_node *reverse = NULL;
 
list = llist_del_all(&wait_list->list);
 
/* We first reverse the list to preserve FIFO ordering and fairness */
-
-   while (list) {
-   struct llist_node *t = list;
-   list = llist_next(list);
-
-   t->next = reverse;
-   reverse = t;
-   }
+   reverse = llist_reverse_order(list);
 
/* Then do the wakeups */
-
-   while (reverse) {
-   cl = container_of(reverse, struct closure, list);
-   reverse = llist_next(reverse);
-
+   llist_for_each_entry_safe(cl, t, reverse, list) {
closure_set_waiting(cl, 0);
closure_sub(cl, CLOSURE_WAITING + 1);
}
-- 
1.9.1

[PATCH v2 8/9] sched: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 kernel/sched/core.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index d01f9d0..417060b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1783,17 +1783,8 @@ void sched_ttwu_pending(void)
raw_spin_lock_irqsave(&rq->lock, flags);
rq_pin_lock(rq, &rf);
 
-   while (llist) {
-   int wake_flags = 0;
-
-   p = llist_entry(llist, struct task_struct, wake_entry);
-   llist = llist_next(llist);
-
-   if (p->sched_remote_wakeup)
-   wake_flags = WF_MIGRATED;
-
-   ttwu_do_activate(rq, p, wake_flags, &rf);
-   }
+   llist_for_each_entry(p, llist, wake_entry)
+   ttwu_do_activate(rq, p, p->sched_remote_wakeup ? WF_MIGRATED : 
0, &rf);
 
rq_unpin_lock(rq, &rf);
raw_spin_unlock_irqrestore(&rq->lock, flags);
-- 
1.9.1

[PATCH v2 5/9] fput: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 fs/file_table.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/fs/file_table.c b/fs/file_table.c
index 6d982b5..3209da2 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -231,12 +231,10 @@ static void __fput(struct file *file)
 static void delayed_fput(struct work_struct *unused)
 {
struct llist_node *node = llist_del_all(&delayed_fput_list);
-   struct llist_node *next;
+   struct file *f, *t;
 
-   for (; node; node = next) {
-   next = llist_next(node);
-   __fput(llist_entry(node, struct file, f_u.fu_llist));
-   }
+   llist_for_each_entry_safe(f, t, node, f_u.fu_llist)
+   __fput(f);
 }
 
 static void fput(struct callback_head *work)
@@ -310,7 +308,7 @@ void put_filp(struct file *file)
 }
 
 void __init files_init(void)
-{ 
+{
filp_cachep = kmem_cache_create("filp", sizeof(struct file), 0,
SLAB_HWCACHE_ALIGN | SLAB_PANIC, NULL);
percpu_counter_init(&nr_files, 0, GFP_KERNEL);
@@ -329,4 +327,4 @@ void __init files_maxfiles_init(void)
n = ((totalram_pages - memreserve) * (PAGE_SIZE / 1024)) / 10;
 
files_stat.max_files = max_t(unsigned long, n, NR_FILE);
-} 
+}
-- 
1.9.1

[PATCH v2 3/9] raid5: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 drivers/md/raid5.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 36c13e4..22a0326 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -353,17 +353,15 @@ static void release_inactive_stripe_list(struct r5conf 
*conf,
 static int release_stripe_list(struct r5conf *conf,
   struct list_head *temp_inactive_list)
 {
-   struct stripe_head *sh;
+   struct stripe_head *sh, *t;
int count = 0;
struct llist_node *head;
 
head = llist_del_all(&conf->released_stripes);
head = llist_reverse_order(head);
-   while (head) {
+   llist_for_each_entry_safe(sh, t, head, release_list) {
int hash;
 
-   sh = llist_entry(head, struct stripe_head, release_list);
-   head = llist_next(head);
/* sh could be readded after STRIPE_ON_RELEASE_LIST is cleard */
smp_mb();
clear_bit(STRIPE_ON_RELEASE_LIST, &sh->state);
-- 
1.9.1

[PATCH v2 4/9] vhost/scsi: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 drivers/vhost/scsi.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 253310c..a4cb966 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -496,14 +496,12 @@ static void vhost_scsi_evt_work(struct vhost_work *work)
struct vhost_scsi *vs = container_of(work, struct vhost_scsi,
vs_event_work);
struct vhost_virtqueue *vq = &vs->vqs[VHOST_SCSI_VQ_EVT].vq;
-   struct vhost_scsi_evt *evt;
+   struct vhost_scsi_evt *evt, *t;
struct llist_node *llnode;
 
mutex_lock(&vq->mutex);
llnode = llist_del_all(&vs->vs_event_list);
-   while (llnode) {
-   evt = llist_entry(llnode, struct vhost_scsi_evt, list);
-   llnode = llist_next(llnode);
+   llist_for_each_entry_safe(evt, t, llnode, list) {
vhost_scsi_do_evt_work(vs, evt);
vhost_scsi_free_evt(vs, evt);
}
@@ -529,10 +527,7 @@ static void vhost_scsi_complete_cmd_work(struct vhost_work 
*work)
 
bitmap_zero(signal, VHOST_SCSI_MAX_VQ);
llnode = llist_del_all(&vs->vs_completion_list);
-   while (llnode) {
-   cmd = llist_entry(llnode, struct vhost_scsi_cmd,
-tvc_completion_list);
-   llnode = llist_next(llnode);
+   llist_for_each_entry(cmd, llnode, tvc_completion_list) {
se_cmd = &cmd->tvc_se_cmd;
 
pr_debug("%s tv_cmd %p resid %u status %#02x\n", __func__,
-- 
1.9.1

[PATCH v3 2/2] mtd: nand: Update dependency of IFC for LS1021A

[Alison Wang]

As NAND support for Freescale/NXP IFC controller is available on
LS1021A, the dependency for LS1021A is added.

LS1021A is an earlier product and is not compatible with later
LayerScape architecture. So ARCH_LAYERSCAPE can't cover LS1021A.

Signed-off-by: Alison Wang 
---
Changes in v3:
- Update the commit message.

Changes in v2:
- None

 drivers/mtd/nand/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 353a9dd..85e3860 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -441,7 +441,7 @@ config MTD_NAND_FSL_ELBC
 
 config MTD_NAND_FSL_IFC
tristate "NAND support for Freescale IFC controller"
-   depends on FSL_SOC || ARCH_LAYERSCAPE
+   depends on FSL_SOC || ARCH_LAYERSCAPE || SOC_LS1021A
select FSL_IFC
select MEMORY
help
-- 
2.1.0.27.g96db324

RE: [PATCH v2 2/2] mtd: nand: Update dependency of IFC for LS1021A

[Alison Wang]

Hi, Boris,

> On Thu, 5 Jan 2017 02:02:30 +
> Alison Wang  wrote:
> 
> > > On 01/04/2017 02:46 AM, Alison Wang wrote:
> > > >> On 01/03/2017 03:41 AM, Alison Wang wrote:
> > > >>> As NAND support for Freescale/NXP IFC controller is available
> on
> > > >>> LS1021A, the dependency for LS1021A is added.
> > > >>
> > > >> Does LS stand for LayerScape ? Yes it does. So why does
> > > >> ARCH_LAYERSCAPE not cover LS1021 ?
> > > > [Alison Wang] LS1021A is an earlier product and is not compatible
> > > with later Layerscape architecture. So ARCH_LAYERSCAPE can't cover
> > > LS1021A.
> > >
> > > Ah ok, I see. That information would be useful in the commit
> message
> > > ;-)
> > >
> > [Alison Wang] Ok. :)
> 
> Would you mind sending a v3 with the updated commit message?
> 
[Alison Wang] I will send the v3 patches at once. :)


Best Regards,
Alison Wang

[PATCH v3 1/2] mtd: ifc: Update dependency of IFC for LS1021A

[Alison Wang]

As Freescale/NXP IFC controller is available on LS1021A, the dependency
for LS1021A is added.

LS1021A is an earlier product and is not compatible with later
LayerScape architecture. So ARCH_LAYERSCAPE can't cover LS1021A.

Signed-off-by: Alison Wang 
---
Changes in v3:
- Update the commit message.

Changes in v2:
- New patch

 drivers/memory/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index ec80e35..fff8345 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -115,7 +115,7 @@ config FSL_CORENET_CF
 
 config FSL_IFC
bool
-   depends on FSL_SOC || ARCH_LAYERSCAPE
+   depends on FSL_SOC || ARCH_LAYERSCAPE || SOC_LS1021A
 
 config JZ4780_NEMC
bool "Ingenic JZ4780 SoC NEMC driver"
-- 
2.1.0.27.g96db324

Re: [PATCH 0/3] s390: audit and remove needless module.h includes

[Heiko Carstens]

On Thu, Feb 09, 2017 at 03:20:22PM -0500, Paul Gortmaker wrote:
> Paul Gortmaker (3):
>   s390: kernel: Audit and remove any unnecessary uses of module.h
>   s390: mm: Audit and remove any unnecessary uses of module.h
>   s390: Audit and remove any remaining unnecessary uses of module.h

Applied, thanks!

Re: [PATCH] perf: Fix CONFIG_KPROBE_EVENTS and CONFIG_UPROBE_EVENTS typos

[Ingo Molnar]

* Anton Blanchard  wrote:

> From: Anton Blanchard 
> 
> Fix some incorrect Kconfig options, they should be CONFIG_KPROBE_EVENT
> and CONFIG_UPROBE_EVENT.
> 
> Signed-off-by: Anton Blanchard 
> ---
>  arch/sparc/configs/sparc64_defconfig | 2 +-
>  tools/perf/util/probe-file.c | 8 
>  2 files changed, 5 insertions(+), 5 deletions(-)

So the names should be fixed, it should be CONFIG_UPROBE_EVENTS and 
CONFIG_KPROBE_EVENTS throughout the code. It's CONFIG_PERF_EVENTS and 
CONFIG_PROBE_EVENTS after all and lives in kernel/events/ - all plural.

I didn't notice the misnomer when merging these bits.

Thanks,

Ingo

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

[Stephen Rothwell]

Hi Paul,

On Sun, 12 Feb 2017 20:37:48 -0800 "Paul E. McKenney" 
 wrote:
>
> I chickened out on that commit for this merge window, so it will come
> back at -rc1.  But I will cover that when I rebase to -rc1.

OK, thanks.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] Make EN2 pin optional in the TRF7970A driver

[Heiko Schocher]

Hello Rob,

Am 10.02.2017 um 16:51 schrieb Rob Herring:

On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote:

From: Guan Ben 

Make the EN2 pin optional. This is useful for boards,
which have this pin fix wired, for example to ground.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
Signed-off-by: Heiko Schocher 

---

  .../devicetree/bindings/net/nfc/trf7970a.txt   |  4 ++--
  drivers/nfc/trf7970a.c | 26 --
  2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt 
b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..5889a3d 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -5,8 +5,8 @@ Required properties:
  - spi-max-frequency: Maximum SPI frequency (<= 200).
  - interrupt-parent: phandle of parent interrupt handler.
  - interrupts: A single interrupt specifier.
-- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the
-  TRF7970A.
+- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins on the
+  TRF7970A. EN2 is optional.


Could EN ever be optional/fixed? If so, perhaps deprecate this property
and do 2 properties, one for each pin.


The hardware I have has the EN2 pin fix connected to ground. Looking
into http://www.ti.com/lit/ds/slos743k/slos743k.pdf page 19 table 6-3
and 6-4 the EN2 pin is a don;t core if EN = 1. If EN = 0 EN2 pin
selects between Power Down and Sleep Mode ... I see no reason why
this is not possible/allowed ...

Hmm.. I do not like the idea of deprecating the "ti,enable-gpios"
property into 2 seperate properties ... but if this would be a reason
for not accepting this patch, I can do this ... How should I name
the 2 new properties?

"ti,pin-enable"  and "ti,pin-enable2" ?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

linux-next: Tree for Feb 13

[Stephen Rothwell]

Hi all,

Changes since 20170210:

The ipsec-next tree gained a conflict against the net-next tree.

The rdma-leon gained a conflict against Linus' tree.

The l2mtd-tree lost its build failure.

Non-merge commits (relative to Linus' tree): 8646
 9682 files changed, 388711 insertions(+), 182504 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 256 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (1ce42845f987 Merge branch 'x86-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (8ba605b607b7 ARC: [plat-*] ARC_HAS_COH_CACHES no 
longer relevant)
Merging arm-current/fixes (228dbbfb5d77 ARM: 8643/3: arm/ptrace: Preserve 
previous registers for short regset write)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (f83e6862047e powerpc/powernv: Properly set 
"host-ipi" on IPIs)
Merging sparc/master (f9a42e0d58cf Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (e722af639194 ibmvnic: Call napi_disable instead of 
napi_enable in failure path)
Merging ipsec/master (c28a45cb xfrm: policy: init locks early)
Merging netfilter/master (f95d7a46bc57 netfilter: ctnetlink: Fix regression in 
CTA_HELP processing)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (52f5631a4c05 rtlwifi: rtl8192ce: Fix loading 
of incorrect firmware)
Merging mac80211/master (fd551bac4795 nl80211: Fix mesh HT operation check)
Merging sound-current/for-linus (af677166cf63 ALSA: hda - adding a new NV 
HDMI/DP codec ID in the driver)
Merging pci-current/for-linus (d98e0929071e Revert "PCI: pciehp: Add runtime PM 
support for PCIe hotplug ports")
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (d07830db1bdb USB: serial: pl2303: add ATEN 
device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging char-misc.current/char-misc-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging input-current/for-linus (413d37326700 Input: synaptics-rmi4 - select 
'SERIO' when needed)
Merging crypto-current/master (7c2cf1c4615c crypto: chcr - Fix key length for 
RFC4106)
Merging ide/master (da095587e6be Revert "ide: Fix interface autodetection in 
legacy IDE driver (trial #2)")
Merging vfio-fixes/for-linus (930a42ded3fe vfio/spapr_tce: Set window when 
adding addi

Re: [PATCH 1/1] dma: imx-sdma: add 1ms delay to ensure SDMA channel is stopped

[Jiada Wang]

Hello Vinod

On 02/13/2017 11:05 AM, Vinod Koul wrote:

On Fri, Feb 10, 2017 at 06:46:45AM -0800, jiada_w...@mentor.com wrote:

From: Jiada Wang 

sdma_disable_channel() cannot ensure dma is stopped to access
module's FIFOs. Maybe SDMA core is running and accessing BD when
disable of corresponding channel, this may cause sometimes even
after call of .sdma_disable_channel(), SDMA core still be running
and accessing module's FIFOs.

We should add delay of one BD SDMA cost time, the maximum is 1ms.
So that SDMA clients by calling .device_terminate_all can
ensure SDMA core has really been stopped.

Signed-off-by: Jiada Wang 
---
 drivers/dma/imx-sdma.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index d1651a5..7332c40 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -937,6 +937,14 @@ static int sdma_disable_channel(struct dma_chan *chan)
return 0;
 }

+static int sdma_disable_channel_with_delay(struct dma_chan *chan)
+{
+   sdma_disable_channel(chan);
+   mdelay(1);


what is the gaurantee that 1ms is fine? Shouldn't you poll the bit to see
channel is disabled properly..


I got the information from NXP (freescale) R&D team,
according to them, by write '1' to SDMA_H_STATSTOP, only disables
the related sdma channel (so poll HE bit will indicates the channel has 
been disabled),

but it cannot ensure SDMA core stop to access modules' FIFO,
SDMA core may still is running, this is a bug in HW.

regarding if the '1ms' is enough to ensure SDMA core has stopped,
NXP R&D team mentioned:
"we should add some delay of one BD SDMA cost time after disable the 
channel bit, the maximum is 1ms"

so I assume 1ms should work for all cases

Thanks,
Jiada

+
+   return 0;
+}
+
 static void sdma_set_watermarklevel_for_p2p(struct sdma_channel *sdmac)
 {
struct sdma_engine *sdma = sdmac->sdma;
@@ -1828,7 +1836,7 @@ static int sdma_probe(struct platform_device *pdev)
sdma->dma_device.device_prep_slave_sg = sdma_prep_slave_sg;
sdma->dma_device.device_prep_dma_cyclic = sdma_prep_dma_cyclic;
sdma->dma_device.device_config = sdma_config;
-   sdma->dma_device.device_terminate_all = sdma_disable_channel;
+   sdma->dma_device.device_terminate_all = sdma_disable_channel_with_delay;
sdma->dma_device.src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
sdma->dma_device.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
sdma->dma_device.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
--
2.7.4

Re: [PATCH] Input: tsc2004/5 - do not use irq_set_irq_wake() directly

[Sebastian Reichel]

Hi,

On Sun, Feb 12, 2017 at 03:43:33PM -0800, Dmitry Torokhov wrote:
> Instead of setting irq_set_irq_wake() directly in probe(), mark the device
> as wakeup-capable, and use enable_irq_wake() and disable_irq_wake() in
> suspend/resume path.
> 
> Signed-off-by: Dmitry Torokhov 

Reviewed-By: Sebastian Reichel 

I suggest to add a paragraph in the patch description, why the
change was done. E.g.:

This adds support for changing the wakeup setting dynamically at
runtime using /sys/devices/.../tsc2005/power/wakeup.

Also I wonder if the default should be 'off' (by using
device_set_wakeup_capable() instead of device_init_wakeup()

-- Sebastian

>  drivers/input/touchscreen/tsc200x-core.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/tsc200x-core.c 
> b/drivers/input/touchscreen/tsc200x-core.c
> index 88ea5e1b72ae..d1c40c803d61 100644
> --- a/drivers/input/touchscreen/tsc200x-core.c
> +++ b/drivers/input/touchscreen/tsc200x-core.c
> @@ -114,7 +114,9 @@ struct tsc200x {
>  
>   struct gpio_desc*reset_gpio;
>   int (*tsc200x_cmd)(struct device *dev, u8 cmd);
> +
>   int irq;
> + boolwake_irq_enabled;
>  };
>  
>  static void tsc200x_update_pen_state(struct tsc200x *ts,
> @@ -573,7 +575,8 @@ int tsc200x_probe(struct device *dev, int irq, const 
> struct input_id *tsc_id,
>   goto err_remove_sysfs;
>   }
>  
> - irq_set_irq_wake(irq, 1);
> + device_init_wakeup(dev, true);
> +
>   return 0;
>  
>  err_remove_sysfs:
> @@ -607,6 +610,9 @@ static int __maybe_unused tsc200x_suspend(struct device 
> *dev)
>  
>   ts->suspended = true;
>  
> + if (device_may_wakeup(dev))
> + ts->wake_irq_enabled = enable_irq_wake(ts->irq) == 0;
> +
>   mutex_unlock(&ts->mutex);
>  
>   return 0;
> @@ -618,6 +624,11 @@ static int __maybe_unused tsc200x_resume(struct device 
> *dev)
>  
>   mutex_lock(&ts->mutex);
>  
> + if (ts->wake_irq_enabled) {
> + disable_irq_wake(ts->irq);
> + ts->wake_irq_enabled = false;
> + }
> +
>   if (ts->suspended && ts->opened)
>   __tsc200x_enable(ts);
>  
> -- 
> 2.11.0.483.g087da7b7c-goog
> 
> 
> -- 
> Dmitry


signature.asc
Description: PGP signature

[PATCH RFC 3/3] arm64: dts: register Hi6220's coresight debug module

[Leo Yan]

Bind coresight debug driver for Hi6220.

Signed-off-by: Leo Yan 
---
 .../boot/dts/hisilicon/hikey_6220_coresight.dtsi   | 73 ++
 1 file changed, 73 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hikey_6220_coresight.dtsi 
b/arch/arm64/boot/dts/hisilicon/hikey_6220_coresight.dtsi
index 77c2aab..e14d75c 100644
--- a/arch/arm64/boot/dts/hisilicon/hikey_6220_coresight.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hikey_6220_coresight.dtsi
@@ -15,6 +15,79 @@
#size-cells = <2>;
compatible = "arm,amba-bus";
ranges;
+
+   debug@0,f659 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf659 0 0x1000>;
+   default_enable;
+   clocks = <&sys_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <&cpu0>;
+   };
+
+   debug@1,f6592000 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf6592000 0 0x1000>;
+   default_enable;
+   clocks = <&sys_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <&cpu1>;
+   };
+
+   debug@2,f6594000 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf6594000 0 0x1000>;
+   default_enable;
+   clocks = <&sys_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <&cpu2>;
+   };
+
+   debug@3,f6596000 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf6596000 0 0x1000>;
+   default_enable;
+   clocks = <&sys_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <&cpu3>;
+   };
+
+   debug@4,f65d {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf65d 0 0x1000>;
+   default_enable;
+   clocks = <&sys_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <&cpu4>;
+   };
+
+   debug@5,f65d2000 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf65d2000 0 0x1000>;
+   default_enable;
+   clocks = <&sys_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <&cpu5>;
+   };
+
+   debug@6,f65d4000 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf65d4000 0 0x1000>;
+   default_enable;
+   clocks = <&sys_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <&cpu6>;
+   };
+
+   debug@7,f65d6000 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf65d6000 0 0x1000>;
+   default_enable;
+   clocks = <&sys_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <&cpu7>;
+   };
+
etm@0,f659c000 {
compatible = "arm,coresight-etm4x","arm,primecell";
reg = <0 0xf659c000 0 0x1000>;
-- 
2.7.4

[PATCH RFC 2/3] coresight: add support for debug module

[Leo Yan]

Coresight includes debug module and usually the module connects with CPU
debug logic. ARMv8 architecture reference manual (ARMv8-ARM) has defined
the debug registers in the chapter "H9: External Debug Register
Descriptions".

After enable the debug module we can check CPU state and PC value, etc.
So this is helpful for some CPU lockup bugs, e.g. if one CPU has run
into infinite loop with IRQ disabled. So the CPU cannot switch context
and handle any interrupt, so it cannot handle SMP call for stack dump,
etc. Furthermore, now ARMv8 introduces some other runtime firmwares like
ARM trusted firmware BL31, so sometime CPU hard lock may happen in the
firmware and cannot return back to kernel.

This patch is to enable coresight debug module and register callback
notifier for panic; so when system detect the CPU lockup we can utilize
debug module registers to get to know PC value for all CPUs; so we can
quickly know the hang address for CPUs.

This is initial driver for coresight debug module and could enhance it
later according to debugging requirement.

Signed-off-by: Leo Yan 
---
 drivers/hwtracing/coresight/Kconfig   |   8 ++
 drivers/hwtracing/coresight/Makefile  |   1 +
 drivers/hwtracing/coresight/coresight-debug.c | 169 ++
 3 files changed, 178 insertions(+)
 create mode 100644 drivers/hwtracing/coresight/coresight-debug.c

diff --git a/drivers/hwtracing/coresight/Kconfig 
b/drivers/hwtracing/coresight/Kconfig
index 130cb21..dcf59cc 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -89,4 +89,12 @@ config CORESIGHT_STM
  logging useful software events or data coming from various entities
  in the system, possibly running different OSs
 
+config CORESIGHT_DEBUG
+   bool "CoreSight debug driver"
+   depends on ARM || ARM64
+   help
+ This driver provides support for coresight debugging module. This
+ is primarily used for printing out debug registers for panic and
+ soft and hard lockup.
+
 endif
diff --git a/drivers/hwtracing/coresight/Makefile 
b/drivers/hwtracing/coresight/Makefile
index af480d9..d540d45 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
coresight-etm4x-sysfs.o
 obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
 obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
+obj-$(CONFIG_CORESIGHT_DEBUG) += coresight-debug.o
diff --git a/drivers/hwtracing/coresight/coresight-debug.c 
b/drivers/hwtracing/coresight/coresight-debug.c
new file mode 100644
index 000..28206a83
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-debug.c
@@ -0,0 +1,169 @@
+/*
+ * Copyright(C) 2017 Linaro Limited. All rights reserved.
+ * Author: Leo Yan 
+ *
+ * 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 .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "coresight-priv.h"
+
+#define EDPCSR_LO  0x0A0
+#define EDPCSR_HI  0x0AC
+#define EDOSLAR0x300
+#define EDOSLSR0x304
+#define EDPDCR 0x310
+#define EDPDSR 0x314
+
+struct debug_drvdata {
+   void __iomem*base;
+   struct device   *dev;
+   int cpu;
+};
+
+static struct debug_drvdata *debug_drvdata[NR_CPUS];
+
+static void debug_os_unlock(struct debug_drvdata *drvdata)
+{
+   /* Unlocks the debug registers */
+   writel_relaxed(0x0, drvdata->base + EDOSLAR);
+   isb();
+}
+
+static void debug_read_pcsr(struct debug_drvdata *drvdata)
+{
+   u32 pcsr_hi, pcsr_lo;
+
+   CS_UNLOCK(drvdata->base);
+
+   debug_os_unlock(drvdata);
+
+#ifdef CONFIG_64BIT
+   pcsr_lo = readl_relaxed(drvdata->base + EDPCSR_LO);
+   pcsr_hi = readl_relaxed(drvdata->base + EDPCSR_HI);
+
+   pr_emerg("CPU[%d]: PSCR=0x%lx\n", drvdata->cpu,
+((unsigned long)pcsr_hi << 32 | (unsigned long)pcsr_lo));
+#else
+   pcsr_lo = readl_relaxed(drvdata->base + EDPCSR_LO);
+
+   pr_emerg("CPU[%d]: PSCR=0x%lx\n", drvdata->cpu, pcsr_lo);
+#endif
+
+   CS_LOCK(drvdata->base);
+}
+
+/*
+ * Dump out memory limit information on panic.
+ */
+static int dump_debug(struc

Re: [PATCH] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

Hello Rob,

Am 10.02.2017 um 16:48 schrieb Rob Herring:

On Tue, Feb 07, 2017 at 06:21:34AM +0100, Heiko Schocher wrote:

From: Guan Ben 

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher 

---

  .../devicetree/bindings/input/pwm-beeper.txt   |  3 ++
  drivers/input/misc/pwm-beeper.c| 36 --
  2 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt 
b/Documentation/devicetree/bindings/input/pwm-beeper.txt
index be332ae..438c6e0 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -5,3 +5,6 @@ Registers a PWM device as beeper.
  Required properties:
  - compatible: should be "pwm-beeper"
  - pwms: phandle to the physical PWM device
+
+optional properties:
+- bell-frequency:  bell frequency in Hz


Needs a unit suffix:
bell-frequency-hz or just bell-hz as hz implies frequency.

Or maybe beeper-hz would be more consistant.


Ok, I change it to "beeper-hz". Are this all issues with this patch?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[PATCH RFC 1/3] coresight: binding for coresight debug driver

[Leo Yan]

Adding compatible string for new coresight debug driver.

Signed-off-by: Leo Yan 
---
 Documentation/devicetree/bindings/arm/coresight.txt | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/coresight.txt 
b/Documentation/devicetree/bindings/arm/coresight.txt
index fcbae6a..3ff15fd 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -40,6 +40,9 @@ its hardware characteristcs.
- System Trace Macrocell:
"arm,coresight-stm", "arm,primecell"; [1]
 
+   - Debug Unit:
+   "arm,coresight-debug", "arm,primecell";
+
* reg: physical base address and length of the register
  set(s) of the component.
 
@@ -78,8 +81,10 @@ its hardware characteristcs.
* arm,cp14: must be present if the system accesses ETM/PTM management
  registers via co-processor 14.
 
-   * cpu: the cpu phandle this ETM/PTM is affined to. When omitted the
- source is considered to belong to CPU0.
+* Optional properties for ETM/PTM/Debugs:
+
+   * cpu: the cpu phandle this ETM/PTM/Debug is affined to. When omitted
+ the source is considered to belong to CPU0.
 
 * Optional property for TMC:
 
-- 
2.7.4

[PATCH RFC 0/3] coresight: enable debug module

[Leo Yan]

This patch series is to enable coresight debug module. With debug
module we can check CPU state and PC value, etc. So this is helpful for
CPU lockup bugs, e.g. if one CPU has run into infinite loop with IRQ
disabled. The hang CPU cannot switch context and handle any interrupt,
so it cannot handle SMP call for stack dump, etc.

Furthermore, now ARMv8 introduces some runtime firmwares like ARM
trusted firmware BL31, so sometime CPU lockup may happen in the
firmware and cannot return back to kernel.

This initial patch series enable debug module and registers call back
notifier for PCSR register dumping when panic happens, so we can see
below dumping info for panic:

[   13.751777] Coresight debug module:
[   13.755275] CPU[0]: PSCR=0x08090cbc
[   13.759469] CPU[1]: PSCR=0x088bf9e4
[   13.763662] CPU[2]: PSCR=0x08090cc0
[   13.767856] CPU[3]: PSCR=0x08090cb8
[   13.772049] CPU[4]: PSCR=0x08090cc0
[   13.776243] CPU[5]: PSCR=0x08090cbc
[   13.780436] CPU[6]: PSCR=0x08090cc0
[   13.784630] CPU[7]: PSCR=0x08090cbc

This patch series has been verified on 96boards Hikey.


Leo Yan (3):
  coresight: binding for coresight debug driver
  coresight: add support for debug module
  arm64: dts: register Hi6220's coresight debug module

 .../devicetree/bindings/arm/coresight.txt  |   9 +-
 .../boot/dts/hisilicon/hikey_6220_coresight.dtsi   |  73 +
 drivers/hwtracing/coresight/Kconfig|   8 +
 drivers/hwtracing/coresight/Makefile   |   1 +
 drivers/hwtracing/coresight/coresight-debug.c  | 169 +
 5 files changed, 258 insertions(+), 2 deletions(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-debug.c

-- 
2.7.4

[PATCH] x86: kernel: fix unused variable warning in vm86_32.c

[Seunghun Han]

If CONFIG_TRANSPARENT_HUGEPAGE is not set in kernel config, a warning is shown
in vm86_32.c.

The warning is as follows:
>arch/x86/kernel/vm86_32.c: In function ‘mark_screen_rdonly’:
>arch/x86/kernel/vm86_32.c:180:26: warning: unused variable ‘vma’ 
>[-Wunused-variable]
> struct vm_area_struct *vma = find_vma(mm, 0xA);

The vma variable is used to call split_huge_pmd() macro function, but
split_huge_pmd() is defined as a null macro when CONFIG_TRANSPARENT_HUGEPAGE is
not set in kernel config. Therefore, the compiler shows an unused variable
warning.

To remove this warning, I change the split_huge_pmd() macro function to static
inline function and static inline null function.
Inline function works like a macro function, therefore there is no impact on
Linux kernel working.

Signed-off-by: Seunghun Han 
---
 include/linux/huge_mm.h | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index a3762d4..912a763 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -123,15 +123,12 @@ void deferred_split_huge_page(struct page *page);
 void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
unsigned long address, bool freeze, struct page *page);
 
-#define split_huge_pmd(__vma, __pmd, __address)
\
-   do {\
-   pmd_t *pmd = (__pmd);   \
-   if (pmd_trans_huge(*pmd)\
-   || pmd_devmap(*pmd))\
-   __split_huge_pmd(__vma, __pmd, __address,   \
-   false, NULL);   \
-   }  while (0)
-
+static inline void split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
+   unsigned long address)
+{
+   if (pmd_trans_huge(*pmd) || pmd_devmap(*pmd))
+   __split_huge_pmd(vma, pmd, address, false, NULL);
+}
 
 void split_huge_pmd_address(struct vm_area_struct *vma, unsigned long address,
bool freeze, struct page *page);
@@ -241,9 +238,8 @@ static inline int split_huge_page(struct page *page)
return 0;
 }
 static inline void deferred_split_huge_page(struct page *page) {}
-#define split_huge_pmd(__vma, __pmd, __address)\
-   do { } while (0)
-
+static inline void split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
+   unsigned long address) {}
 static inline void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
unsigned long address, bool freeze, struct page *page) {}
 static inline void split_huge_pmd_address(struct vm_area_struct *vma,
-- 
2.1.4

Re: [lkp] [x86/acpi] dc6db24d24: BUG: unable to handle kernel paging request at 0000116007090008

[Ye Xiaolong]

Hi, liyang

On 02/13, Dou Liyang wrote:
>Hi, Xiaolong
>
>At 02/13/2017 09:37 AM, Ye Xiaolong wrote:
>>On 11/21, Dou Liyang wrote:
>>>Hi, Xiaolong,
>>>
>>>At 11/21/2016 09:31 AM, Ye Xiaolong wrote:
On 11/18, Dou Liyang wrote:
>Hi xiaolong
>
>At 11/18/2016 02:16 PM, Ye Xiaolong wrote:
>>Hi, liyang
>>
>>Sorry for the late.
>>
>>On 10/31, Dou Liyang wrote:
>>>Hi, Xiaolong,
>>>
>>>I research the ACPI table for a long time, and I found that:
>>>The reason for this bug is the duplicate IDs "0xFF" in DSDT.
>>>it has already been fixed in the committed id
>>>8e089eaa1999def4bb954caa91941f29b0672b6a and
>>>fd74da217df7d4bd25e95411da64e0b92762842e which is after the
>>>dc6db24d2476cd09c0ecf2b8d80313539f737a89 .
>>>
>>>could you help me to Verify my thoughts in the LKP.
>>>
>>
>>I've queued the same test jobs for commit fd74da217d, I'll notify you
>>once I get the results.
>

Hi, Liyang,

Results show that the reported error is gone with commit 
fd74da217df7d4bd25e95411da64e0b92762842e
below is the comparison.

>>>
>>>thanks a lot. that means it has been fixed.
>>
>>Sorry for my neglect, the result for fd74da217df7d4bd25e95411da showed no 
>>dmesg
>>because it's incomplete run and has no demsg stat at all.
>
>Is that means:
>
>you have already tested the Linux branch which contains the commit
>fd74da217df7d. and it doesn't work well.
>
>Btw, Why the test is incomplete run ?

Yes, We've got plenty test results for kernel that contains fd74da217df7d such 
as v4.9,
v4.10-rc1, v4.10-rc2, they all have the same dmesg errors.
For the incomplete run, it may happen sometimes due to kernel panic during boot 
time and
0day failed to capture its dmesg stat.

>
>>The bug still persists in v4.9, v4.10-rcx, the lastest kernel head,
>
>If the dmesg and stat of the test is NULL, How do you prove that the
>bug still exists?

This "dmesg stat is empty" refer to test for kernel image which head commit is 
fd74da217df7d,
not for all test results.

>
>>could you help to check?
>>
>
>Yes, I think we first should make the test with commit fd74da217df7d
>work in the specific test machine.
>
>test machine: 72 threads Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
>with 128G memory
>
>Am I right? waiting your response.

Yes, currently we just found this issue on a specific machine, and I've queued 
the
same jobs to other machines to see whether they have the same issue.

Thanks,
Xiaolong
>
>Thanks,
>Liyang
>
>>Thanks,
>>Xiaolong
>>
>>>

compare -at dc6db24d2476cd09c0ecf2b8d80313539f737a89 
fd74da217df7d4bd25e95411da64e0b92762842e
tests: 1
testcase/path_params/tbox_group/run: 
vm-scalability/300-never-never-1-1-swap-w-rand-performance/lkp-hsw-ep2

dc6db24d2476cd09  fd74da217df7d4bd25e95411da
  --
  fail:runs  %reproductionfail:runs
  | | |
12:12-100%:3 
 dmesg.BUG:unable_to_handle_kernel
12:12-100%:3 dmesg.Oops
12:12-100%:3 dmesg.RIP:get_partial_node
 9:12 -75%:3 
 dmesg.RIP:_raw_spin_lock_irqsave
 3:12 -25%:3 
 dmesg.general_protection_fault:#[##]SMP
 3:12 -25%:3 
 dmesg.RIP:native_queued_spin_lock_slowpath
 3:12 -25%:3 
 dmesg.Kernel_panic-not_syncing:Hard_LOCKUP
 2:12 -17%:3 dmesg.RIP:load_balance
 2:12 -17%:3 
 dmesg.Kernel_panic-not_syncing:Fatal_exception_in_interrupt
 1:12  -8%:3 dmesg.RIP:resched_curr
 1:12  -8%:3 
 dmesg.Kernel_panic-not_syncing:Fatal_exception
 5:12 -42%:3 
 dmesg.WARNING:at_include/linux/uaccess.h:#__probe_kernel_read
 1:12  -8%:3 
 dmesg.WARNING:at_lib/list_debug.c:#__list_add


>>>
>>>2. About the LKP-tests, I want run the tests in my own pc.
>>>I use the debain sid as an OS. the .yaml file can be installed and
>>>job splited, but it can't be run correctly.
>>>
>>>Is the linux source code must be in /tmp/?
>>>And if I need to modify the .yaml file to fit my pc.
>>>
>>
>>Could you paste the error log for me to analyze?
>
>Yes.  let me tidy up it ah. :)
>
>>>
>>>And, I am very interesting in LKP-Test. when I built it, I met some
>>>problems.
>>>
>>>here is the error log:
>>>
>>>root@debian:/home/douly/lkp-tests# lkp run 
>>>./job-unlink2-performance-04c197c080f2ed7a022f79701455c6837f4b9573-debian-x86_64-2016-08-31.cgz.yaml
>>>
>>>IPMI BMC is not supported on this machine, skip bmc-watchdog setup!
>>>2016-11-21 15:21:01 ./runt

Re: [RFC][PATCH 12/21] tracing: Account for variables in named trigger compatibility

[Namhyung Kim]

On Wed, Feb 08, 2017 at 11:25:08AM -0600, Tom Zanussi wrote:
> Named triggers must also have the same set of variables in order to be
> considered compatible - update the trigger match test to account for
> that.
> 
> The reason for this requirement is that named triggers with variables
> are meant to allow one or more events to set the same variable.
> 
> Signed-off-by: Tom Zanussi 
> ---
>  kernel/trace/trace_events_hist.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/kernel/trace/trace_events_hist.c 
> b/kernel/trace/trace_events_hist.c
> index e707577..889455e 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -1576,6 +1576,10 @@ static bool hist_trigger_match(struct 
> event_trigger_data *data,
>   return false;
>   if (key_field->is_signed != key_field_test->is_signed)
>   return false;
> + if ((key_field->var_name && !key_field_test->var_name) ||
> + (!key_field->var_name && key_field_test->var_name) ||
> + strcmp(key_field->var_name, key_field_test->var_name) != 0)
> + return false;

What if key_field->var_name and key_field_test->var_name are both
NULL?

Thanks,
Namhyung

>   }
>  
>   for (i = 0; i < hist_data->n_sort_keys; i++) {
> -- 
> 1.9.3
> 

Re: [RFC][PATCH 11/21] tracing: Add variable support to hist triggers

[Namhyung Kim]

On Wed, Feb 08, 2017 at 11:25:07AM -0600, Tom Zanussi wrote:
> Add support for saving the value of a current event's event field by
> assigning it to a variable that can be read by a subsequent event.
> 
> The basic syntax for saving a variable is to simply prefix a unique
> variable name not corresponding to any keyword along with an '=' sign
> to any event field.
> 
> Both keys and values can be saved and retrieved in this way:
> 
> # echo 'hist:keys=next_pid:vals=ts0=common_timestamp ...
> # echo 'hist:key=timer_pid=common_pid ...'
> 
> If a variable isn't a key variable or prefixed with 'vals=', the
> associated event field will be saved in a variable but won't be summed
> as a value:
> 
> # echo 'hist:keys=next_pid:ts1=common_timestamp:...
> 
> Multiple variables can be assigned at the same time:
> 
> # echo 'hist:keys=pid:vals=ts0=common_timestamp,b=field1,field2 ...
> 
> Variables set as above can be used by being referenced from another
> event, as described in a subsequent patch.
> 
> Signed-off-by: Tom Zanussi 
> ---
>  kernel/trace/trace_events_hist.c | 160 
> ---
>  1 file changed, 131 insertions(+), 29 deletions(-)
> 
> diff --git a/kernel/trace/trace_events_hist.c 
> b/kernel/trace/trace_events_hist.c
> index 8d7f7dd..e707577 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -29,6 +29,7 @@ typedef u64 (*hist_field_fn_t) (struct hist_field *field, 
> void *event,
>   struct ring_buffer_event *rbe);
>  
>  #define HIST_FIELD_OPERANDS_MAX  2
> +#define HIST_ASSIGNMENT_MAX  4
>  
>  struct hist_field {
>   struct ftrace_event_field   *field;
> @@ -36,8 +37,10 @@ struct hist_field {
>   hist_field_fn_t fn;
>   unsigned intsize;
>   unsigned intoffset;
> - unsigned intis_signed;
> + unsigned intis_signed;

It seems like an unnecessary change.

>   struct hist_field   *operands[HIST_FIELD_OPERANDS_MAX];
> + u64 var_val;
> + char*var_name;
>  };
>  
>  static u64 hist_field_none(struct hist_field *field, void *event,
> @@ -140,12 +143,16 @@ enum hist_field_flags {
>   HIST_FIELD_FL_SYSCALL   = 128,
>   HIST_FIELD_FL_STACKTRACE= 256,
>   HIST_FIELD_FL_LOG2  = 512,
> - HIST_FIELD_FL_TIMESTAMP = 1024,
> + HIST_FIELD_FL_VAR   = 1024,
> + HIST_FIELD_FL_VAR_ONLY  = 2048,
> + HIST_FIELD_FL_TIMESTAMP = 4096,

Why did you move the timestamp?

>  };
>  
>  struct hist_trigger_attrs {
>   char*keys_str;
>   char*vals_str;
> + char*assignment_str[HIST_ASSIGNMENT_MAX];
> + unsigned intn_assignments;
>   char*sort_key_str;
>   char*name;
>   boolpause;
> @@ -241,9 +248,14 @@ static int parse_map_size(char *str)
>  
>  static void destroy_hist_trigger_attrs(struct hist_trigger_attrs *attrs)
>  {
> + unsigned int i;
> +
>   if (!attrs)
>   return;
>  
> + for (i = 0; i < attrs->n_assignments; i++)
> + kfree(attrs->assignment_str[i]);
> +
>   kfree(attrs->name);
>   kfree(attrs->sort_key_str);
>   kfree(attrs->keys_str);
> @@ -258,9 +270,9 @@ static int parse_assignment(char *str, struct 
> hist_trigger_attrs *attrs)
>   if ((strncmp(str, "key=", strlen("key=")) == 0) ||
>   (strncmp(str, "keys=", strlen("keys=")) == 0))
>   attrs->keys_str = kstrdup(str, GFP_KERNEL);
> - else if ((strncmp(str, "val=", strlen("val=")) == 0) ||
> -  (strncmp(str, "vals=", strlen("vals=")) == 0) ||
> -  (strncmp(str, "values=", strlen("values=")) == 0))
> + else if (((strncmp(str, "val=", strlen("val=")) == 0) ||
> +   (strncmp(str, "vals=", strlen("vals=")) == 0) ||
> +   (strncmp(str, "values=", strlen("values=")) == 0)))

Looks unnecessary too.

>   attrs->vals_str = kstrdup(str, GFP_KERNEL);
>   else if (strncmp(str, "sort=", strlen("sort=")) == 0)
>   attrs->sort_key_str = kstrdup(str, GFP_KERNEL);
> @@ -274,8 +286,22 @@ static int parse_assignment(char *str, struct 
> hist_trigger_attrs *attrs)
>   goto out;
>   }
>   attrs->map_bits = map_bits;
> - } else
> - ret = -EINVAL;
> + } else {
> + char *assignment;
> +
> + if (attrs->n_assignments == HIST_ASSIGNMENT_MAX) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + assignment = kstrdup(str, GFP_KERNEL);
> + if (!assignment) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + attrs->assignme

Re: [PATCH] llist: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

On Mon, Feb 13, 2017 at 05:43:26AM +, Al Viro wrote:
> On Mon, Feb 13, 2017 at 01:10:13PM +0900, Byungchul Park wrote:
> > Although llist provides proper APIs, they are not used. Make them used.
> 
> > @@ -231,12 +231,10 @@ static void __fput(struct file *file)
> >  static void delayed_fput(struct work_struct *unused)
> >  {
> > struct llist_node *node = llist_del_all(&delayed_fput_list);
> > -   struct llist_node *next;
> > +   struct file *f;
> >  
> > -   for (; node; node = next) {
> > -   next = llist_next(node);
> > -   __fput(llist_entry(node, struct file, f_u.fu_llist));
> > -   }
> > +   llist_for_each_entry(f, node, f_u.fu_llist)
> > +   __fput(f);
> >  }
> 
> #define llist_for_each_entry(pos, node, member) \
> for ((pos) = llist_entry((node), typeof(*(pos)), member);   \
>  &(pos)->member != NULL;\
>  (pos) = llist_entry((pos)->member.next, typeof(*(pos)), member))
> 
> Now, think what happens after __fput() frees the damn thing.  In the
> step of that loop, that is.
> 
> That kind of pattern (find next, do something with the current, proceed to
> the next we'd found before) is a strong hint that this "do something"
> might remove the thing from the list, or outright destroy it.  Both
> file_table.c and namespace.c chunks are breaking exactly that kind of
> places.
> 
> Please, don't do this kind of conversions blindly.  There _is_ another
> iterating primitive for such places, but figuring out which one is right
> is not something you can do without understanding what the code is doing.

I'm really sorry. I made a mistake. I should have used the safe version in
the case.

> And no, blind replacement of all such loops with llist_for_each_entry_safe,
> just in case, is not a good idea either.

Re: [PATCH] llist: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

On Mon, Feb 13, 2017 at 01:38:36PM +0800, Huang, Ying wrote:
> Hi, Byungchul,
> 
> Byungchul Park  writes:
> 
> > Although llist provides proper APIs, they are not used. Make them used.
> >
> > Signed-off-by: Byungchul Park 
> > ---
> >  drivers/md/bcache/closure.c | 15 ++-
> >  drivers/md/raid5.c  |  4 +---
> >  drivers/vhost/scsi.c|  9 ++---
> >  fs/file_table.c | 12 +---
> >  fs/namespace.c  | 12 +---
> >  include/linux/llist.h   |  3 +++
> >  kernel/irq_work.c   |  6 +-
> >  kernel/sched/core.c | 13 ++---
> >  mm/vmalloc.c|  8 +++-
> 
> I think you need to split the patch.  One for each subsystem, this makes
> it easier to be reviewed and merged.

Thank you. I will do it.

> 
> Best Regards,
> Huang, Ying
> 
> [snip]

Re: ANNOUNCE: mdadm 4.0 - A tool for managing md Soft RAID under Linux

[zhilong]

On 02/13/2017 01:08 PM, zhilong wrote:

Hi, Jes;


On 01/13/2017 12:41 AM, Jes Sorensen wrote:

On 01/11/17 23:24, Guoqing Jiang wrote:


On 01/12/2017 12:59 AM, Jes Sorensen wrote:

On 01/11/17 11:52, Shaohua Li wrote:

On Tue, Jan 10, 2017 at 11:49:04AM -0600, Bruce Dubbs wrote:

Jes Sorensen wrote:

I am pleased to announce the availability of
  mdadm version 4.0

It is available at the usual places:
http://www.kernel.org/pub/linux/utils/raid/mdadm/
and via git at
git://git.kernel.org/pub/scm/utils/mdadm/mdadm.git
  http://git.kernel.org/cgit/utils/mdadm/

The update in major version number primarily indicates this is a
release by it's new maintainer. In addition it contains a large 
number
of fixes in particular for IMSM RAID and clustered RAID 
support.  In

addition this release includes support for IMSM 4k sector drives,
failfast and better documentation for journaled RAID.

Thank you for the new release.  Unfortunately I get 9 failures
running the
test suite:

tests/00raid1...  FAILED
tests/07autoassemble...   FAILED
tests/07changelevels...   FAILED
tests/07revert-grow...FAILED
tests/07revert-inplace... FAILED
tests/07testreshape5...   FAILED
tests/10ddf-fail-twice... FAILED
tests/20raid5journal...   FAILED
tests/10ddf-incremental-wrong-order...  FAILED

Yep, several tests usually fail. It appears some checks aren't always
good.  At
least the 'check' function for reshape/resync isn't reliable in my
test, I saw
07changelevelintr fails frequently.
That is my experience as well - some of them are affected by the 
kernel

version too. We probably need to look into making them more reliable.
If possible, it could be a potential topic for lsf/mm raid 
discussion as

Coly suggested
in previous mail.

Is current test can run the test for different raid level, say, "./test
--raidtype=raid1" could
execute all the *r1* tests, does it make sense to do it if we don't
support it now.

We could have a discussion about this at LSF/MM, if someone is willing
to sponsor getting it accepted and we can get the right people there.

Note that the test suite also allows you to run all the 01 tests by
specifying ./test 01. I do like to see the test suite improved and made
more resilient.
I'm sorry for my late response, I'm just back to work today from 
vacation. In the past months, I learned and worked for cluster-md 
feature,
and I have draft one test suit for cluster-md feature. please refer to 
https://github.com/zhilongliu/clustermd-autotest
I'm very willing to do something for improving mdadm testing part, 
also wanna improve cluster-md test suit, welcome all comments for it.


  I would keep making cluster-md test scripts more and more stable, and 
finally apply to integrate into mdadm test part. :-)


Best regards,
-Zhilong

Cheers,
Jes

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



Thanks very much,
-Zhilong
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 23/25] Staging: rtl8192u: ieee80211: ieee80211_crypt.h - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.h | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.h 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.h
index 0b4ea431982d..005bf89aae65 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.h
@@ -30,7 +30,8 @@ struct ieee80211_crypto_ops {
 
/* init new crypto context (e.g., allocate private data space,
 * select IV, etc.); returns NULL on failure or pointer to allocated
-* private data on success */
+* private data on success
+*/
void * (*init)(int keyidx);
 
/* deinitialize crypto context and free allocated private data */
@@ -46,7 +47,8 @@ struct ieee80211_crypto_ops {
int (*decrypt_mpdu)(struct sk_buff *skb, int hdr_len, void *priv);
 
/* These functions are called for full MSDUs, i.e. full frames.
-* These can be NULL if full MSDU operations are not needed. */
+* These can be NULL if full MSDU operations are not needed.
+*/
int (*encrypt_msdu)(struct sk_buff *skb, int hdr_len, void *priv);
int (*decrypt_msdu)(struct sk_buff *skb, int keyidx, int hdr_len,
void *priv);
@@ -55,14 +57,16 @@ struct ieee80211_crypto_ops {
int (*get_key)(void *key, int len, u8 *seq, void *priv);
 
/* procfs handler for printing out key information and possible
-* statistics */
+* statistics
+*/
char * (*print_stats)(char *p, void *priv);
 
/* maximum number of bytes added by encryption; encrypt buf is
 * allocated with extra_prefix_len bytes, copy of in_buf, and
 * extra_postfix_len; encrypt need not use all this space, but
 * the result must start at the beginning of the buffer and correct
-* length must be returned */
+* length must be returned
+*/
int extra_prefix_len, extra_postfix_len;
 
struct module *owner;
-- 
2.11.1

[PATCH v2 24/25] Staging: rtl8192u: ieee80211: ieee80211_crypt.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c
index 9cf90d040cfe..8b2cd0c2caa7 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt.c
@@ -88,7 +88,8 @@ void ieee80211_crypt_delayed_deinit(struct ieee80211_device 
*ieee,
 
/* must not run ops->deinit() while there may be pending encrypt or
 * decrypt operations. Use a list of delayed deinits to avoid needing
-* locking. */
+* locking.
+*/
 
spin_lock_irqsave(&ieee->lock, flags);
list_add(&tmp->list, &ieee->crypt_deinit_list);
-- 
2.11.1

Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode

[Mike Galbraith]

On Sun, 2017-02-12 at 07:59 +0100, Mike Galbraith wrote:
> On Sun, 2017-02-12 at 14:05 +0900, Tejun Heo wrote:
> 
> > > I think cgroup tree depth is a more significant issue; because of
> > > hierarchy we often do tree walks (uo-to-root or down-to-task).
> > > 
> > > So creating elaborate trees is something I try not to do.
> > 
> > So, as long as the depth stays reasonable (single digit or lower),
> > what we try to do is keeping tree traversal operations aggregated or
> > located on slow paths.  There still are places that this overhead
> > shows up (e.g. the block controllers aren't too optimized) but it
> > isn't particularly difficult to make a handful of layers not matter at
> > all.
> 
> A handful of cpu bean counting layers stings considerably.

BTW, that overhead is also why merging cpu/cpuacct is not really as
wonderful as it may seem on paper.  If you only want to account, you
may not have anything to gain from group scheduling (in fact it may
wreck performance), but you'll pay for it.
 
> homer:/abuild # pipe-test 1  
> 2.010057 usecs/loop -- avg 2.010057 995.0 KHz
> 2.006630 usecs/loop -- avg 2.009714 995.2 KHz
> 2.127118 usecs/loop -- avg 2.021455 989.4 KHz
> 2.256244 usecs/loop -- avg 2.044934 978.0 KHz
> 1.993693 usecs/loop -- avg 2.039810 980.5 KHz
> ^C
> homer:/abuild # cgexec -g cpu:hurt pipe-test 1
> 2.771641 usecs/loop -- avg 2.771641 721.6 KHz
> 2.432333 usecs/loop -- avg 2.737710 730.5 KHz
> 2.750493 usecs/loop -- avg 2.738988 730.2 KHz
> 2.663203 usecs/loop -- avg 2.731410 732.2 KHz
> 2.762564 usecs/loop -- avg 2.734525 731.4 KHz
> ^C
> homer:/abuild # cgexec -g cpu:hurt/pain pipe-test 1
> 2.967201 usecs/loop -- avg 2.967201 674.0 KHz
> 3.049012 usecs/loop -- avg 2.975382 672.2 KHz
> 3.031226 usecs/loop -- avg 2.980966 670.9 KHz
> 2.954259 usecs/loop -- avg 2.978296 671.5 KHz
> 2.933432 usecs/loop -- avg 2.973809 672.5 KHz
> ^C
> ...
> homer:/abuild # cgexec -g cpu:hurt/pain/ouch/moan/groan pipe-test 1
> 4.417044 usecs/loop -- avg 4.417044 452.8 KHz
> 4.494913 usecs/loop -- avg 4.424831 452.0 KHz
> 4.253861 usecs/loop -- avg 4.407734 453.7 KHz
> 4.378059 usecs/loop -- avg 4.404766 454.1 KHz
> 4.179895 usecs/loop -- avg 4.382279 456.4 KHz

[PATCH v2 25/25] Staging: rtl8192u: ieee80211: ieee80211.h - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211.h | 61 +++---
 1 file changed, 36 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h 
b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
index 10bb23739748..71add69df815 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
@@ -329,12 +329,13 @@ typedef struct ieee_param {
 // linux under 2.6.9 release may not support it, so modify it for common use
 #define IEEE80211_DATA_LEN 2304
 /* Maximum size for the MA-UNITDATA primitive, 802.11 standard section
-   6.2.1.1.2.
-
-   The figure in section 7.1.2 suggests a body size of up to 2312
-   bytes is allowed, which is a bit confusing, I suspect this
-   represents the 2304 bytes of real data, plus a possible 8 bytes of
-   WEP IV and ICV. (this interpretation suggested by Ramiro Barreiro) */
+ *   6.2.1.1.2.
+ *
+ *   The figure in section 7.1.2 suggests a body size of up to 2312
+ *   bytes is allowed, which is a bit confusing, I suspect this
+ *   represents the 2304 bytes of real data, plus a possible 8 bytes of
+ *   WEP IV and ICV. (this interpretation suggested by Ramiro Barreiro)
+ */
 #define IEEE80211_1ADDR_LEN 10
 #define IEEE80211_2ADDR_LEN 16
 #define IEEE80211_3ADDR_LEN 24
@@ -685,7 +686,8 @@ struct ieee_ibss_seq {
 
 /* NOTE: This data is for statistical purposes; not all hardware provides this
  *   information for frames received.  Not setting these will not cause
- *   any adverse affects. */
+ *   any adverse affects.
+ */
 struct ieee80211_rx_stats {
u32 mac_time[2];
s8 rssi;
@@ -754,7 +756,8 @@ struct ieee80211_rx_stats {
 /* IEEE 802.11 requires that STA supports concurrent reception of at least
  * three fragmented frames. This define can be increased to support more
  * concurrent frames, but it should be noted that each entry can consume about
- * 2 kB of RAM and increasing cache size will slow down frame reassembly. */
+ * 2 kB of RAM and increasing cache size will slow down frame reassembly.
+ */
 #define IEEE80211_FRAG_CACHE_LEN 4
 
 struct ieee80211_frag_entry {
@@ -836,15 +839,15 @@ struct ieee80211_security {
 
 
 /*
- 802.11 data frame from AP
-  ,---.
-Bytes |  2   |  2   |6|6|6|  2   | 0..2312 |   4  |
-  |--|--|-|-|-|--|-|--|
-Desc. | ctrl | dura |  DA/RA  |   TA|SA   | Sequ |  frame  |  fcs |
-  |  | tion | (BSSID) | | | ence |  data   |  |
-  `---'
-Total: 28-2340 bytes
-*/
+ *  802.11 data frame from AP
+ *   ,---.
+ * Bytes |  2   |  2   |6|6|6|  2   | 0..2312 |   4  |
+ *   |--|--|-|-|-|--|-|--|
+ * Desc. | ctrl | dura |  DA/RA  |   TA|SA   | Sequ |  frame  |  fcs |
+ *   |  | tion | (BSSID) | | | ence |  data   |  |
+ *   `---'
+ *  Total: 28-2340 bytes
+ */
 
 /* Management Frame Information Element Types */
 enum ieee80211_mfie {
@@ -882,7 +885,8 @@ enum ieee80211_mfie {
 
 /* Minimal header; can be used for passing 802.11 frames with sufficient
  * information to determine what type of underlying data type is actually
- * stored in the data. */
+ * stored in the data.
+ */
 struct rtl_80211_hdr {
__le16 frame_ctl;
__le16 duration_id;
@@ -980,7 +984,8 @@ struct ieee80211_probe_response {
__le16 beacon_interval;
__le16 capability;
/* SSID, supported rates, FH params, DS params,
-* CF params, IBSS params, TIM (if beacon), RSN */
+* CF params, IBSS params, TIM (if beacon), RSN
+*/
struct ieee80211_info_element info_element[0];
 } __packed;
 
@@ -1055,7 +1060,8 @@ typedef union _frameqos {
 /* MAX_RATES_LENGTH needs to be 12.  The spec says 8, and many APs
  * only use 8, and then use extended rates for the remaining supported
  * rates.  Other APs, however, stick all of their supported rates on the
- * main rates information element... */
+ * main rates information element...
+ */
 #define MAX_RATES_LENGTH  ((u8)12)
 #define MAX_RATES_EX_LENGTH   ((u8)16)
 #define MAX_NETWORK_COUNT  128
@@ -1677,14 +1683,16 @@ struct ieee80211_device {
spinlock_t wpax_suitlist_lock;
 
int tx_headroom; /* Set to size of any additional room needed at front
- * of allocated Tx SKBs */
+ * of allocated Tx SKBs
+ */
u32 config;
 
/* WEP and other encrypti

[PATCH v2 22/25] Staging: rtl8192u: ieee80211: ieee80211_rx.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 91 +++
 1 file changed, 58 insertions(+), 33 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
index b1f2fdfcb718..99c39aa3d1b5 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
@@ -148,7 +148,8 @@ ieee80211_frag_cache_get(struct ieee80211_device *ieee,
memcpy(entry->dst_addr, hdr->addr1, ETH_ALEN);
} else {
/* received a fragment of a frame for which the head fragment
-* should have already been received */
+* should have already been received
+*/
entry = ieee80211_frag_cache_find(ieee, seq, frag, 
tid,hdr->addr2,
  hdr->addr1);
if (entry != NULL) {
@@ -207,7 +208,8 @@ static int ieee80211_frag_cache_invalidate(struct 
ieee80211_device *ieee,
  *
  * Responsible for handling management control frames
  *
- * Called by ieee80211_rx */
+ * Called by ieee80211_rx
+ */
 static inline int
 ieee80211_rx_frame_mgmt(struct ieee80211_device *ieee, struct sk_buff *skb,
struct ieee80211_rx_stats *rx_stats, u16 type,
@@ -240,8 +242,9 @@ ieee80211_rx_frame_mgmt(struct ieee80211_device *ieee, 
struct sk_buff *skb,
   ieee->dev->name);
return 0;
 /*
-  hostap_update_sta_ps(ieee, (struct hostap_ieee80211_hdr_4addr *)
-  skb->data);*/
+ *  hostap_update_sta_ps(ieee, (struct hostap_ieee80211_hdr_4addr *)
+ *  skb->data);
+ */
}
 
if (ieee->hostapd && type == IEEE80211_TYPE_MGMT) {
@@ -249,14 +252,16 @@ ieee80211_rx_frame_mgmt(struct ieee80211_device *ieee, 
struct sk_buff *skb,
ieee->iw_mode == IW_MODE_MASTER) {
struct sk_buff *skb2;
/* Process beacon frames also in kernel driver to
-* update STA(AP) table statistics */
+* update STA(AP) table statistics
+*/
skb2 = skb_clone(skb, GFP_ATOMIC);
if (skb2)
hostap_rx(skb2->dev, skb2, rx_stats);
}
 
/* send management frames to the user space daemon for
-* processing */
+* processing
+*/
ieee->apdevstats.rx_packets++;
ieee->apdevstats.rx_bytes += skb->len;
prism2_rx_80211(ieee->apdev, skb, rx_stats, PRISM2_RX_MGMT);
@@ -554,7 +559,8 @@ void ieee80211_indicate_packets(struct ieee80211_device 
*ieee, struct ieee80211_
  ethertype != ETH_P_AARP && ethertype != 
ETH_P_IPX) ||
 memcmp(sub_skb->data, bridge_tunnel_header, 
SNAP_SIZE) == 0)) {
/* remove RFC1042 or Bridge-Tunnel encapsulation and
-* replace EtherType */
+* replace EtherType
+*/
skb_pull(sub_skb, SNAP_SIZE);
memcpy(skb_push(sub_skb, ETH_ALEN), prxb->src, 
ETH_ALEN);
memcpy(skb_push(sub_skb, ETH_ALEN), prxb->dst, 
ETH_ALEN);
@@ -885,7 +891,8 @@ static u8 parse_subframe(struct sk_buff *skb,
 
 /* All received frames are sent to this function. @skb contains the frame in
  * IEEE 802.11 format, i.e., in the format it was sent over air.
- * This function is called only as a tasklet (software IRQ). */
+ * This function is called only as a tasklet (software IRQ).
+ */
 int ieee80211_rx(struct ieee80211_device *ieee, struct sk_buff *skb,
 struct ieee80211_rx_stats *rx_stats)
 {
@@ -949,7 +956,8 @@ int ieee80211_rx(struct ieee80211_device *ieee, struct 
sk_buff *skb,
//IEEE80211_DEBUG_DATA(IEEE80211_DL_DATA, skb->data, skb->len);
 #ifdef NOT_YET
/* Put this code here so that we avoid duplicating it in all
-* Rx paths. - Jean II */
+* Rx paths. - Jean II
+*/
 #ifdef IW_WIRELESS_SPY /* defined in iw_handler.h */
/* If spy monitoring on */
if (iface->spy_data.spy_number > 0) {
@@ -984,7 +992,8 @@ int ieee80211_rx(struct ieee80211_device *ieee, struct 
sk_buff *skb,
 * bcrx_sta_key parameter is set, station specific key is used
 * even with broad/multicast targets (this is against IEEE
 * 802.11, but makes it easier to use different keys with
-* stations that do not support WEP key mapping). */
+* stations that do not support WEP key mapping).
+*/
 
if (!(hdr->addr1[0] & 0x01) || local->bcrx_sta_key)
  

[PATCH v2 19/25] Staging: rtl8192u: ieee80211: rtl819x_BA.h - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/rtl819x_BA.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_BA.h 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_BA.h
index 2c398ca9a8ac..e61f608718b1 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_BA.h
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_BA.h
@@ -19,12 +19,12 @@
 #defineDELBA_REASON_UNKNOWN_BA 38
 #defineDELBA_REASON_TIMEOUT39
 /*  whether need define BA Action frames here?
-struct ieee80211_ADDBA_Req{
-   struct ieee80211_header_data header;
-   u8  category;
-   u8
-} __attribute__ ((packed));
-*/
+ *struct ieee80211_ADDBA_Req{
+ * struct ieee80211_header_data header;
+ * u8  category;
+ * u8
+ *} __attribute__ ((packed));
+ */
 //Is this need?I put here just to make it easier to define structure BA_RECORD 
//WB
 typedef union _SEQUENCE_CONTROL{
u16 ShortData;
-- 
2.11.1

[PATCH v2 20/25] Staging: rtl8192u: ieee80211: ieee80211_wx.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c | 87 ---
 1 file changed, 47 insertions(+), 40 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
index 563d7fed6e1c..0d24158e038a 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
@@ -1,34 +1,34 @@
 /**
-
-  Copyright(c) 2004 Intel Corporation. All rights reserved.
-
-  Portions of this file are based on the WEP enablement code provided by the
-  Host AP project hostap-drivers v0.1.3
-  Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen
-  
-  Copyright (c) 2002-2003, Jouni Malinen 
-
-  This program is free software; you can redistribute it and/or modify it
-  under the terms of version 2 of the GNU General Public License 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, write to the Free Software Foundation, Inc., 59
-  Temple Place - Suite 330, Boston, MA  02111-1307, USA.
-
-  The full GNU General Public License is included in this distribution in the
-  file called LICENSE.
-
-  Contact Information:
-  James P. Ketrenos 
-  Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
-
-**/
+ *
+ *  Copyright(c) 2004 Intel Corporation. All rights reserved.
+ *
+ *  Portions of this file are based on the WEP enablement code provided by the
+ *  Host AP project hostap-drivers v0.1.3
+ *  Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen
+ *  
+ *  Copyright (c) 2002-2003, Jouni Malinen 
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of version 2 of the GNU General Public License 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, write to the Free Software Foundation, Inc., 59
+ *  Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+ *
+ *  The full GNU General Public License is included in this distribution in the
+ *  file called LICENSE.
+ *
+ *  Contact Information:
+ *  James P. Ketrenos 
+ *  Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+ *
+ 
**/
 #include 
 #include 
 #include 
@@ -108,7 +108,8 @@ static inline char *rtl819x_translate_scan(struct 
ieee80211_device *ieee,
/* Add frequency/channel */
iwe.cmd = SIOCGIWFREQ;
 /* iwe.u.freq.m = ieee80211_frequency(network->channel, network->mode);
-   iwe.u.freq.e = 3; */
+ * iwe.u.freq.e = 3;
+ */
iwe.u.freq.m = network->channel;
iwe.u.freq.e = 0;
iwe.u.freq.i = 0;
@@ -227,7 +228,8 @@ static inline char *rtl819x_translate_scan(struct 
ieee80211_device *ieee,
 
 
/* Add EXTRA: Age to display seconds since last beacon/probe response
-* for given network. */
+* for given network.
+*/
iwe.cmd = IWEVCUSTOM;
p = custom;
p += snprintf(p, MAX_CUSTOM_LEN - (p - custom),
@@ -325,7 +327,8 @@ int ieee80211_wx_set_encode(struct ieee80211_device *ieee,
IEEE80211_DEBUG_WX("Disabling encryption.\n");
 
/* Check all the keys to see if any are still configured,
-* and if no key index was provided, de-init them all */
+* and if no key index was provided, de-init them all
+*/
for (i = 0; i < WEP_KEYS; i++) {
if (ieee->crypt[i] != NULL) {
if (key_provided)
@@ -352,7 +355,8 @@ int ieee80211_wx_set_encode(struct ieee80211_device *ieee,
if (*crypt != NULL && (*crypt)->ops != NULL &&
strcmp((*crypt)->ops->name, "WEP") != 0) {
/* changing to use WEP; deinit previously used algorithm
-* on this key */
+* on this key
+*/
ieee80211_crypt_delayed_deinit(ieee, crypt);
}
 
@@ -399,7 +403,8 @@ int ieee80211_wx_set_encode(struct 

[PATCH v2 21/25] Staging: rtl8192u: ieee80211: ieee80211_tx.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c | 290 +++---
 1 file changed, 150 insertions(+), 140 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
index 2b0e1b4b2345..3a0a4ce80211 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
@@ -1,35 +1,34 @@
 /**
-
-  Copyright(c) 2003 - 2004 Intel Corporation. All rights reserved.
-
-  This program is free software; you can redistribute it and/or modify it
-  under the terms of version 2 of the GNU General Public License 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, write to the Free Software Foundation, Inc., 59
-  Temple Place - Suite 330, Boston, MA  02111-1307, USA.
-
-  The full GNU General Public License is included in this distribution in the
-  file called LICENSE.
-
-  Contact Information:
-  James P. Ketrenos 
-  Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
-
-**
-
-  Few modifications for Realtek's Wi-Fi drivers by
-  Andrea Merello 
-
-  A special thanks goes to Realtek for their support !
-
-**/
+ *
+ *  Copyright(c) 2003 - 2004 Intel Corporation. All rights reserved.
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of version 2 of the GNU General Public License 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, write to the Free Software Foundation, Inc., 59
+ *  Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+ *
+ *  The full GNU General Public License is included in this distribution in the
+ *  file called LICENSE.
+ *
+ *  Contact Information:
+ *  James P. Ketrenos 
+ *  Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+ *
+ *
+ *  Few modifications for Realtek's Wi-Fi drivers by
+ *  Andrea Merello 
+ *
+ *  A special thanks goes to Realtek for their support !
+ *
+ 
**/
 
 #include 
 #include 
@@ -55,101 +54,101 @@
 
 
 /*
-
-
-802.11 Data Frame
-
-
-802.11 frame_contorl for data frames - 2 bytes
- 
,-.
-bits | 0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |  8  |  9  |  a  |  b  |  
c  |  d  |  e   |
- 
||-|-|-|-|-|-|-|-|-|-|-|-|-|--|
-val  | 0  |  0  |  0  |  1  |  x  |  0  |  0  |  0  |  1  |  0  |  x  |  x  |  
x  |  x  |  x   |
- 
||-|-|-|-|-|-|-|-|-|-|-|-|-|--|
-desc | ^-ver-^  |  ^type-^  |  ^-subtype-^  | to  |from |more |retry| 
pwr |more |wep   |
- |  |   | x=0 data,x=1 data+ack | DS  | DS  |frag | | 
mgm |data |  |
- 
'-'
-/\
-|
-802.11 Data Frame   |
-   ,- 'ctrl' expands to >---'
-  |
-  ,--'---,-.
-Bytes |  2   |  2   |6|6|6|  2   | 0..2312 |   4  |
-  |--|--|-|-|-|--|-|--|
-Desc. | ctrl | dura |  DA/RA  |   TA|SA   | Sequ |  Frame  |  fcs |
-  |  | tion | (BSSID) | | | ence |  data   |  |
-  `--| |--'
-Total: 28 non-data bytes `.'
-  |
-   .- 'Frame data' expands to <---'
-   |
-   V
-  ,---.
-Bytes |  1   |  1   |1| 

[PATCH v2 18/25] Staging: rtl8192u: ieee80211: rtl819x_HT.h - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 69 +
 1 file changed, 35 insertions(+), 34 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
index c3aabbaac7ae..d270c8ac807c 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
@@ -86,38 +86,38 @@ typedef enum _CHNLOP{
((_pHTInfo)->ChnlOp > CHNLOP_NONE) ? TRUE : FALSE
 
 /*
-typedefunion _HT_CAPABILITY{
-   u16 ShortData;
-   u8  CharData[2];
-   struct
-   {
-   u16 AdvCoding:1;
-   u16 ChlWidth:1;
-   u16 MimoPwrSave:2;
-   u16 GreenField:1;
-   u16 ShortGI20Mhz:1;
-   u16 ShortGI40Mhz:1;
-   u16 STBC:1;
-   u16 BeamForm:1;
-   u16 DelayBA:1;
-   u16 MaxAMSDUSize:1;
-   u16 DssCCk:1;
-   u16 PSMP:1;
-   u16 Rsvd:3;
-   }Field;
-}HT_CAPABILITY, *PHT_CAPABILITY;
-
-typedefunion _HT_CAPABILITY_MACPARA{
-   u8  ShortData;
-   u8  CharData[1];
-   struct
-   {
-   u8  MaxRxAMPDU:2;
-   u8  MPDUDensity:2;
-   u8  Rsvd:4;
-   }Field;
-}HT_CAPABILITY_MACPARA, *PHT_CAPABILITY_MACPARA;
-*/
+ * typedef union _HT_CAPABILITY{
+ * u16 ShortData;
+ * u8  CharData[2];
+ * struct
+ * {
+ * u16 AdvCoding:1;
+ * u16 ChlWidth:1;
+ * u16 MimoPwrSave:2;
+ * u16 GreenField:1;
+ * u16 ShortGI20Mhz:1;
+ * u16 ShortGI40Mhz:1;
+ * u16 STBC:1;
+ * u16 BeamForm:1;
+ * u16 DelayBA:1;
+ * u16 MaxAMSDUSize:1;
+ * u16 DssCCk:1;
+ * u16 PSMP:1;
+ * u16 Rsvd:3;
+ * }Field;
+ * }HT_CAPABILITY, *PHT_CAPABILITY;
+ *
+ * typedef union _HT_CAPABILITY_MACPARA{
+ * u8  ShortData;
+ * u8  CharData[1];
+ * struct
+ * {
+ * u8  MaxRxAMPDU:2;
+ * u8  MPDUDensity:2;
+ * u8  Rsvd:4;
+ * }Field;
+ * }HT_CAPABILITY_MACPARA, *PHT_CAPABILITY_MACPARA;
+ */
 
 typedef enum _HT_ACTION{
ACT_RECOMMAND_WIDTH = 0,
@@ -421,8 +421,9 @@ extern u8 MCS_FILTER_ALL[16];
 extern u8 MCS_FILTER_1SS[16];
 
 /* 2007/07/11 MH Modify the macro. Becaus STA may link with a N-AP. If we set
-   STA in A/B/G mode and AP is still in N mode. The macro will be wrong. We 
have
-   to add a macro to judge wireless mode. */
+ * STA in A/B/G mode and AP is still in N mode. The macro will be wrong. We 
have
+ * to add a macro to judge wireless mode.
+ */
 #define PICK_RATE(_nLegacyRate, _nMcsRate) \
(_nMcsRate==0)?(_nLegacyRate&0x7f):(_nMcsRate)
 /* 2007/07/12 MH We only define legacy and HT wireless mode now. */
-- 
2.11.1

[PATCH v2 16/25] Staging: rtl8192u: ieee80211: rtl819x_HTProc.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 .../staging/rtl8192u/ieee80211/rtl819x_HTProc.c| 164 ++---
 1 file changed, 82 insertions(+), 82 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
index c27397b14adb..9e8ed8c2e21e 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
@@ -217,8 +217,8 @@ void HTDebugHTInfo(u8 *InfoIE, u8 *TitleString)
 }
 
 /*
-*  Return: true if station in half n mode and AP supports 40 bw
-*/
+ * Return: true if station in half n mode and AP supports 40 bw
+ */
 static bool IsHTHalfNmode40Bandwidth(struct ieee80211_device *ieee)
 {
boolretValue = false;
@@ -412,7 +412,7 @@ static void HTIOTPeerDetermine(struct ieee80211_device 
*ieee)
  *  u8 *   PeerMacAddr
  *  output:  none
  *  return:  return 1 if driver should declare MCS13 only(otherwise return 0)
-  * 
*/
+ 
**/
 static u8 HTIOTActIsDisableMCS14(struct ieee80211_device *ieee, u8 
*PeerMacAddr)
 {
return 0;
@@ -420,17 +420,17 @@ static u8 HTIOTActIsDisableMCS14(struct ieee80211_device 
*ieee, u8 *PeerMacAddr)
 
 
 /**
-* Function:HTIOTActIsDisableMCS15
-*
-* Overview:Check whether driver should declare capability of receiving 
MCS15
-*
-* Input:
-*  PADAPTERAdapter,
-*
-* Output:  None
-* Return:  true if driver should disable MCS15
-* 2008.04.15   Emily
-*/
+ * Function:   HTIOTActIsDisableMCS15
+ *
+ * Overview:   Check whether driver should declare capability of receiving 
MCS15
+ *
+ * Input:
+ * PADAPTERAdapter,
+ *
+ * Output: None
+ * Return: true if driver should disable MCS15
+ * 2008.04.15  Emily
+ */
 static bool HTIOTActIsDisableMCS15(struct ieee80211_device *ieee)
 {
bool retValue = false;
@@ -457,17 +457,17 @@ static bool HTIOTActIsDisableMCS15(struct 
ieee80211_device *ieee)
 }
 
 /**
-* Function:HTIOTActIsDisableMCSTwoSpatialStream
-*
-* Overview:Check whether driver should declare capability of receiving All 
2 ss packets
-*
-* Input:
-*  PADAPTERAdapter,
-*
-* Output:  None
-* Return:  true if driver should disable all two spatial stream packet
-* 2008.04.21   Emily
-*/
+ * Function:   HTIOTActIsDisableMCSTwoSpatialStream
+ *
+ * Overview:   Check whether driver should declare capability of receiving All 
2 ss packets
+ *
+ * Input:
+ * PADAPTERAdapter,
+ *
+ * Output: None
+ * Return: true if driver should disable all two spatial stream packet
+ * 2008.04.21  Emily
+ */
 static bool HTIOTActIsDisableMCSTwoSpatialStream(struct ieee80211_device *ieee,
 u8 *PeerMacAddr)
 {
@@ -483,7 +483,7 @@ static bool HTIOTActIsDisableMCSTwoSpatialStream(struct 
ieee80211_device *ieee,
  *  u8*PeerMacAddr
  *  output:  none
  *  return:  return 1 if driver should disable EDCA turbo mode(otherwise 
return 0)
-  * 
*/
+ 
**/
 static u8 HTIOTActIsDisableEDCATurbo(struct ieee80211_device *ieee,
 u8 *PeerMacAddr)
 {  /* default enable EDCA Turbo mode. */
@@ -495,7 +495,7 @@ static u8 HTIOTActIsDisableEDCATurbo(struct 
ieee80211_device *ieee,
  *   input:  struct ieee80211_network *network   //current network we live
  *  output:  none
  *  return:  return 1 if true
-  * 
*/
+ 
*/
 static u8 HTIOTActIsMgntUseCCK6M(struct ieee80211_network *network)
 {
u8  retValue = 0;
@@ -542,7 +542,7 @@ void HTResetIOTSetting(
  *  output:  none
  *  return:  none
  *  notice:  posHTCap can't be null and should be initialized before.
-  * 
*/
+ 
**/
 void HTConstructCapabilityElement(struct ieee80211_device *ieee, u8 *posHTCap, 
u8 *len, u8 IsEncrypt)
 {
PRT_HIGH_THROUGHPUT pHT = ieee->pHTInfo;

[PATCH v2 17/25] Staging: rtl8192u: ieee80211: rtl819x_BAProc.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 .../staging/rtl8192u/ieee80211/rtl819x_BAProc.c| 28 +++---
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
index 98fbb6ef484d..e8c4b2a05f49 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
@@ -14,7 +14,7 @@
  *   input:  PBA_RECORDpBA  //BA entry to be enabled
  *  u16Time //indicate time delay.
  *  output:  none
-/
+ 
/
 static void ActivateBAEntry(struct ieee80211_device *ieee, PBA_RECORD pBA, u16 
Time)
 {
pBA->bValid = true;
@@ -26,7 +26,7 @@ static void ActivateBAEntry(struct ieee80211_device *ieee, 
PBA_RECORD pBA, u16 T
  *function:  deactivate BA entry, including its timer.
  *   input:  PBA_RECORDpBA  //BA entry to be disabled
  *  output:  none
-/
+ 
/
 static void DeActivateBAEntry(struct ieee80211_device *ieee, PBA_RECORD pBA)
 {
pBA->bValid = false;
@@ -38,7 +38,7 @@ static void DeActivateBAEntry(struct ieee80211_device *ieee, 
PBA_RECORD pBA)
  *  PTX_TS_RECORD  pTxTs //Tx Ts which is to deactivate BA 
entry.
  *  output:  none
  *  notice:  As PTX_TS_RECORD structure will be defined in QOS, so wait to be 
merged. //FIXME
-/
+ 
/
 static u8 TxTsDeleteBA(struct ieee80211_device *ieee, PTX_TS_RECORD pTxTs)
 {
PBA_RECORD  pAdmittedBa = &pTxTs->TxAdmittedBARecord;  
//These two BA entries must exist in TS structure
@@ -68,7 +68,7 @@ static u8 TxTsDeleteBA(struct ieee80211_device *ieee, 
PTX_TS_RECORD pTxTs)
  *  PRX_TS_RECORD  pRxTs //Rx Ts which is to deactivate BA 
entry.
  *  output:  none
  *  notice:  As PRX_TS_RECORD structure will be defined in QOS, so wait to be 
merged. //FIXME, same with above
-/
+ 
/
 static u8 RxTsDeleteBA(struct ieee80211_device *ieee, PRX_TS_RECORD pRxTs)
 {
PBA_RECORD  pBa = &pRxTs->RxAdmittedBARecord;
@@ -88,7 +88,7 @@ static u8 RxTsDeleteBA(struct ieee80211_device *ieee, 
PRX_TS_RECORD pRxTs)
  *   input:
  *  PBA_RECORD pBA //entry to be reset
  *  output:  none
-/
+ 
/
 void ResetBaEntry(PBA_RECORD pBA)
 {
pBA->bValid = false;
@@ -106,7 +106,7 @@ void ResetBaEntry(PBA_RECORD pBA)
  *  u8 type//indicate whether it's 
RSP(ACT_ADDBARSP) ow REQ(ACT_ADDBAREQ)
  *  output:  none
  *  return:  sk_buff*  skb //return constructed skb to xmit
-***/
+ 
***/
 static struct sk_buff *ieee80211_ADDBA(struct ieee80211_device *ieee, u8 *Dst, 
PBA_RECORD pBA, u16 StatusCode, u8 type)
 {
struct sk_buff *skb = NULL;
@@ -184,7 +184,7 @@ static struct sk_buff *ieee80211_ADDBA(struct 
ieee80211_device *ieee, u8 *Dst, P
  *  u16ReasonCode  //status code.
  *  output:  none
  *  return:  sk_buff*  skb //return constructed skb to xmit
-/
+ 
/
 static struct sk_buff *ieee80211_DELBA(
struct ieee80211_device  *ieee,
u8   *dst,
@@ -250,7 +250,7 @@ static struct sk_buff *ieee80211_DELBA(
  *  PBA_RECORD pBA //BA_RECORD entry whi

[PATCH v2 14/25] Staging: rtl8192u: ieee80211: ieee80211_softmac.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 .../staging/rtl8192u/ieee80211/ieee80211_softmac.c | 71 +++---
 1 file changed, 36 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
index 844e257ece7a..ab1018c0bb0b 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
@@ -203,14 +203,14 @@ static u8 MgntQuery_MgntFrameTxRate(struct 
ieee80211_device *ieee)
}
 
/*
-   // Data rate of ProbeReq is already decided. Annie, 2005-03-31
-   if( pMgntInfo->bScanInProgress || (pMgntInfo->bDualModeScanStep!=0) )
-   {
-   if(pMgntInfo->dot11CurrentWirelessMode==WIRELESS_MODE_A)
-   rate = 0x0c;
-   else
-   rate = 0x02;
-   }
+*  //Data rate of ProbeReq is already decided. Annie, 2005-03-31
+* if( pMgntInfo->bScanInProgress || (pMgntInfo->bDualModeScanStep!=0) )
+* {
+* if(pMgntInfo->dot11CurrentWirelessMode==WIRELESS_MODE_A)
+* rate = 0x0c;
+* else
+* rate = 0x02;
+* }
 */
return rate;
 }
@@ -270,10 +270,10 @@ inline void softmac_mgmt_xmit(struct sk_buff *skb, struct 
ieee80211_device *ieee

if(!ieee->check_nic_enough_desc(ieee->dev,tcb_desc->queue_index)||\

(skb_queue_len(&ieee->skb_waitQ[tcb_desc->queue_index]) != 0)||\
(ieee->queue_stop) ) {
-   /* insert the skb packet to the management queue */
-   /* as for the completion function, it does not need
+   /* insert the skb packet to the management queue
+* as for the completion function, it does not need
 * to check it any more.
-* */
+*/
printk("%s():insert to waitqueue!\n",__func__);
skb_queue_tail(&ieee->skb_waitQ[tcb_desc->queue_index], 
skb);
} else {
@@ -1455,8 +1455,8 @@ inline void ieee80211_softmac_new_net(struct 
ieee80211_device *ieee, struct ieee
(!apset && ssidset && ssidbroad && ssidmatch)
){
/* if the essid is hidden replace it with the
-   * essid provided by the user.
-   */
+* essid provided by the user.
+*/
if (!ssidbroad) {
strncpy(tmp_ssid, 
ieee->current_network.ssid, IW_ESSID_MAX_SIZE);
tmp_ssid_len = 
ieee->current_network.ssid_len;
@@ -1726,11 +1726,10 @@ static short ieee80211_sta_ps_sleep(struct 
ieee80211_device *ieee, u32 *time_h,
int timeout = ieee->ps_timeout;
u8 dtim;
/*if(ieee->ps == IEEE80211_PS_DISABLED ||
-   ieee->iw_mode != IW_MODE_INFRA ||
-   ieee->state != IEEE80211_LINKED)
-
-   return 0;
-   */
+*  ieee->iw_mode != IW_MODE_INFRA ||
+*  ieee->state != IEEE80211_LINKED)
+*  return 0;
+*/
dtim = ieee->current_network.dtim_data;
if(!(dtim & IEEE80211_DTIM_VALID))
return 0;
@@ -2092,8 +2091,8 @@ ieee80211_rx_frame_softmac(struct ieee80211_device *ieee, 
struct sk_buff *skb,
case IEEE80211_STYPE_DISASSOC:
case IEEE80211_STYPE_DEAUTH:
/* FIXME for now repeat all the association procedure
-   * both for disassociation and deauthentication
-   */
+* both for disassociation and deauthentication
+*/
if ((ieee->softmac_features & IEEE_SOFTMAC_ASSOCIATE) &&
ieee->state == IEEE80211_LINKED &&
ieee->iw_mode == IW_MODE_INFRA){
@@ -2168,7 +2167,7 @@ void ieee80211_softmac_xmit(struct ieee80211_txb *txb, 
struct ieee80211_device *
/* insert the skb packet to the wait queue */
/* as for the completion function, it does not need
 * to check it any more.
-* */
+*/
//printk("error:no descriptor left@queue_index %d\n", 
queue_index);
//ieee80211_stop_queue(ieee);
 #ifdef USB_TX_DRIVER_AGGREGATION_ENABLE
@@ -2517,18 +2516,18 @@ static void ieee80211_associate_retry_wq(struct 
work_struct *work)
goto exit;
 
/* until we do not set the state to IEEE80211_NOLINK
-   * there are no possibility to have someone else trying
-   * to start an association procedure (we get here with
-   * ieee->state = IEEE

Re: [PATCH] llist: Don't reinvent the wheel but use existing llist API

[Al Viro]

On Mon, Feb 13, 2017 at 01:10:13PM +0900, Byungchul Park wrote:
> Although llist provides proper APIs, they are not used. Make them used.

> @@ -231,12 +231,10 @@ static void __fput(struct file *file)
>  static void delayed_fput(struct work_struct *unused)
>  {
>   struct llist_node *node = llist_del_all(&delayed_fput_list);
> - struct llist_node *next;
> + struct file *f;
>  
> - for (; node; node = next) {
> - next = llist_next(node);
> - __fput(llist_entry(node, struct file, f_u.fu_llist));
> - }
> + llist_for_each_entry(f, node, f_u.fu_llist)
> + __fput(f);
>  }

#define llist_for_each_entry(pos, node, member) \
for ((pos) = llist_entry((node), typeof(*(pos)), member);   \
 &(pos)->member != NULL;\
 (pos) = llist_entry((pos)->member.next, typeof(*(pos)), member))

Now, think what happens after __fput() frees the damn thing.  In the
step of that loop, that is.

That kind of pattern (find next, do something with the current, proceed to
the next we'd found before) is a strong hint that this "do something"
might remove the thing from the list, or outright destroy it.  Both
file_table.c and namespace.c chunks are breaking exactly that kind of
places.

Please, don't do this kind of conversions blindly.  There _is_ another
iterating primitive for such places, but figuring out which one is right
is not something you can do without understanding what the code is doing.
And no, blind replacement of all such loops with llist_for_each_entry_safe,
just in case, is not a good idea either.

[PATCH v2 15/25] Staging: rtl8192u: ieee80211: ieee80211_module.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 .../staging/rtl8192u/ieee80211/ieee80211_module.c  | 60 +++---
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
index 30fff6c5696b..b7fcc4da9737 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
@@ -1,34 +1,34 @@
 
/***
-
-  Copyright(c) 2004 Intel Corporation. All rights reserved.
-
-  Portions of this file are based on the WEP enablement code provided by the
-  Host AP project hostap-drivers v0.1.3
-  Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen
-  
-  Copyright (c) 2002-2003, Jouni Malinen 
-
-  This program is free software; you can redistribute it and/or modify it
-  under the terms of version 2 of the GNU General Public License 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, write to the Free Software Foundation, Inc., 59
-  Temple Place - Suite 330, Boston, MA  02111-1307, USA.
-
-  The full GNU General Public License is included in this distribution in the
-  file called LICENSE.
-
-  Contact Information:
-  James P. Ketrenos 
-  Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
-
-***/
+ *
+ *  Copyright(c) 2004 Intel Corporation. All rights reserved.
+ *
+ *  Portions of this file are based on the WEP enablement code provided by the
+ *  Host AP project hostap-drivers v0.1.3
+ *  Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen
+ *  
+ *  Copyright (c) 2002-2003, Jouni Malinen 
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of version 2 of the GNU General Public License 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, write to the Free Software Foundation, Inc., 59
+ *  Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+ *
+ *  The full GNU General Public License is included in this distribution in the
+ *  file called LICENSE.
+ *
+ *  Contact Information:
+ *  James P. Ketrenos 
+ *  Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+ *
+ 
***/
 
 #include 
 /* #include  */
-- 
2.11.1

[PATCH v2 12/25] Staging: rtl8192u: ieee80211: ieee80211_crypt_wep.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
index 1999bc5cbbc1..a05dae9f5918 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
@@ -109,7 +109,8 @@ static int prism2_wep_encrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
 
/* Fluhrer, Mantin, and Shamir have reported weaknesses in the key
 * scheduling algorithm of RC4. At least IVs (KeyByte + 3, 0xff, N)
-* can be used to speedup attacks, so avoid using them. */
+* can be used to speedup attacks, so avoid using them.
+*/
if ((wep->iv & 0xff00) == 0xff00) {
u8 B = (wep->iv >> 16) & 0xff;
 
-- 
2.11.1

[PATCH v2 13/25] Staging: rtl8192u: ieee80211: rtl819x_TSProc.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
index b9ff8fec2edf..b4c13fff2c65 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
@@ -21,7 +21,7 @@ static void TsInactTimeout(unsigned long data)
  *   input:  unsigned long  data   //acturally we send 
TX_TS_RECORD or RX_TS_RECORD to these timer
  *  return:  NULL
  *  notice:
-/
+ 
/
 static void RxPktPendingTimeout(unsigned long data)
 {
PRX_TS_RECORD   pRxTs = (PRX_TS_RECORD)data;
@@ -95,7 +95,7 @@ static void RxPktPendingTimeout(unsigned long data)
  *   input:  unsigned long  data   //acturally we send 
TX_TS_RECORD or RX_TS_RECORD to these timer
  *  return:  NULL
  *  notice:
-/
+ 
/
 static void TsAddBaProcess(unsigned long data)
 {
PTX_TS_RECORD   pTxTs = (PTX_TS_RECORD)data;
-- 
2.11.1

[PATCH v2 11/25] Staging: rtl8192u: r8180_93cx6.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/r8180_93cx6.c | 36 +-
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8180_93cx6.c 
b/drivers/staging/rtl8192u/r8180_93cx6.c
index f35defc36fd9..c414efc0662e 100644
--- a/drivers/staging/rtl8192u/r8180_93cx6.c
+++ b/drivers/staging/rtl8192u/r8180_93cx6.c
@@ -1,22 +1,22 @@
 /*
-   This files contains card eeprom (93c46 or 93c56) programming routines,
-   memory is addressed by 16 bits words.
-
-   This is part of rtl8180 OpenSource driver.
-   Copyright (C) Andrea Merello 2004  
-   Released under the terms of GPL (General Public Licence)
-
-   Parts of this driver are based on the GPL part of the
-   official realtek driver.
-
-   Parts of this driver are based on the rtl8180 driver skeleton
-   from Patric Schenke & Andres Salomon.
-
-   Parts of this driver are based on the Intel Pro Wireless 2100 GPL driver.
-
-   We want to thank the Authors of those projects and the Ndiswrapper
-   project Authors.
-*/
+ *  This files contains card eeprom (93c46 or 93c56) programming routines,
+ *  memory is addressed by 16 bits words.
+ *
+ *  This is part of rtl8180 OpenSource driver.
+ *  Copyright (C) Andrea Merello 2004  
+ *  Released under the terms of GPL (General Public Licence)
+ *
+ *  Parts of this driver are based on the GPL part of the
+ *  official realtek driver.
+ *
+ *  Parts of this driver are based on the rtl8180 driver skeleton
+ *  from Patric Schenke & Andres Salomon.
+ *
+ *  Parts of this driver are based on the Intel Pro Wireless 2100 GPL driver.
+ *
+ *  We want to thank the Authors of those projects and the Ndiswrapper
+ *  project Authors.
+ */
 
 #include "r8180_93cx6.h"
 
-- 
2.11.1

[PATCH v2 10/25] Staging: rtl8192u: r8190_rtl8256.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/r8190_rtl8256.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8190_rtl8256.c 
b/drivers/staging/rtl8192u/r8190_rtl8256.c
index d733fb2ade91..e54f6fad2e68 100644
--- a/drivers/staging/rtl8192u/r8190_rtl8256.c
+++ b/drivers/staging/rtl8192u/r8190_rtl8256.c
@@ -1,12 +1,12 @@
 /*
-* This is part of the rtl8192 driver
-* released under the GPL (See file COPYING for details).
-*
-* This files contains programming code for the rtl8256
-* radio frontend.
-*
-* *Many* thanks to Realtek Corp. for their great support!
-*/
+ * This is part of the rtl8192 driver
+ * released under the GPL (See file COPYING for details).
+ *
+ * This files contains programming code for the rtl8256
+ * radio frontend.
+ *
+ * *Many* thanks to Realtek Corp. for their great support!
+ */
 
 #include "r8192U.h"
 #include "r8192U_hw.h"
-- 
2.11.1

[PATCH v2 09/25] Staging: rtl8192u: r8190_rtl8256.h - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/r8190_rtl8256.h | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8190_rtl8256.h 
b/drivers/staging/rtl8192u/r8190_rtl8256.h
index 1ba4f83b520e..5c325ce9d631 100644
--- a/drivers/staging/rtl8192u/r8190_rtl8256.h
+++ b/drivers/staging/rtl8192u/r8190_rtl8256.h
@@ -1,14 +1,14 @@
 /*
-  This is part of the rtl8180-sa2400 driver
-  released under the GPL (See file COPYING for details).
-  Copyright (c) 2005 Andrea Merello 
-
-  This files contains programming code for the rtl8256
-  radio frontend.
-
-  *Many* thanks to Realtek Corp. for their great support!
-
-*/
+ *  This is part of the rtl8180-sa2400 driver
+ *  released under the GPL (See file COPYING for details).
+ *  Copyright (c) 2005 Andrea Merello 
+ *
+ *
+ *  This files contains programming code for the rtl8256
+ *  radio frontend.
+ *
+ *  *Many* thanks to Realtek Corp. for their great support!
+ */
 
 #ifndef RTL8225H
 #define RTL8225H
-- 
2.11.1

[RESEND PATCH 0/2] sched/fair: Add documentation and optimize __update_sched_avg()

[Yuyang Du]

Hi Peter,

I found I have some patches that go nowhere, out of which two stand out. So I 
resend them.

The first one adds a document about how to calculate the constants used in load 
tracking,
which was suggested by you and mentioned in commit 
7b20b916e953cabef569541f991a0a583bc344cb

  Author: Yuyang Du 
  Date:   Tue May 3 05:54:27 2016 +0800

  sched/fair: Optimize sum computation with a lookup table

And the second one attempts to optimize __update_sched_avg(), mostly resulting 
in code simplification.

These two patches have NO changes made to the names nor functions in the 
existing codes.

Would you please give it a look?

Thanks,
Yuyang

--

Yuyang Du (2):
  documentation: Add scheduler/sched-avg.txt
  sched/fair: Optimize __update_sched_avg()

 Documentation/scheduler/sched-avg.txt |  94 ++
 kernel/sched/fair.c   | 174 +-
 2 files changed, 182 insertions(+), 86 deletions(-)
 create mode 100644 Documentation/scheduler/sched-avg.txt

-- 
2.1.4

[PATCH v2 07/25] Staging: rtl8192u: r8192U_core.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/r8192U_core.c | 70 +-
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index fdb03dccb449..1fd1ee960328 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -503,8 +503,7 @@ static void watch_dog_timer_callback(unsigned long data);
 
 /
  *   -PROCFS STUFF-
-*
- */
+ /
 
 static struct proc_dir_entry *rtl8192_proc;
 
@@ -715,8 +714,8 @@ static void rtl8192_proc_remove_one(struct net_device *dev)
 }
 
 /
-   -MISC STUFF-
-*/
+ *  -MISC STUFF-
+ */
 
 short check_nic_enough_desc(struct net_device *dev, int queue_index)
 {
@@ -1328,7 +1327,7 @@ short rtl819xU_tx_cmd(struct net_device *dev, struct 
sk_buff *skb)
  * 2006.10.30 by Emily
  *
  * \param QUEUEID   Software Queue
-*/
+ */
 static u8 MapHwQueueToFirmwareQueue(u8 QueueID)
 {
u8 QueueSelect = 0x0;   /* default set to */
@@ -1499,7 +1498,7 @@ static void tx_zero_isr(struct urb *tx_urb)
  * The tx procedure is just as following,
  * skb->cb will contain all the following information,
  * priority, morefrag, rate, &dev.
- * */
+ */
 short rtl8192_tx(struct net_device *dev, struct sk_buff *skb)
 {
struct r8192_priv *priv = ieee80211_priv(dev);
@@ -1840,8 +1839,8 @@ static void rtl8192_update_beacon(struct work_struct 
*work)
 }
 
 /*
-* background support to run QoS activate functionality
-*/
+ * background support to run QoS activate functionality
+ */
 static int WDCAPARA_ADD[] = {EDCAPARA_BE, EDCAPARA_BK,
 EDCAPARA_VI, EDCAPARA_VO};
 static void rtl8192_qos_activate(struct work_struct *work)
@@ -1946,10 +1945,10 @@ static int rtl8192_handle_beacon(struct net_device *dev,
 }
 
 /*
-* handling the beaconing responses. if we get different QoS setting
-* off the network from the associated setting, adjust the QoS
-* setting
-*/
+ * handling the beaconing responses. if we get different QoS setting
+ * off the network from the associated setting, adjust the QoS
+ * setting
+ */
 static int rtl8192_qos_association_resp(struct r8192_priv *priv,
struct ieee80211_network *network)
 {
@@ -3045,8 +3044,8 @@ static bool rtl8192_adapter_start(struct net_device *dev)
  * be used to stop beacon transmission
  */
 /***
----NET STUFF---
-***/
+ *   ---NET STUFF---
+ ***/
 
 static struct net_device_stats *rtl8192_stats(struct net_device *dev)
 {
@@ -3074,9 +3073,9 @@ static bool HalTxCheckStuck819xUsb(struct net_device *dev)
 }
 
 /*
-*  
-*  First added: 2006.11.19 by emily
-*/
+ * 
+ * First added: 2006.11.19 by emily
+ */
 static RESET_TYPE TxCheckStuck(struct net_device *dev)
 {
struct r8192_priv *priv = ieee80211_priv(dev);
@@ -4156,7 +4155,8 @@ static void rtl8192_process_phyinfo(struct r8192_priv 
*priv, u8 *buffer,
  * Output: NONE
  *
  * Return: 0-100 percentage
- *---*/
+ *---
+ */
 static u8 rtl819x_query_rxpwrpercentage(s8 antpower)
 {
if ((antpower <= -100) || (antpower >= 20))
@@ -4529,19 +4529,19 @@ static void TranslateRxSignalStuff819xUsb(struct 
sk_buff *skb,
 }
 
 /**
-* Function:UpdateReceivedRateHistogramStatistics
-* Overview:Record the received data rate
-*
-* Input:
-*  struct net_device *dev
-*  struct ieee80211_rx_stats *stats
-*
-* Output:
-*
-*  (priv->stats.ReceivedRateHistogram[] is updated)
-* Return:
-*  None
-*/
+ * Function:   UpdateReceivedRateHistogramStatistics
+ * Overview:   Record the received data rate
+ *
+ * Input:
+ * struct net_device *dev
+ * struct ieee80211_rx_stats *stats
+ *
+ * Output:
+ *
+ * (priv->stats.ReceivedRateHistogram[] is updated)
+ * Return:
+ *

[PATCH v2 08/25] Staging: rtl8192u: r8192U.h - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/r8192U.h | 39 ++-
 1 file changed, 26 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 0b7b04ea0910..a7ba8f37384e 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -626,7 +626,8 @@ typedef struct Stats {
long signal_quality;
long last_signal_strength_inpercent;
/* Correct smoothed ss in dbm, only used in driver
-* to report real power now */
+* to report real power now
+*/
long recv_signal_power;
u8 rx_rssi_percentage[4];
u8 rx_evm_percentage[2];
@@ -672,32 +673,40 @@ typedef struct _BB_REGISTER_DEFINITION {
/* Tx gain stage:   0x80c~0x80f [4 bytes]  */
u32 rfTxGainStage;
/* wire parameter control1: 0x820~0x823, 0x828~0x82b,
-*  0x830~0x833, 0x838~0x83b [16 bytes] */
+*  0x830~0x833, 0x838~0x83b [16 bytes]
+*/
u32 rfHSSIPara1;
/* wire parameter control2: 0x824~0x827, 0x82c~0x82f,
-*  0x834~0x837, 0x83c~0x83f [16 bytes] */
+*  0x834~0x837, 0x83c~0x83f [16 bytes]
+*/
u32 rfHSSIPara2;
/* Tx Rx antenna control:   0x858~0x85f [16 bytes] */
u32 rfSwitchControl;
/* AGC parameter control1:  0xc50~0xc53, 0xc58~0xc5b,
-*  0xc60~0xc63, 0xc68~0xc6b [16 bytes] */
+*  0xc60~0xc63, 0xc68~0xc6b [16 bytes]
+*/
u32 rfAGCControl1;
/* AGC parameter control2:  0xc54~0xc57, 0xc5c~0xc5f,
-*  0xc64~0xc67, 0xc6c~0xc6f [16 bytes] */
+*  0xc64~0xc67, 0xc6c~0xc6f [16 bytes]
+*/
u32 rfAGCControl2;
/* OFDM Rx IQ imbalance matrix: 0xc14~0xc17, 0xc1c~0xc1f,
-*  0xc24~0xc27, 0xc2c~0xc2f [16 bytes] */
+*  0xc24~0xc27, 0xc2c~0xc2f [16 bytes]
+*/
u32 rfRxIQImbalance;
/* Rx IQ DC offset and Rx digital filter, Rx DC notch filter:
 *  0xc10~0xc13, 0xc18~0xc1b,
-*  0xc20~0xc23, 0xc28~0xc2b [16 bytes] */
+*  0xc20~0xc23, 0xc28~0xc2b [16 bytes]
+*/
u32 rfRxAFE;
/* OFDM Tx IQ imbalance matrix: 0xc80~0xc83, 0xc88~0xc8b,
-*  0xc90~0xc93, 0xc98~0xc9b [16 bytes] */
+*  0xc90~0xc93, 0xc98~0xc9b [16 bytes]
+*/
u32 rfTxIQImbalance;
/* Tx IQ DC Offset and Tx DFIR type:
 *  0xc84~0xc87, 0xc8c~0xc8f,
-*  0xc94~0xc97, 0xc9c~0xc9f [16 bytes] */
+*  0xc94~0xc97, 0xc9c~0xc9f [16 bytes]
+*/
u32 rfTxAFE;
/* LSSI RF readback data:   0x8a0~0x8af [16 bytes] */
u32 rfLSSIReadBack;
@@ -776,7 +785,8 @@ typedef struct _phy_ofdm_rx_status_report_819xusb {
 typedef struct _phy_cck_rx_status_report_819xusb {
/* For CCK rate descriptor. This is an unsigned 8:1 variable.
 * LSB bit presend 0.5. And MSB 7 bts presend a signed value.
-* Range from -64~+63.5. */
+* Range from -64~+63.5.
+*/
u8  adc_pwdb_X[4];
u8  sq_rpt;
u8  cck_agc_rpt;
@@ -991,7 +1001,8 @@ typedef struct r8192_priv {
/* Control channel sub-carrier */
u8  nCur40MhzPrimeSC;
/* Test for shorten RF configuration time.
-* We save RF reg0 in this variable to reduce RF reading. */
+* We save RF reg0 in this variable to reduce RF reading.
+*/
u32 RfReg0Value[4];
u8  NumTotalRFPath;
boolbrfpath_rxenable[4];
@@ -1009,11 +1020,13 @@ typedef struct r8192_priv {
 
boolbstore_last_dtpflag;
/* Define to discriminate on High power State or
-* on sitesurvey to change Tx gain index */
+* on sitesurvey to change Tx gain index
+*/
boolbstart_txctrl_bydtp;
rate_adaptive rate_adaptive;
/* TX power tracking
-* OPEN/CLOSE TX POWER TRACKING */
+* OPEN/CLOSE TX POWER TRACKING
+*/
txbbgain_struct txbbgain_table[TxBBGainTableLength];
u8  txpower_count; /* For 6 sec do tracking again */
boolbtxpower_trackingInit;
-- 
2.11.1

[PATCH v2 06/25] Staging: rtl8192u: r8192U_dm.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/r8192U_dm.c | 175 +++
 1 file changed, 97 insertions(+), 78 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_dm.c 
b/drivers/staging/rtl8192u/r8192U_dm.c
index 9209aad0515e..9f05280e557b 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -1,18 +1,18 @@
-/*++
-Copyright-c Realtek Semiconductor Corp. All rights reserved.
-
-Module Name:
-   r8192U_dm.c
-
-Abstract:
-   HW dynamic mechanism.
-
-Major Change History:
-   WhenWho What
-   --  --- ---
-   2008-05-14  amy create version 0 porting from 
windows code.
-
---*/
+/*
+ * Copyright-c Realtek Semiconductor Corp. All rights reserved.
+ *
+ * Module Name:
+ *  r8192U_dm.c
+ *
+ * Abstract:
+ * HW dynamic mechanism.
+ *
+ * Major Change History:
+ * WhenWho What
+ * --  --- ---
+ * 2008-05-14  amy create version 0 porting from 
windows code.
+ *
+ */
 #include "r8192U.h"
 #include "r8192U_dm.h"
 #include "r8192U_hw.h"
@@ -158,20 +158,20 @@ void dm_CheckRxAggregation(struct net_device *dev)
unsigned long   curRxOkCnt = 0;
 
 /*
-   if (pHalData->bForcedUsbRxAggr) {
-   if (pHalData->ForcedUsbRxAggrInfo == 0) {
-   if (pHalData->bCurrentRxAggrEnable) {
-   Adapter->HalFunc.HalUsbRxAggrHandler(Adapter, 
FALSE);
-   }
-   } else {
-   if (!pHalData->bCurrentRxAggrEnable || 
(pHalData->ForcedUsbRxAggrInfo != pHalData->LastUsbRxAggrInfoSetting)) {
-   Adapter->HalFunc.HalUsbRxAggrHandler(Adapter, 
TRUE);
-   }
-   }
-   return;
-   }
-
-*/
+ * if (pHalData->bForcedUsbRxAggr) {
+ * if (pHalData->ForcedUsbRxAggrInfo == 0) {
+ * if (pHalData->bCurrentRxAggrEnable) {
+ * Adapter->HalFunc.HalUsbRxAggrHandler(Adapter, 
FALSE);
+ * }
+ * } else {
+ * if (!pHalData->bCurrentRxAggrEnable || 
(pHalData->ForcedUsbRxAggrInfo != pHalData->LastUsbRxAggrInfoSetting)) {
+ * Adapter->HalFunc.HalUsbRxAggrHandler(Adapter, 
TRUE);
+ * }
+ * }
+ * return;
+ * }
+ *
+ */
curTxOkCnt = priv->stats.txbytesunicast - lastTxOkCnt;
curRxOkCnt = priv->stats.rxbytesunicast - lastRxOkCnt;
 
@@ -293,7 +293,8 @@ void init_rate_adaptive(struct net_device *dev)
  * WhenWho Remark
  * 05/26/08amy Create version 0 porting from windows code.
  *
- *---*/
+ *---
+ */
 static void dm_check_rate_adaptive(struct net_device *dev)
 {
struct r8192_priv *priv = ieee80211_priv(dev);
@@ -347,9 +348,10 @@ static void dm_check_rate_adaptive(struct net_device *dev)
((bshort_gi_enabled) ? BIT(31) : 0);
 
/* 2007/10/08 MH We support RA smooth scheme now. When it is 
the first
-  time to link with AP. We will not change upper/lower 
threshold. If
-  STA stay in high or low level, we must change two different 
threshold
-  to prevent jumping frequently. */
+* time to link with AP. We will not change upper/lower 
threshold. If
+* STA stay in high or low level, we must change two different 
threshold
+* to prevent jumping frequently.
+*/
if (pra->ratr_state == DM_RATR_STA_HIGH) {
HighRSSIThreshForRA = 
pra->high2low_rssi_thresh_for_ra;
LowRSSIThreshForRA  = (priv->CurrentChannelBW != 
HT_CHANNEL_WIDTH_20) ?
@@ -391,7 +393,8 @@ static void dm_check_rate_adaptive(struct net_device *dev)
ping_rssi_state = 1;
}
/*else
-   DbgPrint("TestRSSI is between the 
range.\n");*/
+*  DbgPrint("TestRSSI is between the 
range.\n");
+*/
} else {
/*DbgPrint("TestRSSI Recover to 0x%x\n", 
targetRATR);*/
ping_rssi_state = 0;
@@ -732,8 +735,9 @@ static void dm_TXPowerTrackingCallback_ThermalMeter(struct 
net_device *dev)
tmpCCK40Mindex = 0;
   

[PATCH v2 03/25] Staging: rtl8192u: r819xU_cmdpkt.h - style fix

[Derek Robson]

Fixed style of block comments.
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/r819xU_cmdpkt.h | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.h 
b/drivers/staging/rtl8192u/r819xU_cmdpkt.h
index f490e253ee50..ad0f6003570d 100644
--- a/drivers/staging/rtl8192u/r819xU_cmdpkt.h
+++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.h
@@ -55,7 +55,8 @@ typedef struct tag_cmd_pkt_tx_feedback {
 } cmpk_txfb_t;
 
 /* 2. RX side: Interrupt status packet. It includes Beacon State,
- * Beacon Timer Interrupt and other useful informations in MAC ISR Reg. */
+ * Beacon Timer Interrupt and other useful informations in MAC ISR Reg.
+ */
 typedef struct tag_cmd_pkt_interrupt_status {
u8  element_id; /* Command packet type. */
u8  length; /* Command packet length. */
@@ -83,13 +84,15 @@ typedef struct tag_cmd_pkt_set_configuration {
 } cmpk_set_cfg_t;
 
 /* 4. Both side : TX/RX query configuraton packet. The query structure is the
-  same as set configuration. */
+ *same as set configuration.
+ */
 #definecmpk_query_cfg_tcmpk_set_cfg_t
 
 /* 5. Multi packet feedback status. */
 typedef struct tag_tx_stats_feedback {
/* For endian transfer --> Driver will not the same as
-  firmware structure. */
+*  firmware structure.
+*/
/* DW 0 */
u16 reserve1;
u8  length; /* Command packet length */
-- 
2.11.1

[PATCH v2 05/25] Staging: rtl8192u: r8192U_hw.h - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/r8192U_hw.h | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_hw.h 
b/drivers/staging/rtl8192u/r8192U_hw.h
index e07d65d04dbc..174ccf618d3e 100644
--- a/drivers/staging/rtl8192u/r8192U_hw.h
+++ b/drivers/staging/rtl8192u/r8192U_hw.h
@@ -1,18 +1,18 @@
 /*
-   This is part of rtl8187 OpenSource driver.
-   Copyright (C) Andrea Merello 2004-2005  
-   Released under the terms of GPL (General Public Licence)
-
-   Parts of this driver are based on the GPL part of the
-   official Realtek driver.
-   Parts of this driver are based on the rtl8180 driver skeleton
-   from Patric Schenke & Andres Salomon.
-   Parts of this driver are based on the Intel Pro Wireless
-   2100 GPL driver.
-
-   We want to thank the Authors of those projects
-   and the Ndiswrapper project Authors.
-*/
+ * This is part of rtl8187 OpenSource driver.
+ * Copyright (C) Andrea Merello 2004-2005  
+ * Released under the terms of GPL (General Public Licence)
+ *
+ * Parts of this driver are based on the GPL part of the
+ * official Realtek driver.
+ * Parts of this driver are based on the rtl8180 driver skeleton
+ * from Patric Schenke & Andres Salomon.
+ * Parts of this driver are based on the Intel Pro Wireless
+ * 2100 GPL driver.
+ *
+ * We want to thank the Authors of those projects
+ * and the Ndiswrapper project Authors.
+ */
 
 /* Mariusz Matuszek added full registers definition with Realtek's name */
 
-- 
2.11.1

[PATCH v2 04/25] Staging: rtl8192u: r819xU_cmdpkt.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
Version #1 had a problem where I commented out valid code.

 drivers/staging/rtl8192u/r819xU_cmdpkt.c | 82 
 1 file changed, 52 insertions(+), 30 deletions(-)

diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.c 
b/drivers/staging/rtl8192u/r819xU_cmdpkt.c
index 1168d133522e..7db98f1fa2b8 100644
--- a/drivers/staging/rtl8192u/r819xU_cmdpkt.c
+++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.c
@@ -34,7 +34,8 @@ rt_status SendTxCommandPacket(struct net_device *dev, void 
*pData, u32 DataLen)
unsigned char   *ptr_buf;
 
/* Get TCB and local buffer from common pool.
-  (It is shared by CmdQ, MgntQ, and USB coalesce DataQ) */
+* (It is shared by CmdQ, MgntQ, and USB coalesce DataQ)
+*/
skb  = dev_alloc_skb(USB_HWDESC_HEADER_LEN + DataLen + 4);
if (!skb)
return RT_STATUS_FAILURE;
@@ -76,7 +77,8 @@ rt_status SendTxCommandPacket(struct net_device *dev, void 
*pData, u32 DataLen)
  *  When   Who Remark
  *  05/12/2008 amy Create Version 0 porting from windows code.
  *
- *---*/
+ *---
+ */
 static void cmpk_count_txstatistic(struct net_device *dev, cmpk_txfb_t 
*pstx_fb)
 {
struct r8192_priv *priv = ieee80211_priv(dev);
@@ -87,8 +89,9 @@ static void cmpk_count_txstatistic(struct net_device *dev, 
cmpk_txfb_t *pstx_fb)
  (pu1Byte)(&rtState));
 
/* When RF is off, we should not count the packet for hw/sw synchronize
-  reason, ie. there may be a duration while sw switch is changed and
-  hw switch is being changed. */
+* reason, ie. there may be a duration while sw switch is changed and
+* hw switch is being changed.
+*/
if (rtState == eRfOff)
return;
 #endif
@@ -98,8 +101,9 @@ static void cmpk_count_txstatistic(struct net_device *dev, 
cmpk_txfb_t *pstx_fb)
return;
 #endif
/* We can not know the packet length and transmit type:
-  broadcast or uni or multicast. So the relative statistics
-  must be collected in tx feedback info. */
+* broadcast or uni or multicast. So the relative statistics
+* must be collected in tx feedback info.
+*/
if (pstx_fb->tok) {
priv->stats.txfeedbackok++;
priv->stats.txoktotal++;
@@ -155,7 +159,8 @@ static void cmpk_count_txstatistic(struct net_device *dev, 
cmpk_txfb_t *pstx_fb)
  *  When   Who Remark
  *  05/08/2008 amy Create Version 0 porting from windows code.
  *
- *---*/
+ *---
+ */
 static void cmpk_handle_tx_feedback(struct net_device *dev, u8 *pmsg)
 {
struct r8192_priv *priv = ieee80211_priv(dev);
@@ -165,8 +170,9 @@ static void cmpk_handle_tx_feedback(struct net_device *dev, 
u8 *pmsg)
 
/* 1. Extract TX feedback info from RFD to temp structure buffer. */
/* It seems that FW use big endian(MIPS) and DRV use little endian in
-  windows OS. So we have to read the content byte by byte or transfer
-  endian type before copy the message copy. */
+* windows OS. So we have to read the content byte by byte or transfer
+* endian type before copy the message copy.
+*/
/* Use pointer to transfer structure memory. */
memcpy((u8 *)&rx_tx_fb, pmsg, sizeof(cmpk_txfb_t));
/* 2. Use tx feedback info to count TX statistics. */
@@ -174,7 +180,8 @@ static void cmpk_handle_tx_feedback(struct net_device *dev, 
u8 *pmsg)
/* Comment previous method for TX statistic function. */
/* Collect info TX feedback packet to fill TCB. */
/* We can not know the packet length and transmit type: broadcast or uni
-  or multicast. */
+* or multicast.
+*/
 }
 
 static void cmdpkt_beacontimerinterrupt_819xusb(struct net_device *dev)
@@ -215,7 +222,8 @@ static void cmdpkt_beacontimerinterrupt_819xusb(struct 
net_device *dev)
  *  When   Who Remark
  *  05/12/2008 amy Add this for rtl8192 porting from windows code.
  *
- *---*/
+ *---
+ */
 static void cmpk_handle_interrupt_status(struct net_device *dev, u8 *pmsg)
 {
cmpk_intr_sta_t rx_intr_status; /* */
@@ -225,8 +233,9 @@ static void cmpk_handle_interrupt_status(struct net_device 
*dev, u8 *pmsg)
 
/* 1. Extract TX feedback info from RFD to temp structure buffer. */
/* It seems th

[PATCH v2 01/25] Staging: rtl8192u: r819xU_phy.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/r819xU_phy.c | 41 +++
 1 file changed, 27 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/rtl8192u/r819xU_phy.c 
b/drivers/staging/rtl8192u/r819xU_phy.c
index 696df3440077..c99130fdb8ee 100644
--- a/drivers/staging/rtl8192u/r819xU_phy.c
+++ b/drivers/staging/rtl8192u/r819xU_phy.c
@@ -367,7 +367,8 @@ static u32 phy_FwRFSerialRead(struct net_device *dev, 
RF90_RADIO_PATH_E eRFPath,
/* Firmware RF Write control.
 * We can not execute the scheme in the initial step.
 * Otherwise, RF-R/W will waste much time.
-* This is only for site survey. */
+* This is only for site survey.
+*/
/* 1. Read operation need not insert data. bit 0-11 */
/* 2. Write RF register address. bit 12-19 */
data |= ((offset&0xFF)<<12);
@@ -380,7 +381,8 @@ static u32 phy_FwRFSerialRead(struct net_device *dev, 
RF90_RADIO_PATH_E eRFPath,
read_nic_dword(dev, QPNR, &tmp);
while (tmp & 0x8000) {
/* If FW can not finish RF-R/W for more than ?? times.
-  We must reset FW. */
+* We must reset FW.
+*/
if (time++ < 100) {
udelay(10);
read_nic_dword(dev, QPNR, &tmp);
@@ -394,7 +396,8 @@ static u32 phy_FwRFSerialRead(struct net_device *dev, 
RF90_RADIO_PATH_E eRFPath,
read_nic_dword(dev, QPNR, &tmp);
while (tmp & 0x8000) {
/* If FW can not finish RF-R/W for more than ?? times.
-  We must reset FW. */
+* We must reset FW.
+*/
if (time++ < 100) {
udelay(10);
read_nic_dword(dev, QPNR, &tmp);
@@ -426,7 +429,8 @@ static void phy_FwRFSerialWrite(struct net_device *dev,
/* Firmware RF Write control.
 * We can not execute the scheme in the initial step.
 * Otherwise, RF-R/W will waste much time.
-* This is only for site survey. */
+* This is only for site survey.
+*/
 
/* 1. Set driver write bit and 12 bit data. bit 0-11 */
/* 2. Write RF register address. bit 12-19 */
@@ -442,7 +446,8 @@ static void phy_FwRFSerialWrite(struct net_device *dev,
read_nic_dword(dev, QPNR, &tmp);
while (tmp & 0x8000) {
/* If FW can not finish RF-R/W for more than ?? times.
-  We must reset FW. */
+* We must reset FW.
+*/
if (time++ < 100) {
udelay(10);
read_nic_dword(dev, QPNR, &tmp);
@@ -451,10 +456,12 @@ static void phy_FwRFSerialWrite(struct net_device *dev,
}
}
/* 7. No matter check bit. We always force the write.
-  Because FW will not accept the command. */
+* Because FW will not accept the command.
+*/
write_nic_dword(dev, QPNR, data);
/* According to test, we must delay 20us to wait firmware
-  to finish RF write operation. */
+* to finish RF write operation.
+*/
/* We support delay in firmware side now. */
 }
 
@@ -723,7 +730,8 @@ u8 rtl8192_phy_checkBBAndRF(struct net_device *dev, 
HW90_BLOCK_E CheckBlock,
 WriteAddr[HW90_BLOCK_RF],
 bMask12Bits, WriteData[i]);
/* TODO: we should not delay for such a long time.
-  Ask SD3 */
+* Ask SD3
+*/
usleep_range(1000, 1000);
reg = rtl8192_phy_QueryRFReg(dev, eRFPath,
 WriteAddr[HW90_BLOCK_RF],
@@ -820,7 +828,8 @@ static void rtl8192_BB_Config_ParaFile(struct net_device 
*dev)
}
 
/* Check if the CCK HighPower is turned ON.
-  This is used to calculate PWDB. */
+* This is used to calculate PWDB.
+*/
priv->bCckHighPower = (u8)rtl8192_QueryBBReg(dev,
 rFPGA0_XA_HSSIParameter2,
 0x200);
@@ -839,7 +848,8 @@ void rtl8192_BBConfig(struct net_device *dev)
rtl8192_InitBBRFRegDef(dev);
/* config BB&RF. As hardCode based initialization has not been well
 * implemented, so use file first.
-* FIXME: should implement it for hardcode? */
+* FIXME: should implement it for hardcode?
+*/
rtl8192_BB_Config_ParaFile(dev);
 }
 
@@ -1158,7 +1168,8 @@ bool rtl8192_SetRFPowerState(struct net_device *dev,
switch (pHalData->eRFPowerState) {
case eRfOff:
/* If Rf off r

[RESEND PATCH 2/2] sched/fair: Optimize __update_sched_avg()

[Yuyang Du]

__update_load_avg() has the following steps:

  1. add the remainder of the last incomplete period
  2. decay old sum
  3. accumulate new sum in full periods since last_update_time
  4. accumulate the current incomplete period
  5. update averages

However, there is no need to separately compute steps 1, 3, and 4.

Illustation:

 c1  c3   c4
 ^   ^^
 |   ||
   |<->|<->|<--->|
   ... |---x---|--| ... |--|-x (now)

c1, c3, and c4 are the accumulated (meanwhile decayed) contributions
in timing in steps 1, 3, and 4 respectively.

With them, the accumulated contribution to load_sum, for example, is:

contrib = c1 * weight * freq_scaled;
contrib += c3 * weight * freq_scaled;
contrib += c4 * weight * freq_scaled;

Obviously, we can optimize the above and they equate to:

contrib = c1 + c3 + c4;
contrib *= weight * freq_scaled;

By doing so, we save instructions, and the codes are is obviously much
cleaner and simpler. One potential issue is that c1 must be additionally
decayed as opposed to doing it in step 2. However, these two approaches
should be about the same if you compare decay_load() with a round of
contrib accumulation.

Code size comparison (with allyesconfig):

Before: kernel/sched/built-in.o 1213304
After : kernel/sched/built-in.o 1212536 (-768B)

Signed-off-by: Yuyang Du 
---
 kernel/sched/fair.c | 174 ++--
 1 file changed, 88 insertions(+), 86 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3e88b35..be01d89 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2802,24 +2802,83 @@ static __always_inline u64 decay_load(u64 val, u64 n)
  * We can compute this reasonably efficiently by combining:
  *   y^PERIOD = 1/2 with precomputed \Sum 1024*y^n {for  n = LOAD_AVG_MAX_N))
+   if (unlikely(periods >= LOAD_AVG_MAX_N))
return LOAD_AVG_MAX;
 
-   /* Since n < LOAD_AVG_MAX_N, n/LOAD_AVG_PERIOD < 11 */
-   contrib = __accumulated_sum_N32[n/LOAD_AVG_PERIOD];
-   n %= LOAD_AVG_PERIOD;
-   contrib = decay_load(contrib, n);
-   return contrib + runnable_avg_yN_sum[n];
+   remainder += decay_load((u64)(1024 - period_contrib), periods);
+
+   periods -= 1;
+   if (likely(periods <= LOAD_AVG_PERIOD))
+   contrib = runnable_avg_yN_sum[periods];
+   else {
+   contrib = __accumulated_sum_N32[periods/LOAD_AVG_PERIOD];
+   periods %= LOAD_AVG_PERIOD;
+   contrib = decay_load(contrib, periods);
+   contrib += runnable_avg_yN_sum[periods];
+   }
+
+   return contrib + remainder;
 }
 
 #define cap_scale(v, s) ((v)*(s) >> SCHED_CAPACITY_SHIFT)
 
+static __always_inline u32 accumulate_sum(u64 delta, struct sched_avg *sa,
+   struct cfs_rq *cfs_rq, int cpu, unsigned long weight, int running)
+{
+   u32 contrib;
+   u64 periods;
+   unsigned long scale_freq, scale_cpu;
+
+   scale_freq = arch_scale_freq_capacity(NULL, cpu);
+   scale_cpu = arch_scale_cpu_capacity(NULL, cpu);
+
+   delta += sa->period_contrib;
+   periods = delta >> 10; /* A period is 1024us (~1ms) */
+
+   /*
+* Accumulating *_sum has two steps.
+*
+* Step 1: decay old *_sum if we crossed period boundaries.
+*/
+   if (periods) {
+   sa->load_sum = decay_load(sa->load_sum, periods);
+   if (cfs_rq) {
+   cfs_rq->runnable_load_sum =
+   decay_load(cfs_rq->runnable_load_sum, periods);
+   }
+   sa->util_sum = decay_load((u64)(sa->util_sum), periods);
+   }
+
+   /*
+* Step 2: accumulate new *_sum since last_update_time. This at most has
+* three parts (at least one part): (1) remainder of incomplete last
+* period, (2) full periods since (1), and (3) incomplete current 
period.
+*
+* Fortunately, we can (and should) do all these three at once.
+*/
+   delta %= 1024;
+   contrib = __accumulate_sum(periods, sa->period_contrib, delta);
+   sa->period_contrib = delta;
+
+   contrib = cap_scale(contrib, scale_freq);
+   if (weight) {
+   sa->load_sum += weight * contrib;
+   if (cfs_rq)
+   cfs_rq->runnable_load_sum += weight * contrib;
+   }
+   if (running)
+   sa->util_sum += contrib * scale_cpu;
+
+   return periods;
+}
+
 /*
  * We can represent the historical contribution to runnable average as the
  * coefficients of a geometric series.  To do this we sub-divide our runnable
@@ -2852,10 +2911,7 @@ static __always_inline int
 __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
  unsigned long weight, int running, struct cfs_rq *cfs_rq)
 {
-   u64 delta, scaled_delta, periods;
-   u32 contrib;
-

[RESEND PATCH 1/2] documentation: Add scheduler/sched-avg.txt

[Yuyang Du]

This doc file has the program to generate the constants to compute
sched averages.

Signed-off-by: Yuyang Du 
---
 Documentation/scheduler/sched-avg.txt | 94 +++
 1 file changed, 94 insertions(+)
 create mode 100644 Documentation/scheduler/sched-avg.txt

diff --git a/Documentation/scheduler/sched-avg.txt 
b/Documentation/scheduler/sched-avg.txt
new file mode 100644
index 000..e1b3c542
--- /dev/null
+++ b/Documentation/scheduler/sched-avg.txt
@@ -0,0 +1,94 @@
+The following program is used to generate the constants for
+computing sched averages.
+
+==
+   C program (compile with -lm)
+==
+
+#include 
+#include 
+
+#define HALFLIFE 32
+#define SHIFT 32
+
+double y;
+
+void calc_runnable_avg_yN_inv() {
+   int i;
+   unsigned int x;
+
+   printf("static const u32 runnable_avg_yN_inv[] = {");
+   for(i = 0; i < HALFLIFE; i++) {
+   x = ((1UL<<32)-1)*pow(y, i);
+
+   if (i % 6 == 0) printf("\n\t");
+   printf("0x%8x, ", x);
+   }
+   printf("\n};\n\n");
+}
+
+int sum = 1024;
+void calc_runnable_avg_yN_sum() {
+   int i;
+
+   printf("static const u32 runnable_avg_yN_sum[] = {\n\t0,");
+   for(i = 1; i <= HALFLIFE; i++) {
+   if (i == 1)
+   sum *= y;
+   else
+   sum = sum*y + 1024*y;
+
+   if (i % 11 == 0) printf("\n\t");
+   printf("%5d,", sum);
+   }
+   printf("\n};\n\n");
+}
+
+int n = -1;
+/* first period */
+long max = 1024;
+
+void calc_converged_max() {
+   long last = 0, y_inv = ((1UL<<32)-1)*y;
+
+   for (; ; n++) {
+   if (n > -1)
+   max = ((max*y_inv)>>SHIFT) + 1024;
+   /*
+* This is the same as:
+* max = max*y + 1024;
+*/
+
+   if (last == max)
+   break;
+
+   last = max;
+   }
+   n--;
+   printf("#define LOAD_AVG_PERIOD %d\n", HALFLIFE);
+   printf("#define LOAD_AVG_MAX %ld\n", max);
+   printf("#define LOAD_AVG_MAX_N %d\n\n", n);
+}
+
+void calc_accumulated_sum_32() {
+   int i, x = sum;
+
+   printf("static const u32 __accumulated_sum_N32[] = {\n\t 0,");
+   for(i = 1; i <= n/HALFLIFE+1; i++) {
+   if (i > 1)
+   x = x/2 + sum;
+
+   if (i % 6 == 0) printf("\n\t");
+   printf("%6d,", x);
+   }
+   printf("\n};\n\n");
+}
+
+void main() {
+   y = pow(0.5, 1/(double)HALFLIFE);
+
+   calc_runnable_avg_yN_inv();
+   calc_runnable_avg_yN_sum();
+   calc_converged_max();
+   calc_accumulated_sum_32();
+}
-- 
2.1.4

[PATCH v2 02/25] Staging: rtl8192u: r819xU_firmware.c - style fix

[Derek Robson]

Fixed style of block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/rtl8192u/r819xU_firmware.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8192u/r819xU_firmware.c 
b/drivers/staging/rtl8192u/r819xU_firmware.c
index 08302dfb0d90..38b17f8d921a 100644
--- a/drivers/staging/rtl8192u/r819xU_firmware.c
+++ b/drivers/staging/rtl8192u/r819xU_firmware.c
@@ -10,7 +10,7 @@
  * Returns:
  *NDIS_STATUS_FAILURE - the following initialization process should be 
terminated
  *NDIS_STATUS_SUCCESS - if firmware initialization process success
-**/
+ 
**/
 
 #include "r8192U.h"
 #include "r8192U_hw.h"
@@ -62,7 +62,7 @@ static bool fw_download_code(struct net_device *dev, u8 
*code_virtual_address,
 
/* Allocate skb buffer to contain firmware info and tx 
descriptor info
 * add 4 to avoid packet appending overflow.
-* */
+*/
skb  = dev_alloc_skb(USB_HWDESC_HEADER_LEN + frag_length + 4);
if (!skb)
return false;
@@ -277,7 +277,7 @@ bool init_firmware(struct net_device *dev)
 * 2. each packet segment will be put in the skb_buff packet.
 * 3. each skb_buff packet data content will already include 
the firmware info
 *   and Tx descriptor info
-* */
+*/
rt_status = fw_download_code(dev, mapped_file, file_length);
if (rst_opt == OPT_SYSTEM_RESET)
release_firmware(fw_entry);
-- 
2.11.1

[PATCH v2 00/25] Staging: rtl8192u - fixed block comments

[Derek Robson]

Fixed style of block comments across all of the rtl8192u driver
This driver has a lot of code commented out that could be deleted, I have not 
changed that.

Version #1  had a bug in 04/25 where I commented out valid code.


Derek Robson (25):
  Staging: rtl8192u: r819xU_phy.c - style fix
  Staging: rtl8192u: r819xU_firmware.c - style fix
  Staging: rtl8192u: r819xU_cmdpkt.h - style fix
  Staging: rtl8192u: r819xU_cmdpkt.c - style fix
  Staging: rtl8192u: r8192U_hw.h - style fix
  Staging: rtl8192u: r8192U_dm.c - style fix
  Staging: rtl8192u: r8192U_core.c - style fix
  Staging: rtl8192u: r8192U.h - style fix
  Staging: rtl8192u: r8190_rtl8256.h - style fix
  Staging: rtl8192u: r8190_rtl8256.c - style fix
  Staging: rtl8192u: r8180_93cx6.c - style fix
  Staging: rtl8192u: ieee80211: ieee80211_crypt_wep.c - style fix
  Staging: rtl8192u: ieee80211: rtl819x_TSProc.c - style fix
  Staging: rtl8192u: ieee80211: ieee80211_softmac.c - style fix
  Staging: rtl8192u: ieee80211: ieee80211_module.c - style fix
  Staging: rtl8192u: ieee80211: rtl819x_HTProc.c - style fix
  Staging: rtl8192u: ieee80211: rtl819x_BAProc.c - style fix
  Staging: rtl8192u: ieee80211: rtl819x_HT.h - style fix
  Staging: rtl8192u: ieee80211: rtl819x_BA.h - style fix
  Staging: rtl8192u: ieee80211: ieee80211_wx.c - style fix
  Staging: rtl8192u: ieee80211: ieee80211_tx.c - style fix
  Staging: rtl8192u: ieee80211: ieee80211_rx.c - style fix
  Staging: rtl8192u: ieee80211: ieee80211_crypt.h - style fix
  Staging: rtl8192u: ieee80211: ieee80211_crypt.c - style fix
  Staging: rtl8192u: ieee80211: ieee80211.h - style fix

 drivers/staging/rtl8192u/ieee80211/ieee80211.h |  61 +++--
 .../staging/rtl8192u/ieee80211/ieee80211_crypt.c   |   3 +-
 .../staging/rtl8192u/ieee80211/ieee80211_crypt.h   |  12 +-
 .../rtl8192u/ieee80211/ieee80211_crypt_wep.c   |   3 +-
 .../staging/rtl8192u/ieee80211/ieee80211_module.c  |  60 ++---
 drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c  |  91 ---
 .../staging/rtl8192u/ieee80211/ieee80211_softmac.c |  71 ++---
 drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c  | 290 +++--
 drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c  |  87 ---
 drivers/staging/rtl8192u/ieee80211/rtl819x_BA.h|  12 +-
 .../staging/rtl8192u/ieee80211/rtl819x_BAProc.c|  28 +-
 drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h|  69 ++---
 .../staging/rtl8192u/ieee80211/rtl819x_HTProc.c| 164 ++--
 .../staging/rtl8192u/ieee80211/rtl819x_TSProc.c|   4 +-
 drivers/staging/rtl8192u/r8180_93cx6.c |  36 +--
 drivers/staging/rtl8192u/r8190_rtl8256.c   |  16 +-
 drivers/staging/rtl8192u/r8190_rtl8256.h   |  20 +-
 drivers/staging/rtl8192u/r8192U.h  |  39 ++-
 drivers/staging/rtl8192u/r8192U_core.c |  70 ++---
 drivers/staging/rtl8192u/r8192U_dm.c   | 175 +++--
 drivers/staging/rtl8192u/r8192U_hw.h   |  28 +-
 drivers/staging/rtl8192u/r819xU_cmdpkt.c   |  82 +++---
 drivers/staging/rtl8192u/r819xU_cmdpkt.h   |   9 +-
 drivers/staging/rtl8192u/r819xU_firmware.c |   6 +-
 drivers/staging/rtl8192u/r819xU_phy.c  |  41 ++-
 25 files changed, 804 insertions(+), 673 deletions(-)

-- 
2.11.1

Re: [PATCH] llist: Don't reinvent the wheel but use existing llist API

[Huang, Ying]

Hi, Byungchul,

Byungchul Park  writes:

> Although llist provides proper APIs, they are not used. Make them used.
>
> Signed-off-by: Byungchul Park 
> ---
>  drivers/md/bcache/closure.c | 15 ++-
>  drivers/md/raid5.c  |  4 +---
>  drivers/vhost/scsi.c|  9 ++---
>  fs/file_table.c | 12 +---
>  fs/namespace.c  | 12 +---
>  include/linux/llist.h   |  3 +++
>  kernel/irq_work.c   |  6 +-
>  kernel/sched/core.c | 13 ++---
>  mm/vmalloc.c|  8 +++-

I think you need to split the patch.  One for each subsystem, this makes
it easier to be reviewed and merged.

Best Regards,
Huang, Ying

[snip]

Re: [PATCH 10/11] [media] v4l2: Add v4l2 control IDs for HEVC encoder

[Smitha T Murthy]

On Mon, 2017-02-06 at 15:54 +0100, Andrzej Hajda wrote:
> Hi Smitha,
> 
> I have no big experience with HEVC, so it is hard to review it
> appropriately but I will try do my best.
> As these control names goes to user space you should be very careful
> about it.
> I guess it could be good to compare these controls with other HEVC
> encoders including software ones (ffmpeg, intel, ...) to find some
> similarities, common naming convention.
> 
Thank you so much for the review :)
I will compare it with the software HEVC encoders for the naming
convention. Basically I was following the convention used for other
codecs in the same file.
> 
> On 18.01.2017 11:02, Smitha T Murthy wrote:
> > Add v4l2 controls for HEVC encoder
> >
> > CC: Hans Verkuil 
> > CC: Wu-Cheng Li 
> > CC: Kieran Bingham 
> > CC: Vladimir Zapolskiy 
> > CC: Laurent Pinchart 
> > Signed-off-by: Smitha T Murthy 
> > ---
> >  drivers/media/v4l2-core/v4l2-ctrls.c |   51 
> >  include/uapi/linux/v4l2-controls.h   |  109 
> > ++
> >  2 files changed, 160 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> > b/drivers/media/v4l2-core/v4l2-ctrls.c
> > index 47001e2..387439d 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> > @@ -775,6 +775,57 @@ static bool is_new_manual(const struct v4l2_ctrl 
> > *master)
> > case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:return "VPX 
> > P-Frame QP Value";
> > case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:   return "VPX 
> > Profile";
> >  
> > +   /* HEVC controls */
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP:   return "HEVC 
> > Frame QP value";
> 
> Should be "HEVC I-Frame", it looks like the convention is to upper-case
> first letter of all words,
> and the convention is I-Frame, B-Frame, P-Frame, here and in the next
> controls.
> I would drop also the word "value", but it is already used in other
> controls so I do not know :)
> 
The I,P,B frame naming convention for other codecs is like
"V4L2_CID_MPEG_VIDEO_H263_I_FRAME_QP" and
"V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP"
so I followed the same for HEVC codec too.

Yes they use the word "value" for other codecs too.

> > +   case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP:   return "HEVC P 
> > frame QP value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP:   return "HEVC B 
> > frame QP value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP:   return "HEVC 
> > Minimum QP value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP:   return "HEVC 
> > Maximum QP value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_DARK: return "HEVC 
> > dark region adaptive";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_SMOOTH:   return "HEVC 
> > smooth region adaptive";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_STATIC:   return "HEVC 
> > static region adaptive";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_ACTIVITY: return "HEVC 
> > activity adaptive";
> 
> Shouldn't it be "... Region Adaptive RC", or "... Region Adaptive Rate
> Control" ?
> 
I will correct it to Region Adaptive Rate Control.

> > +   case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:  return "HEVC 
> > Profile";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:return "HEVC 
> > level";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_TIER_FLAG:return "HEVC 
> > tier_flag default is Main";
> 
> I guess 0 - means main tier, 1 means high tier, am I right? In such case
> it should be named "HEVC high tier" or sth similar.
> 
Yes 0 is for Main tier and 1 is for High tier. Since the flag by default
is main tier and it can be used for both the tiers I just kept the name
as "TIER_FLAG"

> > +   case V4L2_CID_MPEG_VIDEO_HEVC_RC_FRAME_RATE:return "HEVC 
> > Frame rate";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_MAX_PARTITION_DEPTH:  return "HEVC 
> > Maximum coding unit depth";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_REF_NUMBER_FOR_PFRAMES:   return "HEVC 
> > Number of reference picture";
> 
> What is purpose of this control? Macro name suggest sth different than
> string.
> 
Sorry the description should have been "Number of reference frames for
P-Frame". P-frame can use 1 or 2 frames for reference.

> > +   case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE: return "HEVC 
> > refresh type";
> 
> Could you enumerate these refresh types, in patch 9 and documentation,
> maybe it would be worth to make it menu.
> 
There are 3 refresh types : None, CRA, IDR. I will add more details in
the Documentation patch and in the menu on this.

> > +   case V4L2_CID_MPEG_VIDEO_HEVC_CONST_INTRA_PRED_ENABLE:  return "HEVC 
> > constant intra prediction enabled";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_LOSSLESS_CU_ENABLE:   return "HEVC 
> > lossless encoding select";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_WAVEFRONT_ENABLE:   

Re: [lkp] [x86/acpi] dc6db24d24: BUG: unable to handle kernel paging request at 0000116007090008

[Dou Liyang]

Hi, Xiaolong

At 02/13/2017 09:37 AM, Ye Xiaolong wrote:

On 11/21, Dou Liyang wrote:

Hi, Xiaolong,

At 11/21/2016 09:31 AM, Ye Xiaolong wrote:

On 11/18, Dou Liyang wrote:

Hi xiaolong

At 11/18/2016 02:16 PM, Ye Xiaolong wrote:

Hi, liyang

Sorry for the late.

On 10/31, Dou Liyang wrote:

Hi, Xiaolong,

I research the ACPI table for a long time, and I found that:
The reason for this bug is the duplicate IDs "0xFF" in DSDT.
it has already been fixed in the committed id
8e089eaa1999def4bb954caa91941f29b0672b6a and
fd74da217df7d4bd25e95411da64e0b92762842e which is after the
dc6db24d2476cd09c0ecf2b8d80313539f737a89 .

could you help me to Verify my thoughts in the LKP.



I've queued the same test jobs for commit fd74da217d, I'll notify you
once I get the results.




Hi, Liyang,

Results show that the reported error is gone with commit 
fd74da217df7d4bd25e95411da64e0b92762842e
below is the comparison.



thanks a lot. that means it has been fixed.


Sorry for my neglect, the result for fd74da217df7d4bd25e95411da showed no dmesg
because it's incomplete run and has no demsg stat at all.


Is that means:

you have already tested the Linux branch which contains the commit
fd74da217df7d. and it doesn't work well.

Btw, Why the test is incomplete run ?


The bug still persists in v4.9, v4.10-rcx, the lastest kernel head,


If the dmesg and stat of the test is NULL, How do you prove that the
bug still exists?


could you help to check?



Yes, I think we first should make the test with commit fd74da217df7d
work in the specific test machine.

test machine: 72 threads Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz with 
128G memory


Am I right? waiting your response.

Thanks,
Liyang


Thanks,
Xiaolong





compare -at dc6db24d2476cd09c0ecf2b8d80313539f737a89 
fd74da217df7d4bd25e95411da64e0b92762842e
tests: 1
testcase/path_params/tbox_group/run: 
vm-scalability/300-never-never-1-1-swap-w-rand-performance/lkp-hsw-ep2

dc6db24d2476cd09  fd74da217df7d4bd25e95411da
  --
  fail:runs  %reproductionfail:runs
  | | |
12:12-100%:3 dmesg.BUG:unable_to_handle_kernel
12:12-100%:3 dmesg.Oops
12:12-100%:3 dmesg.RIP:get_partial_node
 9:12 -75%:3 dmesg.RIP:_raw_spin_lock_irqsave
 3:12 -25%:3 
dmesg.general_protection_fault:#[##]SMP
 3:12 -25%:3 
dmesg.RIP:native_queued_spin_lock_slowpath
 3:12 -25%:3 
dmesg.Kernel_panic-not_syncing:Hard_LOCKUP
 2:12 -17%:3 dmesg.RIP:load_balance
 2:12 -17%:3 
dmesg.Kernel_panic-not_syncing:Fatal_exception_in_interrupt
 1:12  -8%:3 dmesg.RIP:resched_curr
 1:12  -8%:3 
dmesg.Kernel_panic-not_syncing:Fatal_exception
 5:12 -42%:3 
dmesg.WARNING:at_include/linux/uaccess.h:#__probe_kernel_read
 1:12  -8%:3 
dmesg.WARNING:at_lib/list_debug.c:#__list_add





2. About the LKP-tests, I want run the tests in my own pc.
I use the debain sid as an OS. the .yaml file can be installed and
job splited, but it can't be run correctly.

Is the linux source code must be in /tmp/?
And if I need to modify the .yaml file to fit my pc.



Could you paste the error log for me to analyze?


Yes.  let me tidy up it ah. :)



And, I am very interesting in LKP-Test. when I built it, I met some
problems.

here is the error log:

root@debian:/home/douly/lkp-tests# lkp run 
./job-unlink2-performance-04c197c080f2ed7a022f79701455c6837f4b9573-debian-x86_64-2016-08-31.cgz.yaml

IPMI BMC is not supported on this machine, skip bmc-watchdog setup!
2016-11-21 15:21:01 ./runtest.py unlink2 32 both 1 54 72
/home/douly/lkp-tests/bin/log_cmd: 7: exec: ./runtest.py: not found
kill 18805 vmstat -n 10
kill 18803 dmesg --follow --decode
kill 18829 /lkp/benchmarks/perf-stat/perf stat -a -I 1000 -x  -e 
cpu-clock,task-clock,page-faults,context-switches,cpu-migrations,minor-faults,major-faults
--log-fd 1 --
kill 18806 vmstat -n 1
wait for background monitors: 18811 18813 18830 18833 18832 18819
18821 18826 18818 18815 18810 18814 18825 18827 proc-stat meminfo
oom-killer uptime nfs-hang softirqs diskstats sched_debug
latency_stats interrupts proc-vmstat slabinfo turbostat perf-profile
Error:
The /tmp/lkp-root/perf.data file has no samples!

Thanks,

Dou.

Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode

[Mike Galbraith]

On Sun, 2017-02-12 at 13:16 -0800, Paul Turner wrote:
> 
> 
> On Thursday, February 9, 2017, Peter Zijlstra  wrote:
> > On Thu, Feb 09, 2017 at 05:07:16AM -0800, Paul Turner wrote:
> > > The only case that this does not support vs ".threads" would be some
> > > hybrid where we co-mingle threads from different processes (with the
> > > processes belonging to the same node in the hierarchy).  I'm not aware
> > > of any usage that looks like this.
> > 
> > If I understand you right; this is a fairly common thing with RT where
> > we would stuff all the !rt threads of the various processes in a 'misc'
> > bucket.
> > 
> > Similarly, it happens that we stuff the various rt threads of processes
> > in a specific (shared) 'rt' bucket.
> > 
> > So I would certainly not like to exclude that setup.
> > 
> 
> Unless you're using rt groups I'm not sure this one really changes.  
> Whether the "misc" threads exist at the parent level or one below
> should not matter.

(with exclusive cpusets, a mask can exist at one and only one location)

Re: [PATCH v2] arm64: use is_vmalloc_addr

[Andreas Färber]

Hi,

Am 09.02.2017 um 12:45 schrieb Miles Chen:
> To is_vmalloc_addr() to check if an address is a vmalloc address

"Use ..."?

Regards,
Andreas

> instead of checking VMALLOC_START and VMALLOC_END manually.
> 
> Signed-off-by: Miles Chen 

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[PATCH] powerpc/xmon: add turn off xmon option

[Pan Xinhui]

Once xmon is triggered, there is no interface to turn it off again.
However there exists disable/enable xmon code flows. And more important,
System reset interrupt on powerVM will fire an oops to make a dump. At
that time, xmon should not be triggered.

So add 'z' option after current 'x|X' exit commands. Turn xmon off if 'z'
is following.

Signed-off-by: Pan Xinhui 
---
 arch/powerpc/xmon/xmon.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 9c0e17c..2f4e7b1 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -76,6 +76,7 @@ static int xmon_gate;
 #endif /* CONFIG_SMP */
 
 static unsigned long in_xmon __read_mostly = 0;
+static int xmon_off = 0;
 
 static unsigned long adrs;
 static int size = 1;
@@ -255,8 +256,8 @@ Commands:\n\
   Sr # read SPR #\n\
   Sw #v write v to SPR #\n\
   tprint backtrace\n\
-  xexit monitor and recover\n\
-  Xexit monitor and don't recover\n"
+  x[z] exit monitor and recover, turn off xmon with 'z'\n\
+  X[z] exit monitor and don't recover, turn off xmon with 'z'\n"
 #if defined(CONFIG_PPC64) && !defined(CONFIG_PPC_BOOK3E)
 "  u   dump segment table or SLB\n"
 #elif defined(CONFIG_PPC_STD_MMU_32)
@@ -952,6 +953,8 @@ cmds(struct pt_regs *excp)
break;
case 'x':
case 'X':
+   if (inchar() == 'z')
+   xmon_off = 1;
return cmd;
case EOF:
printf(" \n");
@@ -3248,8 +3251,11 @@ static void xmon_init(int enable)
 static void sysrq_handle_xmon(int key)
 {
/* ensure xmon is enabled */
+   xmon_off = 0;
xmon_init(1);
debugger(get_irq_regs());
+   if (xmon_off)
+   xmon_init(0);
 }
 
 static struct sysrq_key_op sysrq_xmon_op = {
@@ -3266,7 +3272,7 @@ static int __init setup_xmon_sysrq(void)
 __initcall(setup_xmon_sysrq);
 #endif /* CONFIG_MAGIC_SYSRQ */
 
-static int __initdata xmon_early, xmon_off;
+static int __initdata xmon_early;
 
 static int __init early_parse_xmon(char *p)
 {
-- 
2.4.11

Re: [PATCH] llist: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

On Mon, Feb 13, 2017 at 03:56:08PM +1100, NeilBrown wrote:
> On Mon, Feb 13 2017, Byungchul Park wrote:
> 
> > Although llist provides proper APIs, they are not used. Make them used.
> >
> > Signed-off-by: Byungchul Park 
> > ---
> >  drivers/md/bcache/closure.c | 15 ++-
> >  drivers/md/raid5.c  |  4 +---
> >  drivers/vhost/scsi.c|  9 ++---
> >  fs/file_table.c | 12 +---
> >  fs/namespace.c  | 12 +---
> >  include/linux/llist.h   |  3 +++
> >  kernel/irq_work.c   |  6 +-
> >  kernel/sched/core.c | 13 ++---
> >  mm/vmalloc.c|  8 +++-
> >  9 files changed, 24 insertions(+), 58 deletions(-)
> >
> ...
> 
> > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> > index 36c13e4..c82243a 100644
> > --- a/drivers/md/raid5.c
> > +++ b/drivers/md/raid5.c
> > @@ -359,11 +359,9 @@ static int release_stripe_list(struct r5conf *conf,
> >  
> > head = llist_del_all(&conf->released_stripes);
> > head = llist_reverse_order(head);
> > -   while (head) {
> > +   llist_for_each_entry(sh, head, release_list) {
> > int hash;
> >  
> > -   sh = llist_entry(head, struct stripe_head, release_list);
> > -   head = llist_next(head);
> > /* sh could be readded after STRIPE_ON_RELEASE_LIST is cleard */
> > smp_mb();
> > clear_bit(STRIPE_ON_RELEASE_LIST, &sh->state);
> 
> This one is wrong (I haven't checked the rest).
> As soon a STRIPE_ON_RELEASE_LIST is cleared, the llist_node can be
> reused, so we need to call llist_next *before* the rest of the code.
> You have moved the call to afterwards.
> 
> You could possibly change it to use llist_for_each_entry_safe()

Yes right. I also found that I should have used the safe version. :(

Thank you very much.

> 
> NeilBrown

Re: ANNOUNCE: mdadm 4.0 - A tool for managing md Soft RAID under Linux

[zhilong]

Hi, Jes;


On 01/13/2017 12:41 AM, Jes Sorensen wrote:

On 01/11/17 23:24, Guoqing Jiang wrote:


On 01/12/2017 12:59 AM, Jes Sorensen wrote:

On 01/11/17 11:52, Shaohua Li wrote:

On Tue, Jan 10, 2017 at 11:49:04AM -0600, Bruce Dubbs wrote:

Jes Sorensen wrote:

I am pleased to announce the availability of
  mdadm version 4.0

It is available at the usual places:
  http://www.kernel.org/pub/linux/utils/raid/mdadm/
and via git at
  git://git.kernel.org/pub/scm/utils/mdadm/mdadm.git
  http://git.kernel.org/cgit/utils/mdadm/

The update in major version number primarily indicates this is a
release by it's new maintainer. In addition it contains a large number
of fixes in particular for IMSM RAID and clustered RAID support.  In
addition this release includes support for IMSM 4k sector drives,
failfast and better documentation for journaled RAID.

Thank you for the new release.  Unfortunately I get 9 failures
running the
test suite:

tests/00raid1...  FAILED
tests/07autoassemble...   FAILED
tests/07changelevels...   FAILED
tests/07revert-grow...FAILED
tests/07revert-inplace... FAILED
tests/07testreshape5...   FAILED
tests/10ddf-fail-twice... FAILED
tests/20raid5journal...   FAILED
tests/10ddf-incremental-wrong-order...  FAILED

Yep, several tests usually fail. It appears some checks aren't always
good.  At
least the 'check' function for reshape/resync isn't reliable in my
test, I saw
07changelevelintr fails frequently.

That is my experience as well - some of them are affected by the kernel
version too. We probably need to look into making them more reliable.

If possible, it could be a potential topic for lsf/mm raid discussion as
Coly suggested
in previous mail.

Is current test can run the test for different raid level, say, "./test
--raidtype=raid1" could
execute all the *r1* tests, does it make sense to do it if we don't
support it now.

We could have a discussion about this at LSF/MM, if someone is willing
to sponsor getting it accepted and we can get the right people there.

Note that the test suite also allows you to run all the 01 tests by
specifying ./test 01. I do like to see the test suite improved and made
more resilient.
I'm sorry for my late response, I'm just back to work today from 
vacation. In the past months, I learned and worked for cluster-md feature,
and I have draft one test suit for cluster-md feature. please refer to 
https://github.com/zhilongliu/clustermd-autotest
I'm very willing to do something for improving mdadm testing part, also 
wanna improve cluster-md test suit, welcome all comments for it.



Cheers,
Jes

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



Thanks very much,
-Zhilong

Re: [PATCH V2 3/7] mm: reclaim MADV_FREE pages

[Minchan Kim]

On Fri, Feb 10, 2017 at 09:43:07AM -0800, Shaohua Li wrote:

< snip >

> > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > index 947ab6f..b304a84 100644
> > > --- a/mm/vmscan.c
> > > +++ b/mm/vmscan.c
> > > @@ -864,7 +864,7 @@ static enum page_references 
> > > page_check_references(struct page *page,
> > >   return PAGEREF_RECLAIM;
> > >  
> > >   if (referenced_ptes) {
> > > - if (PageSwapBacked(page))
> > > + if (PageSwapBacked(page) || PageAnon(page))
> > 
> > If anyone accesses MADV_FREEed range with load op, not store,
> > why shouldn't we discard that pages?
> 
> Don't have strong opinion about this, userspace probably shouldn't do this. 
> I'm
> ok to delete it if you insist.

Yes, I prefer to removing unnecessary code unless there is a some reaason.

> 
> > >   return PAGEREF_ACTIVATE;
> > >   /*
> > >* All mapped pages start out with page table

< snip >

> > > @@ -971,7 +971,7 @@ static unsigned long shrink_page_list(struct 
> > > list_head *page_list,
> > >   int may_enter_fs;
> > >   enum page_references references = PAGEREF_RECLAIM_CLEAN;
> > >   bool dirty, writeback;
> > > - bool lazyfree = false;
> > > + bool lazyfree;
> > >   int ret = SWAP_SUCCESS;
> > >  
> > >   cond_resched();
> > > @@ -986,6 +986,8 @@ static unsigned long shrink_page_list(struct 
> > > list_head *page_list,
> > >  
> > >   sc->nr_scanned++;
> > >  
> > > + lazyfree = page_is_lazyfree(page);
> > > +
> > >   if (unlikely(!page_evictable(page)))
> > >   goto cull_mlocked;
> > >  
> > > @@ -993,7 +995,7 @@ static unsigned long shrink_page_list(struct 
> > > list_head *page_list,
> > >   goto keep_locked;
> > >  
> > >   /* Double the slab pressure for mapped and swapcache pages */
> > > - if (page_mapped(page) || PageSwapCache(page))
> > > + if ((page_mapped(page) || PageSwapCache(page)) && !lazyfree)
> > >   sc->nr_scanned++;
> > 
> > In this phase, we cannot know whether lazyfree marked page is discarable
> > or not. If it is freeable and mapped, this logic makes sense. However,
> > if the page is dirty?
> 
> I think this doesn't matter. If the page is dirty, it will go to reclaim in
> next round and swap out. At that time, we will add nr_scanned there.

If the lazyfree page in LRU comes around again into this, it's true but
the page could be freed before that.
Having said that, I don't know how critical it is and what kinds of rationale
was to push slab reclaim so I don't insist on it.

Thanks.

Re: [PATCH RFC] ptr_ring: fix race conditions when resizing

[Jason Wang]

On 2017年02月11日 06:31, Michael S. Tsirkin wrote:

Resizing currently drops consumer lock.  This can cause entries to be
reordered, which isn't good in itself.  More importantly, consumer can
detect a false ring empty condition and block forever.

Further, nesting of consumer within producer lock is problematic for
tun, since it produces entries in an interrupt, which causes a


In an bh actually?

Except for this.

Acked-by: Jason Wang 


lock order reversal:

CPU0CPU1

   consume:
   lock(&(&r->consumer_lock)->rlock);
resize:
local_irq_disable();
lock(&(&r->producer_lock)->rlock);
lock(&(&r->consumer_lock)->rlock);
   
   produce:
   lock(&(&r->producer_lock)->rlock);

To fix, nest producer lock within consumer lock during resize,
and keep consumer lock during the whole swap operation.

Reported-by: Dmitry Vyukov 
Cc: sta...@vger.kernel.org
Cc: "David S. Miller" 
Cc: Jason Wang 
Signed-off-by: Michael S. Tsirkin 
---
  include/linux/ptr_ring.h | 36 +++-
  1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index 2052011..6c70444 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -111,6 +111,11 @@ static inline int __ptr_ring_produce(struct ptr_ring *r, 
void *ptr)
return 0;
  }
  
+/*

+ * Note: resize (below) nests producer lock within consumer lock, so if you
+ * consume in interrupt or BH context, you must disable interrupts/BH when
+ * calling this.
+ */
  static inline int ptr_ring_produce(struct ptr_ring *r, void *ptr)
  {
int ret;
@@ -242,6 +247,11 @@ static inline void *__ptr_ring_consume(struct ptr_ring *r)
return ptr;
  }
  
+/*

+ * Note: resize (below) nests producer lock within consumer lock, so if you
+ * call this in interrupt or BH context, you must disable interrupts/BH when
+ * producing.
+ */
  static inline void *ptr_ring_consume(struct ptr_ring *r)
  {
void *ptr;
@@ -357,7 +367,7 @@ static inline void **__ptr_ring_swap_queue(struct ptr_ring 
*r, void **queue,
void **old;
void *ptr;
  
-	while ((ptr = ptr_ring_consume(r)))

+   while ((ptr = __ptr_ring_consume(r)))
if (producer < size)
queue[producer++] = ptr;
else if (destroy)
@@ -372,6 +382,12 @@ static inline void **__ptr_ring_swap_queue(struct ptr_ring 
*r, void **queue,
return old;
  }
  
+/*

+ * Note: producer lock is nested within consumer lock, so if you
+ * resize you must make sure all uses nest correctly.
+ * In particular if you consume ring in interrupt or BH context, you must
+ * disable interrupts/BH when doing so.
+ */
  static inline int ptr_ring_resize(struct ptr_ring *r, int size, gfp_t gfp,
  void (*destroy)(void *))
  {
@@ -382,17 +398,25 @@ static inline int ptr_ring_resize(struct ptr_ring *r, int 
size, gfp_t gfp,
if (!queue)
return -ENOMEM;
  
-	spin_lock_irqsave(&(r)->producer_lock, flags);

+   spin_lock_irqsave(&(r)->consumer_lock, flags);
+   spin_lock(&(r)->producer_lock);
  
  	old = __ptr_ring_swap_queue(r, queue, size, gfp, destroy);
  
-	spin_unlock_irqrestore(&(r)->producer_lock, flags);

+   spin_unlock(&(r)->producer_lock);
+   spin_unlock_irqrestore(&(r)->consumer_lock, flags);
  
  	kfree(old);
  
  	return 0;

  }
  
+/*

+ * Note: producer lock is nested within consumer lock, so if you
+ * resize you must make sure all uses nest correctly.
+ * In particular if you consume ring in interrupt or BH context, you must
+ * disable interrupts/BH when doing so.
+ */
  static inline int ptr_ring_resize_multiple(struct ptr_ring **rings, int 
nrings,
   int size,
   gfp_t gfp, void (*destroy)(void *))
@@ -412,10 +436,12 @@ static inline int ptr_ring_resize_multiple(struct 
ptr_ring **rings, int nrings,
}
  
  	for (i = 0; i < nrings; ++i) {

-   spin_lock_irqsave(&(rings[i])->producer_lock, flags);
+   spin_lock_irqsave(&(rings[i])->consumer_lock, flags);
+   spin_lock(&(rings[i])->producer_lock);
queues[i] = __ptr_ring_swap_queue(rings[i], queues[i],
  size, gfp, destroy);
-   spin_unlock_irqrestore(&(rings[i])->producer_lock, flags);
+   spin_unlock(&(rings[i])->producer_lock);
+   spin_unlock_irqrestore(&(rings[i])->consumer_lock, flags);
}
  
  	for (i = 0; i < nrings; ++i)

Re: [PATCH 0/3] Add support for MyGica T230C DVB-T2 stick

[Antti Palosaari]

On 02/12/2017 05:26 PM, Stefan Brüns wrote:

The required command sequence for the new tuner (Si2141) was traced from the
current Windows driver and verified with a small python script/libusb.
The changes to the Si2168 and cxusb driver are mostly addition of the
required IDs and some glue code.

Stefan Brüns (3):
  [media] si2157: Add support for Si2141-A10
  [media] si2168: add support for Si2168-D60
  [media] cxusb: MyGica T230C support

 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/dvb-frontends/si2168.c  |  4 ++
 drivers/media/dvb-frontends/si2168_priv.h |  2 +
 drivers/media/tuners/si2157.c | 23 -
 drivers/media/tuners/si2157_priv.h|  2 +
 drivers/media/usb/dvb-usb/cxusb.c | 80 +--
 6 files changed, 106 insertions(+), 6 deletions(-)



Patch set looks pretty correct, but remote controller is something I 
hope you could fix. Old T230 did it wrong and defined 
rc_map_d680_dmb_table whilst proper map is 
RC_MAP_TOTAL_MEDIA_IN_HAND_02. Secondly it should be converted to 
rc-core. Even those are wrong for old revision, for new devices those 
should be done correct.


regards
Antti
--
http://palosaari.fi/

Re: [PATCH v2 5/6] drm: convert drivers to use drm_of_find_panel_or_bridge

[Archit Taneja]

On 02/10/2017 12:35 AM, Rob Herring wrote:

Similar to the previous commit, convert drivers open coding OF graph
parsing to use drm_of_find_panel_or_bridge instead.

This changes some error messages to debug messages (in the graph core).
Graph connections are often "no connects" depending on the particular
board, so we want to avoid spurious messages. Plus the kernel is not a
DT validator.


For the bridge drivers:

Reviewed-by: Archit Taneja 

Thanks,
Archit



Signed-off-by: Rob Herring 
---
v2:
- fix wrong node ptr in imx-ldb
- build fixes in kirin and imx drivers

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 64 -
 drivers/gpu/drm/bridge/nxp-ptn3460.c | 16 ++---
 drivers/gpu/drm/bridge/parade-ps8622.c   | 16 ++---
 drivers/gpu/drm/bridge/tc358767.c| 27 +--
 drivers/gpu/drm/exynos/exynos_dp.c   | 35 -
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 49 -
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 27 ++-
 drivers/gpu/drm/imx/imx-ldb.c| 27 ++-
 drivers/gpu/drm/imx/parallel-display.c   | 36 ++
 drivers/gpu/drm/mediatek/mtk_dsi.c   | 23 ++
 drivers/gpu/drm/mxsfb/mxsfb_out.c| 36 ++
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c  | 26 ++-
 drivers/gpu/drm/sun4i/sun4i_rgb.c| 13 ++--
 drivers/gpu/drm/sun4i/sun4i_tcon.c   | 90 ++--
 14 files changed, 88 insertions(+), 397 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 6119b5085501..4614048a4935 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -22,7 +22,7 @@
 #include 

 #include 
-#include 
+#include 

 #include "atmel_hlcdc_dc.h"

@@ -152,29 +152,11 @@ static const struct drm_connector_funcs 
atmel_hlcdc_panel_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

-static int atmel_hlcdc_check_endpoint(struct drm_device *dev,
- const struct of_endpoint *ep)
-{
-   struct device_node *np;
-   void *obj;
-
-   np = of_graph_get_remote_port_parent(ep->local_node);
-
-   obj = of_drm_find_panel(np);
-   if (!obj)
-   obj = of_drm_find_bridge(np);
-
-   of_node_put(np);
-
-   return obj ? 0 : -EPROBE_DEFER;
-}
-
 static int atmel_hlcdc_attach_endpoint(struct drm_device *dev,
-  const struct of_endpoint *ep)
+  const struct device_node *np)
 {
struct atmel_hlcdc_dc *dc = dev->dev_private;
struct atmel_hlcdc_rgb_output *output;
-   struct device_node *np;
struct drm_panel *panel;
struct drm_bridge *bridge;
int ret;
@@ -195,13 +177,11 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
*dev,

output->encoder.possible_crtcs = 0x1;

-   np = of_graph_get_remote_port_parent(ep->local_node);
-
-   ret = -EPROBE_DEFER;
+   ret = drm_of_find_panel_or_bridge(np, 0, 0, &panel, &bridge);
+   if (ret)
+   return ret;

-   panel = of_drm_find_panel(np);
if (panel) {
-   of_node_put(np);
output->connector.dpms = DRM_MODE_DPMS_OFF;
output->connector.polled = DRM_CONNECTOR_POLL_CONNECT;
drm_connector_helper_add(&output->connector,
@@ -226,9 +206,6 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
*dev,
return 0;
}

-   bridge = of_drm_find_bridge(np);
-   of_node_put(np);
-
if (bridge) {
output->encoder.bridge = bridge;
bridge->encoder = &output->encoder;
@@ -245,31 +222,14 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
*dev,

 int atmel_hlcdc_create_outputs(struct drm_device *dev)
 {
-   struct device_node *ep_np = NULL;
-   struct of_endpoint ep;
+   struct device_node *remote;
int ret;

-   for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
-   ret = of_graph_parse_endpoint(ep_np, &ep);
-   if (!ret)
-   ret = atmel_hlcdc_check_endpoint(dev, &ep);
-
-   if (ret) {
-   of_node_put(ep_np);
-   return ret;
-   }
-   }
-
-   for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
-   ret = of_graph_parse_endpoint(ep_np, &ep);
-   if (!ret)
-   ret = atmel_hlcdc_attach_endpoint(dev, &ep);
-
-   if (ret) {
-   of_node_put(ep_np);
-   return ret;
-   }
-   }
+   remote = of_graph_get_remote_node(dev->dev->of_node, 0, 0);
+   if (!remote)
+   return -ENODEV;

-   return 0;
+  

Re: [PATCH V2 2/7] mm: move MADV_FREE pages into LRU_INACTIVE_FILE list

[Minchan Kim]

Hi Shaohua,

On Fri, Feb 10, 2017 at 09:30:09AM -0800, Shaohua Li wrote:

< snip >

> > > +static inline bool page_is_lazyfree(struct page *page)
> > > +{
> > > + return PageAnon(page) && !PageSwapBacked(page);
> > > +}
> > > +
> > 
> > trivial:
> > 
> > How about using PageLazyFree for consistency with other PageXXX?
> > As well, use SetPageLazyFree/ClearPageLazyFree rather than using
> > raw {Set,Clear}PageSwapBacked.
> 
> So SetPageLazyFree == ClearPageSwapBacked, that would be weird. I personally
> prefer directly using {Set, Clear}PageSwapBacked, because reader can
> immediately know what's happening. If using the PageLazyFree, people always
> need to refer the code and check the relationship between PageLazyFree and
> PageSwapBacked.

I was not against so I was about to sending "No problem" now but I found your
patch 5 which accounts lazyfreeable pages in zone/node stat and handle them
in lru list management. Hmm, I think now we don't handle lazyfree pages with
separate LRU list so it's awkward to me although it may work. So, my idea is
we can handle it through wrapper regardless of LRU management.

For instance,

void SetLazyFreePage(struct page *page)
{
if (!TestSetPageSwapBacked(page))
inc_zone_page_state(page, NR_ZONE_LAZYFREE);
}


void ClearLazyFreePage(struct page *page)
{
if (TestClearPageSwapBacked(page))
dec_zone_page_state(page, NR_ZONE_LAZYFREE);
}

madvise_free_pte_range:
SetLageFreePage(page);

activate_page,shrink_page_list:
ClearLazyFreePage(page);

free_pages_prepare:
if (PageMappingFlags(page)) {
if (PageLazyFreePage(page))
dec_zone_page_state(page, NR_ZONE_LAZYFREE);
page->mapping = NULL;
}

Surely, it's orthgonal issue regardless of using wrapper but it might
nudge you to use wrapper.

>  
> > >  static __always_inline void __update_lru_size(struct lruvec *lruvec,
> > >   enum lru_list lru, enum zone_type zid,
> > >   int nr_pages)
> > > diff --git a/include/linux/swap.h b/include/linux/swap.h
> > > index 45e91dd..486494e 100644
> > > --- a/include/linux/swap.h
> > > +++ b/include/linux/swap.h
> > > @@ -279,7 +279,7 @@ extern void lru_add_drain_cpu(int cpu);
> > >  extern void lru_add_drain_all(void);
> > >  extern void rotate_reclaimable_page(struct page *page);
> > >  extern void deactivate_file_page(struct page *page);
> > > -extern void deactivate_page(struct page *page);
> > > +extern void mark_page_lazyfree(struct page *page);
> > 
> > trivial:
> > 
> > How about "deactivate_lazyfree_page"? IMO, it would show intention
> > clear that move the lazy free page to inactive list.
> > 
> > It's just matter of preference so I'm not strong against.
> 
> Yes, I thought about the name a little bit. Don't think we should use
> deactivate, because it sounds that only works for active page, while the
> function works for both active/inactive pages. I'm open to any suggestions.

Indeed.

I don't have better idea, either so my last suggestion is 
"demote_lazyfree_page".
It seems there are several papers/wikipedia to use *demote* in LRU managment.

Re: [PATCH] llist: Don't reinvent the wheel but use existing llist API

[NeilBrown]

On Mon, Feb 13 2017, Byungchul Park wrote:

> Although llist provides proper APIs, they are not used. Make them used.
>
> Signed-off-by: Byungchul Park 
> ---
>  drivers/md/bcache/closure.c | 15 ++-
>  drivers/md/raid5.c  |  4 +---
>  drivers/vhost/scsi.c|  9 ++---
>  fs/file_table.c | 12 +---
>  fs/namespace.c  | 12 +---
>  include/linux/llist.h   |  3 +++
>  kernel/irq_work.c   |  6 +-
>  kernel/sched/core.c | 13 ++---
>  mm/vmalloc.c|  8 +++-
>  9 files changed, 24 insertions(+), 58 deletions(-)
>
...

> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 36c13e4..c82243a 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -359,11 +359,9 @@ static int release_stripe_list(struct r5conf *conf,
>  
>   head = llist_del_all(&conf->released_stripes);
>   head = llist_reverse_order(head);
> - while (head) {
> + llist_for_each_entry(sh, head, release_list) {
>   int hash;
>  
> - sh = llist_entry(head, struct stripe_head, release_list);
> - head = llist_next(head);
>   /* sh could be readded after STRIPE_ON_RELEASE_LIST is cleard */
>   smp_mb();
>   clear_bit(STRIPE_ON_RELEASE_LIST, &sh->state);

This one is wrong (I haven't checked the rest).
As soon a STRIPE_ON_RELEASE_LIST is cleared, the llist_node can be
reused, so we need to call llist_next *before* the rest of the code.
You have moved the call to afterwards.

You could possibly change it to use llist_for_each_entry_safe()

NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH v2 3/6] drm: of: introduce drm_of_find_panel_or_bridge

[Archit Taneja]

On 02/10/2017 12:35 AM, Rob Herring wrote:

Many drivers have a common pattern of searching the OF graph for either an
attached panel or bridge and then finding the DRM struct for the panel
or bridge. Also, most drivers need to handle deferred probing when the
DRM device is not yet instantiated. Create a common function,
drm_of_find_panel_or_bridge, to find the connected node and the
associated DRM panel or bridge device.

Signed-off-by: Rob Herring 
Acked-by: Philipp Zabel 
---
v2:
- Reworked code flow
- Added note that at least one of panel or bridge must not be NULL.

 drivers/gpu/drm/drm_of.c | 52 
 include/drm/drm_of.h | 13 
 2 files changed, 65 insertions(+)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 47848ed8ca48..86b8b959587a 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -3,7 +3,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 

 static void drm_release_of(struct device *dev, void *data)
@@ -207,3 +209,53 @@ int drm_of_encoder_active_endpoint(struct device_node 
*node,
return -EINVAL;
 }
 EXPORT_SYMBOL_GPL(drm_of_encoder_active_endpoint);
+
+/*
+ * drm_of_find_panel_or_bridge - return connected panel or bridge device
+ * @np: device tree node containing encoder input ports


Should this be 'encoder output ports'? It's the encoder's output port(s) that
contain the endpoint corresponding to the bridge/panel input port.

Thanks,
Archit


+ * @panel: pointer to hold returned drm_panel
+ * @bridge: pointer to hold returned drm_bridge
+ *
+ * Given a DT node's port and endpoint number, find the connected node and
+ * return either the associated struct drm_panel or drm_bridge device. Either
+ * @panel or @bridge must not be NULL.
+ *
+ * Returns zero if successful, or one of the standard error codes if it fails.
+ */
+int drm_of_find_panel_or_bridge(const struct device_node *np,
+   int port, int endpoint,
+   struct drm_panel **panel,
+   struct drm_bridge **bridge)
+{
+   int ret = -EPROBE_DEFER;
+   struct device_node *remote;
+
+   if (!panel && !bridge)
+   return -EINVAL;
+
+   remote = of_graph_get_remote_node(np, port, endpoint);
+   if (!remote)
+   return -ENODEV;
+
+   if (panel) {
+   *panel = of_drm_find_panel(remote);
+   if (*panel)
+   ret = 0;
+   }
+
+   /* No panel found yet, check for a bridge next. */
+   if (bridge) {
+   if (ret) {
+   *bridge = of_drm_find_bridge(remote);
+   if (*bridge)
+   ret = 0;
+   } else {
+   *bridge = NULL;
+   }
+
+   }
+
+   of_node_put(remote);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index 26a64805cc15..f86507f0599b 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -8,6 +8,8 @@ struct component_match;
 struct device;
 struct drm_device;
 struct drm_encoder;
+struct drm_panel;
+struct drm_bridge;
 struct device_node;

 #ifdef CONFIG_OF
@@ -23,6 +25,10 @@ extern int drm_of_component_probe(struct device *dev,
 extern int drm_of_encoder_active_endpoint(struct device_node *node,
  struct drm_encoder *encoder,
  struct of_endpoint *endpoint);
+extern int drm_of_find_panel_or_bridge(const struct device_node *np,
+  int port, int endpoint,
+  struct drm_panel **panel,
+  struct drm_bridge **bridge);
 #else
 static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
  struct device_node *port)
@@ -52,6 +58,13 @@ static inline int drm_of_encoder_active_endpoint(struct 
device_node *node,
 {
return -EINVAL;
 }
+static inline int drm_of_find_panel_or_bridge(const struct device_node *np,
+ int port, int endpoint,
+ struct drm_panel **panel,
+ struct drm_bridge **bridge)
+{
+   return -EINVAL;
+}
 #endif

 static inline int drm_of_encoder_active_endpoint_id(struct device_node *node,
--
2.10.1



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

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

[Paul E. McKenney]

On Mon, Feb 13, 2017 at 01:21:33PM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Thu, 19 Jan 2017 13:54:37 -0800 Paul McKenney  wrote:
> >
> > On Wed, Jan 18, 2017 at 7:34 PM, Stephen Rothwell  
> > wrote:
> > > Hi Paul,
> > >
> > > After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > >
> > > net/smc/af_smc.c:102:16: error: 'SLAB_DESTROY_BY_RCU' undeclared here 
> > > (not in a function)
> > >   .slab_flags = SLAB_DESTROY_BY_RCU,
> > > ^
> > >
> > > Caused by commit
> > >
> > >   c7a545924ca1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU")
> > >
> > > interacting with commit
> > >
> > >   ac7138746e14 ("smc: establish new socket family")
> > >
> > > from the net-next tree.
> > >
> > > I have applied the following merge fix patch (someone will need to
> > > remember to mention this to Linus):  
> > 
> > Thank you, Stephen!  I expect that there might be a bit more
> > bikeshedding on the name, but here is hoping...  :-/
> 
> The need for this merge fix patch has gone away today.  Is that a
> permanent situation, or will it come back?

I chickened out on that commit for this merge window, so it will come
back at -rc1.  But I will cover that when I rebase to -rc1.

Thanx, Paul

Re: [lkp-robot] [platform/x86] b925ff7dcd: BUG:unable_to_handle_kernel

[Jonathan Woithe]

Michael

On Mon, Feb 13, 2017 at 10:40:15AM +0800, kernel test robot wrote:
> FYI, we noticed the following commit:
> 
> commit: b925ff7dcd1fc45b86baaebd3442f8b484123716 ("platform/x86: 
> fujitsu-laptop: only register backlight device if FUJ02B1 is present")
> url: 
> https://github.com/0day-ci/linux/commits/Micha-K-pie/fujitsu-laptop-renames-and-cleanups/20170209-030748
> base: git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git 
> for-next
> 
> in testcase: boot
> 
> on test machine: qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -m 360M
> 
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):
> :
> [4.656202] fujitsu_laptop: call_fext_func: FUNC interface is not present
> [4.657478] BUG: unable to handle kernel NULL pointer dereference at 
> 0008
> [4.658433] IP: fujitsu_init+0x137/0x1b7
> [4.659208] *pdpt =  *pde = f000ff53f000ff53 
> :

I'm away from my Fujitsu hardware right now, and in any case this does not
get triggered on it.

I note that prior to the bug we get "FUNC interface is not present". 
Therefore something called call_fext_func() some time before the NULL
pointer dereference.  As far as I can tell the only such call which could be
made prior to or within fujitsu_init() is from fujitsu_init(), but this is
conditional on acpi_video_get_backlight_type() returning
acpi_backlight_vendor (line 1269).  Obviously if this conditional were
passed but fujitsu_bl->bl_device were NULL then we would get the NULL
dereference.

If ACPI_FUJITSU_LAPTOP_HID is not present then presumedly the

  acpi_bus_register_driver(&acpi_fujitsu_bl_driver)

call in fujitsu_init() will fail and nothing further would happen. 
Therefore this HID must be in the system.

However, the acpi_fujitsu_bl_add() callback wouldn't necessarily get run by
acpi_bus_register_driver(), would it?  I'm not too familiar with the lower
level ACPI functions but a quick trip through the source suggested that the
add callback isn't called via acpi_bus_register_driver().  This would mean
that that fujitsu_bl->bl_device would not yet be initialised when referenced
within fujitsu_init() at line 1271 or 1273.  If this were the case then I
see two options:

 1) Don't move the backlight registration out of fujitsu_init().

 2) Move the remaining backlight code (lines 1268-1274) into
acpi_fujitsu_bl_add().

Item 1 effectively amounts to dropping this commit.  I'm not sure option 2
is workable because of the code's reliance on FUJ02E3; is that guaranteed to
be useable by the time acpi_fujitsu_bl_add() is called?

The only problem with the above theory is that it doesn't explain why the
NULL pointer dereference wasn't triggered on my Fujitsu hardware when this
code was tested on it.  If the ACPI bus probed/added asynchronously I guess
there could be a race whereby acpi_fujitsu_bl_add() may or may not have
completed by the time fujitsu_init() referenced fujitsu_bl->bl_device.  That
doesn't seem right to me though.

Regards
  jonathan

Re: [PATCH] sched/deadline: Remove redundant code replenishing runtime

[Byungchul Park]

On Mon, Feb 13, 2017 at 11:30:09AM +0900, Byungchul Park wrote:
> On Fri, Feb 10, 2017 at 01:39:33PM +, Juri Lelli wrote:
> > Hi,
> > 
> > On 10/02/17 18:11, Byungchul Park wrote:
> > > For a task passing its deadline while !rq, it will be replenished
> > > in the following path because dl_se->deadline < rq_lock.
> > > 
> > >enqueue_dl_entity(ENQUEUE_WAKEUP)
> > >   update_dl_entity
> > > 
> > > Therefore, code replenishing it in the timer callback in the case is
> > > unnecessary. This is not for enhancing performance but just for removing
> > > a redundant code.
> > > 
> > > Signed-off-by: Byungchul Park 
> > > ---
> > >  kernel/sched/deadline.c | 4 +---
> > >  1 file changed, 1 insertion(+), 3 deletions(-)
> > > 
> > > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> > > index 27737f3..9c77696 100644
> > > --- a/kernel/sched/deadline.c
> > > +++ b/kernel/sched/deadline.c
> > > @@ -624,10 +624,8 @@ static enum hrtimer_restart dl_task_timer(struct 
> > > hrtimer *timer)
> > >* We can be both throttled and !queued. Replenish the counter
> > >* but do not enqueue -- wait for our wakeup to do that.
> > >*/
> > > - if (!task_on_rq_queued(p)) {
> > > - replenish_dl_entity(dl_se, dl_se);
> > 
> > I think we actually want to replenish and set the next deadline at this
> > point of time, not the one that we get when the task will eventually wake 
> > up.
> 
> Hello juri,
> 
> But I wonder if it's meaningful to set a next deadline for a 'sleeping
> task', which, rather, could be worse because its bandwidth might be
> distorted at the time it's woken up.
> 
> IMHO, it's neat to set its deadline and runtime when being woken up, in
> the case already passed its deadline. Am I wrong?

And I found that dl_entity_overflow() returns true and replenishes the
task unconditionally in update_dl_entity() again when the task is woken
up, because 'runtime / (deadline - t) > dl_runtime / dl_period' is true.

In other words, replenishing the sleeping task in timer callback is
totally unnecessary and redundant work.

> 
> Thank you,
> Byungchul