[PATCH v2 11/20] [SCSI] mpt3sas: Add branding string support for OEM custom HBA

[Sreekanth Reddy]

Add the following OEM's branding to the mpt3sas driver.

"VendorID"   "DeviceID"  "SubsystemVendor ID"   "SubsystemDevice ID"  Cisco 
Branding String
0x1000 0x97 SVID = 0x1137 0x014C  Cisco 
9300-8E 12G SAS HBA

Changes in v2:
Patch version change only.

Signed-off-by: Sreekanth Reddy 
Reviewed-by: Martin K. Petersen 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 34 ++
 drivers/scsi/mpt3sas/mpt3sas_base.h | 11 +++
 2 files changed, 45 insertions(+)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index e8b93a8..4f82687 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -2398,6 +2398,39 @@ _base_display_dell_branding(struct MPT3SAS_ADAPTER *ioc)
}
 }
 
+/**
+ * _base_display_cisco_branding - Display branding string
+ * @ioc: per adapter object
+ *
+ * Return nothing.
+ */
+static void
+_base_display_cisco_branding(struct MPT3SAS_ADAPTER *ioc)
+{
+   if (ioc->pdev->subsystem_vendor != PCI_VENDOR_ID_CISCO)
+   return;
+
+   switch (ioc->pdev->device) {
+   case MPI25_MFGPAGE_DEVID_SAS3008:
+   switch (ioc->pdev->subsystem_device) {
+   case MPT3SAS_CISCO_12G_HBA_SSDID:
+   pr_info(MPT3SAS_FMT "%s\n", ioc->name,
+   MPT3SAS_CISCO_12G_HBA_BRANDING);
+   break;
+   default:
+   pr_info(MPT3SAS_FMT
+ "Cisco 12Gbps SAS HBA: Subsystem ID: 0x%X\n",
+ ioc->name, ioc->pdev->subsystem_device);
+   break;
+   }
+   break;
+   default:
+pr_info(MPT3SAS_FMT
+   "Cisco 12Gbps SAS HBA: Subsystem ID: 0x%X\n",
+   ioc->name, ioc->pdev->subsystem_device);
+   break;
+   }
+}
 
 /**
  * _base_display_ioc_capabilities - Disply IOC's capabilities.
@@ -2430,6 +2463,7 @@ _base_display_ioc_capabilities(struct MPT3SAS_ADAPTER 
*ioc)
 
_base_display_intel_branding(ioc);
_base_display_dell_branding(ioc);
+   _base_display_cisco_branding(ioc);
 
pr_info(MPT3SAS_FMT "Protocol=(", ioc->name);
 
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index a5a34f3..736682c 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -163,6 +163,17 @@
 #define MPT3SAS_DELL_12G_HBA_SSDID 0x1F46
 
 /*
+ * Cisco HBA branding
+ */
+#define MPT3SAS_CISCO_12G_HBA_BRANDING   \
+   "Cisco 9300-8E 12G SAS HBA"
+
+/*
+ * Cisco HBA SSSDIDs
+ */
+ #define MPT3SAS_CISCO_12G_HBA_SSDID  0x14C
+
+/*
  * status bits for ioc->diag_buffer_status
  */
 #define MPT3_DIAG_BUFFER_IS_REGISTERED (0x01)
-- 
2.0.2

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

[PATCH v2 12/20] [SCSI] mpt3sas: Bump mpt3sas driver version to v6.100.00.00

[Sreekanth Reddy]

Bump mpt3sas driver version to v6.100.00.00.

Changes in v2:
Patch version change only.

Signed-off-by: Sreekanth Reddy 
Reviewed-by: Martin K. Petersen 
Reviewed-by: Johannes Thumshirn 
---
 drivers/scsi/mpt3sas/mpt3sas_base.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 736682c..4196fbb 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -71,8 +71,8 @@
 #define MPT3SAS_DRIVER_NAME"mpt3sas"
 #define MPT3SAS_AUTHOR "Avago Technologies "
 #define MPT3SAS_DESCRIPTION"LSI MPT Fusion SAS 3.0 Device Driver"
-#define MPT3SAS_DRIVER_VERSION "05.100.00.00"
-#define MPT3SAS_MAJOR_VERSION  5
+#define MPT3SAS_DRIVER_VERSION "06.100.00.00"
+#define MPT3SAS_MAJOR_VERSION  6
 #define MPT3SAS_MINOR_VERSION  100
 #define MPT3SAS_BUILD_VERSION  0
 #define MPT3SAS_RELEASE_VERSION00
-- 
2.0.2

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

[PATCH v2 13/20] [SCSI] mpt3sas: MPI 2.5 Rev K (2.5.6) specifications

[Sreekanth Reddy]

Below are the new changes to MPI 2.5 Rev K(2.5.6) specification and 2.00.35 
header files
1) Added a minimum size requirement for target mode command buffers.
2) Added MinMSIxIndex and MaxMSIxIndex fields to CommandBufferPostBase Request.
3) For BIOS Page 1, added SSUTimeout field, and added Product Name String 
Format bits to the BiosOptions field

Changes in v2:
Patch version change only.

Signed-off-by: Sreekanth Reddy 
Reviewed-by: Martin K. Petersen 
Reviewed-by: Johannes Thumshirn 
---
 drivers/scsi/mpt3sas/mpi/mpi2.h  |  5 +++--
 drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h | 17 ++---
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpi/mpi2.h b/drivers/scsi/mpt3sas/mpi/mpi2.h
index c2d127c..ec27ad2 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2.h
@@ -8,7 +8,7 @@
  * scatter/gather formats.
  * Creation Date:  June 21, 2006
  *
- * mpi2.h Version:  02.00.34
+ * mpi2.h Version:  02.00.35
  *
  * NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
  *   prefix are for use only on MPI v2.5 products, and must not be used
@@ -91,6 +91,7 @@
  * 08-19-13  02.00.32  Bumped MPI2_HEADER_VERSION_UNIT.
  * 12-05-13  02.00.33  Bumped MPI2_HEADER_VERSION_UNIT.
  * 01-08-14  02.00.34  Bumped MPI2_HEADER_VERSION_UNIT
+ * 06-13-14  02.00.35  Bumped MPI2_HEADER_VERSION_UNIT.
  * --
  */
 
@@ -124,7 +125,7 @@
 #define MPI2_VERSION_02_05  (0x0205)
 
 /*Unit and Dev versioning for this MPI header set */
-#define MPI2_HEADER_VERSION_UNIT(0x22)
+#define MPI2_HEADER_VERSION_UNIT(0x23)
 #define MPI2_HEADER_VERSION_DEV (0x00)
 #define MPI2_HEADER_VERSION_UNIT_MASK   (0xFF00)
 #define MPI2_HEADER_VERSION_UNIT_SHIFT  (8)
diff --git a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h 
b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
index cf2b6bf..581fdb3 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
@@ -6,7 +6,7 @@
  * Title:  MPI Configuration messages and pages
  * Creation Date:  November 10, 2006
  *
- *   mpi2_cnfg.h Version:  02.00.28
+ *   mpi2_cnfg.h Version:  02.00.29
  *
  * NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
  *   prefix are for use only on MPI v2.5 products, and must not be used
@@ -177,6 +177,8 @@
  *MPI2_CONFIG_PAGE_SAS_ENCLOSURE_0.
  * 01-08-14  02.00.28  Added more defines for the BiosOptions field of
  *MPI2_CONFIG_PAGE_BIOS_1.
+ * 06-13-14  02.00.29  Added SSUTimeout field to MPI2_CONFIG_PAGE_BIOS_1, and
+ *more defines for the BiosOptions field..
  * --
  */
 
@@ -1324,7 +1326,9 @@ typedef struct _MPI2_CONFIG_PAGE_BIOS_1 {
MPI2_CONFIG_PAGE_HEADER Header; /*0x00 */
U32 BiosOptions;/*0x04 */
U32 IOCSettings;/*0x08 */
-   U32 Reserved1;  /*0x0C */
+   U8  SSUTimeout; /*0x0C */
+   U8  Reserved1;  /*0x0D */
+   U16 Reserved2;  /*0x0E */
U32 DeviceSettings; /*0x10 */
U16 NumberOfDevices;/*0x14 */
U16 UEFIVersion;/*0x16 */
@@ -1336,9 +1340,16 @@ typedef struct _MPI2_CONFIG_PAGE_BIOS_1 {
*PTR_MPI2_CONFIG_PAGE_BIOS_1,
Mpi2BiosPage1_t, *pMpi2BiosPage1_t;
 
-#define MPI2_BIOSPAGE1_PAGEVERSION  (0x06)
+#define MPI2_BIOSPAGE1_PAGEVERSION  (0x07)
 
 /*values for BIOS Page 1 BiosOptions field */
+#define MPI2_BIOSPAGE1_OPTIONS_PNS_MASK (0x3800)
+#define MPI2_BIOSPAGE1_OPTIONS_PNS_PBDHL(0x)
+#define MPI2_BIOSPAGE1_OPTIONS_PNS_ENCSLOSURE   (0x0800)
+#define MPI2_BIOSPAGE1_OPTIONS_PNS_LWWID(0x1000)
+#define MPI2_BIOSPAGE1_OPTIONS_PNS_PSENS(0x1800)
+#define MPI2_BIOSPAGE1_OPTIONS_PNS_ESPHY(0x2000)
+
 #define MPI2_BIOSPAGE1_OPTIONS_X86_DISABLE_BIOS(0x0400)
 
 #define MPI2_BIOSPAGE1_OPTIONS_MASK_REGISTRATION_UEFI_BSD  (0x0300)
-- 
2.0.2

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

[PATCH v2 14/20] [SCSI] mpt3sas: Complete the SCSI command with DID_RESET status for log_info value 0x0x32010081

[Sreekanth Reddy]

For any SCSI command, if the driver receives
IOC status = SCSI_IOC_TERMINATED and log info = 0x32010081 then
that command will be completed with DID_RESET host status.

The definition of this log info value is
"Virtual IO has failed and has to be retried".

Firmware will provide this log info value with IOC Status
"SCSI_IOC_TERMINATED", whenever a drive (with is a part of a volume)
is pulled and pushed back within some minimal delay.
With this log info value, firmware informs the driver to retry the
failed IO command infinite times, so to provide some time for the
firmware to discover the reinserted drive successfully instated of
just retrying failed command for five times(doesn't giving enough
time for firmware to complete the drive discovery) and failing the
IO permanently even though drive came back successfully.

Changes in v1:
   Defined macro VIRTUAL_IO_FAILED_RETRY for magic a value 0x32010081

Changes in v2:
Patch version change only.

Signed-off-by: Sreekanth Reddy 
Reviewed-by: Martin K. Petersen 
Reviewed-by: Johannes Thumshirn 
---
 drivers/scsi/mpt3sas/mpt3sas_base.h  | 2 ++
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 4196fbb..3b03639 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -202,6 +202,8 @@
 #define MFG10_GF0_SSD_DATA_SCRUB_DISABLE   (0x0008)
 #define MFG10_GF0_SINGLE_DRIVE_R0  (0x0010)
 
+#define VIRTUAL_IO_FAILED_RETRY(0x32010081)
+
 /* OEM Specific Flags will come from OEM specific header files */
 struct Mpi2ManufacturingPage10_t {
MPI2_CONFIG_PAGE_HEADER Header; /* 00h */
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 64dd90b..49c412b 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -4241,6 +4241,9 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 
msix_index, u32 reply)
scmd->device->expecting_cc_ua = 1;
}
break;
+   } else if (log_info == VIRTUAL_IO_FAILED_RETRY) {
+   scmd->result = DID_RESET << 16;
+   break;
}
scmd->result = DID_SOFT_ERROR << 16;
break;
-- 
2.0.2

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

[PATCH v2 15/20] [SCSI] mpt3sas: Return host busy error status to SML when DMA mapping of scatter gather list fails for a SCSI command

[Sreekanth Reddy]

scsi_dma_map API will return a negative value (i.e. -ENOMEM)
if DMA mapping of sg lists fails and zero if the sg list in the
SCSI cmd is NULL. But drivers doesn't handled sg list DMA mapping
failure case properly.

So, Updated the code to return host busy error status to SCSI MID Layer(SML),
when DMA mapping of scatter gather list fails for a SCSI command.
So that SML will retry this SCSI cmd after some time.

Changes in v2:
Corrected the typo mistake from "(!sges_left < 0)" to "(sges_left < 0)".

