[PATCH 6/13] scsi: arcmsr: replace constant ARCMSR_MAX_OUTSTANDING_CMD by variable acb->maxOutstanding that was determined by user

[Ching Huang]

From: Ching Huang 

replace constant ARCMSR_MAX_OUTSTANDING_CMD by variable acb->maxOutstanding 
that was determined by user

Signed-off-by: Ching Huang 
---

diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c  2017-11-08 18:51:20.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c  2017-11-08 18:52:04.0 +0800
@@ -1319,7 +1319,7 @@ static void arcmsr_done4abort_postqueue(
/*clear and abort all outbound posted Q*/
writel(outbound_intstatus, >outbound_intstatus);/*clear 
interrupt*/
while(((flag_ccb = readl(>outbound_queueport)) != 
0x)
-   && (i++ < ARCMSR_MAX_OUTSTANDING_CMD)) {
+   && (i++ < acb->maxOutstanding)) {
pARCMSR_CDB = (struct ARCMSR_CDB *)(acb->vir2phy_offset 
+ (flag_ccb << 5));/*frame must be 32 bytes aligned*/
pCCB = container_of(pARCMSR_CDB, struct 
CommandControlBlock, arcmsr_cdb);
error = (flag_ccb & ARCMSR_CCBREPLY_FLAG_ERROR_MODE0) ? 
true : false;
@@ -1349,7 +1349,7 @@ static void arcmsr_done4abort_postqueue(
break;
case ACB_ADAPTER_TYPE_C: {
struct MessageUnit_C __iomem *reg = acb->pmuC;
-   while ((readl(>host_int_status) & 
ARCMSR_HBCMU_OUTBOUND_POSTQUEUE_ISR) && (i++ < ARCMSR_MAX_OUTSTANDING_CMD)) {
+   while ((readl(>host_int_status) & 
ARCMSR_HBCMU_OUTBOUND_POSTQUEUE_ISR) && (i++ < acb->maxOutstanding)) {
/*need to do*/
flag_ccb = readl(>outbound_queueport_low);
ccb_cdb_phy = (flag_ccb & 0xFFF0);
@@ -1425,7 +1425,7 @@ static void arcmsr_remove(struct pci_dev
acb->acb_flags |= ACB_F_SCSISTOPADAPTER;
acb->acb_flags &= ~ACB_F_IOP_INITED;
 
-   for (poll_count = 0; poll_count < ARCMSR_MAX_OUTSTANDING_CMD; 
poll_count++){
+   for (poll_count = 0; poll_count < acb->maxOutstanding; poll_count++){
if (!atomic_read(>ccboutstandingcount))
break;
arcmsr_interrupt(acb);/* FIXME: need spinlock */

[PATCH] staging: ccree: remove unused pointer cc_base

[Colin King]

From: Colin Ian King 

Pointer cc_base is being assigned but is never read, hence it is
redundant and can be removed. Cleans up clang warning:

drivers/staging/ccree/ssi_driver.c:235:2: warning: Value stored to
'cc_base' is never read

Signed-off-by: Colin Ian King 
---
 drivers/staging/ccree/ssi_driver.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/ccree/ssi_driver.c 
b/drivers/staging/ccree/ssi_driver.c
index 1a3c481fa92a..f4c0af8047e4 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -199,7 +199,6 @@ int init_cc_regs(struct ssi_drvdata *drvdata, bool is_probe)
 static int init_cc_resources(struct platform_device *plat_dev)
 {
struct resource *req_mem_cc_regs = NULL;
-   void __iomem *cc_base = NULL;
struct ssi_drvdata *new_drvdata;
struct device *dev = _dev->dev;
struct device_node *np = dev->of_node;
@@ -232,8 +231,6 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
dev_dbg(dev, "CC registers mapped from %pa to 0x%p\n",
_mem_cc_regs->start, new_drvdata->cc_base);
 
-   cc_base = new_drvdata->cc_base;
-
/* Then IRQ */
new_drvdata->irq = platform_get_irq(plat_dev, 0);
if (new_drvdata->irq < 0) {
-- 
2.14.1

Re: [GIT PULL] perf fixes

[Markus Trippelsdorf]

On 2017.11.05 at 15:40 +0100, Ingo Molnar wrote:
> Linus,
>
> Please pull the latest perf-urgent-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> perf-urgent-for-linus
>
> Jiri Olsa (1):
>   perf tools: Unwind properly location after REJECT

The patch above breaks the build for me:

util/parse-events.l: In function ‘parse_events_lex’:
util/parse-events-flex.c:4722:16: error: ‘reject_used_but_not_detected’ 
undeclared (first use in this function)
  */
^
util/parse-events.l:159:2: note: in expansion of macro ‘REJECT’
  REJECT
  ^~
util/parse-events.l:343:26: note: in expansion of macro ‘USER_REJECT’
 {bpf_source}  { if (!isbpf(yyscanner)) USER_REJECT; return str(yyscanner, 
PE_BPF_SOURCE); }
  ^~~
util/parse-events-flex.c:4722:16: note: each undeclared identifier is reported 
only once for each function it appears in
  */
^
util/parse-events.l:159:2: note: in expansion of macro ‘REJECT’
  REJECT
  ^~
util/parse-events.l:343:26: note: in expansion of macro ‘USER_REJECT’
 {bpf_source}  { if (!isbpf(yyscanner)) USER_REJECT; return str(yyscanner, 
PE_BPF_SOURCE); }
  ^~~
mv: cannot stat 'util/.parse-events-flex.o.tmp': No such file or directory

--
Markus

Re: [PATCH] ARM: dts: add phy-reset property for rk3066a-rayeager emac

[Roger Quadros]

On 08/11/17 11:49, Chris Zhong wrote:
> Hi Florian Fainelli
> 
> 
> On 2017年11月08日 02:26, Florian Fainelli wrote:
>> On 11/07/2017 01:51 AM, Chris Zhong wrote:
>>>
>>> On 2017年11月07日 15:54, Vladimir Zapolskiy wrote:
 Hello Chris,

 On 11/07/2017 04:49 AM, Chris Zhong wrote:
> The ethernet phy of rk3066a-rayeager has a reset pin, it controlled by
> GPIO1_D6, this pin should be pull down then pull up to reset the phy.
> Add a phy-reset property in emac, make the phy can be reset when emac
> power on.
 for PHY reset there are properties 'reset-gpios' and 'reset-delay-us',
 please reference to Documentation/devicetree/bindings/net/mdio.txt

 Can you try to reuse them instead of adding new custom properties?
>>> This phy-reset is from Documentation/devicetree/bindings/net/arc_emac.txt.
>>> And copy from arch/arm/boot/dts/rk3036-kylin.dts.
>>> Can we just use these properties, they are not new.
>> Because it already exists does not mean it's correct, in fact, it is not
>> at all because it places the reset property for a PHY into the MAC node,
>> which is just not what this is, what we should be using instead is the
>> following patch series:
>>
>> http://patchwork.ozlabs.org/project/netdev/list/?series=9267
>>
>> http://patchwork.ozlabs.org/patch/828499/
>> http://patchwork.ozlabs.org/patch/828505/
>> http://patchwork.ozlabs.org/patch/828501/
>> http://patchwork.ozlabs.org/patch/828502/
> Okay, this series works for me, and I will push a new version patch following 
> it,
> with a reset-gpios property under phy node.
> And hope this series can be applied soon.
> 

If 'reset-gpios' and 'reset-delay-us' as per [1] works for you
then why not use that?

[1] Documentation/devicetree/bindings/net/mdio.txt

> Thanks
> Chris Zhong
> 
> 
 As a side question, which is mainly addressed to Sergei and Roger,
 I don't quite understand why PHY properties were initially added to
 MAC/MDIO bus device tree nodes, in my opinion they must be moved under
 PHY device tree nodes.

 -- 
 With best wishes,
 Vladimir

> Signed-off-by: Chris Zhong 
> ---
>
>    arch/arm/boot/dts/rk3066a-rayeager.dts | 2 ++
>    1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3066a-rayeager.dts
> b/arch/arm/boot/dts/rk3066a-rayeager.dts
> index 570157f..6064a0a 100644
> --- a/arch/arm/boot/dts/rk3066a-rayeager.dts
> +++ b/arch/arm/boot/dts/rk3066a-rayeager.dts
> @@ -173,6 +173,8 @@
>    pinctrl-0 = <_xfer>, <_mdio>, <_rst>;
>    phy = <>;
>    phy-supply = <_rmii>;
> +    phy-reset-gpios = < RK_PD6 GPIO_ACTIVE_LOW>; /* PHY_RST */
> +    phy-reset-duration = <10>; /* millisecond */
>    status = "okay";
>  phy0: ethernet-phy@0 {
>

>>
> 

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

[PATCH 13/13] scsi: arcmsr: update driver version to v1.40.00.02-20171011

[Ching Huang]

From: Ching Huang 

update driver version to v1.40.00.02-20171011

Signed-off-by: Ching Huang 
---

diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h  2017-11-07 17:29:10.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h  2017-11-07 17:50:06.0 +0800
@@ -54,7 +54,7 @@ struct device_attribute;
 #endif
 #define ARCMSR_DEFAULT_OUTSTANDING_CMD 128
 #define ARCMSR_MIN_OUTSTANDING_CMD 32
-#define ARCMSR_DRIVER_VERSION  "v1.30.00.22-20151126"
+#define ARCMSR_DRIVER_VERSION  "v1.40.00.02-20171011"
 #define ARCMSR_SCSI_INITIATOR_ID   255
 #define ARCMSR_MAX_XFER_SECTORS512
 #define ARCMSR_MAX_XFER_SECTORS_B  4096

[PATCH v2 2/2] ARM: sun8i: bananapi-m3: Enable dwmac-sun8i

[Corentin Labbe]

The dwmac-sun8i hardware is present on the bananapi m3
It uses an external PHY rtl8211e via RGMII.

This patch create the needed emac and phy nodes.

Signed-off-by: Corentin Labbe 
---
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts 
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index c606af3dbfed..45bdd5c17829 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -52,6 +52,7 @@
compatible = "sinovoip,bpi-m3", "allwinner,sun8i-a83t";
 
aliases {
+   ethernet0 = 
serial0 = 
};
 
@@ -88,6 +89,23 @@
/* TODO GL830 USB-to-SATA bridge downstream w/ GPIO power controls */
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgmii_pins>;
+   phy-handle = <_rgmii_phy>;
+   phy-mode = "rgmii";
+   allwinner,rx-delay-ps = <700>;
+   allwinner,tx-delay-ps = <700>;
+
+   status = "okay";
+};
+
+ {
+   ext_rgmii_phy: ethernet-phy@1 {
+   reg = <1>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-- 
2.13.6

Re: [PATCH V3 2/2] acpi: apei: call into AER handling regardless of severity

[Borislav Petkov]

On Wed, Nov 08, 2017 at 12:13:12PM -0700, Tyler Baicar wrote:
> Currently the GHES code only calls into the AER driver for
> recoverable type errors. This is incorrect because errors of
> other severities do not get logged by the AER driver and do not
> get exposed to user space via the AER trace event. So, call
> into the AER driver for PCIe errors regardless of the severity
> 
> Signed-off-by: Tyler Baicar 
> ---
>  drivers/acpi/apei/ghes.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 839c3d5..bb65fa6 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -458,14 +458,12 @@ static void ghes_handle_memory_failure(struct 
> acpi_hest_generic_data *gdata, int
>  #endif
>  }

Where did the explanatory comment go?

+/*
+ * PCIe AER errors need to be sent to the AER driver for reporting and
+ * recovery. The GHES severities map to the following AER severities and
+ * require the following handling:
+ *
+ * GHES_SEV_CORRECTABLE -> AER_CORRECTABLE
+ * These need to be reported by the AER driver but no recovery is
+ * necessary.
+ * GHES_SEV_RECOVERABLE -> AER_NONFATAL
+ * GHES_SEV_RECOVERABLE && CPER_SEC_RESET -> AER_FATAL
+ * These both need to be reported and recovered from by the AER driver.
+ * GHES_SEV_PANIC does not make it to this handling since the kernel must
+ * panic.
+ */

<--- ???

> -static void ghes_handle_aer(struct acpi_hest_generic_data *gdata, int sev, 
> int sec_sev)
> +static void ghes_handle_aer(struct acpi_hest_generic_data *gdata)
>  {
>  #ifdef CONFIG_ACPI_APEI_PCIEAER
>   struct cper_sec_pcie *pcie_err = acpi_hest_get_payload(gdata);
>  
> - if (sev == GHES_SEV_RECOVERABLE &&
> - sec_sev == GHES_SEV_RECOVERABLE &&
> - pcie_err->validation_bits & CPER_PCIE_VALID_DEVICE_ID &&
> + if (pcie_err->validation_bits & CPER_PCIE_VALID_DEVICE_ID &&
>   pcie_err->validation_bits & CPER_PCIE_VALID_AER_INFO) {
>   unsigned int devfn;
>   int aer_severity;
> @@ -519,7 +517,7 @@ static void ghes_do_proc(struct ghes *ghes,
>   ghes_handle_memory_failure(gdata, sev);
>   }
>   else if (guid_equal(sec_type, _SEC_PCIE)) {
> - ghes_handle_aer(gdata, sev, sec_sev);
> + ghes_handle_aer(gdata);
>   }
>   else if (guid_equal(sec_type, _SEC_PROC_ARM)) {
>   struct cper_sec_proc_arm *err = 
> acpi_hest_get_payload(gdata);
> -- 

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH 1/2] sched/swait: allow swake_up() to return

[Paolo Bonzini]

On 09/11/2017 10:18, Peter Xu wrote:
> Let swake_up() to return whether any of the waiters is waked up. One use
> case of it would be:
> 
>   if (swait_active(wq)) {
> swake_up(wq);
> // do something when waiter is waked up
> waked_up++;
>   }
> 
> Logically it's possible that when reaching swake_up() the wait queue is
> not active any more, and here doing something like waked_up++ would be
> inaccurate.  To correct it, we need an atomic version of it.
> 
> With this patch, we can simply re-write it into:
> 
>   if (swake_up(wq)) {
> // do something when waiter is waked up
> waked_up++;
>   }
> 
> After all we are checking swait_active() inside swake_up() too.

Better subject:

sched/swait: make swake_up() return whether there were any waiters

I like this patch.

> 
> CC: Ingo Molnar 
> CC: Peter Zijlstra 
> CC: Peter Xu 
> CC: linux-kernel@vger.kernel.org
> Signed-off-by: Peter Xu 
> ---
>  include/linux/swait.h |  4 ++--
>  kernel/sched/swait.c  | 21 -
>  2 files changed, 18 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/swait.h b/include/linux/swait.h
> index c1f9c62a8a50..c55171280ac8 100644
> --- a/include/linux/swait.h
> +++ b/include/linux/swait.h
> @@ -84,9 +84,9 @@ static inline int swait_active(struct swait_queue_head *q)
>   return !list_empty(>task_list);
>  }
>  
> -extern void swake_up(struct swait_queue_head *q);
> +extern bool swake_up(struct swait_queue_head *q);
>  extern void swake_up_all(struct swait_queue_head *q);
> -extern void swake_up_locked(struct swait_queue_head *q);
> +extern bool swake_up_locked(struct swait_queue_head *q);
>  
>  extern void __prepare_to_swait(struct swait_queue_head *q, struct 
> swait_queue *wait);
>  extern void prepare_to_swait(struct swait_queue_head *q, struct swait_queue 
> *wait, int state);
> diff --git a/kernel/sched/swait.c b/kernel/sched/swait.c
> index 3d5610dcce11..31f8d677c690 100644
> --- a/kernel/sched/swait.c
> +++ b/kernel/sched/swait.c
> @@ -16,29 +16,40 @@ EXPORT_SYMBOL(__init_swait_queue_head);
>   * If for some reason it would return 0, that means the previously waiting
>   * task is already running, so it will observe condition true (or has 
> already).
>   */
> -void swake_up_locked(struct swait_queue_head *q)
> +bool swake_up_locked(struct swait_queue_head *q)
>  {
>   struct swait_queue *curr;
>  
>   if (list_empty(>task_list))
> - return;
> + return false;
>  
>   curr = list_first_entry(>task_list, typeof(*curr), task_list);
>   wake_up_process(curr->task);
>   list_del_init(>task_list);
> + return true;
>  }
>  EXPORT_SYMBOL(swake_up_locked);
>  
> -void swake_up(struct swait_queue_head *q)
> +/**
> + * swake_up - Wake up one process on the waiting list
> + * @q:the waitqueue to wake up
> + *
> + * Returns true if some process is waked up, otherwise false if there
> + * is no waiter to wake up.
> + */
> +bool swake_up(struct swait_queue_head *q)
>  {
> + bool ret;
>   unsigned long flags;
>  
>   if (!swait_active(q))
> - return;
> + return false;
>  
>   raw_spin_lock_irqsave(>lock, flags);
> - swake_up_locked(q);
> + ret = swake_up_locked(q);
>   raw_spin_unlock_irqrestore(>lock, flags);
> +
> + return ret;
>  }
>  EXPORT_SYMBOL(swake_up);
>  
> 

Re: [PATCH v10 5/7] perf: cavium: Support memory controller PMU counters

[Suzuki K Poulose]

On 25/09/17 13:35, Jan Glauber wrote:

Add support for the PMU counters on Cavium SOC memory controllers.

This patch also adds generic functions to allow supporting more
devices with PMU counters.

Properties of the LMC PMU counters:
- not stoppable
- fixed purpose
- read-only
- one PCI device per memory controller

Signed-off-by: Jan Glauber 
---
  drivers/perf/Kconfig|   8 +
  drivers/perf/Makefile   |   1 +
  drivers/perf/cavium_pmu.c   | 430 
  drivers/soc/cavium/cavium_lmc.c |   4 +
  include/linux/cpuhotplug.h  |   1 +
  include/linux/soc/cavium/lmc.h  |   3 +
  6 files changed, 447 insertions(+)
  create mode 100644 drivers/perf/cavium_pmu.c



+int cvm_lmc_pmu_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
+{
+   struct cvm_pmu_dev *next, *lmc;
+   int nr = 0, ret = -ENOMEM;
+   char *name;
+
+   lmc = devm_kzalloc(>dev, sizeof(*lmc), GFP_KERNEL);
+   if (!lmc)
+   return -ENOMEM;
+
+   lmc->map = devm_ioremap(>dev, pci_resource_start(pdev, 0),
+   pci_resource_len(pdev, 0));
+   if (!lmc->map)
+   return -EINVAL;
+
+   list_for_each_entry(next, _pmu_lmcs, entry)
+   nr++;
+   name = devm_kasprintf(>dev, GFP_KERNEL, "lmc%d", nr);
+   if (!name)
+   return -ENOMEM;
+
+   lmc->pdev = pdev;
+   lmc->num_counters = ARRAY_SIZE(cvm_pmu_lmc_events_attr) - 1;
+   lmc->pmu = (struct pmu) {
+   .task_ctx_nr= perf_invalid_context,
+   .name   = name,
+   .event_init = cvm_pmu_event_init,
+   .add= cvm_pmu_lmc_add,
+   .del= cvm_pmu_del,
+   .start  = cvm_pmu_start,
+   .stop   = cvm_pmu_stop,
+   .read   = cvm_pmu_read,
+   .attr_groups= cvm_pmu_lmc_attr_groups,
+   };
+


You need to fill in the "module" field of the PMU to prevent the module from
being unloaded while the PMU is active.

See :

http://lists.infradead.org/pipermail/linux-arm-kernel/2017-November/540647.html

Suzuki

Re: [PATCH 25/31] nds32: defconfig

[Arnd Bergmann]

On Thu, Nov 9, 2017 at 9:00 AM, Greentime Hu  wrote:
> 2017-11-08 18:03 GMT+08:00 Arnd Bergmann :
>> On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu  wrote:
>>> From: Greentime Hu 
>>>
>>> Signed-off-by: Vincent Chen 
>>> Signed-off-by: Greentime Hu 
>>> ---
>>>  arch/nds32/configs/ae3xx_defconfig  |  110 
>>> +++
>>>  arch/nds32/configs/ag101p_defconfig |  109 
>>> ++
>>
>> Are those two incompatible? I would recommend starting without board
>> specific defconfig
>> files, it just gets messy once you get more than a few machines you
>> want to support.
>
> Thanks.
> These 2 are incompatible.
> They use different drivers. I may still keep these 2 defconfigs.

Using different drivers doesn't make machines incompatible. For instance, the
x86 desktop machine has drivers for all kinds of devices, but it uses
one configuration
that works on basically any x86 machine.

Similarly, we only have one defconfig file on arm64, and it works across very
diverse machines (phone, home routers, large servers, etc.).

All drivers should be written in a way to allow being built into the
kernel without
doing any harm when you don't have the respective hardware.

>>> +CONFIG_FB=y
>>> +# CONFIG_VGA_CONSOLE is not set
>>> +CONFIG_FRAMEBUFFER_CONSOLE=y
>>
>> You have a framebuffer console here, but no framebuffer driver?
>
> Thanks.
> I shall enable it when I push our framebuffer in the next time.
> I will disable it in the next version patch.

The fbdev subsystem is no longer recommended for new drivers, they
should be written on top of the DRM framework. You can use
CONFIG_DRM_FBDEV_EMULATION to get the framebuffer
console on top of that, but then you don't need to enable CONFIG_FB.

Please have a look at drivers/gpu/drm/tinydrm/ to see if you can either
use that directly, or take it as a skeleton for your own driver.

   Arnd

[tip:x86/asm] x86/build: Make the boot image generation less verbose

[tip-bot for Changbin Du]

Commit-ID:  7980f029d05d8a3b4634aa6952e1ec51bce9431f
Gitweb: https://git.kernel.org/tip/7980f029d05d8a3b4634aa6952e1ec51bce9431f
Author: Changbin Du 
AuthorDate: Thu, 9 Nov 2017 14:09:11 +0800
Committer:  Ingo Molnar 
CommitDate: Thu, 9 Nov 2017 07:34:57 +0100

x86/build: Make the boot image generation less verbose

This change suppresses the 'dd' output and adds the '-quiet' parameter
to mkisofs tool. It also removes the 'Using ...' messages, as none of the
messages matter to the user normally.

"make V=1" can still be used for a more verbose build.

The new build messages are now a streamlined set of:

  $ make isoimage
  ...
  Kernel: arch/x86/boot/bzImage is ready  (#75)
GENIMAGE arch/x86/boot/image.iso
  Kernel: arch/x86/boot/image.iso is ready

Signed-off-by: Changbin Du 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1510207751-22166-1-git-send-email-changbin...@intel.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/boot/genimage.sh | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/x86/boot/genimage.sh b/arch/x86/boot/genimage.sh
index 628e936..49f4970 100644
--- a/arch/x86/boot/genimage.sh
+++ b/arch/x86/boot/genimage.sh
@@ -19,6 +19,13 @@
 #   $6 - inird image file
 #
 
+# Use "make V=1" to debug this script
+case "${KBUILD_VERBOSE}" in
+*1*)
+set -x
+;;
+esac
+
 verify () {
if [ ! -f "$1" ]; then
echo ""   1>&2
@@ -50,7 +57,7 @@ genbzdisk() {
 }
 
 genfdimage144() {
-   dd if=/dev/zero of=$FIMAGE bs=1024 count=1440
+   dd if=/dev/zero of=$FIMAGE bs=1024 count=1440 2> /dev/null
mformat v:
syslinux $FIMAGE
echo "$KCMDLINE" | mcopy - v:syslinux.cfg
@@ -61,7 +68,7 @@ genfdimage144() {
 }
 
 genfdimage288() {
-   dd if=/dev/zero of=$FIMAGE bs=1024 count=2880
+   dd if=/dev/zero of=$FIMAGE bs=1024 count=2880 2> /dev/null
mformat w:
syslinux $FIMAGE
echo "$KCMDLINE" | mcopy - W:syslinux.cfg
@@ -79,14 +86,12 @@ genisoimage() {
for j in syslinux ISOLINUX ; do
if [ -f /usr/$i/$j/isolinux.bin ] ; then
isolinux=/usr/$i/$j/isolinux.bin
-   echo "Using $isolinux"
cp $isolinux $tmp_dir
fi
done
for j in syslinux syslinux/modules/bios ; do
if [ -f /usr/$i/$j/ldlinux.c32 ]; then
ldlinux=/usr/$i/$j/ldlinux.c32
-   echo "Using $ldlinux"
cp $ldlinux $tmp_dir
fi
done
@@ -103,7 +108,7 @@ genisoimage() {
if [ -f "$FDINITRD" ] ; then
cp "$FDINITRD" $tmp_dir/initrd.img
fi
-   mkisofs -J -r -input-charset=utf-8 -o $FIMAGE -b isolinux.bin \
+   mkisofs -J -r -input-charset=utf-8 -quiet -o $FIMAGE -b isolinux.bin \
-c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table \
$tmp_dir
isohybrid $FIMAGE 2>/dev/null || true

[tip:sched/core] sched/core: Optimize sched_feat() for !CONFIG_SCHED_DEBUG builds

[tip-bot for Patrick Bellasi]

Commit-ID:  765cc3a4b224e22bf524fabe40284a524f37cdd0
Gitweb: https://git.kernel.org/tip/765cc3a4b224e22bf524fabe40284a524f37cdd0
Author: Patrick Bellasi 
AuthorDate: Wed, 8 Nov 2017 18:41:01 +
Committer:  Ingo Molnar 
CommitDate: Thu, 9 Nov 2017 07:35:08 +0100

sched/core: Optimize sched_feat() for !CONFIG_SCHED_DEBUG builds

When the kernel is compiled with !CONFIG_SCHED_DEBUG support, we expect that
all SCHED_FEAT are turned into compile time constants being propagated
to support compiler optimizations.

Specifically, we expect that code blocks like this:

   if (sched_feat(FEATURE_NAME) [&& ]) {
/* FEATURE CODE */
   }

are turned into dead-code in case FEATURE_NAME defaults to FALSE, and thus
being removed by the compiler from the finale image.

For this mechanism to properly work it's required for the compiler to
have full access, from each translation unit, to whatever is the value
defined by the sched_feat macro. This macro is defined as:

   #define sched_feat(x) (sysctl_sched_features & (1UL << __SCHED_FEAT_##x))

and thus, the compiler can optimize that code only if the value of
sysctl_sched_features is visible within each translation unit.

Since:

   029632fbb ("sched: Make separate sched*.c translation units")

the scheduler code has been split into separate translation units
however the definition of sysctl_sched_features is part of
kernel/sched/core.c while, for all the other scheduler modules, it is
visible only via kernel/sched/sched.h as an:

   extern const_debug unsigned int sysctl_sched_features

Unfortunately, an extern reference does not allow the compiler to apply
constants propagation. Thus, on !CONFIG_SCHED_DEBUG kernel we still end up
with code to load a memory reference and (eventually) doing an unconditional
jump of a chunk of code.

This mechanism is unavoidable when sched_features can be turned on and off at
run-time. However, this is not the case for "production" kernels compiled with
!CONFIG_SCHED_DEBUG. In this case, sysctl_sched_features is just a constant 
value
which cannot be changed at run-time and thus memory loads and jumps can be
avoided altogether.

This patch fixes the case of !CONFIG_SCHED_DEBUG kernel by declaring a local 
version
of the sysctl_sched_features constant for each translation unit. This will
ultimately allow the compiler to perform constants propagation and dead-code
pruning.

Tests have been done, with !CONFIG_SCHED_DEBUG on a v4.14-rc8 with and without
the patch, by running 30 iterations of:

   perf bench sched messaging --pipe --thread --group 4 --loop 5

on a 40 cores Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz using the
powersave governor to rule out variations due to frequency scaling.

Statistics on the reported completion time:

   count mean   std min   99% max
  v4.14-rc8 30.0  15.7831  0.176032  15.442  16.01226  16.014
  v4.14-rc8+patch   30.0  15.5033  0.189681  15.232  15.93938  15.962

... show a 1.8% speedup on average completion time and 0.5% speedup in the
99 percentile.

Signed-off-by: Patrick Bellasi 
Signed-off-by: Chris Redpath 
Reviewed-by: Dietmar Eggemann 
Reviewed-by: Brendan Jackman 
Acked-by: Peter Zijlstra 
Cc: Juri Lelli 
Cc: Linus Torvalds 
Cc: Morten Rasmussen 
Cc: Thomas Gleixner 
Cc: Vincent Guittot 
Link: http://lkml.kernel.org/r/20171108184101.16006-1-patrick.bell...@arm.com
Signed-off-by: Ingo Molnar 
---
 kernel/sched/core.c  |  9 ++---
 kernel/sched/sched.h | 25 ++---
 2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 1a55c84..a39a081 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -43,18 +43,21 @@
 
 DEFINE_PER_CPU_SHARED_ALIGNED(struct rq, runqueues);
 
+#if defined(CONFIG_SCHED_DEBUG) && defined(HAVE_JUMP_LABEL)
 /*
  * Debugging: various feature bits
+ *
+ * If SCHED_DEBUG is disabled, each compilation unit has its own copy of
+ * sysctl_sched_features, defined in sched.h, to allow constants propagation
+ * at compile time and compiler optimization based on features default.
  */
-
 #define SCHED_FEAT(name, enabled)  \
(1UL << __SCHED_FEAT_##name) * enabled |
-
 const_debug unsigned int sysctl_sched_features =
 #include "features.h"
0;
-
 #undef SCHED_FEAT
+#endif
 
 /*
  * Number of tasks to iterate in a single balance run.
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 58787e3..45ab0bf 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1233,8 +1233,6 @@ static inline void __set_task_cpu(struct task_struct *p, 
unsigned int cpu)
 # define const_debug const
 #endif
 
-extern const_debug 

Re: [PATCH V13 03/10] mmc: block: Add blk-mq support

[Adrian Hunter]

On 08/11/17 10:54, Linus Walleij wrote:
> On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter  wrote:
> 
>> Define and use a blk-mq queue. Discards and flushes are processed
>> synchronously, but reads and writes asynchronously. In order to support
>> slow DMA unmapping, DMA unmapping is not done until after the next request
>> is started. That means the request is not completed until then. If there is
>> no next request then the completion is done by queued work.
>>
>> Signed-off-by: Adrian Hunter 
> 
>> -   blk_end_request_all(req, ret ? BLK_STS_IOERR : BLK_STS_OK);
>> +   if (req->mq_ctx)
>> +   blk_mq_end_request(req, ret ? BLK_STS_IOERR : BLK_STS_OK);
>> +   else
>> +   blk_end_request_all(req, ret ? BLK_STS_IOERR : BLK_STS_OK);
> 
> I think this quite obvious code duplication is unfortunate.
> 
> What my patches do is get rid of the old block layer in order
> to be able to focus on the new stuff using just MQ.
> 
> One reason is that the code is hairy already as it is, by just
> supporting MQ the above is still just one line of code, the same
> goes for the other instances below.
> 
> At least you could do what I did and break out a helper like
> this:
> 
> /*
>  * This reports status back to the block layer for a finished request.
>  */
> static void mmc_blk_complete(struct mmc_queue_req *mq_rq,
> blk_status_t status)
> {
>struct request *req = mmc_queue_req_to_req(mq_rq);
> 
>if (req->mq_ctx) {
>   blk_mq_end_request(req, status);
>} else
>   blk_end_request_all(req, status);
> }

You are quibbling.  It makes next to no difference especially as it all goes
away when the legacy code is deleted.  I will change it in the next
revision, but what a waste of everyone's time.  Please try to focus on
things that matter.

>> +/* Single sector read during recovery */
>> +static void mmc_blk_ss_read(struct mmc_queue *mq, struct request *req)
>> +{
>> +   struct mmc_queue_req *mqrq = req_to_mmc_queue_req(req);
>> +   blk_status_t status;
>> +
>> +   while (1) {
>> +   mmc_blk_rw_rq_prep(mqrq, mq->card, 1, mq);
>> +
>> +   mmc_wait_for_req(mq->card->host, >brq.mrq);
>> +
>> +   /*
>> +* Not expecting command errors, so just give up in that 
>> case.
>> +* If there are retries remaining, the request will get
>> +* requeued.
>> +*/
>> +   if (mqrq->brq.cmd.error)
>> +   return;
>> +
>> +   if (blk_rq_bytes(req) <= 512)
>> +   break;
>> +
>> +   status = mqrq->brq.data.error ? BLK_STS_IOERR : BLK_STS_OK;
>> +
>> +   blk_update_request(req, status, 512);
>> +   }
>> +
>> +   mqrq->retries = MMC_NO_RETRIES;
>> +}
>> +
>> +static void mmc_blk_rw_recovery(struct mmc_queue *mq, struct request *req)
>> +{
>> +   int type = rq_data_dir(req) == READ ? MMC_BLK_READ : MMC_BLK_WRITE;
>> +   struct mmc_queue_req *mqrq = req_to_mmc_queue_req(req);
>> +   struct mmc_blk_request *brq = >brq;
>> +   struct mmc_blk_data *md = mq->blkdata;
>> +   struct mmc_card *card = mq->card;
>> +   static enum mmc_blk_status status;
>> +
>> +   brq->retune_retry_done = mqrq->retries;
>> +
>> +   status = __mmc_blk_err_check(card, mqrq);
>> +
>> +   mmc_retune_release(card->host);
>> +
>> +   /*
>> +* Requests are completed by mmc_blk_mq_complete_rq() which sets 
>> simple
>> +* policy:
>> +* 1. A request that has transferred at least some data is considered
>> +* successful and will be requeued if there is remaining data to
>> +* transfer.
>> +* 2. Otherwise the number of retries is incremented and the request
>> +* will be requeued if there are remaining retries.
>> +* 3. Otherwise the request will be errored out.
>> +* That means mmc_blk_mq_complete_rq() is controlled by bytes_xfered 
>> and
>> +* mqrq->retries. So there are only 4 possible actions here:
>> +*  1. do not accept the bytes_xfered value i.e. set it to zero
>> +*  2. change mqrq->retries to determine the number of retries
>> +*  3. try to reset the card
>> +*  4. read one sector at a time
>> +*/
>> +   switch (status) {
>> +   case MMC_BLK_SUCCESS:
>> +   case MMC_BLK_PARTIAL:
>> +   /* Reset success, and accept bytes_xfered */
>> +   mmc_blk_reset_success(md, type);
>> +   break;
>> +   case MMC_BLK_CMD_ERR:
>> +   /*
>> +* For SD cards, get bytes written, but do not accept
>> +* bytes_xfered if that fails. For MMC cards accept
>> +* bytes_xfered. Then try to reset. If reset fails then
>> +* error out the remaining request, 

Re: [PATCH v2] USB: add SPDX identifiers to all remaining files in drivers/usb/

[Pavel Machek]

On Thu 2017-11-09 11:40:28, Greg Kroah-Hartman wrote:
> On Thu, Nov 09, 2017 at 10:51:48AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > It's good to have SPDX identifiers in all files to make it easier to
> > > audit the kernel tree for correct licenses.
> > > 
> > > Update the drivers/usb/ and include/linux/usb* files with the correct
> > > SPDX license identifier based on the license text in the file itself.
> > > The SPDX identifier is a legally binding shorthand, which can be used
> > > instead of the full boiler plate text.
> > > 
> > > This work is based on a script and data from Thomas Gleixner, Philippe
> > > Ombredanne, and Kate Stewart.
> > > 
> > > Cc: Thomas Gleixner 
> > > Cc: Kate Stewart 
> > > Cc: Philippe Ombredanne 
> > > Signed-off-by: Greg Kroah-Hartman 
> > > ---
> > > v2: Use the "standard" format of putting the identifier at the top of
> > > the file, and use // for .c and .h files.
> > > Removed the files already marked in Linus's tree.
> > > 
> > > Unless someone really complains, I'm going to add this to my tree for
> > > 4.15-rc1.
> > 
> > as you said in some other email... this stands out a bit too
> > much.
> 
> That is the goal, sorry.

Then it is bad goal.

Automated tools can pick it up whereever it is. No need to grab
attention with poor placing.

> > What about using normal c comments, and put it near the original
> > license text? It is not exactly the most important thing...
> > 
> > Or maybe near the MODULE_LICENSE, so the two don't get out of sync?
> 
> No, the top of the file is best, thanks.

No, it is not, thanks.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] soc: amlogic: meson-gx-pwrc-vpu: fix power-off when powered by bootloader

[Arnd Bergmann]

On Thu, Nov 9, 2017 at 1:50 AM, Kevin Hilman  wrote:
> Arnd, Olof,
>
> Neil Armstrong  writes:
>
>> In the case the VPU power domain has been powered on by the bootloader
>> and no driver are attached to this power domain, the genpd will power it
>> off after a certain amount of time, but the clocks hasn't been enabled
>> by the kernel itself and the power-off will trigger some faults.
>> This patch enable the clocks to have a coherent state for an eventual
>> poweroff and switches to the pm_domain_always_on_gov governor.
>>
>> Fixes: 75fcb5ca4b46 ("soc: amlogic: add Meson GX VPU Domains driver")
>> Signed-off-by: Neil Armstrong 
>
> Tested-by: Kevin Hilman 
>
> This fixes a patch that's currently in arm-soc next/drivers (or
> amlogic/drivers-2 to be precise.)
>
> If it's not too late, please feel free to apply directly.  If not, I
> will queue up for v4.15-rc fixes cycle.

Applied to next/drivers, thanks!

  Arnd

Re: [PATCH RFC v2 4/4] mm/mempolicy: add nodes_empty check in SYSC_migrate_pages

[Yisheng Xie]

Hi Christopher,

On 2017/11/8 23:02, Christopher Lameter wrote:
> On Wed, 8 Nov 2017, Yisheng Xie wrote:
> 
>> Another case is current process is *not* the same as target process, and
>> when current process try to migrate pages of target process from old_nodes
>> to new_nodes, the new_nodes should be a subset of target process cpuset.
> 
> The caller of migrate_pages should be able to migrate the target process
> pages anywhere the caller can allocate memory. If that is outside the
> target processes cpuset then that is fine. Pagecache pages that are not
> allocated by the target process already are not subject to the target
> processes restriction. So this is not that unusual.

So there is no need to check the restriction of target process cpuset, right?
I hope that I do not miss anything :)

Thanks
Yisheng Xie
> 
> .
> 

Re: [PATCH v10 13/18] x86/insn-eval: Add utility functions to get segment selector

[Arnd Bergmann]

On Fri, Oct 27, 2017 at 10:25 PM, Ricardo Neri
 wrote:

> diff --git a/arch/x86/include/asm/inat.h b/arch/x86/include/asm/inat.h
> index 02aff08..1c78580 100644
> --- a/arch/x86/include/asm/inat.h
> +++ b/arch/x86/include/asm/inat.h
> @@ -97,6 +97,16 @@
>  #define INAT_MAKE_GROUP(grp)   ((grp << INAT_GRP_OFFS) | INAT_MODRM)
>  #define INAT_MAKE_IMM(imm) (imm << INAT_IMM_OFFS)
>
> +/* Identifiers for segment registers */
> +#define INAT_SEG_REG_IGNORE0
> +#define INAT_SEG_REG_DEFAULT   1
> +#define INAT_SEG_REG_CS2
> +#define INAT_SEG_REG_SS3
> +#define INAT_SEG_REG_DS4
> +#define INAT_SEG_REG_ES5
> +#define INAT_SEG_REG_FS6
> +#define INAT_SEG_REG_GS7
> +

linux-next still reports a warning because of this change:

Warning: synced file at 'tools/objtool/arch/x86/include/asm/inat.h'
differs from latest kernel version at 'arch/x86/include/asm/inat.h'

Should the same change be applied to the objtool file in the
tip:x86/mpx branch?

   Arnd

Re: kernel BUG at net/key/af_key.c:LINE!

[Herbert Xu]

On Wed, Nov 08, 2017 at 08:59:15AM +0100, Dmitry Vyukov wrote:
>
> Also the repro needs to be compiled with -m32 (but it does not compile
> without it due to missing __NR_mmap2, so I guess you passed -m32).

OK that's what I was missing.  I had hacked it to compile in
64-bit :)

However, I still don't understand why it's crashing yet.  What is
clear is that we're getting a socket policy with xp->family set
to zero, and the policy is created via the xfrm code path (as
opposed to af_key).

The xfrm code path is meant to forbid the creation of such a policy.
I don't currently see how this is bypassing that check.  But
clearly it has found a way through the check since it's crashing.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v3 13/18] powerpc: Add support for setting SPRN_TIDR

[Michael Ellerman]

Sukadev Bhattiprolu  writes:

> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 37ed60b..d861fcd 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -1120,6 +1120,13 @@ static inline void restore_sprs(struct thread_struct 
> *old_thread,
>   mtspr(SPRN_TAR, new_thread->tar);
>   }
>  #endif
> +#ifdef CONFIG_PPC64
> + if (old_thread->tidr != new_thread->tidr) {
> + /* TIDR should be non-zero only with ISA3.0. */
> + WARN_ON_ONCE(!cpu_has_feature(CPU_FTR_ARCH_300));

This is silly, just make the whole block depend on CPU_FTR_ARCH_300.

I've fixed it up.

> @@ -1466,6 +1581,10 @@ int arch_dup_task_struct(struct task_struct *dst, 
> struct task_struct *src)
>  
>   clear_task_ebb(dst);
>  
> +#ifdef CONFIG_PPC64
> + dst->thread.tidr = 0;
> +#endif
> +
>   return 0;
>  }

This is called from clone().


> @@ -1576,6 +1695,9 @@ int copy_thread(unsigned long clone_flags, unsigned 
> long usp,
>  #endif
>  
>   setup_ksp_vsid(p, sp);
> +#ifdef CONFIG_PPC64
> + p->thread.tidr = 0;
> +#endif
  
And so is this.

So I think you only need the latter.

That does mean you're clearing the TIDR on fork(), but not exec().

Typically you'd do the reverse, ie. clear it on exec() but leave it the
same on fork().

Because this is a "thread id" I think it does make sense to clear it on
fork(), otherwise you potentially have two processes with the same id
and only one of them will be woken up by the AS_notify.

So I'll drop the clear from arch_dup_task_struct().

cheers

Re: [linux-sunxi] Re: [PATCH v2 00/10] Allwinner H3/H5/A64(DE2) SimpleFB support

[Maxime Ripard]

On Thu, Nov 09, 2017 at 11:17:03AM +, Chris Obbard wrote:
> Hi Everyone,
> 
> What's the status of HDMI/SimpleFB driver for H5?
> 
> I don't see anything related to HDMI in linux-next dts files:
> 
> arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts  (example board)
> arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> arch/arm/boot/dts/sunxi-h3-h5.dtsi

It will be part of 4.16 and are not in linux-next (yet).

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: Feature request - support kbd_backlight on Hewlett-Packard

[Andy Shevchenko]

+Cc: correct subsystem

On Thu, Nov 9, 2017 at 3:04 AM, kedar kedar  wrote:
> Hello,
>
> Can anyone please try add support for controlling keyboard backlight
> via sysfs on Hewlett-Packard notebooks?
> Maybe in a similar way as this last year patch for Thinkpad?
> https://lkml.org/lkml/2015/12/24/295
> BTW: This functionality is already supported (minimaly) on Apple,
> ASUS, Dell, Samsung, Sony, Thinkpad, Toshiba :-)

I dunno if my corporate windows laptop has this feature, though I
can't do anything in near future regarding to this, no time.

In any case it looks like HP stuff is kinda orphaned in PDx86
subsystem (just occasional fixes happen).

-- 
With Best Regards,
Andy Shevchenko

Re: [RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

[Zhengqiang]

On 2017/10/31 23:38, James Morse wrote:
> GHES is doing ioremap_page_range() in both NMI and irq context, neither
> are safe as it may sleep to allocate intermediate levels of page table.
> 
> Replace the NMI/irq GHES_IOREMAP_PAGES to use a fixmap entry each.
> 
> After this nothing uses ghes_ioremap_area or arch_apei_flush_tlb_one(),
> rip them out.
> 
> RFC as I've only build-tested this on x86. For arm64 I've tested it on a
> software model. Any more testing would be welcome. These patches are based
> on rc7.
> 


Tested-by:  Qiang Zheng 

Verified on our arm64, it work for me. Thanks.

Qiang

Re: WTF? Re: [PATCH] License cleanup: add SPDX GPL-2.0 license identifier to files with no license

[Greg Kroah-Hartman]

On Thu, Nov 09, 2017 at 10:47:04AM +1100, Dave Chinner wrote:
> On Tue, Nov 07, 2017 at 07:29:03PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Nov 07, 2017 at 09:20:42AM -0800, Darrick J. Wong wrote:
> > > On Tue, Nov 07, 2017 at 08:39:40AM +0100, Greg Kroah-Hartman wrote:
> > > > On Mon, Nov 06, 2017 at 11:20:40PM -0800, Christoph Hellwig wrote:
> > > > > NAK, for both the libxfs patch and the kernel one.
> > > > 
> > > > What libxfs patch?  And what "kernel one" are you referring to here?
> > > > 
> > > > > I wrote the file and it has no copyright header because it conatians
> > > > > trivial, non-copyrightable code.
> > > > 
> > > > What file exactly?
> > > > 
> > > > And from what I know, there is nothing that is "non-copyrightable".
> > > > 
> > > > And this isn't changing the copyright of _ANYTHING_ it is just putting
> > > > the explicit license of the file, on each file in the kernel, because it
> > > > needs to be tracked.
> > > > 
> > > > > I don't know why people think they can touch license information on
> > > > > files I've written without even asking me.
> > > > 
> > > > Nothing was changed, the license should be the exact same as it was
> > > > before.  But as I don't know what file you are referring to here, it's a
> > > > bit hard to determine what you are talking about exactly :(
> > > 
> > > fs/xfs/libxfs/xfs_cksum.h
> > 
> > Given that it had no license text on it at all, it "defaults" to GPLv2,
> > so the GPLv2 SPDX identifier was added to it.
> 
> I'll point out here that this file is shared with a userspace
> package that has a mixed LGPL/GPL code base, so even if we disregard
> what Christoph says, this file could actually be LGPL (like
> fs/xfs/libxfs/xfs_fs.h) and not GPL. So from that perspective alone,
> your process on deciding what license tag should be used is
> flawed and these changes needed, at minimum, maintainer review.
> 
> IMO, unannounced, unreviewed tree wide change via a back-door
> commits sent straight to Linus reek of an attempt to avoid review
> and oversight.

This was not unannounced, it was posted to lkml and discussed at the
kernel summit ahead of time.

> And that is *completely unacceptible* when making claims about
> important details like licenses for *code you do not know anything
> about*. 

When a file does not have a license, again, all lawyers I have worked
with said it is implicitly GPLv2, so we did the best we knew how at the
time.  If we got a few files wrong, please fix them up, I hit 11k files
at once here.

And how an internal file is shared with userspace is, to be fair,
completely strange, you have to agree :)

> We have a documented process for a reason: to stop shit like this
> from happening. 
> 
> > No copyright was changed, nothing at all happened except we explicitly
> > list the license of the file, instead of it being "implicit" before.
> 
> You keep saying "no copyright has changed", despite being given an
> explicit statement by the code author that this is *exactly what you
> have done*.

Again, no, the copyright was not changed.  Whom ever held the original
copyright still holds it today.

thanks,

greg k-h

Re: [PATCH 1/1] ALSA: usb: initial USB Audio Device Class 3.0 support

[Takashi Iwai]

On Thu, 09 Nov 2017 09:04:58 +0100,
Greg Kroah-Hartman wrote:
> 
> On Wed, Nov 08, 2017 at 03:38:35PM +0100, Takashi Iwai wrote:
> > On Tue, 07 Nov 2017 03:01:20 +0100,
> > Ruslan Bilovol wrote:
> > > 
> > > Recently released USB Audio Class 3.0 specification
> > > introduces many significant changes comparing to
> > > previous versions, like
> > >  - new Power Domains, support for LPM/L1
> > >  - new Cluster descriptor
> > >  - changed layout of all class-specific descriptors
> > >  - new High Capability descriptors
> > >  - New class-specific String descriptors
> > >  - new and removed units
> > >  - additional sources for interrupts
> > >  - removed Type II Audio Data Formats
> > >  - ... and many other things (check spec)
> > > 
> > > It also provides backward compatibility through
> > > multiple configurations, as well as requires
> > > mandatory support for BADD (Basic Audio Device
> > > Definition) on each ADC3.0 compliant device
> > > 
> > > This patch adds initial support of UAC3 specification
> > > that is enough for Generic I/O Profile (BAOF, BAIF)
> > > device support from BADD document.
> > > 
> > > Signed-off-by: Ruslan Bilovol 
> > 
> > The patch looks good, but the timing is fairly late for merging to
> > 4.15.
> 
> Isn't kbuild barfing all over these?  Is that because of the cross-tree
> changes needed?

No, it's just local to the audio driver, plus a few
include/linux/usb/*.h modification / addition.
So there shouldn't be a big breakage in that regard.


> > So from my side, the primary question is whether the changes in USB
> > (audio) header files are OK for USB guys.
> > 
> > Greg, could you check these changes and give an ack if it's OK to
> > merge?  Or if you prefer postpone, just let me know.
> 
> I don't object to the USB header changes, as long as the fixes you point
> out are made :)

Good to hear.
Could you give your acked-by once after reviewing the patch?
I think this should go through sound tree.

Thanks!


Takashi

Re: [Xen-devel] [PATCH] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute

[Jan Beulich]

>>> On 08.11.17 at 16:44,  wrote:
> On 11/7/2017 8:40 AM, Jan Beulich wrote:
> On 06.11.17 at 18:48,  wrote:
>>> --- a/Documentation/ABI/testing/sysfs-driver-pciback
>>> +++ b/Documentation/ABI/testing/sysfs-driver-pciback
>>> @@ -11,3 +11,15 @@ Description:
>>>   #echo 00:19.0-E0:2:FF > 
>>> /sys/bus/pci/drivers/pciback/quirks
>>>   will allow the guest to read and write to the 
>>> configuration
>>>   register 0x0E.
>>> +
>>> +What:   /sys/bus/pci/drivers/pciback/do_flr
>>> +Date:   Nov 2017
>>> +KernelVersion:  4.15
>>> +Contact:xen-de...@lists.xenproject.org 
>>> +Description:
>>> +An option to perform a slot or bus reset when a PCI device
>>> +   is owned by Xen PCI backend. Writing a string of :BB:DD.F
>>> +   will cause the pciback driver to perform a slot or bus reset
>>> +   if the device supports it. It also checks to make sure that
>>> +   all of the devices under the bridge are owned by Xen PCI
>>> +   backend.
>> Why do you name this "do_flr" when you don't even try FLR, but
>> go to slot or then bus reset right away.
> Yes, I agree but xen toolstack has already been modified to 
> consume"do_flr" attribute. Hence, we are using the
> function that matches with sysfs attribute.

That's not a valid reason imo: Right now the driver doesn't expose
such an attribute, so if the tool stack was trying to use it, it would
not do what is intended at present anyway (i.e. the code could at
best be called dead). Furthermore, contrary to what you claim in
your reply to Pasi, I can't see where you try an actual FLR first -
you go straight to pci_probe_reset_{slot,bus}(). If you actually
tried FLR first, only falling back to the other methods as "emulation",
I could certainly agree with the file name chosen.

And btw - I don't consider it too good an idea to post the next
version of a patch when discussion of the prior one hasn't really
settled yet.

Jan

Re: [PATCH libdrm 0/6] drm-next header syncing

[Daniel Vetter]

On Wed, Nov 08, 2017 at 11:34:41AM -0800, Eric Anholt wrote:
> I wanted to update the vc4 header so that I could land some igt
> testcases (though I'd much rather just be importing the header into
> igt and ditching libdrm).  In the process, I cleaned up some other
> header deltas to the kernel so that there's less diff for the next
> person to look at.

I'm mildly tempted to just pull a mesa in igt too and put the headers in
directly. To avoid the need for way too many libdrm releases when hacking
on tests we atm add all the uapi stuff with a local_ prefix, but that's
kinda silly.

Maybe start a thread with vc4 as example converted (I guess we need to
make sure the include order is right) to get this started.
-Daniel

> 
> I skipped the actual ABI changes for the other drivers, though.
> 
> Eric Anholt (6):
>   headers: Sync vc4 header from drm-next.
>   headers: Sync up some header guard changes from drm-next.
>   headers: Sync up some comment spelling and whitespace fixes from
> drm-next.
>   headers: Sync up mga_drm.h from drm-next.
>   headers: Sync up kernel changes to use kernel types instead of
> stdint.h.
>   headers: Drop outdated node about a delta in drm_mode.h.
> 
>  include/drm/README|  22 +---
>  include/drm/mga_drm.h |  12 -
>  include/drm/nouveau_drm.h |  94 +++---
>  include/drm/qxl_drm.h |  82 +++--
>  include/drm/r128_drm.h|  10 
>  include/drm/radeon_drm.h  | 128 
> +++---
>  include/drm/savage_drm.h  |  20 ++--
>  include/drm/sis_drm.h |  10 
>  include/drm/tegra_drm.h   |  14 +++--
>  include/drm/vc4_drm.h |  47 +++--
>  include/drm/via_drm.h |   8 +++
>  include/drm/vmwgfx_drm.h  |   9 
>  12 files changed, 280 insertions(+), 176 deletions(-)
> 
> -- 
> 2.15.0
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2] IB/ocrdma_hw: remove unnecessary code in ocrdma_mbx_dealloc_lkey

[Leon Romanovsky]

On Wed, Nov 08, 2017 at 02:16:25PM -0600, Gustavo A. R. Silva wrote:
>
> Quoting Leon Romanovsky :
>
> > On Tue, Nov 07, 2017 at 08:56:37AM -0600, Gustavo A. R. Silva wrote:
> > >
> > > Quoting Leon Romanovsky :
> > >
> > > > On Tue, Nov 07, 2017 at 08:45:17AM -0600, Gustavo A. R. Silva wrote:
> > > > > Check on return value and goto label mbx_err are unnecessary.
> > > > >
> > > > > Addresses-Coverity-ID: 1268780
> > > > > Signed-off-by: Gustavo A. R. Silva 
> > > > > Reviewed-by: Yuval Shaia 
> > > > > ---
> > > > > Changes in v2:
> > > > >  Remove assignment from "int status = -ENOMEM" as suggested by Leon
> > > > > Romanovsky.
> > > > >
> > > > >  drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 6 ++
> > > > >  1 file changed, 2 insertions(+), 4 deletions(-)
> > > >
> > > > Please use git send-email to send patches and not reply to the
> > > conversation.
> > > >
> > >
> > > I'm using mutt.
> > > What would be the advantage of using git send-email in this case?
> >
> > New mail headers, so it won't appear as Reply-To and will be presented
> > correctly in mutt's threaded mode.
> >
>
> Oh I actually did that on purpose.
>
> So the preferred way to do this is to send the vN of the patch as a reply to
> the first patch?
> or as a new thread?

As a new thread, please. It gives numerous advantages: nice view in mutt,
easy followed links in web archives and maintainer's acceptance email as
a response to actual vN patch and not to initial patch.

Thanks

>
> Thanks
> --
> Gustavo A. R. Silva
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: PGP signature

Re: [General protection fault] in bio_integrity_advance

[Yu Chen]

On Tue, Nov 7, 2017 at 4:38 PM, Yu Chen  wrote:
> Hi all,
> We are using 4.13.5-100.fc25.x86_64 and a panic was found during
> resume from hibernation, the backtrace is illustrated as below, would
> someone please take a look if this has already been fixed or is this issue 
> still
> in the upstream kernel? thanks!
> [  114.846213] PM: Using 3 thread(s) for decompression.
> [  114.846213] PM: Loading and decompressing image data (6555729 pages)...
> [  115.143169] PM: Image loading progress:   0%
> [  156.386990] PM: Image loading progress:  10%
> [  175.114169] PM: Image loading progress:  20%
> [  185.364073] PM: Image loading progress:  30%
> [  191.345652] PM: Image loading progress:  40%
> [  200.655883] PM: Image loading progress:  50%
> [  220.084360] PM: Image loading progress:  60%
> [  240.581079] PM: Image loading progress:  70%
> [  250.406290] general protection fault:  [#1] SMP
> [  250.411779] Modules linked in: nouveau video mxm_wmi i2c_algo_bit
> drm_kms_helper ttm drm crc32c_intel wmi
> [  250.422524] CPU: 99 PID: 0 Comm: swapper/99 Not tainted
> 4.13.5-100.fc25.x86_64 #1
> [  250.430902] Hardware name: Intel Corporation PURLEY/PURLEY, BIOS
> PLYXCRB1.86B.0521.D18.1710241520 10/24/2017
> [  250.441901] task: 97f5827c task.stack: b0e418cdc000^M
> [  250.448528] RIP: 0010:bio_integrity_advance+0x1a/0xf0
> [  250.454182] RSP: 0018:97f58f6c3da8 EFLAGS: 00010202
> [  250.460024] RAX: db19e5a5b91ff161 RBX: 58b38c0def2b26b8 RCX: 
> 000180400021
> [  250.468008] RDX:  RSI: 8000 RDI: 
> 97f56eb7fd20
> [  250.475993] RBP: 97f58f6c3db0 R08: 97f56d8d3600 R09: 
> 000180400021
> [  250.483976] R10: 97f58f6c3c48 R11: 000a8000 R12: 
> 8000
> [  250.491961] R13: 9739fcdfd400 R14: 000a R15: 
> 8000
> [  250.499944] FS:  () GS:97f58f6c()
> knlGS:
> [  250.508997] CS:  0010 DS:  ES:  CR0: 80050033
> [  250.515427] CR2: 565407552e40 CR3: 0115b7a67000 CR4: 
> 007406e0
> [  250.523412] DR0:  DR1:  DR2: 
> 
> [  250.533458] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [  250.543500] PKRU: 5554
> [  250.548604] Call Trace:
> [  250.553415]  
> [  250.557729]  bio_advance+0x28/0xf0
> [  250.563598]  blk_update_request+0x92/0x2f0
> [  250.570223]  scsi_end_request+0x37/0x1d0
> [  250.576654]  scsi_io_completion+0x20e/0x690
> [  250.583362]  ? rebalance_domains+0x160/0x2b0
> [  250.590187]  scsi_finish_command+0xd9/0x120
> [  250.596924]  scsi_softirq_done+0x125/0x140
> [  250.603562]  blk_done_softirq+0x9e/0xd0
> [  250.609916]  __do_softirq+0x10c/0x2a5
> [  250.616073]  irq_exit+0xff/0x110
> [  250.621737]  smp_call_function_single_interrupt+0x33/0x40
> [  250.629831]  call_function_single_interrupt+0x93/0xa0
> [  250.637544] RIP: 0010:cpuidle_enter_state+0x126/0x2c0
> [  250.645263] RSP: 0018:b0e418cdfe60 EFLAGS: 0246 ORIG_RAX:
> ff04
> [  250.655814] RAX:  RBX: 0002 RCX: 
> 001f
> [  250.665885] RDX: 003a4d5f2d20 RSI: ffc820eb310b RDI: 
> 
> [  250.675956] RBP: b0e418cdfe98 R08: 0176 R09: 
> 0018
> [  250.686018] R10: b0e418cdfe30 R11: 0094 R12: 
> 97f58f6e3b00
> [  250.696080] R13: b1f72a78 R14: 003a4d5f2d20 R15: 
> b1f72a60
> [  250.706123]  
> [  250.710547]  cpuidle_enter+0x17/0x20
> [  250.716609]  call_cpuidle+0x23/0x40
> [  250.722550]  do_idle+0x18e/0x1e0
> [  250.728177]  cpu_startup_entry+0x73/0x80
> [  250.734560]  start_secondary+0x156/0x190
> [  250.740930]  secondary_startup_64+0x9f/0x9f
> [  250.747578] Code: 01 79 cc b1 e8 09 16 ce ff 31 c0 eb e6 0f 1f 40
> 00 0f 1f 44 00 00 55 48 89 e5 53 31 db f6 47 16 01 74 04 48 8b 5f 68
> 48 8b 47 08 <48> 8b 80 80 00 00 00 48 8b 90 d0 03 00 00 48 83 ba 48 02
> 00 00
> [  250.770821] RIP: bio_integrity_advance+0x1a/0xf0 RSP: 97f58f6c3da8^M
> [  250.780481] ---[ end trace d7b00b76aab34156 ]---
> [  250.841521] Kernel panic - not syncing: Fatal exception in interrupt
> [  250.851158] Kernel Offset: 0x3000 from 0x8100
> (relocation range: 0x8000-0xbfff)
> [  250.912067] ---[ end Kernel panic - not syncing: Fatal exception in 
> interrupt

According to the log, the exception was triggered when trying to
access:
bio->bi_bdev->bd_disk:

03b0 :
 3b0:   e8 00 00 00 00  callq  3b5 
 ...
 3c2:   48 8b 5f 68 mov0x68(%rdi),%rbx
 3c6:   48 8b 47 08 mov0x8(%rdi),%rax

 bio->bi_bdev->bd_disk, BOOM!
 3ca:   48 8b 80 80 00 00 00mov0x80(%rax),%rax

When the exception was triggered, the bio->bi_bdev is:
RAX: db19e5a5b91ff161
besides, we can see that bio->bi_integrity is
RBX: 

Re: Linux & FAT32 label

[Pali Rohár]

On Monday 06 November 2017 11:14:44 Karel Zak wrote:
> On Sun, Nov 05, 2017 at 03:34:11PM +0100, Pali Rohár wrote:
> > On Sunday 05 November 2017 16:25:54 Andy Shevchenko wrote:
> > > On Sun, Nov 5, 2017 at 4:07 PM, Pali Rohár  wrote:
> > > > On Sunday 05 November 2017 15:56:53 Andy Shevchenko wrote:
> > > >> On Sun, Nov 5, 2017 at 3:39 PM, Pali Rohár  
> > > >> wrote:
> > > >> > On Tuesday 31 October 2017 10:35:48 Andy Shevchenko wrote:
> > > >> >> On Mon, Oct 16, 2017 at 4:12 AM, Andreas Bombe  
> > > >> >> wrote:
> > > >> >> > On Thu, Oct 12, 2017 at 10:49:31PM +0200, Pali Rohár wrote:
> > > >> >> >> On Thursday 12 October 2017 12:13:11 Karel Zak wrote:
> > > >>
> > > >> >> > I was worried that there might be some scripts or programs that 
> > > >> >> > expect
> > > >> >>
> > > >> >> If we really care about such scripts another approach might be to
> > > >> >> introduce a CLI switch to "spec compatible mode" to each tool and
> > > >> >> suggest in documentation to use it.
> > > >> >>
> > > >> >> There are also variants:
> > > >> >> - spec compatible
> > > >> >> - WinXX compatible
> > > >> >> - DOS compatible
> > > >> >> - etc
> > > >> >
> > > >> > I did tests with MS-DOS and Windows versions (results in previous
> > > >> > email), and they seems to be compatible how they read label.
> > > >> >
> > > >> > Based on results I would suggest to ignore label from the boot sector
> > > >> > when reading label.
> > > >>
> > > >> So, for tools which are not doing that to add
> > > >>
> > > >>  --ignore-boot-sector-label (or alike) [recommended]
> > > >>
> > > >> right?
> > > >>
> > > >> We don't actually know how many users (scripts) are relying on current
> > > >> behaviour.
> > > >> If there are only few, we may introduce backward compatibility switch
> > > >>
> > > >> --read-boot-sector-label
> 
> The current recommended way how to get filesystem label is to read it
> from udev db. For example this is the way how lsblk reads labels by
> default.
> 
> And udevd and some another tools are linked with libblkid. I don't
> see an elegant way how to support something like "read-boot-sector-label" 
> switch for the library to switch it on the fly.
> 
> Maybe it would be good enough to change the default behavior and add 
> #ifdef to the library to switch to the old behavior. This is elegant
> way how to move the decision to downstream maintainers. They have more
> clue about importance of the FAT32 usage. I can imagine that for example
> for some embedded systems it's more important than for example for
> Fedora desktop. I prefer this solution.
> 
> The another way is to add an option to blkid.conf, but it will make
> filesystems probing more complex and slow (we don't read the file
> during superblocks probing now). I'm sure udev guys will hate me with
> this solution. I'd like to avoid something like this.

What about exporting e.g. BOOT_LABEL field from libblkid for vfat disks?
LABEL (which is shown to user, e.g. in GUI) would be that one from root
directory (same which is used by label on MS-DOS and Windows) and
BOOT_LABEL would be from boot sector. If somebody really needs to know
current label stored in boot sector he would be able to do it via blkid.
Also it would be possible then via blkid to read exact label stored in
root directory and also read what is stored in boot sector. Because
currently it is not possible to know from which location LABEL comes
from.

-- 
Pali Rohár
pali.ro...@gmail.com

Re: [PATCH 1/1] ALSA: usb: initial USB Audio Device Class 3.0 support

[Takashi Iwai]

On Thu, 09 Nov 2017 09:33:44 +0100,
Greg Kroah-Hartman wrote:
> 
> On Thu, Nov 09, 2017 at 09:16:52AM +0100, Takashi Iwai wrote:
> > On Thu, 09 Nov 2017 09:04:58 +0100,
> > Greg Kroah-Hartman wrote:
> > > 
> > > On Wed, Nov 08, 2017 at 03:38:35PM +0100, Takashi Iwai wrote:
> > > > On Tue, 07 Nov 2017 03:01:20 +0100,
> > > > Ruslan Bilovol wrote:
> > > > > 
> > > > > Recently released USB Audio Class 3.0 specification
> > > > > introduces many significant changes comparing to
> > > > > previous versions, like
> > > > >  - new Power Domains, support for LPM/L1
> > > > >  - new Cluster descriptor
> > > > >  - changed layout of all class-specific descriptors
> > > > >  - new High Capability descriptors
> > > > >  - New class-specific String descriptors
> > > > >  - new and removed units
> > > > >  - additional sources for interrupts
> > > > >  - removed Type II Audio Data Formats
> > > > >  - ... and many other things (check spec)
> > > > > 
> > > > > It also provides backward compatibility through
> > > > > multiple configurations, as well as requires
> > > > > mandatory support for BADD (Basic Audio Device
> > > > > Definition) on each ADC3.0 compliant device
> > > > > 
> > > > > This patch adds initial support of UAC3 specification
> > > > > that is enough for Generic I/O Profile (BAOF, BAIF)
> > > > > device support from BADD document.
> > > > > 
> > > > > Signed-off-by: Ruslan Bilovol 
> > > > 
> > > > The patch looks good, but the timing is fairly late for merging to
> > > > 4.15.
> > > 
> > > Isn't kbuild barfing all over these?  Is that because of the cross-tree
> > > changes needed?
> > 
> > No, it's just local to the audio driver, plus a few
> > include/linux/usb/*.h modification / addition.
> > So there shouldn't be a big breakage in that regard.
> > 
> > 
> > > > So from my side, the primary question is whether the changes in USB
> > > > (audio) header files are OK for USB guys.
> > > > 
> > > > Greg, could you check these changes and give an ack if it's OK to
> > > > merge?  Or if you prefer postpone, just let me know.
> > > 
> > > I don't object to the USB header changes, as long as the fixes you point
> > > out are made :)
> > 
> > Good to hear.
> > Could you give your acked-by once after reviewing the patch?
> 
> I'm guessing there will be a new patch?  I'll be glad to review that
> one.

Sure, no problem.


thanks,

Takashi

[PATCH v2 04/10] staging: ccree: simplify buf mgr using local vars

[Gilad Ben-Yossef]

Make the code more readable by using a local variables
for commonly use expressions in the buffer manager part
of the driver.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_buffer_mgr.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 2d971f2..b3ca249 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -225,16 +225,18 @@ static int cc_generate_mlli(
mlli_p = (u32 *)mlli_params->mlli_virt_addr;
/* go over all SG's and link it to one MLLI table */
for (i = 0; i < sg_data->num_of_buffers; i++) {
+   union buffer_array_entry *entry = _data->entry[i];
+   u32 tot_len = sg_data->total_data_len[i];
+   u32 offset = sg_data->offset[i];
+
if (sg_data->type[i] == DMA_SGL_TYPE)
-   rc = cc_render_sg_to_mlli(dev, sg_data->entry[i].sgl,
- sg_data->total_data_len[i],
- sg_data->offset[i],
- _nents, _p);
+   rc = cc_render_sg_to_mlli(dev, entry->sgl, tot_len,
+ offset, _nents,
+ _p);
else /*DMA_BUFF_TYPE*/
-   rc = cc_render_buff_to_mlli(dev,
-   
sg_data->entry[i].buffer_dma,
-   sg_data->total_data_len[i],
-   _nents, _p);
+   rc = cc_render_buff_to_mlli(dev, entry->buffer_dma,
+   tot_len, _nents,
+   _p);
if (rc != 0)
return rc;
 
-- 
2.7.4

[PATCH v2 02/10] staging: ccree: make long func call sites readable

[Gilad Ben-Yossef]

The driver was using a function naming scheme
including common prefixes for driver global
functions based on the code module they came from.

The combination of long names with long common
prefixes made the whole thing too long for a human
to parse.

Switch to simple and shorter function naming
scheme. Where required, realign parameters and
add paranthesis for better code readability.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_aead.c|  32 +--
 drivers/staging/ccree/ssi_buffer_mgr.c  | 430 ++--
 drivers/staging/ccree/ssi_buffer_mgr.h  |  49 ++--
 drivers/staging/ccree/ssi_cipher.c  |  13 +-
 drivers/staging/ccree/ssi_driver.c  |  18 +-
 drivers/staging/ccree/ssi_hash.c| 116 +
 drivers/staging/ccree/ssi_ivgen.c   |   2 +-
 drivers/staging/ccree/ssi_pm.c  |  26 +-
 drivers/staging/ccree/ssi_pm.h  |  12 +-
 drivers/staging/ccree/ssi_request_mgr.c |  16 +-
 drivers/staging/ccree/ssi_request_mgr.h |   6 +-
 drivers/staging/ccree/ssi_sram_mgr.c|  11 +-
 drivers/staging/ccree/ssi_sram_mgr.h|   6 +-
 13 files changed, 345 insertions(+), 392 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index ba0954e..0b5b230 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -233,7 +233,7 @@ static void ssi_aead_complete(struct device *dev, void 
*ssi_req, void __iomem *c
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
int err = 0;
 
-   ssi_buffer_mgr_unmap_aead_request(dev, areq);
+   cc_unmap_aead_request(dev, areq);
 
/* Restore ordinary iv pointer */
areq->iv = areq_ctx->backup_iv;
@@ -246,17 +246,20 @@ static void ssi_aead_complete(struct device *dev, void 
*ssi_req, void __iomem *c
/* In case of payload authentication failure, MUST NOT
 * revealed the decrypted message --> zero its memory.
 */
-   ssi_buffer_mgr_zero_sgl(areq->dst, areq_ctx->cryptlen);
+   cc_zero_sgl(areq->dst, areq_ctx->cryptlen);
err = -EBADMSG;
}
} else { /*ENCRYPT*/
-   if (unlikely(areq_ctx->is_icv_fragmented))
-   ssi_buffer_mgr_copy_scatterlist_portion(
-   dev, areq_ctx->mac_buf, areq_ctx->dst_sgl,
-   areq->cryptlen + areq_ctx->dst_offset,
-   (areq->cryptlen + areq_ctx->dst_offset +
-ctx->authsize),
-   SSI_SG_FROM_BUF);
+   if (unlikely(areq_ctx->is_icv_fragmented)) {
+   cc_copy_sg_portion(dev, areq_ctx->mac_buf,
+  areq_ctx->dst_sgl,
+  (areq->cryptlen +
+   areq_ctx->dst_offset),
+  (areq->cryptlen +
+   areq_ctx->dst_offset +
+   ctx->authsize),
+  SSI_SG_FROM_BUF);
+   }
 
/* If an IV was generated, copy it back to the user provided 
buffer. */
if (areq_ctx->backup_giv) {
@@ -2053,7 +2056,7 @@ static int ssi_aead_process(struct aead_request *req, 
enum drv_crypto_direction
}
 #endif /*SSI_CC_HAS_AES_GCM*/
 
-   rc = ssi_buffer_mgr_map_aead_request(ctx->drvdata, req);
+   rc = cc_map_aead_request(ctx->drvdata, req);
if (unlikely(rc != 0)) {
dev_err(dev, "map_request() failed\n");
goto exit;
@@ -2112,7 +2115,7 @@ static int ssi_aead_process(struct aead_request *req, 
enum drv_crypto_direction
 #endif
default:
dev_err(dev, "Unsupported authenc (%d)\n", ctx->auth_mode);
-   ssi_buffer_mgr_unmap_aead_request(dev, req);
+   cc_unmap_aead_request(dev, req);
rc = -ENOTSUPP;
goto exit;
}
@@ -2123,7 +2126,7 @@ static int ssi_aead_process(struct aead_request *req, 
enum drv_crypto_direction
 
if (unlikely(rc != -EINPROGRESS)) {
dev_err(dev, "send_request() failed (rc=%d)\n", rc);
-   ssi_buffer_mgr_unmap_aead_request(dev, req);
+   cc_unmap_aead_request(dev, req);
}
 
 exit:
@@ -2753,8 +2756,9 @@ int ssi_aead_alloc(struct ssi_drvdata *drvdata)
INIT_LIST_HEAD(_handle->aead_list);
drvdata->aead_handle = aead_handle;
 
-   aead_handle->sram_workspace_addr = ssi_sram_mgr_alloc(
-   drvdata, MAX_HMAC_DIGEST_SIZE);
+   aead_handle->sram_workspace_addr = cc_sram_alloc(drvdata,
+MAX_HMAC_DIGEST_SIZE);
+
if 

Re: [PATCH] media: coda: remove definition of CODA_STD_MJPG

[Philipp Zabel]

On Wed, 2017-11-08 at 19:58 +0100, Martin Kepplinger wrote:
> According to i.MX VPU API Reference Manuals the MJPG video codec is
> refernced to by number 7, not 3.
> 
> Also Philipp pointed out that this value is only meant to fill in
> CMD_ENC_SEQ_COD_STD for encoding, only on i.MX53. It was never written
> to any register, and even if defined correctly, wouldn't be needed
> for i.MX6.
> 
> So avoid confusion and remove this definition.
> 
> Signed-off-by: Martin Kepplinger 
> ---
>  drivers/media/platform/coda/coda_regs.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/media/platform/coda/coda_regs.h 
> b/drivers/media/platform/coda/coda_regs.h
> index 38df5fd9a2fa..35e620c7f1f4 100644
> --- a/drivers/media/platform/coda/coda_regs.h
> +++ b/drivers/media/platform/coda/coda_regs.h
> @@ -254,7 +254,6 @@
>  #define  CODA9_STD_H264  0
>  #define  CODA_STD_H263   1
>  #define  CODA_STD_H264   2
> -#define  CODA_STD_MJPG   3
>  #define  CODA9_STD_MPEG4 3
>  
>  #define CODA_CMD_ENC_SEQ_SRC_SIZE0x190

Thanks,

Acked-by: Philipp Zabel 

regards
Philipp

[PATCH v2 10/10] staging: ccree: remove unused cc_base parameter

[Gilad Ben-Yossef]

Remove a common parameter named cc_base with the pointer
to the mapped command registers which was used by the
old register access macros that are not longer in use.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_aead.c|  2 +-
 drivers/staging/ccree/ssi_cipher.c  | 12 +---
 drivers/staging/ccree/ssi_driver.c  |  3 ---
 drivers/staging/ccree/ssi_driver.h  |  2 +-
 drivers/staging/ccree/ssi_hash.c|  6 +++---
 drivers/staging/ccree/ssi_request_mgr.c |  5 ++---
 6 files changed, 12 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index e036168..9e24783 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -225,7 +225,7 @@ static int ssi_aead_init(struct crypto_aead *tfm)
return -ENOMEM;
 }
 
-static void ssi_aead_complete(struct device *dev, void *ssi_req, void __iomem 
*cc_base)
+static void ssi_aead_complete(struct device *dev, void *ssi_req)
 {
struct aead_request *areq = (struct aead_request *)ssi_req;
struct aead_req_ctx *areq_ctx = aead_request_ctx(areq);
diff --git a/drivers/staging/ccree/ssi_cipher.c 
b/drivers/staging/ccree/ssi_cipher.c
index 4d05b4a..b5bb97c 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -67,7 +67,7 @@ struct ssi_ablkcipher_ctx {
struct crypto_shash *shash_tfm;
 };
 
-static void ssi_ablkcipher_complete(struct device *dev, void *ssi_req, void 
__iomem *cc_base);
+static void ssi_ablkcipher_complete(struct device *dev, void *ssi_req);
 
 static int validate_keys_sizes(struct ssi_ablkcipher_ctx *ctx_p, u32 size)
 {
@@ -688,8 +688,7 @@ static int ssi_blkcipher_complete(struct device *dev,
  struct scatterlist *dst,
  struct scatterlist *src,
  unsigned int ivsize,
- void *areq,
- void __iomem *cc_base)
+ void *areq)
 {
int completion_error = 0;
struct ablkcipher_request *req = (struct ablkcipher_request *)areq;
@@ -832,8 +831,7 @@ static int ssi_blkcipher_process(
   dst);
} else {
rc = ssi_blkcipher_complete(dev, ctx_p, req_ctx, dst,
-   src, ivsize, NULL,
-   ctx_p->drvdata->cc_base);
+   src, ivsize, NULL);
}
}
 
@@ -849,7 +847,7 @@ static int ssi_blkcipher_process(
return rc;
 }
 
-static void ssi_ablkcipher_complete(struct device *dev, void *ssi_req, void 
__iomem *cc_base)
+static void ssi_ablkcipher_complete(struct device *dev, void *ssi_req)
 {
struct ablkcipher_request *areq = (struct ablkcipher_request *)ssi_req;
struct blkcipher_req_ctx *req_ctx = ablkcipher_request_ctx(areq);
@@ -858,7 +856,7 @@ static void ssi_ablkcipher_complete(struct device *dev, 
void *ssi_req, void __io
unsigned int ivsize = crypto_ablkcipher_ivsize(tfm);
 
ssi_blkcipher_complete(dev, ctx_p, req_ctx, areq->dst, areq->src,
-  ivsize, areq, cc_base);
+  ivsize, areq);
 }
 
 /* Async wrap functions */
diff --git a/drivers/staging/ccree/ssi_driver.c 
b/drivers/staging/ccree/ssi_driver.c
index 7b77f3f..0d5c1a9 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -199,7 +199,6 @@ int init_cc_regs(struct ssi_drvdata *drvdata, bool is_probe)
 static int init_cc_resources(struct platform_device *plat_dev)
 {
struct resource *req_mem_cc_regs = NULL;
-   void __iomem *cc_base = NULL;
struct ssi_drvdata *new_drvdata;
struct device *dev = _dev->dev;
struct device_node *np = dev->of_node;
@@ -232,8 +231,6 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
dev_dbg(dev, "CC registers mapped from %pa to 0x%p\n",
_mem_cc_regs->start, new_drvdata->cc_base);
 
-   cc_base = new_drvdata->cc_base;
-
/* Then IRQ */
new_drvdata->irq = platform_get_irq(plat_dev, 0);
if (new_drvdata->irq < 0) {
diff --git a/drivers/staging/ccree/ssi_driver.h 
b/drivers/staging/ccree/ssi_driver.h
index 94c755c..f4967ca 100644
--- a/drivers/staging/ccree/ssi_driver.h
+++ b/drivers/staging/ccree/ssi_driver.h
@@ -100,7 +100,7 @@
 
 #define SSI_MAX_IVGEN_DMA_ADDRESSES3
 struct ssi_crypto_req {
-   void (*user_cb)(struct device *dev, void *req, void __iomem *cc_base);
+   void (*user_cb)(struct device *dev, void *req);
void *user_arg;
dma_addr_t ivgen_dma_addr[SSI_MAX_IVGEN_DMA_ADDRESSES];
/* For the first 'ivgen_dma_addr_len' addresses of this array,
diff --git 

Re: [PATCH] checkpatch.pl: Add SPDX license tag check

[Greg Kroah-Hartman]

On Wed, Nov 08, 2017 at 06:10:19PM -0800, Joe Perches wrote:
> On Wed, 2017-11-08 at 19:10 -0600, Rob Herring wrote:
> > Add a check warning if SPDX-License-Identifier tags are not used in
> > newly added files.
> 
> If this is to be done, and I think it's not a great idea,
> there are better ways of doing this that emit this warning
> on a per-file basis instead of a per-patch.

Any hints as to how to do that?  :)

thanks,

greg k-h

Re: [PATCH] drm/i915/intel_sdvo: mark expected switch fall-throughs

[Jani Nikula]

On Thu, 09 Nov 2017, Jani Nikula  wrote:
> On Wed, 08 Nov 2017, "Gustavo A. R. Silva"  wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>>
>> Addresses-Coverity-ID: 141432
>> Addresses-Coverity-ID: 141433
>> Addresses-Coverity-ID: 141434
>> Addresses-Coverity-ID: 141435
>> Addresses-Coverity-ID: 141436
>> Signed-off-by: Gustavo A. R. Silva 
>
> Acked-by: Jani Nikula 

More explicitly, the patch looks good, but I'll give others the chance
to chime in before merging. In particular Chris has been doing plenty of
warning fixes lately.

BR,
Jani.


>
>> ---
>>  drivers/gpu/drm/i915/intel_sdvo.c | 11 ++-
>>  1 file changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
>> b/drivers/gpu/drm/i915/intel_sdvo.c
>> index 7437944..921e372 100644
>> --- a/drivers/gpu/drm/i915/intel_sdvo.c
>> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
>> @@ -1327,6 +1327,7 @@ static void intel_sdvo_pre_enable(struct intel_encoder 
>> *intel_encoder,
>>  switch (crtc_state->pixel_multiplier) {
>>  default:
>>  WARN(1, "unknown pixel multiplier specified\n");
>> +/* fall through */
>>  case 1: rate = SDVO_CLOCK_RATE_MULT_1X; break;
>>  case 2: rate = SDVO_CLOCK_RATE_MULT_2X; break;
>>  case 4: rate = SDVO_CLOCK_RATE_MULT_4X; break;
>> @@ -2274,15 +2275,15 @@ intel_sdvo_guess_ddc_bus(struct intel_sdvo *sdvo)
>>   */
>>  switch (sdvo->controlled_output) {
>>  case SDVO_OUTPUT_LVDS1:
>> -mask |= SDVO_OUTPUT_LVDS1;
>> +mask |= SDVO_OUTPUT_LVDS1; /* fall through */
>>  case SDVO_OUTPUT_LVDS0:
>> -mask |= SDVO_OUTPUT_LVDS0;
>> +mask |= SDVO_OUTPUT_LVDS0; /* fall through */
>>  case SDVO_OUTPUT_TMDS1:
>> -mask |= SDVO_OUTPUT_TMDS1;
>> +mask |= SDVO_OUTPUT_TMDS1; /* fall through */
>>  case SDVO_OUTPUT_TMDS0:
>> -mask |= SDVO_OUTPUT_TMDS0;
>> +mask |= SDVO_OUTPUT_TMDS0; /* fall through */
>>  case SDVO_OUTPUT_RGB1:
>> -mask |= SDVO_OUTPUT_RGB1;
>> +mask |= SDVO_OUTPUT_RGB1; /* fall through */
>>  case SDVO_OUTPUT_RGB0:
>>  mask |= SDVO_OUTPUT_RGB0;
>>  break;

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v2 09/10] staging: ccree: remove braces for single statement

[Gilad Ben-Yossef]

Remove necessary braces for single statement blocks to
improve code readabilty.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_buffer_mgr.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 29ef046..bfabb5b 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -1491,9 +1491,8 @@ int cc_map_hash_request_final(struct ssi_drvdata 
*drvdata, void *ctx,
/* add the src data to the sg_data */
cc_add_sg_entry(dev, _data, areq_ctx->in_nents, src, nbytes,
0, true, _ctx->mlli_nents);
-   if (unlikely(cc_generate_mlli(dev, _data, mlli_params))) {
+   if (unlikely(cc_generate_mlli(dev, _data, mlli_params)))
goto fail_unmap_din;
-   }
}
/* change the buffer index for the unmap function */
areq_ctx->buff_index = (areq_ctx->buff_index ^ 1);
@@ -1610,9 +1609,8 @@ int cc_map_hash_request_update(struct ssi_drvdata 
*drvdata, void *ctx,
cc_add_sg_entry(dev, _data, areq_ctx->in_nents, src,
(update_data_len - *curr_buff_cnt), 0, true,
_ctx->mlli_nents);
-   if (unlikely(cc_generate_mlli(dev, _data, mlli_params))) {
+   if (unlikely(cc_generate_mlli(dev, _data, mlli_params)))
goto fail_unmap_din;
-   }
}
areq_ctx->buff_index = (areq_ctx->buff_index ^ swap_index);
 
-- 
2.7.4

[PATCH v2 07/10] staging: ccree: remove unneeded cast

[Gilad Ben-Yossef]

Remove unneeded cast of the return value of dev_get_drvdata()
to struct ssi_drvdata * for better readability.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_pm.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/ccree/ssi_pm.c b/drivers/staging/ccree/ssi_pm.c
index d60143c..d3e9382 100644
--- a/drivers/staging/ccree/ssi_pm.c
+++ b/drivers/staging/ccree/ssi_pm.c
@@ -36,8 +36,7 @@
 
 int cc_pm_suspend(struct device *dev)
 {
-   struct ssi_drvdata *drvdata =
-   (struct ssi_drvdata *)dev_get_drvdata(dev);
+   struct ssi_drvdata *drvdata = dev_get_drvdata(dev);
int rc;
 
dev_dbg(dev, "set HOST_POWER_DOWN_EN\n");
@@ -56,8 +55,7 @@ int cc_pm_suspend(struct device *dev)
 int cc_pm_resume(struct device *dev)
 {
int rc;
-   struct ssi_drvdata *drvdata =
-   (struct ssi_drvdata *)dev_get_drvdata(dev);
+   struct ssi_drvdata *drvdata = dev_get_drvdata(dev);
 
dev_dbg(dev, "unset HOST_POWER_DOWN_EN\n");
cc_iowrite(drvdata, CC_REG(HOST_POWER_DOWN_EN), POWER_DOWN_DISABLE);
@@ -90,8 +88,7 @@ int cc_pm_resume(struct device *dev)
 int cc_pm_get(struct device *dev)
 {
int rc = 0;
-   struct ssi_drvdata *drvdata =
-   (struct ssi_drvdata *)dev_get_drvdata(dev);
+   struct ssi_drvdata *drvdata = dev_get_drvdata(dev);
 
if (cc_req_queue_suspended(drvdata))
rc = pm_runtime_get_sync(dev);
@@ -104,8 +101,7 @@ int cc_pm_get(struct device *dev)
 int cc_pm_put_suspend(struct device *dev)
 {
int rc = 0;
-   struct ssi_drvdata *drvdata =
-   (struct ssi_drvdata *)dev_get_drvdata(dev);
+   struct ssi_drvdata *drvdata = dev_get_drvdata(dev);
 
if (!cc_req_queue_suspended(drvdata)) {
pm_runtime_mark_last_busy(dev);
-- 
2.7.4

Re: [PATCH 00/31] Andes(nds32) Linux Kernel Port

[Greentime Hu]

2017-11-08 18:26 GMT+08:00 Arnd Bergmann :
> On Wed, Nov 8, 2017 at 6:54 AM, Greentime Hu  wrote:
>> This patchset adds core architecture support to Linux for Andestech's
>> N13, N15, D15, N10, D10 processor cores.
>>
>> Based on the 16/32-bit AndeStar RISC-like architecture, we designed the
>> configurable AndesCore series of embedded processor families. AndesCores
>> range from highly performance-efficient small-footprint cores for
>> microcontrollers and deeply-embedded applications to 1GHz+ cores running
>> Linux, covering general-purpose N-series cores for a wide range of computing
>> need, DSP-capable D-series cores for digital signal control,
>> instruction-extensible E-series cores for application-specific acceleration,
>> and secure S-series cores for best protection of the most valuable.
>
> I looked at the entire patch series now and commented on anything I noticed
> that could be improved, overall this looks very nice, great work!
>
> Most of my comments are about tiny details that are easy to address.
>
> I see two areas that need to be looked at carefully, and that may take a
> few more rounds to get right:
>
> - In the user space ABI, you have a couple of things that differ from the
>   normal asm-generic definitions, i.e. s few syscall entry points and some
>   types in asm/posix-types.h. I guess you did that to remain compatible
>   with an older glibc port, but IMHO this compatibility should be broken
>   in favor of having the standard ABI before the port gets merged.
>
> - For the boot interface, you need to clearly define what can be expected
>   and what cannot. This involves the presence of the l2cc, the physical
>   memory address, the built-in dtb, and probably a few more things I
>   missed. For long-term maintainability, you probably want to ensure that
>   you can build a kernel that runs on as much diverse hardware as possible.
>

Many thanks to all your feedbacks. We will prepare the V2 patch to fix
them ASAP. :)

Re: [PATCH v6] x86: use lock+addl for smp_mb()

[Peter Zijlstra]

On Fri, Oct 27, 2017 at 07:14:31PM +0300, Michael S. Tsirkin wrote:

> The one difference between lock+add and mfence is that lock+addl does
> not affect clflush, previous patches converted all uses of clflush to
> call mb(), such that changes to smp_mb won't affect it.
> 
> Update mb/rmb/wmb on 32 bit to use the negative offset, too, for
> consistency.

So I briefly spoke to hpa about this patch in Prague, and yes, we should
do this.

By the very simple argument that we already rely on all LOCK prefixed
instructions to fully imply smp_mb().

And yes, there are differences between MFENCE and LOCK prefix, but as
already noted above, those should not have been using smp_mb() in the
first place and should be converted to mb()

So:

Acked-by: Peter Zijlstra (Intel) 


> diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
> index bfb28ca..3c6ba1e 100644
> --- a/arch/x86/include/asm/barrier.h
> +++ b/arch/x86/include/asm/barrier.h
> @@ -11,11 +11,11 @@
>   */
>  
>  #ifdef CONFIG_X86_32
> -#define mb() asm volatile(ALTERNATIVE("lock; addl $0,0(%%esp)", "mfence", \
> +#define mb() asm volatile(ALTERNATIVE("lock; addl $0,-4(%%esp)", "mfence", \
> X86_FEATURE_XMM2) ::: "memory", "cc")
> -#define rmb() asm volatile(ALTERNATIVE("lock; addl $0,0(%%esp)", "lfence", \
> +#define rmb() asm volatile(ALTERNATIVE("lock; addl $0,-4(%%esp)", "lfence", \
>  X86_FEATURE_XMM2) ::: "memory", "cc")
> -#define wmb() asm volatile(ALTERNATIVE("lock; addl $0,0(%%esp)", "sfence", \
> +#define wmb() asm volatile(ALTERNATIVE("lock; addl $0,-4(%%esp)", "sfence", \
>  X86_FEATURE_XMM2) ::: "memory", "cc")
>  #else
>  #define mb() asm volatile("mfence":::"memory")
> @@ -30,7 +30,11 @@
>  #endif
>  #define dma_wmb()barrier()
>  
> -#define __smp_mb()   mb()
> +#ifdef CONFIG_X86_32
> +#define __smp_mb()   asm volatile("lock; addl $0,-4(%%esp)" ::: "memory", 
> "cc")
> +#else
> +#define __smp_mb()   asm volatile("lock; addl $0,-4(%%rsp)" ::: "memory", 
> "cc")
> +#endif
>  #define __smp_rmb()  dma_rmb()
>  #define __smp_wmb()  barrier()
>  #define __smp_store_mb(var, value) do { (void)xchg(, value); } while (0)

Re: [PATCH 28/31] irqchip: Andestech Internal Vector Interrupt Controller driver

[Greentime Hu]

2017-11-08 22:24 GMT+08:00 Marc Zyngier :
> On 08/11/17 05:55, Greentime Hu wrote:
>> From: Greentime Hu 
>>
>
> Please add a commit message, indicating what this does, and potentially
> a pointer to some documentation (if publicly available).
>

Thans.
I will add proper commit messages in the next version patch.

>> Signed-off-by: Rick Chen 
>> Signed-off-by: Greentime Hu 
>> ---
>>  drivers/irqchip/Makefile   |1 +
>>  drivers/irqchip/irq-ativic32.c |  149 
>> 
>>  2 files changed, 150 insertions(+)
>>  create mode 100644 drivers/irqchip/irq-ativic32.c
>>
>> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
>> index b842dfd..201ca9f 100644
>> --- a/drivers/irqchip/Makefile
>> +++ b/drivers/irqchip/Makefile
>> @@ -80,3 +80,4 @@ obj-$(CONFIG_ARCH_ASPEED)   += irq-aspeed-vic.o 
>> irq-aspeed-i2c-ic.o
>>  obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o
>>  obj-$(CONFIG_QCOM_IRQ_COMBINER)  += qcom-irq-combiner.o
>>  obj-$(CONFIG_IRQ_UNIPHIER_AIDET) += irq-uniphier-aidet.o
>> +obj-$(CONFIG_NDS32)  += irq-ativic32.o
>> diff --git a/drivers/irqchip/irq-ativic32.c b/drivers/irqchip/irq-ativic32.c
>> new file mode 100644
>> index 000..d3dae59
>> --- /dev/null
>> +++ b/drivers/irqchip/irq-ativic32.c
>> @@ -0,0 +1,149 @@
>> +/*
>> + * Copyright (C) 2005-2017 Andes Technology Corporation
>> + *
>> + * 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 
>> +
>> +static void ativic32_ack_irq(struct irq_data *data)
>> +{
>> + __nds32__mtsr_dsb(1 << data->hwirq, NDS32_SR_INT_PEND2);
>> +}
>> +
>> +static void ativic32_mask_irq(struct irq_data *data)
>> +{
>> + unsigned long int_mask2 = __nds32__mfsr(NDS32_SR_INT_MASK2);
>> + __nds32__mtsr_dsb(int_mask2 & (~(1 << data->hwirq)), 
>> NDS32_SR_INT_MASK2);
>> +}
>> +
>> +static void ativic32_mask_ack_irq(struct irq_data *data)
>> +{
>> + unsigned long int_mask2 = __nds32__mfsr(NDS32_SR_INT_MASK2);
>> + __nds32__mtsr_dsb(int_mask2 & (~(1 << data->hwirq)), 
>> NDS32_SR_INT_MASK2);
>> + __nds32__mtsr_dsb((1 << data->hwirq), NDS32_SR_INT_PEND2);
>> +
>> +}
>> +
>> +static void ativic32_unmask_irq(struct irq_data *data)
>> +{
>> + unsigned long int_mask2 = __nds32__mfsr(NDS32_SR_INT_MASK2);
>> + __nds32__mtsr_dsb(int_mask2 | (1 << data->hwirq), NDS32_SR_INT_MASK2);
>> +}
>> +
>> +static int ativic32_set_type(struct irq_data *data, unsigned int flow_type)
>> +{
>> + printk(KERN_WARNING "interrupt type is not configurable\n");
>
> If it is not configurable, what is the point of having each interrupt
> carry a trigger type in DT?

Make sense.
We should remove this function and DT trigger type description.

>> + return 0;
>> +}
>> +
>> +static struct irq_chip ativic32_chip = {
>> + .name = "ativic32",
>> + .irq_ack = ativic32_ack_irq,
>> + .irq_mask = ativic32_mask_irq,
>> + .irq_mask_ack = ativic32_mask_ack_irq,
>> + .irq_unmask = ativic32_unmask_irq,
>> + .irq_set_type = ativic32_set_type,
>> +};
>> +
>> +static unsigned int __initdata nivic_map[6] = { 6, 2, 10, 16, 24, 32 };
>> +
>> +struct irq_domain *root_domain;
>
> Why isn't this static? Is there anything accessing it from outside of
> this driver?

Thanks.
I will check if it is not used outside and add static in the next version patch.

>> +static int ativic32_irq_domain_map(struct irq_domain *id, unsigned int virq,
>> +   irq_hw_number_t hw)
>> +{
>> +
>> + unsigned long int_trigger_type;
>> + int_trigger_type = __nds32__mfsr(NDS32_SR_INT_TRIGGER);
>> + if (int_trigger_type & (1 << hw))
>> + irq_set_chip_and_handler(virq, _chip, 
>> handle_edge_irq);
>> + else
>> + irq_set_chip_and_handler(virq, _chip, 
>> handle_level_irq);
>> +
>> + return 0;
>> +}
>> +
>> +static struct irq_domain_ops ativic32_ops = {
>> + .map = ativic32_irq_domain_map,
>> + .xlate = irq_domain_xlate_onecell
>
> Huh... Your DT binding insist on two cells, and yet...

Thanks.
It is inconsistent. We will fix it in the next version patch.

>> +};
>> +
>> +static int get_intr_src(void)
>> +{
>> + return 

Re: [PATCH 01/11] Initialize the mapping of KASan shadow memory

[Marc Zyngier]

On 09/11/17 07:46, Liuwenliang (Abbott Liu) wrote:
> On 12/10/17 15:59, Marc Zyngier [mailto:marc.zyng...@arm.com] wrote:
>> On 11/10/17 09:22, Abbott Liu wrote:
>>> diff --git a/arch/arm/include/asm/proc-fns.h 
>>> b/arch/arm/include/asm/proc-fns.h
>>> index f2e1af4..6e26714 100644
>>> --- a/arch/arm/include/asm/proc-fns.h
>>> +++ b/arch/arm/include/asm/proc-fns.h
>>> @@ -131,6 +131,15 @@ extern void cpu_resume(void);
>>> pg &= ~(PTRS_PER_PGD*sizeof(pgd_t)-1);  \
>>> (pgd_t *)phys_to_virt(pg);  \
>>> })
>>> +
>>> +#define cpu_set_ttbr0(val) \
>>> +   do {\
>>> +   u64 ttbr = val; \
>>> +   __asm__("mcrr   p15, 0, %Q0, %R0, c2"   \
>>> +   : : "r" (ttbr));\
>>> +   } while (0)
>>> +
>>> +
>>>  #else
>>>  #define cpu_get_pgd()  \
>>> ({  \
>>> @@ -140,6 +149,30 @@ extern void cpu_resume(void);
>>> pg &= ~0x3fff;  \
>>> (pgd_t *)phys_to_virt(pg);  \
>>> })
>>> +
>>> +#define cpu_set_ttbr(nr, val)  \
>>> +   do {\
>>> +   u64 ttbr = val; \
>>> +   __asm__("mcrp15, 0, %0, c2, c0, 0"  \
>>> +   : : "r" (ttbr));\
>>> +   } while (0)
>>> +
>>> +#define cpu_get_ttbr(nr)   \
>>> +   ({  \
>>> +   unsigned long ttbr; \
>>> +   __asm__("mrcp15, 0, %0, c2, c0, 0"  \
>>> +   : "=r" (ttbr)); \
>>> +   ttbr;   \
>>> +   })
>>> +
>>> +#define cpu_set_ttbr0(val) \
>>> +   do {\
>>> +   u64 ttbr = val; \
>>> +   __asm__("mcrp15, 0, %0, c2, c0, 0"  \
>>> +   : : "r" (ttbr));\
>>> +   } while (0)
>>> +
>>> +
>>
>> You could instead lift and extend the definitions provided in kvm_hyp.h,
>> and use the read_sysreg/write_sysreg helpers defined in cp15.h.
> 
> Thanks for your review. 
> I extend definitions of TTBR0/TTBR1/PAR in kvm_hyp.h when the CONFIG_ARM_LPAE 
> is 
> not defined. 
> Because cortex A9 don't support virtualization, so use CONFIG_ARM_LPAE to 
> exclude
> some functions and macros which are only used in virtualization.
> 
> Here is the code which I tested on vexpress_a15 and vexpress_a9:
> 
> diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
> index 14b5903..2592608 100644
> --- a/arch/arm/include/asm/kvm_hyp.h
> +++ b/arch/arm/include/asm/kvm_hyp.h
> @@ -19,12 +19,14 @@
>  #define __ARM_KVM_HYP_H__
> 
>  #include 
> -#include 
>  #include 
> +
> +#ifdef CONFIG_ARM_LPAE
> +#include 
>  #include 
>  #include 
> -
>  #define __hyp_text __section(.hyp.text) notrace
> +#endif
> 
>  #define __ACCESS_VFP(CRn)  \
> "mrc", "mcr", __stringify(p10, 7, %0, CRn, cr0, 0), u32
> @@ -37,12 +39,18 @@
> __val;  \
>  })
> 
> +#ifdef CONFIG_ARM_LPAE
>  #define TTBR0  __ACCESS_CP15_64(0, c2)
>  #define TTBR1  __ACCESS_CP15_64(1, c2)
>  #define VTTBR  __ACCESS_CP15_64(6, c2)
>  #define PAR__ACCESS_CP15_64(0, c7)
>  #define CNTV_CVAL  __ACCESS_CP15_64(3, c14)
>  #define CNTVOFF__ACCESS_CP15_64(4, c14)
> +#else
> +#define TTBR0   __ACCESS_CP15(c2, 0, c0, 0)
> +#define TTBR1   __ACCESS_CP15(c2, 0, c0, 1)
> +#define PAR  __ACCESS_CP15(c7, 0, c4, 0)
> +#endif

There is no reason for this LPAE vs non LPAE dichotomy. Both registers
do exist if your system supports LPAE. So you can either suffix the
64bit version with an _64 (and change the KVM code), or suffix the bit
version with _32.

> 
>  #define MIDR   __ACCESS_CP15(c0, 0, c0, 0)
>  #define CSSELR __ACCESS_CP15(c0, 2, c0, 0)
> @@ -98,6 +106,7 @@
>  #define cntvoff_el2CNTVOFF
>  #define cnthctl_el2CNTHCTL
> 
> +#ifdef CONFIG_ARM_LPAE
>  void __timer_save_state(struct kvm_vcpu *vcpu);
>  void __timer_restore_state(struct kvm_vcpu *vcpu);
> 
> @@ -123,5 +132,6 @@ void __hyp_text __banked_restore_state(struct 
> kvm_cpu_context *ctxt);
>  asmlinkage int __guest_enter(struct kvm_vcpu *vcpu,
>  struct kvm_cpu_context *host);
>  asmlinkage int __hyp_do_panic(const char *, int, u32);
> +#endif
> 
>  #endif /* __ARM_KVM_HYP_H__ */
> diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
> index 049ee0a..359a782 

Re: [PATCH RESEND 2/3] KVM: Add paravirt remote TLB flush

[Paolo Bonzini]

On 09/11/2017 03:02, Wanpeng Li wrote:
> From: Wanpeng Li 
> 
> Remote flushing api's does a busy wait which is fine in bare-metal
> scenario. But with-in the guest, the vcpus might have been pre-empted
> or blocked. In this scenario, the initator vcpu would end up
> busy-waiting for a long amount of time.
> 
> This patch set implements para-virt flush tlbs making sure that it
> does not wait for vcpus that are sleeping. And all the sleeping vcpus
> flush the tlb on guest enter.
> 
> The best result is achieved when we're overcommiting the host by running 
> multiple vCPUs on each pCPU. In this case PV tlb flush avoids touching 
> vCPUs which are not scheduled and avoid the wait on the main CPU.
> 
> Test on a Haswell i7 desktop 4 cores (2HT), so 8 pCPUs, running ebizzy in 
> one linux guest.
> 
> ebizzy -M 
>   vanillaoptimized boost
>  8 vCPUs   10152   10083   -0.68% 
> 16 vCPUs12244866   297.5% 
> 24 vCPUs11093871   249%
> 32 vCPUs10253375   229.3% 
> 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Signed-off-by: Wanpeng Li 
> ---
>  arch/x86/include/uapi/asm/kvm_para.h |  1 +
>  arch/x86/kernel/kvm.c| 29 +
>  2 files changed, 30 insertions(+)
> 
> diff --git a/arch/x86/include/uapi/asm/kvm_para.h 
> b/arch/x86/include/uapi/asm/kvm_para.h
> index ff23ce9..189e354 100644
> --- a/arch/x86/include/uapi/asm/kvm_para.h
> +++ b/arch/x86/include/uapi/asm/kvm_para.h
> @@ -52,6 +52,7 @@ struct kvm_steal_time {
>  
>  #define KVM_VCPU_NOT_PREEMPTED  (0 << 0)
>  #define KVM_VCPU_PREEMPTED  (1 << 0)
> +#define KVM_VCPU_SHOULD_FLUSH   (1 << 1)
>  
>  #define KVM_CLOCK_PAIRING_WALLCLOCK 0
>  struct kvm_clock_pairing {
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index 1b1b641..2e2f3ae 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -465,6 +465,33 @@ static void __init kvm_apf_trap_init(void)
>   update_intr_gate(X86_TRAP_PF, async_page_fault);
>  }
>  
> +static void kvm_flush_tlb_others(const struct cpumask *cpumask,
> + const struct flush_tlb_info *info)
> +{
> + u8 state;
> + int cpu;
> + struct kvm_steal_time *src;
> + cpumask_t flushmask;
> +
> +
> + cpumask_copy(, cpumask);
> + /*
> +  * We have to call flush only on online vCPUs. And
> +  * queue flush_on_enter for pre-empted vCPUs
> +  */
> + for_each_cpu(cpu, cpumask) {
> + src = _cpu(steal_time, cpu);
> + state = src->preempted;
> + if ((state & KVM_VCPU_PREEMPTED)) {
> + if (cmpxchg(>preempted, state, state | 1 <<
> + KVM_VCPU_SHOULD_FLUSH))
> + cpumask_clear_cpu(cpu, );
> + }
> + }
> +
> + native_flush_tlb_others(, info);
> +}
> +
>  void __init kvm_guest_init(void)
>  {
>   int i;
> @@ -484,6 +511,8 @@ void __init kvm_guest_init(void)
>   pv_time_ops.steal_clock = kvm_steal_clock;
>   }
>  
> + pv_mmu_ops.flush_tlb_others = kvm_flush_tlb_others;

This needs to be keyed on a new CPUID feature bit.  Eduardo is also
adding a new "PV_DEDICATED" hint and you might disable PV TLB flush when
PV_DEDICATED is set.

Paolo

>   if (kvm_para_has_feature(KVM_FEATURE_PV_EOI))
>   apic_set_eoi_write(kvm_guest_apic_eoi_write);
>  
> 

Re: [PATCH v5 3/3] KVM: nVMX: Fix mmu context after VMLAUNCH/VMRESUME failure

[Wanpeng Li]

2017-11-09 18:40 GMT+08:00 Paolo Bonzini :
> On 09/11/2017 01:37, Wanpeng Li wrote:
>> 2017-11-09 5:47 GMT+08:00 Jim Mattson :
>>> I realize now that there are actually many other problems with
>>> deferring some control field checks to the hardware VM-entry of
>>> vmcs02. When there is an invalid control field, the vCPU should just
>>> fall through to the next instruction, without any state modifiation
>>> other than the ALU flags and the VM-instruction error field of the
>>> current VMCS. However, in preparation for the hardware VM-entry of
>>> vmcs02, we have already changed quite a bit of the vCPU state: the
>>> MSRs on the VM-entry MSR-load list, DR7, IA32_DEBUGCTL, the entire
>>> FLAGS register, etc. All of these changes should be undone, and we're
>>> not prepared to do that. (For instance, what was the old DR7 value
>>> that needs to be restored?)
>> I didn't observe real issue currently, and I hope this patchset can
>> catch the upcoming merge window. Then we can dig more into your
>> concern.
>
> Can any of you write a simple testcase for just one bug (e.g. DR7)?

Jim you can have a try for your concern, I have already tried tons of
stress testing and didn't observe any issue.

Regards,
Wanpeng Li

Re: [PATCH 00/15] Add support for clang LTO

[Marc Zyngier]

On 09/11/17 10:54, AKASHI Takahiro wrote:
> On Sat, Nov 04, 2017 at 02:13:04AM +, Mark Rutland wrote:
>> On Fri, Nov 03, 2017 at 12:56:47PM -0700, Sami Tolvanen wrote:
>>> On Fri, Nov 03, 2017 at 07:26:35PM +, Mark Rutland wrote:
 I guess that in Google you haven't tested on a platform with EL2
 available?
>>>
>>> Correct. I'll look into this and include a fix in v2. Does this work on a
>>> clang build without LTO?
>>
>> I saw this on v4.14-rc7, with patch 7 (-mno-implicit-float), but no other
>> patches from this series (i.e. no LTO).
> 
> 
> Add -fno-jump-tables to ccflags-y of arch/arm64/kvm/hyp/Makefile.
> Without this option, clang generates a branch instruction (br x11)
> to an absolute (EL1) virtual address.

Instead of adding more compiler flags to the Makefile, is there any way
to have that as a function attribute?

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

[PATCH 2/2] irqchip: mips-gic: Print warning if inherited GIC base is used

[Matt Redfearn]

If the physical address of the GIC resource cannot be read from device
tree, then the code falls back to reading it from the gcr_gic_base
register. Hopefully this has been set to a sane value by the bootloader
or some platform code, but is defined by the hardware manual to have
"undefined" reset state. Using it as the address at which the GIC will
be mapped into physical memory space can therefore be risky if it has
not been initialised, since it may result in the GIC being mapped to an
effectively random address anywhere in physical memory, where it might
conflict with peripherals or RAM and lead to weird crashes.

Since a "sane value" is very platform specific because it is particular
to the platform's memory map, it is difficult to test for. At the very
least, a warning message should be printed in the case that we trust the
inherited value.

Reported-by: Amit Kama 
Signed-off-by: Matt Redfearn 
Reviewed-by: Paul Burton 

---

 drivers/irqchip/irq-mips-gic.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
index 9b768899f07b..ef92a4d2038e 100644
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -701,6 +701,8 @@ static int __init gic_of_init(struct device_node *node,
gic_base = read_gcr_gic_base() &
~CM_GCR_GIC_BASE_GICEN;
gic_len = 0x2;
+   pr_warn("Using inherited base address %pa\n",
+   _base);
} else {
pr_err("Failed to get memory range\n");
return -ENODEV;
-- 
2.7.4

Re: [PATCH RESEND 2/3] KVM: Add paravirt remote TLB flush

[Paolo Bonzini]

On 09/11/2017 12:01, Wanpeng Li wrote:
> 2017-11-09 18:48 GMT+08:00 Paolo Bonzini :
>> On 09/11/2017 03:02, Wanpeng Li wrote:
>>> @@ -484,6 +511,8 @@ void __init kvm_guest_init(void)
>>>   pv_time_ops.steal_clock = kvm_steal_clock;
>>>   }
>>>
>>> + pv_mmu_ops.flush_tlb_others = kvm_flush_tlb_others;
>>
>> This needs to be keyed on a new CPUID feature bit.  Eduardo is also
> 
> Will do.
> 
>> adding a new "PV_DEDICATED" hint and you might disable PV TLB flush when
>> PV_DEDICATED is set.
> 
> Why disable PV TLB flush for PV_DEDICATED(qspinlock)?

PV_DEDICATED says pretty much that it is very unlikely to have a
preempted vCPU.  Therefore, the cpumask loop is unnecessary.

Paolo

Re: A test of the philosophical impact.. Unnud Oddox be with you

[Ywe Cærlyn]

Den 11/6/2017 19:13, skrev Ywe Cærlyn:

Den 11/6/2017 11:00, skrev Ywe Cærlyn:

Den 11/4/2017 23:53, skrev Ywe Cærlyn:

Den 11/3/2017 07:46, skrev Ywe Cærlyn:

Den 10/29/2017 17:21, skrev Ywe Cærlyn:

Den 10/29/2017 17:00, skrev Ywe Cærlyn:

Den 10/27/2017 23:28, skrev Ywe Cærlyn:

Den 10/27/2017 23:01, skrev Ywe Cærlyn:
Philosophical requantization of a (atm) theoretical linux 
distribution:


Excellent Ubuntu, is a Good Linux, with a Minimal Jitter Kernel.
An Available Source Operating System.
Philosophical Lead: Ywe Cærlyn.

Desktop Flavour: Customized Gnome

Finetuned for fast reponsiveness, and smoothness in operation. 
Configuration of Kernel, for favoring short buffers, lowest 
latency, minimal jitter, minimal wasted CPU, max cpu utilization.


Perfect scaling, from desktop to supercomputing.

Redefined Internet, with the finest philosophy, and correct 
attitude.


Call 999-Excellence for a trial CD... No that we don´t have 
yet, but how does it sound?


Peace,
Ywe Cærlyn.


I have made a good logo 
aswell:http://xn--ywecrlyn-m0a.net/ExcellentUbuntu/ExcellentUbuntu.png 



I really believe in this, and what makes this just perfect: 
Everyone is their own newsservice, getting their views on for 
instance, youtube. And gets the income from this. Which makes a 
finely granulated internet economy.


A test channel: 
https://www.youtube.com/channel/UCR3gmLVjHS5A702wo4bol_Q


Peace,
Ywe Cærlyn.


With Linus Torvalds as patchmeister as usual, ofcourse.

So considering this, and the finely granulated internet economics 
comes from this type of mindset, and with reintergration of it 
back, I would suggest changing the naming scheme of "open source", 
and "free software" to "Available Source". It is repeated a lot, 
and needs to have a corresponding name. (To not speak of avoiding 
uneccesary pointer variables in GNU code... ). This is also based 
on on my conclusion on philosophy research over 15 years, and that 
things need to be right. And even metaphysically. For Success. I 
also CC Richard Stallman on this, maybe GNU4.0 will make 
considerations for this. The hacker will now not only be free, but 
make money. ;)


Peace.



Mister GNU Richard Stallman replied me two times on this, since he 
did not mail LKML, I will restate them here, for the record.


|
|[[[ To any NSA and FBI agents reading my email: please consider    ]]]
|[[[ whether defending the US Constitution against all enemies, ]]]
|[[[ foreign or domestic, requires you to follow Snowden's example. 
]]]|

|
|It seems that you're making a new variant of GNU/Linux.  If you call
|it "something Linux", you are talking about our work but giving us
|none of the credit.  Please call it "something GNU/Linux" so as to
|give us equal mention.
|
|See https://gnu.org/gnu/linux-and-gnu.html and
|https://gnu.org/gnu/gnu-linux-faq.html, plus the history in
|https://gnu.org/gnu/the-gnu-project.html.
|
|--
|Dr Richard Stallman
|President, Free Software Foundation (gnu.org, fsf.org)
|Internet Hall-of-Famer (internethalloffame.org)
|Skype: No way! See stallman.org/skype.html.
|
And-

|
|[[[ To any NSA and FBI agents reading my email: please consider    ]]]
|[[[ whether defending the US Constitution against all enemies, ]]]
|[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
|
|"Available source" is too weak a criterion.  Free software and open
|source stand for categories of software that are nearly coterminous.
|However, available source is a much weaker criterion and would
|include programs that don't come anywhere near free.
|
|Also, the point of the free software movement is that users deserve
|freedom.  "Available source" doesn't even hint at this idea,
|so it would not communicate what we want to say.
|
|
|--
|Dr Richard Stallman
|President, Free Software Foundation (gnu.org, fsf.org)
|Internet Hall-of-Famer (internethalloffame.org)
|Skype: No way! See stallman.org/skype.html.
|

Not even an acknowledgement on pointer variables from this 
self-appointed spokesman for hackers. Or indeed the larger issue of 
finegranulated internet economics. How shall an OS indeed succeed if 
it chokes its own success?


To not speak of the paranoid insertions. Does he fear mountains 
shall fall on him, for GNU? Indeed GNU seems to be his qualifier and 
god, he slaves to.


Or is gnu, a god to slave to, free software your food, and Richard 
Stallman its Jesusian son? Will it be up to others to make the 
decision?


How much is this in conflict with pure hacking, from C64 asm, to PC 
C, and the original unix hacking?


Have a Mindful Zen moment on this.



As for my own experience, check out my Biit channel where I am going 
to go through highlights, and do DSP retrofits, remasters etc.


For instance this track: https://www.youtube.com/watch?v=xMfWsx3JBUg
Uses my own developed absolute minimal psychacoustically corrected 
phase plateau band EQ. Here I am even using these EQs in serial and 
parallel on the mix, and on the master, without 

Re: [PATCH v4] printk: Add console owner and waiter logic to loadbalance console writes

[Tetsuo Handa]

Michal Hocko wrote:
> On Thu 09-11-17 19:22:58, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > Hi,
> > > assuming that this passes warn stall torturing by Tetsuo, do you think
> > > we can drop 
> > > http://lkml.kernel.org/r/1509017339-4802-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
> > > from the mmotm tree?
> > 
> > I don't think so.
> > 
> > The rule that "do not try to printk() faster than the kernel can write to
> > consoles" will remain no matter how printk() changes. Unless asynchronous
> > approach like https://lwn.net/Articles/723447/ is used, I think we can't
> > obtain useful information.
> 
> Does that mean that the patch doesn't pass your test?
> 

Test is irrelevant. See the changelog.

  Synchronous approach is prone to unexpected results (e.g. too late [1], too
  frequent [2], overlooked [3]). As far as I know, warn_alloc() never helped
  with providing information other than "something is going wrong".
  I want to consider asynchronous approach which can obtain information
  during stalls with possibly relevant threads (e.g. the owner of oom_lock
  and kswapd-like threads) and serve as a trigger for actions (e.g. turn
  on/off tracepoints, ask libvirt daemon to take a memory dump of stalling
  KVM guest for diagnostic purpose).

  [1] https://bugzilla.kernel.org/show_bug.cgi?id=192981
  [2] 
http://lkml.kernel.org/r/cam_iqpwupvgc2ky8m-9yukects+zkjidasnymx7rmcbjbfy...@mail.gmail.com
  [3] commit db73ee0d46379922 ("mm, vmscan: do not loop on too_many_isolated 
for ever")

[PATCH 1/2] irqchip/mips-gic: Add pr_fmt and reword pr_* messages

[Matt Redfearn]

Several messages from the MIPS GIC driver include the text "GIC", but
the format is not standard. Add a pr_fmt of "irq-mips-gic: " and reword
the messages now that they will be prefixed with the driver name.

Signed-off-by: Matt Redfearn 
Reviewed-by: Paul Burton 
---

 drivers/irqchip/irq-mips-gic.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
index 3ccebb020f40..9b768899f07b 100644
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -6,6 +6,9 @@
  * Copyright (C) 2008 Ralf Baechle (r...@linux-mips.org)
  * Copyright (C) 2012 MIPS Technologies, Inc.  All rights reserved.
  */
+
+#define pr_fmt(fmt) "irq-mips-gic: " fmt
+
 #include 
 #include 
 #include 
@@ -685,7 +688,7 @@ static int __init gic_of_init(struct device_node *node,
 
cpu_vec = find_first_zero_bit(, hweight_long(ST0_IM));
if (cpu_vec == hweight_long(ST0_IM)) {
-   pr_err("No CPU vectors available for GIC\n");
+   pr_err("No CPU vectors available\n");
return -ENODEV;
}
 
@@ -699,7 +702,7 @@ static int __init gic_of_init(struct device_node *node,
~CM_GCR_GIC_BASE_GICEN;
gic_len = 0x2;
} else {
-   pr_err("Failed to get GIC memory range\n");
+   pr_err("Failed to get memory range\n");
return -ENODEV;
}
} else {
@@ -757,7 +760,7 @@ static int __init gic_of_init(struct device_node *node,
   gic_shared_intrs, 0,
   _irq_domain_ops, NULL);
if (!gic_irq_domain) {
-   pr_err("Failed to add GIC IRQ domain");
+   pr_err("Failed to add IRQ domain");
return -ENXIO;
}
 
@@ -766,7 +769,7 @@ static int __init gic_of_init(struct device_node *node,
  GIC_NUM_LOCAL_INTRS + 
gic_shared_intrs,
  node, _ipi_domain_ops, 
NULL);
if (!gic_ipi_domain) {
-   pr_err("Failed to add GIC IPI domain");
+   pr_err("Failed to add IPI domain");
return -ENXIO;
}
 
-- 
2.7.4

Re: [PATCH] add backlight level quirk for Asus ROG laptops

[Jiri Kosina]

On Sat, 28 Oct 2017, Mustafa Kuscu wrote:

> On laptops such as Asus GL553VD, setting keyboard backlight levels 
> does not work. This change enables F3/F4 keys to set backlight levels 
> (from 0 to 3, total 4 levels) on such laptops. 
> 
> It is intended only to the following device: 0x0b05 1854:
> P: Vendor=0b05 ProdID=1854 Rev=03.02
> S: Manufacturer=ITE Tech. Inc.
> S: Product=ITE Device(8910)
> 
> Note: Just reloading the hid_asus module would not suffice, reload 
> the whole thing or reboot, you know.
> 
> Signed-off-by: Mustafa C Kuscu 

I've reformatted the changelog/shortlog a little bit and applied to 
for-4.15/asus. Thanks,

-- 
Jiri Kosina
SUSE Labs

[GIT PULL] irqchip updates for 4.15, take 3

[Marc Zyngier]

Hi Thomas,

This is the third and final pile of updates from the irqchip
madhouse. On the menu, the STM32 update that has been lingering on the
list for a while, yet another Socionext irqchip driver, a fix for a
GICv4 facepalm bug, and a last minute MIPS cleanup.

>From now on, I'm only taking bug fixes.

Please pull.

   M.

The following changes since commit 61dc367e5d767e1c56147f6e497d13cc2771abb1:

  irqchip: mips-gic: Make IPI bitmaps static (2017-11-02 15:55:48 +)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git 
tags/irqchip-4.15-3

for you to fetch changes up to 666740fde412567aa0a8ea251ffee3004a6fa3a6:

  irqchip: mips-gic: Print warning if inherited GIC base is used (2017-11-09 
11:35:28 +)


irqchip updates for 4.15, take #3

- New Socionext Synquacer EXIU driver
- stm32 new platform support and fixes
- One GICv4 bugfix
- A couple of MIPS GIC cleanups


Ard Biesheuvel (2):
  dt-bindings: Add description of Socionext EXIU interrupt controller
  irqchip/exiu: Add support for Socionext Synquacer EXIU controller

Ludovic Barre (6):
  irqchip/stm32: Select GENERIC_IRQ_CHIP
  irqchip/stm32: Add multi-bank management
  dt-bindings/interrupt-controllers: Add compatible string for stm32h7
  irqchip/stm32: Add stm32h7 support
  irqchip/stm32: Fix initial values
  irqchip/stm32: Move the wakeup on interrupt mask

Marc Zyngier (1):
  irqchip/gic-v3-its: Fix VPE activate callback return value

Matt Redfearn (2):
  irqchip/mips-gic: Add pr_fmt and reword pr_* messages
  irqchip: mips-gic: Print warning if inherited GIC base is used

 .../socionext,synquacer-exiu.txt   |  32 +++
 .../interrupt-controller/st,stm32-exti.txt |   4 +-
 arch/arm64/Kconfig.platforms   |   3 +
 drivers/irqchip/Kconfig|   1 +
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-gic-v3-its.c   |   2 +-
 drivers/irqchip/irq-mips-gic.c |  13 +-
 drivers/irqchip/irq-sni-exiu.c | 227 +
 drivers/irqchip/irq-stm32-exti.c   | 206 ++-
 9 files changed, 434 insertions(+), 55 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/socionext,synquacer-exiu.txt
 create mode 100644 drivers/irqchip/irq-sni-exiu.c

Re: [PATCH] usb: gadget: f_fs: Fix use-after-free in ffs_free_inst

[Greg KH]

On Wed, Nov 08, 2017 at 10:13:15AM -0700, Andrew Gabbasov wrote:
> KASAN enabled configuration reports an error
> 
> BUG: KASAN: use-after-free in ffs_free_inst+... [usb_f_fs] at addr ...
> Write of size 8 by task ...
> 
> This is observed after "ffs-test" is run and interrupted. If after that
> functionfs is unmounted and g_ffs module is unloaded, that use-after-free
> occurs during g_ffs module removal.
> 
> Although the report indicates ffs_free_inst() function, the actual
> use-after-free condition occurs in _ffs_free_dev() function, which
> is probably inlined into ffs_free_inst().
> 
> This happens due to keeping the ffs_data reference in device structure
> during functionfs unmounting, while ffs_data itself is freed as no longer
> needed. The fix is to clear that reference in ffs_closed() function,
> which is a counterpart of ffs_ready(), where the reference is stored.
> 
> Fixes: 3262ad824307 ("usb: gadget: f_fs: Stop ffs_closed NULL pointer 
> dereference")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Andrew Gabbasov 
> ---
>  drivers/usb/gadget/function/f_fs.c | 1 +
>  1 file changed, 1 insertion(+)

Felipe, want me to take this directly?

thanks,

greg k-h

[PATCH v3] powerpc/kernel/sysfs: Export ldbar spr to sysfs

[Anju T Sudhakar]

Add ldbar spr to sysfs. The spr holds thread level In-Memory Collection (IMC)   

counter configuration data. Exposing this will help to understand the current
configuration of thread-level counters in the system.
Primarily, Bit 0 of ldbar says whether the counters are enabled or not.
And bit 1 indicates the mode (if 0-Accumulation Mode/if 1-Trace Mode). 

Signed-off-by: Anju T Sudhakar 
---
 arch/powerpc/kernel/sysfs.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 4437c70..f8caee0 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -485,6 +485,7 @@ SYSFS_PMCSETUP(mmcra, SPRN_MMCRA);
 SYSFS_SPRSETUP(purr, SPRN_PURR);
 SYSFS_SPRSETUP(spurr, SPRN_SPURR);
 SYSFS_SPRSETUP(pir, SPRN_PIR);
+SYSFS_SPRSETUP(ldbar, SPRN_LDBAR);
 
 /*
   Lets only enable read for phyp resources and
@@ -492,6 +493,7 @@ SYSFS_SPRSETUP(pir, SPRN_PIR);
   Lets be conservative and default to pseries.
 */
 static DEVICE_ATTR(mmcra, 0600, show_mmcra, store_mmcra);
+static DEVICE_ATTR(ldbar, 0400, show_ldbar, store_ldbar);
 static DEVICE_ATTR(spurr, 0400, show_spurr, NULL);
 static DEVICE_ATTR(purr, 0400, show_purr, store_purr);
 static DEVICE_ATTR(pir, 0400, show_pir, NULL);
@@ -757,6 +759,9 @@ static int register_cpu_online(unsigned int cpu)
device_create_file(s, _attrs[i]);
 
 #ifdef CONFIG_PPC64
+   if (cpu_has_feature(CPU_FTR_ARCH_300))
+   device_create_file(s, _attr_ldbar);
+
if (cpu_has_feature(CPU_FTR_MMCRA))
device_create_file(s, _attr_mmcra);
 
@@ -842,6 +847,9 @@ static int unregister_cpu_online(unsigned int cpu)
device_remove_file(s, _attrs[i]);
 
 #ifdef CONFIG_PPC64
+   if (cpu_has_feature(CPU_FTR_ARCH_300))
+   device_remove_file(s, _attr_ldbar);
+
if (cpu_has_feature(CPU_FTR_MMCRA))
device_remove_file(s, _attr_mmcra);
 
-- 
2.7.4

Re: [PATCH 2/2] kbuild: handle dtb-y and CONFIG_OF_ALL_DTBS natively in Makefile.lib

[Masahiro Yamada]

Hi James,


2017-11-09 21:19 GMT+09:00 James Hogan :
> (resend using a working From address)
>
>  wrote:
>> If CONFIG_OF_ALL_DTBS is enabled, "make ARCH=arm64 dtbs" compiles each
>> DTB twice; one from arch/arm64/boot/dts/*/Makefile and the other from
>> the dtb-$(CONFIG_OF_ALL_DTBS) line in arch/arm64/boot/dts/Makefile.
>> It could be a race problem when building DTBS in parallel.
>>
>> Another minor issue is CONFIG_OF_ALL_DTBS covers only *.dts in vendor
>> sub-directories, so this broke when Broadcom added one more hierarchy
>> in arch/arm64/boot/dts/broadcom//.
>>
>> One idea to fix the issues in a clean way is to move DTB handling
>> to Kbuild core scripts.  Makefile.dtbinst already recognizes dtb-y
>> natively, so it should not hurt to do so.
>>
>> Add $(dtb-y) to extra-y, and $(dtb-) as well if CONFIG_OF_ALL_DTBS is
>> enabled.  All clutter things in Makefiles go away.
>>
>> As a bonus clean-up, I also removed dts-dirs.  Just use subdir-y
>> directly to traverse sub-directories.
>>
>> Signed-off-by: Masahiro Yamada 
>
>  ...
>
>> diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
>> index 7891ffa..b2b0d88 100644
>> --- a/arch/mips/boot/dts/Makefile
>> +++ b/arch/mips/boot/dts/Makefile
>> @@ -1,20 +1,14 @@
>> -dts-dirs   += brcm
>> -dts-dirs   += cavium-octeon
>> -dts-dirs   += img
>> -dts-dirs   += ingenic
>> -dts-dirs   += lantiq
>> -dts-dirs   += mti
>> -dts-dirs   += netlogic
>> -dts-dirs   += ni
>> -dts-dirs   += pic32
>> -dts-dirs   += qca
>> -dts-dirs   += ralink
>> -dts-dirs   += xilfpga
>> +subdir-y   += brcm
>> +subdir-y   += cavium-octeon
>> +subdir-y   += img
>> +subdir-y   += ingenic
>> +subdir-y   += lantiq
>> +subdir-y   += mti
>> +subdir-y   += netlogic
>> +subdir-y   += ni
>> +subdir-y   += pic32
>> +subdir-y   += qca
>> +subdir-y   += ralink
>> +subdir-y   += xilfpga
>>
>> -obj-y  := $(addsuffix /, $(dts-dirs))
>> -
>> -dtstree:= $(srctree)/$(src)
>> -dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb, $(foreach 
>> d,$(dts-dirs), $(wildcard $(dtstree)/$(d)/*.dts)))
>> -
>> -always := $(dtb-y)
>> -subdir-y   := $(dts-dirs)
>> +obj-$(BUILTIN_DTB) := $(addsuffix /, $(subdir-y))
>
> I wonder if that should be CONFIG_BUILTIN_DTB?
>
> This is causing failures in linux-next with MIPS
> cavium_octeon_defconfig like below, and changing this line to
> CONFIG_BUILTIN_DTB seems to fix it.

Good catch!


Rob,
Can you fix it to CONFIG_BUILTIN_DTB?

Thanks!



> arch/mips/cavium-octeon/setup.o: In function `__octeon_is_model_runtime__':
> /work/mips/linux/main/./arch/mips/include/asm/octeon/octeon-model.h:368:
> undefined reference to `__dtb_octeon_3xxx_begin'
> arch/mips/cavium-octeon/setup.o: In function `device_tree_init':
> /work/mips/linux/main/arch/mips/cavium-octeon/setup.c:1188: undefined
> reference to `__dtb_octeon_3xxx_begin'
> /work/mips/linux/main/arch/mips/cavium-octeon/setup.c:1184: undefined
> reference to `__dtb_octeon_68xx_begin'
> /work/mips/linux/main/arch/mips/cavium-octeon/setup.c:1184: undefined
> reference to `__dtb_octeon_68xx_begin'
>
> Thanks
> James
>
>


-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2 2/4] kaslr: select the memory region in immovable node to process

[Baoquan He]

Hi Chao,

On 11/01/17 at 07:32pm, Chao Fan wrote:
> Compare the region of memmap entry and immovable_mem, then choose the
> intersection to process_mem_region.
> 
> Since the interrelationship between e820 or efi entries and memory
> region in immovable_mem is different:

Could you paste a bootlog with efi=debug specified in cmdline on the
system you tested? I want to check what kind of intersection between
them. The adding makes code pretty ugly, want to make sure if we have
to do like this.

Thanks
Baoquan

> One memory region in one node may contain several entries of e820 or
> efi sometimes, and one entry of e820 or efi may contain the memory in
> different nodes sometimes.
> It may split one node or one entry to several regions.
> 
> Signed-off-by: Chao Fan 
> ---
>  arch/x86/boot/compressed/kaslr.c | 60 
> ++--
>  1 file changed, 52 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/boot/compressed/kaslr.c 
> b/arch/x86/boot/compressed/kaslr.c
> index 0a591c0023f1..fcd640fdeaed 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -634,6 +634,54 @@ static void process_mem_region(struct mem_vector *entry,
>   }
>  }
>  
> +static bool select_immovable_node(struct mem_vector region,
> +   unsigned long long minimum,
> +   unsigned long long image_size)
> +{
> + int i;
> +
> + /* If no immovable_mem stored, use region directly */
> + if (num_immovable_region == 0) {
> + process_mem_region(, minimum, image_size);
> +
> + if (slot_area_index == MAX_SLOT_AREA) {
> + debug_putstr("Aborted memmap scan (slot_areas 
> full)!\n");
> + return 1;
> + }
> + } else {
> + /*
> +  * Walk all immovable regions, and filter the intersection
> +  * to process_mem_region.
> +  */
> + for (i = 0; i < num_immovable_region; i++) {
> + struct mem_vector entry;
> + unsigned long long start, end, select_end, region_end;
> +
> + region_end = region.start + region.size - 1;
> + start = immovable_mem[i].start;
> + end = start + immovable_mem[i].size - 1;
> +
> + if (region_end < start || region.start > end)
> + continue;
> +
> + /* May split one region to several entries. */
> + entry.start = start > region.start ?
> +   start : region.start;
> + select_end = end > region_end ? region_end : end;
> +
> + entry.size = select_end - entry.start + 1;
> +
> + process_mem_region(, minimum, image_size);
> +
> + if (slot_area_index == MAX_SLOT_AREA) {
> + debug_putstr("Aborted memmap scan (slot_areas 
> full)!\n");
> + return 1;
> + }
> + }
> + }
> + return 0;
> +}
> +
>  #ifdef CONFIG_EFI
>  /*
>   * Returns true if mirror region found (and must have been processed
> @@ -699,11 +747,9 @@ process_efi_entries(unsigned long minimum, unsigned long 
> image_size)
>  
>   region.start = md->phys_addr;
>   region.size = md->num_pages << EFI_PAGE_SHIFT;
> - process_mem_region(, minimum, image_size);
> - if (slot_area_index == MAX_SLOT_AREA) {
> - debug_putstr("Aborted EFI scan (slot_areas full)!\n");
> +
> + if (select_immovable_node(region, minimum, image_size))
>   break;
> - }
>   }
>   return true;
>  }
> @@ -730,11 +776,9 @@ static void process_e820_entries(unsigned long minimum,
>   continue;
>   region.start = entry->addr;
>   region.size = entry->size;
> - process_mem_region(, minimum, image_size);
> - if (slot_area_index == MAX_SLOT_AREA) {
> - debug_putstr("Aborted e820 scan (slot_areas full)!\n");
> +
> + if (select_immovable_node(region, minimum, image_size))
>   break;
> - }
>   }
>  }
>  
> -- 
> 2.13.6
> 
> 
> 

Re: [PATCH v2 2/2] sparc: pass endianness info to sparse

[Christoph Hellwig]

On Thu, Nov 09, 2017 at 07:16:52AM +0100, Luc Van Oostenryck wrote:
> sparc is big-endian only but sparse assumes the same endianness
> as the building machine.
> This is problematic for code which expect __BYTE_ORDER__ being
> correctly predefined by the compiler which sparse can then
> pre-process differently from what gcc would, depending on the
> building machine endianness.
> 
> Fix this by letting sparse know about the architecture endianness.

You're posted patches for this for about half a dozen architectures
now, but we also now have generic Kconfig symbols for the byte order.

I'd much rather see this done in generic code than hacking it up
everywhere.

Re: [PATCH] ARM: dts: add phy-reset property for rk3066a-rayeager emac

[Roger Quadros]

On 09/11/17 10:28, Roger Quadros wrote:
> On 08/11/17 11:49, Chris Zhong wrote:
>> Hi Florian Fainelli
>>
>>
>> On 2017年11月08日 02:26, Florian Fainelli wrote:
>>> On 11/07/2017 01:51 AM, Chris Zhong wrote:

 On 2017年11月07日 15:54, Vladimir Zapolskiy wrote:
> Hello Chris,
>
> On 11/07/2017 04:49 AM, Chris Zhong wrote:
>> The ethernet phy of rk3066a-rayeager has a reset pin, it controlled by
>> GPIO1_D6, this pin should be pull down then pull up to reset the phy.
>> Add a phy-reset property in emac, make the phy can be reset when emac
>> power on.
> for PHY reset there are properties 'reset-gpios' and 'reset-delay-us',
> please reference to Documentation/devicetree/bindings/net/mdio.txt
>
> Can you try to reuse them instead of adding new custom properties?
 This phy-reset is from Documentation/devicetree/bindings/net/arc_emac.txt.
 And copy from arch/arm/boot/dts/rk3036-kylin.dts.
 Can we just use these properties, they are not new.
>>> Because it already exists does not mean it's correct, in fact, it is not
>>> at all because it places the reset property for a PHY into the MAC node,
>>> which is just not what this is, what we should be using instead is the
>>> following patch series:
>>>
>>> http://patchwork.ozlabs.org/project/netdev/list/?series=9267
>>>
>>> http://patchwork.ozlabs.org/patch/828499/
>>> http://patchwork.ozlabs.org/patch/828505/
>>> http://patchwork.ozlabs.org/patch/828501/
>>> http://patchwork.ozlabs.org/patch/828502/
>> Okay, this series works for me, and I will push a new version patch 
>> following it,
>> with a reset-gpios property under phy node.
>> And hope this series can be applied soon.
>>
> 
> If 'reset-gpios' and 'reset-delay-us' as per [1] works for you
> then why not use that?
> 
> [1] Documentation/devicetree/bindings/net/mdio.txt

I take back my statement.

You should use the above only if you have a single reset line connected to 
multiple PHYs
on the same MDIO bus.
In all other cases the reset properties should be part of PHY device node.

However, we need to still ensure that the mdio_bus driver issues the reset. 
This piece
is still missing in the code.

> 
>> Thanks
>> Chris Zhong
>>
>>
> As a side question, which is mainly addressed to Sergei and Roger,
> I don't quite understand why PHY properties were initially added to
> MAC/MDIO bus device tree nodes, in my opinion they must be moved under
> PHY device tree nodes.
>
> -- 
> With best wishes,
> Vladimir
>
>> Signed-off-by: Chris Zhong 
>> ---
>>
>>    arch/arm/boot/dts/rk3066a-rayeager.dts | 2 ++
>>    1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/rk3066a-rayeager.dts
>> b/arch/arm/boot/dts/rk3066a-rayeager.dts
>> index 570157f..6064a0a 100644
>> --- a/arch/arm/boot/dts/rk3066a-rayeager.dts
>> +++ b/arch/arm/boot/dts/rk3066a-rayeager.dts
>> @@ -173,6 +173,8 @@
>>    pinctrl-0 = <_xfer>, <_mdio>, <_rst>;
>>    phy = <>;
>>    phy-supply = <_rmii>;
>> +    phy-reset-gpios = < RK_PD6 GPIO_ACTIVE_LOW>; /* PHY_RST */
>> +    phy-reset-duration = <10>; /* millisecond */
>>    status = "okay";
>>  phy0: ethernet-phy@0 {
>>
>
>>>
>>
> 

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH] net: sfc: remove redundant variable start

[Bert Kenward]

On 09/11/17 08:01, Colin King wrote:
> From: Colin Ian King 
> 
> Variable start is assigned but never read hence it is redundant
> and can be removed. Cleans up clang warning:
> 
> drivers/net/ethernet/sfc/ptp.c:655:2: warning: Value stored to 'start'
> is never read
> 
> Signed-off-by: Colin Ian King 

Acked-by: Bert Kenward 

Thanks Colin.

> ---
>  drivers/net/ethernet/sfc/ptp.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/sfc/ptp.c b/drivers/net/ethernet/sfc/ptp.c
> index 56c2db398def..caa89bf7603e 100644
> --- a/drivers/net/ethernet/sfc/ptp.c
> +++ b/drivers/net/ethernet/sfc/ptp.c
> @@ -648,11 +648,9 @@ static void efx_ptp_send_times(struct efx_nic *efx,
>   struct pps_event_time now;
>   struct timespec64 limit;
>   struct efx_ptp_data *ptp = efx->ptp_data;
> - struct timespec64 start;
>   int *mc_running = ptp->start.addr;
>  
>   pps_get_ts();
> - start = now.ts_real;
>   limit = now.ts_real;
>   timespec64_add_ns(, SYNCHRONISE_PERIOD_NS);
>  
> 

pt_regs usage in cpuacct_charge()

[Pavel V. Panteleev]

Hello!

In cpuacct_charge() function pt_regs of other thread could be used. 
There is a such call chain: ...-> __schedule -> pick_next_task_fair -> 
load_balance -> idle_balance -> load_balance -> detach_tasks -> 
deactivate_task -> dequeue_task_fair -> dequeue_entity -> update_curr -> 
cpuacct_charge.


I think that pt_regs could disappeared or be changed. How it's assumed 
to syncronize pt_regs usage in this place?


Kernel verion 4.9.47-rt47.


Best regards,
Pavel V. Panteleev

Re: [PATCH v2] s390/virtio: mark headers as BSD licensed

[Cornelia Huck]

On Thu, 9 Nov 2017 09:29:32 +0100
Christian Borntraeger  wrote:

> On 11/08/2017 08:58 PM, Michael S. Tsirkin wrote:
> > On Wed, Nov 08, 2017 at 08:39:11PM +0100, Christian Borntraeger wrote:  
> >>
> >>
> >> On 11/08/2017 08:35 PM, Michael S. Tsirkin wrote:  
> >>> On Wed, Nov 08, 2017 at 07:57:28PM +0100, Christian Borntraeger wrote:  
>  So what about the following
> 
>  - leave kvm_virtio.h unchanged and we will delete this file via the s390 
>  tree  
> >>>
> >>> Seems to be used by kvm_virtio.c - are you removing that too?  
> >>
> >> Yes, so sorry my first url for the git.kernel.org was in the wrong 
> >> subfolder:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit?h=features=7fb2b2d512448cf0e914c4647a1cf02b52263702
> >>
> >>  
> >>>  
>  - change virtio_ccw.h to BSD license. The content of this file is really 
>  really trivial
>  and it boils down to 2 defines, that can be easily reconstructed by 
>  looking at the virtio spec.
>  Not even sure if something like this can be copyrighted.  
> >>>
> >>> Yes. What prompted this was Greg's patch.
> >>>  
> 
>  For reference the content of this file minus comments is
> 
>  - snip -
>  #define KVM_VIRTIO_CCW_RING_ALIGN 4096
>  #define KVM_S390_VIRTIO_CCW_NOTIFY 3
>  - snip -
> 
>   
> >>
> >> [..]  
> > 
> > 
> > So for ccw if both you and Cornelia ACK, we'll be fine I think.
> > No one else touched this code.  
> 
> A patch that changes virtio_ccw.h to a dual gpl2/bsd licence is
> 
> Acked-by: Christian Borntraeger 
> 
> as it matches the original intent of the virtio header relicensing
> from 2008 while at the same time covers the fact that the whole 
> kernel is GPL2.
> 

FWIW, that would be

Acked-by: Cornelia Huck 

as well (I wrote the header, but any copyright is with IBM).

[PATCH v2 00/10] staging: ccree: fixes and cleanups

[Gilad Ben-Yossef]

This is another batch of ccree fixes & cleanups.

The first patch is a bug fix. All others are pure
readability and coding style fixes.

Changes from v1:
- Fix several coding style issues pointed out by
  Dan Carpenter.
- Added two more patches of similar issues that
  surfaced during the review.

Gilad Ben-Yossef (10):
  staging: ccree: fix leak of import() after init()
  staging: ccree: make long func call sites readable
  staging: ccree: simplify AEAD using local var
  staging: ccree: simplify buf mgr using local vars
  staging: ccree: fold common code into function
  staging: ccree: simplify pm manager using local var
  staging: ccree: remove unneeded cast
  staging: ccree: remove compare to none zero
  staging: ccree: remove braces for single statement
  staging: ccree: remove unused cc_base parameter

 drivers/staging/ccree/ssi_aead.c|  60 ++--
 drivers/staging/ccree/ssi_buffer_mgr.c  | 553 ++--
 drivers/staging/ccree/ssi_buffer_mgr.h  |  49 ++-
 drivers/staging/ccree/ssi_cipher.c  |  39 ++-
 drivers/staging/ccree/ssi_driver.c  |  51 ++-
 drivers/staging/ccree/ssi_driver.h  |   2 +-
 drivers/staging/ccree/ssi_hash.c| 201 ++--
 drivers/staging/ccree/ssi_ivgen.c   |   4 +-
 drivers/staging/ccree/ssi_pm.c  |  46 ++-
 drivers/staging/ccree/ssi_pm.h  |  12 +-
 drivers/staging/ccree/ssi_request_mgr.c |  29 +-
 drivers/staging/ccree/ssi_request_mgr.h |   6 +-
 drivers/staging/ccree/ssi_sram_mgr.c|  13 +-
 drivers/staging/ccree/ssi_sram_mgr.h|   6 +-
 14 files changed, 502 insertions(+), 569 deletions(-)

-- 
2.7.4

Re: [PATCH v4 01/17] PCI: dwc: Use the DMA-API to get the MSI address

[Niklas Cassel]

On 11/08/2017 06:27 PM, Bjorn Helgaas wrote:
> On Wed, Nov 08, 2017 at 12:45:49PM +, Joao Pinto wrote:
>> Hello to all,
>>
>> Às 12:56 AM de 11/8/2017, Bjorn Helgaas escreveu:
>>> On Fri, Nov 03, 2017 at 02:47:05PM +0100, Niklas Cassel wrote:
 Use the DMA-API to get the MSI address. This address will be written to
 our PCI config space and to the register which determines which AXI
 address the DWC IP will spoof for incoming MSI irqs.

 Since it is a PCIe endpoint device, rather than the CPU, that is supposed
 to write to the MSI address, the proper way to get the MSI address is by
 using the DMA API, not by using virt_to_phys().

 Using virt_to_phys() might work on some systems, but using the DMA API
 should work on all systems.

 This is essentially the same thing as allocating a buffer in a driver
 to which the endpoint will write to. To do this, we use the DMA API.

 Signed-off-by: Niklas Cassel 
>>>
>>> I'm expecting Jingoo and/or Joao to chime in and ack the
>>> DesignWare-related patches.  I think all the others are in
>>> pretty good shape.
>>>
 ---
  drivers/pci/dwc/pcie-designware-host.c | 15 ---
  drivers/pci/dwc/pcie-designware.h  |  3 ++-
  2 files changed, 14 insertions(+), 4 deletions(-)
 ...
>>
>> Let me test this patch-set in my setup first!
>> I will give feedback until Friday.
> 
> OK, thanks.  This may push this series out until v4.16 because the
> v4.15 merge window will probably open Sunday, and I don't like to add
> code during the window and merge it immediately.
> 

I suspected as much. The general rule seems to be that
a patch has to be in linux-next for at least 2 weeks
before sending it to Linus.

No worries, there is not really a rush.

Regards,
Niklas

Re: [PATCH] staging: ccree: remove unused pointer cc_base

[Gilad Ben-Yossef]

Hi Colin,

Thank you very much for your patch.

On Thu, Nov 9, 2017 at 10:13 AM, Colin King  wrote:
> From: Colin Ian King 
>
> Pointer cc_base is being assigned but is never read, hence it is
> redundant and can be removed. Cleans up clang warning:
>
> drivers/staging/ccree/ssi_driver.c:235:2: warning: Value stored to
> 'cc_base' is never read
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/staging/ccree/ssi_driver.c | 3 ---
>  1 file changed, 3 deletions(-)

Your patch is perfectly fine but I just happened to send a patch
series that includes
this fix but also deals with  other occurrences of the same now
no-longer needed cc_base
variable just a second ago before checking my email...

Sorry about that and thanks again.

Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Legal question: Author, Sign-off, Company Copyright and gmail

[Daniel Lezcano]

Hi all,

I noticed a practice when the patches are submitted where I'm a bit
confused about how it fits with the DCO.

People are creating gmail accounts to send patches on behalf of their
company because the company's email configuration does not allow to send
patches or adds extra infos, or whatever...

That ends up with patches submitted by a gmail account with no history
and verifiable origin and new files containing a company copyright [1].

At the first glance I would say, it is not allowed, and if a company is
willing to do opensource, it should provide the tools to its employees
to do so. But I don't want block patch submission if this practice is
tolerated.

What is the policy in this case ?

Thanks in advance.

  -- Daniel

[1] https://patchwork.kernel.org/patch/10045815/

-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 02/31] nds32: Kernel booting and initialization

[Greentime Hu]

2017-11-08 21:38 GMT+08:00 Rob Herring :
> On Tue, Nov 7, 2017 at 11:54 PM, Greentime Hu  wrote:
>> From: Greentime Hu 
>>
>
> Commit message needed.

Thanks.
I will add more commit messages in the next version patch.

>
>> Signed-off-by: Vincent Chen 
>> Signed-off-by: Greentime Hu 
>> ---
>
>> +   /* it could update max_pfn */
>> +   if (max_pfn - ram_start_pfn <= MAXMEM_PFN)
>> +   max_low_pfn = max_pfn;
>> +   else {
>> +   max_low_pfn = MAXMEM_PFN + ram_start_pfn;
>> +#ifndef CONFIG_HIGHMEM
>
> Use IS_ENABLED here and other ifdef's if possible.
>

Thanks
I will try to use IS_ENABLED here in the next version patch.

>> +   max_pfn = MAXMEM_PFN + ram_start_pfn;
>> +#endif
>> +   }
>
>
>> +static int __init nds32_device_probe(void)
>> +{
>> +   return of_platform_populate(NULL, NULL, NULL, NULL);
>> +}
>> +
>> +device_initcall(nds32_device_probe);
>
> You can drop this. The core code will call of_platform_populate for you.

Thanks.
I will drop this in the next version patch.

Re: [PATCH v4] printk: Add console owner and waiter logic to loadbalance console writes

[Michal Hocko]

On Thu 09-11-17 19:22:58, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > Hi,
> > assuming that this passes warn stall torturing by Tetsuo, do you think
> > we can drop 
> > http://lkml.kernel.org/r/1509017339-4802-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
> > from the mmotm tree?
> 
> I don't think so.
> 
> The rule that "do not try to printk() faster than the kernel can write to
> consoles" will remain no matter how printk() changes. Unless asynchronous
> approach like https://lwn.net/Articles/723447/ is used, I think we can't
> obtain useful information.

Does that mean that the patch doesn't pass your test?

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2] mm, shrinker: make shrinker_list lockless

[Tetsuo Handa]

On 2017/11/09 2:37, Shakeel Butt wrote:
> In our production, we have observed that the job loader gets stuck for
> 10s of seconds while doing mount operation. It turns out that it was
> stuck in register_shrinker() and some unrelated job was under memory
> pressure and spending time in shrink_slab(). Our machines have a lot
> of shrinkers registered and jobs under memory pressure has to traverse
> all of those memcg-aware shrinkers and do affect unrelated jobs which
> want to register their own shrinkers.
> 
> This patch has made the shrinker_list traversal lockless and shrinker
> register remain fast. For the shrinker unregister, atomic counter
> has been introduced to avoid synchronize_rcu() call. The fields of
> struct shrinker has been rearraged to make sure that the size does
> not increase for x86_64.
> 
> The shrinker functions are allowed to reschedule() and thus can not
> be called with rcu read lock. One way to resolve that is to use
> srcu read lock but then ifdefs has to be used as SRCU is behind
> CONFIG_SRCU. Another way is to just release the rcu read lock before
> calling the shrinker and reacquire on the return. The atomic counter
> will make sure that the shrinker entry will not be freed under us.
> 
> Signed-off-by: Shakeel Butt 
> ---
> Changelog since v1:
> - release and reacquire rcu lock across shrinker call.
> 
>  include/linux/shrinker.h |  4 +++-
>  mm/vmscan.c  | 54 
> ++--
>  2 files changed, 37 insertions(+), 21 deletions(-)
> 

If you can accept serialized register_shrinker()/unregister_shrinker(),
I think that something like shown below can do it.

--
diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h
index 388ff29..e2272dd 100644
--- a/include/linux/shrinker.h
+++ b/include/linux/shrinker.h
@@ -62,9 +62,10 @@ struct shrinker {
 
int seeks;  /* seeks to recreate an obj */
long batch; /* reclaim batch size, 0 = default */
-   unsigned long flags;
+   unsigned int flags;
 
/* These are for internal use */
+   atomic_t nr_active; /* Counted only if !SHRINKER_PERMANENT */
struct list_head list;
/* objs pending delete, per node */
atomic_long_t *nr_deferred;
@@ -74,6 +75,7 @@ struct shrinker {
 /* Flags */
 #define SHRINKER_NUMA_AWARE(1 << 0)
 #define SHRINKER_MEMCG_AWARE   (1 << 1)
+#define SHRINKER_PERMANENT (1 << 2)
 
 extern int register_shrinker(struct shrinker *);
 extern void unregister_shrinker(struct shrinker *);
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 1c1bc95..e963359 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -157,7 +157,7 @@ struct scan_control {
 unsigned long vm_total_pages;
 
 static LIST_HEAD(shrinker_list);
-static DECLARE_RWSEM(shrinker_rwsem);
+static DEFINE_MUTEX(shrinker_lock);
 
 #ifdef CONFIG_MEMCG
 static bool global_reclaim(struct scan_control *sc)
@@ -285,9 +285,10 @@ int register_shrinker(struct shrinker *shrinker)
if (!shrinker->nr_deferred)
return -ENOMEM;
 
-   down_write(_rwsem);
-   list_add_tail(>list, _list);
-   up_write(_rwsem);
+   atomic_set(>nr_active, 0);
+   mutex_lock(_lock);
+   list_add_tail_rcu(>list, _list);
+   mutex_unlock(_lock);
return 0;
 }
 EXPORT_SYMBOL(register_shrinker);
@@ -297,9 +298,14 @@ int register_shrinker(struct shrinker *shrinker)
  */
 void unregister_shrinker(struct shrinker *shrinker)
 {
-   down_write(_rwsem);
-   list_del(>list);
-   up_write(_rwsem);
+   BUG_ON(shrinker->flags & SHRINKER_PERMANENT);
+   mutex_lock(_lock);
+   list_del_rcu(>list);
+   synchronize_rcu();
+   while (atomic_read(>nr_active))
+   msleep(1);
+   synchronize_rcu();
+   mutex_unlock(_lock);
kfree(shrinker->nr_deferred);
 }
 EXPORT_SYMBOL(unregister_shrinker);
@@ -468,18 +474,9 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
if (nr_scanned == 0)
nr_scanned = SWAP_CLUSTER_MAX;
 
-   if (!down_read_trylock(_rwsem)) {
-   /*
-* If we would return 0, our callers would understand that we
-* have nothing else to shrink and give up trying. By returning
-* 1 we keep it going and assume we'll be able to shrink next
-* time.
-*/
-   freed = 1;
-   goto out;
-   }
-
-   list_for_each_entry(shrinker, _list, list) {
+   rcu_read_lock();
+   list_for_each_entry_rcu(shrinker, _list, list) {
+   bool permanent;
struct shrink_control sc = {
.gfp_mask = gfp_mask,
.nid = nid,
@@ -498,11 +495,16 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
if (!(shrinker->flags & SHRINKER_NUMA_AWARE))
sc.nid = 0;
 
+   permanent = (shrinker->flags & 

Re: [PATCH 02/30] x86, tlb: make CR4-based TLB flushes more robust

[Thomas Gleixner]

On Thu, 9 Nov 2017, Borislav Petkov wrote:
> On Wed, Nov 08, 2017 at 11:46:49AM -0800, Dave Hansen wrote:
> > +   /* Put original CR4 value back: */
> > native_write_cr4(cr4);
> >  }
> 
> Btw, Andy, we read the CR4 shadow in that function but we don't update
> it. Why?

Because its the same as before.

> > +   /* Put original CR4 value back: */
> > native_write_cr4(cr4);

Thanks,

tglx

Re: [PATCH 00/15] Add support for clang LTO

[AKASHI Takahiro]

On Sat, Nov 04, 2017 at 02:13:04AM +, Mark Rutland wrote:
> On Fri, Nov 03, 2017 at 12:56:47PM -0700, Sami Tolvanen wrote:
> > On Fri, Nov 03, 2017 at 07:26:35PM +, Mark Rutland wrote:
> > > I guess that in Google you haven't tested on a platform with EL2
> > > available?
> > 
> > Correct. I'll look into this and include a fix in v2. Does this work on a
> > clang build without LTO?
> 
> I saw this on v4.14-rc7, with patch 7 (-mno-implicit-float), but no other
> patches from this series (i.e. no LTO).


Add -fno-jump-tables to ccflags-y of arch/arm64/kvm/hyp/Makefile.
Without this option, clang generates a branch instruction (br x11)
to an absolute (EL1) virtual address.

-Takahiro AKASHI

> Thanks,
> Mark.

Re: [PATCH v4] printk: Add console owner and waiter logic to loadbalance console writes

[Michal Hocko]

On Thu 09-11-17 20:03:30, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Thu 09-11-17 19:22:58, Tetsuo Handa wrote:
> > > Michal Hocko wrote:
> > > > Hi,
> > > > assuming that this passes warn stall torturing by Tetsuo, do you think
> > > > we can drop 
> > > > http://lkml.kernel.org/r/1509017339-4802-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
> > > > from the mmotm tree?
> > > 
> > > I don't think so.
> > > 
> > > The rule that "do not try to printk() faster than the kernel can write to
> > > consoles" will remain no matter how printk() changes. Unless asynchronous
> > > approach like https://lwn.net/Articles/723447/ is used, I think we can't
> > > obtain useful information.
> > 
> > Does that mean that the patch doesn't pass your test?
> > 
> 
> Test is irrelevant. See the changelog.
> 
>   Synchronous approach is prone to unexpected results (e.g. too late [1], too
>   frequent [2], overlooked [3]). As far as I know, warn_alloc() never helped
>   with providing information other than "something is going wrong".
>   I want to consider asynchronous approach which can obtain information
>   during stalls with possibly relevant threads (e.g. the owner of oom_lock
>   and kswapd-like threads) and serve as a trigger for actions (e.g. turn
>   on/off tracepoints, ask libvirt daemon to take a memory dump of stalling
>   KVM guest for diagnostic purpose).
> 
>   [1] https://bugzilla.kernel.org/show_bug.cgi?id=192981
>   [2] 
> http://lkml.kernel.org/r/cam_iqpwupvgc2ky8m-9yukects+zkjidasnymx7rmcbjbfy...@mail.gmail.com
>   [3] commit db73ee0d46379922 ("mm, vmscan: do not loop on too_many_isolated 
> for ever")

So you want to keep the warning out of the kernel even though the
problems you are seeing are gone just to allow for an async approach
nobody is very fond of? That is a very dubious approach.
-- 
Michal Hocko
SUSE Labs

[PATCH] mm: Replace-simple_strtoul-with-kstrtoul

[Manjeet Pawar]

simple_strtoul() is obselete now, so using newer function kstrtoul()

Signed-off-by: Manjeet Pawar 
Signed-off-by: Vinay Kumar Rijhwani 
Signed-off-by: Rohit Thapliyal 
---
 mm/page_alloc.c |  3 +--
 mm/shmem.c  | 11 +--
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 77e4d3c..f9d812e 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -7197,9 +7197,8 @@ int percpu_pagelist_fraction_sysctl_handler(struct 
ctl_table *table, int write,
 
 static int __init set_hashdist(char *str)
 {
-   if (!str)
+   if (!str || kstrtoul(str, 0, (unsigned long *)))
return 0;
-   hashdist = simple_strtoul(str, , 0);
return 1;
 }
 __setup("hashdist=", set_hashdist);
diff --git a/mm/shmem.c b/mm/shmem.c
index 07a1d22..bf7d905 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -3470,6 +3470,7 @@ static int shmem_parse_options(char *options, struct 
shmem_sb_info *sbinfo,
struct mempolicy *mpol = NULL;
uid_t uid;
gid_t gid;
+   unsigned long mode;
 
while (options != NULL) {
this_char = options;
@@ -3522,14 +3523,13 @@ static int shmem_parse_options(char *options, struct 
shmem_sb_info *sbinfo,
} else if (!strcmp(this_char,"mode")) {
if (remount)
continue;
-   sbinfo->mode = simple_strtoul(value, , 8) & 0;
-   if (*rest)
+   if (kstrtoul(value, 8, ))
goto bad_val;
+   sbinfo->mode = mode & 0;
} else if (!strcmp(this_char,"uid")) {
if (remount)
continue;
-   uid = simple_strtoul(value, , 0);
-   if (*rest)
+   if (kstrtoul(value, 0, (unsigned long *)))
goto bad_val;
sbinfo->uid = make_kuid(current_user_ns(), uid);
if (!uid_valid(sbinfo->uid))
@@ -3537,8 +3537,7 @@ static int shmem_parse_options(char *options, struct 
shmem_sb_info *sbinfo,
} else if (!strcmp(this_char,"gid")) {
if (remount)
continue;
-   gid = simple_strtoul(value, , 0);
-   if (*rest)
+   if (kstrtoul(value, 0, (unsigned long *)))
goto bad_val;
sbinfo->gid = make_kgid(current_user_ns(), gid);
if (!gid_valid(sbinfo->gid))
-- 
1.9.1

Re: [PATCH V13 04/10] mmc: block: Add CQE support

[Linus Walleij]

On Wed, Nov 8, 2017 at 2:20 PM, Adrian Hunter  wrote:
> On 08/11/17 11:00, Linus Walleij wrote:

>> This and other bits gives me the feeling CQE is now actually ONLY
>> working on the MQ path.
>
> I was not allowed to support non-mq.

Fair enough.

>> That is good. We only add new functionality on the MQ path,
>> yay!
>>
>> But this fact (only abailable iff MQ==true) should at least be
>> mentioned in the commit message I think?
>
> Why?  CQE is MQ only.

So if you read what I say, I think the commit message should
say that CQE is MQ only so that people know that CQE is
MQ only.

>> So why not ditch the old block layer or at least make MQ default?
>
> CQE is MQ only.

Yeah? So why keep it around for everything else?

>> When you keep it like this people have to reconfigure
>> their kernel to enable MQ before they see the benefits of MQ+CQE
>> combined, I think that should rather be the default experience.
>
> Not at all.  I guess you are confusing the legacy mmc with CQE.  CQE is not
> a layer on top of legacy mmc.  It is an alternative to legacy mmc.  CQE
> does not sit on top of the legacy mmc blk-mq support.  You don't have to
> enable legacy mmc blk-mq support to use CQE.

Now I am confused. I can't parse the last sentence. There is no
such thing as legcay blk-mq?

Yours,
Linus Walleij

Re: [PATCH V13 05/10] mmc: cqhci: support for command queue enabled host

[Linus Walleij]

On Wed, Nov 8, 2017 at 3:14 PM, Adrian Hunter  wrote:
> On 08/11/17 11:22, Linus Walleij wrote:
>> On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter  
>> wrote:

>> (...)

>>> +EXPORT_SYMBOL(cqhci_resume);
>>
>> Why would the CQE case require special suspend/resume
>> functionality?
>
> Seems like a very strange question.

Please realize that patch review is partly about education.

Educating me or anyone about your patch set involves
being humbe and not seeing your peers as lesser.

Making your reviewer feel stupid by saying the ask
"strange" or outright stupid questions is not helping
your cause.

> Obviously CQHCI has to be configured
> after suspend.

Yeah. I think I misunderstood is such that:

> Also please don't confuse CQE and CQHCI.  CQHCI is an implementation of a
> CQE.  We currently do not expect to have another implementation, but it is
> not impossible.

OK now you educated me, see it's not that hard without
using belitteling language.

>> This seems two much like on the side CQE-silo engineering,
>> just use the device .[runtime]_suspend/resume callbacks like
>> everyone else, make it possible for the host to figure out
>> if it is in CQE mode or not (I guess it should know already
>> since cqhci .enable() has been called?) and handle it
>> from there.
>
> That is how it works!  The host controller has to decide how to handle
> suspend / resume.

OK.

> cqhci_suspend() / cqhci_resume() are helper functions that the host
> controller can use, but doesn't have to.

OK.

>> Why would CQE hosts need special accessors and the rest
>> of the host not need it?
>
> Special accessors can be used to fix up registers that don't work exactly
> the way the standard specified.

Yeah this is fine as it is for CQHCI, I didn't get that
part :)

>> ->enable and ->disable() for just CQE seem reasonable.
>> But that leaves just two new ops.
>>
>> So why not just put .cqe_enable() and .cqe_disable()
>> ops into mmc_host_ops as optional and be done with it?
>
> Ok so you are not understanding this at all.

No I did not get it. But I do now (I think).

> As a CQE implementation, CQHCI interfaces with the upper layers through the
> CQE ops etc.
>
> But CQHCI also has to work with any host controller driver, so it needs an
> interface for that, which is what cqhci_host_ops is for.  All the ops serve
> useful purposes.
(...)
> The whole point is to prove a library that can work with any host controller
> driver.  That means it must provide functions and callbacks.

OK

>> I think the above approach to put any CQE-specific callbacks
>> directly into the struct mmc_host_ops is way more viable.
>
> Nothing to do with CQE.  This is CQHCI.  Please try to get the difference.

I am trying, please try to think about your language.

>> If special CQE init is needed, why a special cqhci_init()
>> call? And cqhci_pltfm_init()? It's confusing. Can't
>> you just call this by default from the core if the host is
>> CQE capable? Ass a .cqhci_init() callback into mmc_host_ops
>> if need be.
>
> Yeah, so CQHCI is just one of theoretically any number of CQE
> implementations.  This has nothing to do with the core.  It is entirely up
> to the host driver.  cqhci_pltfm_init() allows the mmio space to be defined
> by platform resources, whereas cqhci_init() does all the rest of the
> initialization.

It's fair.

Yours,
Linus Walleij

[PATCH 7/13] scsi: arcmsr: add driver option cmd_per_lun to set host->cmd_per_lun value by user

[Ching Huang]

From: Ching Huang 

add driver option cmd_per_lun to set host->cmd_per_lun value by user

Signed-off-by: Ching Huang 
---

diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h  2017-08-04 17:40:54.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h  2017-08-04 18:12:54.0 +0800
@@ -61,7 +61,9 @@ struct device_attribute;
 #define ARCMSR_MAX_XFER_SECTORS_C  
304
 #define ARCMSR_MAX_TARGETID
17
 #define ARCMSR_MAX_TARGETLUN   
8
-#define ARCMSR_MAX_CMD_PERLUN   
ARCMSR_MAX_OUTSTANDING_CMD
+#define ARCMSR_MAX_CMD_PERLUN  128
+#define ARCMSR_DEFAULT_CMD_PERLUN  32
+#define ARCMSR_MIN_CMD_PERLUN  1
 #define ARCMSR_MAX_QBUFFER 
4096
 #define ARCMSR_DEFAULT_SG_ENTRIES  
38
 #define ARCMSR_MAX_HBB_POSTQUEUE   
264
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c  2017-11-08 18:52:04.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c  2017-11-08 18:52:48.0 +0800
@@ -79,6 +79,10 @@ static int host_can_queue = ARCMSR_DEFAU
 module_param(host_can_queue, int, S_IRUGO);
 MODULE_PARM_DESC(host_can_queue, " adapter queue depth(32 ~ 1024), default is 
128");
 
+static int cmd_per_lun = ARCMSR_DEFAULT_CMD_PERLUN;
+module_param(cmd_per_lun, int, S_IRUGO);
+MODULE_PARM_DESC(cmd_per_lun, " device queue depth(1 ~ 128), default is 32");
+
 #defineARCMSR_SLEEPTIME10
 #defineARCMSR_RETRYCOUNT   12
 
@@ -141,7 +145,7 @@ static struct scsi_host_template arcmsr_
.this_id= ARCMSR_SCSI_INITIATOR_ID,
.sg_tablesize   = ARCMSR_DEFAULT_SG_ENTRIES, 
.max_sectors= ARCMSR_MAX_XFER_SECTORS_C, 
-   .cmd_per_lun= ARCMSR_MAX_CMD_PERLUN,
+   .cmd_per_lun= ARCMSR_DEFAULT_CMD_PERLUN,
.use_clustering = ENABLE_CLUSTERING,
.shost_attrs= arcmsr_host_attrs,
.no_write_same  = 1,
@@ -884,7 +888,9 @@ static int arcmsr_probe(struct pci_dev *
if ((host_can_queue < ARCMSR_MIN_OUTSTANDING_CMD) || (host_can_queue > 
ARCMSR_MAX_OUTSTANDING_CMD))
host_can_queue = ARCMSR_DEFAULT_OUTSTANDING_CMD;
host->can_queue = host_can_queue;   /* max simultaneous cmds */ 

-   host->cmd_per_lun = ARCMSR_MAX_CMD_PERLUN;  
+   if ((cmd_per_lun < ARCMSR_MIN_CMD_PERLUN) || (cmd_per_lun > 
ARCMSR_MAX_CMD_PERLUN))
+   cmd_per_lun = ARCMSR_DEFAULT_CMD_PERLUN;
+   host->cmd_per_lun = cmd_per_lun;
host->this_id = ARCMSR_SCSI_INITIATOR_ID;
host->unique_id = (bus << 8) | dev_fun;
pci_set_drvdata(pdev, host);

Re: [PATCH] ARM: dts: add phy-reset property for rk3066a-rayeager emac

[Roger Quadros]

Hi,

On 07/11/17 09:54, Vladimir Zapolskiy wrote:
> Hello Chris,
> 
> On 11/07/2017 04:49 AM, Chris Zhong wrote:
>> The ethernet phy of rk3066a-rayeager has a reset pin, it controlled by
>> GPIO1_D6, this pin should be pull down then pull up to reset the phy.
>> Add a phy-reset property in emac, make the phy can be reset when emac
>> power on.
> 
> for PHY reset there are properties 'reset-gpios' and 'reset-delay-us',
> please reference to Documentation/devicetree/bindings/net/mdio.txt
> 
> Can you try to reuse them instead of adding new custom properties?
> 
> As a side question, which is mainly addressed to Sergei and Roger,
> I don't quite understand why PHY properties were initially added to
> MAC/MDIO bus device tree nodes, in my opinion they must be moved under
> PHY device tree nodes.

The PHY reset *has* to be performed at the MDIO bus driver level so that they
can be pin-strap configured correctly and be detected during MDIO bus scan.

- We have boards where PHYs won't be detected if RESET is not done before the 
scan. (due to invalid h/w pin-strapping config)
- We have boards where a single GPIO line controls reset of all PHYs on the bus.

Due to these reasons the RESET control lies with the MDIO bus driver.

> 
> --
> With best wishes,
> Vladimir
> 
>>
>> Signed-off-by: Chris Zhong 
>> ---
>>
>>  arch/arm/boot/dts/rk3066a-rayeager.dts | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/rk3066a-rayeager.dts 
>> b/arch/arm/boot/dts/rk3066a-rayeager.dts
>> index 570157f..6064a0a 100644
>> --- a/arch/arm/boot/dts/rk3066a-rayeager.dts
>> +++ b/arch/arm/boot/dts/rk3066a-rayeager.dts
>> @@ -173,6 +173,8 @@
>>  pinctrl-0 = <_xfer>, <_mdio>, <_rst>;
>>  phy = <>;
>>  phy-supply = <_rmii>;
>> +phy-reset-gpios = < RK_PD6 GPIO_ACTIVE_LOW>; /* PHY_RST */
>> +phy-reset-duration = <10>; /* millisecond */
>>  status = "okay";
>>  
>>  phy0: ethernet-phy@0 {
>>

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

[PATCH] extcon: max77693: Delete an unnecessary variable initialisation in max77693_muic_set_path()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 9 Nov 2017 09:40:59 +0100

The variable "ret" will be set to an appropriate value a bit later.
Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring 
---
 drivers/extcon/extcon-max77693.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index 643411066ad9..227651ff9666 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -266,7 +266,7 @@ static int max77693_muic_set_debounce_time(struct 
max77693_muic_info *info,
 static int max77693_muic_set_path(struct max77693_muic_info *info,
u8 val, bool attached)
 {
-   int ret = 0;
+   int ret;
unsigned int ctrl1, ctrl2 = 0;
 
if (attached)
-- 
2.15.0

Re: [PATCH V2] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute

[Jan Beulich]

>>> On 09.11.17 at 00:06,  wrote:
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -244,6 +244,91 @@ struct pci_dev *pcistub_get_pci_dev(struct 
> xen_pcibk_device *pdev,
>   return found_dev;
>  }
>  
> +struct pcistub_args {
> + struct pci_dev *dev;

Please don't ignore prior review comments: Either carry out what
was requested, or explain why the request can't be fulfilled. You
saying "This field will point to first device that is not owned by
pcistub" to Roger's request to make this a pointer to const is not a
valid reason to not do the adjustment; in fact your reply is entirely
unrelated to the request.

> +static int pcistub_search_dev(struct pci_dev *dev, void *data)
> +{
> + struct pcistub_device *psdev;
> + struct pcistub_args *arg = data;
> + bool found_dev = false;

Purely cosmetical, but anyway: Why not just "found"? What else
could be (not) found here other than the device in question?

> + unsigned long flags;
> +
> + spin_lock_irqsave(_devices_lock, flags);
> +
> + list_for_each_entry(psdev, _devices, dev_list) {
> + if (psdev->dev == dev) {
> + found_dev = true;
> + arg->dcount++;
> + break;
> + }
> + }
> +
> + spin_unlock_irqrestore(_devices_lock, flags);
> +
> + /* Device not owned by pcistub, someone owns it. Abort the walk */
> + if (!found_dev)
> + arg->dev = dev;
> +
> + return found_dev ? 0 : 1;

Despite the function needing to return int, this can be simplified to
"return !found_dev". I'd also like to note that the part of the
earlier comment related to this is sort of disconnected. How about

/* Device not owned by pcistub, someone owns it. Abort the walk */
if (!found_dev) {
arg->dev = dev;
return 1;
}

return 0;

And finally - I don't think the comment is entirely correct - the
device not being owned by pciback doesn't necessarily mean it's
owned by another driver. It could as well be unowned.

> +static int pcistub_reset_dev(struct pci_dev *dev)
> +{
> + struct xen_pcibk_dev_data *dev_data;
> + bool slot = false, bus = false;
> + struct pcistub_args arg = {};
> +
> + if (!dev)
> + return -EINVAL;
> +
> + dev_dbg(>dev, "[%s]\n", __func__);
> +
> + if (!pci_probe_reset_slot(dev->slot))
> + slot = true;
> + else if ((!pci_probe_reset_bus(dev->bus)) &&
> +  (!pci_is_root_bus(dev->bus)))
> + bus = true;
> +
> + if (!bus && !slot)
> + return -EOPNOTSUPP;
> +
> + /*
> +  * Make sure all devices on this bus are owned by the
> +  * PCI backend so that we can safely reset the whole bus.
> +  */

Is that really the case when you mean to do a slot reset? It was for
a reason that I had asked about a missing "else" in v1 review,
rather than questioning the conditional around the logic.

> + pci_walk_bus(dev->bus, pcistub_search_dev, );
> +
> + /* All devices under the bus should be part of pcistub! */
> + if (arg.dev) {
> + dev_err(>dev, "%s device on bus 0x%x is not owned by 
> pcistub\n",

%#x

Yet then, thinking about what would be useful information should the
situation really arise, I'm not convinced printing a bare bus number
here is useful either. Especially for the case of multiple parallel
requests you want to make it possible to match each message to the
original request (guest start or whatever). Hence I think you want
something like

"%s on the same bus as %s is not owned by " DRV_NAME "\n"

> + pci_name(arg.dev), dev->bus->number);
> +
> + return -EBUSY;
> + }
> +
> + dev_dbg(>dev, "pcistub owns %d devices on bus 0x%x\n",
> + arg.dcount, dev->bus->number);

While here the original device is perhaps not necessary to print,
the bare bus number doesn't carry enough information: You'll
want to prefix it by the segment number. Plus you'll want to use
canonical formatting (:bb), so one can get matches when
suitably grep-ing the log. Perhaps bus->name is what you're
after.

Jan

Re: [PATCH net-next 2/6] net: dsa: return after mdb prepare phase

[Egil Hjelmeland]

On 08. nov. 2017 18:19, Vivien Didelot wrote:

The current code does not return after successfully preparing the MDB
addition on every ports member of a multicast group. Fix this.

Fixes: a1a6b7ea7f2d ("net: dsa: add cross-chip multicast support")
Reported-by: Egil Hjelmeland 
Signed-off-by: Vivien Didelot 
---
  net/dsa/switch.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/net/dsa/switch.c b/net/dsa/switch.c
index 04e8ad2c3d5d..0041aba5c339 100644
--- a/net/dsa/switch.c
+++ b/net/dsa/switch.c
@@ -133,6 +133,8 @@ static int dsa_switch_mdb_add(struct dsa_switch *ds,
if (err)
return err;
}
+
+   return 0;
}
  
  	for_each_set_bit(port, group, ds->num_ports)




Hi Vivien!

Will this cause a merge-conflict with the "net" patch you sent, when 
"net" is merged to "net-next"? Perhaps more polite to hold on to this 
(and following patches) until "net" patch has trickled through the system?


Regards
Egil

Re: Linux & FAT32 label

[Pali Rohár]

On Tuesday 07 November 2017 12:28:41 Theodore Ts'o wrote:
> On Sun, Nov 05, 2017 at 10:12:49PM +0100, Pali Rohár wrote:
> > Easy way how to achieve this situation:
> > 
> > 1. use mkdosfs to format hard disk to FAT32 with label LABEL42
> > 
> > 2. boot Windows 10 (or XP) and set label of that FAT32 partition to
> > empty (via Explorer GUI)
> > 
> > 3. profit
> > 
> > You would have stored LABEL42 in boot sector and no label in root
> > directory. Windows handle this situation as there is no label.
> 
> But why should we *care*?

FAT is Microsoft's filesystem and the only usage of it on Linux is due
to interoperability with different non-Linux systems. So here we should
implement FAT in the similar/same way as other systems. It does not make
sense to implement it differently and specially in non-compatible way.
Because it lost reason what is primary usage of the FAT on Linux.

-- 
Pali Rohár
pali.ro...@gmail.com

[PATCH 1/2] sched/swait: allow swake_up() to return

[Peter Xu]

Let swake_up() to return whether any of the waiters is waked up. One use
case of it would be:

  if (swait_active(wq)) {
swake_up(wq);
// do something when waiter is waked up
waked_up++;
  }

Logically it's possible that when reaching swake_up() the wait queue is
not active any more, and here doing something like waked_up++ would be
inaccurate.  To correct it, we need an atomic version of it.

With this patch, we can simply re-write it into:

  if (swake_up(wq)) {
// do something when waiter is waked up
waked_up++;
  }

After all we are checking swait_active() inside swake_up() too.

CC: Ingo Molnar 
CC: Peter Zijlstra 
CC: Peter Xu 
CC: linux-kernel@vger.kernel.org
Signed-off-by: Peter Xu 
---
 include/linux/swait.h |  4 ++--
 kernel/sched/swait.c  | 21 -
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/include/linux/swait.h b/include/linux/swait.h
index c1f9c62a8a50..c55171280ac8 100644
--- a/include/linux/swait.h
+++ b/include/linux/swait.h
@@ -84,9 +84,9 @@ static inline int swait_active(struct swait_queue_head *q)
return !list_empty(>task_list);
 }
 
-extern void swake_up(struct swait_queue_head *q);
+extern bool swake_up(struct swait_queue_head *q);
 extern void swake_up_all(struct swait_queue_head *q);
-extern void swake_up_locked(struct swait_queue_head *q);
+extern bool swake_up_locked(struct swait_queue_head *q);
 
 extern void __prepare_to_swait(struct swait_queue_head *q, struct swait_queue 
*wait);
 extern void prepare_to_swait(struct swait_queue_head *q, struct swait_queue 
*wait, int state);
diff --git a/kernel/sched/swait.c b/kernel/sched/swait.c
index 3d5610dcce11..31f8d677c690 100644
--- a/kernel/sched/swait.c
+++ b/kernel/sched/swait.c
@@ -16,29 +16,40 @@ EXPORT_SYMBOL(__init_swait_queue_head);
  * If for some reason it would return 0, that means the previously waiting
  * task is already running, so it will observe condition true (or has already).
  */
-void swake_up_locked(struct swait_queue_head *q)
+bool swake_up_locked(struct swait_queue_head *q)
 {
struct swait_queue *curr;
 
if (list_empty(>task_list))
-   return;
+   return false;
 
curr = list_first_entry(>task_list, typeof(*curr), task_list);
wake_up_process(curr->task);
list_del_init(>task_list);
+   return true;
 }
 EXPORT_SYMBOL(swake_up_locked);
 
-void swake_up(struct swait_queue_head *q)
+/**
+ * swake_up - Wake up one process on the waiting list
+ * @q:the waitqueue to wake up
+ *
+ * Returns true if some process is waked up, otherwise false if there
+ * is no waiter to wake up.
+ */
+bool swake_up(struct swait_queue_head *q)
 {
+   bool ret;
unsigned long flags;
 
if (!swait_active(q))
-   return;
+   return false;
 
raw_spin_lock_irqsave(>lock, flags);
-   swake_up_locked(q);
+   ret = swake_up_locked(q);
raw_spin_unlock_irqrestore(>lock, flags);
+
+   return ret;
 }
 EXPORT_SYMBOL(swake_up);
 
-- 
2.13.6

Re: [PATCH v4] printk: Add console owner and waiter logic to load balance console writes

[Michal Hocko]

Hi,
assuming that this passes warn stall torturing by Tetsuo, do you think
we can drop 
http://lkml.kernel.org/r/1509017339-4802-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
from the mmotm tree?

On Wed 08-11-17 10:27:23, Steven Rostedt wrote:
> [ claws-mail is really pissing me off. It did it again, after I
>   manually fixed all the addresses. This time, I'm going to do things
>   slightly different. Sorry for all the spam :-( ]
> 
> From: Steven Rostedt (VMware) 
> 
> This patch implements what I discussed in Kernel Summit. I added
> lockdep annotation (hopefully correctly), and it hasn't had any splats
> (since I fixed some bugs in the first iterations). It did catch
> problems when I had the owner covering too much. But now that the owner
> is only set when actively calling the consoles, lockdep has stayed
> quiet.
>  
> Here's the design again:
> 
> I added a "console_owner" which is set to a task that is actively
> writing to the consoles. It is *not* the same an the owner of the
> console_lock. It is only set when doing the calls to the console
> functions. It is protected by a console_owner_lock which is a raw spin
> lock.
> 
> There is a console_waiter. This is set when there is an active console
> owner that is not current, and waiter is not set. This too is protected
> by console_owner_lock.
> 
> In printk() when it tries to write to the consoles, we have:
> 
>   if (console_trylock())
>   console_unlock();
> 
> Now I added an else, which will check if there is an active owner, and
> no current waiter. If that is the case, then console_waiter is set, and
> the task goes into a spin until it is no longer set.
> 
> When the active console owner finishes writing the current message to
> the consoles, it grabs the console_owner_lock and sees if there is a
> waiter, and clears console_owner.
> 
> If there is a waiter, then it breaks out of the loop, clears the waiter
> flag (because that will release the waiter from its spin), and exits.
> Note, it does *not* release the console semaphore. Because it is a
> semaphore, there is no owner. Another task may release it. This means
> that the waiter is guaranteed to be the new console owner! Which it
> becomes.
> 
> Then the waiter calls console_unlock() and continues to write to the
> consoles.
> 
> If another task comes along and does a printk() it too can become the
> new waiter, and we wash rinse and repeat!
> 
> Signed-off-by: Steven Rostedt (VMware) 
> ---
> Changes from v3:
> 
>   Fixed while loop on console_waiter (Thanks Vlastimil!)
> 
>   Moved console_owner out of logbuf_lock taking (reported by
>   Tetsuo Handa)
> 
> Changes from v2:
> 
>   - Added back some READ/WRITE_ONCE() just to be on the safe side
> Index: linux-trace.git/kernel/printk/printk.c
> ===
> --- linux-trace.git.orig/kernel/printk/printk.c
> +++ linux-trace.git/kernel/printk/printk.c
> @@ -86,8 +86,15 @@ EXPORT_SYMBOL_GPL(console_drivers);
>  static struct lockdep_map console_lock_dep_map = {
>   .name = "console_lock"
>  };
> +static struct lockdep_map console_owner_dep_map = {
> + .name = "console_owner"
> +};
>  #endif
>  
> +static DEFINE_RAW_SPINLOCK(console_owner_lock);
> +static struct task_struct *console_owner;
> +static bool console_waiter;
> +
>  enum devkmsg_log_bits {
>   __DEVKMSG_LOG_BIT_ON = 0,
>   __DEVKMSG_LOG_BIT_OFF,
> @@ -1753,8 +1760,56 @@ asmlinkage int vprintk_emit(int facility
>* semaphore.  The release will print out buffers and wake up
>* /dev/kmsg and syslog() users.
>*/
> - if (console_trylock())
> + if (console_trylock()) {
>   console_unlock();
> + } else {
> + struct task_struct *owner = NULL;
> + bool waiter;
> + bool spin = false;
> +
> + printk_safe_enter_irqsave(flags);
> +
> + raw_spin_lock(_owner_lock);
> + owner = READ_ONCE(console_owner);
> + waiter = READ_ONCE(console_waiter);
> + if (!waiter && owner && owner != current) {
> + WRITE_ONCE(console_waiter, true);
> + spin = true;
> + }
> + raw_spin_unlock(_owner_lock);
> +
> + /*
> +  * If there is an active printk() writing to the
> +  * consoles, instead of having it write our data too,
> +  * see if we can offload that load from the active
> +  * printer, and do some printing ourselves.
> +  * Go into a spin only if there isn't already a waiter
> +  * spinning, and there is an active printer, and
> +  * that active 

Re: Legal question: Author, Sign-off, Company Copyright and gmail

[Greg Kroah-Hartman]

On Thu, Nov 09, 2017 at 10:45:27AM +0100, Daniel Lezcano wrote:
> 
> Hi all,
> 
> I noticed a practice when the patches are submitted where I'm a bit
> confused about how it fits with the DCO.
> 
> People are creating gmail accounts to send patches on behalf of their
> company because the company's email configuration does not allow to send
> patches or adds extra infos, or whatever...
> 
> That ends up with patches submitted by a gmail account with no history
> and verifiable origin and new files containing a company copyright [1].

If there is a question, just ask.

> At the first glance I would say, it is not allowed, and if a company is
> willing to do opensource, it should provide the tools to its employees
> to do so. But I don't want block patch submission if this practice is
> tolerated.

Fixing the use of a company's email server is outside of almost all
Linux kernel divisions.  As one such example, Red Hat has a system that
messes with patches :)

I only know of one company that uses Exchange that has "fixed it" enough
to allow their developers to send patches out that are not corrupted
(and no, it's not Microsoft).  Preventing all of those companies, or
those that use Lotus Notes, or any other horrid email system, from
contributing to kernel development is not a good idea.

> What is the policy in this case ?

I just ask all new contributors who they work for, and so we then know,
it's not that big of a deal.

thanks,

greg k-h

[PATCH] x86: use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" again

[WANG Chao]

Commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo) caused
a serious performance issue when reading from /proc/cpuinfo on system
with aperfmperf.

For each cpu, arch_freq_get_on_cpu() sleeps 20ms to get its frequency.
On a system with 64 cpus, it takes 1.5s to finish running `cat
/proc/cpuinfo`, while it previously was done in 15ms.

Some programs use /proc/cpuinfo during startup or runtime, eg. QEMU.
This patch will restore the previous behavior and let user space happy.

Fixes: 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo)
Cc: sta...@kernel.org   # 4.13
Signed-off-by: WANG Chao 
---
 arch/x86/kernel/cpu/Makefile | 2 +-
 arch/x86/kernel/cpu/proc.c   | 4 +---
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 236999c54edc..c60922a66385 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -22,7 +22,7 @@ obj-y += common.o
 obj-y  += rdrand.o
 obj-y  += match.o
 obj-y  += bugs.o
-obj-y  += aperfmperf.o
+obj-$(CONFIG_CPU_FREQ) += aperfmperf.o
 
 obj-$(CONFIG_PROC_FS)  += proc.o
 obj-$(CONFIG_X86_FEATURE_NAMES) += capflags.o powerflags.o
diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index 4378a729b933..6b7e17bf0b71 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -78,10 +78,8 @@ static int show_cpuinfo(struct seq_file *m, void *v)
seq_printf(m, "microcode\t: 0x%x\n", c->microcode);
 
if (cpu_has(c, X86_FEATURE_TSC)) {
-   unsigned int freq = arch_freq_get_on_cpu(cpu);
+   unsigned int freq = cpufreq_quick_get(cpu);
 
-   if (!freq)
-   freq = cpufreq_quick_get(cpu);
if (!freq)
freq = cpu_khz;
seq_printf(m, "cpu MHz\t\t: %u.%03u\n",
-- 
2.15.0

Re: [PATCH RESEND 2/3] KVM: Add paravirt remote TLB flush

[Wanpeng Li]

2017-11-09 19:02 GMT+08:00 Paolo Bonzini :
> On 09/11/2017 12:01, Wanpeng Li wrote:
>> 2017-11-09 18:48 GMT+08:00 Paolo Bonzini :
>>> On 09/11/2017 03:02, Wanpeng Li wrote:
 @@ -484,6 +511,8 @@ void __init kvm_guest_init(void)
   pv_time_ops.steal_clock = kvm_steal_clock;
   }

 + pv_mmu_ops.flush_tlb_others = kvm_flush_tlb_others;
>>>
>>> This needs to be keyed on a new CPUID feature bit.  Eduardo is also
>>
>> Will do.
>>
>>> adding a new "PV_DEDICATED" hint and you might disable PV TLB flush when
>>> PV_DEDICATED is set.
>>
>> Why disable PV TLB flush for PV_DEDICATED(qspinlock)?
>
> PV_DEDICATED says pretty much that it is very unlikely to have a
> preempted vCPU.  Therefore, the cpumask loop is unnecessary.

Thanks for pointing out this. :)

Regards,
Wanpeng Li

RE: [PATCH x86 v2] uprobe: emulate push insns for uprobe on x86

[David Laight]

From: Yonghong Song
> Sent: 09 November 2017 00:55
>
> Uprobe is a tracing mechanism for userspace programs.
> Typical uprobe will incur overhead of two traps.
> First trap is caused by replaced trap insn, and
> the second trap is to execute the original displaced
> insn in user space.
> 
> To reduce the overhead, kernel provides hooks
> for architectures to emulate the original insn
> and skip the second trap. In x86, emulation
> is done for certain branch insns.
> 
> This patch extends the emulation to "push "
> insns. These insns are typical in the beginning
> of the function. For example, bcc
...
> diff --git a/arch/x86/include/asm/uprobes.h b/arch/x86/include/asm/uprobes.h
> index 74f4c2f..f9d2b43 100644
> --- a/arch/x86/include/asm/uprobes.h
> +++ b/arch/x86/include/asm/uprobes.h
> @@ -33,6 +33,11 @@ typedef u8 uprobe_opcode_t;
...
> @@ -53,6 +59,10 @@ struct arch_uprobe {
>   u8  fixups;
>   u8  ilen;
>   }   defparam;
> + struct {
> + u8  rex_prefix;

Just call this 'reg_high' and set to 0 or 1.

> + u8  opc1;
> + }   push;
>   };
>  };
> 
> diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
> index a3755d2..5ace65c 100644
> --- a/arch/x86/kernel/uprobes.c
> +++ b/arch/x86/kernel/uprobes.c
> @@ -640,11 +640,71 @@ static bool check_jmp_cond(struct arch_uprobe *auprobe, 
> struct pt_regs *regs)
>  #undef   COND
>  #undef   CASE_COND
> 
> -static bool branch_emulate_op(struct arch_uprobe *auprobe, struct pt_regs 
> *regs)
> +static unsigned long *get_push_reg_ptr(struct arch_uprobe *auprobe,
> +struct pt_regs *regs)
>  {
> - unsigned long new_ip = regs->ip += auprobe->branch.ilen;
> - unsigned long offs = (long)auprobe->branch.offs;
> +#if defined(CONFIG_X86_64)
> + switch (auprobe->push.opc1) {
> + case 0x50:
> + return auprobe->push.rex_prefix ? >r8 : >ax;
> + case 0x51:
> + return auprobe->push.rex_prefix ? >r9 : >cx;
> + case 0x52:
> + return auprobe->push.rex_prefix ? >r10 : >dx;
> + case 0x53:
> + return auprobe->push.rex_prefix ? >r11 : >bx;
> + case 0x54:
> + return auprobe->push.rex_prefix ? >r12 : >sp;
> + case 0x55:
> + return auprobe->push.rex_prefix ? >r13 : >bp;
> + case 0x56:
> + return auprobe->push.rex_prefix ? >r14 : >si;
> + }
> +
> + /* opc1 0x57 */
> + return auprobe->push.rex_prefix ? >r15 : >di;

The bottom of that switch statement is horrid
Actually why can't you sort out this address in the code that
sets up 'reg_prefix' (etc);

David

Re: [PATCH 1/3] HID: cp2112: fix interface specification URL

[Jiri Kosina]

On Thu, 2 Nov 2017, Sébastien Szymanski wrote:

> Signed-off-by: Sébastien Szymanski 
> ---
>  drivers/hid/hid-cp2112.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
> index 078026f..28e3c18 100644
> --- a/drivers/hid/hid-cp2112.c
> +++ b/drivers/hid/hid-cp2112.c
> @@ -21,7 +21,7 @@
>   * Data Sheet:
>   *   http://www.silabs.com/Support%20Documents/TechnicalDocs/CP2112.pdf
>   * Programming Interface Specification:
> - *   http://www.silabs.com/Support%20Documents/TechnicalDocs/AN495.pdf
> + *   
> https://www.silabs.com/documents/public/application-notes/an495-cp2112-interface-specification.pdf
>   */

I've applied patches 1 and 2 (with stable anotation) for now. Thanks,

-- 
Jiri Kosina
SUSE Labs

[PATCH v4 3/3] dt-bindings: timer: Add andestech atcpit100 timer binding doc

[Rick Chen]

Add a document to describe Andestech atcpit100 timer and
binding information.

Signed-off-by: Rick Chen 
Acked-by: Rob Herring 
Signed-off-by: Greentime Hu 
---
 .../bindings/timer/andestech,atcpit100-timer.txt   | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt

diff --git 
a/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt 
b/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
new file mode 100644
index 000..b97ff32
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
@@ -0,0 +1,33 @@
+Andestech ATCPIT100 timer
+--
+ATCPIT100 is a generic IP block from Andes Technology, embedded in
+Andestech AE3XX platforms and other designs.
+
+This timer is a set of compact multi-function timers, which can be
+used as pulse width modulators (PWM) as well as simple timers.
+
+It supports up to 4 PIT channels. Each PIT channel is a
+multi-function timer and provide the following usage scenarios:
+One 32-bit timer
+Two 16-bit timers
+Four 8-bit timers
+One 16-bit PWM
+One 16-bit timer and one 8-bit PWM
+Two 8-bit timer and one 8-bit PWM
+
+Required properties:
+- compatible   : Should be "andestech,atcpit100"
+- reg  : Address and length of the register set
+- interrupts   : Reference to the timer interrupt
+- clocks : a clock to provide the tick rate for "andestech,atcpit100"
+- clock-names : should be "PCLK" for the external tick timer.
+
+Examples:
+
+timer0: timer@f040 {
+   compatible = "andestech,atcpit100";
+   reg = <0xf040 0x1000>;
+   interrupts = <2 4>;
+   clocks = <_pll>;
+   clock-names = "PCLK";
+};
-- 
2.7.4

[PATCH 12/13] scsi: arcmsr: adjust some tab or white-space to make text alignment

[Ching Huang]

From: Ching Huang 

adjust some tab or white-space to make text alignment

Signed-off-by: Ching Huang 
---

diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h  2017-11-07 16:18:22.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h  2017-11-07 17:29:10.0 +0800
@@ -55,35 +55,35 @@ struct device_attribute;
 #define ARCMSR_DEFAULT_OUTSTANDING_CMD 128
 #define ARCMSR_MIN_OUTSTANDING_CMD 32
 #define ARCMSR_DRIVER_VERSION  "v1.30.00.22-20151126"
-#define ARCMSR_SCSI_INITIATOR_ID   
255
-#define ARCMSR_MAX_XFER_SECTORS
512
-#define ARCMSR_MAX_XFER_SECTORS_B  
4096
-#define ARCMSR_MAX_XFER_SECTORS_C  
304
-#define ARCMSR_MAX_TARGETID
17
-#define ARCMSR_MAX_TARGETLUN   
8
+#define ARCMSR_SCSI_INITIATOR_ID   255
+#define ARCMSR_MAX_XFER_SECTORS512
+#define ARCMSR_MAX_XFER_SECTORS_B  4096
+#define ARCMSR_MAX_XFER_SECTORS_C  304
+#define ARCMSR_MAX_TARGETID17
+#define ARCMSR_MAX_TARGETLUN   8
 #define ARCMSR_MAX_CMD_PERLUN  128
 #define ARCMSR_DEFAULT_CMD_PERLUN  32
 #define ARCMSR_MIN_CMD_PERLUN  1
-#define ARCMSR_MAX_QBUFFER 
4096
-#define ARCMSR_DEFAULT_SG_ENTRIES  
38
-#define ARCMSR_MAX_HBB_POSTQUEUE   
264
+#define ARCMSR_MAX_QBUFFER 4096
+#define ARCMSR_DEFAULT_SG_ENTRIES  38
+#define ARCMSR_MAX_HBB_POSTQUEUE   264
 #define ARCMSR_MAX_ARC1214_POSTQUEUE   256
 #define ARCMSR_MAX_ARC1214_DONEQUEUE   257
 #define ARCMSR_MAX_HBE_DONEQUEUE   512
-#define ARCMSR_MAX_XFER_LEN
0x26000 /* 152K */
-#define ARCMSR_CDB_SG_PAGE_LENGTH  
256 
+#define ARCMSR_MAX_XFER_LEN0x26000 /* 152K */
+#define ARCMSR_CDB_SG_PAGE_LENGTH  256 
 #define ARCMST_NUM_MSIX_VECTORS4
 #ifndef PCI_DEVICE_ID_ARECA_1880
-#define PCI_DEVICE_ID_ARECA_1880 0x1880
- #endif
+#define PCI_DEVICE_ID_ARECA_1880   0x1880
+#endif
 #ifndef PCI_DEVICE_ID_ARECA_1214
-   #define PCI_DEVICE_ID_ARECA_12140x1214
+#define PCI_DEVICE_ID_ARECA_1214   0x1214
 #endif
 #ifndef PCI_DEVICE_ID_ARECA_1203
-   #define PCI_DEVICE_ID_ARECA_12030x1203
+#define PCI_DEVICE_ID_ARECA_1203   0x1203
 #endif
 #ifndef PCI_DEVICE_ID_ARECA_1884
-   #define PCI_DEVICE_ID_ARECA_18840x1884
+#define PCI_DEVICE_ID_ARECA_1884   0x1884
 #endif
 #defineARCMSR_HOURS(1000 * 60 * 60 * 4)
 #defineARCMSR_MINUTES  (1000 * 60 * 60)
@@ -92,15 +92,15 @@ struct device_attribute;
 **
 
**
 */
-#define ARC_SUCCESS   0
-#define ARC_FAILURE   1
+#define ARC_SUCCESS0
+#define ARC_FAILURE1
 /*
 ***
 **split 64bits dma addressing
 ***
 */
-#define dma_addr_hi32(addr)   (uint32_t) ((addr>>16)>>16)
-#define dma_addr_lo32(addr)   (uint32_t) (addr & 0x)
+#define dma_addr_hi32(addr)(uint32_t) ((addr>>16)>>16)
+#define dma_addr_lo32(addr)(uint32_t) (addr & 0x)
 /*
 ***
 **MESSAGE CONTROL CODE
@@ -140,7 +140,7 @@ struct CMD_MESSAGE_FIELD
 #define FUNCTION_SAY_HELLO 0x0807
 #define FUNCTION_SAY_GOODBYE   0x0808
 #define FUNCTION_FLUSH_ADAPTER_CACHE   0x0809
-#define FUNCTION_GET_FIRMWARE_STATUS   0x080A
+#define FUNCTION_GET_FIRMWARE_STATUS   0x080A
 #define FUNCTION_HARDWARE_RESET0x080B
 /* ARECA IO CONTROL CODE*/
 #define ARCMSR_MESSAGE_READ_RQBUFFER   \
@@ -171,18 +171,18 @@ struct CMD_MESSAGE_FIELD
 **   structure for holding DMA address data
 *
 */
-#define IS_DMA64   (sizeof(dma_addr_t) == 8)
-#define IS_SG64_ADDR0x0100 /* bit24 */
+#define IS_DMA64   (sizeof(dma_addr_t) == 8)
+#define IS_SG64_ADDR   0x0100 /* bit24 */
 struct  SG32ENTRY
 {
-   __le32  length;
-   __le32  address;
+   __le32  

[PATCH v4 1/3] clocksource/drivers/atcpit100: Add andestech atcpit100 timer

[Rick Chen]

ATCPIT100 is often used on the Andes architecture,
This timer provide 4 PIT channels. Each PIT channel is a
multi-function timer, can be configured as 32,16,8 bit timers
or PWM as well.

For system timer it will set channel 1 32-bit timer0 as clock
source and count downwards until underflow and restart again.

It also set channel 0 32-bit timer0 as clock event and count
downwards until condition match. It will generate an interrupt
for handling periodically.

Signed-off-by: Rick Chen 
Signed-off-by: Greentime Hu 
---
 drivers/clocksource/timer-atcpit100.c | 248 ++
 1 file changed, 248 insertions(+)
 create mode 100644 drivers/clocksource/timer-atcpit100.c

diff --git a/drivers/clocksource/timer-atcpit100.c 
b/drivers/clocksource/timer-atcpit100.c
new file mode 100644
index 000..fb0a4e4
--- /dev/null
+++ b/drivers/clocksource/timer-atcpit100.c
@@ -0,0 +1,248 @@
+/*
+ *  Andestech ATCPIT100 Timer Device Driver Implementation
+ *
+ * Copyright (C) 2017 Andes Technology Corporation
+ * Rick Chen, Andes Technology Corporation 
+
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "timer-of.h"
+
+/*
+ * Definition of register offsets
+ */
+
+/* ID and Revision Register */
+#define ID_REV 0x0
+
+/* Configuration Register */
+#define CFG0x10
+
+/* Interrupt Enable Register */
+#define INT_EN 0x14
+#define CH_INT_EN(c, i)((1<

[PATCH v4 2/3] clocksource/drivers/Kconfig: Support andestech atcpit100 timer

[Rick Chen]

Add CLKSRC_ATCPIT100 for Andestech atcpit100 timer selection.
It often be used in Andestech AE3XX platform.

Signed-off-by: Rick Chen 
Signed-off-by: Greentime Hu 
---
 drivers/clocksource/Kconfig  | 6 ++
 drivers/clocksource/Makefile | 1 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index cc60620..e950066 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -615,4 +615,10 @@ config CLKSRC_ST_LPC
  Enable this option to use the Low Power controller timer
  as clocksource.
 
+config CLKSRC_ATCPIT100
+   bool "Clocksource for AE3XX platform" if COMPILE_TEST
+  depends on GENERIC_CLOCKEVENTS && HAS_IOMEM
+   help
+ This option enables support for the Andestech AE3XX platform timers.
+
 endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index dbc1ad1..24d15bd 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -74,3 +74,4 @@ obj-$(CONFIG_H8300_TMR16) += h8300_timer16.o
 obj-$(CONFIG_H8300_TPU)+= h8300_tpu.o
 obj-$(CONFIG_CLKSRC_ST_LPC)+= clksrc_st_lpc.o
 obj-$(CONFIG_X86_NUMACHIP) += numachip.o
+obj-$(CONFIG_CLKSRC_ATCPIT100) += timer-atcpit100.o
-- 
2.7.4

Re: [PATCH] dell-smbios: fix string overflow

[Pali Rohár]

On Wednesday 08 November 2017 13:08:39 Arnd Bergmann wrote:
> The new sysfs code overwrites two fixed-length character arrays
> that are each one byte shorter than they need to be, to hold
> the trailing \0:
> 
> drivers/platform/x86/dell-smbios.c: In function 'build_tokens_sysfs':
> drivers/platform/x86/dell-smbios.c:494:42: error: 'sprintf' writing a 
> terminating nul past the end of the destination [-Werror=format-overflow=]
>sprintf(buffer_location, "%04x_location",
> drivers/platform/x86/dell-smbios.c:494:3: note: 'sprintf' output 14 bytes 
> into a destination of size 13
> drivers/platform/x86/dell-smbios.c:506:36: error: 'sprintf' writing a 
> terminating nul past the end of the destination [-Werror=format-overflow=]
>sprintf(buffer_value, "%04x_value",
> drivers/platform/x86/dell-smbios.c:506:3: note: 'sprintf' output 11 bytes 
> into a destination of size 10
> 
> This changes it to just use kasprintf(), which always gets it right.
> 
> Fixes: 33b9ca1e53b4 ("platform/x86: dell-smbios: Add a sysfs interface for 
> SMBIOS tokens")
> Signed-off-by: Arnd Bergmann 

Reviewed-by: Pali Rohár 

> ---
>  drivers/platform/x86/dell-smbios.c | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/platform/x86/dell-smbios.c 
> b/drivers/platform/x86/dell-smbios.c
> index d99edd803c19..6a60db515bda 100644
> --- a/drivers/platform/x86/dell-smbios.c
> +++ b/drivers/platform/x86/dell-smbios.c
> @@ -463,8 +463,6 @@ static struct platform_driver platform_driver = {
>  
>  static int build_tokens_sysfs(struct platform_device *dev)
>  {
> - char buffer_location[13];
> - char buffer_value[10];
>   char *location_name;
>   char *value_name;
>   size_t size;
> @@ -491,9 +489,8 @@ static int build_tokens_sysfs(struct platform_device *dev)
>   if (da_tokens[i].tokenID == 0)
>   continue;
>   /* add location */
> - sprintf(buffer_location, "%04x_location",
> - da_tokens[i].tokenID);
> - location_name = kstrdup(buffer_location, GFP_KERNEL);
> + location_name = kasprintf(GFP_KERNEL, "%04x_location",
> +   da_tokens[i].tokenID);
>   if (location_name == NULL)
>   goto out_unwind_strings;
>   sysfs_attr_init(_location_attrs[i].attr);
> @@ -503,9 +500,8 @@ static int build_tokens_sysfs(struct platform_device *dev)
>   token_attrs[j++] = _location_attrs[i].attr;
>  
>   /* add value */
> - sprintf(buffer_value, "%04x_value",
> - da_tokens[i].tokenID);
> - value_name = kstrdup(buffer_value, GFP_KERNEL);
> + value_name = kasprintf(GFP_KERNEL, "%04x_value",
> +da_tokens[i].tokenID);
>   if (value_name == NULL)
>   goto loop_fail_create_value;
>   sysfs_attr_init(_value_attrs[i].attr);

-- 
Pali Rohár
pali.ro...@gmail.com

Re: [PATCH] mm: don't warn about allocations which stall for too long

[Michal Hocko]

[Please try to trim the context you are replying to]

On Wed 08-11-17 11:30:23, peter enderborg wrote:
[...]
> What about the idea to keep the function, but instead of printing only do a 
> trace event.

I am not sure. I would rather see a tracepoint to mark the allocator
entry. This would allow both 1) measuring the allocation latency (to
compare it to the trace_mm_page_alloc and 2) check for stalls with
arbitrary user defined timeout (just print all allocations which haven't
passed trace_mm_page_alloc for the given amount of time).
-- 
Michal Hocko
SUSE Labs

[PATCH] crypto: chelsio: remove redundant assignments to reqctx and dst_size

[Colin King]

From: Colin Ian King 

Pointer reqctx is assigned the same value twice, once on initialization
and again a few statements later, remove the second redundant assignment.
Variable dst_size is assigned but it is never read, so the variable is
redundant and can be removed. Cleans up clang warnings:

drivers/crypto/chelsio/chcr_algo.c:156:29: warning: Value stored to
'reqctx' during its initialization is never read
drivers/crypto/chelsio/chcr_algo.c:2020:2: warning: Value stored to
'dst_size' is never read

Signed-off-by: Colin Ian King 
---
 drivers/crypto/chelsio/chcr_algo.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/crypto/chelsio/chcr_algo.c 
b/drivers/crypto/chelsio/chcr_algo.c
index 4eed7171e2ae..300e66fe8a3c 100644
--- a/drivers/crypto/chelsio/chcr_algo.c
+++ b/drivers/crypto/chelsio/chcr_algo.c
@@ -160,7 +160,6 @@ static inline void chcr_handle_ahash_resp(struct 
ahash_request *req,
 
if (input == NULL)
goto out;
-   reqctx = ahash_request_ctx(req);
digestsize = crypto_ahash_digestsize(crypto_ahash_reqtfm(req));
if (reqctx->is_sg_map)
chcr_hash_dma_unmap(_ctx->lldi.pdev->dev, req);
@@ -2014,11 +2013,8 @@ static int chcr_aead_common_init(struct aead_request 
*req,
struct chcr_aead_ctx *aeadctx = AEAD_CTX(a_ctx(tfm));
struct chcr_aead_reqctx  *reqctx = aead_request_ctx(req);
int error = -EINVAL;
-   unsigned int dst_size;
unsigned int authsize = crypto_aead_authsize(tfm);
 
-   dst_size = req->assoclen + req->cryptlen + (op_type ?
-   -authsize : authsize);
/* validate key size */
if (aeadctx->enckey_len == 0)
goto err;
-- 
2.14.1

Re: WTF? Re: [PATCH] License cleanup: add SPDX GPL-2.0 license identifier to files with no license

[Christoph Hellwig]

On Thu, Nov 09, 2017 at 09:23:35AM +0100, Greg Kroah-Hartman wrote:
> The documentation of this process is lagging the patches, as usually
> happens, sorry about that.

In cases like this the documentation is the most important part.
Without documentation it is completely pointless.

> 
> Thomas is working on a document to describe the process, and what a file
> should contain, based on the work he has been doing.  This was discussed
> at the kernel summit, and sorry for it not getting out wider than that
> audience, things take time, which is why I was only touching my
> subsystems with the "general license cleanups" at the moment until his
> document was ready.
> 
> Hopefully a draft of it will go out today, Thomas?

It would help to Cc him, I've done that. 

> SPDX is an industry-wide accepted set of tags for all licenses, some
> projects have been using it for years (like Uboot).  These are not going
> to change randomly, and again, the document that Thomas has will
> describe these in detail.

It is not an 'industry-wide accepted set of tags' (did you get a company
discount on buzzwords).  Yes, it it a scheme someone can up with (seems
like an industry consortium that happens to employ you, what a
coincidence), and from a quick look it even seems like a pretty reasonable
scheme.  But without backing it with an explanation of those tags in
the tree, and explaining people how to use them and how they are
relevant it is absolutely useless.

And to come up with a scheme we need to have a broad discussion on
what we are doing.

> sorry for the confusion, it was not intended at all, but it what happens
> in time with distributed developers, all working at different rates on
> different parts of the tree.

Sorry but I call bullshit on this.  We have absolutely no problem
working together if we try.  You clearly did not even try to cooperate
with anyone - the clear indicator is that no RFC was posted, no
questions were asked but you just sent a pull requests right before
the end of the merge window.

Re: [PATCH] slub: Fix sysfs duplicate filename creation when slub_debug=O

[Miles Chen]

On Wed, 2017-11-08 at 09:05 -0600, Christopher Lameter wrote:
> On Wed, 8 Nov 2017, Miles Chen wrote:
> 
> > > Ok then the aliasing failed for some reason. The creation of the unique id
> > > and the alias detection needs to be in sync otherwise duplicate filenames
> > > are created. What is the difference there?
> >
> > The aliasing failed because find_mergeable() returns if (flags &
> > SLAB_NEVER_MERGE) is true. So we do not go to search for alias caches.
> >
> > __kmem_cache_alias()
> >   find_mergeable()
> > kmem_cache_flags()  --> setup flag by the slub_debug
> > if (flags & SLAB_NEVER_MERGE) return NULL;
> > ...
> > search alias logic...
> >
> >
> > The flags maybe changed if disable_higher_order_debug=1. So the
> > unmergeable cache becomes mergeable later.
> 
> Ok so make sure taht the aliasing logic also clears those flags before
> checking for SLAB_NEVER_MERGE.
> 
> > > The clearing of the DEBUG_METADATA_FLAGS looks ok to me. kmem_cache_alias
> > > should do the same right?
> > >
> > Yes, I think clearing DEBUG_METADATA flags in kmem_cache_alias is
> > another solution for this issue.
> >
> > We will need to do calculate_sizes() by using original flags and compare
> > the order of s->size and s->object_size when
> > disable_higher_order_debug=1.
> 
> Hmmm... Or move the aliasing check to a point where we know the size of
> the slab objects?

The biggest concern is that we may have some merged caches even if we
enable CONFIG_SLUB_DEBUG_ON and slub_debug=O. So a developer cannot say
"I set CONFIG_SLUB_DEBUG_ON=y to stop all slab merging". 
(https://www.spinics.net/lists/linux-mm/msg77919.html)

In this fix patch, it disables slab merging if SLUB_DEBUG=O and
CONFIG_SLUB_DEBUG_ON=y but the debug features are disabled by the
disable_higher_order_debug logic and it holds the "slab merging is off
if any debug features are enabled" behavior.

[PATCH v2 06/10] staging: ccree: simplify pm manager using local var

[Gilad Ben-Yossef]

Make the code more readable by using a local variable.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_pm.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/ccree/ssi_pm.c b/drivers/staging/ccree/ssi_pm.c
index e1bc4c5..d60143c 100644
--- a/drivers/staging/ccree/ssi_pm.c
+++ b/drivers/staging/ccree/ssi_pm.c
@@ -90,20 +90,24 @@ int cc_pm_resume(struct device *dev)
 int cc_pm_get(struct device *dev)
 {
int rc = 0;
+   struct ssi_drvdata *drvdata =
+   (struct ssi_drvdata *)dev_get_drvdata(dev);
 
-   if (cc_req_queue_suspended((struct ssi_drvdata *)dev_get_drvdata(dev))) 
{
+   if (cc_req_queue_suspended(drvdata))
rc = pm_runtime_get_sync(dev);
-   } else {
+   else
pm_runtime_get_noresume(dev);
-   }
+
return rc;
 }
 
 int cc_pm_put_suspend(struct device *dev)
 {
int rc = 0;
+   struct ssi_drvdata *drvdata =
+   (struct ssi_drvdata *)dev_get_drvdata(dev);
 
-   if (!cc_req_queue_suspended((struct ssi_drvdata 
*)dev_get_drvdata(dev))) {
+   if (!cc_req_queue_suspended(drvdata)) {
pm_runtime_mark_last_busy(dev);
rc = pm_runtime_put_autosuspend(dev);
} else {
-- 
2.7.4

Re: [PATCH] extcon: max77693: Delete an unnecessary variable initialisation in max77693_muic_set_path()

[Chanwoo Choi]

Hi,

On 2017년 11월 09일 17:49, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Thu, 9 Nov 2017 09:40:59 +0100
> 
> The variable "ret" will be set to an appropriate value a bit later.
> Thus omit the explicit initialisation at the beginning.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/extcon/extcon-max77693.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/extcon/extcon-max77693.c 
> b/drivers/extcon/extcon-max77693.c
> index 643411066ad9..227651ff9666 100644
> --- a/drivers/extcon/extcon-max77693.c
> +++ b/drivers/extcon/extcon-max77693.c
> @@ -266,7 +266,7 @@ static int max77693_muic_set_debounce_time(struct 
> max77693_muic_info *info,
>  static int max77693_muic_set_path(struct max77693_muic_info *info,
>   u8 val, bool attached)
>  {
> - int ret = 0;
> + int ret;
>   unsigned int ctrl1, ctrl2 = 0;
>  
>   if (attached)
> 

Applied it. But, it will be merged to v4.16-rc1.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

[PATCH v2 05/10] staging: ccree: fold common code into function

[Gilad Ben-Yossef]

Fold common code copying MAC to/from a temp. buffer
into an inline function instead of keeping multiple
open coded versions of same.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_buffer_mgr.c | 89 ++
 1 file changed, 37 insertions(+), 52 deletions(-)

diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index b3ca249..48c0b02 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -65,6 +65,27 @@ struct buffer_array {
 };
 
 /**
+ * cc_copy_mac() - Copy MAC to temporary location
+ *
+ * @dev: device object
+ * @req: aead request object
+ * @dir: [IN] copy from/to sgl
+ */
+static inline void cc_copy_mac(struct device *dev, struct aead_request *req,
+  enum ssi_sg_cpy_direct dir)
+{
+   struct aead_req_ctx *areq_ctx = aead_request_ctx(req);
+   struct crypto_aead *tfm = crypto_aead_reqtfm(req);
+   u32 skip = req->assoclen + req->cryptlen;
+
+   if (areq_ctx->is_gcm4543)
+   skip += crypto_aead_ivsize(tfm);
+
+   cc_copy_sg_portion(dev, areq_ctx->backup_mac, req->src,
+  (skip - areq_ctx->req_authsize), skip, dir);
+}
+
+/**
  * cc_get_sgl_nents() - Get scatterlist number of entries.
  *
  * @sg_list: SG list
@@ -670,19 +691,11 @@ void cc_unmap_aead_request(struct device *dev, struct 
aead_request *req)
if (drvdata->coherent &&
(areq_ctx->gen_ctx.op_type == DRV_CRYPTO_DIRECTION_DECRYPT) &&
likely(req->src == req->dst)) {
-   u32 size_to_skip = req->assoclen;
-
-   if (areq_ctx->is_gcm4543)
-   size_to_skip += crypto_aead_ivsize(tfm);
 
-   /* copy mac to a temporary location to deal with possible
+   /* copy back mac from temporary location to deal with possible
 * data memory overriding that caused by cache coherence 
problem.
 */
-   cc_copy_sg_portion(dev, areq_ctx->backup_mac, req->src,
-  (size_to_skip + req->cryptlen -
-   areq_ctx->req_authsize),
-  (size_to_skip + req->cryptlen),
-  SSI_SG_FROM_BUF);
+   cc_copy_mac(dev, req, SSI_SG_FROM_BUF);
}
 }
 
@@ -918,7 +931,6 @@ static inline int cc_prepare_aead_data_mlli(
enum drv_crypto_direction direct = areq_ctx->gen_ctx.op_type;
unsigned int authsize = areq_ctx->req_authsize;
int rc = 0, icv_nents;
-   struct crypto_aead *tfm = crypto_aead_reqtfm(req);
struct device *dev = drvdata_to_dev(drvdata);
 
if (likely(req->src == req->dst)) {
@@ -943,24 +955,14 @@ static inline int cc_prepare_aead_data_mlli(
 * MAC verification upon request completion
 */
if (direct == DRV_CRYPTO_DIRECTION_DECRYPT) {
-   if (!drvdata->coherent) {
/* In coherent platforms (e.g. ACP)
 * already copying ICV for any
 * INPLACE-DECRYPT operation, hence
 * we must neglect this code.
 */
-   u32 skip = req->assoclen;
-
-   if (areq_ctx->is_gcm4543)
-   skip += crypto_aead_ivsize(tfm);
-
-   cc_copy_sg_portion(dev,
-  areq_ctx->backup_mac,
-  req->src,
-  (skip + 
req->cryptlen - areq_ctx->req_authsize),
-  (skip + 
req->cryptlen),
-  SSI_SG_TO_BUF);
-   }
+   if (!drvdata->coherent)
+   cc_copy_mac(dev, req, SSI_SG_TO_BUF);
+
areq_ctx->icv_virt_addr = areq_ctx->backup_mac;
} else {
areq_ctx->icv_virt_addr = areq_ctx->mac_buf;
@@ -996,22 +998,14 @@ static inline int cc_prepare_aead_data_mlli(
goto prepare_data_mlli_exit;
}
 
+   /* Backup happens only when ICV is fragmented, ICV
+* verification is made by CPU compare in order to simplify
+* MAC verification upon request completion
+*/
if (unlikely(areq_ctx->is_icv_fragmented)) {
-   /* Backup happens only when ICV is fragmented, ICV
-* verification is made 

Re: [PATCH] extcon: max8997: Delete an unnecessary variable initialisation in max8997_muic_set_path()

[Chanwoo Choi]

Hi,

On 2017년 11월 09일 18:05, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Thu, 9 Nov 2017 10:00:08 +0100
> 
> The variable "ret" will be set to an appropriate value a bit later.
> Thus omit the explicit initialisation at the beginning.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/extcon/extcon-max8997.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/extcon/extcon-max8997.c b/drivers/extcon/extcon-max8997.c
> index 8152790d72e1..9f30f4929b72 100644
> --- a/drivers/extcon/extcon-max8997.c
> +++ b/drivers/extcon/extcon-max8997.c
> @@ -204,7 +204,7 @@ static int max8997_muic_set_debounce_time(struct 
> max8997_muic_info *info,
>  static int max8997_muic_set_path(struct max8997_muic_info *info,
>   u8 val, bool attached)
>  {
> - int ret = 0;
> + int ret;
>   u8 ctrl1, ctrl2 = 0;
>  
>   if (attached)
> 

Applied it.
But, it will be merged to v4.16-rc1.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics