Re: [PATCH] staging fbtft: Fixed lines exceeding columns limit

2018-04-13 Thread Renato Soma 
On Fri, Apr 13, 2018 at 03:57:47PM +0300, Dan Carpenter wrote:
> > -   ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, 0); 
> > \
> 
> I feel like the original is basically OK but if we're going to change it
> then align it like this:
> 
>   ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, 
> \
>0);
> \
> 
> 
> Etc.
> 

Alright, I'll fix this issue then send another email with the fixed patch.

Thanks!
renato
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [Resend Patch 3/3] Storvsc: Select channel based on available percentage of ring buffer to write

2018-04-13 Thread Long Li 
> Subject: RE: [Resend Patch 3/3] Storvsc: Select channel based on available
> percentage of ring buffer to write
> 
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org
> >  On Behalf Of Long Li
> > Sent: Tuesday, March 27, 2018 5:49 PM
> > To: KY Srinivasan ; Haiyang Zhang
> > ; Stephen Hemminger
> ;
> > James E . J . Bottomley ; Martin K . Petersen
> > ; de...@linuxdriverproject.org; linux-
> > s...@vger.kernel.org; linux-ker...@vger.kernel.org;
> > net...@vger.kernel.org
> > Cc: Long Li 
> > Subject: [Resend Patch 3/3] Storvsc: Select channel based on available
> > percentage of ring buffer to write
> >
> > From: Long Li 
> >
> > This is a best effort for estimating on how busy the ring buffer is
> > for that channel, based on available buffer to write in percentage. It
> > is still possible that at the time of actual ring buffer write, the
> > space may not be available due to other processes may be writing at the
> time.
> >
> > Selecting a channel based on how full it is can reduce the possibility
> > that a ring buffer write will fail, and avoid the situation a channel
> > is over busy.
> >
> > Now it's possible that storvsc can use a smaller ring buffer size
> > (e.g. 40k bytes) to take advantage of cache locality.
> >
> > Signed-off-by: Long Li 
> > ---
> >  drivers/scsi/storvsc_drv.c | 62
> > +-
> >  1 file changed, 50 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> > index a2ec0bc9e9fa..b1a87072b3ab 100644
> > --- a/drivers/scsi/storvsc_drv.c
> > +++ b/drivers/scsi/storvsc_drv.c
> > @@ -395,6 +395,12 @@ MODULE_PARM_DESC(storvsc_ringbuffer_size,
> "Ring
> > buffer size (bytes)");
> >
> >  module_param(storvsc_vcpus_per_sub_channel, int, S_IRUGO);
> > MODULE_PARM_DESC(storvsc_vcpus_per_sub_channel, "Ratio of VCPUs
> to
> > subchannels");
> > +
> > +static int ring_avail_percent_lowater = 10;
> 
> Reserving 10% of each ring buffer by default seems like more than is needed
> in the storvsc driver.  That would be about 4Kbytes for the 40K ring buffer
> you suggest, and even more for a ring buffer of 128K.  Each outgoing record is
> only about 344 bytes (I'd have to check exactly).  With the new channel
> selection algorithm below, the only time we use a channel that is already
> below the low water mark is when no channel could be found that is above
> the low water mark.   There could be a case of two or more threads deciding
> that a channel is above the low water mark at the same time and both
> choosing it, but that's likely to be rare.  So it seems like we could set the

It's not rare for two processes checking on the same channel at the same time, 
when running multiple processes I/O workload. The CPU to channel is not 1:1 
mapping.

> default low water mark to 5 percent or even 3 percent, which will let more of
> the ring buffer be used, and let a channel be assigned according to the
> algorithm, rather than falling through to the default because all channels
> appear to be "full".

It seems it's not about how big ring buffer is, e.g. even you have a ring 
buffer of infinite size, it won't help with performance if it's getting queued 
all the time, while other ring buffers are near empty. It's more about how 
multiple ring buffers are getting utilized in a reasonable and balanced way. 
Testing shows 10 is a good choice, while 3 is prone to return BUSY and trigger 
block layer retry.

> 
> > +module_param(ring_avail_percent_lowater, int, S_IRUGO);
> > +MODULE_PARM_DESC(ring_avail_percent_lowater,
> > +   "Select a channel if available ring size > this in percent");
> > +
> >  /*
> >   * Timeout in seconds for all devices managed by this driver.
> >   */
> > @@ -1285,9 +1291,9 @@ static int storvsc_do_io(struct hv_device
> > *device,  {
> > struct storvsc_device *stor_device;
> > struct vstor_packet *vstor_packet;
> > -   struct vmbus_channel *outgoing_channel;
> > +   struct vmbus_channel *outgoing_channel, *channel;
> > int ret = 0;
> > -   struct cpumask alloced_mask;
> > +   struct cpumask alloced_mask, other_numa_mask;
> > int tgt_cpu;
> >
> > vstor_packet = >vstor_packet; @@ -1301,22 +1307,53 @@
> > static int storvsc_do_io(struct hv_device *device,
> > /*
> >  * Select an an appropriate channel to send the request out.
> >  */
> > -
> > if (stor_device->stor_chns[q_num] != NULL) {
> > outgoing_channel = stor_device->stor_chns[q_num];
> > -   if (outgoing_channel->target_cpu == smp_processor_id()) {
> > +   if (outgoing_channel->target_cpu == q_num) {
> > /*
> >  * Ideally, we want to pick a different channel if
> >

RE: [Resend Patch 2/3] Netvsc: Use the vmbus functiton to calculate ring buffer percentage

2018-04-13 Thread Michael Kelley (EOSG) 
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org  
> On Behalf
> Of Long Li
> Sent: Tuesday, March 27, 2018 5:49 PM
> To: KY Srinivasan ; Haiyang Zhang 
> ; Stephen
> Hemminger ; James E . J . Bottomley 
> ;
> Martin K . Petersen ; 
> de...@linuxdriverproject.org; linux-
> s...@vger.kernel.org; linux-ker...@vger.kernel.org; net...@vger.kernel.org
> Cc: Long Li 
> Subject: [Resend Patch 2/3] Netvsc: Use the vmbus functiton to calculate ring 
> buffer
> percentage
> 
> From: Long Li 
> 
> In Vmbus, we have defined a function to calculate available ring buffer
> percentage to write.
> 
> Use that function and remove netvsc's private version.
> 
> Signed-off-by: Long Li 

Reviewed-by:  Michael Kelley 

> ---
>  drivers/net/hyperv/hyperv_net.h |  1 -
>  drivers/net/hyperv/netvsc.c | 17 +++--
>  drivers/net/hyperv/netvsc_drv.c |  3 ---
>  3 files changed, 3 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
> index cd538d5a7986..a0199ab13d67 100644
> --- a/drivers/net/hyperv/hyperv_net.h
> +++ b/drivers/net/hyperv/hyperv_net.h
> @@ -189,7 +189,6 @@ struct netvsc_device;
>  struct net_device_context;
> 
>  extern u32 netvsc_ring_bytes;
> -extern struct reciprocal_value netvsc_ring_reciprocal;
> 
>  struct netvsc_device *netvsc_device_add(struct hv_device *device,
>   const struct netvsc_device_info *info);
> diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
> index 0265d703eb03..8af0069e4d8c 100644
> --- a/drivers/net/hyperv/netvsc.c
> +++ b/drivers/net/hyperv/netvsc.c
> @@ -31,7 +31,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> 
>  #include 
> 
> @@ -590,17 +589,6 @@ void netvsc_device_remove(struct hv_device *device)
>  #define RING_AVAIL_PERCENT_HIWATER 20
>  #define RING_AVAIL_PERCENT_LOWATER 10
> 
> -/*
> - * Get the percentage of available bytes to write in the ring.
> - * The return value is in range from 0 to 100.
> - */
> -static u32 hv_ringbuf_avail_percent(const struct hv_ring_buffer_info 
> *ring_info)
> -{
> - u32 avail_write = hv_get_bytes_to_write(ring_info);
> -
> - return reciprocal_divide(avail_write  * 100, netvsc_ring_reciprocal);
> -}
> -
>  static inline void netvsc_free_send_slot(struct netvsc_device *net_device,
>u32 index)
>  {
> @@ -649,7 +637,8 @@ static void netvsc_send_tx_complete(struct netvsc_device
> *net_device,
>   wake_up(_device->wait_drain);
> 
>   if (netif_tx_queue_stopped(netdev_get_tx_queue(ndev, q_idx)) &&
> - (hv_ringbuf_avail_percent(>outbound) >
> RING_AVAIL_PERCENT_HIWATER ||
> + (hv_get_avail_to_write_percent(>outbound) >
> +  RING_AVAIL_PERCENT_HIWATER ||
>queue_sends < 1)) {
>   netif_tx_wake_queue(netdev_get_tx_queue(ndev, q_idx));
>   ndev_ctx->eth_stats.wake_queue++;
> @@ -757,7 +746,7 @@ static inline int netvsc_send_pkt(
>   struct netdev_queue *txq = netdev_get_tx_queue(ndev, packet->q_idx);
>   u64 req_id;
>   int ret;
> - u32 ring_avail = hv_ringbuf_avail_percent(_channel->outbound);
> + u32 ring_avail = hv_get_avail_to_write_percent(_channel->outbound);
> 
>   nvmsg.hdr.msg_type = NVSP_MSG1_TYPE_SEND_RNDIS_PKT;
>   if (skb)
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index faea0be18924..b0b1c2fd2b7b 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -35,7 +35,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> 
>  #include 
>  #include 
> @@ -55,7 +54,6 @@ static unsigned int ring_size __ro_after_init = 128;
>  module_param(ring_size, uint, S_IRUGO);
>  MODULE_PARM_DESC(ring_size, "Ring buffer size (# of pages)");
>  unsigned int netvsc_ring_bytes __ro_after_init;
> -struct reciprocal_value netvsc_ring_reciprocal __ro_after_init;
> 
>  static const u32 default_msg = NETIF_MSG_DRV | NETIF_MSG_PROBE |
>   NETIF_MSG_LINK | NETIF_MSG_IFUP |
> @@ -2186,7 +2184,6 @@ static int __init netvsc_drv_init(void)
>   ring_size);
>   }
>   netvsc_ring_bytes = ring_size * PAGE_SIZE;
> - netvsc_ring_reciprocal = reciprocal_value(netvsc_ring_bytes);
> 
>   ret = vmbus_driver_register(_drv);
>   if (ret)
> --
> 2.14.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [Resend Patch 3/3] Storvsc: Select channel based on available percentage of ring buffer to write

2018-04-13 Thread Michael Kelley (EOSG) 
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org  
> On Behalf
> Of Long Li
> Sent: Tuesday, March 27, 2018 5:49 PM
> To: KY Srinivasan ; Haiyang Zhang 
> ; Stephen
> Hemminger ; James E . J . Bottomley 
> ;
> Martin K . Petersen ; 
> de...@linuxdriverproject.org; linux-
> s...@vger.kernel.org; linux-ker...@vger.kernel.org; net...@vger.kernel.org
> Cc: Long Li 
> Subject: [Resend Patch 3/3] Storvsc: Select channel based on available 
> percentage of ring
> buffer to write
> 
> From: Long Li 
> 
> This is a best effort for estimating on how busy the ring buffer is for
> that channel, based on available buffer to write in percentage. It is still
> possible that at the time of actual ring buffer write, the space may not be
> available due to other processes may be writing at the time.
> 
> Selecting a channel based on how full it is can reduce the possibility that
> a ring buffer write will fail, and avoid the situation a channel is over
> busy.
> 
> Now it's possible that storvsc can use a smaller ring buffer size
> (e.g. 40k bytes) to take advantage of cache locality.
> 
> Signed-off-by: Long Li 
> ---
>  drivers/scsi/storvsc_drv.c | 62 
> +-
>  1 file changed, 50 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index a2ec0bc9e9fa..b1a87072b3ab 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -395,6 +395,12 @@ MODULE_PARM_DESC(storvsc_ringbuffer_size, "Ring buffer 
> size
> (bytes)");
> 
>  module_param(storvsc_vcpus_per_sub_channel, int, S_IRUGO);
>  MODULE_PARM_DESC(storvsc_vcpus_per_sub_channel, "Ratio of VCPUs to 
> subchannels");
> +
> +static int ring_avail_percent_lowater = 10;

Reserving 10% of each ring buffer by default seems like more than is needed
in the storvsc driver.  That would be about 4Kbytes for the 40K ring buffer
you suggest, and even more for a ring buffer of 128K.  Each outgoing record
is only about 344 bytes (I'd have to check exactly).  With the new channel
selection algorithm below, the only time we use a channel that is already
below the low water mark is when no channel could be found that is above
the low water mark.   There could be a case of two or more threads deciding
that a channel is above the low water mark at the same time and both
choosing it, but that's likely to be rare.  So it seems like we could set the
default low water mark to 5 percent or even 3 percent, which will let more
of the ring buffer be used, and let a channel be assigned according to the
algorithm, rather than falling through to the default because all channels
appear to be "full".

> +module_param(ring_avail_percent_lowater, int, S_IRUGO);
> +MODULE_PARM_DESC(ring_avail_percent_lowater,
> + "Select a channel if available ring size > this in percent");
> +
>  /*
>   * Timeout in seconds for all devices managed by this driver.
>   */
> @@ -1285,9 +1291,9 @@ static int storvsc_do_io(struct hv_device *device,
>  {
>   struct storvsc_device *stor_device;
>   struct vstor_packet *vstor_packet;
> - struct vmbus_channel *outgoing_channel;
> + struct vmbus_channel *outgoing_channel, *channel;
>   int ret = 0;
> - struct cpumask alloced_mask;
> + struct cpumask alloced_mask, other_numa_mask;
>   int tgt_cpu;
> 
>   vstor_packet = >vstor_packet;
> @@ -1301,22 +1307,53 @@ static int storvsc_do_io(struct hv_device *device,
>   /*
>* Select an an appropriate channel to send the request out.
>*/
> -
>   if (stor_device->stor_chns[q_num] != NULL) {
>   outgoing_channel = stor_device->stor_chns[q_num];
> - if (outgoing_channel->target_cpu == smp_processor_id()) {
> + if (outgoing_channel->target_cpu == q_num) {
>   /*
>* Ideally, we want to pick a different channel if
>* available on the same NUMA node.
>*/
>   cpumask_and(_mask, _device->alloced_cpus,
>   cpumask_of_node(cpu_to_node(q_num)));
> - for_each_cpu_wrap(tgt_cpu, _mask,
> - outgoing_channel->target_cpu + 1) {
> - if (tgt_cpu != outgoing_channel->target_cpu) {
> - outgoing_channel =
> - stor_device->stor_chns[tgt_cpu];
> - break;
> +
> + for_each_cpu_wrap(tgt_cpu, _mask, q_num + 1) {
> + if (tgt_cpu == q_num)
> + continue;
> + channel =

Re: [PATCH 03/17] media: atomisp: fix __user annotations

2018-04-13 Thread kbuild test robot 
Hi Mauro,

I love your patch! Yet something to improve:

[auto build test ERROR on next-20180411]
[also build test ERROR on v4.16]
[cannot apply to linuxtv-media/master staging/staging-testing v4.16 v4.16-rc7 
v4.16-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Mauro-Carvalho-Chehab/media-staging-atomisp-fix-number-conversion/20180414-000700
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the 
linux-review/Mauro-Carvalho-Chehab/media-staging-atomisp-fix-number-conversion/20180414-000700
 HEAD 3b98aee6f72133addf14b8bc4fc71c2978bf81f9 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> ERROR: "mmu_reg_store" 
>> [drivers/staging/media/atomisp/pci/atomisp2/atomisp.ko] undefined!
>> ERROR: "mmu_reg_load" 
>> [drivers/staging/media/atomisp/pci/atomisp2/atomisp.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 02/17] media: staging: atomisp: don't declare the same vars as both private and public

2018-04-13 Thread kbuild test robot 
Hi Mauro,

I love your patch! Yet something to improve:

[auto build test ERROR on next-20180411]
[also build test ERROR on v4.16]
[cannot apply to linuxtv-media/master staging/staging-testing v4.16 v4.16-rc7 
v4.16-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Mauro-Carvalho-Chehab/media-staging-atomisp-fix-number-conversion/20180414-000700
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   
drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu.o:
 In function `mmu_set_page_table_base_index':
>> mmu.c:(.text+0x10): undefined reference to `mmu_reg_store'
   
drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu.o:
 In function `mmu_get_page_table_base_index':
>> mmu.c:(.text+0x2e): undefined reference to `mmu_reg_load'
   
drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu.o:
 In function `mmu_invalidate_cache':
   mmu.c:(.text+0x50): undefined reference to `mmu_reg_store'
   
drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu.o:
 In function `mmu_invalidate_cache_all':
   mmu.c:(.text+0x72): undefined reference to `mmu_reg_store'
   mmu.c:(.text+0x83): undefined reference to `mmu_reg_store'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 14/14] staging: ks7010: use linux circular buffer header macros to handle tx and rx queues

2018-04-13 Thread Sergio Paracuellos 
On Fri, Apr 13, 2018 at 3:27 PM, Dan Carpenter  wrote:
>
> This is the last patch in the series so I think we could just drop it
> without resending the others.

True. Ok, I'll resend the last one modified in my next series.

>
> regards,
> dan carpenter
>

Best regards,
Sergio Paracuellos
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 14/14] staging: ks7010: use linux circular buffer header macros to handle tx and rx queues

2018-04-13 Thread Dan Carpenter 

This is the last patch in the series so I think we could just drop it
without resending the others.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 14/14] staging: ks7010: use linux circular buffer header macros to handle tx and rx queues

2018-04-13 Thread Sergio Paracuellos 
On Fri, Apr 13, 2018 at 2:14 PM, Dan Carpenter  wrote:
> On Thu, Apr 12, 2018 at 05:50:31PM +0200, Sergio Paracuellos wrote:
>> This commit replace current custom implementation of some circular
>> buffer head and tail logic in favour of the use of macros defined
>> in linux circ_buf.h header. It also review internal names and adds
>> a new CIRC_INC macro to make code more readable. Note also that
>> CIRC_INC does not need to go inside do-while(0) block because its
>> use is only located in the four functions that make use of it
>> so it won't expand into invalid code at all.
>>
>> Signed-off-by: Sergio Paracuellos 
>> ---
>>  drivers/staging/ks7010/ks7010_sdio.c | 59 
>> ++--
>>  1 file changed, 36 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/staging/ks7010/ks7010_sdio.c 
>> b/drivers/staging/ks7010/ks7010_sdio.c
>> index 9c591e0..9676902 100644
>> --- a/drivers/staging/ks7010/ks7010_sdio.c
>> +++ b/drivers/staging/ks7010/ks7010_sdio.c
>> @@ -10,6 +10,7 @@
>>   *   published by the Free Software Foundation.
>>   */
>>
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -101,38 +102,50 @@ enum gen_com_reg_b {
>>
>>  #define KS7010_IO_BLOCK_SIZE 512
>>
>> +#define CIRC_INC(a, b) if (++a >= b) a = 0
>
> I don't like this macro.  If we're going to call it CIRC_INC() then it
> needs to be included in include/linux/circ_buf.h and not here.  I don't
> like that the argument is  "b" instead of "size" or something.  It
> should be wrapped in a do { } while(0).  There should be parens around
> "a" and "b" so I don't have to think about precedence bugs.

Ok, I'll send v2 using other macros included in
include/linux/circ_buf.h but avoiding
the use of this new one.

Thanks, Dan.

>
> regards,
> dan carpenter

Best regards,
Sergio Paracuellos
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH RFC 3/8] mm: use PG_offline in online/offlining code

2018-04-13 Thread David Hildenbrand 
Let's mark all offline pages with PG_offline. We'll continue to mark
them reserved.

Signed-off-by: David Hildenbrand 
---
 drivers/hv/hv_balloon.c |  2 +-
 mm/memory_hotplug.c | 10 ++
 mm/page_alloc.c |  5 -
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index b3e9f13f8bc3..04d98d9b6191 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -893,7 +893,7 @@ static unsigned long handle_pg_range(unsigned long pg_start,
 * backed previously) online too.
 */
if (start_pfn > has->start_pfn &&
-   !PageReserved(pfn_to_page(start_pfn - 1)))
+   !PageOffline(pfn_to_page(start_pfn - 1)))
hv_bring_pgs_online(has, start_pfn, pgs_ol);
 
}
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index d4474781c799..3a8d56476233 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -260,8 +260,8 @@ static int __meminit __add_section(int nid, unsigned long 
phys_start_pfn,
return ret;
 
/*
-* Make all the pages reserved so that nobody will stumble over half
-* initialized state.
+* Make all the pages offline and reserved so that nobody will stumble
+* over half initialized state.
 * FIXME: We also have to associate it with a node because page_to_nid
 * relies on having page with the proper node.
 */
@@ -274,6 +274,7 @@ static int __meminit __add_section(int nid, unsigned long 
phys_start_pfn,
page = pfn_to_page(pfn);
set_page_node(page, nid);
SetPageReserved(page);
+   SetPageOffline(page);
}
 
if (!want_memblock)
@@ -669,6 +670,7 @@ EXPORT_SYMBOL_GPL(__online_page_increment_counters);
 
 void __online_page_free(struct page *page)
 {
+   ClearPageOffline(page);
__free_reserved_page(page);
 }
 EXPORT_SYMBOL_GPL(__online_page_free);
@@ -687,7 +689,7 @@ static int online_pages_range(unsigned long start_pfn, 
unsigned long nr_pages,
unsigned long onlined_pages = *(unsigned long *)arg;
struct page *page;
 
-   if (PageReserved(pfn_to_page(start_pfn)))
+   if (PageOffline(pfn_to_page(start_pfn)))
for (i = 0; i < nr_pages; i++) {
page = pfn_to_page(start_pfn + i);
(*online_page_callback)(page);
@@ -1437,7 +1439,7 @@ do_migrate_range(unsigned long start_pfn, unsigned long 
end_pfn)
 }
 
 /*
- * remove from free_area[] and mark all as Reserved.
+ * remove from free_area[] and mark all as Reserved and Offline.
  */
 static int
 offline_isolated_pages_cb(unsigned long start, unsigned long nr_pages,
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 647c8c6dd4d1..2e5dcfdb0908 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -8030,6 +8030,7 @@ __offline_isolated_pages(unsigned long start_pfn, 
unsigned long end_pfn)
if (unlikely(!PageBuddy(page) && PageHWPoison(page))) {
pfn++;
SetPageReserved(page);
+   SetPageOffline(page);
continue;
}
 
@@ -8043,8 +8044,10 @@ __offline_isolated_pages(unsigned long start_pfn, 
unsigned long end_pfn)
list_del(>lru);
rmv_page_order(page);
zone->free_area[order].nr_free--;
-   for (i = 0; i < (1 << order); i++)
+   for (i = 0; i < (1 << order); i++) {
SetPageReserved((page+i));
+   SetPageOffline(page + i);
+   }
pfn += (1 << order);
}
spin_unlock_irqrestore(>lock, flags);
-- 
2.14.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging fbtft: Fixed lines exceeding columns limit

2018-04-13 Thread Dan Carpenter 
>   if (unlikely(par->debug & DEBUG_WRITE_REGISTER)) {\
>   va_start(args, len);  \
>   for (i = 0; i < len; i++) {   \
> - buf[i] = modifier((data_type)va_arg(args, unsigned 
> int)); \
> + buf[i] = modifier((data_type)va_arg(args, \
> + unsigned int));   \


Normally we'd align the parameters like so:

buf[i] = modifier((data_type)va_arg(args,   
\
unsigned int)); 
\



>   } \
>   va_end(args); \
> - fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, par->info->device, 
> buffer_type, buf, len, "%s: ", __func__); \
> + fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par,  \
> + par->info->device, buffer_type,   \
> + buf, len, "%s: ", __func__);  \
>   } \

Not properly aligned.


> \
>   va_start(args, len);  \
> @@ -37,7 +40,8 @@ void func(struct fbtft_par *par, int len, ...)  
>   \
>   } \
> \
>   *buf = modifier((data_type)va_arg(args, unsigned int));   \
> - ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, 0); 
> \

I feel like the original is basically OK but if we're going to change it
then align it like this:

ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, 
\
 0);
\


Etc.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 14/14] staging: ks7010: use linux circular buffer header macros to handle tx and rx queues

2018-04-13 Thread Dan Carpenter 
On Thu, Apr 12, 2018 at 05:50:31PM +0200, Sergio Paracuellos wrote:
> This commit replace current custom implementation of some circular
> buffer head and tail logic in favour of the use of macros defined
> in linux circ_buf.h header. It also review internal names and adds
> a new CIRC_INC macro to make code more readable. Note also that
> CIRC_INC does not need to go inside do-while(0) block because its
> use is only located in the four functions that make use of it 
> so it won't expand into invalid code at all.
> 
> Signed-off-by: Sergio Paracuellos 
> ---
>  drivers/staging/ks7010/ks7010_sdio.c | 59 
> ++--
>  1 file changed, 36 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/staging/ks7010/ks7010_sdio.c 
> b/drivers/staging/ks7010/ks7010_sdio.c
> index 9c591e0..9676902 100644
> --- a/drivers/staging/ks7010/ks7010_sdio.c
> +++ b/drivers/staging/ks7010/ks7010_sdio.c
> @@ -10,6 +10,7 @@
>   *   published by the Free Software Foundation.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -101,38 +102,50 @@ enum gen_com_reg_b {
>  
>  #define KS7010_IO_BLOCK_SIZE 512
>  
> +#define CIRC_INC(a, b) if (++a >= b) a = 0

I don't like this macro.  If we're going to call it CIRC_INC() then it
needs to be included in include/linux/circ_buf.h and not here.  I don't
like that the argument is  "b" instead of "size" or something.  It
should be wrapped in a do { } while(0).  There should be parens around
"a" and "b" so I don't have to think about precedence bugs.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 01/13] dt-bindings: connector: add properties for typec

2018-04-13 Thread Jun Li 
2018-04-03 16:29 GMT+08:00 Andrzej Hajda :
>
> On 28.03.2018 18:06, Li Jun wrote:
> > Add bingdings supported by current typec driver, so user can pass
> > all those properties via dt.
> >
> > Signed-off-by: Li Jun 
> > ---
> >  .../bindings/connector/usb-connector.txt   | 39 
> > ++
> >  1 file changed, 39 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
> > b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > index e1463f1..922f22b 100644
> > --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > @@ -15,6 +15,29 @@ Optional properties:
> >  - type: size of the connector, should be specified in case of USB-A, USB-B
> >non-fullsize connectors: "mini", "micro".
> >
> > +Optional properties for usb-c-connector:
> > +- power-type: should be one of "source", "sink" or "dual"(DRP) if typec
> > +  connector has power support.
> > +- try-power-role: preferred power role if "dual"(DRP) can support Try.SNK
> > +  or Try.SRC, should be "sink" for Try.SNK or "source" for Try.SRC.
> > +- data-type: should be one of "host", "device", "dual"(DRD) if typec
> > +  connector supports USB data.
> > +
> > +Required properties for usb-c-connector with power delivery support:
> > +- source-pdos: An array of u32 with each entry providing supported power
> > +  source data object(PDO), the detailed bit definitions of PDO can be found
> > +  in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
> > +  Source_Capabilities Message, the order of each entry(PDO) should follow
> > +  the PD spec chapter 6.4.1. Required for power source and power dual role.
> > +- sink-pdos: An array of u32 with each entry providing supported power
> > +  sink data object(PDO), the detailed bit definitions of PDO can be found
> > +  in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3
> > +  Sink Capabilities Message, the order of each entry(PDO) should follow
> > +  the PD spec chapter 6.4.1. Required for power sink and power dual role.
> > +- op-sink-microwatt-hours: Sink required operating power in micro
> > +  watt-hours, if source offered power is less then it, Capability Mismatch
> > +  is set, required for power sink and power dual role.
>
> I have lurked into specs and I am not sure what is the relation of this
> field with PD protocol, there is Minimum Operating Power, Maximum
> Operating Power and Operating Power present in different RDOs, there are
> also similar fields in sink PDOs.
> I guess it can be one of them, which one?

Per current usage of op-sink-microwatt(operating_snk_mw in tcpm),
this property is actually for max operating power, which is only used to
judge capability mismatch, i.e. the required max current/power is larger
than the selected source PDO can provide.

After checking the PD spec about this, basically I think this property also
can be removed, we can judge the capability mismatch by compare the
selected source pdo and sink pdo, considering there are existing users
of this field(operating_snk_mw in tcpm), I will check how this can be done.

I am removing the other 3 max_snk_*, see [1]

[1] https://www.spinics.net/lists/linux-usb/msg167262.html

> why other ones are not
> provided? What if this or any other property can be calculated only in
> runtime?
> I am not sure if any of them should be marked "required".
>
> > +
> >  Required nodes:
> >  - any data bus to the connector should be modeled using the OF graph 
> > bindings
> >specified in bindings/graph.txt, unless the bus is between parent node 
> > and
> > @@ -73,3 +96,19 @@ ccic: s2mm005@33 {
> >   };
> >   };
> >  };
> > +
> > +3. USB-C connector attached to a typec port controller(ptn5110), which has
> > +power delivery support and enables drp.
> > +
> > +typec: ptn5110@50 {
> > + ...
> > + usb_con: connector {
> > + compatible = "usb-c-connector";
> > + label = "USB-C";
> > + power-type = "dual";
> > + try-power-role = "sink";
> > + source-pdos = <0x380190c8>;
>
> I understand from DT specification point of view cryptic numbers are OK,
> but for sake of readability I strongly suggest use/define macros similar
> to the ones present already in kernel:
> source-pdos = < PDO_FIXED(5000, 400, PDO_FIXED_FLAGS) >;

I agree it's easier to read, so with the proposed way, we need maintain
a copy of those macros for dts(e.g. under dt-binding/usb/pd.h), right?

thanks
Jun
>
> It much less error prone, and makes review process much more easier.
>
> Regards
> Andrzej
>
> > + sink-pdos = <0x380190c8 0x3802d0c8>;
> > + op-sink-microwatt-hours = <900>;
> > + };
> > +};
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org