Signed-off-by: Sreekanth Reddy 
Reviewed-by: Martin K. Petersen 
Reviewed-by: Johannes Thumshirn 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 4f82687..6e44370 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1360,7 +1360,7 @@ _base_build_sg_scmd_ieee(struct MPT3SAS_ADAPTER *ioc,
 
sg_scmd = scsi_sglist(scmd);
sges_left = scsi_dma_map(scmd);
-   if (!sges_left) {
+   if (sges_left < 0) {
sdev_printk(KERN_ERR, scmd->device,
"pci_map_sg failed: request for %d bytes!\n",
scsi_bufflen(scmd));
@@ -1429,7 +1429,7 @@ _base_build_sg_scmd_ieee(struct MPT3SAS_ADAPTER *ioc,
  fill_in_last_segment:
 
/* fill the last segment */
-   while (sges_left) {
+   while (sges_left > 0) {
if (sges_left == 1)
_base_add_sg_single_ieee(sg_local,
simple_sgl_flags_last, 0, sg_dma_len(sg_scmd),
-- 
2.0.2

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

[PATCH v2 16/20] [SCSI] mpt3sas: Added support for customer specific branding

[Sreekanth Reddy]

Added support for below customer specific brandings

"VendorID"   "DeviceID"  "SubsystemVendor ID"   "SubsystemDevice ID"  Cisco 
Branding String
0x1000 0x97   0x1137 0x154   Cisco 
9300-8i 12Gbps SAS HBA
0x1000 0x97   0x1137 0x155   Cisco 12G 
Modular SAS Pass through Controller
0x1000 0x97   0x1137 0x156   UCS C3X60 
12G SAS Pass through Controller

Changes in v2:
Patch version change only.

Signed-off-by: Sreekanth Reddy 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 29 +++--
 drivers/scsi/mpt3sas/mpt3sas_base.h | 16 
 2 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 6e44370..dd04ec0 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -2413,9 +2413,17 @@ _base_display_cisco_branding(struct MPT3SAS_ADAPTER *ioc)
switch (ioc->pdev->device) {
case MPI25_MFGPAGE_DEVID_SAS3008:
switch (ioc->pdev->subsystem_device) {
-   case MPT3SAS_CISCO_12G_HBA_SSDID:
+   case MPT3SAS_CISCO_12G_8E_HBA_SSDID:
pr_info(MPT3SAS_FMT "%s\n", ioc->name,
-   MPT3SAS_CISCO_12G_HBA_BRANDING);
+   MPT3SAS_CISCO_12G_8E_HBA_BRANDING);
+   break;
+   case MPT3SAS_CISCO_12G_8I_HBA_SSDID:
+   pr_info(MPT3SAS_FMT "%s\n", ioc->name,
+   MPT3SAS_CISCO_12G_8I_HBA_BRANDING);
+   break;
+   case MPT3SAS_CISCO_12G_AVILA_HBA_SSDID:
+   pr_info(MPT3SAS_FMT "%s\n", ioc->name,
+   MPT3SAS_CISCO_12G_AVILA_HBA_BRANDING);
break;
default:
pr_info(MPT3SAS_FMT
@@ -2424,6 +2432,23 @@ _base_display_cisco_branding(struct MPT3SAS_ADAPTER *ioc)
break;
}
break;
+   case MPI25_MFGPAGE_DEVID_SAS3108_1:
+   switch (ioc->pdev->subsystem_device) {
+   case MPT3SAS_CISCO_12G_AVILA_HBA_SSDID:
+   pr_info(MPT3SAS_FMT "%s\n", ioc->name,
+   MPT3SAS_CISCO_12G_AVILA_HBA_BRANDING);
+   break;
+   case MPT3SAS_CISCO_12G_COLUSA_MEZZANINE_HBA_SSDID:
+   pr_info(MPT3SAS_FMT "%s\n", ioc->name,
+   MPT3SAS_CISCO_12G_COLUSA_MEZZANINE_HBA_BRANDING);
+   break;
+   default:
+   pr_info(MPT3SAS_FMT
+"Cisco 12Gbps SAS HBA: Subsystem ID: 0x%X\n",
+ioc->name, ioc->pdev->subsystem_device);
+   break;
+   }
+   break;
default:
 pr_info(MPT3SAS_FMT
"Cisco 12Gbps SAS HBA: Subsystem ID: 0x%X\n",
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 3b03639..87e9000 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -165,13 +165,21 @@
 /*
  * Cisco HBA branding
  */
-#define MPT3SAS_CISCO_12G_HBA_BRANDING   \
-   "Cisco 9300-8E 12G SAS HBA"
-
+#define MPT3SAS_CISCO_12G_8E_HBA_BRANDING  \
+   "Cisco 9300-8E 12G SAS HBA"
+#define MPT3SAS_CISCO_12G_8I_HBA_BRANDING  \
+   "Cisco 9300-8i 12G SAS HBA"
+#define MPT3SAS_CISCO_12G_AVILA_HBA_BRANDING   \
+   "Cisco 12G Modular SAS Pass through Controller"
+#define MPT3SAS_CISCO_12G_COLUSA_MEZZANINE_HBA_BRANDING\
+   "UCS C3X60 12G SAS Pass through Controller"
 /*
  * Cisco HBA SSSDIDs
  */
- #define MPT3SAS_CISCO_12G_HBA_SSDID  0x14C
+#define MPT3SAS_CISCO_12G_8E_HBA_SSDID  0x14C
+#define MPT3SAS_CISCO_12G_8I_HBA_SSDID  0x154
+#define MPT3SAS_CISCO_12G_AVILA_HBA_SSDID  0x155
+#define MPT3SAS_CISCO_12G_COLUSA_MEZZANINE_HBA_SSDID  0x156
 
 /*
  * status bits for ioc->diag_buffer_status
-- 
2.0.2

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

[PATCH v2 10/20] [SCSI] mpt3sas: Add branding string support for OEM's HBA

[Sreekanth Reddy]

Added the following Dell branding to the mpt3sas driver.

"VendorID"   "DeviceID"  "SubsystemVendor ID"  "SubsystemDevice ID"  Dell 
Branding String
0x10000x0097  0x1028 0x1F46DELL 
12Gbps HBA

Changes in v2:
Patch version change only.

Signed-off-by: Sreekanth Reddy 
Reviewed-by: Martin K. Petersen 
Reviewed-by: Johannes Thumshirn 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 36 
 drivers/scsi/mpt3sas/mpt3sas_base.h | 11 +++
 2 files changed, 47 insertions(+)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 8730160..e8b93a8 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -2365,6 +2365,41 @@ _base_display_intel_branding(struct MPT3SAS_ADAPTER *ioc)
 
 
 /**
+ * _base_display_dell_branding - Display branding string
+ * @ioc: per adapter object
+ *
+ * Return nothing.
+ */
+static void
+_base_display_dell_branding(struct MPT3SAS_ADAPTER *ioc)
+{
+   if (ioc->pdev->subsystem_vendor != PCI_VENDOR_ID_DELL)
+   return;
+
+   switch (ioc->pdev->device) {
+   case MPI25_MFGPAGE_DEVID_SAS3008:
+   switch (ioc->pdev->subsystem_device) {
+   case MPT3SAS_DELL_12G_HBA_SSDID:
+   pr_info(MPT3SAS_FMT "%s\n", ioc->name,
+   MPT3SAS_DELL_12G_HBA_BRANDING);
+   break;
+   default:
+   pr_info(MPT3SAS_FMT
+  "Dell 12Gbps HBA: Subsystem ID: 0x%X\n", ioc->name,
+  ioc->pdev->subsystem_device);
+   break;
+   }
+   break;
+   default:
+   pr_info(MPT3SAS_FMT
+   "Dell 12Gbps HBA: Subsystem ID: 0x%X\n", ioc->name,
+   ioc->pdev->subsystem_device);
+   break;
+   }
+}
+
+
+/**
  * _base_display_ioc_capabilities - Disply IOC's capabilities.
  * @ioc: per adapter object
  *
@@ -2394,6 +2429,7 @@ _base_display_ioc_capabilities(struct MPT3SAS_ADAPTER 
*ioc)
bios_version & 0x00FF);
 
_base_display_intel_branding(ioc);
+   _base_display_dell_branding(ioc);
 
pr_info(MPT3SAS_FMT "Protocol=(", ioc->name);
 
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index c0c774f..a5a34f3 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -152,6 +152,17 @@
 #define MPT3SAS_INTEL_RS3UC080_SSDID0x3524
 
 /*
+ * Dell HBA branding
+ */
+#define MPT3SAS_DELL_12G_HBA_BRANDING   \
+   "Dell 12Gbps HBA"
+
+/*
+ * Dell HBA SSDIDs
+ */
+#define MPT3SAS_DELL_12G_HBA_SSDID 0x1F46
+
+/*
  * status bits for ioc->diag_buffer_status
  */
 #define MPT3_DIAG_BUFFER_IS_REGISTERED (0x01)
-- 
2.0.2

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

[PATCH v2 05/20] [SCSI] mpt3sas: MPI 2.5 Rev I (2.5.4) specifications.

[Sreekanth Reddy]

Update MPI 2.5 Release: MPI 2.5 Rev I (2.5.4) specification and 2.00.33 header 
files

Below is the change set from the MPI specification for I Rev

1) Added Base Enclosure Level bit to the Flags field of Manufacturing Page 7.
2) Updated description of the MaxTargetPortConnectTime field of SAS IO Unit 
Page 1.
3) Added EnclosureLevel and ConnectorName fields to SAS Device Page 0. Also, 
added EnclosureLevel and ConnectorName Valid bit to the Flags field.
4) Added EnclosureLevel field to SAS Enclosure Page 0. Also, added 
EnclosureLevel Valid bit to the Flags field.
5) Added value for BIOS image to HashImageType.

Changes in v2:
Patch version change only.

Signed-off-by: Sreekanth Reddy 
Reviewed-by: Martin K. Petersen 
Reviewed-by: Johannes Thumshirn 
---
 drivers/scsi/mpt3sas/mpi/mpi2.h  |  6 --
 drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h | 27 +--
 drivers/scsi/mpt3sas/mpi/mpi2_ioc.h  |  4 +++-
 3 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpi/mpi2.h b/drivers/scsi/mpt3sas/mpi/mpi2.h
index c34c115..d730c5c 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2.h
@@ -8,7 +8,7 @@
  * scatter/gather formats.
  * Creation Date:  June 21, 2006
  *
- * mpi2.h Version:  02.00.31
+ * mpi2.h Version:  02.00.33
  *
  * NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
  *   prefix are for use only on MPI v2.5 products, and must not be used
@@ -88,6 +88,8 @@
  * Added MPI25_SUP_REPLY_POST_HOST_INDEX_OFFSET.
  * 04-09-13  02.00.30  Bumped MPI2_HEADER_VERSION_UNIT.
  * 04-17-13  02.00.31  Bumped MPI2_HEADER_VERSION_UNIT.
+ * 08-19-13  02.00.32  Bumped MPI2_HEADER_VERSION_UNIT.
+ * 12-05-13  02.00.33  Bumped MPI2_HEADER_VERSION_UNIT.
  * --
  */
 
@@ -121,7 +123,7 @@
 #define MPI2_VERSION_02_05  (0x0205)
 
 /*Unit and Dev versioning for this MPI header set */
-#define MPI2_HEADER_VERSION_UNIT(0x1F)
+#define MPI2_HEADER_VERSION_UNIT(0x21)
 #define MPI2_HEADER_VERSION_DEV (0x00)
 #define MPI2_HEADER_VERSION_UNIT_MASK   (0xFF00)
 #define MPI2_HEADER_VERSION_UNIT_SHIFT  (8)
diff --git a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h 
b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
index e261a31..62dfbf6 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
@@ -6,7 +6,7 @@
  * Title:  MPI Configuration messages and pages
  * Creation Date:  November 10, 2006
  *
- *   mpi2_cnfg.h Version:  02.00.26
+ *   mpi2_cnfg.h Version:  02.00.27
  *
  * NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
  *   prefix are for use only on MPI v2.5 products, and must not be used
@@ -165,6 +165,16 @@
  * match the specification.
  * 08-19-13  02.00.26  Added reserved words to MPI2_CONFIG_PAGE_IO_UNIT_7 for
  * future use.
+ * 12-05-13  02.00.27  Added MPI2_MANPAGE7_FLAG_BASE_ENCLOSURE_LEVEL for
+ *MPI2_CONFIG_PAGE_MAN_7.
+ *Added EnclosureLevel and ConnectorName fields to
+ *MPI2_CONFIG_PAGE_SAS_DEV_0.
+ *Added MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID for
+ *MPI2_CONFIG_PAGE_SAS_DEV_0.
+ *Added EnclosureLevel field to
+ *MPI2_CONFIG_PAGE_SAS_ENCLOSURE_0.
+ *Added MPI2_SAS_ENCLS0_FLAGS_ENCL_LEVEL_VALID for
+ *MPI2_CONFIG_PAGE_SAS_ENCLOSURE_0.
  * --
  */
 
@@ -724,6 +734,7 @@ typedef struct _MPI2_CONFIG_PAGE_MAN_7 {
 #define MPI2_MANUFACTURING7_PAGEVERSION (0x01)
 
 /*defines for the Flags field */
+#define MPI2_MANPAGE7_FLAG_BASE_ENCLOSURE_LEVEL (0x0008)
 #define MPI2_MANPAGE7_FLAG_EVENTREPLAY_SLOT_ORDER   (0x0002)
 #define MPI2_MANPAGE7_FLAG_USE_SLOT_INFO(0x0001)
 
@@ -2633,9 +2644,9 @@ typedef struct _MPI2_CONFIG_PAGE_SAS_DEV_0 {
U8
ControlGroup;   /*0x2E */
U8
-   Reserved1;  /*0x2F */
+   EnclosureLevel; /*0x2F */
U32
-   Reserved2;  /*0x30 */
+   ConnectorName[4];   /*0x30 */
U32
Reserved3;  /*0x34 */
 } MPI2_CONFIG_PAGE_SAS_DEV_0,
@@ -2643,7 +2654,7 @@ typedef struct _MPI2_CONFIG_PAGE_SAS_DEV_0 {
Mpi2SasDevicePage0_t,
*pMpi2SasDevicePage0_t;
 
-#define MPI2_SASDEVICE0_PAGEVERSION (0x08)
+#define MPI2_SASDEVICE0_PAGEVERSION (0x09)
 
 /*values for SAS Device Page 0 AccessStatus field */
 #define MPI2_SAS_DEVICE0_ASTATUS_NO_ERRORS  (0x00)
@@ -2683,6 +2694,7 @@ typedef struct _MPI2_CONFIG_PAGE_SAS_DEV_0 {
 #define MPI2_SAS_DEVICE0_FLAGS_SATA_NCQ_S

[PATCH v2 1/2] Document: DT: Add bindings for mediatek MT6580 SoC Platform

[Mars Cheng]

This adds a DT binding documentation for the MT6580 SoC from Mediatek.

Change-Id: I608738d330d356291b581203befcfe69c3a846c1
Signed-off-by: Mars Cheng 
---
 Documentation/devicetree/bindings/arm/mediatek.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt 
b/Documentation/devicetree/bindings/arm/mediatek.txt
index dd7550a..2daa424 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -5,6 +5,7 @@ Boards with a MediaTek mt65xx/mt81xx SoC shall have the 
following property:
 Required root node property:
 
 compatible: Must contain one of
+   "mediatek,mt6580"
"mediatek,mt6589"
"mediatek,mt6592"
"mediatek,mt8127"
@@ -14,6 +15,9 @@ compatible: Must contain one of
 
 Supported boards:
 
+- Evaluation board for MT6580:
+Required root node properties:
+  - compatible = "mediatek,mt6580-evbp1", "mediatek,mt6580";
 - bq Aquaris5 smart phone:
 Required root node properties:
   - compatible = "mundoreader,bq-aquaris5", "mediatek,mt6589";
-- 
1.8.1.1.dirty

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

[PATCH v2 0/2] Add mt6580 basic chip support

[Mars Cheng]

This patch add basic support for Mediatek's new 4-core chip, mt6580.

Change in v2:
1. Use stdout-path in device tree to indicate console
2. Remove board-specific bootargs

Mars Cheng (2):
  Document: DT: Add bindings for mediatek MT6580 SoC Platform
  ARM: dts: mediatek: add 6580 support

 Documentation/devicetree/bindings/arm/mediatek.txt |   4 +
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/mt6580-evbp1.dts |  35 ++
 arch/arm/boot/dts/mt6580.dtsi  | 125 +
 4 files changed, 165 insertions(+)
 create mode 100644 arch/arm/boot/dts/mt6580-evbp1.dts
 create mode 100644 arch/arm/boot/dts/mt6580.dtsi

--
1.8.1.1.dirty

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

[PATCH v2 06/20] [SCSI] mpt3sas: Provides the physical location of sas drives

[Sreekanth Reddy]

This Patch will provide more details of the devices such as slot number, 
enclosure logical id, enclosure level & connector name in the following 
scenarios,

- When end device is added in the topology,
- When the end device is removed from the setup,
- When the SCSI mid layer issues TASK ABORT/ DEVICE RESET/ TARGET RESET during 
error handling,
- When any command to the device fails with Sense key Hardware error or Medium 
error or Unit Attention,
- When firmware returns device error or device not ready status for the end 
device,
- When a Predicted fault is detected on an end device.

This information can be used by the user to identify the location of the 
desired drive in the topology.

Driver will get these information by reading the sas device page0.

Changes in v2:
 Fixed the undefined scsih_scsi_ioc_info() function compilation errors 
which we observe 
only if CONFIG_SCSI_MPT3SAS_LOGGING flag is disabled.

Signed-off-by: Sreekanth Reddy 
Reviewed-by: Martin K. Petersen 
Reviewed-by: Johannes Thumshirn 
---
 drivers/scsi/mpt3sas/mpt3sas_base.h  |   2 +
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 240 +--
 2 files changed, 203 insertions(+), 39 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 01d92db..da82a97 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -324,6 +324,8 @@ struct _sas_device {
u8  fast_path;
u8  pfa_led_on;
u8  pend_sas_rphy_add;
+   u8  enclosure_level;
+   u8  connector_name[4];
 };
 
 /**
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index d457dba..ec3b3d3 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -585,6 +585,22 @@ _scsih_sas_device_remove(struct MPT3SAS_ADAPTER *ioc,
 
if (!sas_device)
return;
+   pr_info(MPT3SAS_FMT
+   "removing handle(0x%04x), sas_addr(0x%016llx)\n",
+   ioc->name, sas_device->handle,
+   (unsigned long long) sas_device->sas_address);
+
+   if (sas_device->enclosure_handle != 0)
+   pr_info(MPT3SAS_FMT
+  "removing enclosure logical id(0x%016llx), slot(%d)\n",
+  ioc->name, (unsigned long long)
+  sas_device->enclosure_logical_id, sas_device->slot);
+
+   if (sas_device->connector_name[0] != '\0')
+   pr_info(MPT3SAS_FMT
+  "removing enclosure level(0x%04x), connector name( %s)\n",
+  ioc->name, sas_device->enclosure_level,
+  sas_device->connector_name);
 
spin_lock_irqsave(&ioc->sas_device_lock, flags);
list_del(&sas_device->list);
@@ -663,6 +679,18 @@ _scsih_sas_device_add(struct MPT3SAS_ADAPTER *ioc,
ioc->name, __func__, sas_device->handle,
(unsigned long long)sas_device->sas_address));
 
+   if (sas_device->enclosure_handle != 0)
+   dewtprintk(ioc, pr_info(MPT3SAS_FMT
+   "%s: enclosure logical id(0x%016llx), slot( %d)\n",
+   ioc->name, __func__, (unsigned long long)
+   sas_device->enclosure_logical_id, sas_device->slot));
+
+   if (sas_device->connector_name[0] != '\0')
+   dewtprintk(ioc, pr_info(MPT3SAS_FMT
+   "%s: enclosure level(0x%04x), connector name( %s)\n",
+   ioc->name, __func__,
+   sas_device->enclosure_level, sas_device->connector_name));
+
spin_lock_irqsave(&ioc->sas_device_lock, flags);
list_add_tail(&sas_device->list, &ioc->sas_device_list);
spin_unlock_irqrestore(&ioc->sas_device_lock, flags);
@@ -704,6 +732,18 @@ _scsih_sas_device_init_add(struct MPT3SAS_ADAPTER *ioc,
__func__, sas_device->handle,
(unsigned long long)sas_device->sas_address));
 
+   if (sas_device->enclosure_handle != 0)
+   dewtprintk(ioc, pr_info(MPT3SAS_FMT
+   "%s: enclosure logical id(0x%016llx), slot( %d)\n",
+   ioc->name, __func__, (unsigned long long)
+   sas_device->enclosure_logical_id, sas_device->slot));
+
+   if (sas_device->connector_name[0] != '\0')
+   dewtprintk(ioc, pr_info(MPT3SAS_FMT
+   "%s: enclosure level(0x%04x), connector name( %s)\n",
+   ioc->name, __func__, sas_device->enclosure_level,
+   sas_device->connector_name));
+
spin_lock_irqsave(&ioc->sas_device_lock, flags);
list_add_tail(&sas_device->list, &ioc->sas_device_init_list);
_scsih_determine_boot_device(ioc, sas_device, 0);
@@ -1772,10 +1812,16 @@ _scsih_slave_configure(struct scsi_device *sdev)
"sas_addr(0x%016llx), phy(%d), device_name(0x%016llx)\n",
ds, handle, (unsigned long long)sas_device->sas_address,
sas_d

[PATCH v2 04/20] [SCSI] mpt3sas: Remove redundancy code while freeing the controller resources.

[Sreekanth Reddy]

Removed the redundancy code while freeing the controller resources.

Changes in v2:
Patch version change only.

Signed-off-by: Sreekanth Reddy 
Reviewed-by: Martin K. Petersen 
Reviewed-by: Johannes Thumshirn 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 57 +
 1 file changed, 32 insertions(+), 25 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 0410cc5..bf2d7dc 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1813,6 +1813,36 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
 }
 
 /**
+ * mpt3sas_base_unmap_resources - free controller resources
+ * @ioc: per adapter object
+ */
+void
+mpt3sas_base_unmap_resources(struct MPT3SAS_ADAPTER *ioc)
+{
+   struct pci_dev *pdev = ioc->pdev;
+
+   dexitprintk(ioc, printk(MPT3SAS_FMT "%s\n",
+   ioc->name, __func__));
+
+   _base_free_irq(ioc);
+   _base_disable_msix(ioc);
+
+   if (ioc->msix96_vector)
+   kfree(ioc->replyPostRegisterIndex);
+
+   if (ioc->chip_phys) {
+   iounmap(ioc->chip);
+   ioc->chip_phys = 0;
+   }
+
+   if (pci_is_enabled(pdev)) {
+   pci_release_selected_regions(ioc->pdev, ioc->bars);
+   pci_disable_pcie_error_reporting(pdev);
+   pci_disable_device(pdev);
+   }
+}
+
+/**
  * mpt3sas_base_map_resources - map in controller resources (io/irq/memap)
  * @ioc: per adapter object
  *
@@ -1945,14 +1975,7 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
return 0;
 
  out_fail:
-   if (ioc->chip_phys)
-   iounmap(ioc->chip);
-   ioc->chip_phys = 0;
-   pci_release_selected_regions(ioc->pdev, ioc->bars);
-   pci_disable_pcie_error_reporting(pdev);
-   pci_disable_device(pdev);
-   if (ioc->msix96_vector)
-   kfree(ioc->replyPostRegisterIndex);
+   mpt3sas_base_unmap_resources(ioc);
return r;
 }
 
@@ -4689,8 +4712,6 @@ _base_make_ioc_operational(struct MPT3SAS_ADAPTER *ioc, 
int sleep_flag)
 void
 mpt3sas_base_free_resources(struct MPT3SAS_ADAPTER *ioc)
 {
-   struct pci_dev *pdev = ioc->pdev;
-
dexitprintk(ioc, pr_info(MPT3SAS_FMT "%s\n", ioc->name,
__func__));
 
@@ -4701,21 +4722,7 @@ mpt3sas_base_free_resources(struct MPT3SAS_ADAPTER *ioc)
ioc->shost_recovery = 0;
}
 
-   _base_free_irq(ioc);
-   _base_disable_msix(ioc);
-
-   if (ioc->msix96_vector)
-   kfree(ioc->replyPostRegisterIndex);
-
-   if (ioc->chip_phys && ioc->chip)
-   iounmap(ioc->chip);
-   ioc->chip_phys = 0;
-
-   if (pci_is_enabled(pdev)) {
-   pci_release_selected_regions(ioc->pdev, ioc->bars);
-   pci_disable_pcie_error_reporting(pdev);
-   pci_disable_device(pdev);
-   }
+   mpt3sas_base_unmap_resources(ioc);
return;
 }
 
-- 
2.0.2

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

[PATCH v2 2/2] ARM: dts: mediatek: add 6580 support

[Mars Cheng]

This adds basic chip support for Mediatek 6580.

Change-Id: Ic5c93eb5d1e6e23503dabd28d41c30a7f02e9c18
Signed-off-by: Mars Cheng 
---
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/mt6580-evbp1.dts |  35 +++
 arch/arm/boot/dts/mt6580.dtsi  | 125 +
 3 files changed, 161 insertions(+)
 create mode 100644 arch/arm/boot/dts/mt6580-evbp1.dts
 create mode 100644 arch/arm/boot/dts/mt6580.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 86217db..9298531 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -656,6 +656,7 @@ dtb-$(CONFIG_MACH_DOVE) += \
dove-d3plug.dtb \
dove-dove-db.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += \
+   mt6580-evbp1.dtb \
mt6589-aquaris5.dtb \
mt6592-evb.dtb \
mt8127-moose.dtb \
diff --git a/arch/arm/boot/dts/mt6580-evbp1.dts 
b/arch/arm/boot/dts/mt6580-evbp1.dts
new file mode 100644
index 000..8c42335
--- /dev/null
+++ b/arch/arm/boot/dts/mt6580-evbp1.dts
@@ -0,0 +1,35 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Mars.C 
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include "mt6580.dtsi"
+
+/ {
+   model = "MediaTek MT6580 evaluation board";
+   compatible = "mediatek,mt6580-evbp1", "mediatek,mt6580";
+
+   chosen {
+   bootargs = "console=ttyS0,921600n8 earlyprintk";
+   stdout-path = &uart0;
+   };
+
+   memory {
+   reg = <0x8000 0x2000>;
+   };
+};
+
+&uart0 {
+   status = "okay";
+};
+
diff --git a/arch/arm/boot/dts/mt6580.dtsi b/arch/arm/boot/dts/mt6580.dtsi
new file mode 100644
index 000..ac97d64
--- /dev/null
+++ b/arch/arm/boot/dts/mt6580.dtsi
@@ -0,0 +1,125 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Mars.C 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include "skeleton.dtsi"
+
+/ {
+   compatible = "mediatek,mt6580";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   interrupt-parent = <&sysirq>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x0>;
+   };
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x1>;
+   };
+   cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x2>;
+   };
+   cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x3>;
+   };
+
+   };
+
+   clocks {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   ranges;
+
+   system_clk: dummy13m {
+   compatible = "fixed-clock";
+   clock-frequency = <1300>;
+   #clock-cells = <0>;
+   };
+
+   rtc_clk: dummy32k {
+   compatible = "fixed-clock";
+   clock-frequency = <32000>;
+   #clock-cells = <0>;
+   };
+
+   uart_clk: dummy26m {
+   compatible = "fixed-clock";
+   clock-frequency = <2600>;
+   #clock-cells = <0>;
+   };
+   };
+
+   timer: timer@10008000 {
+   compatible = "mediatek,mt6580-timer",
+"mediatek,mt6577-timer";
+   reg = <0x10008000 0x80>;
+   interrupts = ;
+   clocks = <&system_clk>, <&rtc_clk>;
+   clock-names = "system-clk", "rtc-clk";
+   };
+
+   sysirq: interrupt-controller@10200100 {
+   compatible = "mediatek,mt6580-sysirq",
+"mediatek,mt6577-sysirq";
+ 

Re: [PATCH] dmaengine: pl330: Really fix choppy sound because of wrong residue calculation

[Lars-Peter Clausen]

On 06/30/2015 06:51 AM, Krzysztof Kozłowski wrote:

2015-06-30 13:14 GMT+09:00 Vinod Koul :

On Mon, Jun 22, 2015 at 11:14:42AM +0900, Krzysztof Kozłowski wrote:

2015-06-15 23:00 GMT+09:00 Krzysztof Kozlowski :

When pl330 driver was used during sound playback, after some time or
after a number of plays the sound became choppy or totally noisy. For
example on Odroid XU3 board the first four executions of aplay with
small WAVE worked fine, but fifth was unrecognizable with errors:
 $ aplay /usr/share/sounds/alsa/Front_Right.wava
 underrun!!! (at least 0.095 ms long)

Issue was caused by wrong residue reported by pl330 driver to
pcm_dmaengine for its cyclic dma transfers.

The pl330_tx_status(), residue reporting function, used a "last" flag in
a descriptor to indicate that there is no more data to send.

The pl330_tx_submit() iterated over descriptors trying to remove this
flag from them and then mark last descriptor as "last".  However when
iterating it actually removed the flag not from descriptors but always
from last of it (and then reset it). Thus effectively once some
descriptor was marked as last, then it stayed like this forever causing
residue to be reported too low.

Signed-off-by: Krzysztof Kozlowski 
Fixes: aee4d1fac887 ("dmaengine: pl330: improve pl330_tx_status() function")
Cc: 
Reported-by: gabr...@unseen.is
Suggested-by: Marek Szyprowski 


Gabriel, could you give this patch a try? It helped for my Odroid XU3,
which has the same audio codec. Nevertheless it would be great to hear
that it solves the initial bug report.


So is there a word on  what finally fixes this


This fixes sound issue on my Odroid XU3 board, which is good. My board
has the same audio codec and DMA driver as the board used by Gabriel
so there is high chance that his issue is also fixed.

However it is sad that I did not receive any reviews or tests from
anyone, apparently no one cares enough about it :) .


I care, I've had it in applied to my local tree for a while now. Without it 
audio does not work.


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

Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation

[Daniel Vetter]

Any updates on this or too much distractions? I really think doing
this would be awesome for the drm subsystem, instead of reinventing
this wheel for each driver.
-Daniel

On Wed, Mar 25, 2015 at 10:21 AM, Daniel Vetter  wrote:
> On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote:
>> Hi,
>>
>> On 03/13/2015 02:36 PM, Daniel Vetter wrote:
>> >On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:
>> >>
>> >>
>> >>On 03/11/2015 08:47 PM, Daniel Vetter wrote:
>> >>>On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
>> 
>> 
>> On 03/10/2015 05:47 PM, Daniel Vetter wrote:
>> >On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
>> >>On 03/10/2015 03:35 PM, Daniel Vetter wrote:
>> >>>On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
>> On 03/10/2015 03:17 PM, Daniel Vetter wrote:
>> >On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
>> >>diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> >>index 151a050..38f83a0 100644
>> >>--- a/drivers/gpu/drm/Kconfig
>> >>+++ b/drivers/gpu/drm/Kconfig
>> >>@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
>> >>help
>> >>  FBDEV helpers for KMS drivers.
>> >>
>> >>+config DRM_FBDEV_EMULATION
>> >>+   bool "Enable legacy fbdev support for your modesetting driver"
>> >>+   depends on DRM
>> >>+   select DRM_KMS_HELPER
>> >>+   select DRM_KMS_FB_HELPER
>> >>+   select FB_SYS_FILLRECT
>> >>+   select FB_SYS_COPYAREA
>> >>+   select FB_SYS_IMAGEBLIT
>> >>+   select FB_SYS_FOPS
>> >>+   select FB_CFB_FILLRECT
>> >>+   select FB_CFB_COPYAREA
>> >>+   select FB_CFB_IMAGEBLIT
>> >>+   default y
>> >>+   help
>> >>+ Choose this option if you have a need for the legacy fbdev
>> >>+ support. Note that this support also provide the linux 
>> >>console
>> >>+ support on top of your modesetting driver.
>> >
>> >Maybe clarify that for linux console support you also need
>> >CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.
>> 
>> DRM_KMS_FB_HELPER selects that for us, right?
>> >>>
>> >>>Hm right I've missed that. Reminds me that you need one more patch at 
>> >>>the
>> >>>end to remove all the various select DRM_KMS_FB_HELPER from all drm
>> >>>drivers. Otherwise this knob here won't work by default if you e.g. 
>> >>>select
>> >>>radeon. In general we can't mix explicit options with menu entries 
>> >>>with a
>> >>>select.
>> >>
>> >>I was trying that out. Removing DRM_KMS_FB_HELPER and having
>> >>DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff 
>> >>internally in
>> >>their respective xyz_fbdev.c files.
>> >
>> >But with the stubbed out functions that should work, right? Why doesn't
>> >it?
>> 
>> There are still calls to functions from fb core like fb_set_suspend and
>> register_framebuffer which aren't covered by the drm fb helper functions.
>> >>>
>> >>>Hm, sounds like we need another patch to stub out fb_set_suspend when
>> >>>fbdev isn't enabled. Is there anything else?
>> >>
>> >>There are a handful of fb core functions which are called by drm drivers:
>> >>
>> >>fb_alloc_cmap/fb_dealloc_cmap
>> >>
>> >>fb_sys_read/fb_sys_write
>> >>
>> >>register_framebuffer/unregister_framebuffer/unlink_framebuffer/
>> >>remove_conflicting_framebuffers
>> >>
>> >>fb_set_suspend
>> >>
>> >>fb_deferred_io_init/fb_deferred_io_cleanup
>> >>
>> >>framebuffer_alloc/framebuffer_release
>> >
>> >Hm yeah that's somewhat annoying indeed. What about the following:
>> >1. We move all the #include  from drivers into drm_fb_helper.h
>> >
>> >2. Then we add stubs for these functions in drm_fb_helper.h, like this
>> >
>> >#if defined(CONFIG_FB)
>> >#include 
>> >#else
>> >
>> >/* static inline stubs for all the fb stuff used by kms drivers */
>> >#endif
>> >
>> >Imo this makes sense since kms drivers really have a bit a special
>> >situation with fbdev. They're not full-blown fbdev drivers and can be
>> >useful fully without fbdev.
>> >
>>
>> I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs
>> won't really work because struct declarations(like fb_info) also get
>> removed.
>>
>> I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h itself,
>> but that seemed a bit too intrusive.
>>
>> This is what I'm currently doing:
>>
>> - Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap would
>> actually benefit if we have drm fb helpers for them. They are used in
>> exactly the same manner by all the drivers.
>>
>> - For the rest of the functions that are sparsely used, I was considering
>> making very simple drm_fb_* wrapper functions. Something like:
>>
>> void drm_fb_helper_deferred_io_init(str

Re: [PATCH v2] watchdog: omap_wdt: early_enable module parameter

[Wim Van Sebroeck]

Hi Paul,

> On Thu, Jun 25, 2015 at 9:46 AM, Guenter Roeck  wrote:
> > On 06/25/2015 03:21 AM, poesc...@lemonage.de wrote:
> >>
> >> From: Lars Poeschel 
> >>
> >> Add a early_enable module parameter to the omap_wdt that starts the
> >> watchdog on module insertion. The default value is 0 which does not
> >> start the watchdog - which also does not change the behavior if the
> >> parameter is not given.
> >>
> >> Signed-off-by: Lars Poeschel 
> >
> >
> > Reviewed-by: Guenter Roeck 
> 
> In case the info hasn't looped back around yet, this breaks the
> omap builds in linux-next:
> 
> drivers/watchdog/omap_wdt.c:288:18: error: 'omap_wdt' undeclared
> (first use in this function)
> 
> (Not sure how this could have ever worked as-is.)
> 
> http://kisskb.ellerman.id.au/kisskb/buildresult/12452335/
> 
> I see a patch has already been posted to arm-kernel but not
> Cc'd to all originally involved so figured I'd mention it.

It's fixed. The reason why we din't catch it was because of interference
with 'watchdog: omap: put struct watchdog_device into driver data'.

Kind regards,
Wim.

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

[GIT PULL] Delete new __cpuinit users and then delete stubs

[Paul Gortmaker]

We removed the __cpuinit stuff in 3.11-rc1 with commit 
22f0a27367742f65130c0fb25ef00f7297e032c1 ("init.h: remove __cpuinit
sections from the kernel") but we left some no-op stubs as
a courtesy to unmerged code.

Here we get rid of the stubs as well, since (as can be seen in these
changes) they are enabling use cases to sneak back in, primarily from
older BSP code that has been living out of tree for some time prior
to getting mainlined.  So we get rid of these "new" users 1st and
then get rid of the stubs.

Obviously, getting rid of the stubs can't happen until all the users
are gone, so I had to keep this together as a series, even though some
of these commits since got picked up into maintainers trees as well.

The nature of this change is such that it should have zero impact on
the generated runtime.

This is one of several independent cleanup branches aimed at
enabling better organization in the init.h and module.h code.  They
have been getting coverage in the linux-next tree for the last month,
in addition to my local testing, which also covers approximately a
half dozen or more architectures.

Original posting:
  "Delete new __cpuinit users and then delete stubs"
  
https://lkml.kernel.org/r/1430174880-27958-1-git-send-email-paul.gortma...@windriver.com

Thanks,
Paul.
---

The following changes since commit 0f57d86787d8b1076ea8f9cba2a46d534a27:

  Linux 4.1-rc8 (2015-06-14 15:51:10 -1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git 
tags/cpuinit-v4.1-rc8

for you to fetch changes up to 22c1587adfed1977d26a57ac2831d03e37f8f805:

  init: delete the __cpuinit related stubs (2015-06-16 14:12:23 -0400)


Remove __cpuinit macros and users.


Paul Gortmaker (11):
  arm/mach-keystone: remove legacy __cpuinit sections that crept in
  arm/mach-mvebu: remove legacy __cpuinit sections that crept in
  arm/mach-rockchip: remove legacy __cpuinit section that crept in
  arm/mach-hisi: remove legacy __CPUINIT section that crept in
  mips/ath25: remove legacy __cpuinit section that crept in
  mips/bcm77xx: remove legacy __cpuinit sections that crept in
  mips/c-r4k: remove legacy __cpuinit section that crept in
  mips/mm/tlbex: remove new instance of __cpuinit that crept back in
  sched/core: remove __cpuinit section tag that crept back in.
  kernel/cpu.c: remove new instance of __cpuinit that crept back in
  init: delete the __cpuinit related stubs

 arch/arm/mach-hisi/headsmp.S   |  3 ---
 arch/arm/mach-keystone/platsmp.c   |  4 ++--
 arch/arm/mach-mvebu/headsmp-a9.S   |  3 ---
 arch/arm/mach-mvebu/platsmp-a9.c   |  2 +-
 arch/arm/mach-rockchip/platsmp.c   |  3 +--
 arch/mips/ath25/board.c|  2 +-
 arch/mips/bcm47xx/prom.c   |  2 +-
 arch/mips/include/asm/pgtable-32.h |  2 +-
 arch/mips/mm/c-r4k.c   |  2 +-
 arch/mips/mm/tlb-r4k.c |  2 +-
 arch/mips/mm/tlbex.c   |  2 +-
 include/linux/init.h   | 11 ---
 kernel/cpu.c   |  2 +-
 kernel/sched/core.c|  2 +-
 scripts/tags.sh|  2 +-
 15 files changed, 13 insertions(+), 31 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: cleaning per architecture MM hook header files

[Vineet Gupta]

On Monday 29 June 2015 07:55 PM, Laurent Dufour wrote:
> The commit 2ae416b142b6 ("mm: new mm hook framework") introduced an empty
> header file (mm-arch-hooks.h) for every architecture, even those which
> doesn't need to define mm hooks.
> 
> As suggested by Geert Uytterhoeven, this could be cleaned through the use
> of a generic header file included via each per architecture
> asm/include/Kbuild file.
> 
> The powerpc architecture is not impacted here since this architecture has
> to defined the arch_remap MM hook.
> 
> Signed-off-by: Laurent Dufour 
> Suggested-by: Geert Uytterhoeven 
> CC: Andrew Morton 
> CC: linux-a...@vger.kernel.org
> CC: linux...@kvack.org
> CC: linux-kernel@vger.kernel.org
> ---

snipped

> diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild
> index 769b312c1abb..2febe6ff32ed 100644
> --- a/arch/arc/include/asm/Kbuild
> +++ b/arch/arc/include/asm/Kbuild
> @@ -49,3 +49,4 @@ generic-y += ucontext.h
>  generic-y += user.h
>  generic-y += vga.h
>  generic-y += xor.h
> +generic-y += mm-arch-hooks.h
> diff --git a/arch/arc/include/asm/mm-arch-hooks.h 
> b/arch/arc/include/asm/mm-arch-hooks.h
> deleted file mode 100644
> index c37541c5f8ba..
> --- a/arch/arc/include/asm/mm-arch-hooks.h
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -/*
> - * Architecture specific mm hooks
> - *
> - * Copyright (C) 2015, IBM Corporation
> - * Author: Laurent Dufour 
> - *
> - * 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.
> - */
> -
> -#ifndef _ASM_ARC_MM_ARCH_HOOKS_H
> -#define _ASM_ARC_MM_ARCH_HOOKS_H
> -
> -#endif /* _ASM_ARC_MM_ARCH_HOOKS_H */
> diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild
> index 83c50193626c..870a2f7cbada 100644
> --- a/arch/arm/include/asm/Kbuild
> +++ b/arch/arm/include/asm/Kbuild
> @@ -36,3 +36,4 @@ generic-y += termios.h
>  generic-y += timex.h
>  generic-y += trace_clock.h
>  generic-y += unaligned.h
> +generic-y += mm-arch-hooks.h

We keep this file sorted by headers so please can u respin with right ordering !

Thx,
-Vineet

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

[GIT PULL] Fix implicit users that will break later.

[Paul Gortmaker]

The files changed here are simply modular source files that are implicitly
relying on  being present.  We fix them up now, so that we can
decouple some of the module related init code from the core init code in
the future.

The addition of the module.h include to several files here is also a
no-op from a code generation point of view, else there would already be
compile issues with these files today.

There may be lots more implicit includes of  in tree, but
these are the ones that extensive build test coverage has shown that
must be fixed in order to avoid build breakage fallout for the
pending module.h <---> init.h code relocation we desire to complete.

Original posting:
  "Fix implicit includes of  that will break."
  
https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortma...@windriver.com

Thanks,
Paul.
---

The following changes since commit 0f57d86787d8b1076ea8f9cba2a46d534a27:

  Linux 4.1-rc8 (2015-06-14 15:51:10 -1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git 
tags/module-implicit-v4.1-rc8

for you to fetch changes up to 7cac34370a4dde12e6430c2f0985926d4ef0f459:

  frv: add module.h to mb93090-mb00/flash.c to avoid compile fail (2015-06-16 
14:12:26 -0400)


Fix up implicit  users that will break later.


Paul Gortmaker (11):
  drivers/clk: include  for clk-max77xxx modular code
  drivers/gpio: include  for modular crystalcove code
  drivers/gpu: include  for modular rockchip code
  drivers/hsi: include  for modular omap_ssi code
  drivers/pcmcia: include  for modular xxs1500_ss code
  drivers/regulator: include  for modular max77802 code
  sh: mach-highlander/psw.c is tristate and should use module.h
  crypto/asymmetric_keys: pkcs7_key_type needs module.h
  drivers/staging: include  for modular android tegra_ion code
  drivers/cpufreq: include  for modular exynos-cpufreq.c code
  frv: add module.h to mb93090-mb00/flash.c to avoid compile fail

 arch/frv/mb93090-mb00/flash.c | 2 +-
 arch/sh/boards/mach-highlander/psw.c  | 2 +-
 crypto/asymmetric_keys/pkcs7_key_type.c   | 1 +
 drivers/clk/clk-max77686.c| 1 +
 drivers/clk/clk-max77802.c| 1 +
 drivers/cpufreq/exynos-cpufreq.c  | 1 +
 drivers/gpio/gpio-crystalcove.c   | 1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   | 1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 1 +
 drivers/hsi/controllers/omap_ssi.h| 1 +
 drivers/pcmcia/xxs1500_ss.c   | 1 +
 drivers/regulator/max77802.c  | 1 +
 drivers/staging/android/ion/tegra/tegra_ion.c | 1 +
 13 files changed, 13 insertions(+), 2 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 11/19] staging: sm750fb: consistent spacing around operators

[Sudip Mukherjee]

On Thu, Jun 25, 2015 at 10:53:33PM -0700, Juston Li wrote:
> On Thu, Jun 25, 2015 at 9:05 PM, Sudip Mukherjee
>  wrote:
> > Usually I use the checkpatch which is in linux-next. That will be the
> > latest version. If you compare, last commit on checkpatch of staging
> > tree was on April 16th, where as last commit in linux-next is on
> > June 19th. And if you use this checkpatch you will see these warnings
> > also. :)
> 
> Just wanted to clarify. So even with the linux-next checkpatch.pl, no
> errors/warnings show for me. Only when I run checkpatch.pl with the
> '--strict' option does it give the following checks for various operators:
> CHECK: space preferred before that '|' (ctx:VxE)
> 
> Are these the warnings you are referring too? Do you want me to fix all
> of these for this patch?
Hi,
Sorry for the late reply, was a bit busy.
since your commit message was saying "spacing around operators"
and you were fixing the spacing around all types of operators so there
is no point leaving few not fixed on the same line.
But anyways, since you have already sent new series, its ok.

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

Re: drm/mgag200: doesn't work in panic context

[Rui Wang]

On Tuesday, June 30, 2015 2:37 PM, Daniel Vetter  wrote:
> On Tue, Jun 30, 2015 at 4:53 AM, Rui Wang  wrote:
> >
> > I think testing can be done by injecting a fatal machine check
> > exception via einj's debugfs interface. I can reproduce the hard hang every
> time.
> > I think It can be a simple script or C program do to the automated testing.
> > If anyone has any patch I'll be happy to help test it out.
> 
> Testing shouldn't kill the machine ;-)

Yes :) What I assumed was that after applying a future patch the machine should
be able to reboot instead of hanging itself, so the testing can repeat.

> 
> The idea I had is to just exercise the drm panic code (since we'd need to
> shunt everything else), and that can be done my calling the relevant
> functions from a hardirq context. And hardirq context is simples to get with a
> IPI to the local cpu. This way we don't depend upon the entire panic path to
> be recoverable, but only upon the drm bits being sane.

Yes If it can be tested without rebooting then it'll be more efficient.
But einj does something more than what an IPI can do, it injects hardware
errors which trigger exceptions in NMI context... and the exception handler 
usually panics on fatal errors. And the display may be the only way to catch
what has happened. I'm just hoping that the future version may work in NMI
context.

Thanks
Rui

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

Re: [PATCH] HID:multitouch:add driver fo CJTouch MultiTouch

[Jiri Kosina]

On Mon, 29 Jun 2015, linux...@163.com wrote:

> From: linuxsea 
> 
> Signed-off-by:linuxsea

Please use your real name for authorship and signoffs. Thanks,

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

Re: [PATCH 07/10] Staging: fbtft: Remove useless newline

[Dan Carpenter]

On Tue, Jun 30, 2015 at 08:43:14AM +0200, Fabio Falzoi wrote:
> No newline is needed since checkpatch doesn't complain about line longer
> than 80 characters for string literals.
> 
> Signed-off-by: Fabio Falzoi 

The original was correct.  There was no need to go over 80 characters
just because of a limitation in checkpatch.

regards,
dan carpenter

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

Re: Use of pinctrl-single for external device over I2C

[Vaibhav Hiremath]

On Thursday 25 June 2015 11:16 AM, Vaibhav Hiremath wrote:



On Thursday 25 June 2015 10:08 AM, Tony Lindgren wrote:

* Vaibhav Hiremath  [150624 10:12]:


I do not like this, as this is not HW feature, so DT may not be right
approach.

So I will dig more from either runtime or Compile time option to use
regmap_ Vs raw read/writes.


Can't you just check if the pinctrl node has compatible = "syscon"
property?

A compile time option won't work for sure. I don't know what you
would check at runtime as you do not know what the bus is behind
syscon.



Although, I haven't gone through syscon, but not sure whether syscon
would be useful.

As you rightly stated, we need to know the bus behind regmap.



Trying to understand what is the right way of doing pinctrl of external
device on board,

I feel it would not be good idea to pollute pinctrl-single driver, and 
also I am still not able to figure out how can I have access to bus

behind regmap.


How about having separate driver (generic for all I2C), say pinctrl-
i2c.c, which is i2c_client driver and would support pinctrl and pinmux
on I2C client device.


The current usecase which I have is pretty simple in nature,

88PM860 has few GPIO pins which can be configured to different
functionality, based on board design.
In most of the cases they are one/init/boot time settings.

GPIO_0:
===
  000 = GPIO input mode
  001 = GPIO output mode
  010 = SLEEPOUTN mirror mode
  011 = Buck4 FPWM enable
  100 = 32 Khz output buffer mode
  101 = PMICINTN output mode
  110 = HW_RESET1 mode
  111 = HW_RESET2 mode


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

Re: [tip:timers/core] clocksource: Increase dependencies of timer-stm32 to limit build wreckage

[Maxime Coquelin]

2015-06-29 11:09 GMT+02:00 Daniel Lezcano :
> On 06/22/2015 10:05 AM, Maxime Coquelin wrote:
>
> [ ... ]
>
>>> ---
>>>   drivers/clocksource/Kconfig | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>
>> Thanks Paul for the patch.
>> Actually, I already had sent a patch to fix this dependency issue [0].
>> I thought Daniel had pick it, but don't find it in his tree.
>> My patch adds a build dependency on GENERIC_CLOCKEVENTS, which I think
>> is the best way to fix the problem.
>
>
> Yes, I have it in my tree but I was expecting some more fixes to pick up in
> order to send a PR to Thomas.
>
> Is it possible you send your a fix on top of this patch ? So I can drop your
> initial patch.
>

Sure. I will rebase my patch on top of Paul's one.

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

[GIT PULL] Replace module_init with device_initcall in non modules

[Paul Gortmaker]

This series of commits converts non-modular code that is using
the module_init() call to hook itself into the system to instead
use device_initcall().

The conversion is a runtime no-op, since module_init actually
becomes __initcall in the non-modular case, and that in turn gets
mapped onto device_initcall.  A couple files show a larger negative
diffstat, representing ones that had a module_exit function that we
remove here vs. previously relying on the linker to dispose of it.

We make this conversion now, so that we can relocate module_init
from init.h into module.h in the future.

The files changed here are just limited to those that would
otherwise have to add module.h to obviously non-modular code, in
order to avoid a compile fail, as testing has shown.

Original posting:
  "Replace module_init with device_initcall in non modules"
  
https://lkml.kernel.org/r/1432860493-23831-1-git-send-email-paul.gortma...@windriver.com

Thanks,
Paul.
---

The following changes since commit 0f57d86787d8b1076ea8f9cba2a46d534a27:

  Linux 4.1-rc8 (2015-06-14 15:51:10 -1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git 
tags/module_init-device_initcall-v4.1-rc8

for you to fetch changes up to b0c6d93014c8f2f53b70e9362b9fbec13b8e3aa0:

  MIPS: don't use module_init in non-modular cobalt/mtd.c file (2015-06-16 
14:34:36 -0400)


Replace module_init with equivalent device_initcall in non modules.


James Hogan (1):
  tty/metag_da: Avoid module_init/module_exit in non-modular code

Paul Gortmaker (17):
  x86: don't use module_init in non-modular intel_mid_vrtc.c
  x86: don't use module_init in non-modular devicetree.c code
  powerpc: use device_initcall for registering rtc devices
  powerpc: don't use module_init in non-modular 83xx suspend code
  arm: don't use module_init in non-modular mach-vexpress/spc.c code
  ia64: don't use module_init for non-modular core kernel/mca.c code
  ia64: don't use module_init in non-modular sim/simscsi.c code
  cris: don't use module_init for non-modular core intmem.c code
  parisc: don't use module_init for non-modular core pdc_cons code
  parisc64: don't use module_init for non-modular core perf code
  mn10300: don't use module_init in non-modular flash.c code
  sh: don't use module_init in non-modular psw.c code
  xtensa: don't use module_init for non-modular core network.c code
  drivers/clk: don't use module_init in clk-nomadik.c which is non-modular
  cris: don't use module_init for non-modular core eeprom.c code
  drivers/leds: don't use module_init in non-modular leds-cobalt-raq.c
  MIPS: don't use module_init in non-modular cobalt/mtd.c file

 arch/arm/mach-vexpress/spc.c |  2 +-
 arch/cris/arch-v10/drivers/eeprom.c  |  3 +--
 arch/cris/arch-v32/mm/intmem.c   |  3 +--
 arch/ia64/hp/sim/simscsi.c   | 11 +--
 arch/ia64/sn/kernel/mca.c|  3 +--
 arch/mips/cobalt/mtd.c   |  3 +--
 arch/mn10300/unit-asb2303/flash.c|  3 +--
 arch/parisc/kernel/pdc_cons.c|  3 +--
 arch/parisc/kernel/perf.c|  3 +--
 arch/powerpc/kernel/time.c   |  2 +-
 arch/powerpc/platforms/83xx/suspend.c|  3 +--
 arch/powerpc/platforms/ps3/time.c|  3 +--
 arch/sh/boards/mach-landisk/psw.c|  2 +-
 arch/x86/kernel/devicetree.c |  2 +-
 arch/x86/platform/intel-mid/intel_mid_vrtc.c |  3 +--
 arch/xtensa/platforms/iss/network.c  |  4 +---
 drivers/clk/clk-nomadik.c|  3 +--
 drivers/leds/leds-cobalt-raq.c   | 15 +--
 drivers/tty/metag_da.c   | 20 +---
 19 files changed, 19 insertions(+), 72 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v2 PATCH 2/8] mm: introduce MIGRATE_MIRROR to manage the mirrored pages

[Kamezawa Hiroyuki]

On 2015/06/30 11:45, Xishi Qiu wrote:

On 2015/6/29 15:32, Kamezawa Hiroyuki wrote:


On 2015/06/27 11:24, Xishi Qiu wrote:

This patch introduces a new migratetype called "MIGRATE_MIRROR", it is used to
allocate mirrored pages.
When cat /proc/pagetypeinfo, you can see the count of free mirrored blocks.

Signed-off-by: Xishi Qiu 


My fear about this approarch is that this may break something existing.

Now, when we add MIGRATE_MIRROR type, we'll hide attributes of pageblocks as
MIGRATE_UNMOVABOLE, MIGRATE_RECLAIMABLE, MIGRATE_MOVABLE.

Logically, MIRROR attribute is independent from page mobility and this 
overwrites
will make some information lost.

Then,


---
   include/linux/mmzone.h | 9 +
   mm/page_alloc.c| 3 +++
   mm/vmstat.c| 3 +++
   3 files changed, 15 insertions(+)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 54d74f6..54e891a 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -39,6 +39,9 @@ enum {
   MIGRATE_UNMOVABLE,
   MIGRATE_RECLAIMABLE,
   MIGRATE_MOVABLE,
+#ifdef CONFIG_MEMORY_MIRROR
+MIGRATE_MIRROR,
+#endif


I think
 MIGRATE_MIRROR_UNMOVABLE,
 MIGRATE_MIRROR_RECLAIMABLE,
 MIGRATE_MIRROR_MOVABLE, <== adding this may need discuss.
 MIGRATE_MIRROR_RESERVED,<== reserved pages should be 
maintained per mirrored/unmirrored.



Hi Kame,

You mean add 3 or 4 new migratetype?



yes. But please check how NR_MIGRATETYPE_BITS will be.
I think this will not have big impact in x86-64 .


should be added with the following fallback list.

/*
  * MIRROR page range is defined by firmware at boot. The range is limited
  * and is used only for kernel memory mirroring.
  */
[MIGRATE_UNMOVABLE_MIRROR]   = {MIGRATE_RECLAIMABLE_MIRROR, MIGRATE_RESERVE}
[MIGRATE_RECLAIMABLE_MIRROR] = {MIGRATE_UNMOVABLE_MIRROR, MIGRATE_RESERVE}



Why not like this:
{MIGRATE_RECLAIMABLE_MIRROR, MIGRATE_MIRROR_RESERVED, MIGRATE_RESERVE}



 My mistake.
[MIGRATE_UNMOVABLE_MIRROR]   = {MIGRATE_RECLAIMABLE_MIRROR, 
MIGRATE_RESERVE_MIRROR}
[MIGRATE_RECLAIMABLE_MIRROR] = {MIGRATE_UNMOVABLE_MIRROR, 
MIGRATE_RESERVE_MIRROR}

was my intention. This means mirrored memory and unmirrored memory is separated 
completely.

But this should affect kswapd or other memory reclaim logic.

for example, kswapd stops free pages are more than hi watermark.
But mirrored/unmirrored pages exhausted cases are not handled in this series.
You need some extra check in memory reclaim logic if you go with migration_type.




Then, we'll not lose the original information of "Reclaiable Pages".

One problem here is whteher we should have MIGRATE_RESERVE_MIRROR.

If we never allow users to allocate mirrored memory, we should have 
MIGRATE_RESERVE_MIRROR.
But it seems to require much more code change to do that.

Creating a zone or adding an attribues to zones are another design choice.



If we add a new zone, mirror_zone will span others, I'm worry about this
maybe have problems.


Yes. that's problem. And zoneid bit is very limited resource.
(But memory reclaim logic can be unchanged.)

Anyway, I'd like to see your solution with above changes 1st rather than adding 
zones.

Thanks,
-Kame


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

Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation

[Archit Taneja]

Hi,

On 06/30/2015 12:40 PM, Daniel Vetter wrote:

Any updates on this or too much distractions? I really think doing
this would be awesome for the drm subsystem, instead of reinventing
this wheel for each driver.


I'd started on this again. I've got more free time now than before, so I 
should have something in a week or so. I agree it will help a lot (there 
are already two new drivers since we started discussing this!)


Archit


-Daniel

On Wed, Mar 25, 2015 at 10:21 AM, Daniel Vetter  wrote:

On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote:

Hi,

On 03/13/2015 02:36 PM, Daniel Vetter wrote:

On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:



On 03/11/2015 08:47 PM, Daniel Vetter wrote:

On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:



On 03/10/2015 05:47 PM, Daniel Vetter wrote:

On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:

On 03/10/2015 03:35 PM, Daniel Vetter wrote:

On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:

On 03/10/2015 03:17 PM, Daniel Vetter wrote:

On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..38f83a0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
help
  FBDEV helpers for KMS drivers.

+config DRM_FBDEV_EMULATION
+   bool "Enable legacy fbdev support for your modesetting driver"
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_KMS_FB_HELPER
+   select FB_SYS_FILLRECT
+   select FB_SYS_COPYAREA
+   select FB_SYS_IMAGEBLIT
+   select FB_SYS_FOPS
+   select FB_CFB_FILLRECT
+   select FB_CFB_COPYAREA
+   select FB_CFB_IMAGEBLIT
+   default y
+   help
+ Choose this option if you have a need for the legacy fbdev
+ support. Note that this support also provide the linux console
+ support on top of your modesetting driver.


Maybe clarify that for linux console support you also need
CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.


DRM_KMS_FB_HELPER selects that for us, right?


Hm right I've missed that. Reminds me that you need one more patch at the
end to remove all the various select DRM_KMS_FB_HELPER from all drm
drivers. Otherwise this knob here won't work by default if you e.g. select
radeon. In general we can't mix explicit options with menu entries with a
select.


I was trying that out. Removing DRM_KMS_FB_HELPER and having
DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in
their respective xyz_fbdev.c files.


But with the stubbed out functions that should work, right? Why doesn't
it?


There are still calls to functions from fb core like fb_set_suspend and
register_framebuffer which aren't covered by the drm fb helper functions.


Hm, sounds like we need another patch to stub out fb_set_suspend when
fbdev isn't enabled. Is there anything else?


There are a handful of fb core functions which are called by drm drivers:

fb_alloc_cmap/fb_dealloc_cmap

fb_sys_read/fb_sys_write

register_framebuffer/unregister_framebuffer/unlink_framebuffer/
remove_conflicting_framebuffers

fb_set_suspend

fb_deferred_io_init/fb_deferred_io_cleanup

framebuffer_alloc/framebuffer_release


Hm yeah that's somewhat annoying indeed. What about the following:
1. We move all the #include  from drivers into drm_fb_helper.h

2. Then we add stubs for these functions in drm_fb_helper.h, like this

#if defined(CONFIG_FB)
#include 
#else

/* static inline stubs for all the fb stuff used by kms drivers */
#endif

Imo this makes sense since kms drivers really have a bit a special
situation with fbdev. They're not full-blown fbdev drivers and can be
useful fully without fbdev.



I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs
won't really work because struct declarations(like fb_info) also get
removed.

I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h itself,
but that seemed a bit too intrusive.

This is what I'm currently doing:

- Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap would
actually benefit if we have drm fb helpers for them. They are used in
exactly the same manner by all the drivers.

- For the rest of the functions that are sparsely used, I was considering
making very simple drm_fb_* wrapper functions. Something like:

void drm_fb_helper_deferred_io_init(struct drm_fb_helper *helper)
{
   if (helper->fbdev)
   fb_deferred_io_init(helper->fbdev);
}

We could have all fb calls called within drm_fb_helper.c, creating
drm_fb_helper_* stub functions would then be an easier task. What do you
think?


That's actually an option I considered, but I hoped we could do it with
less work. If this indeed works and you can create the patch that would be
awesome.

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






--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundatio

Re: [PATCH v2 4/4] arm64: dts: Add spi bus dts

[Daniel Kurtz]

Hi Leilk,

On Mon, Jun 29, 2015 at 9:04 PM, Leilk Liu  wrote:
> This patch adds MT8173 spi bus controllers into device tree.
>
> Signed-off-by: Leilk Liu 
> ---
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 512e4eb..923d2eb 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -259,6 +259,15 @@
> status = "disabled";
> };
>
> +   spi: spi@1100a000 {
> +   compatible = "mediatek,mt8173-spi";
> +   reg = <0 0x1100a000 0 0x1000>;
> +   interrupts = ;
> +   clocks = <&pericfg CLK_PERI_SPI0>;
> +   clock-names = "main";

Please also add the spi pinctl node, and set it as the default pinctl
for this spi node.

> +   status = "disabled";
> +   };
> +
> mmsys: mmsys@1400 {
> compatible = "mediatek,mt8173-mmsys", "syscon";
> reg = <0 0x1400 0 0x1000>;
> --
> 1.8.1.1.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL 0/8] perf/pt -> Intel PT/BTS

[Adrian Hunter]

On 30/06/15 07:58, Ingo Molnar wrote:
> 
> * Arnaldo Carvalho de Melo  wrote:
> 
>> Hi Ingo,
>>
>>  Please consider pulling, there are several other patches after this,
>> but I think that this may be acceptable to showcase the capabilities already
>> present, look at the output of 'perf script' and callchains for userspace
>> without using any extra debugging info (no need for DWARF, CFI, nothing),
>> really cool capabilities... :-)
>>
>>  Adrian wrote some docs and I tested it both on a Ivy Bridge machine
>> where there is only BTS and on a Broadwell machine with the whole shebang,
>> adding the output of the commands to the csets, to further showcase what is
>> there already.
>>
>>  This is on top of my last perf-core-for-mingo tag.
>>
>>  Up to you, please let us know what you think and we'll continue working
>> on having this in an acceptable form for merging,
>>
>> Regards,
>>
>> - Arnaldo
>>
>> P.S. Kudos for Adrian for the patience with this process, way more is needed 
>> to
>> polish this, but the promise is there, cool stuff indeed! :-)
>>
>> The following changes since commit 36c8bb56a9f718a9a5f35d1834ca9dcec95deb4a:
>>
>>   perf symbols: Check access permission when reading symbol files 
>> (2015-06-26 12:11:53 -0300)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
>> tags/perf-pt-for-mingo
>>
>> for you to fetch changes up to 04759f172270afb28c8004f5cad62ed55710a499:
>>
>>   perf tools: Add Intel BTS support (2015-06-26 18:36:11 -0300)
>>
>> 
>> Put Intel PT and BTS into initial use (Adrian Hunter)
>>
>> Signed-off-by: Arnaldo Carvalho de Melo 
>>
>> 
>> Adrian Hunter (8):
>>   perf auxtrace: Add Intel PT as an AUX area tracing type
>>   perf tools: Add Intel PT packet decoder
>>   perf tools: Add Intel PT instruction decoder
>>   perf tools: Add Intel PT log
>>   perf tools: Add Intel PT decoder
>>   perf tools: Add Intel PT support
>>   perf tools: Take Intel PT into use
>>   perf tools: Add Intel BTS support
>>
>>  tools/build/Makefile.build |2 +
>>  tools/perf/.gitignore  |2 +
>>  tools/perf/Documentation/intel-bts.txt |   86 +
>>  tools/perf/Documentation/intel-pt.txt  |  588 ++
>>  tools/perf/MANIFEST|7 +
>>  tools/perf/Makefile.perf   |   12 +-
>>  tools/perf/arch/x86/util/Build |5 +
>>  tools/perf/arch/x86/util/auxtrace.c|   83 +
>>  tools/perf/arch/x86/util/intel-bts.c   |  458 +
>>  tools/perf/arch/x86/util/intel-pt.c|  752 
>>  tools/perf/arch/x86/util/pmu.c |   18 +
>>  tools/perf/util/Build  |3 +
>>  tools/perf/util/auxtrace.c |9 +-
>>  tools/perf/util/auxtrace.h |2 +
>>  tools/perf/util/intel-bts.c|  791 
>>  tools/perf/util/intel-bts.h|   43 +
>>  tools/perf/util/intel-pt-decoder/Build |   14 +
>>  .../perf/util/intel-pt-decoder/intel-pt-decoder.c  | 1759 ++
>>  .../perf/util/intel-pt-decoder/intel-pt-decoder.h  |  102 ++
>>  .../util/intel-pt-decoder/intel-pt-insn-decoder.c  |  246 +++
>>  .../util/intel-pt-decoder/intel-pt-insn-decoder.h  |   65 +
>>  tools/perf/util/intel-pt-decoder/intel-pt-log.c|  155 ++
>>  tools/perf/util/intel-pt-decoder/intel-pt-log.h|   52 +
>>  .../util/intel-pt-decoder/intel-pt-pkt-decoder.c   |  400 +
>>  .../util/intel-pt-decoder/intel-pt-pkt-decoder.h   |   64 +
>>  tools/perf/util/intel-pt.c | 1889 
>> 
>>  tools/perf/util/intel-pt.h |   51 +
>>  tools/perf/util/pmu.c  |4 -
>>  28 files changed, 7655 insertions(+), 7 deletions(-)
>>  create mode 100644 tools/perf/Documentation/intel-bts.txt
>>  create mode 100644 tools/perf/Documentation/intel-pt.txt
>>  create mode 100644 tools/perf/arch/x86/util/auxtrace.c
>>  create mode 100644 tools/perf/arch/x86/util/intel-bts.c
>>  create mode 100644 tools/perf/arch/x86/util/intel-pt.c
>>  create mode 100644 tools/perf/arch/x86/util/pmu.c
>>  create mode 100644 tools/perf/util/intel-bts.c
>>  create mode 100644 tools/perf/util/intel-bts.h
>>  create mode 100644 tools/perf/util/intel-pt-decoder/Build
>>  create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
>>  create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-decoder.h
>>  create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c
>>  create mode 100644 tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.h
>>  create mode 100644 tools/perf/util/int

Re: [PATCH] dmaengine: pl330: Really fix choppy sound because of wrong residue calculation

[Krzysztof Kozłowski]

2015-06-30 16:01 GMT+09:00 Lars-Peter Clausen :
> On 06/30/2015 06:51 AM, Krzysztof Kozłowski wrote:
>>
>> 2015-06-30 13:14 GMT+09:00 Vinod Koul :
>>>
>>> On Mon, Jun 22, 2015 at 11:14:42AM +0900, Krzysztof Kozłowski wrote:

 2015-06-15 23:00 GMT+09:00 Krzysztof Kozlowski
 :
>
> When pl330 driver was used during sound playback, after some time or
> after a number of plays the sound became choppy or totally noisy. For
> example on Odroid XU3 board the first four executions of aplay with
> small WAVE worked fine, but fifth was unrecognizable with errors:
>  $ aplay /usr/share/sounds/alsa/Front_Right.wava
>  underrun!!! (at least 0.095 ms long)
>
> Issue was caused by wrong residue reported by pl330 driver to
> pcm_dmaengine for its cyclic dma transfers.
>
> The pl330_tx_status(), residue reporting function, used a "last" flag
> in
> a descriptor to indicate that there is no more data to send.
>
> The pl330_tx_submit() iterated over descriptors trying to remove this
> flag from them and then mark last descriptor as "last".  However when
> iterating it actually removed the flag not from descriptors but always
> from last of it (and then reset it). Thus effectively once some
> descriptor was marked as last, then it stayed like this forever causing
> residue to be reported too low.
>
> Signed-off-by: Krzysztof Kozlowski 
> Fixes: aee4d1fac887 ("dmaengine: pl330: improve pl330_tx_status()
> function")
> Cc: 
> Reported-by: gabr...@unseen.is
> Suggested-by: Marek Szyprowski 


 Gabriel, could you give this patch a try? It helped for my Odroid XU3,
 which has the same audio codec. Nevertheless it would be great to hear
 that it solves the initial bug report.
>>>
>>>
>>> So is there a word on  what finally fixes this
>>
>>
>> This fixes sound issue on my Odroid XU3 board, which is good. My board
>> has the same audio codec and DMA driver as the board used by Gabriel
>> so there is high chance that his issue is also fixed.
>>
>> However it is sad that I did not receive any reviews or tests from
>> anyone, apparently no one cares enough about it :) .
>
>
> I care, I've had it in applied to my local tree for a while now. Without it
> audio does not work.
>
> Tested-by: Lars-Peter Clausen 

Thanks, I appreciate this!

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

Re: Use of pinctrl-single for external device over I2C

[Vaibhav Hiremath]

On Tuesday 30 June 2015 01:16 PM, Vaibhav Hiremath wrote:



On Thursday 25 June 2015 11:16 AM, Vaibhav Hiremath wrote:



On Thursday 25 June 2015 10:08 AM, Tony Lindgren wrote:

* Vaibhav Hiremath  [150624 10:12]:


I do not like this, as this is not HW feature, so DT may not be right
approach.

So I will dig more from either runtime or Compile time option to use
regmap_ Vs raw read/writes.


Can't you just check if the pinctrl node has compatible = "syscon"
property?

A compile time option won't work for sure. I don't know what you
would check at runtime as you do not know what the bus is behind
syscon.



Although, I haven't gone through syscon, but not sure whether syscon
would be useful.

As you rightly stated, we need to know the bus behind regmap.



Trying to understand what is the right way of doing pinctrl of external
device on board,

I feel it would not be good idea to pollute pinctrl-single driver, and
also I am still not able to figure out how can I have access to bus
behind regmap.


How about having separate driver (generic for all I2C), say pinctrl-
i2c.c, which is i2c_client driver and would support pinctrl and pinmux
on I2C client device.



I mean, part of mfd here (mfd_cell)



The current usecase which I have is pretty simple in nature,

88PM860 has few GPIO pins which can be configured to different
functionality, based on board design.
In most of the cases they are one/init/boot time settings.

GPIO_0:
===
   000 = GPIO input mode
   001 = GPIO output mode
   010 = SLEEPOUTN mirror mode
   011 = Buck4 FPWM enable
   100 = 32 Khz output buffer mode
   101 = PMICINTN output mode
   110 = HW_RESET1 mode
   111 = HW_RESET2 mode


Thanks,
Vaibhav

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

Re: [PATCH 1/1] igb: Use ARRAY_SIZE instead fo sizeof(a)/sizeof(a[0])

[Maninder Singh]

Hi Joe,

>> Use ARRAY_SIZE instead fo sizeof(a)/sizeof(a[0])
>
>I think all of these #defines should be removed instead
>as they are all used only once.

If we replcase only ARRAY_SIZE then cood will look alike
to drivers/net/ethernet/intel/e1000e/phy.c

And if we have to remove these #defines , then we can also remove it from 
drivers/net/ethernet/intel/e1000e/phy.c 

Because same operations and same usage is there in both files.
what say?

>> diff --git a/drivers/net/ethernet/intel/igb/e1000_phy.c 
>> b/drivers/net/ethernet/intel/igb/e1000_phy.c
>[]
>> @@ -37,8 +37,7 @@ static s32  igb_set_master_slave_mode(struct e1000_hw *hw);
>>  static const u16 e1000_m88_cable_length_table[] = {
>>  0, 50, 80, 110, 140, 140, E1000_CABLE_LENGTH_UNDEFINED };
>>  #define M88E1000_CABLE_LENGTH_TABLE_SIZE \
>> -(sizeof(e1000_m88_cable_length_table) / \
>> -sizeof(e1000_m88_cable_length_table[0]))
>> +ARRAY_SIZE(e1000_m88_cable_length_table)
>>  N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü¨}©ž²Æ 
>> zÚ&j:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹®w¥¢¸?™¨è­Ú&¢)ߢf”ù^jÇ«y§m…á@A«a¶Úÿ
>> 0¶ìh®å’i

[PATCH/RFC RESEND] leds: Use set_brightness_work for brightness_set ops that can sleep

[Jacek Anaszewski]

This patch rearranges the core LED subsystem code, so that it
now removes from drivers the responsibility of using work queues
internally in case their brightness_set ops can sleep.
Addition of two flags: LED_BRIGHTNESS_FAST and LED_BLINK_DISABLE
as well as new_brightness_value property to the struct led_classdev
allows for employing existing set_brightness_work to do the job.
The modifications allow also to get rid of brightness_set_sync op,
as flash LED devices can now be handled properly only basing on the
SET_BRIGHTNESS_SYNC flag.


Signed-off-by: Jacek Anaszewski 
Cc: Bryan Wu 
Cc: Richard Purdie 
Cc: Stas Sergeev 
Cc: Pavel Machek 
Cc: Sakari Ailus 
Cc: Andreas Werner 
Cc: Andrew Lunn 
Cc: Antonio Ospite 
Cc: Atsushi Nemoto 
Cc: Ben Dooks 
Cc: Chris Boot 
Cc: Dan Murphy 
Cc: Daniel Jeong 
Cc: Daniel Mack 
Cc: David S. Miller 
Cc: Fabio Baltieri 
Cc: Felipe Balbi 
Cc: Florian Fainelli 
Cc: G.Shark Jeong 
Cc: Guennadi Liakhovetski 
Cc: Ingi Kim 
Cc: Jan-Simon Moeller 
Cc: Johan Hovold 
Cc: John Lenz 
Cc: Jonas Gorski 
Cc: Kim Kyuwon 
Cc: Kristian Kielhofner 
Cc: Kristoffer Ericson 
Cc: Linus Walleij 
Cc: Mark Brown 
Cc: Michael Hennerich 
Cc: Milo Kim 
Cc: Márton Németh 
Cc: Nate Case 
Cc: NeilBrown 
Cc: Nick Forbes 
Cc: Paul Parsons 
Cc: Peter Meerwald 
Cc: Phil Sutter 
Cc: Philippe Retornaz 
Cc: Raphael Assenat 
Cc: Richard Purdie 
Cc: Rod Whitby 
Cc: Dave Hansen 
Cc: Rodolfo Giometti 
Cc: Sebastian A. Siewior 
Cc: Shuah Khan 
Cc: Simon Guinot 
Cc: Álvaro Fernández Rojas 
---

Resending because previously this patch failed to reach
linux-leds list. Also updated/removed defunct Cc addresses.

Hi All,

Since this patch will affect all the LED subsystem drivers
I'd like it was tested by as many developers as possible
to make sure that I haven't missed something.

For the drivers which can sleep in their brightness_set ops
(e.g. use mutex or gpio "cansleep" API) you only need to
remove the work queues and move the code executed currently
in the work queue task to the brightness_set op, as now
LED core does the job.

For drivers that are capable of setting brightness with use
of MMIO you need to set the LED_BRIGHTNESS_FAST flag, so
that LED core would know that it doesn't have to employ
work queue.

After the patch is positively verified I will create relevant
patches for every LED class driver.

This patch is based on linux-next_20150622.

I am looking forward to your cooperation.

Best Regards,
Jacek Anaszewski


 drivers/leds/led-class.c  |   18 +++
 drivers/leds/led-core.c   |   50 +
 drivers/leds/leds.h   |   41 +--
 drivers/leds/trigger/ledtrig-backlight.c  |8 ++---
 drivers/leds/trigger/ledtrig-default-on.c |2 +-
 drivers/leds/trigger/ledtrig-gpio.c   |6 ++--
 drivers/leds/trigger/ledtrig-heartbeat.c  |2 +-
 drivers/leds/trigger/ledtrig-oneshot.c|4 +--
 drivers/leds/trigger/ledtrig-transient.c  |8 ++---
 include/linux/leds.h  |9 ++
 10 files changed, 83 insertions(+), 65 deletions(-)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index beabfbc..07ccaeb 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -109,7 +109,7 @@ static void led_timer_function(unsigned long data)
unsigned long delay;
 
if (!led_cdev->blink_delay_on || !led_cdev->blink_delay_off) {
-   led_set_brightness_async(led_cdev, LED_OFF);
+   led_set_brightness_nosleep(led_cdev, LED_OFF);
return;
}
 
@@ -121,10 +121,10 @@ static void led_timer_function(unsigned long data)
brightness = led_get_brightness(led_cdev);
if (!brightness) {
/* Time to switch the LED on. */
-   if (led_cdev->delayed_set_value) {
+   if (led_cdev->new_brightness_value) {
led_cdev->blink_brightness =
-   led_cdev->delayed_set_value;
-   led_cdev->delayed_set_value = 0;
+   led_cdev->new_brightness_value;
+   led_cdev->new_brightness_value = 0;
}
brightness = led_cdev->blink_brightness;
delay = led_cdev->blink_delay_on;
@@ -137,7 +137,7 @@ static void led_timer_function(unsigned long data)
delay = led_cdev->blink_delay_off;
}
 
-   led_set_brightness_async(led_cdev, brightness);
+   led_set_brightness_nosleep(led_cdev, brightness);
 
/* Return in next iteration if led is in one-shot mode and we are in
 * the final blink state so that the led is toggled each delay_on +
@@ -161,9 +161,13 @@ static void set_brightness_delayed(struct work_struct *ws)
struct led_classdev *led_cdev =
container_of(ws, struct led_classdev, set_brightness_work);
 
-   led_stop_software_blink(led_cdev);
+   if

[PATCH] lib/bitmap.c: rewrite __bitmap_parse && __bitmap_parselist

[Pan Xinhui]

add __bitmap_parse_common to match any contents and return expected result.

as __bitmap_parse_common need NULL-terminated string, we alloc a new buf.

this patch also fix some parse issues in __bitmap_parselist.
now it can handle grouping errors with input like " ", ",", etc.

Signed-off-by: xinhuix.pan 
---
 lib/bitmap.c | 232 ---
 1 file changed, 128 insertions(+), 104 deletions(-)

diff --git a/lib/bitmap.c b/lib/bitmap.c
index 64c0926..bc53c4f 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -16,6 +16,8 @@
 #include 
 #include 
 
+#include 

+#include 
 /*
  * bitmaps provide an array of bits, implemented using an an
  * array of unsigned longs.  The number of valid bits in a
@@ -331,6 +333,58 @@ again:
 EXPORT_SYMBOL(bitmap_find_next_zero_area_off);
 
 /*

+ * __bitmap_parse_common - parse expected number from buf
+ * Return 0 on success.
+ * there two patterns.
+ * if buf's contents did not match any of them, reutrn equivalent error.
+ * Notice buf's contents may be changed.
+ */
+static int __bitmap_parse_common(char *buf, unsigned int buflen,
+unsigned long *a, unsigned long *b)
+{
+   int ret;
+   int token;
+   const match_table_t table = {
+   {
+   .token = 1,
+   .pattern = "%u",
+   },
+   {
+   .token = 2,
+   .pattern = "%u-%u",
+   },
+   {
+   .token = 0,
+   .pattern = NULL,
+   }
+   };
+   substring_t substr[MAX_OPT_ARGS];
+
+   if (!buflen || !a)
+   return -EINVAL;
+
+   token = match_token((char *)buf, table, substr);
+   switch (token) {
+   case 1:
+   *substr[0].to = '\0';
+   ret = kstrtoul(substr[0].from, 0, a);
+   if (b)
+   *b = *a;
+   break;
+   case 2:
+   *substr[0].to = '\0';
+   *substr[1].to = '\0';
+   ret = kstrtoul(substr[0].from, 0, a);
+   ret |= b ? kstrtoul(substr[1].from, 0, b) : -EINVAL;
+   break;
+   default:
+   ret = -EINVAL;
+   break;
+   }
+   return ret;
+}
+
+/*
  * Bitmap printing & parsing functions: first version by Nadia Yvette Chambers,
  * second version by Paul Jackson, third by Joe Korty.
  */
@@ -359,57 +413,44 @@ int __bitmap_parse(const char *buf, unsigned int buflen,
int is_user, unsigned long *maskp,
int nmaskbits)
 {
-   int c, old_c, totaldigits, ndigits, nchunks, nbits;
+   int nchunks, nbits, ret;
+   unsigned long a;
u32 chunk;
const char __user __force *ubuf = (const char __user __force *)buf;
+   char *kbuf, *endp;
+
+   if (!buflen)
+   return -EINVAL;
+   kbuf = kmalloc(buflen + 1, GFP_KERNEL);
+   if (!kbuf)
+   return -ENOMEM;
+   if (is_user) {
+   if (copy_from_user(kbuf, ubuf, buflen) != 0) {
+   kfree(kbuf);
+   return -EFAULT;
+   }
+   } else
+   memcpy(kbuf, buf, buflen);
+   kbuf[buflen] = '\0';
+   buf = strim(kbuf);
 
 	bitmap_zero(maskp, nmaskbits);
 
-	nchunks = nbits = totaldigits = c = 0;

+   nchunks = nbits = 0;
do {
-   chunk = ndigits = 0;
-
-   /* Get the next chunk of the bitmap */
-   while (buflen) {
-   old_c = c;
-   if (is_user) {
-   if (__get_user(c, ubuf++))
-   return -EFAULT;
-   }
-   else
-   c = *buf++;
-   buflen--;
-   if (isspace(c))
-   continue;
-
-   /*
-* If the last character was a space and the current
-* character isn't '\0', we've got embedded whitespace.
-* This is a no-no, so throw an error.
-*/
-   if (totaldigits && c && isspace(old_c))
-   return -EINVAL;
-
-   /* A '\0' or a ',' signal the end of the chunk */
-   if (c == '\0' || c == ',')
-   break;
-
-   if (!isxdigit(c))
-   return -EINVAL;
-
-   /*
-* Make sure there are at least 4 free bits in 'chunk'.
-* If not, this hexdigit will overflow 'chunk', so
-* throw an error.
-*/
-   if (chunk & ~((1UL << (CHUNKSZ - 4)) - 1))
-   return -EOVERFLOW;
-

4.2-rc0: early boot broken on Thinkpad X60, T40p

[Pavel Machek]

Hi!

Boot hangs after "Booting the kernel." message. 4.1-rc7 (or so) worked
ok. Same failure on thinkpad T40p.

Kernel based on c63f887bdae80858c7cebf914f45f69bbaa88e8d . Will try
current -rc0 next.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC v2 1/3] tty: serial core: provide method to search uart by phandle

[Sergei Zviagintsev]

Hi,

On Mon, Jun 29, 2015 at 06:44:23PM +0200, Dr. H. Nikolaus Schaller wrote:
[...]
> >> +  list_for_each_entry(uart, &uart_list, head) {
> >> +  if (node != uart->dev->of_node)
> >> +  continue;
> >> +
> >> +  return uart;
> > 
> > We can easily save three lines here :)
> 
> Hm. We have copied from here:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/phy/phy.c?id=refs/tags/v4.1#n65
> 
> So please let us know how you want to save 3 lines.

Sorry for not being specific, I just meant that it could be written as

if (node == uart->dev->of_node)
return uart;

> >> +/**
> >> + * devm_serial_get_uart_by_phandle - find the uart by phandle
> >> + * @dev - device that requests this uart
> >> + * @phandle - name of the property holding the uart phandle value
> >> + * @index - the index of the uart
> >> + *
> >> + * Returns the uart_port associated with the given phandle value,
> >> + * after getting a refcount to it, -ENODEV if there is no such uart or
> >> + * -EPROBE_DEFER if there is a phandle to the uart, but the device is
> >> + * not yet loaded. While at that, it also associates the device with
> >> + * the uart using devres. On driver detach, release function is invoked
> >> + * on the devres data, then, devres data is freed.
> > 
> > Add -ENOMEM and -EINVAL, remove -EPROBE_DEFER?
> 
> Well, if the device is not loaded it means the caller must return 
> -EPROBE_DEFER
> anyways since it can’t complete it’s probe function.

That was my mistake, from the first sight I hadn't found where
-EPROBE_DEFER is actually returned from the code and thus decided that
kernel-doc has an error. But now I see it, thanks.

> >> +
> >> +  *ptr = uart;
> >> +  devres_add(dev, ptr);
> > 
> > What is the point of assigning value to *ptr?
> 
> Good question. I think it is necessary to store a copy of the found uart/phy 
> instead of a reference.
> Therefore the assignment to *ptr copies into the new memory area allocated 
> above by 
> 
> ptr = devres_alloc(devm_serial_uart_release, sizeof(*ptr), GFP_KERNEL);
> 
> This makes the dev the owner of the data - instead of unknown ownership 
> before.
> 
> It is the same as here (but it might be wrong/unnecessary there as well):
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/phy/phy.c?id=refs/tags/v4.1#n209
> 
> Maybe it has something to do with the unfinished devm_serial_uart_release().

Indeed. I haven't noticed this through the first quick look into the
code. Thank you for explanation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] macintosh: Delete an unnecessary check before the function call "of_node_put"

[SF Markus Elfring]

Am 04.02.2015 um 21:36 schrieb SF Markus Elfring:
> From: Markus Elfring 
> Date: Wed, 4 Feb 2015 21:32:27 +0100
> 
> The of_node_put() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/macintosh/smu.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
> index 10ae69b..d531f80 100644
> --- a/drivers/macintosh/smu.c
> +++ b/drivers/macintosh/smu.c
> @@ -557,8 +557,7 @@ int __init smu_init (void)
>   return 0;
>  
>  fail_msg_node:
> - if (smu->msg_node)
> - of_node_put(smu->msg_node);
> + of_node_put(smu->msg_node);
>  fail_db_node:
>   of_node_put(smu->db_node);
>  fail_bootmem:
> 

Would you like to integrate this update suggestion
into another source code repository?

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

[PATCH 0/5] perf session: Fill in the missing freeing a session after an error occur

[Taeung Song]

In some cases some sessions aren't freed.
For example, a session is allocated and then
if an error occur, just a error value is returned
without freeing the session. So allocating and freeing
session have to be matched as a pair even if an error occur.

Taeung Song (5):
  perf inject: Fill in the missing freeing a session after an error
occur
  perf kmem: Fill in the missing freeing a session after an error occur
  perf kvm: Fill in the missing freeing a session after an error occur
  perf mem: Fill in the missing freeing a session after an error occur
  perf report: Fill in the missing freeing a session after an error
occur

 tools/perf/builtin-inject.c |  7 ---
 tools/perf/builtin-kmem.c   |  4 ++--
 tools/perf/builtin-kvm.c| 16 
 tools/perf/builtin-mem.c| 17 ++---
 tools/perf/builtin-report.c |  6 --
 5 files changed, 32 insertions(+), 18 deletions(-)

-- 
1.9.1

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

[PATCH 1/5] perf inject: Fill in the missing freeing a session after an error occur

[Taeung Song]

When an error occur a error value is just returned
without freeing the session. So allocating and freeing
session have to be matched as a pair even if an error occur.

Signed-off-by: Taeung Song 
---
 tools/perf/builtin-inject.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 52ec66b..01b0649 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -630,12 +630,13 @@ int cmd_inject(int argc, const char **argv, const char 
*prefix __maybe_unused)
if (inject.session == NULL)
return -1;
 
-   if (symbol__init(&inject.session->header.env) < 0)
-   return -1;
+   ret = symbol__init(&inject.session->header.env);
+   if (ret < 0)
+   goto out_delete;
 
ret = __cmd_inject(&inject);
 
+out_delete:
perf_session__delete(inject.session);
-
return ret;
 }
-- 
1.9.1

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

[PATCH 4/5] perf mem: Fill in the missing freeing a session after an error occur

[Taeung Song]

When an error occur a error value is just returned
without freeing the session. So allocating and freeing
session have to be matched as a pair even if an error occur.

Signed-off-by: Taeung Song 
---
 tools/perf/builtin-mem.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/tools/perf/builtin-mem.c b/tools/perf/builtin-mem.c
index da2ec06..8b6d473 100644
--- a/tools/perf/builtin-mem.c
+++ b/tools/perf/builtin-mem.c
@@ -135,24 +135,27 @@ static int report_raw_events(struct perf_mem *mem)
if (mem->cpu_list) {
ret = perf_session__cpu_bitmap(session, mem->cpu_list,
   mem->cpu_bitmap);
-   if (ret)
+   if (ret) {
+   ret = err;
goto out_delete;
+   }
}
 
-   if (symbol__init(&session->header.env) < 0)
-   return -1;
+   ret = symbol__init(&session->header.env);
+   if (ret < 0)
+   goto out_delete;
 
printf("# PID, TID, IP, ADDR, LOCAL WEIGHT, DSRC, SYMBOL\n");
 
err = perf_session__process_events(session);
if (err)
-   return err;
-
-   return 0;
+   ret = err;
+   else
+   ret = 0;
 
 out_delete:
perf_session__delete(session);
-   return err;
+   return ret;
 }
 
 static int report_events(int argc, const char **argv, struct perf_mem *mem)
-- 
1.9.1

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

[PATCH 5/5] perf report: Fill in the missing freeing a session after an error occur

[Taeung Song]

When an error occur a error value is just returned
without freeing the session. So allocating and freeing
session have to be matched as a pair even if an error occur.

Signed-off-by: Taeung Song 
---
 tools/perf/builtin-report.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 32626ea..610d056 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -828,8 +828,10 @@ repeat:
if (report.header || report.header_only) {
perf_session__fprintf_info(session, stdout,
   report.show_full_info);
-   if (report.header_only)
-   return 0;
+   if (report.header_only) {
+   ret = 0;
+   goto error;
+   }
} else if (use_browser == 0) {
fputs("# To display the perf.data header info, please use 
--header/--header-only options.\n#\n",
  stdout);
-- 
1.9.1

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

[PATCH 3/5] perf kvm: Fill in the missing freeing a session after an error occur

[Taeung Song]

When an error occur a error value is just returned
without freeing the session. So allocating and freeing
session have to be matched as a pair even if an error occur.

Signed-off-by: Taeung Song 
---
 tools/perf/builtin-kvm.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index 74878cd..5fa96a0 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -1061,8 +1061,10 @@ static int read_events(struct perf_kvm_stat *kvm)
 
symbol__init(&kvm->session->header.env);
 
-   if (!perf_session__has_traces(kvm->session, "kvm record"))
-   return -EINVAL;
+   if (!perf_session__has_traces(kvm->session, "kvm record")) {
+   ret = -EINVAL;
+   goto out_delete;
+   }
 
/*
 * Do not use 'isa' recorded in kvm_exit tracepoint since it is not
@@ -1070,9 +1072,15 @@ static int read_events(struct perf_kvm_stat *kvm)
 */
ret = cpu_isa_config(kvm);
if (ret < 0)
-   return ret;
+   goto out_delete;
 
-   return perf_session__process_events(kvm->session);
+   ret = perf_session__process_events(kvm->session);
+   if (ret < 0)
+   goto out_delete;
+
+out_delete:
+   perf_session__delete(kvm->session);
+   return ret;
 }
 
 static int parse_target_str(struct perf_kvm_stat *kvm)
-- 
1.9.1

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

Re: 4.2-rc0: early boot broken on Thinkpad X60, T40p

[Pavel Machek]

On Tue 2015-06-30 10:08:06, Pavel Machek wrote:
> Hi!
> 
> Boot hangs after "Booting the kernel." message. 4.1-rc7 (or so) worked
> ok. Same failure on thinkpad T40p.
> 
> Kernel based on c63f887bdae80858c7cebf914f45f69bbaa88e8d . Will try
> current -rc0 next.

Hmm, I do have CONFIG_SLAB enabled, so I guess

23936 Theodore T commit 4066c33d0308f8 breaks booting under KVM
23937 N   Theodore T └─>
23938 N   Christoph└─>
23939 N   Christoph  └─>[PATCH] Fix kmalloc slab creation sequence
23940 N   Linus Torv   └─>

is relevant to me.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] perf kmem: Fill in the missing freeing a session after an error occur

[Taeung Song]

When an error occur a error value is just returned
without freeing the session. So allocating and freeing
session have to be matched as a pair even if an error occur.

Signed-off-by: Taeung Song 
---
 tools/perf/builtin-kmem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 950f296..23b1faa 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -1916,7 +1916,7 @@ int cmd_kmem(int argc, const char **argv, const char 
*prefix __maybe_unused)
if (!perf_evlist__find_tracepoint_by_name(session->evlist,
  "kmem:kmalloc")) {
pr_err(errmsg, "slab", "slab");
-   return -1;
+   goto out_delete;
}
}
 
@@ -1927,7 +1927,7 @@ int cmd_kmem(int argc, const char **argv, const char 
*prefix __maybe_unused)
 
"kmem:mm_page_alloc");
if (evsel == NULL) {
pr_err(errmsg, "page", "page");
-   return -1;
+   goto out_delete;
}
 
kmem_page_size = pevent_get_page_size(evsel->tp_format->pevent);
-- 
1.9.1

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

[PATCH] staging: wilc1000: fix build failure

[Sudip Mukherjee]

commit 80279fb7ba5b ("cfg80211: properly send
NL80211_ATTR_DISCONNECTED_BY_AP in disconnect") has changed the api of
cfg80211_disconnected() and caused a build failure.
Add the extra argument as false since it appears from the code that the
disconnection is not locally generated.
And incase of doubt we can use false as that is the default behaviour.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 92064db..f7f5faf 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -675,7 +675,8 @@ static void CfgConnectResult(tenuConnDisconnEvent 
enuConnDisconnEvent,
pstrDisconnectNotifInfo->u16reason = 1;
}
cfg80211_disconnected(dev, pstrDisconnectNotifInfo->u16reason, 
pstrDisconnectNotifInfo->ie,
- pstrDisconnectNotifInfo->ie_len, 
GFP_KERNEL);
+ pstrDisconnectNotifInfo->ie_len, false,
+ GFP_KERNEL);
 
}
 
-- 
1.8.1.2

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

Re: [PATCH 01/41] clocksource: asm9260: Migrate to new 'set-state' interface

[Daniel Lezcano]

On 06/18/2015 12:54 PM, Viresh Kumar wrote:

Migrate asm9260 driver to the new 'set-state' interface provided by
clockevents core, the earlier 'set-mode' interface is marked obsolete
now.

This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.


Could you add in the changelog the subtle change with set_mode(RESUME) 
and this code. As a default the timer was stopped when entering in the 
set_mode function, now with the new API, this is done explicitly.



Cc: Oleksij Rempel 
Signed-off-by: Viresh Kumar 
---


[ ... ]


+static int asm9260_timer_shutdown(struct clock_event_device *evt)
  {
/* stop timer0 */
writel_relaxed(BM_C0_EN, priv.base + HW_TCR + CLR_REG);
+   return 0;
+}
+
+static int asm9260_timer_set_oneshot(struct clock_event_device *evt)
+{
+   /* stop timer0 */
+   writel_relaxed(BM_C0_EN, priv.base + HW_TCR + CLR_REG);


Can you replace this line with a call to asm9260_timer_shutdown ?


+   /* enable reset and stop on match */
+   writel_relaxed(BM_MCR_RES_EN(0) | BM_MCR_STOP_EN(0),
+  priv.base + HW_MCR + SET_REG);
+   return 0;
+}


[ ... ]


+static int asm9260_timer_set_periodic(struct clock_event_device *evt)
+{
+   /* stop timer0 */
+   writel_relaxed(BM_C0_EN, priv.base + HW_TCR + CLR_REG);


idem.

Thanks

  -- Daniel

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

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

Re: [PATCH RFC v2 3/3] misc: Add w2g0004 gps receiver driver

[Sergei Zviagintsev]

Hi,

I left some comments below.

On Sun, Jun 28, 2015 at 09:46:26PM +0200, Marek Belisko wrote:
> From: "H. Nikolaus Schaller" 
> 
> Add driver for Wi2Wi w2g004 GPS module connected through  uart. Use uart
> slave + notification hooks to glue with tty.
> 
> Signed-off-by: H. Nikolaus Schaller 
> Signed-off-by: Marek Belisko 
> ---
>  .../devicetree/bindings/misc/wi2wi,w2sg0004.txt|  18 +
>  drivers/misc/Kconfig   |  18 +
>  drivers/misc/Makefile  |   1 +
>  drivers/misc/w2sg0004.c| 436 
> +
>  include/linux/w2sg0004.h   |  28 ++
>  5 files changed, 501 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
>  create mode 100644 drivers/misc/w2sg0004.c
>  create mode 100644 include/linux/w2sg0004.h
> 
> diff --git a/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt 
> b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
> new file mode 100644
> index 000..ef0d6d5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
> @@ -0,0 +1,18 @@
> +Wi2Wi GPS module connected through UART
> +
> +Required properties:
> +- compatible: wi2wi,w2sg0004 or wi2wi,w2sg0084
> +- on-off-gpio: the GPIO that controls the module's on-off toggle input
> +- uart: the uart we are connected to (provides DTR for power control)
> +
> +Optional properties:
> +- lna-suppy: an (optional) LNA regulator that is enabled together with the 
> GPS receiver
> +
> +example:
> +
> +gps_receiver: w2sg0004 {
> +compatible = "wi2wi,w2sg0004";
> +lna-supply = <&vsim>;/* LNA regulator */
> +on-off-gpio = <&gpio5 17 0>; /* GPIO_145: trigger for 
> turning on/off w2sg0004 */
> +uart = <&uart1>; /* we are a slave of uart1 */
> +}
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 42c3852..952add4 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -527,4 +527,22 @@ source "drivers/misc/mic/Kconfig"
>  source "drivers/misc/genwqe/Kconfig"
>  source "drivers/misc/echo/Kconfig"
>  source "drivers/misc/cxl/Kconfig"
> +
> +menu "GTA04 misc hardware support"
> +
> +config W2SG0004
> + tristate "W2SG0004 on/off control"
> + depends on GPIOLIB
> + help
> +   Enable on/off control of W2SG0004 GPS using a tty slave to
> +   to allow powering up if the /dev/tty$n is opened.
> +   It also provides a rfkill gps node to control the LNA power.
> +
> +config W2SG0004_DEBUG
> + bool "W2SG0004 on/off debugging"
> + depends on W2SG0004
> + help
> +   Enable driver debugging mode of W2SG0004 GPS.
> +
> +endmenu
>  endmenu
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index d056fb7..3bc67c7 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -53,5 +53,6 @@ obj-$(CONFIG_SRAM)  += sram.o
>  obj-y+= mic/
>  obj-$(CONFIG_GENWQE) += genwqe/
>  obj-$(CONFIG_ECHO)   += echo/
> +obj-$(CONFIG_W2SG0004)   += w2sg0004.o
>  obj-$(CONFIG_VEXPRESS_SYSCFG)+= vexpress-syscfg.o
>  obj-$(CONFIG_CXL_BASE)   += cxl/
> diff --git a/drivers/misc/w2sg0004.c b/drivers/misc/w2sg0004.c
> new file mode 100644
> index 000..c5f0f7b
> --- /dev/null
> +++ b/drivers/misc/w2sg0004.c
> @@ -0,0 +1,436 @@
> +/*
> + * w2sg0004.c
> + * Driver for power controlling the w2sg0004/w2sg0084 GPS receiver.
> + *
> + * This receiver has an ON/OFF pin which must be toggled to
> + * turn the device 'on' of 'off'.  A high->low->high toggle
> + * will switch the device on if it is off, and off if it is on.
> + *
> + * To enable receiving on/off requests we register with the
> + * UART power management notifications.
> + *
> + * It is not possible to directly detect the state of the device.
> + * However when it is on it will send characters on a UART line
> + * regularly.
> + *
> + * To detect that the power state is out of sync (e.g. if GPS
> + * was enabled before a reboot), we register for UART data received
> + * notifications.
> + *
> + * In addition we register as a rfkill client so that we can
> + * control the LNA power.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#ifdef CONFIG_W2SG0004_DEBUG
> +#undef pr_debug
> +#define pr_debug printk
> +#endif
> +
> +/*
> + * There seems to be restrictions on how quickly we can toggle the
> + * on/off line.  data sheets says "two rtc ticks", whatever that means.
> + * If we do it too soon it doesn't work.
> + * So we have a state machine which uses the common work queue to ensure
> + * clean transitions.
> + * When a change is requested we record that request and only act on it
> + * once the previous chan

Re: [PATCH/RFC RESEND] leds: Use set_brightness_work for brightness_set ops that can sleep

[Jacek Anaszewski]

On 06/29/2015 05:17 PM, Stas Sergeev wrote:> 29.06.2015 17:05, Jacek 
Anaszewski пишет:

>> +   * If need to disable soft blinking delegate this to the
>> +   * work queue task to avoid problems in case we are
>> +   * called from hard irq context.
>> +   */
>> +  led_cdev->flags |= LED_BLINK_DISABLE;
> Wouldn't it be better to just enforce the callers
> to explicitly disable software blink, so that it to
> never happen from irq context? Something like in this
> patch:
> https://lkml.org/lkml/2015/5/13/491
>

Blinking can be disabled not only by removing trigger explicitly,
but also by setting brightness to 0 and led_set_brightness
can be called from hard irq context. set_brightness_work
was originally introduced exactly for this use case.

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

Re: [PATCH 02/41] clocksource: cadence_ttc: Migrate to new 'set-state' interface

[Daniel Lezcano]

On 06/18/2015 12:54 PM, Viresh Kumar wrote:

Migrate cadence_ttc driver to the new 'set-state' interface provided by
clockevents core, the earlier 'set-mode' interface is marked obsolete
now.

This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.

Cc: Michal Simek 
Cc: Sören Brinkmann 
Signed-off-by: Viresh Kumar 
---


Sounds good.


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation

[Benjamin Gaignard]

Hi,

I think that what have been done by Rob with module_param is also a good idea:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934

Can you mix compilation flag and module param ?

Benjamin

2015-06-30 9:56 GMT+02:00 Archit Taneja :
> Hi,
>
> On 06/30/2015 12:40 PM, Daniel Vetter wrote:
>>
>> Any updates on this or too much distractions? I really think doing
>> this would be awesome for the drm subsystem, instead of reinventing
>> this wheel for each driver.
>
>
> I'd started on this again. I've got more free time now than before, so I
> should have something in a week or so. I agree it will help a lot (there are
> already two new drivers since we started discussing this!)
>
> Archit
>
>
>> -Daniel
>>
>> On Wed, Mar 25, 2015 at 10:21 AM, Daniel Vetter  wrote:
>>>
>>> On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote:

 Hi,

 On 03/13/2015 02:36 PM, Daniel Vetter wrote:
>
> On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:
>>
>>
>>
>> On 03/11/2015 08:47 PM, Daniel Vetter wrote:
>>>
>>> On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:



 On 03/10/2015 05:47 PM, Daniel Vetter wrote:
>
> On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
>>
>> On 03/10/2015 03:35 PM, Daniel Vetter wrote:
>>>
>>> On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:

 On 03/10/2015 03:17 PM, Daniel Vetter wrote:
>
> On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
>>
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index 151a050..38f83a0 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
>> help
>>   FBDEV helpers for KMS drivers.
>>
>> +config DRM_FBDEV_EMULATION
>> +   bool "Enable legacy fbdev support for your modesetting
>> driver"
>> +   depends on DRM
>> +   select DRM_KMS_HELPER
>> +   select DRM_KMS_FB_HELPER
>> +   select FB_SYS_FILLRECT
>> +   select FB_SYS_COPYAREA
>> +   select FB_SYS_IMAGEBLIT
>> +   select FB_SYS_FOPS
>> +   select FB_CFB_FILLRECT
>> +   select FB_CFB_COPYAREA
>> +   select FB_CFB_IMAGEBLIT
>> +   default y
>> +   help
>> + Choose this option if you have a need for the legacy
>> fbdev
>> + support. Note that this support also provide the linux
>> console
>> + support on top of your modesetting driver.
>
>
> Maybe clarify that for linux console support you also need
> CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.


 DRM_KMS_FB_HELPER selects that for us, right?
>>>
>>>
>>> Hm right I've missed that. Reminds me that you need one more
>>> patch at the
>>> end to remove all the various select DRM_KMS_FB_HELPER from all
>>> drm
>>> drivers. Otherwise this knob here won't work by default if you
>>> e.g. select
>>> radeon. In general we can't mix explicit options with menu
>>> entries with a
>>> select.
>>
>>
>> I was trying that out. Removing DRM_KMS_FB_HELPER and having
>> DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff
>> internally in
>> their respective xyz_fbdev.c files.
>
>
> But with the stubbed out functions that should work, right? Why
> doesn't
> it?


 There are still calls to functions from fb core like fb_set_suspend
 and
 register_framebuffer which aren't covered by the drm fb helper
 functions.
>>>
>>>
>>> Hm, sounds like we need another patch to stub out fb_set_suspend when
>>> fbdev isn't enabled. Is there anything else?
>>
>>
>> There are a handful of fb core functions which are called by drm
>> drivers:
>>
>> fb_alloc_cmap/fb_dealloc_cmap
>>
>> fb_sys_read/fb_sys_write
>>
>> register_framebuffer/unregister_framebuffer/unlink_framebuffer/
>> remove_conflicting_framebuffers
>>
>> fb_set_suspend
>>
>> fb_deferred_io_init/fb_deferred_io_cleanup
>>
>> framebuffer_alloc/framebuffer_release
>
>
> Hm yeah that's somewhat annoying indeed. What about the following:
> 1. We move all the #include  from drivers into
> drm_fb_helper.h
>
> 2. Then we add stubs for these fu

Re: [PATCH] lib/bitmap.c: return -EINVAL for grouping errors in __bitmap_parselist

[Yury Norov]

2015-07-01 4:37 GMT+03:00 Pan Xinhui :
> hi, Yury
> thanks for your nice reply.
>
> On 2015年06月29日 21:39, Yury Norov wrote:
>>>
>>> Sometimes the input from user may cause an unexpected result.
>>
>>
>> Could you please provide specific example?
>>
> I wrote some scripts to do some tests about irqs.
> echo "1-3," > /proc/irq//smp_affinity_list
> this command ends with ',' by mistake.
> actually __bitmap_parselist() will report "0-3" for the final result which
> is wrong.
>

Hmm...
I don't think this is wrong passing echo "1-3,".
With or without a comma, the final result must be the same.
More flexible format is useful for hard scripts (for your one).
It's not too difficult to imagine a script producing a line:
 "1-24,  ,   ,,, ,  12-64, 92,92,92,,,"
And I don't think we should reject user with this once the range is valid.
Even more, to spend a time writing some additional code for it, and make
user spend his time as well.

I just tried
  cd /home/yury///./././/work
and it works perfectly well for me, and it's fine.

The true problem is that a and b variables
goes zero after comma, and EOL after comma just takes it:
 514 do {
 ...
 517 a = b = 0;   //
<--- comma makes it 0 here
 ...
 520 while (buflen) {
 ...
 539 /* A '\0' or a ',' signal the end of a cpu# or range */
 540 if (c == '\0' || c == ',') //
<---here we just break after '\0'
 541 break;
 559 }
 ...
 565 while (a <= b) {
 566 set_bit(a, maskp);   // <--- and
here we set unneeded 0 bit.
 567 a++;
 568 }

So currently, "1-3,\0" is the same as "1-3,0,\0". And this is definitely wrong.

>
>>>
>>> just like __bitmap_parse, we return -EINVAL if there is no avaiable digit
>>> in each
>>> parsing procedures.
>>>
>>> Signed-off-by: Pan Xinhui 
>>
>>
>> Hello, Pan.
>>
>> (Adding Alexey Klimov, Rasmus Villemoes)
>>
>>> ---
>>>lib/bitmap.c | 7 +--
>>>1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/lib/bitmap.c b/lib/bitmap.c
>>> index 64c0926..995fca2 100644
>>> --- a/lib/bitmap.c
>>> +++ b/lib/bitmap.c
>>> @@ -504,7 +504,7 @@ static int __bitmap_parselist(const char *buf,
>>> unsigned int buflen,
>>>int nmaskbits)
>>>{
>>>unsigned a, b;
>>> -int c, old_c, totaldigits;
>>> +int c, old_c, totaldigits, ndigits;
>>>const char __user __force *ubuf = (const char __user __force
>>> *)buf;
>>>int exp_digit, in_range;
>>>
>>> @@ -514,6 +514,7 @@ static int __bitmap_parselist(const char *buf,
>>> unsigned int buflen,
>>>exp_digit = 1;
>>>in_range = 0;
>>>a = b = 0;
>>> +ndigits = 0;
>>>
>>>/* Get the next cpu# or a range of cpu#'s */
>>>while (buflen) {
>>> @@ -555,8 +556,10 @@ static int __bitmap_parselist(const char *buf,
>>> unsigned int buflen,
>>>if (!in_range)
>>>a = b;
>>>exp_digit = 0;
>>> -totaldigits++;
>>> +ndigits++; totaldigits++;
>>
>>
>> I'm not happy with joining two statements to a single line.
>> Maybe sometimes it's OK for loop iterators like
>>
>>  while (a[i][j]) {
>>  i++; j++;
>>  }
>>
>> But here it looks nasty. Anyway, it's minor.
>>
>
> thanks for pointing out my mistake about the code style :)
>
>>>}
>>> +if (ndigits == 0)
>>> +return -EINVAL;
>>
>>
>> You can avoid in-loop incrementation of ndigits if you'll
>> save current totaldigits to ndigits before loop, and check
>> ndigits against totaldigits after the loop:
>>
>>  ndigits = totaldigits;
>>  while (...) {
>>   ...
>>  totaldigits++;
>>  }
>>
>>  if (ndigits == totaldigits)
>>  return -EINVAL;
>>
>> Maybe it's a good point to rework initial __bitmap_parse() similar way...
>>
>
> your advice is a good idea, thanks.
> I am also thinking if we can rewrite them into one function for common
> codes.
>
> thanks for your reply again :)
>
> thanks
> xinhui
>
>
>>>if (!(a <= b))
>>>return -EINVAL;
>>>if (b >= nmaskbits)
>>> --
>>> 1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2] lib/bitmap.c: rewrite __bitmap_parse && __bitmap_parselist

[Pan Xinhui]

add __bitmap_parse_common to match any contents and return expected reslut.

as __bitmap_parse_common need NULL-terminated string, we alloc a new buf.

this patch also fix some parse issues in __bitmap_parselist.
now it can handle grouping errors with input like " ", ",", etc.

Signed-off-by: Pan Xinhui 
---
 lib/bitmap.c | 234 +--
 1 file changed, 130 insertions(+), 104 deletions(-)
---
change log
V2:
__bitmap_parse_common need *base* to parse correct result

V1:
add __bitmap_parse_common and rewrite __bitmap_parse && __bitmap_parselist
---

diff --git a/lib/bitmap.c b/lib/bitmap.c
index 64c0926..dde19bf 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -16,6 +16,8 @@
 #include 
 #include 
 
+#include 

+#include 
 /*
  * bitmaps provide an array of bits, implemented using an an
  * array of unsigned longs.  The number of valid bits in a
@@ -331,6 +333,58 @@ again:
 EXPORT_SYMBOL(bitmap_find_next_zero_area_off);
 
 /*

+ * __bitmap_parse_common - parse expected number from buf
+ * Return 0 on success.
+ * there two patterns.
+ * if buf's contents did not match any of them, reutrn equivalent error.
+ * Notice buf's contents may be changed.
+ */
+static int __bitmap_parse_common(char *buf, unsigned int buflen,
+unsigned long *a, unsigned long *b, int base)
+{
+   int ret;
+   int token;
+   const match_table_t table = {
+   {
+   .token = 1,
+   .pattern = "%x",
+   },
+   {
+   .token = 2,
+   .pattern = "%x-%x",
+   },
+   {
+   .token = 0,
+   .pattern = NULL,
+   }
+   };
+   substring_t substr[MAX_OPT_ARGS];
+
+   if (!buflen || !a)
+   return -EINVAL;
+
+   token = match_token((char *)buf, table, substr);
+   switch (token) {
+   case 1:
+   *substr[0].to = '\0';
+   ret = kstrtoul(substr[0].from, base, a);
+   if (b)
+   *b = *a;
+   break;
+   case 2:
+   *substr[0].to = '\0';
+   *substr[1].to = '\0';
+   ret = kstrtoul(substr[0].from, base, a);
+   ret |= b ? kstrtoul(substr[1].from, base, b) : -EINVAL;
+   break;
+   default:
+   ret = -EINVAL;
+   break;
+   }
+   return ret;
+}
+
+/*
  * Bitmap printing & parsing functions: first version by Nadia Yvette Chambers,
  * second version by Paul Jackson, third by Joe Korty.
  */
@@ -359,57 +413,45 @@ int __bitmap_parse(const char *buf, unsigned int buflen,
int is_user, unsigned long *maskp,
int nmaskbits)
 {
-   int c, old_c, totaldigits, ndigits, nchunks, nbits;
+   int nchunks, nbits, ret;
+   unsigned long a;
u32 chunk;
const char __user __force *ubuf = (const char __user __force *)buf;
+   char *kbuf, *endp;
+
+   if (!buflen)
+   return -EINVAL;
+   kbuf = kmalloc(buflen + 1, GFP_KERNEL);
+   if (!kbuf)
+   return -ENOMEM;
+   if (is_user) {
+   if (copy_from_user(kbuf, ubuf, buflen) != 0) {
+   kfree(kbuf);
+   return -EFAULT;
+   }
+   } else
+   memcpy(kbuf, buf, buflen);
+   kbuf[buflen] = '\0';
+   buf = strim(kbuf);
 
 	bitmap_zero(maskp, nmaskbits);
 
-	nchunks = nbits = totaldigits = c = 0;

+   nchunks = nbits = 0;
do {
-   chunk = ndigits = 0;
-
-   /* Get the next chunk of the bitmap */
-   while (buflen) {
-   old_c = c;
-   if (is_user) {
-   if (__get_user(c, ubuf++))
-   return -EFAULT;
-   }
-   else
-   c = *buf++;
-   buflen--;
-   if (isspace(c))
-   continue;
-
-   /*
-* If the last character was a space and the current
-* character isn't '\0', we've got embedded whitespace.
-* This is a no-no, so throw an error.
-*/
-   if (totaldigits && c && isspace(old_c))
-   return -EINVAL;
-
-   /* A '\0' or a ',' signal the end of the chunk */
-   if (c == '\0' || c == ',')
-   break;
-
-   if (!isxdigit(c))
-   return -EINVAL;
-
-   /*
-* Make sure there are at least 4 free bits in 'chunk'.
-* If not, this hexdigit will overflow 'chunk', so
-  

Re: [PATCH RFC v2 3/3] misc: Add w2g0004 gps receiver driver

[Dr. H. Nikolaus Schaller]

Hi,
thanks for the valid and very valuable comments!
We will integrate them into RFC v3.
BR,
Nikolaus

Am 30.06.2015 um 10:23 schrieb Sergei Zviagintsev :

> Hi,
> 
> I left some comments below.
> 
> On Sun, Jun 28, 2015 at 09:46:26PM +0200, Marek Belisko wrote:
>> From: "H. Nikolaus Schaller" 
>> 
>> Add driver for Wi2Wi w2g004 GPS module connected through  uart. Use uart
>> slave + notification hooks to glue with tty.
>> 
>> Signed-off-by: H. Nikolaus Schaller 
>> Signed-off-by: Marek Belisko 
>> ---
>> .../devicetree/bindings/misc/wi2wi,w2sg0004.txt|  18 +
>> drivers/misc/Kconfig   |  18 +
>> drivers/misc/Makefile  |   1 +
>> drivers/misc/w2sg0004.c| 436 
>> +
>> include/linux/w2sg0004.h   |  28 ++
>> 5 files changed, 501 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
>> create mode 100644 drivers/misc/w2sg0004.c
>> create mode 100644 include/linux/w2sg0004.h
>> 
>> diff --git a/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt 
>> b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
>> new file mode 100644
>> index 000..ef0d6d5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
>> @@ -0,0 +1,18 @@
>> +Wi2Wi GPS module connected through UART
>> +
>> +Required properties:
>> +- compatible: wi2wi,w2sg0004 or wi2wi,w2sg0084
>> +- on-off-gpio: the GPIO that controls the module's on-off toggle input
>> +- uart: the uart we are connected to (provides DTR for power control)
>> +
>> +Optional properties:
>> +- lna-suppy: an (optional) LNA regulator that is enabled together with the 
>> GPS receiver
>> +
>> +example:
>> +
>> +gps_receiver: w2sg0004 {
>> +compatible = "wi2wi,w2sg0004";
>> +lna-supply = <&vsim>;   /* LNA regulator */
>> +on-off-gpio = <&gpio5 17 0>;/* GPIO_145: trigger 
>> for turning on/off w2sg0004 */
>> +uart = <&uart1>;/* we are a slave of uart1 */
>> +}
>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>> index 42c3852..952add4 100644
>> --- a/drivers/misc/Kconfig
>> +++ b/drivers/misc/Kconfig
>> @@ -527,4 +527,22 @@ source "drivers/misc/mic/Kconfig"
>> source "drivers/misc/genwqe/Kconfig"
>> source "drivers/misc/echo/Kconfig"
>> source "drivers/misc/cxl/Kconfig"
>> +
>> +menu "GTA04 misc hardware support"
>> +
>> +config W2SG0004
>> +tristate "W2SG0004 on/off control"
>> +depends on GPIOLIB
>> +help
>> +  Enable on/off control of W2SG0004 GPS using a tty slave to
>> +  to allow powering up if the /dev/tty$n is opened.
>> +  It also provides a rfkill gps node to control the LNA power.
>> +
>> +config W2SG0004_DEBUG
>> +bool "W2SG0004 on/off debugging"
>> +depends on W2SG0004
>> +help
>> +  Enable driver debugging mode of W2SG0004 GPS.
>> +
>> +endmenu
>> endmenu
>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
>> index d056fb7..3bc67c7 100644
>> --- a/drivers/misc/Makefile
>> +++ b/drivers/misc/Makefile
>> @@ -53,5 +53,6 @@ obj-$(CONFIG_SRAM) += sram.o
>> obj-y+= mic/
>> obj-$(CONFIG_GENWQE) += genwqe/
>> obj-$(CONFIG_ECHO)   += echo/
>> +obj-$(CONFIG_W2SG0004)  += w2sg0004.o
>> obj-$(CONFIG_VEXPRESS_SYSCFG)+= vexpress-syscfg.o
>> obj-$(CONFIG_CXL_BASE)   += cxl/
>> diff --git a/drivers/misc/w2sg0004.c b/drivers/misc/w2sg0004.c
>> new file mode 100644
>> index 000..c5f0f7b
>> --- /dev/null
>> +++ b/drivers/misc/w2sg0004.c
>> @@ -0,0 +1,436 @@
>> +/*
>> + * w2sg0004.c
>> + * Driver for power controlling the w2sg0004/w2sg0084 GPS receiver.
>> + *
>> + * This receiver has an ON/OFF pin which must be toggled to
>> + * turn the device 'on' of 'off'.  A high->low->high toggle
>> + * will switch the device on if it is off, and off if it is on.
>> + *
>> + * To enable receiving on/off requests we register with the
>> + * UART power management notifications.
>> + *
>> + * It is not possible to directly detect the state of the device.
>> + * However when it is on it will send characters on a UART line
>> + * regularly.
>> + *
>> + * To detect that the power state is out of sync (e.g. if GPS
>> + * was enabled before a reboot), we register for UART data received
>> + * notifications.
>> + *
>> + * In addition we register as a rfkill client so that we can
>> + * control the LNA power.
>> + *
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#ifdef CONFIG_W2SG0004_DEBUG
>> +#undef pr_debug
>> +#define pr_debug printk
>> +#endif
>> +
>> +/*
>> + * There seems to be restrictions on how quickly we can toggle the
>> + * on/off line.  data sheets says "two rt

Re: kexec crash kernel running with watchdog enabled

[Hidehiro Kawai]

(2015/06/29 21:26), Vivek Goyal wrote:
> On Mon, Jun 29, 2015 at 06:53:29PM +0900, Hidehiro Kawai wrote:
>> Hi,
>>
>> (2015/06/27 3:33), dwal...@fifo99.com wrote:
> On Fri, Jun 26, 2015 at 10:02:00AM +0900, Hidehiro Kawai wrote:
 Hi,

 (2015/06/25 1:31), dwal...@fifo99.com wrote:
> On Wed, Jun 24, 2015 at 03:52:48PM +0900, Masami Hiramatsu wrote:
>> Hi,
>>
>> On 2015/06/23 23:05, dwal...@fifo99.com wrote:
>>>
>>> Hi,
>>>
>>> There was a commit in kernel/panic.c which altered when the kexec crash 
>>> kernel is executed,
>>>
>>> commit f06e5153f4ae2e2f3b0300f0e260e40cb7fefd45
>>> Author: Masami Hiramatsu 
>>> Date:   Fri Jun 6 14:37:07 2014 -0700
>>>
>>> kernel/panic.c: add "crash_kexec_post_notifiers" option for kdump 
>>> after panic_notifers
>>>
>>>
>>> This made it possible for smp_send_stop() to be executed prior to 
>>> calling the kexec crash
>>> kernel.
>>>
>>> The issue is that smp_send_stop() offlines the cores, and other code 
>>> depend on the cores being online.
>>>
>>> In my case on Octeon here's an example,
>>>
>>> panic()
>>>  crash_kexec()
>>>   machine_crash_shutdown()
>>>octeon_generic_shutdown()
>>>
>>> Inside octeon_generic_shutdown() the Octeon watchdog is shutdown 
>>> for_each_online_cpu(), but since
>>> most of the cpu's already got offlined in smp_send_stop() it means the 
>>> watchdog is still alive on
>>> those cores. This results in a reboot during the crash kernel execution.
>>
>> Ah, I see.
>>
>>> Another example seem to be in default_machine_crash_shutdown() where 
>>> crash_kexec_prepare_cpus() depends
>>> on an IPI for saving the registers on different cores. However, the 
>>> cpu's are all offlined with
>>> interrupts disabled so they won't be running those IPI's in this case.
>>>
>>> I'm looking for any advice on how this should be fixed, or if it's 
>>> already fixed. I'm not going to be
>>> submitting a patch so if anyone wants to submit one feel free to do so.
>>
>> Hmm, IMHO, when the cpu goes to offline in appropriate 
>> way(smp_send_stop), it should stop
>> watchdog timer on the offlined cpu too.
>> Or, you can also register crash handler which stops all watchdogs, but 
>> it's a bit tricky.
>>
>
> That doesn't really fix all the issue tho. As I was explaining generic 
> MIPS code depends on the cpu's
> effectively being online for crash data collection (with an IPI). This 
> issue may effect other architectures also,
> because smp_send_stop() offlines the cpu on other architectures also. I 
> haven't surveyed the other architectures
> enough to know what issue could happen from this tho.
>
> Is it possible to move the smp_send_stop() below the notifiers ? I'm just 
> throwing out ideas.

 No, that doesn't works.  Some notifiers assume that they run in
 single core mode.

 Another possible solution is to add notifiers just after
 machine_crash_shutdown() like this:

 void panic(const char *fmt, ...)
 ...
 -  if (!crash_kexec_post_notifiers)
 -  crash_kexec(NULL);
 +  crash_kexec(NULL, buf);

   and

 -void crash_kexec(struct pt_regs *regs)
 +void crash_kexec(struct pt_regs *regs, char *msg)
  ...
if (kexec_crash_image) {
struct pt_regs fixed_regs;
  
crash_setup_regs(&fixed_regs, regs);
crash_save_vmcoreinfo();
machine_crash_shutdown(&fixed_regs);
 +  if (crash_kexec_post_notifiers) {
 +  kmsg_dump(KMSG_DUMP_PANIC);
 +  
 atomic_notifier_call_chain(&panic_notifier_list, 0, msg);
 +  }
 machine_kexec(kexec_crash_image);

 Most of archs stop other cores in machine_crash_shutdown(),
 so it will work well.  Furthermore, it simplifies the special
 case where crash_kexec() is called without entering panic().

 However, we need some tweaks for sh and s390 cases.  As for sh,
 it seems not to stop other cores in the crash_kexec() sequence
 (kdump support is incompleted?).  For s390, smp_send_stop() is
 called in machine_kexec() but not machine_crash_shutdown().
>>>
>>> You could add an ifdef into the __setup() to filter out s390 and sh, until 
>>> we figure out what
>>> to do there. So the "crash_kexec_post_notifiers" wouldn't be available for 
>>> those platforms.
>>
>> I agree on disabling the "crash_kexec_post_notifiers" feature for
>> s390 and sh at this time.  Also, we should make this feature effective
>> only if CONFIG_CRASH_DUMP=y.  Otherwise, it makes no sense.
>>
>> I'll prepare the bug fix patch.  Please wait a moment.
> 
> Why

Re: [PATCH][v2] asus-rbtn: new driver for asus radio button for Windows 8

[Alex Hung]

Pali,

Thanks for comments, but will you be able to provide more details so
it is more clear how this works?

On Mon, Jun 29, 2015 at 8:29 PM, Pali Rohár  wrote:
> On Friday 26 June 2015 23:24:10 Alex Hung wrote:
>> On Fri, Jun 26, 2015 at 10:56 PM, Pali Rohár  wrote:
>> > Hi!
>> >
>> > On Wednesday 24 June 2015 10:57:51 Alex Hung wrote:
>> >> ASUS introduced a new approach to handle wireless hotkey
>> >> since Windows 8.  When the hotkey is pressed, BIOS generates
>> >> a notification 0x88 to a new ACPI device, ATK4001.  This
>> >> new driver not only translates the notification to KEY_RFKILL
>> >> but also toggles its LED accordingly.
>> >>
>> >> Signed-off-by: Alex Hung 
>> >
>> > ...
>> >
>> >> +static int asus_radio_led_set(bool blocked)
>> >> +{
>> >> + acpi_status status;
>> >> + union acpi_object arg0 = { ACPI_TYPE_INTEGER };
>> >> + struct acpi_object_list args = { 1, &arg0 };
>> >> + unsigned long long output;
>> >> +
>> >> + arg0.integer.value = blocked;
>> >> + status = acpi_evaluate_integer(asus_rbtn_device->handle, "HSWC",
>> >> +&args, &output);
>> >
>> > What is this ACPI call doing? Just set LED control? Or something more?
>> >
>> >> + if (!ACPI_SUCCESS(status) || output == 0) {
>> >> + pr_err("fail to change wireless LED.\n");
>> >> + return -EINVAL;
>> >> + }
>> >> +
>> >> + return 0;
>> >> +}
>> >> +
>> >> +static int asus_rfkill_set(void *data, bool blocked)
>> >> +{
>> >> + radio_led_state = blocked ? 0 : 1;
>> >> +
>> >> + return asus_radio_led_set(radio_led_state);
>> >> +}
>> >
>> > In my opinion this is not good idea that "rfkill block" call from
>> > userspace just change LED on/off state and nothing more...
>> >
>> > If above ACPI call just change LED, then should not be this in LED
>> > subsystem instead rfkill one? Or why do you prefer to use rfkill
>> > interface instead led?
>>
>> It indeed controls LED only at the moment.  My intention was to have
>> have everything work without the need to modify any userspace
>> applications.  Current it is 1) aus-rbtn issues KEY_RFKILL 2) an
>> userspace application changes rfkill states, and 3) both radio and LED
>> work.  It will also work when a user enable/disable wireless devices
>> on a user application which uses rfkill interface.
>>
>> Come to think about it now, I may have to handle LED with WLAN and BT
>> but I will have to find a system with both devices later.
>>
>> I am not too familiar with userspace applications v.s. LED.  Is it
>> possible to do the same (i.e. without touching userspace)? I think
>> rfkill is good interface to handle whatever needs doing when changing
>> wireless states, such as LED controls.  However, if other approach can
>> meet the need I am happy to investigate.
>>
>
> There are triggers for led which automatically enable/disable led. I
> think that configuring default wifi/bluetooth trigger for that new led
> could work...
>
> --
> Pali Rohár
> pali.ro...@gmail.com



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

Re: [PATCH] lib/bitmap.c: return -EINVAL for grouping errors in __bitmap_parselist

[Pan Xinhui]

hi, Yury

On 2015年06月30日 16:32, Yury Norov wrote:

2015-07-01 4:37 GMT+03:00 Pan Xinhui :

hi, Yury
 thanks for your nice reply.

On 2015年06月29日 21:39, Yury Norov wrote:


Sometimes the input from user may cause an unexpected result.



Could you please provide specific example?


I wrote some scripts to do some tests about irqs.
echo "1-3," > /proc/irq//smp_affinity_list
this command ends with ',' by mistake.
actually __bitmap_parselist() will report "0-3" for the final result which
is wrong.



Hmm...
I don't think this is wrong passing echo "1-3,".
With or without a comma, the final result must be the same.
More flexible format is useful for hard scripts (for your one).
It's not too difficult to imagine a script producing a line:
  "1-24,  ,   ,,, ,  12-64, 92,92,92,,,"
And I don't think we should reject user with this once the range is valid.
Even more, to spend a time writing some additional code for it, and make
user spend his time as well.

I just tried
   cd /home/yury///./././/work
and it works perfectly well for me, and it's fine.

The true problem is that a and b variables
goes zero after comma, and EOL after comma just takes it:
  514 do {
  ...
  517 a = b = 0;   //
<--- comma makes it 0 here
  ...
  520 while (buflen) {
  ...
  539 /* A '\0' or a ',' signal the end of a cpu# or range */
  540 if (c == '\0' || c == ',') //
<---here we just break after '\0'
  541 break;
  559 }
  ...
  565 while (a <= b) {
  566 set_bit(a, maskp);   // <--- and
here we set unneeded 0 bit.
  567 a++;
  568 }

So currently, "1-3,\0" is the same as "1-3,0,\0". And this is definitely wrong.


yes, you are right.
current codes did not check if there is any digit between ',' or '\0'.
I has sent out patch V2, which rewrite two functions.
could you help have a code review if you have free time? thanks for your nice 
reply :)

thanks,
xinhui





just like __bitmap_parse, we return -EINVAL if there is no avaiable digit
in each
parsing procedures.

Signed-off-by: Pan Xinhui 



Hello, Pan.

(Adding Alexey Klimov, Rasmus Villemoes)


---
lib/bitmap.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/lib/bitmap.c b/lib/bitmap.c
index 64c0926..995fca2 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -504,7 +504,7 @@ static int __bitmap_parselist(const char *buf,
unsigned int buflen,
int nmaskbits)
{
unsigned a, b;
-int c, old_c, totaldigits;
+int c, old_c, totaldigits, ndigits;
const char __user __force *ubuf = (const char __user __force
*)buf;
int exp_digit, in_range;

@@ -514,6 +514,7 @@ static int __bitmap_parselist(const char *buf,
unsigned int buflen,
exp_digit = 1;
in_range = 0;
a = b = 0;
+ndigits = 0;

/* Get the next cpu# or a range of cpu#'s */
while (buflen) {
@@ -555,8 +556,10 @@ static int __bitmap_parselist(const char *buf,
unsigned int buflen,
if (!in_range)
a = b;
exp_digit = 0;
-totaldigits++;
+ndigits++; totaldigits++;



I'm not happy with joining two statements to a single line.
Maybe sometimes it's OK for loop iterators like

  while (a[i][j]) {
  i++; j++;
  }

But here it looks nasty. Anyway, it's minor.



thanks for pointing out my mistake about the code style :)


}
+if (ndigits == 0)
+return -EINVAL;



You can avoid in-loop incrementation of ndigits if you'll
save current totaldigits to ndigits before loop, and check
ndigits against totaldigits after the loop:

  ndigits = totaldigits;
  while (...) {
   ...
  totaldigits++;
  }

  if (ndigits == totaldigits)
  return -EINVAL;

Maybe it's a good point to rework initial __bitmap_parse() similar way...



your advice is a good idea, thanks.
I am also thinking if we can rewrite them into one function for common
codes.

thanks for your reply again :)

thanks
xinhui



if (!(a <= b))
return -EINVAL;
if (b >= nmaskbits)
--
1.9.1

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

Re: [PATCH] mm: cleaning per architecture MM hook header files

[Laurent Dufour]

On 30/06/2015 09:28, Vineet Gupta wrote:
>> diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild
>> index 769b312c1abb..2febe6ff32ed 100644
>> --- a/arch/arc/include/asm/Kbuild
>> +++ b/arch/arc/include/asm/Kbuild
>> @@ -49,3 +49,4 @@ generic-y += ucontext.h
>>  generic-y += user.h
>>  generic-y += vga.h
>>  generic-y += xor.h
>> +generic-y += mm-arch-hooks.h
>> diff --git a/arch/arc/include/asm/mm-arch-hooks.h 
>> b/arch/arc/include/asm/mm-arch-hooks.h
>> deleted file mode 100644
>> index c37541c5f8ba..
>> --- a/arch/arc/include/asm/mm-arch-hooks.h
>> +++ /dev/null
>> @@ -1,15 +0,0 @@
>> -/*
>> - * Architecture specific mm hooks
>> - *
>> - * Copyright (C) 2015, IBM Corporation
>> - * Author: Laurent Dufour 
>> - *
>> - * 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.
>> - */
>> -
>> -#ifndef _ASM_ARC_MM_ARCH_HOOKS_H
>> -#define _ASM_ARC_MM_ARCH_HOOKS_H
>> -
>> -#endif /* _ASM_ARC_MM_ARCH_HOOKS_H */
>> diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild
>> index 83c50193626c..870a2f7cbada 100644
>> --- a/arch/arm/include/asm/Kbuild
>> +++ b/arch/arm/include/asm/Kbuild
>> @@ -36,3 +36,4 @@ generic-y += termios.h
>>  generic-y += timex.h
>>  generic-y += trace_clock.h
>>  generic-y += unaligned.h
>> +generic-y += mm-arch-hooks.h
> 
> We keep this file sorted by headers so please can u respin with right 
> ordering !

Sure, I will send a new version.

Thanks for the review,
Laurent.

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

Re: [PATCH] arm: perf: Set affinity for PPI based PMUs

[Will Deacon]

Hi Stephen,

On Mon, Jun 29, 2015 at 10:58:46PM +0100, Stephen Boyd wrote:
> For PPI based PMUs, we bail out early in of_pmu_irq_cfg() without
> setting the PMU's supported_cpus bitmap. This causes the
> smp_call_function_any() in armv7_probe_num_events() to fail. Set
> the bitmap to be all CPUs so that we properly probe PMUs that use
> PPIs.
> 
> Fixes: cc88116da0d1 ("arm: perf: treat PMUs as CPU affine")
> Cc: Mark Rutland 
> Signed-off-by: Stephen Boyd 
> ---
>  arch/arm/kernel/perf_event.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> index 54272e0be713..7d5379c1c443 100644
> --- a/arch/arm/kernel/perf_event.c
> +++ b/arch/arm/kernel/perf_event.c
> @@ -795,8 +795,10 @@ static int of_pmu_irq_cfg(struct arm_pmu *pmu)
>  
>   /* Don't bother with PPIs; they're already affine */
>   irq = platform_get_irq(pdev, 0);
> - if (irq >= 0 && irq_is_percpu(irq))
> + if (irq >= 0 && irq_is_percpu(irq)) {
> + cpumask_setall(&pmu->supported_cpus);
>   return 0;
> + }

Looks good to me as a fix, but I'm currently working on extending the
interrupt-affinity property to work with both SPIs and PPIs so that we
can use it to identify PMU affinity on multi-cluster systems.

  
https://git.kernel.org/cgit/linux/kernel/git/will/linux.git/commit/?h=perf/updates&id=633fa0b629d86e58d68aff295f92031877dd0294

Any chance you could take that for a spin on your platform, please?

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

Re: 4.2-rc0: early boot broken on Thinkpad X60, T40p

[Pavel Machek]

On Tue 2015-06-30 10:15:51, Pavel Machek wrote:
> On Tue 2015-06-30 10:08:06, Pavel Machek wrote:
> > Hi!
> > 
> > Boot hangs after "Booting the kernel." message. 4.1-rc7 (or so) worked
> > ok. Same failure on thinkpad T40p.
> > 
> > Kernel based on c63f887bdae80858c7cebf914f45f69bbaa88e8d . Will try
> > current -rc0 next.

It now hangs at debug: inmapping init... message.

>   pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][v2] asus-rbtn: new driver for asus radio button for Windows 8

[Pali Rohár]

Hi!

Ideally, try to touch led trigger configuration from userspace yourself,
so you will see how it works. Take some machine which has some
configurable led exported in /sys/class/leds/ and try to set some
trigger via "trigger" entry.

I think that default trigger for led device (from kernel) can be set via
"default_trigger" property in struct led_classdev. See file linux/leds.h

On Tuesday 30 June 2015 16:38:18 Alex Hung wrote:
> Pali,
> 
> Thanks for comments, but will you be able to provide more details so
> it is more clear how this works?
> 
> On Mon, Jun 29, 2015 at 8:29 PM, Pali Rohár  wrote:
> > On Friday 26 June 2015 23:24:10 Alex Hung wrote:
> >> On Fri, Jun 26, 2015 at 10:56 PM, Pali Rohár  wrote:
> >> > Hi!
> >> >
> >> > On Wednesday 24 June 2015 10:57:51 Alex Hung wrote:
> >> >> ASUS introduced a new approach to handle wireless hotkey
> >> >> since Windows 8.  When the hotkey is pressed, BIOS generates
> >> >> a notification 0x88 to a new ACPI device, ATK4001.  This
> >> >> new driver not only translates the notification to KEY_RFKILL
> >> >> but also toggles its LED accordingly.
> >> >>
> >> >> Signed-off-by: Alex Hung 
> >> >
> >> > ...
> >> >
> >> >> +static int asus_radio_led_set(bool blocked)
> >> >> +{
> >> >> + acpi_status status;
> >> >> + union acpi_object arg0 = { ACPI_TYPE_INTEGER };
> >> >> + struct acpi_object_list args = { 1, &arg0 };
> >> >> + unsigned long long output;
> >> >> +
> >> >> + arg0.integer.value = blocked;
> >> >> + status = acpi_evaluate_integer(asus_rbtn_device->handle, "HSWC",
> >> >> +&args, &output);
> >> >
> >> > What is this ACPI call doing? Just set LED control? Or something more?
> >> >
> >> >> + if (!ACPI_SUCCESS(status) || output == 0) {
> >> >> + pr_err("fail to change wireless LED.\n");
> >> >> + return -EINVAL;
> >> >> + }
> >> >> +
> >> >> + return 0;
> >> >> +}
> >> >> +
> >> >> +static int asus_rfkill_set(void *data, bool blocked)
> >> >> +{
> >> >> + radio_led_state = blocked ? 0 : 1;
> >> >> +
> >> >> + return asus_radio_led_set(radio_led_state);
> >> >> +}
> >> >
> >> > In my opinion this is not good idea that "rfkill block" call from
> >> > userspace just change LED on/off state and nothing more...
> >> >
> >> > If above ACPI call just change LED, then should not be this in LED
> >> > subsystem instead rfkill one? Or why do you prefer to use rfkill
> >> > interface instead led?
> >>
> >> It indeed controls LED only at the moment.  My intention was to have
> >> have everything work without the need to modify any userspace
> >> applications.  Current it is 1) aus-rbtn issues KEY_RFKILL 2) an
> >> userspace application changes rfkill states, and 3) both radio and LED
> >> work.  It will also work when a user enable/disable wireless devices
> >> on a user application which uses rfkill interface.
> >>
> >> Come to think about it now, I may have to handle LED with WLAN and BT
> >> but I will have to find a system with both devices later.
> >>
> >> I am not too familiar with userspace applications v.s. LED.  Is it
> >> possible to do the same (i.e. without touching userspace)? I think
> >> rfkill is good interface to handle whatever needs doing when changing
> >> wireless states, such as LED controls.  However, if other approach can
> >> meet the need I am happy to investigate.
> >>
> >
> > There are triggers for led which automatically enable/disable led. I
> > think that configuring default wifi/bluetooth trigger for that new led
> > could work...
> >
> > --
> > Pali Rohár
> > pali.ro...@gmail.com
> 
> 
> 

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

[PATCH RESEND 0/5] x86_64 kasan fixes

[Andrey Ryabinin]

Ugh, sorry Resending with lkml CC'ed.


On 06/30/2015 08:23 AM, Ingo Molnar wrote:> 
> 
> So if there's a latest series of fixes to apply, please send it.
> 
> Thanks,
> 
>   Ingo

I've grabbed everything in this series. Including fix from Alexander
with slightly tweaked changelog by me and with stable tag.
Plus trivial patch that moves config option into a proper place.

Alexander Popov (1):
  x86_64: fix kasan shadow region page tables

Andrey Ryabinin (4):
  x86_64: kasan: flush tlbs after switching cr3
  x86_64: kasan: fix boot crash on AMD processors
  x86_64: kasan: add message about kasan being initialized
  x86_64: kasan: move KASAN_SHADOW_OFFSET to the arch Kconfig

 arch/x86/Kconfig |  5 +
 arch/x86/include/asm/kasan.h |  8 ++--
 arch/x86/kernel/head64.c | 10 --
 arch/x86/kernel/head_64.S| 29 ---
 arch/x86/mm/kasan_init_64.c  | 47 +++-
 lib/Kconfig.kasan|  4 
 6 files changed, 53 insertions(+), 50 deletions(-)

-- 
2.4.4

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

Re: [PATCH 01/41] clocksource: asm9260: Migrate to new 'set-state' interface

[Viresh Kumar]

On 30-06-15, 10:25, Daniel Lezcano wrote:
> Could you add in the changelog the subtle change with
> set_mode(RESUME) and this code. As a default the timer was stopped
> when entering in the set_mode function, now with the new API, this
> is done explicitly.

> Can you replace this line with a call to asm9260_timer_shutdown ?

How does this look ?

--8<--

Message-Id: 
<12839571df542ecc8b9304b7de9881216d45aef8.1435654791.git.viresh.ku...@linaro.org>
From: Viresh Kumar 
Date: Fri, 27 Feb 2015 13:39:52 +0530
Subject: [PATCH] clocksource: asm9260: Migrate to new 'set-state' interface

Migrate asm9260 driver to the new 'set-state' interface provided by
clockevents core, the earlier 'set-mode' interface is marked obsolete
now.

As a default the timer was stopped when entering in the set_mode(RESUME)
function, now this is done explicitly with the new API.

This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.

Cc: Oleksij Rempel 
Signed-off-by: Viresh Kumar 
---
 drivers/clocksource/asm9260_timer.c | 64 ++---
 1 file changed, 39 insertions(+), 25 deletions(-)

diff --git a/drivers/clocksource/asm9260_timer.c 
b/drivers/clocksource/asm9260_timer.c
index 4c2ba59897e8..217438d39eb3 100644
--- a/drivers/clocksource/asm9260_timer.c
+++ b/drivers/clocksource/asm9260_timer.c
@@ -120,38 +120,52 @@ static int asm9260_timer_set_next_event(unsigned long 
delta,
return 0;
 }
 
-static void asm9260_timer_set_mode(enum clock_event_mode mode,
-   struct clock_event_device *evt)
+static inline void __asm9260_timer_shutdown(struct clock_event_device *evt)
 {
/* stop timer0 */
writel_relaxed(BM_C0_EN, priv.base + HW_TCR + CLR_REG);
+}
+
+static int asm9260_timer_shutdown(struct clock_event_device *evt)
+{
+   __asm9260_timer_shutdown(evt);
+   return 0;
+}
+
+static int asm9260_timer_set_oneshot(struct clock_event_device *evt)
+{
+   __asm9260_timer_shutdown(evt);
+
+   /* enable reset and stop on match */
+   writel_relaxed(BM_MCR_RES_EN(0) | BM_MCR_STOP_EN(0),
+  priv.base + HW_MCR + SET_REG);
+   return 0;
+}
+
+static int asm9260_timer_set_periodic(struct clock_event_device *evt)
+{
+   __asm9260_timer_shutdown(evt);
 
-   switch (mode) {
-   case CLOCK_EVT_MODE_PERIODIC:
-   /* disable reset and stop on match */
-   writel_relaxed(BM_MCR_RES_EN(0) | BM_MCR_STOP_EN(0),
-   priv.base + HW_MCR + CLR_REG);
-   /* configure match count for TC0 */
-   writel_relaxed(priv.ticks_per_jiffy, priv.base + HW_MR0);
-   /* enable TC0 */
-   writel_relaxed(BM_C0_EN, priv.base + HW_TCR + SET_REG);
-   break;
-   case CLOCK_EVT_MODE_ONESHOT:
-   /* enable reset and stop on match */
-   writel_relaxed(BM_MCR_RES_EN(0) | BM_MCR_STOP_EN(0),
-   priv.base + HW_MCR + SET_REG);
-   break;
-   default:
-   break;
-   }
+   /* disable reset and stop on match */
+   writel_relaxed(BM_MCR_RES_EN(0) | BM_MCR_STOP_EN(0),
+  priv.base + HW_MCR + CLR_REG);
+   /* configure match count for TC0 */
+   writel_relaxed(priv.ticks_per_jiffy, priv.base + HW_MR0);
+   /* enable TC0 */
+   writel_relaxed(BM_C0_EN, priv.base + HW_TCR + SET_REG);
+   return 0;
 }
 
 static struct clock_event_device event_dev = {
-   .name   = DRIVER_NAME,
-   .rating = 200,
-   .features   = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
-   .set_next_event = asm9260_timer_set_next_event,
-   .set_mode   = asm9260_timer_set_mode,
+   .name   = DRIVER_NAME,
+   .rating = 200,
+   .features   = CLOCK_EVT_FEAT_PERIODIC |
+ CLOCK_EVT_FEAT_ONESHOT,
+   .set_next_event = asm9260_timer_set_next_event,
+   .set_state_shutdown = asm9260_timer_shutdown,
+   .set_state_periodic = asm9260_timer_set_periodic,
+   .set_state_oneshot  = asm9260_timer_set_oneshot,
+   .tick_resume= asm9260_timer_shutdown,
 };
 
 static irqreturn_t asm9260_timer_interrupt(int irq, void *dev_id)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/5] x86_64: kasan: add message about kasan being initialized

[Andrey Ryabinin]

Print informational message to tell user that kernel
runs with kasan enabled.
Add "kasan: " prefix to all messages in kasan_init_64.c

Signed-off-by: Andrey Ryabinin 
---
 arch/x86/mm/kasan_init_64.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
index 9a54dbe..e1840f3 100644
--- a/arch/x86/mm/kasan_init_64.c
+++ b/arch/x86/mm/kasan_init_64.c
@@ -1,3 +1,4 @@
+#define pr_fmt(fmt) "kasan: " fmt
 #include 
 #include 
 #include 
@@ -237,4 +238,6 @@ void __init kasan_init(void)
load_cr3(init_level4_pgt);
__flush_tlb_all();
init_task.kasan_depth = 0;
+
+   pr_info("Kernel address sanitizer initialized\n");
 }
-- 
2.4.4

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

[PATCH 1/5] x86_64: fix kasan shadow region page tables

[Andrey Ryabinin]

From: Alexander Popov 

Currently kasan shadow region page tables created without respect of
physical offset (phys_base). This causes kernel halt when phys_base
is not zero.
So let's initialize kasan shadow region page tables in kasan_early_init()
using __pa_nodebug() which considers phys_base.

This patch also cleans up x86_64_start_kernel() from kasan low level details
by moving kasan_map_early_shadow(init_level4_pgt) into kasan_early_init().
That requires to move clear_page(init_level4_pgt) before kasan_early_init().

Remove the comment before clear_bss() which stopped bringing much
profit to the code readability. Otherwise describing all the new
order dependencies would be too verbose.

Signed-off-by: Alexander Popov 
Signed-off-by: Andrey Ryabinin 
Cc:  # 4.0
---
 arch/x86/include/asm/kasan.h |  8 ++--
 arch/x86/kernel/head64.c | 10 --
 arch/x86/kernel/head_64.S| 29 -
 arch/x86/mm/kasan_init_64.c  | 36 ++--
 4 files changed, 40 insertions(+), 43 deletions(-)

diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h
index 8b22422..74a2a8d 100644
--- a/arch/x86/include/asm/kasan.h
+++ b/arch/x86/include/asm/kasan.h
@@ -14,15 +14,11 @@
 
 #ifndef __ASSEMBLY__
 
-extern pte_t kasan_zero_pte[];
-extern pte_t kasan_zero_pmd[];
-extern pte_t kasan_zero_pud[];
-
 #ifdef CONFIG_KASAN
-void __init kasan_map_early_shadow(pgd_t *pgd);
+void __init kasan_early_init(void);
 void __init kasan_init(void);
 #else
-static inline void kasan_map_early_shadow(pgd_t *pgd) { }
+static inline void kasan_early_init(void) { }
 static inline void kasan_init(void) { }
 #endif
 
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 5a46681..f129a9a 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -161,11 +161,12 @@ asmlinkage __visible void __init x86_64_start_kernel(char 
* real_mode_data)
/* Kill off the identity-map trampoline */
reset_early_page_tables();
 
-   kasan_map_early_shadow(early_level4_pgt);
-
-   /* clear bss before set_intr_gate with early_idt_handler */
clear_bss();
 
+   clear_page(init_level4_pgt);
+
+   kasan_early_init();
+
for (i = 0; i < NUM_EXCEPTION_VECTORS; i++)
set_intr_gate(i, early_idt_handler_array[i]);
load_idt((const struct desc_ptr *)&idt_descr);
@@ -177,12 +178,9 @@ asmlinkage __visible void __init x86_64_start_kernel(char 
* real_mode_data)
 */
load_ucode_bsp();
 
-   clear_page(init_level4_pgt);
/* set init_level4_pgt kernel high mapping*/
init_level4_pgt[511] = early_level4_pgt[511];
 
-   kasan_map_early_shadow(init_level4_pgt);
-
x86_64_start_reservations(real_mode_data);
 }
 
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index df7e780..7e5da2c 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -516,38 +516,9 @@ ENTRY(phys_base)
/* This must match the first entry in level2_kernel_pgt */
.quad   0x
 
-#ifdef CONFIG_KASAN
-#define FILL(VAL, COUNT)   \
-   .rept (COUNT) ; \
-   .quad   (VAL) ; \
-   .endr
-
-NEXT_PAGE(kasan_zero_pte)
-   FILL(kasan_zero_page - __START_KERNEL_map + _KERNPG_TABLE, 512)
-NEXT_PAGE(kasan_zero_pmd)
-   FILL(kasan_zero_pte - __START_KERNEL_map + _KERNPG_TABLE, 512)
-NEXT_PAGE(kasan_zero_pud)
-   FILL(kasan_zero_pmd - __START_KERNEL_map + _KERNPG_TABLE, 512)
-
-#undef FILL
-#endif
-
-
 #include "../../x86/xen/xen-head.S"

__PAGE_ALIGNED_BSS
 NEXT_PAGE(empty_zero_page)
.skip PAGE_SIZE
 
-#ifdef CONFIG_KASAN
-/*
- * This page used as early shadow. We don't use empty_zero_page
- * at early stages, stack instrumentation could write some garbage
- * to this page.
- * Latter we reuse it as zero shadow for large ranges of memory
- * that allowed to access, but not instrumented by kasan
- * (vmalloc/vmemmap ...).
- */
-NEXT_PAGE(kasan_zero_page)
-   .skip PAGE_SIZE
-#endif
diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
index 4860906..0e4a05f 100644
--- a/arch/x86/mm/kasan_init_64.c
+++ b/arch/x86/mm/kasan_init_64.c
@@ -11,7 +11,19 @@
 extern pgd_t early_level4_pgt[PTRS_PER_PGD];
 extern struct range pfn_mapped[E820_X_MAX];
 
-extern unsigned char kasan_zero_page[PAGE_SIZE];
+static pud_t kasan_zero_pud[PTRS_PER_PUD] __page_aligned_bss;
+static pmd_t kasan_zero_pmd[PTRS_PER_PMD] __page_aligned_bss;
+static pte_t kasan_zero_pte[PTRS_PER_PTE] __page_aligned_bss;
+
+/*
+ * This page used as early shadow. We don't use empty_zero_page
+ * at early stages, stack instrumentation could write some garbage
+ * to this page.
+ * Latter we reuse it as zero shadow for large ranges of memory
+ * that allowed to access, but not instrumented by kasan
+ * (vmalloc/vmemmap ...).
+ */
+static unsigned ch

[PATCH 2/5] x86_64: kasan: flush tlbs after switching cr3

[Andrey Ryabinin]

load_cr3() doesn't cause tlb_flush if PGE enabled.
This may cause tons of false positive reports spamming
kernel to death.
To fix this __flush_tlb_all() should be called explicitly
after cr3 changed.

Signed-off-by: Andrey Ryabinin 
Cc:  # 4.0
---
 arch/x86/mm/kasan_init_64.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
index 0e4a05f..5d26642 100644
--- a/arch/x86/mm/kasan_init_64.c
+++ b/arch/x86/mm/kasan_init_64.c
@@ -208,6 +208,7 @@ void __init kasan_init(void)
 
memcpy(early_level4_pgt, init_level4_pgt, sizeof(early_level4_pgt));
load_cr3(early_level4_pgt);
+   __flush_tlb_all();
 
clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
 
@@ -234,5 +235,6 @@ void __init kasan_init(void)
memset(kasan_zero_page, 0, PAGE_SIZE);
 
load_cr3(init_level4_pgt);
+   __flush_tlb_all();
init_task.kasan_depth = 0;
 }
-- 
2.4.4

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

[PATCH 5/5] x86_64: kasan: move KASAN_SHADOW_OFFSET to the arch Kconfig

[Andrey Ryabinin]

KASAN_SHADOW_OFFSET is purely arch specific setting,
so it should be in arch's Kconfig file.

Signed-off-by: Andrey Ryabinin 
Cc: Paul Bolle 
---
 arch/x86/Kconfig  | 5 +
 lib/Kconfig.kasan | 4 
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 226d569..8bd35ad 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -248,6 +248,11 @@ config ARCH_SUPPORTS_OPTIMIZED_INLINING
 config ARCH_SUPPORTS_DEBUG_PAGEALLOC
def_bool y
 
+config KASAN_SHADOW_OFFSET
+   hex
+   depends on KASAN
+   default 0xdc00
+
 config HAVE_INTEL_TXT
def_bool y
depends on INTEL_IOMMU && ACPI
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index 777eda7..39f24d6 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -18,10 +18,6 @@ config KASAN
  For better error detection enable CONFIG_STACKTRACE,
  and add slub_debug=U to boot cmdline.
 
-config KASAN_SHADOW_OFFSET
-   hex
-   default 0xdc00 if X86_64
-
 choice
prompt "Instrumentation type"
depends on KASAN
-- 
2.4.4

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

[PATCH 3/5] x86_64: kasan: fix boot crash on AMD processors

[Andrey Ryabinin]

While populating zero shadow wrong bits in upper level page tables
used. __PAGE_KERNEL_RO that was used for pgd/pud/pmd has
_PAGE_BIT_GLOBAL set. Global bit is present only in the lowest
level of the page translation hierarchy (ptes), and it should be zero
in upper levels.
This bug seems doesn't cause any troubles on Intel cpus, while on AMDs
it cause kernel crash on boot.

Use _KERNPG_TABLE bits for pgds/puds/pmds to fix this.

Signed-off-by: Andrey Ryabinin 
Reported-by: Borislav Petkov 
Cc:  # 4.0
---
 arch/x86/mm/kasan_init_64.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
index 5d26642..9a54dbe 100644
--- a/arch/x86/mm/kasan_init_64.c
+++ b/arch/x86/mm/kasan_init_64.c
@@ -85,7 +85,7 @@ static int __init zero_pmd_populate(pud_t *pud, unsigned long 
addr,
while (IS_ALIGNED(addr, PMD_SIZE) && addr + PMD_SIZE <= end) {
WARN_ON(!pmd_none(*pmd));
set_pmd(pmd, __pmd(__pa_nodebug(kasan_zero_pte)
-   | __PAGE_KERNEL_RO));
+   | _KERNPG_TABLE));
addr += PMD_SIZE;
pmd = pmd_offset(pud, addr);
}
@@ -111,7 +111,7 @@ static int __init zero_pud_populate(pgd_t *pgd, unsigned 
long addr,
while (IS_ALIGNED(addr, PUD_SIZE) && addr + PUD_SIZE <= end) {
WARN_ON(!pud_none(*pud));
set_pud(pud, __pud(__pa_nodebug(kasan_zero_pmd)
-   | __PAGE_KERNEL_RO));
+   | _KERNPG_TABLE));
addr += PUD_SIZE;
pud = pud_offset(pgd, addr);
}
@@ -136,7 +136,7 @@ static int __init zero_pgd_populate(unsigned long addr, 
unsigned long end)
while (IS_ALIGNED(addr, PGDIR_SIZE) && addr + PGDIR_SIZE <= end) {
WARN_ON(!pgd_none(*pgd));
set_pgd(pgd, __pgd(__pa_nodebug(kasan_zero_pud)
-   | __PAGE_KERNEL_RO));
+   | _KERNPG_TABLE));
addr += PGDIR_SIZE;
pgd = pgd_offset_k(addr);
}
-- 
2.4.4

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

Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation

[Daniel Vetter]

On Tue, Jun 30, 2015 at 10:31 AM, Benjamin Gaignard
 wrote:
> I think that what have been done by Rob with module_param is also a good idea:
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934
>
> Can you mix compilation flag and module param ?

Hm, the point of the kconfig is to not require all the legacy baggage
from fbdev. But I guess a module option could be added later on too.
bochs has it too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] [media] mt9v032: Add missing initialization of pdata in mt9v032_get_pdata()

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Monday 29 June 2015 14:23:41 Geert Uytterhoeven wrote:
> drivers/media/i2c/mt9v032.c: In function ‘mt9v032_get_pdata’:
> drivers/media/i2c/mt9v032.c:885: warning: ‘pdata’ may be used uninitialized
> in this function
> 
> If parsing the endpoint node properties fails, mt9v032_get_pdata() will
> return an uninitialized pointer value.
> 
> Signed-off-by: Geert Uytterhoeven 

Acked-by: Laurent Pinchart 

and applied to my tree.

> ---
>  drivers/media/i2c/mt9v032.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
> index 977f4006edbd496d..a68ce94ee097604a 100644
> --- a/drivers/media/i2c/mt9v032.c
> +++ b/drivers/media/i2c/mt9v032.c
> @@ -882,7 +882,7 @@ static const struct regmap_config mt9v032_regmap_config
> = { static struct mt9v032_platform_data *
>  mt9v032_get_pdata(struct i2c_client *client)
>  {
> - struct mt9v032_platform_data *pdata;
> + struct mt9v032_platform_data *pdata = NULL;
>   struct v4l2_of_endpoint endpoint;
>   struct device_node *np;
>   struct property *prop;

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 3/4] blk-mq: establish new mapping before cpu starts handling requests

[Ming Lei]

On Mon, Jun 29, 2015 at 10:25 PM, Akinobu Mita  wrote:
> 2015-06-28 1:08 GMT+09:00 Ming Lei :
>> On Sat, Jun 27, 2015 at 1:14 AM, Akinobu Mita  wrote:
>>> Akinobu Mita  wrote:
 2015-06-26 0:40 GMT+09:00 Ming Lei :
 > On Thu, 25 Jun 2015 21:49:43 +0900
 > Akinobu Mita  wrote:
 >> For example, there is a single hw queue (hctx) and two CPU queues
 >> (ctx0 for CPU0, and ctx1 for CPU1).  Now CPU1 is just onlined and
 >> a request is inserted into ctx1->rq_list and set bit0 in pending
 >> bitmap as ctx1->index_hw is still zero.
 >>
 >> And then while running hw queue, flush_busy_ctxs() finds bit0 is set
 >> in pending bitmap and tries to retrieve requests in
 >> hctx->ctxs[0].rq_list.  But htx->ctxs[0] is ctx0, so the request in
 >> ctx1->rq_list is ignored.
 >
 > Per current design, the request should have been inserted into ctx0 
 > instead
 > of ctx1 because ctx1 isn't mapped yet even though ctx1->cpu becomes 
 > ONLINE.
 >
 > So how about the following patch? which looks much simpler.

 OK, I'll try this patch to see if the problem disappears.
>>>
>>> This doesn't fix the problem.  Because:
>>>
 > diff --git a/block/blk-mq.c b/block/blk-mq.c
 > index f537796..2f45b73 100644
 > --- a/block/blk-mq.c
 > +++ b/block/blk-mq.c
 > @@ -1034,7 +1034,12 @@ void blk_mq_insert_request(struct request *rq, 
 > bool at_head, bool run_queue,
 > struct blk_mq_ctx *ctx = rq->mq_ctx, *current_ctx;
 >
 > current_ctx = blk_mq_get_ctx(q);
 > -   if (!cpu_online(ctx->cpu))
 > +   /*
 > +* ctx->cpu may become ONLINE but ctx hasn't been mapped to
 > +* hctx yet because there is a tiny race window between
 > +* ctx->cpu ONLINE and doing the remap
 > +*/
 > +   if (!blk_mq_ctx_mapped(ctx))
 > rq->mq_ctx = ctx = current_ctx;
>>>
>>> The process running on just onlined CPU1 in the above example can
>>> satisfy this condition and current_ctx will be ctx1.  So the same
>>> scenario can happen (the request is ignored by flush_busy_ctxs).
>>
>> Yeah, that is possible, and it should be bug of blk_mq_insert_request(),
>> because the function supposes that the current ctx is mapped.
>>
>> Then I think the approach in your 1st email of this thread may be
>> good one, and looks we have to make the remapping during
>> CPU UP_PREPARE notifier.
>
> OK, we can move on to other topic that you suggested in the other mail
> thread.

Why? That is just what this patch in this thread is doing, :-)

>
>>> I found simple alternative solution that assigns the offline CPUs
>>> unique ctx->index_hw.
>>
>> This solution looks simpler, but it may not be correct.
>
> You are right.  This solution needs amendments, just in case we needs
> to come back this solution instead of the first approach.
>
>>> diff --git a/block/blk-mq.c b/block/blk-mq.c
>>> index 594eea0..a8fcfbf 100644
>>> --- a/block/blk-mq.c
>>> +++ b/block/blk-mq.c
>>> @@ -1787,10 +1787,11 @@ static void blk_mq_map_swqueue(struct
>>> request_queue *q)
>>>  */
>>> queue_for_each_ctx(q, ctx, i) {
>>> /* If the cpu isn't online, the cpu is mapped to first hctx 
>>> */
>>> -   if (!cpu_online(i))
>>> -   continue;
>>> +   if (!cpu_online(i) && cpu_possible(i))
>>
>> The cpu_possible() check isn't needed.
>
> OK.
>
>>> +   hctx = q->mq_ops->map_queue(q, 0);
>>> +   else
>>> +   hctx = q->mq_ops->map_queue(q, i);
>>
>> The above change supposes that all offline CPUs(ctxs)
>> share the same 'hctx' mapped from CPU 0, and that is
>> obvious wrong.
>>
>> All offline CPUs should have shared the 1st 'hctx' instead
>> of the 'hctx' mapped from CPU 0.
>
> Do you mean that we shoud use 'q->queue_hw_ctx[0]' for offline CPU?

Yes, it is the 1st hctx, but I don't think it is good idea to add the unmapped
ctx into the 1st hctx because it may bring side effects.

>
>>>
>>> -   hctx = q->mq_ops->map_queue(q, i);
>>> cpumask_set_cpu(i, hctx->cpumask);
>>
>> CPU i shouldn't have been set on hctx->cpumask in this approach
>> if it isn't online.
>
> OK.
>
>>>ctx->index_hw = hctx->nr_ctx;
>>>hctx->ctxs[hctx->nr_ctx++] = ctx;
>>
>> I am not sure the current code is ready about adding offline 'ctx' into
>> 'hctx', and there are some observalbe effects at least:
>>
>> - blk_mq_run_hw_queue() can run even the hctx hasn't mapped
>> 'ctx'
>
> Is this fixed by not setting hctx->cpumask for offline CPUs?
>
>> - the offline ctx kobject will be exposed to user space in sysfs
>
> OK.  this should be avoided.
>
>> - blk_mq_hw_queue_mapped() may becomes always true
>> - set->tags[i](request entries) may not be freed even if there
>> aren't mapped 'ctx' in one 'hctx'
>
> Aren't these only happend for the 1st hctx (i.e. 'q->queue_hw

[PATCH] clockevents/drivers/timer-stm32: Improve dependencies of timer-stm32

[Maxime Coquelin]

This patch improves the build coverage with COMPILE_TEST so it is not only
limited to ARM builds.

The fix consists in making the STM32 timer depend on GENERIC_CLOCKEVENTS.

Reported-by: kbuild test robot 
Cc: Paul Gortmaker 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Signed-off-by: Maxime Coquelin 
---
 drivers/clocksource/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 32164ba..1778c90 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -112,8 +112,8 @@ config CLKSRC_LPC32XX
select CLKSRC_OF
 
 config CLKSRC_STM32
-   bool "Clocksource for STM32 SoCs" if !ARCH_STM32
-   depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
+   bool "Clocksource for STM32 SoCs" if COMPILE_TEST
+   depends on OF && GENERIC_CLOCKEVENTS
select CLKSRC_MMIO
 
 config ARM_ARCH_TIMER
-- 
1.9.1

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

Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation

[Archit Taneja]

Hi,

On 06/30/2015 02:01 PM, Benjamin Gaignard wrote:

Hi,

I think that what have been done by Rob with module_param is also a good idea:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934

Can you mix compilation flag and module param ?


I guess this won't be hard to do once we have a common fbdev emulation 
config option. We could consider this as a drm top level module param.


I'll keep this in mind.

Thanks,
Archit



Benjamin

2015-06-30 9:56 GMT+02:00 Archit Taneja :

Hi,

On 06/30/2015 12:40 PM, Daniel Vetter wrote:


Any updates on this or too much distractions? I really think doing
this would be awesome for the drm subsystem, instead of reinventing
this wheel for each driver.



I'd started on this again. I've got more free time now than before, so I
should have something in a week or so. I agree it will help a lot (there are
already two new drivers since we started discussing this!)

Archit



-Daniel

On Wed, Mar 25, 2015 at 10:21 AM, Daniel Vetter  wrote:


On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote:


Hi,

On 03/13/2015 02:36 PM, Daniel Vetter wrote:


On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:




On 03/11/2015 08:47 PM, Daniel Vetter wrote:


On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:




On 03/10/2015 05:47 PM, Daniel Vetter wrote:


On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:


On 03/10/2015 03:35 PM, Daniel Vetter wrote:


On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:


On 03/10/2015 03:17 PM, Daniel Vetter wrote:


On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:


diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..38f83a0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
 help
   FBDEV helpers for KMS drivers.

+config DRM_FBDEV_EMULATION
+   bool "Enable legacy fbdev support for your modesetting
driver"
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_KMS_FB_HELPER
+   select FB_SYS_FILLRECT
+   select FB_SYS_COPYAREA
+   select FB_SYS_IMAGEBLIT
+   select FB_SYS_FOPS
+   select FB_CFB_FILLRECT
+   select FB_CFB_COPYAREA
+   select FB_CFB_IMAGEBLIT
+   default y
+   help
+ Choose this option if you have a need for the legacy
fbdev
+ support. Note that this support also provide the linux
console
+ support on top of your modesetting driver.



Maybe clarify that for linux console support you also need
CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.



DRM_KMS_FB_HELPER selects that for us, right?



Hm right I've missed that. Reminds me that you need one more
patch at the
end to remove all the various select DRM_KMS_FB_HELPER from all
drm
drivers. Otherwise this knob here won't work by default if you
e.g. select
radeon. In general we can't mix explicit options with menu
entries with a
select.



I was trying that out. Removing DRM_KMS_FB_HELPER and having
DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff
internally in
their respective xyz_fbdev.c files.



But with the stubbed out functions that should work, right? Why
doesn't
it?



There are still calls to functions from fb core like fb_set_suspend
and
register_framebuffer which aren't covered by the drm fb helper
functions.



Hm, sounds like we need another patch to stub out fb_set_suspend when
fbdev isn't enabled. Is there anything else?



There are a handful of fb core functions which are called by drm
drivers:

fb_alloc_cmap/fb_dealloc_cmap

fb_sys_read/fb_sys_write

register_framebuffer/unregister_framebuffer/unlink_framebuffer/
remove_conflicting_framebuffers

fb_set_suspend

fb_deferred_io_init/fb_deferred_io_cleanup

framebuffer_alloc/framebuffer_release



Hm yeah that's somewhat annoying indeed. What about the following:
1. We move all the #include  from drivers into
drm_fb_helper.h

2. Then we add stubs for these functions in drm_fb_helper.h, like this

#if defined(CONFIG_FB)
#include 
#else

/* static inline stubs for all the fb stuff used by kms drivers */
#endif

Imo this makes sense since kms drivers really have a bit a special
situation with fbdev. They're not full-blown fbdev drivers and can be
useful fully without fbdev.



I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs
won't really work because struct declarations(like fb_info) also get
removed.

I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h
itself,
but that seemed a bit too intrusive.

This is what I'm currently doing:

- Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap
would
actually benefit if we have drm fb helpers for them. They are used in
exactly the same manner by all the drivers.

- For the rest of the functions that are sparsely used, I was
considering
making very simple drm_fb_* wrapper functions. Something like:

void drm_fb_helper_deferred_io_init(s

Re: [PATCH] arm64: dts: mt8173: add clock_null

[James Liao]

On Wed, 2015-06-24 at 12:24 +0200, Heiko Stübner wrote:
> Am Mittwoch, 24. Juni 2015, 15:54:15 schrieb James Liao:
> > On Mon, 2015-06-22 at 14:53 +0200, Heiko Stübner wrote:
> > > Am Montag, 22. Juni 2015, 11:38:37 schrieb James Liao:
> > > > On Fri, 2015-06-19 at 13:36 +0200, Heiko Stuebner wrote:
> > > > Some clocks such as clkph_mck_o, we don't really care where they come
> > > > from and what frequencies are. We model these clocks just because they
> > > > or their derived clocks can be the source of topckgen muxes. Is there a
> > > > better way to model "don't care" clocks?
> > > 
> > > There are two different concepts at work here. You might not care in your
> > > kernel driver implementation _at the moment_ where the clocks come from;
> > > but the devicetree is supposed to model how the hardware is structured
> > > and not contain implementation specific details.
> > 
> > If we model "don't care" clocks inside the driver (i.e. create clk_null
> > in clock driver), then we don't need to model the dummy clock in device.
> > Is it an acceptable way?
> > 
> > > So the clock tree should be modeled according to how the hardware is layed
> > > out not how you want to use the clocks at the moment :-) .
> > > 
> > > It would it any case be good, if you could describe where these clocks
> > > come
> > > from in the hardware, so we can find the best solution on how to model
> > > those.
> > In fact, I don't know where these clocks come from at all, especially
> > when they come from outside of SoC. Besides, some clocks don't need to
> > model in CCF, but they can be the source of clocks that controlled by
> > CCF.
> 
> If a clock is used inside the ccf driver, its tree should be modeled 
> according 
> to the hardware - including these external clocks. Somebody (at least some 
> chip designer or so) should know where these clocks actually come from ;-) .
> 
> 
> > I don't think ALL clocks on a SoC need to be handled in CCF, so there
> > should be some clocks don't have a "real" or "correct" parent. In
> > current implementation I use a dummy clock (clk_null) to be the unreal
> > parent.
> 
> You are right that not all clocks needs to be implemented in a ccf _driver_, 
> but as the devicetree binding describes the hardware and is supposed to be 
> stable and (nearly) unchangeable outside-connections of the clock block need 
> to be defined carefully.
> 
> 
> > Do you think we should model as more clocks as we can in CCF even we
> > don't need them? If no, how do we handle those clocks which are not
> > handled in CCF but can be parent of CCF clocks?
> 
> In general I think everything that has a connection to the outside (external 
> source clock and clocks used by soc ips) should be modeled precisely. What 
> then happens inside the clock controller is less important, as it normally 
> can 
> be fixed later on too.
> 
> 
> Citing my own code [which got inspired on how Samsung did this], Rockchip 
> clock controllers also have numerous possible external clock inputs with only 
> the 24MHz oscillator being required [0].
> 
> All the other clocks may or may not be present. For example xin32k normally 
> comes from an i2c-connected rtc or pmic chip which gets probed a lot later in 
> the boot process, so we rely on the orphan-handling of the ccf for these.
> 
> 
> So please really try to find out what these clocks are in the first place ... 
> somebody must know this ;-)
> 
> 
> Heiko
> 
> 
> [0] 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt#n26

Hi Heiko,

There are 4 clocks which are derived from clk_null directly in current
topckgen implementation:

clkph_mck_o, dpi_ck, usb_syspll_125m, hdmitx_dig_cts

Our designer mentioned 2 things about external clocks:

1. These 4 clocks come from analog macro, not from PLL, nor from
external clocks directly.

2. MT8173 only has 2 external clocks: 26M and 32K.

Analog macro may refer to 26M or other clocks to generate clocks with
specified frequency. But we don't know and don't care how they generate
these clocks. So we want to use a dummy clock to be the root of these 4
clocks.


Hi Sascha,

Do you have any suggestion on clk_null?


Best regards,

James


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

Re: [PATCH 24/51] writeback, blkcg: associate each blkcg_gq with the corresponding bdi_writeback_congested

[Jan Kara]

On Fri 22-05-15 17:13:38, Tejun Heo wrote:
> A blkg (blkcg_gq) can be congested and decongested independently from
> other blkgs on the same request_queue.  Accordingly, for cgroup
> writeback support, the congestion status at bdi (backing_dev_info)
> should be split and updated separately from matching blkg's.
> 
> This patch prepares by adding blkg->wb_congested and associating a
> blkg with its matching per-blkcg bdi_writeback_congested on creation.
> 
> v2: Updated to associate bdi_writeback_congested instead of
> bdi_writeback.
> 
> Signed-off-by: Tejun Heo 
> Cc: Jens Axboe 
> Cc: Jan Kara 
> Cc: Vivek Goyal 

Looks good to me. You can add:

Reviewed-by: Jan Kara 

> ---
>  block/blk-cgroup.c | 17 +++--
>  include/linux/blk-cgroup.h |  6 ++
>  2 files changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
> index 979cfdb..31610ae 100644
> --- a/block/blk-cgroup.c
> +++ b/block/blk-cgroup.c
> @@ -182,6 +182,7 @@ static struct blkcg_gq *blkg_create(struct blkcg *blkcg,
>   struct blkcg_gq *new_blkg)
>  {
>   struct blkcg_gq *blkg;
> + struct bdi_writeback_congested *wb_congested;
>   int i, ret;
>  
>   WARN_ON_ONCE(!rcu_read_lock_held());
> @@ -193,22 +194,30 @@ static struct blkcg_gq *blkg_create(struct blkcg *blkcg,
>   goto err_free_blkg;
>   }
>  
> + wb_congested = wb_congested_get_create(&q->backing_dev_info,
> +blkcg->css.id, GFP_ATOMIC);
> + if (!wb_congested) {
> + ret = -ENOMEM;
> + goto err_put_css;
> + }
> +
>   /* allocate */
>   if (!new_blkg) {
>   new_blkg = blkg_alloc(blkcg, q, GFP_ATOMIC);
>   if (unlikely(!new_blkg)) {
>   ret = -ENOMEM;
> - goto err_put_css;
> + goto err_put_congested;
>   }
>   }
>   blkg = new_blkg;
> + blkg->wb_congested = wb_congested;
>  
>   /* link parent */
>   if (blkcg_parent(blkcg)) {
>   blkg->parent = __blkg_lookup(blkcg_parent(blkcg), q, false);
>   if (WARN_ON_ONCE(!blkg->parent)) {
>   ret = -EINVAL;
> - goto err_put_css;
> + goto err_put_congested;
>   }
>   blkg_get(blkg->parent);
>   }
> @@ -245,6 +254,8 @@ static struct blkcg_gq *blkg_create(struct blkcg *blkcg,
>   blkg_put(blkg);
>   return ERR_PTR(ret);
>  
> +err_put_congested:
> + wb_congested_put(wb_congested);
>  err_put_css:
>   css_put(&blkcg->css);
>  err_free_blkg:
> @@ -391,6 +402,8 @@ void __blkg_release_rcu(struct rcu_head *rcu_head)
>   if (blkg->parent)
>   blkg_put(blkg->parent);
>  
> + wb_congested_put(blkg->wb_congested);
> +
>   blkg_free(blkg);
>  }
>  EXPORT_SYMBOL_GPL(__blkg_release_rcu);
> diff --git a/include/linux/blk-cgroup.h b/include/linux/blk-cgroup.h
> index 3033eb1..07a32b8 100644
> --- a/include/linux/blk-cgroup.h
> +++ b/include/linux/blk-cgroup.h
> @@ -99,6 +99,12 @@ struct blkcg_gq {
>   struct hlist_node   blkcg_node;
>   struct blkcg*blkcg;
>  
> + /*
> +  * Each blkg gets congested separately and the congestion state is
> +  * propagated to the matching bdi_writeback_congested.
> +  */
> + struct bdi_writeback_congested  *wb_congested;
> +
>   /* all non-root blkcg_gq's are guaranteed to have access to parent */
>   struct blkcg_gq *parent;
>  
> -- 
> 2.4.0
> 
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 2/2] schedstat: Expose /proc/pid/schedstat if CONFIG_SCHED_INFO is set

[Naveen N. Rao]

In the unlikely scenario that the kernel is booted with nodelayacct, we
dump all zeroes so as to make it clear that scheduler statistics are not
available.

Signed-off-by: Naveen N. Rao 
---
Changes since v2: Revert to unsigned long in printf


 fs/proc/base.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 286a422..ad63fa3 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -304,14 +304,17 @@ static int proc_pid_stack(struct seq_file *m, struct 
pid_namespace *ns,
 }
 #endif
 
-#ifdef CONFIG_SCHEDSTATS
+#ifdef CONFIG_SCHED_INFO
 /*
  * Provides /proc/PID/schedstat
  */
 static int proc_pid_schedstat(struct seq_file *m, struct pid_namespace *ns,
  struct pid *pid, struct task_struct *task)
 {
-   seq_printf(m, "%llu %llu %lu\n",
+   if (unlikely(!sched_info_on()))
+   seq_printf(m, "0 0 0\n");
+   else
+   seq_printf(m, "%llu %llu %lu\n",
   (unsigned long long)task->se.sum_exec_runtime,
   (unsigned long long)task->sched_info.run_delay,
   task->sched_info.pcount);
@@ -2600,7 +2603,7 @@ static const struct pid_entry tgid_base_stuff[] = {
 #ifdef CONFIG_STACKTRACE
ONE("stack",  S_IRUSR, proc_pid_stack),
 #endif
-#ifdef CONFIG_SCHEDSTATS
+#ifdef CONFIG_SCHED_INFO
ONE("schedstat",  S_IRUGO, proc_pid_schedstat),
 #endif
 #ifdef CONFIG_LATENCYTOP
@@ -2948,7 +2951,7 @@ static const struct pid_entry tid_base_stuff[] = {
 #ifdef CONFIG_STACKTRACE
ONE("stack",  S_IRUSR, proc_pid_stack),
 #endif
-#ifdef CONFIG_SCHEDSTATS
+#ifdef CONFIG_SCHED_INFO
ONE("schedstat", S_IRUGO, proc_pid_schedstat),
 #endif
 #ifdef CONFIG_LATENCYTOP
-- 
2.4.0

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

Re: [PATCH 1/1] perf: Fixed indentation errors in Core.py

[Philipp Trommler]

Hi!

This is just a short reminder for the patch I sent a few weeks ago. As
it's just a really small change I'd like to ask if someone could review
it, so either I have the chance to fix errors or it can be applied.

Thanks in advance,
Philipp Trommler.

Am Freitag, den 05.06.2015, 11:01 +0200 schrieb Philipp Trommler:
> Those errors prevented the script from running. Just changed some 
> tabs to
> spaces.
> 
> Signed-off-by: Philipp Trommler <
> philipp.tromm...@mailbox.tu-dresden.de>
> ---
>  .../python/Perf-Trace-Util/lib/Perf/Trace/Core.py  | 28 +++-
> --
>  1 file changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/tools/perf/scripts/python/Perf-Trace
> -Util/lib/Perf/Trace/Core.py b/tools/perf/scripts/python/Perf-Trace
> -Util/lib/Perf/Trace/Core.py
> index 38dfb72..b4a3857 100644
> --- a/tools/perf/scripts/python/Perf-Trace
> -Util/lib/Perf/Trace/Core.py
> +++ b/tools/perf/scripts/python/Perf-Trace
> -Util/lib/Perf/Trace/Core.py
> @@ -31,7 +31,7 @@ def flag_str(event_name, field_name, value):
>  string = ""
> 
>  if flag_fields[event_name][field_name]:
> - print_delim = 0
> +print_delim = 0
>  keys = flag_fields[event_name][field_name]['values'].keys()
>  keys.sort()
>  for idx in keys:
> @@ -55,10 +55,10 @@ def symbol_str(event_name, field_name, value):
>  keys.sort()
>  for idx in keys:
>  if not value and not idx:
> - string = 
> symbolic_fields[event_name][field_name]['values'][idx]
> +string = 
> symbolic_fields[event_name][field_name]['values'][idx]
>  break
> - if (value == idx):
> - string = 
> symbolic_fields[event_name][field_name]['values'][idx]
> +if (value == idx):
> +string = 
> symbolic_fields[event_name][field_name]['values'][idx]
>  break
> 
>  return string
> @@ -77,16 +77,16 @@ def trace_flag_str(value):
>  keys = trace_flags.keys()
> 
>  for idx in keys:
> - if not value and not idx:
> - string += "NONE"
> - break
> -
> - if idx and (value & idx) == idx:
> - if print_delim:
> - string += " | ";
> - string += trace_flags[idx]
> - print_delim = 1
> - value &= ~idx
> +if not value and not idx:
> +string += "NONE"
> +break
> +
> +if idx and (value & idx) == idx:
> +if print_delim:
> +string += " | ";
> +string += trace_flags[idx]
> +print_delim = 1
> +value &= ~idx
> 
>  return string
> 
> --
> 2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clockevents/drivers/timer-stm32: Improve dependencies of timer-stm32

[Daniel Lezcano]

On 06/30/2015 11:06 AM, Maxime Coquelin wrote:

This patch improves the build coverage with COMPILE_TEST so it is not only
limited to ARM builds.

The fix consists in making the STM32 timer depend on GENERIC_CLOCKEVENTS.

Reported-by: kbuild test robot 
Cc: Paul Gortmaker 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Signed-off-by: Maxime Coquelin 


Applied, thanks !

  -- Daniel

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

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

Re: [RESEND PATCH 1/2] pinctrl: change function behavior for per pin muxing controllers

[Nicolas Ferre]

Le 17/06/2015 17:55, Stephen Warren a écrit :
> On 06/17/2015 06:38 AM, Ludovic Desroches wrote:

[..]

>> I have sent patches months ago trying to improve things by having
>> something more flexible. I don't think I introduce too big changes.
>> The only answers I got were from people thinking that pinctrl framework
>> conception is not good to fit all kind of controllers. I re-sent the
>> patch series to gain more expose and have no  answer...
> 
> I don't see anything in your description which implies pinctrl isn't 
> perfectly suitable for your HW.

We are not talking about suitability, we are talking about some little
changes to the generic part, just to have more accurate information and
a little bit more flexibility with our controller.

We read the drivers that Stephen pointed out and it seems that it even
doesn't use the whole generic part of the pinconf. Moreover, we do think
that the statement "one pin" == "one group" leads to a loss of
information and ease of use.
We are not talking about the use of defines, tables, macros to reach an
usable pinctrl: let's say that we have different views.

> Note that I'm on vacation for a couple weeks soon, and I don't expect to 
> follow this conversation during that time. Ultimately, LinusW owns the 
> pinctrl subsystem, and you need to convince him of any changes.

Okay, so we are back at the same situation we had ended up with several
months ago:

- no agreement on 3 points:
1/ ways to use groups in generic pinctrl
2/ ways to describe a comprehensive configuration in device tree
3/ readability of a sysfs information

- no way out on the generic pinctrl little changes that Ludovic proposed
as Linus W. never gave his point of view (RFC posts on April the 2nd).

Ludovic explained at length our point of view and gave detailed
technical arguments. We don't intend to convince you, we just would like
the harmless modifications to be integrated.

As we preferred to give a chance to the generic pinconf/pinctrl for our
use by adding a little bit of flexibility, we are now in a situation
where we are nearly obliged to give up this approach and write a new
driver without the use of the generic facilities: what a pity!
We lost several months of useless work to match what we thought the
maintainer would prefer.

So Linus, do you confirm that we won't go further with this approach?

We are pretty disappointed by the way this interaction with the pinctrl
sub-system went.

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

Re: [PATCH 01/41] clocksource: asm9260: Migrate to new 'set-state' interface

[Daniel Lezcano]

On 06/30/2015 11:00 AM, Viresh Kumar wrote:

On 30-06-15, 10:25, Daniel Lezcano wrote:

Could you add in the changelog the subtle change with
set_mode(RESUME) and this code. As a default the timer was stopped
when entering in the set_mode function, now with the new API, this
is done explicitly.



Can you replace this line with a call to asm9260_timer_shutdown ?


How does this look ?


Looks good to me.


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

Re: [PATCH 21/51] bdi: separate out congested state into a separate struct

[Jan Kara]

On Fri 22-05-15 17:13:35, Tejun Heo wrote:
> Currently, a wb's (bdi_writeback) congestion state is carried in its
> ->state field; however, cgroup writeback support will require multiple
> wb's sharing the same congestion state.  This patch separates out
> congestion state into its own struct - struct bdi_writeback_congested.
> A new field wb field, wb_congested, points to its associated congested
> struct.  The default wb, bdi->wb, always points to bdi->wb_congested.
> 
> While this patch adds a layer of indirection, it doesn't introduce any
> behavior changes.
> 
> Signed-off-by: Tejun Heo 

Looks good. You can add:

Reviewed-by: Jan Kara 

Honza

> ---
>  include/linux/backing-dev-defs.h | 14 --
>  include/linux/backing-dev.h  |  2 +-
>  mm/backing-dev.c |  7 +--
>  3 files changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/backing-dev-defs.h 
> b/include/linux/backing-dev-defs.h
> index aa18c4b..9e9eafa 100644
> --- a/include/linux/backing-dev-defs.h
> +++ b/include/linux/backing-dev-defs.h
> @@ -16,12 +16,15 @@ struct dentry;
>   * Bits in bdi_writeback.state
>   */
>  enum wb_state {
> - WB_async_congested, /* The async (write) queue is getting full */
> - WB_sync_congested,  /* The sync queue is getting full */
>   WB_registered,  /* bdi_register() was done */
>   WB_writeback_running,   /* Writeback is in progress */
>  };
>  
> +enum wb_congested_state {
> + WB_async_congested, /* The async (write) queue is getting full */
> + WB_sync_congested,  /* The sync queue is getting full */
> +};
> +
>  typedef int (congested_fn)(void *, int);
>  
>  enum wb_stat_item {
> @@ -34,6 +37,10 @@ enum wb_stat_item {
>  
>  #define WB_STAT_BATCH (8*(1+ilog2(nr_cpu_ids)))
>  
> +struct bdi_writeback_congested {
> + unsigned long state;/* WB_[a]sync_congested flags */
> +};
> +
>  struct bdi_writeback {
>   struct backing_dev_info *bdi;   /* our parent bdi */
>  
> @@ -48,6 +55,8 @@ struct bdi_writeback {
>  
>   struct percpu_counter stat[NR_WB_STAT_ITEMS];
>  
> + struct bdi_writeback_congested *congested;
> +
>   unsigned long bw_time_stamp;/* last time write bw is updated */
>   unsigned long dirtied_stamp;
>   unsigned long written_stamp;/* pages written at bw_time_stamp */
> @@ -84,6 +93,7 @@ struct backing_dev_info {
>   unsigned int max_ratio, max_prop_frac;
>  
>   struct bdi_writeback wb;  /* default writeback info for this bdi */
> + struct bdi_writeback_congested wb_congested;
>  
>   struct device *dev;
>  
> diff --git a/include/linux/backing-dev.h b/include/linux/backing-dev.h
> index 7857820..bfdaa18 100644
> --- a/include/linux/backing-dev.h
> +++ b/include/linux/backing-dev.h
> @@ -167,7 +167,7 @@ static inline int bdi_congested(struct backing_dev_info 
> *bdi, int bdi_bits)
>  {
>   if (bdi->congested_fn)
>   return bdi->congested_fn(bdi->congested_data, bdi_bits);
> - return (bdi->wb.state & bdi_bits);
> + return (bdi->wb.congested->state & bdi_bits);
>  }
>  
>  static inline int bdi_read_congested(struct backing_dev_info *bdi)
> diff --git a/mm/backing-dev.c b/mm/backing-dev.c
> index 805b287..5ec7658 100644
> --- a/mm/backing-dev.c
> +++ b/mm/backing-dev.c
> @@ -383,6 +383,9 @@ int bdi_init(struct backing_dev_info *bdi)
>   if (err)
>   return err;
>  
> + bdi->wb_congested.state = 0;
> + bdi->wb.congested = &bdi->wb_congested;
> +
>   return 0;
>  }
>  EXPORT_SYMBOL(bdi_init);
> @@ -504,7 +507,7 @@ void clear_bdi_congested(struct backing_dev_info *bdi, 
> int sync)
>   wait_queue_head_t *wqh = &congestion_wqh[sync];
>  
>   bit = sync ? WB_sync_congested : WB_async_congested;
> - if (test_and_clear_bit(bit, &bdi->wb.state))
> + if (test_and_clear_bit(bit, &bdi->wb.congested->state))
>   atomic_dec(&nr_bdi_congested[sync]);
>   smp_mb__after_atomic();
>   if (waitqueue_active(wqh))
> @@ -517,7 +520,7 @@ void set_bdi_congested(struct backing_dev_info *bdi, int 
> sync)
>   enum wb_state bit;
>  
>   bit = sync ? WB_sync_congested : WB_async_congested;
> - if (!test_and_set_bit(bit, &bdi->wb.state))
> + if (!test_and_set_bit(bit, &bdi->wb.congested->state))
>   atomic_inc(&nr_bdi_congested[sync]);
>  }
>  EXPORT_SYMBOL(set_bdi_congested);
> -- 
> 2.4.0
> 
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: n900 in 4.2-rc0: repeating oopses

[Pavel Machek]

Hi!

> Just tried booting 4.2-rc0 on n900 (commit
> 4a10a91756ef381bced7b88cfb9232f660b92d93) and it is broken. Previous
> -rc0 version worked. This time, there's some output on console, but
> too fast for me to read.
> 
> It seems oopses happen before mounting root. If you have serial
> console, they should be easy to see.

I tried again according to pali's instructions, and it is still
broken the same way. Any other ideas? Does it work for you?

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 69a40cf..ff6f2bf 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -570,6 +570,7 @@
interrupts = <49>;
dmas = <&sdma 69>;
dma-names = "rx";
+   status = "disabled";
};
 
smartreflex_core: smartreflex@480cb000 {

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

4.2-rc0: akcipher breaks compilation

[Pavel Machek]

Hi!

CC  crypto/akcipher.o
CC  block/bio.o
crypto/akcipher.c: In function ‘crypto_akcipher_report’:
crypto/akcipher.c:30:32: error: storage size of ‘rakcipher’ isn’t
known
  struct crypto_report_akcipher rakcipher;
  ^
  crypto/akcipher.c:34:19: error:
‘CRYPTOCFGA_REPORT_AKCIPHER’ undeclared (first use in this
function)
  if (nla_put(skb, CRYPTOCFGA_REPORT_AKCIPHER,
 ^
 crypto/akcipher.c:34:19: note: each
undeclared identifier is reported only once for each function it
appears in
crypto/akcipher.c:35:14: error: invalid application of ‘sizeof’ to
incomplete type ‘struct crypto_report_akcipher’
   sizeof(struct crypto_report_akcipher), &rakcipher))
 ^
 crypto/akcipher.c:30:32: warning: unused
variable ‘rakcipher’ [-Wunused-variable]
  struct crypto_report_akcipher rakcipher;
  ^
  scripts/Makefile.build:258:
recipe for target 'crypto/akcipher.o' failed
make[1]: *** [crypto/akcipher.o] Error 1
Makefile:945: recipe for target 'crypto' failed
make: *** [crypto] Error 2
make: *** Waiting for unfinished jobs

Plus... it is not easy to disable akcipher due to "interesting"
Kconfig with select maze...
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v2 PATCH 2/8] mm: introduce MIGRATE_MIRROR to manage the mirrored pages

[Xishi Qiu]

On 2015/6/30 15:53, Kamezawa Hiroyuki wrote:

> On 2015/06/30 11:45, Xishi Qiu wrote:
>> On 2015/6/29 15:32, Kamezawa Hiroyuki wrote:
>>
>>> On 2015/06/27 11:24, Xishi Qiu wrote:
 This patch introduces a new migratetype called "MIGRATE_MIRROR", it is 
 used to
 allocate mirrored pages.
 When cat /proc/pagetypeinfo, you can see the count of free mirrored blocks.

 Signed-off-by: Xishi Qiu 
>>>
>>> My fear about this approarch is that this may break something existing.
>>>
>>> Now, when we add MIGRATE_MIRROR type, we'll hide attributes of pageblocks as
>>> MIGRATE_UNMOVABOLE, MIGRATE_RECLAIMABLE, MIGRATE_MOVABLE.
>>>
>>> Logically, MIRROR attribute is independent from page mobility and this 
>>> overwrites
>>> will make some information lost.
>>>
>>> Then,
>>>
 ---
include/linux/mmzone.h | 9 +
mm/page_alloc.c| 3 +++
mm/vmstat.c| 3 +++
3 files changed, 15 insertions(+)

 diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
 index 54d74f6..54e891a 100644
 --- a/include/linux/mmzone.h
 +++ b/include/linux/mmzone.h
 @@ -39,6 +39,9 @@ enum {
MIGRATE_UNMOVABLE,
MIGRATE_RECLAIMABLE,
MIGRATE_MOVABLE,
 +#ifdef CONFIG_MEMORY_MIRROR
 +MIGRATE_MIRROR,
 +#endif
>>>
>>> I think
>>>  MIGRATE_MIRROR_UNMOVABLE,
>>>  MIGRATE_MIRROR_RECLAIMABLE,
>>>  MIGRATE_MIRROR_MOVABLE, <== adding this may need discuss.
>>>  MIGRATE_MIRROR_RESERVED,<== reserved pages should be 
>>> maintained per mirrored/unmirrored.
>>>
>>
>> Hi Kame,
>>
>> You mean add 3 or 4 new migratetype?
>>
> 
> yes. But please check how NR_MIGRATETYPE_BITS will be.
> I think this will not have big impact in x86-64 .
> 
>>> should be added with the following fallback list.
>>>
>>> /*
>>>   * MIRROR page range is defined by firmware at boot. The range is limited
>>>   * and is used only for kernel memory mirroring.
>>>   */
>>> [MIGRATE_UNMOVABLE_MIRROR]   = {MIGRATE_RECLAIMABLE_MIRROR, MIGRATE_RESERVE}
>>> [MIGRATE_RECLAIMABLE_MIRROR] = {MIGRATE_UNMOVABLE_MIRROR, MIGRATE_RESERVE}
>>>
>>
>> Why not like this:
>> {MIGRATE_RECLAIMABLE_MIRROR, MIGRATE_MIRROR_RESERVED, MIGRATE_RESERVE}
>>
> 
>  My mistake.
> [MIGRATE_UNMOVABLE_MIRROR]   = {MIGRATE_RECLAIMABLE_MIRROR, 
> MIGRATE_RESERVE_MIRROR}
> [MIGRATE_RECLAIMABLE_MIRROR] = {MIGRATE_UNMOVABLE_MIRROR, 
> MIGRATE_RESERVE_MIRROR}
> 
> was my intention. This means mirrored memory and unmirrored memory is 
> separated completely.
> 
> But this should affect kswapd or other memory reclaim logic.
> 
> for example, kswapd stops free pages are more than hi watermark.
> But mirrored/unmirrored pages exhausted cases are not handled in this series.
> You need some extra check in memory reclaim logic if you go with 
> migration_type.
> 

OK, I understand. Thank you for your suggestion.

Thanks,
Xishi Qiu

> 
> 
>>> Then, we'll not lose the original information of "Reclaiable Pages".
>>>
>>> One problem here is whteher we should have MIGRATE_RESERVE_MIRROR.
>>>
>>> If we never allow users to allocate mirrored memory, we should have 
>>> MIGRATE_RESERVE_MIRROR.
>>> But it seems to require much more code change to do that.
>>>
>>> Creating a zone or adding an attribues to zones are another design choice.
>>>
>>
>> If we add a new zone, mirror_zone will span others, I'm worry about this
>> maybe have problems.
> 
> Yes. that's problem. And zoneid bit is very limited resource.
> (But memory reclaim logic can be unchanged.)
> 
> Anyway, I'd like to see your solution with above changes 1st rather than 
> adding zones.
> 
> Thanks,
> -Kame
> 
> 
> 
> .
> 



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

Re: [PATCH 1/1] cputime: Make the reported utime+stime correspond to the actual runtime.

[Peter Zijlstra]

On Mon, Jun 29, 2015 at 05:28:42PM +0200, Fredrik Markström wrote:
> Hello Peter, the locking part looks good, I don't have a strong
> opinion on per task/signal lock vs global lock.
>
> But with the patch we still update prev->utime and prev->stime
> independently, which was the original problem.

Ah,..

> > @@ -609,19 +593,19 @@ static void cputime_adjust(struct task_cputime *curr,
> > } else if (stime == 0) {
> > utime = rtime;
> > } else {
> > +   stime = scale_stime((__force u64)stime, (__force u64)rtime,
> > +   (__force u64)(stime + utime));
> > +   if (stime < prev->stime)
> > +   stime = prev->stime;
> > utime = rtime - stime;
> > }
> >
> > +   prev->stime = max(prev->stime, stime);
> > +   prev->utime = max(prev->utime, utime);
> >  out:
> > *ut = prev->utime;
> > *st = prev->stime;
> > +   raw_spin_unlock(&prev->lock);
> >  }

So the things we want from this function is that:

 - stime + utime == rtime
 - stime_i+1 >= stime_i, utime_i+1 >= utime_i

Under the assumption that rtime_i+1 >= rtime_i.

There are 3 cases:

 1) utime == 0 -> stime = rtime
 2) stime == 0 -> utime = rtime

Both these trivially meet the above conditions, and:

 3) stime_i+1 = max((stime * rtime) / (stime + utime), stime_i)
utime = rtime - stime

Which I thought would meet them because we keep stime from shrinking and
therefore utime from growing too big. But there is indeed the other side
to consider, what if stime grows too big and makes the new utime too
small. When we update stime but not utime and break the first condition.

Now, you propose:

> +   if (stime < prev->stime) {
> +   stime = prev->stime;
> +   utime = rtime - stime;

Right, I have this branch, it keeps stime in check as per the above.

Since we set stime_i+1 = stime_i, utime_i+1 = rtime - stime_i >= utime_i
since rtime_i+1 >= rtime_i.

> +   } else if (utime < prev->utime) {
> +   utime = prev->utime;
> +   stime = rtime - utime;
> +   }

And that deals with the other side, similar proof.


> +   if (prev->stime + prev->utime < rtime) {
> +   prev->stime = stime;
> +   prev->utime = utime;
> +   }

This I don't really agree with, we can leave the inverse check as is and
simply bail early.

Folding this all together gives me

---
 include/linux/init_task.h | 10 ++
 include/linux/sched.h | 23 +
 kernel/fork.c |  7 ---
 kernel/sched/cputime.c| 51 ++-
 4 files changed, 53 insertions(+), 38 deletions(-)

diff --git a/include/linux/init_task.h b/include/linux/init_task.h
index bb9b075f0eb0..e38681f4912d 100644
--- a/include/linux/init_task.h
+++ b/include/linux/init_task.h
@@ -39,6 +39,14 @@ extern struct fs_struct init_fs;
 #define INIT_CPUSET_SEQ(tsk)
 #endif
 
+#ifndef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
+#define INIT_PREV_CPUTIME(x)   .prev_cputime = {   \
+   .lock = __RAW_SPIN_LOCK_UNLOCKED(x.prev_cputime.lock),  \
+},
+#else
+#define INIT_PREV_CPUTIME(x)
+#endif
+
 #define INIT_SIGNALS(sig) {\
.nr_threads = 1,\
.thread_head= LIST_HEAD_INIT(init_task.thread_node),\
@@ -53,6 +61,7 @@ extern struct fs_struct init_fs;
.cputime_atomic = INIT_CPUTIME_ATOMIC,  \
.running= 0,\
},  \
+   INIT_PREV_CPUTIME(sig)  \
.cred_guard_mutex = \
 __MUTEX_INITIALIZER(sig.cred_guard_mutex), \
INIT_GROUP_RWSEM(sig)   \
@@ -254,6 +263,7 @@ extern struct task_group root_task_group;
INIT_TASK_RCU_TASKS(tsk)\
INIT_CPUSET_SEQ(tsk)\
INIT_RT_MUTEXES(tsk)\
+   INIT_PREV_CPUTIME(tsk)  \
INIT_VTIME(tsk) \
INIT_NUMA_BALANCING(tsk)\
INIT_KASAN(tsk) \
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 6633e83e608a..5dfbe92ce04e 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -531,17 +531,28 @@ struct cpu_itimer {
 };
 
 /**
- * struct cputime - snaphsot of system and user cputime
+ * struct prev_cputime - snaphsot of system and user cputime
  * @utime: time spent in user mode
  * @stime: ti

Re: Official bugreport 4.1 kernel (audio gadget and ChipIdea)

[Marek Vasut]

On Tuesday, June 30, 2015 at 04:23:01 AM, Peter Chen wrote:
> On Fri, Jun 26, 2015 at 07:15:18PM +0200, Sébastien Pruvost wrote:
> > Hello,
> > 
> > I'm sending this mail to report a bug concerning the latest kernel 4.1.
> > 
> > Here is the problem (and the test I've done):
> > I have firstly used the 3.10.53 kernel for my two
> > sabrelites in
> > 
> > order to use the audio gadget driver with the Dual Role ChipIdea
> > Controller (in order to switch roles between my two IMX6 sabreLite).
> > After loading g_audio in my two sabreLite and plugging the cable (microA
> > – microB), there is an error “ci_hdrc.0 request length too big for
> > isochronous snd_uac2.0 1116 Error”.
> > And even after running aplay command, I still got this error and there is
> > no sound getting out of the jack port.
> > I've switched roles between the two boards by following this: https://
> > www.kernel.org/doc/Documentation/usb/chipidea.txt.
> > This works fine with the serial driver, I can see a new serial interface
> > (host side) and after switching role a new serial interfaces at device
> > side. Same thing for ethernet gadget: this works fine too. But not with
> > the audio gadget. In fact, there is a new audio interface at host side
> > but I can not interact with it (even alsamixer doesn’t see any controls
> > on this new sound card). I’ve tested that audio gadget works fine if I
> > don’t use ChipIdea HighSpeed Dual Role Controller.
> > 
> > Secondly I have tested this audio gadget with the latest
> > Kernel
> > 
> > 4.1 for my two IMX6 sabrelites (imx_v6_v7_defconfig). Now these previous
> > errors are gone but there are still no sound getting out of the jack
> > port (even if there are a new sound card in host side)
> 
> It is may not a role switch problem, please check if the g_audio can
> work well with an ubuntu PC (make sure your codec works well).

ci_hdrc.0 request length too big for isochronous

Doesn't this just mean it cannot transfer such a long buffer via ISO pipe ?
I guess the UAC should send smaller buffers to work with the CI HDRC?

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

[no subject]

[Western Union]

This is to re-notify you of the 300,000.00(Pounds) was deposited here in the 
western union office in your name is available for pickup. Contact this email: 
wu.onlinesu...@hotmail.com for your M.T.C.N Numbers. 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] perf tools: Add hugetlbfs memory recognition

[Hou Pengyang]

On 2015/6/29 21:42, Arnaldo Carvalho de Melo wrote:

Em Mon, Jun 29, 2015 at 10:23:29AM -0300, Arnaldo Carvalho de Melo escreveu:

Em Sat, Jun 27, 2015 at 05:08:20PM +0800, Hou Pengyang escreveu:

There is something about MAP_HUGETLB.



In this patch, we check if a mmap area is hugetlbfs area by MAP_HUGETLB,
a bit in MMAP2 event.



However, if mmap area is hugetlb related, MAP_HUGETLB does not always
appear. Because, there are two ways generating MMAP2 event.



1) when a new vm_area_struct is created, its info would be exported
as a MMAP2 event.
2) perf reads /proc/pid/maps for generating MMAP2 event.



MAP_HUGETLB appears if MMAP2 event is generated on situation 1),
while not on situation 2).



This is because on situation 2), perf reads /proc/pid/maps, which
contains only PROT_READ/WRITE/EXEC, MAP_SHARED/MAP_PRIVATE, while more
details appear in /proc/pid/smaps, such as MAP_HUGETLB.


Humm:

[root@zoo ~]# wc -l /proc/`pidof firefox`/maps
934 /proc/4551/maps
[root@zoo ~]# wc -l /proc/`pidof firefox`/smaps
14944 /proc/4551/smaps
[root@zoo ~]#


So I wonder if there is a need to read /proc/pid/smaps instead of
/proc/pid/maps to generate MMAP2 event. Or we should solve the problem by
another way?


Doing some research now...


Bummer, seems that only smaps -> ... -> show_smap_vma_flags() will
expose that to userspace...

Perhaps we can look at some global stat for HugeTLB fs to figure out if
we really, really need to parse smaps instead of just maps? I.e. in my
system, a desktop one, F21, I have:



It seems no other info tell us if one process is using hugetlbfs.
So how about an option to tell perf explicitly which file is from
hugetlbfs, like:

./perf report --hugetlb-file=/mnt/huge/hugepagefile

So that, we can check if a mmap area is from hugetlbfs by its name
instead of MAP_HUGETLB.


[root@zoo ~]# find /proc -name smaps | xargs grep -w ht
grep: /proc/31971/task/31971/smaps: No such file or directory
grep: /proc/31971/smaps: No such file or directory
[root@zoo ~]#

No "ht" HugeTLB areas, so no need to parse 16 times more bytes than by
just using /proc/PID/maps.






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

.




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

Re: [PATCH v2 1/3] iio: magnetometer: Add support for MEMSIC MMC35240 sensor

[Daniel Baluta]

On Mon, Jun 29, 2015 at 10:17 PM, Hartmut Knaack  wrote:
> Daniel Baluta schrieb am 29.06.2015 um 09:52:
>> On Mon, Jun 29, 2015 at 2:07 AM, Hartmut Knaack  wrote:
>>> Daniel Baluta schrieb am 24.04.2015 um 17:58:
 Minimal implementation for MMC35240 3-axis magnetometer
 sensor. It provides processed readings and possiblity to change
 the sampling frequency.

>>>
>>> Hi Daniel,
>>> please find a few issues inline, which you could address in a next
>>> rework patch set. I would have sent a patch for the critical stuff,
>>> but was obviously too stupid to find a data sheet :-(
>>
>> Well, there is no public datasheet. We are discussing with the vendor
>> to make it public.
>>
> <...>
 +static int mmc35240_hw_set(struct mmc35240_data *data, bool set)
 +{
 + int ret;
 + u8 coil_bit;
 +
 + /*
 +  * Recharge the capacitor at VCAP pin, requested to be issued
 +  * before a SET/RESET command.
 +  */
 + ret = regmap_update_bits(data->regmap, MMC35240_REG_CTRL0,
 +  MMC35240_CTRL0_REFILL_BIT,
 +  MMC35240_CTRL0_REFILL_BIT);
 + if (ret < 0)
 + return ret;
 + usleep_range(MMC35240_WAIT_CHARGE_PUMP, MMC35240_WAIT_CHARGE_PUMP + 
 1);
 +
 + if (set)
 + coil_bit = MMC35240_CTRL0_SET_BIT;
 + else
 + coil_bit = MMC35240_CTRL0_RESET_BIT;
 +
 + return regmap_update_bits(data->regmap, MMC35240_REG_CTRL0,
 +   MMC35240_CTRL0_REFILL_BIT,
 +   coil_bit);
>>>
>>> coil_bit is in any case outside the mask of MMC35240_CTRL0_REFILL_BIT.
>>> Not sure about the whole intention, meaning in which state
>>> MMC35240_CTRL0_REFILL_BIT is supposed to be (set) when either
>>> MMC35240_CTRL0_SET_BIT or MMC35240_CTRL0_RESET_BIT is written.
>>
>> Yes, this is a bug. We have a patch prepared for it. Will send once Jonathan 
>> is
>> ready to accept bugfixes. Together with this:
>>
>> http://marc.info/?l=linux-iio&m=143489464403101&w=2
>>
>
> Sending it out earlier gives people more time to review (or may allow more 
> people
> to review).
>
>>
>>>
 +}
>
> <...>
 +
 +static int mmc35240_take_measurement(struct mmc35240_data *data)
 +{
 + int ret, tries = 100;
 + unsigned int reg_status;
 +
 + ret = regmap_write(data->regmap, MMC35240_REG_CTRL0,
 +MMC35240_CTRL0_TM_BIT);
 + if (ret < 0)
 + return ret;
 +
 + while (tries-- > 0) {
 + ret = regmap_read(data->regmap, MMC35240_REG_STATUS,
 +   ®_status);
 + if (ret < 0)
 + return ret;
 + if (reg_status & MMC35240_STATUS_MEAS_DONE_BIT)
 + break;
>>>
>>> I would actually return 0 here, as measurement was successful. That
>>> would mean that getting outside the loop is the error case and would
>>> make the check obsolete.
>>
>> You are right, this could also work. Anyhow, I think code is easier to
>> understand as it is. The check for (tries < 0) makes it very clear, that the
>> data was not ready.
>>
>> Getting outside the loop in the error case is harder to understand at a first
>> glance.
>>
>
> I can not really agree. The mission is accomplished at the break, so better
> take the shortest way out (return 0 usually reflects that). Still going 
> through
> a check that won't trigger in this case just adds bloat without any benefit.
> It's not a bug, so I don't feel too strong to fix it myself (still too much
> reviews to be done). Sorry for annoying with such issues, spending my 
> childhood
> with slow and low memory 8 bit machines just left a mark ;-)
>
>>>
 + msleep(20);
 + }
 +
 + if (tries < 0) {
 + dev_err(&data->client->dev, "data not ready\n");
 + return -EIO;
>>>
>>> Doesn't this qualify more for a timeout error, rather than I/O?
>>
>> Looking at the IIO drivers, most of them return EIO in such case.
>> (grep for EIO in drivers/iio/light for example)
>>
>
> I don't feel too strong about this. I just regard I/O errors as indication
> that communication with the device went wrong. But when getting here, it
> always told to be busy.

Ok, I will you have a good point for both issues. Will try to address them
in a few days.

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

Re: [RFC] COLO Proxy Module

[Patrick McHardy]

On 30.06, Li Zhijian wrote:
> |ping...
> 
> and i have another question:
> can i add a new |||nf_ct_ext_id simply without touching the exiting kernel
> code?|

No, the kernel needs to know the highest extension ID in order to
allocate space for the offsets.

> in order to support COLO-Proxy, i need a extra nf_ct_ext_id called
> "NF_CT_EXT_COLO"
> to store some message of COLO related. This message can help COLO-Proxy to
> buffer packet and compare packet for each connection.
> 
> Thanks
> Li Zhijian

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

[PATCH 1/1] dmaengine: at_xdmac: fix transfer data width in at_xdmac_prep_slave_sg()

[Cyrille Pitchen]

This patch adds a missing part in commit
6d3a7d9e3ada345948f72564ce638c412ccd8c4a:
dmaengine: at_xdmac: allow muliple dwidths when doing slave transfers

Indeed, for each item in the scatter-gather list, we check whether the
transfer length is aligned with the data width provided by
dmaengine_slave_config(). If so, we directly use this data width for the
current part of the transfer we are preparing. Otherwise, the data width
is reduced to 8 bits (1 byte). Of course, the actual number of register
accesses must also be updated to match the new data width.

So one chunk was missing in the original patch: the number of register
accesses was correctly set to (len >> fixed_dwidth) in mbr_ubc but the
real data width was not updated in mbr_cfg. Since mbr_cfg may change for
each part of the scatter-gather transfer this also explains why the
original patch used the Descriptor View 2 instead of the Descriptor
View 1.

Let's take the example of a DMA transfer to write 8bit data into an Atmel
USART with FIFOs. When FIFOs are enabled in the USART, its Transmit
Holding Register (THR) works in multidata mode, that is to say that up to
4 8bit data can be written into the THR in a single 32bit access and it is
still possible to write only one data with a 8bit access. To take
advantage of this new feature, the DMA driver was modified to allow
multiple dwidths when doing slave transfers.
For instance, when the total length is 22 bytes, the USART driver splits
the transfer into 2 parts:

First part: 20 bytes transferred through 5 32bit writes into THR
Second part: 2 bytes transferred though 2 8bit writes into THR

For the second part, the data width was first set to 4_BYTES by the USART
driver thanks to dmaengine_slave_config() then at_xdmac_prep_slave_sg()
reduces this data width to 1_BYTE because the 2 byte length is not aligned
with the original 4_BYTES data width. Since the data width is modified,
the actual number of writes into THR must be set accordingly.

Signed-off-by: Cyrille Pitchen 
---
 drivers/dma/at_xdmac.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index cf1213d..931b218 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -681,15 +681,16 @@ at_xdmac_prep_slave_sg(struct dma_chan *chan, struct 
scatterlist *sgl,
desc->lld.mbr_sa = mem;
desc->lld.mbr_da = atchan->sconfig.dst_addr;
}
-   desc->lld.mbr_cfg = atchan->cfg;
-   dwidth = at_xdmac_get_dwidth(desc->lld.mbr_cfg);
+   dwidth = at_xdmac_get_dwidth(atchan->cfg);
fixed_dwidth = IS_ALIGNED(len, 1 << dwidth)
-  ? at_xdmac_get_dwidth(desc->lld.mbr_cfg)
+  ? dwidth
   : AT_XDMAC_CC_DWIDTH_BYTE;
desc->lld.mbr_ubc = AT_XDMAC_MBR_UBC_NDV2   
/* next descriptor view */
| AT_XDMAC_MBR_UBC_NDEN 
/* next descriptor dst parameter update */
| AT_XDMAC_MBR_UBC_NSEN 
/* next descriptor src parameter update */
| (len >> fixed_dwidth);
/* microblock length */
+   desc->lld.mbr_cfg = (atchan->cfg & ~AT_XDMAC_CC_DWIDTH_MASK) |
+   AT_XDMAC_CC_DWIDTH(fixed_dwidth);
dev_dbg(chan2dev(chan),
 "%s: lld: mbr_sa=%pad, mbr_da=%pad, mbr_ubc=0x%08x\n",
 __func__, &desc->lld.mbr_sa, &desc->lld.mbr_da, 
desc->lld.mbr_ubc);
-- 
1.8.2.2

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

Re: [RFCv4 PATCH 25/34] sched: Add over-utilization/tipping point indicator

[pang . xunlei]

Hi Morten,

Morten Rasmussen  wrote 2015-05-13 AM 03:39:00:
> 
> [RFCv4 PATCH 25/34] sched: Add over-utilization/tipping point indicator
> 
> Energy-aware scheduling is only meant to be active while the system is
> _not_ over-utilized. That is, there are spare cycles available to shift
> tasks around based on their actual utilization to get a more
> energy-efficient task distribution without depriving any tasks. When
> above the tipping point task placement is done the traditional way,
> spreading the tasks across as many cpus as possible based on priority
> scaled load to preserve smp_nice.
> 
> The over-utilization condition is conservatively chosen to indicate
> over-utilization as soon as one cpu is fully utilized at it's highest
> frequency. We don't consider groups as lumping usage and capacity
> together for a group of cpus may hide the fact that one or more cpus in
> the group are over-utilized while group-siblings are partially idle. The
> tasks could be served better if moved to another group with completely
> idle cpus. This is particularly problematic if some cpus have a
> significantly reduced capacity due to RT/IRQ pressure or if the system
> has cpus of different capacity (e.g. ARM big.LITTLE).
> 
> cc: Ingo Molnar 
> cc: Peter Zijlstra 
> 
> Signed-off-by: Morten Rasmussen 
> ---
>  kernel/sched/fair.c  | 35 +++
>  kernel/sched/sched.h |  3 +++
>  2 files changed, 34 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index f36ab2f3..5b7bc28 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4266,6 +4266,8 @@ static inline void hrtick_update(struct rq *rq)
>  }
>  #endif
> 
> +static bool cpu_overutilized(int cpu);
> +
>  /*
>   * The enqueue_task method is called before nr_running is
>   * increased. Here we update the fair scheduling stats and
> @@ -4276,6 +4278,7 @@ enqueue_task_fair(struct rq *rq, struct 
> task_struct *p, int flags)
>  {
> struct cfs_rq *cfs_rq;
> struct sched_entity *se = &p->se;
> +   int task_new = !(flags & ENQUEUE_WAKEUP);
> 
> for_each_sched_entity(se) {
>if (se->on_rq)
> @@ -4310,6 +4313,9 @@ enqueue_task_fair(struct rq *rq, struct 
> task_struct *p, int flags)
> if (!se) {
>update_rq_runnable_avg(rq, rq->nr_running);
>add_nr_running(rq, 1);
> +  if (!task_new && !rq->rd->overutilized &&
> +  cpu_overutilized(rq->cpu))
> + rq->rd->overutilized = true;
> }
> hrtick_update(rq);
>  }
> @@ -4937,6 +4943,14 @@ static int find_new_capacity(struct energy_env 
*eenv,
> return idx;
>  }
> 
> +static unsigned int capacity_margin = 1280; /* ~20% margin */
> +
> +static bool cpu_overutilized(int cpu)
> +{
> +   return (capacity_of(cpu) * 1024) <
> +(get_cpu_usage(cpu) * capacity_margin);
> +}
> +
>  /*
>   * sched_group_energy(): Returns absolute energy consumption of 
> cpus belonging
>   * to the sched_group including shared resources shared only by 
> members of the
> @@ -6732,11 +6746,12 @@ static enum group_type group_classify(struct
> lb_env *env,
>   * @local_group: Does group contain this_cpu.
>   * @sgs: variable to hold the statistics for this group.
>   * @overload: Indicate more than one runnable task for any CPU.
> + * @overutilized: Indicate overutilization for any CPU.
>   */
>  static inline void update_sg_lb_stats(struct lb_env *env,
>   struct sched_group *group, int load_idx,
>   int local_group, struct sg_lb_stats *sgs,
> - bool *overload)
> + bool *overload, bool *overutilized)
>  {
> unsigned long load;
> int i;
> @@ -6766,6 +6781,9 @@ static inline void update_sg_lb_stats(struct 
> lb_env *env,
>sgs->sum_weighted_load += weighted_cpuload(i);
>if (idle_cpu(i))
>   sgs->idle_cpus++;
> +
> +  if (cpu_overutilized(i))
> + *overutilized = true;
> }
> 
> /* Adjust by relative CPU capacity of the group */
> @@ -6871,7 +6889,7 @@ static inline void update_sd_lb_stats(struct 
> lb_env *env, struct sd_lb_stats *sd
> struct sched_group *sg = env->sd->groups;
> struct sg_lb_stats tmp_sgs;
> int load_idx, prefer_sibling = 0;
> -   bool overload = false;
> +   bool overload = false, overutilized = false;
> 
> if (child && child->flags & SD_PREFER_SIBLING)
>prefer_sibling = 1;
> @@ -6893,7 +6911,7 @@ static inline void update_sd_lb_stats(struct 
> lb_env *env, struct sd_lb_stats *sd
>}
> 
>update_sg_lb_stats(env, sg, load_idx, local_group, sgs,
> -  &overload);
> +  &overload, &overutilized);
> 
>if (local_group)
>   goto next_group;
> @@ -6935,8 +6953,14 @@ static inline void update_sd_lb_stats(struct 
> lb_env *env, struct sd_lb_stats *sd
>/* update overload indicator if we are at root domain */
>if (env->dst_rq->rd->overload != overload)
>   env->dst_rq->rd->overload = overload;
> -   }
> 
> +  /

Re: [PATCH 22/51] writeback: add {CONFIG|BDI_CAP|FS}_CGROUP_WRITEBACK

[Jan Kara]

On Fri 22-05-15 17:13:36, Tejun Heo wrote:
> cgroup writeback requires support from both bdi and filesystem sides.
> Add BDI_CAP_CGROUP_WRITEBACK and FS_CGROUP_WRITEBACK to indicate
> support and enable BDI_CAP_CGROUP_WRITEBACK on block based bdi's by
> default.  Also, define CONFIG_CGROUP_WRITEBACK which is enabled if
> both MEMCG and BLK_CGROUP are enabled.
> 
> inode_cgwb_enabled() which determines whether a given inode's both bdi
> and fs support cgroup writeback is added.
> 
> Signed-off-by: Tejun Heo 
> Cc: Jens Axboe 
> Cc: Jan Kara 

Hum, you later changed this to use a per-sb flag instead of a per-fs-type
flag, right? We could do it as well here but OK.

One more question - what does prevent us from supporting CGROUP_WRITEBACK
for all bdis capable of writeback? I guess the reason is that currently
blkcgs are bound to request_queue and we have to have blkcg(s) for
CGROUP_WRITEBACK to work, am I right? But in principle tracking writeback
state and doing writeback per memcg doesn't seem to be bound to any device
properties so we could do that right?

Anyway, this patch looks good. You can add:

Reviewed-by: Jan Kara 

Honza

> ---
>  block/blk-core.c|  2 +-
>  include/linux/backing-dev.h | 32 +++-
>  include/linux/fs.h  |  1 +
>  init/Kconfig|  5 +
>  4 files changed, 38 insertions(+), 2 deletions(-)
> 
> diff --git a/block/blk-core.c b/block/blk-core.c
> index f46688f..e0f726f 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -620,7 +620,7 @@ struct request_queue *blk_alloc_queue_node(gfp_t 
> gfp_mask, int node_id)
>  
>   q->backing_dev_info.ra_pages =
>   (VM_MAX_READAHEAD * 1024) / PAGE_CACHE_SIZE;
> - q->backing_dev_info.capabilities = 0;
> + q->backing_dev_info.capabilities = BDI_CAP_CGROUP_WRITEBACK;
>   q->backing_dev_info.name = "block";
>   q->node = node_id;
>  
> diff --git a/include/linux/backing-dev.h b/include/linux/backing-dev.h
> index bfdaa18..6bb3123 100644
> --- a/include/linux/backing-dev.h
> +++ b/include/linux/backing-dev.h
> @@ -134,12 +134,15 @@ int bdi_set_max_ratio(struct backing_dev_info *bdi, 
> unsigned int max_ratio);
>   * BDI_CAP_NO_WRITEBACK:   Don't write pages back
>   * BDI_CAP_NO_ACCT_WB: Don't automatically account writeback pages
>   * BDI_CAP_STRICTLIMIT:Keep number of dirty pages below bdi threshold.
> + *
> + * BDI_CAP_CGROUP_WRITEBACK: Supports cgroup-aware writeback.
>   */
>  #define BDI_CAP_NO_ACCT_DIRTY0x0001
>  #define BDI_CAP_NO_WRITEBACK 0x0002
>  #define BDI_CAP_NO_ACCT_WB   0x0004
>  #define BDI_CAP_STABLE_WRITES0x0008
>  #define BDI_CAP_STRICTLIMIT  0x0010
> +#define BDI_CAP_CGROUP_WRITEBACK 0x0020
>  
>  #define BDI_CAP_NO_ACCT_AND_WRITEBACK \
>   (BDI_CAP_NO_WRITEBACK | BDI_CAP_NO_ACCT_DIRTY | BDI_CAP_NO_ACCT_WB)
> @@ -229,4 +232,31 @@ static inline int bdi_sched_wait(void *word)
>   return 0;
>  }
>  
> -#endif   /* _LINUX_BACKING_DEV_H */
> +#ifdef CONFIG_CGROUP_WRITEBACK
> +
> +/**
> + * inode_cgwb_enabled - test whether cgroup writeback is enabled on an inode
> + * @inode: inode of interest
> + *
> + * cgroup writeback requires support from both the bdi and filesystem.
> + * Test whether @inode has both.
> + */
> +static inline bool inode_cgwb_enabled(struct inode *inode)
> +{
> + struct backing_dev_info *bdi = inode_to_bdi(inode);
> +
> + return bdi_cap_account_dirty(bdi) &&
> + (bdi->capabilities & BDI_CAP_CGROUP_WRITEBACK) &&
> + (inode->i_sb->s_type->fs_flags & FS_CGROUP_WRITEBACK);
> +}
> +
> +#else/* CONFIG_CGROUP_WRITEBACK */
> +
> +static inline bool inode_cgwb_enabled(struct inode *inode)
> +{
> + return false;
> +}
> +
> +#endif   /* CONFIG_CGROUP_WRITEBACK */
> +
> +#endif   /* _LINUX_BACKING_DEV_H */
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index ce100b87..74e0ae0 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1897,6 +1897,7 @@ struct file_system_type {
>  #define FS_HAS_SUBTYPE   4
>  #define FS_USERNS_MOUNT  8   /* Can be mounted by userns 
> root */
>  #define FS_USERNS_DEV_MOUNT  16 /* A userns mount does not imply MNT_NODEV */
> +#define FS_CGROUP_WRITEBACK  32  /* Supports cgroup-aware writeback */
>  #define FS_RENAME_DOES_D_MOVE32768   /* FS will handle d_move() 
> during rename() internally. */
>   struct dentry *(*mount) (struct file_system_type *, int,
>  const char *, void *);
> diff --git a/init/Kconfig b/init/Kconfig
> index dc24dec..d4f7633 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1141,6 +1141,11 @@ config DEBUG_BLK_CGROUP
>   Enable some debugging help. Currently it exports additional stat
>   files in a cgroup which can be useful for debugging.
>  
> +config CGROUP_WRITEBACK
> + bool
> +   

Re: [RFC v2 PATCH 0/8] mm: mirrored memory support for page buddy allocations

[Mel Gorman]

On Sat, Jun 27, 2015 at 10:19:54AM +0800, Xishi Qiu wrote:
> Intel Xeon processor E7 v3 product family-based platforms introduces support
> for partial memory mirroring called as 'Address Range Mirroring'. This feature
> allows BIOS to specify a subset of total available memory to be mirrored (and
> optionally also specify whether to mirror the range 0-4 GB). This capability
> allows user to make an appropriate tradeoff between non-mirrored memory range
> and mirrored memory range thus optimizing total available memory and still
> achieving highly reliable memory range for mission critical workloads and/or
> kernel space.
> 
> Tony has already send a patchset to supprot this feature at boot time.
> https://lkml.org/lkml/2015/5/8/521
> This patchset is based on Tony's, it can support the feature after boot time.
> Use mirrored memory for all kernel allocations.
> 

This is my first time glancing through the series so I'm not aware of any
past discussion. Hopefully there are no repeats. Broadly speaking though
I'm not comfortable with the series.

First and foremost, there is uncontrolled access to the memory because
it's any kernel request. This includes even short-lived ones that do not
need mirroring such as network buffers or caches. Network network traffic
can be retried, caches can be reconstructed from disk etc.  Kernel page
tables, struct page corruption etc are much harder to recover from.

Who are the expected users of this memory and how are they meant to be
prioritised? What happens if they fail to be mirrored? What happens if the
mirrored memory is all used up and a high priority request arrives? Is there
any prioritisation of one subsystem over another? What about boot-memory
allocations, should they ever use mirrored memory? The expected users are
important and this series does not address it.

Callers do not specify the flag, you just assume that kernel allocations
must be mirrored. If the allocation request fails, then you assume it was
MIGRATE_RECLAIMABLE later in the series. This is wrong as it'll break
fragmentation avoidance on machines with mirrored memory. Even if you
were to use migrate types to handle mirrored memory, you need to treat
mirrored memory as a type of reserve or else as a first preference for
allocations requested.

The fact that this will be used by very few machines but affects the memory
footprint of the page allocator is a general concern. When active, it affects
the fast paths for all users whether they care about mirroring or not.

If all free memory is in the MIGRATE_MIRROR then all user-space requests
will be rejected but reclaim will not make any progress if the zone
is balanced. The system may go prematurely OOM as no progress is made.
Getting around this is tricky and affects a few fast paths. Generally, the
easiest approach would be zone-based but I recognise that it has problems
of its own.

Basically, overall I feel this series is the wrong approach but not knowing
who the users are making is much harder to judge. I strongly suspect that
if mirrored memory is to be properly used then it needs to be available
before the page allocator is even active. Once active, there needs to
be controlled access for allocation requests that are really critical
to mirror and not just all kernel allocations. None of that would use a
MIGRATE_TYPE approach. It would be alterations to the bootmem allocator and
access to an explicit reserve that is not accounted for as "free memory"
and accessed via an explicit GFP flag.

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

Re: da2bc1b9db3351addd293e5b82757efe1f77ed1d breaks hibernation was Re: 4.1-rc7, thinkpad X60: platform mode hibernation does very wrongthing

[Pavel Machek]

Hi!

> > And this all reminded me of https://lkml.org/lkml/2015/3/18/133 . So I
> > think that's another system not covered by commit ab3be73fa7b4
> > ("drm/i915: gen4: work around hang during hibernation").
> 
> Yes, another system broken by
> 
> commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
> Author: Imre Deak 
> Date:   Thu Oct 23 19:23:26 2014 +0300

Imre, your patch already broken 3 machines, and now we discovered it
breakes another. Can you please revert it before it causes more
damage?

Thanks,
Pavel


> drm/i915: add poweroff_late handler
> 
> The suspend_late handler saves some registers and powers off the
> device,
> so it doesn't have a big overhead. Calling it at S4
> poweroff_late time
> makes the power off handling identical to the S3 suspend and
> S4 freeze
> handling, so do this for consistency.
>   
> 
> And no, adding another system to the "blacklist" is a not good idea,
> because we know there are other broken systems out there. Can we
> revert da2bc1b9db3351addd293e5b82757efe1f77ed1d, please? Consistency
> is nice, but not having regressions is even nicer.
>   Pavel
>   
> PS: Now I have real Linus and fake Linus on the Cc list. Or maybe two
> real Linuses, its hard to tell.
> 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: n900 in 4.2-rc0: repeating oopses

[Pali Rohár]

On Tuesday 30 June 2015 11:24:04 Pavel Machek wrote:
> Hi!
> 
> > Just tried booting 4.2-rc0 on n900 (commit
> > 4a10a91756ef381bced7b88cfb9232f660b92d93) and it is broken. Previous
> > -rc0 version worked. This time, there's some output on console, but
> > too fast for me to read.
> > 
> > It seems oopses happen before mounting root. If you have serial
> > console, they should be easy to see.
> 
> I tried again according to pali's instructions, and it is still
> broken the same way. Any other ideas? Does it work for you?
> 
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 69a40cf..ff6f2bf 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -570,6 +570,7 @@
>   interrupts = <49>;
>   dmas = <&sdma 69>;
>   dma-names = "rx";
> + status = "disabled";
>   };
>  
>   smartreflex_core: smartreflex@480cb000 {
> 
>   Pavel
> 

Ok, then it is not problem with omap crypto and HS device...

I will try 4.2 at the end of week.

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

Re: [PATCH v2] perf tools: don't adjust symbols in vDSO

[Adrian Hunter]

On 29/06/15 16:52, Will Deacon wrote:
> On Mon, Jun 29, 2015 at 02:23:51PM +0100, Adrian Hunter wrote:
>> On 29/06/15 15:30, Adrian Hunter wrote:
>>> On 29/06/15 12:02, Adrian Hunter wrote:
 On 27/06/15 12:10, Will Deacon wrote:
> @@ -824,6 +823,14 @@ int dso__load_sym(struct dso *dso, struct map *map,
>   sec = syms_ss->symtab;
>   shdr = syms_ss->symshdr;
>  
> + /*
> +  * Older x86 kernels prelink the vDSO at a high address, so
> +  * we need to reflect that in map->pgoff in order to talk to
> +  * objdump.
> +  */
> + if (dso__is_vdso(dso))
> + map->pgoff = shdr.sh_addr - shdr.sh_offset;

 In the case of perf tools, maps map memory addresses to file offsets.
 That is used to read from the object file, so you can't change the map.
>>>
>>> So what about just this instead:
>>>
>>> if (dso__is_vdso(dso))
>>> map->reloc = shdr.sh_addr - shdr.sh_offset;
>>>
>>
>> No that's no good either :-(
> 
> Yeah... we're fighting against symbol lookup wanting ->map_ip to give the
> address of the ELF symbol but unwinding wanting ->map_ip to give a relative
> offset for file reads.
> 
> Also, the reloc is a bit weird and I think needs to be the other way around
> (i.e. we convert from a map-relative address to an objdump address by
> *subtracting* the reloc). Even with that change, I run into problems with
> annotate comparing ELF symbol addresses with map addresses. Urgh.

Adding or subtracting shouldn't matter.

This seems to work (without any other changes):

if (dso__is_vdso(dso))
map->reloc = map->start - shdr.sh_addr + shdr.sh_offset;

Haven't tested 32-bit yet though.

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

Re: [alsa-devel][PATCH] ASoC: wm8960: update pll and clock setting function

[Zidan Wang]

On Mon, Jun 29, 2015 at 10:44:12AM +0100, Charles Keepax wrote:
> On Fri, Jun 26, 2015 at 07:09:22PM +0800, Zidan Wang wrote:
> > When using snd_soc_dai_set_pll to set pll in machine driver, we
> > should set pll in and pll out freq and ensure 5 < PLLN < 13,
> > otherwise set pll will be failed. In order to support more
> > formats and sample rates for a certain MCLK, if snd_soc_dai_set_pll
> > failed, it will calculate a available pll out freq and set the pll
> > again.
> > 
> > Signed-off-by: Zidan Wang 
> > ---
> 
> I think this need a little more explaination on how this is
> expected to work. From looking at the code what it looks like
> what happens is you can set a PLL frequency through set_pll but
> then if that frequency doesn't support the sample rate requested
> through hw_params it will be changed. This makes me a little
> nervous, as something explicitly requested is being overwritten
> automatically.
> 
>From RM, we should ensure 5 < PLLN < 13. When i using snd_soc_dai_set_pll
to set pll frequency, it's hard for me to get a common pll out frequency.
Sometimes, when codec MCLK or sample rate changed, the pll out frequency
also should be changed, otherwise set_pll function will be failed.

I made it to auto select pll frequency when snd_soc_dai_set_pll failed, so that
it can support more sample rate, and don't need to set different pll out
frequency for different sample rate and different MCLK.

> Would it perhaps be better to allow the auto selection of the
> PLL frequency only when things haven't been manually set, or
> provide some setting that indicates auto mode?
> 
> Thanks,
> Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] gpio / ACPI: Add label to the gpio request

[Andy Shevchenko]

On Tue, 2015-06-30 at 08:32 +0200, Linus Walleij wrote:
> On Mon, Jun 15, 2015 at 4:29 AM, Alexandre Courbot  
> wrote:

> > I don't have the actual v2 patch in my inbox :(
> 
> Tobias, can you resend a v3 with the ACKs.

Just a hint: sometimes it's convenient to forward from lkml.org. Like
this one from https://lkml.org/lkml/2015/6/14/199.

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

[PATCH V3] lib/bitmap.c: rewrite __bitmap_parse && __bitmap_parselist

[Pan Xinhui]

add __bitmap_parse_common to match any contents and return expected reslut.

as __bitmap_parse_common need NULL-terminated string, we alloc a new buf.

this patch also fix an unexpected parse result issue in __bitmap_parselist.

Signed-off-by: Pan Xinhui 
---
 lib/bitmap.c | 238 +--
 1 file changed, 134 insertions(+), 104 deletions(-)
---
change log
v3:
__bitmap_parselist now allow some extra input, like ",2, 3  5-8", at least 
one digit inside.
input like " " ", " is still not allowed.

V2:
__bitmap_parse_common need *base* to parse correct result

V1:
add __bitmap_parse_common and rewrite __bitmap_parse && __bitmap_parselist
---

diff --git a/lib/bitmap.c b/lib/bitmap.c
index 64c0926..f2095e1d 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -16,6 +16,8 @@
 #include 
 #include 
 
+#include 

+#include 
 /*
  * bitmaps provide an array of bits, implemented using an an
  * array of unsigned longs.  The number of valid bits in a
@@ -331,6 +333,58 @@ again:
 EXPORT_SYMBOL(bitmap_find_next_zero_area_off);
 
 /*

+ * __bitmap_parse_common - parse expected number from buf
+ * Return 0 on success.
+ * there two patterns.
+ * if buf's contents did not match any of them, reutrn equivalent error.
+ * Notice buf's contents may be changed.
+ */
+static int __bitmap_parse_common(char *buf, unsigned int buflen,
+unsigned long *a, unsigned long *b, int base)
+{
+   int ret;
+   int token;
+   const match_table_t table = {
+   {
+   .token = 1,
+   .pattern = "%x",
+   },
+   {
+   .token = 2,
+   .pattern = "%x-%x",
+   },
+   {
+   .token = 0,
+   .pattern = NULL,
+   }
+   };
+   substring_t substr[MAX_OPT_ARGS];
+
+   if (!buflen || !a)
+   return -EINVAL;
+
+   token = match_token((char *)buf, table, substr);
+   switch (token) {
+   case 1:
+   *substr[0].to = '\0';
+   ret = kstrtoul(substr[0].from, base, a);
+   if (b)
+   *b = *a;
+   break;
+   case 2:
+   *substr[0].to = '\0';
+   *substr[1].to = '\0';
+   ret = kstrtoul(substr[0].from, base, a);
+   ret |= b ? kstrtoul(substr[1].from, base, b) : -EINVAL;
+   break;
+   default:
+   ret = -EINVAL;
+   break;
+   }
+   return ret;
+}
+
+/*
  * Bitmap printing & parsing functions: first version by Nadia Yvette Chambers,
  * second version by Paul Jackson, third by Joe Korty.
  */
@@ -359,57 +413,45 @@ int __bitmap_parse(const char *buf, unsigned int buflen,
int is_user, unsigned long *maskp,
int nmaskbits)
 {
-   int c, old_c, totaldigits, ndigits, nchunks, nbits;
+   int nchunks, nbits, ret;
+   unsigned long a;
u32 chunk;
const char __user __force *ubuf = (const char __user __force *)buf;
+   char *kbuf, *endp;
+
+   if (!buflen)
+   return -EINVAL;
+   kbuf = kmalloc(buflen + 1, GFP_KERNEL);
+   if (!kbuf)
+   return -ENOMEM;
+   if (is_user) {
+   if (copy_from_user(kbuf, ubuf, buflen) != 0) {
+   kfree(kbuf);
+   return -EFAULT;
+   }
+   } else
+   memcpy(kbuf, buf, buflen);
+   kbuf[buflen] = '\0';
+   buf = strim(kbuf);
 
 	bitmap_zero(maskp, nmaskbits);
 
-	nchunks = nbits = totaldigits = c = 0;

+   nchunks = nbits = 0;
do {
-   chunk = ndigits = 0;
-
-   /* Get the next chunk of the bitmap */
-   while (buflen) {
-   old_c = c;
-   if (is_user) {
-   if (__get_user(c, ubuf++))
-   return -EFAULT;
-   }
-   else
-   c = *buf++;
-   buflen--;
-   if (isspace(c))
-   continue;
-
-   /*
-* If the last character was a space and the current
-* character isn't '\0', we've got embedded whitespace.
-* This is a no-no, so throw an error.
-*/
-   if (totaldigits && c && isspace(old_c))
-   return -EINVAL;
-
-   /* A '\0' or a ',' signal the end of the chunk */
-   if (c == '\0' || c == ',')
-   break;
-
-   if (!isxdigit(c))
-   return -EINVAL;
-
-   /*
-* Make sure there are at least 4 free bits i