RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
> -Original Message- > From: Guenter Roeck [mailto:gro...@google.com] > Sent: Monday, September 12, 2016 10:24 AM > To: Jun Li > Cc: Guenter Roeck ; Felipe Balbi > ; Chandra Sekhar Anagani > ; Bruce Ashfield > ; Bin Gao ; Pranav Tipnis > ; Heikki Krogerus > ; linux-kernel@vger.kernel.org; linux- > u...@vger.kernel.org > Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm) > > On Sun, Sep 11, 2016 at 7:16 PM, Jun Li wrote: > > Hi Guenter > > > >> -Original Message- > >> From: Guenter Roeck [mailto:gro...@google.com] > >> Sent: Saturday, September 10, 2016 10:23 AM > >> To: Jun Li > >> Cc: Guenter Roeck ; Felipe Balbi > >> ; Chandra Sekhar Anagani > >> ; Bruce Ashfield > >> ; Bin Gao ; Pranav > >> Tipnis ; Heikki Krogerus > >> ; linux-kernel@vger.kernel.org; > >> linux- u...@vger.kernel.org > >> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager > >> (tcpm) > >> > >> On Fri, Sep 9, 2016 at 5:26 PM, Jun Li wrote: > >> > Hi Guenter, > >> > > >> >> -Original Message- > >> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- > >> >> ow...@vger.kernel.org] On Behalf Of Guenter Roeck > >> >> Sent: Wednesday, August 24, 2016 5:11 AM > >> >> To: Felipe Balbi > >> >> Cc: Chandra Sekhar Anagani ; > >> >> Bruce Ashfield ; Bin Gao > >> >> ; Pranav Tipnis ; > >> >> Heikki Krogerus ; > >> >> linux-kernel@vger.kernel.org; > >> >> linux- u...@vger.kernel.org; Guenter Roeck > >> >> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager > >> >> (tcpm) > >> >> > >> >> This driver implements the USB Type-C Power Delivery state machine > >> >> for both source and sink ports. Alternate mode support is not > >> >> fully implemented. > >> >> > >> >> The driver attaches to the USB Type-C class code implemented in > >> >> the following patches. > >> >> > >> >> usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C > PHY > >> >> usb: USB Type-C connector class > >> >> > >> >> This driver only implements the state machine. Lower level drivers > >> >> are responsible for > >> >> - Reporting VBUS status and activating VBUS > >> >> - Setting CC lines and providing CC line status > >> >> - Setting line polarity > >> >> - Activating and deactivating VCONN > >> >> - Setting the current limit > >> >> - Activating and deactivating PD message transfers > >> >> - Sending and receiving PD messages > >> >> > >> >> The driver provides both a functional API as well as callbacks for > >> >> lower level drivers. > >> >> > >> >> Signed-off-by: Guenter Roeck > >> >> --- > >> > > >> > A specific question, if power sink wants to request a new power > >> > level after SNK_READY, how to handle it with this tcpm? > >> > > >> > >> So far I have considered the required power level to be static, based > >> on our curent implementations. That should be easy to change, though, > >> with an additional API function, to be called from a low level driver. > >> Do you have that requirement, and would such a function meet your > needs ? > >> > > > > So you are going to make port->tcpc->config to be dynamic to meet my > need? > > > What would that help ? How would tcpm get informed that the power > requirements changed without an API function telling it that power > requirements changed ? Of cos I agree an additional API is required, I am just wondering how that API will be look like, as current request build is according to port->tcpc->config. Li Jun > > Guenter
Re: [PATCH v4 3/3] drm/mediatek: fix the wrong pixel clock when resolution is 4K
Hi, Bibby: Sorry for the late reply. On Wed, 2016-08-17 at 14:58 +0800, Bibby Hsieh wrote: > From: Junzhi Zhao > > Pixel clock should be 297MHz when resolution is 4K. > >From the code you modified, I think title should be: "Enlarge pll_rate range from (, ) to (, )" In description, you can explain the pll_rate for 4K and this enlargement could support more resolution include 4K (Not only 4K). > Signed-off-by: Junzhi Zhao > Signed-off-by: Bibby Hsieh > --- > drivers/gpu/drm/mediatek/mtk_dpi.c |9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c > b/drivers/gpu/drm/mediatek/mtk_dpi.c > index 0186e50..90fb831 100644 > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c > @@ -432,11 +432,16 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi, > unsigned long pll_rate; > unsigned int factor; > > + /* let pll_rate can fix the valid range of tvdpll (1G~2GHz) */ > pix_rate = 1000UL * mode->clock; > - if (mode->clock <= 74000) > + if (mode->clock <= 27000) > + factor = 16 * 3; > + else if (mode->clock <= 84000) > factor = 8 * 3; > - else > + else if (mode->clock <= 167000) > factor = 4 * 3; > + else > + factor = 2 * 3; > pll_rate = pix_rate * factor; > > dev_dbg(dpi->dev, "Want PLL %lu Hz, pixel clock %lu Hz\n", Regards, CK
Linux 4.8-rc6
Things calmed down, and look very normal. About two thirds driver updates, with half of the remainder being misc architecture updates, and the rest being random stuff (some fs/crypto fixes etc). Of course, just minutes after I pushed it out, David sent me the networking pull request, so there's perhaps a reason why rc6 looks fairly small. Oh well. I still haven't decided whether we're going to do an rc8, but I guess I don't have to decide yet. Nothing looks particularly bad, and it will depend on how rc7 looks. Shortlog appended - it's small enough to easily scan to get a feel for what's been going on. Linus --- Adam Ford (2): ARM: dts: logicpd-torpedo-som: Provide NAND ready pin ARM: dts: logicpd-somlv: Fix NAND device nodes Allen Hung (1): dmi-id: don't free dev structure after calling device_register Andi Shyti (1): MAINTAINERS: add myself as Samsung SPI maintainer Andreas Färber (1): ARM: dts: imx6sx-sabreauto: Fix misspelled property Andy Lutomirski (1): virtio_console: Stop doing DMA on the stack Andy Shevchenko (1): spi: pxa2xx-pci: fix ACPI-based enumeration of SPI devices Anson Huang (1): ARM: imx6: add missing BM_CLPCR_BYPASS_PMIC_READY setting for imx6sx Baoyou Xie (3): fix:mailbox:bcm-pdc-mailbox:mark symbols static where possible IB/cxgb4: Make _free_qp static to silence build warning virtio: mark vring_dma_dev() static Benjamin Herrenschmidt (1): powerpc/xics/opal: Fix processor numbers in OPAL ICP Chris Mason (1): Btrfs: remove root_log_ctx from ctx list before btrfs_sync_log returns Christophe Jaillet (3): IB/hfi1: Clean up type used and casting IB/mlx5: Fix the size parameter to find_first_bit IB/hfi1: Fix the size parameter to find_first_bit Christophe Leroy (1): powerpc/32: Fix again csum_partial_copy_generic() Chuck Lever (1): IB/mlx5: Return EINVAL when caller specifies too many SGEs Chunyan Zhang (1): arm64: use preempt_disable_notrace in _percpu_read/write Clemens Gruber (1): usb: chipidea: udc: fix NULL ptr dereference in isr_setup_status_phase Colin Ian King (2): iio: ensure ret is initialized to zero before entering do loop usb: gadget: prevent potenial null pointer dereference on skb->len Dan Carpenter (1): mailbox: bcm-pdc: potential NULL dereference in pdc_shutdown() Dan Williams (3): dax: fix mapping size check mm: fix show_smap() for zone_device-pmd ranges mm: fix cache mode of dax pmd mappings Dave Gerlach (4): ARM: OMAP4+: hwmod: Add hwmod flag for HWMOD_OMAP4_ZERO_CLKCTRL_OFFSET ARM: OMAP2+: AM33XX: Add HWMOD_OMAP4_ZERO_CLKCTRL_OFFSET flag to rtc hwmod ARM: OMAP4+: Have _omap4_wait_target_* check for valid clkctrl_offs ARM: OMAP4+: CM: Remove redundant checks for clkctrl_offs of zero Dave Jiang (1): libnvdimm: allow legacy (e820) pmem region to clear bad blocks Dean Luick (1): IB/hfi1: Add QSFP sanity pre-check Dirk Behme (1): thermal: rcar_thermal: Fix priv->zone error handling Doug Anderson (1): i2c: rk3x: Restore clock settings at resume time Elaine Zhang (1): regmap: drop cache if the bus transfer error Erez Shitrit (2): IB/core: Fix use after free in send_leave function IB/ipoib: Fix memory corruption in ipoib cm mode connect flow Eric Biggers (3): fscrypto: add authorization check for setting encryption policy fscrypto: only allow setting encryption policy on directories fscrypto: require write access to mount to set encryption policy Fabio Estevam (2): ARM: dts: imx6qdl: Fix SPDIF regression usb: phy: phy-generic: Check clk_prepare_enable() error Felipe Balbi (1): usb: dwc3: pci: fix build warning on !PM_SLEEP Gavin Shan (2): powerpc/powernv: Fix crash on releasing compound PE powerpc/powernv: Fix corrupted PE allocation bitmap on releasing PE Geert Uytterhoeven (2): spi: sh-msiof: Avoid invalid clock generator parameters i2c: Spelling s/acknowedge/acknowledge/ Gregor Boirie (2): tools:iio:iio_generic_buffer: fix trigger-less mode iio:core: fix IIO_VAL_FRACTIONAL sign handling Gregory CLEMENT (1): ARM: dts: kirkwood: Fix PCIe label on OpenRD Harish Chegondi (1): IB/hfi1: Make n_krcvqs be an unsigned long integer Herbert Xu (1): crypto: cryptd - Use correct tfm object for AEAD tracking Horia Geantă (1): crypto: caam - fix IV loading for authenc (giv)decryption Hugo Grostabussiat (1): ARM: sun5i: Fix typo in trip point temperature Icenowy Zheng (1): pinctrl: sunxi: fix uart1 CTS/RTS pins at PG on A23/A33 James Hartley (1): pinctrl: pistachio: fix mfio pll_lock pinmux Jean Delvare (1): cpufreq-stats: Minor documentation fix Johan Hovold (3): memory: omap-gpmc: allow probe of child nodes to fail ARM: dts: overo: fix gpmc nand cs0 range ARM: dts: overo: fix
Re: [PATCH] powerpc: set used_vsr/used_vr/used_spe in sigreturn path when MSR bits are active
On Tue, Jul 26, 2016 at 04:06:01PM +0800, wei.guo.si...@gmail.com wrote: > From: Simon Guo > > Normally, when MSR[VSX/VR/SPE] bits = 1, the used_vsr/used_vr/used_spe > bit have already been set. However signal frame locates at user space > and it is controlled by user application. It is up to kernel to make > sure used_vsr/used_vr/used_spe(in kernel)=1 and consistent with MSR > bits. > > For example, CRIU application, who utilizes sigreturn to restore > checkpointed process, will lead to the case where MSR[VSX] bit is > active in signal frame, but used_vsx bit is not set. (the same applies > to VR/SPE). > > This patch will reinforce this at kernel by always setting used_* bit > when MSR related bits are active in signal frame and we are doing > sigreturn. > > This patch is based on Ben's Proposal. > Hi Michael, Just a ping for this patch. The history locates at: http://linuxppc.10917.n7.nabble.com/PATCH-v4-powerpc-Export-thread-struct-used-vr-used-vsr-to-user-space-td110147.html#a110161 If any addtional work required, please let me know. Thanks, - Simon
[PATCH v2] mm, proc: Fix region lost in /proc/self/smaps
Recently, Redhat reported that nvml test suite failed on QEMU/KVM,
more detailed info please refer to:
https://bugzilla.redhat.com/show_bug.cgi?id=1365721
Actually, this bug is not only for NVDIMM/DAX but also for any other file
systems. This simple test case abstracted from nvml can easily reproduce
this bug in common environment:
-- testcase.c -
#define PROCMAXLEN 4096
int
is_pmem_proc(const void *addr, size_t len)
{
const char *caddr = addr;
FILE *fp;
if ((fp = fopen("/proc/self/smaps", "r")) == NULL) {
printf("!/proc/self/smaps");
return 0;
}
int retval = 0; /* assume false until proven otherwise */
char line[PROCMAXLEN]; /* for fgets() */
char *lo = NULL;/* beginning of current range in smaps file */
char *hi = NULL;/* end of current range in smaps file */
int needmm = 0; /* looking for mm flag for current range */
while (fgets(line, PROCMAXLEN, fp) != NULL) {
static const char vmflags[] = "VmFlags:";
static const char mm[] = " wr";
/* check for range line */
if (sscanf(line, "%p-%p", &lo, &hi) == 2) {
if (needmm) {
/* last range matched, but no mm flag found */
printf("never found mm flag.\n");
break;
} else if (caddr < lo) {
/* never found the range for caddr */
printf("###no match for addr %p.\n", caddr);
break;
} else if (caddr < hi) {
/* start address is in this range */
size_t rangelen = (size_t)(hi - caddr);
/* remember that matching has started */
needmm = 1;
/* calculate remaining range to search for */
if (len > rangelen) {
len -= rangelen;
caddr += rangelen;
printf("matched %zu bytes in range "
"%p-%p, %zu left over.\n",
rangelen, lo, hi, len);
} else {
len = 0;
printf("matched all bytes in range "
"%p-%p.\n", lo, hi);
}
}
} else if (needmm && strncmp(line, vmflags,
sizeof(vmflags) - 1) == 0) {
if (strstr(&line[sizeof(vmflags) - 1], mm) != NULL) {
printf("mm flag found.\n");
if (len == 0) {
/* entire range matched */
retval = 1;
break;
}
needmm = 0; /* saw what was needed */
} else {
/* mm flag not set for some or all of range */
printf("range has no mm flag.\n");
break;
}
}
}
fclose(fp);
printf("returning %d.\n", retval);
return retval;
}
#define NTHREAD 16
void *Addr;
size_t Size;
/*
* worker -- the work each thread performs
*/
static void *
worker(void *arg)
{
int *ret = (int *)arg;
*ret = is_pmem_proc(Addr, Size);
return NULL;
}
int main(int argc, char *argv[])
{
if (argc < 2 || argc > 3) {
printf("usage: %s file [env].\n", argv[0]);
return -1;
}
int fd = open(argv[1], O_RDWR);
struct stat stbuf;
fstat(fd, &stbuf);
Size = stbuf.st_size;
Addr = mmap(0, stbuf.st_size, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
close(fd);
pthread_t threads[NTHREAD];
int ret[NTHREAD];
/* kick off NTHREAD threads */
for (int i = 0; i < NTHREAD; i++)
pthread_create(&threads[i], NULL, worker, &ret[i]);
/* wait for all the threads to complete */
for (int i = 0; i < NTHREAD; i++)
pthread_join(threads[i], NULL);
/* verify that all the threads return the same value */
for (int i = 1; i < NTHREAD; i++) {
if (ret[0] != ret[i]) {
printf("Error i %d ret[0] = %d ret[i] = %d.\n",
Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range
On Sun, 11 Sep 2016 10:31:35 -0700 Dan Williams wrote: > As evidenced by this bug report [1], userspace libraries are interested > in whether a mapping is DAX mapped, i.e. no intervening page cache. > Rather than using the ambiguous VM_MIXEDMAP flag in smaps, provide an > explicit "is dax" indication as a new flag in the page vector populated > by mincore. Can you cc linux-arch when adding new syscalls (or other such things that need arch enablement). I wonder if the changelog for a new syscall should have a bit more grandeur. Without seeing patch 2, you might not know this was a new syscall just by reading the subject and changelog. mincore() defines other bits to be reserved, but I guess it probably breaks things if you suddenly started using them. It's a bit sad to introduce a new syscall for this and immediately use up all bits that can be returned. Would it be a serious problem to return a larger mask per page? Thanks, Nick
Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)
>Whether msync/fsync can make data persistent depends on ADR feature on >memory controller, if it exists everything works well, otherwise, we need >to have another interface that is why 'Flush hint table' in ACPI comes >in. 'Flush hint table' is particularly useful for nvdimm virtualization if >we use normal memory to emulate nvdimm with data persistent characteristic >(the data will be flushed to a persistent storage, e.g, disk). > >Does current PMEM programming model fully supports 'Flush hint table'? Is >userspace allowed to use these addresses? The Flush hint table is NOT a replacement for ADR. To support pmem on the x86 architecture, the platform is required to ensure that a pmem store flushed from the CPU caches is in the persistent domain so that the application need not take any additional steps to make it persistent. The most common way to do this is the ADR feature. If the above is not true, then your x86 platform does not support pmem. Flush hints are for use by the BIOS and drivers and are not intended to be used in user space. Flush hints provide two things: First, if a driver needs to write to command registers or movable windows on a DIMM, the Flush hint (if provided in the NFIT) is required to flush the command to the DIMM or ensure stores done through the movable window are complete before moving it somewhere else. Second, for the rare case where the kernel wants to flush stores to the smallest possible failure domain (i.e. to the DIMM even though ADR will handle flushing it from a larger domain), the flush hints provide a way to do this. This might be useful for things like file system journals to help ensure the file system is consistent even in the face of ADR failure. -andy
mipsel-linux-gnu-gcc: error: unrecognized command line option '-mcompact-branches=optimal'
Hi Paul, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 9395452b4aab7bc2475ef8935b4a4fb99d778d70 commit: c1a0e9bc885d46e519fd87d35af6a7937abfb986 MIPS: Allow compact branch policy to be changed date: 11 months ago config: mips-malta_qemu_32r6_defconfig (attached as .config) compiler: mipsel-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout c1a0e9bc885d46e519fd87d35af6a7937abfb986 # save the attached .config to linux build tree make.cross ARCH=mips All errors (new ones prefixed by >>): >> mipsel-linux-gnu-gcc: error: unrecognized command line option >> '-mcompact-branches=optimal' >> mipsel-linux-gnu-gcc: error: unrecognized command line option >> '-mcompact-branches=optimal' make[2]: *** [kernel/bounds.s] Error 1 make[2]: Target '__build' not remade because of errors. make[1]: *** [prepare0] Error 2 make[1]: Target 'prepare' not remade because of errors. make: *** [sub-make] Error 2 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [PATCH] tpm: fix buffer overflow in /dev/tpm0
On Sun, Sep 11, 2016 at 03:19:00PM +0300, Jarkko Sakkinen wrote: > tpm_write() does not check whether the buffer has at least enough space > for the header before passing it to tpm_transmit() so an overflow can > happen. Eh? tpm_write uses a hard wired buffer size of TPM_BUFSIZE when working with tpm_transmit. in_size is never used except for the copy. We should probably fix that to sanity check the header length vs in_size. That doesn't seem to be a security issue however because the header length is propery limited to TPM_BUFSIZE and the data buffer is allocated specifically for that process using kzalloc. Jason
Re: [PATCH] cpuset: handle race between CPU hotplug and cpuset_hotplug_work
On Mon, Sep 12, 2016 at 10:48:31AM +0800, Zefan Li wrote: > Cc: Tejun > > On 2016/9/9 8:41, Joonwoo Park wrote: > > Discrepancy between cpu_online_mask and cpuset's effective CPU masks on > > cpuset hierarchy is inevitable since cpuset defers updating of > > effective CPU masks with workqueue while nothing prevents system from > > doing CPU hotplug. For that reason guarantee_online_cpus() walks up > > the cpuset hierarchy until it finds intersection under the assumption > > that top cpuset's effective CPU mask intersects with cpu_online_mask > > even under such race. > > > > However a sequence of CPU hotplugs can open a time window which is none > > of effective CPUs in the top cpuset intersects with cpu_online_mask. > > > > For example when there are 4 possible CPUs 0-3 where only CPU0 is online: > > > > === > >cpu_online_mask top_cpuset.effective_cpus > > === > >echo 1 > cpu2/online. > >CPU hotplug notifier woke up hotplug work but not yet scheduled. > > [0,2] [0] > > > >echo 0 > cpu0/online. > >The workqueue is still runnable. > > [2] [0] > > === > > > > Now there is no intersection between cpu_online_mask and > > top_cpuset.effective_cpus. Thus invoking sys_sched_setaffinity() at > > this moment can cause following: > > > >Unable to handle kernel NULL pointer dereference at virtual address > > 00d0 > >[ cut here ] > >Kernel BUG at ffc0001389b0 [verbose debug info unavailable] > >Internal error: Oops - BUG: 9605 [#1] PREEMPT SMP > >Modules linked in: > >CPU: 2 PID: 1420 Comm: taskset Tainted: GW 4.4.8+ #98 > >task: ffc06a5c4880 ti: ffc06e124000 task.ti: ffc06e124000 > >PC is at guarantee_online_cpus+0x2c/0x58 > >LR is at cpuset_cpus_allowed+0x4c/0x6c > > > >Process taskset (pid: 1420, stack limit = 0xffc06e124020) > >Call trace: > >[] guarantee_online_cpus+0x2c/0x58 > >[] cpuset_cpus_allowed+0x4c/0x6c > >[] sched_setaffinity+0xc0/0x1ac > >[] SyS_sched_setaffinity+0x98/0xac > >[] el0_svc_naked+0x24/0x28 > > > > The top cpuset's effective_cpus are guaranteed to be identical to online > > CPUs eventually. Hence fall back to online CPU mask when there is no > > intersection between top cpuset's effective_cpus and online CPU mask. > > > > Signed-off-by: Joonwoo Park > > Cc: Li Zefan > > Cc: cgro...@vger.kernel.org > > Cc: linux-kernel@vger.kernel.org > > Thanks for fixing this! > > Acked-by: Zefan Li > Cc: # 3.17+ > Thanks for reviewing. Shortly I will send v2 which has few grammar error fixes in the changelog. No code change has made. Joonwoo
[PATCH v2] cpuset: handle race between CPU hotplug and cpuset_hotplug_work
A discrepancy between cpu_online_mask and cpuset's effective_cpus
mask is inevitable during hotplug since cpuset defers updating of
effective_cpus mask using a workqueue, during which time nothing
prevents the system from more hotplug operations. For that reason
guarantee_online_cpus() walks up the cpuset hierarchy until it finds
an intersection under the assumption that top cpuset's effective_cpus
mask intersects with cpu_online_mask even with such a race occurring.
However a sequence of CPU hotplugs can open a time window, during which
none of the effective CPUs in the top cpuset intersect with
cpu_online_mask.
For example when there are 4 possible CPUs 0-3 and only CPU0 is online:
===
cpu_online_mask top_cpuset.effective_cpus
===
echo 1 > cpu2/online.
CPU hotplug notifier woke up hotplug work but not yet scheduled.
[0,2] [0]
echo 0 > cpu0/online.
The workqueue is still runnable.
[2] [0]
===
Now there is no intersection between cpu_online_mask and
top_cpuset.effective_cpus. Thus invoking sys_sched_setaffinity() at
this moment can cause following:
Unable to handle kernel NULL pointer dereference at virtual address 00d0
[ cut here ]
Kernel BUG at ffc0001389b0 [verbose debug info unavailable]
Internal error: Oops - BUG: 9605 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 1420 Comm: taskset Tainted: GW 4.4.8+ #98
task: ffc06a5c4880 ti: ffc06e124000 task.ti: ffc06e124000
PC is at guarantee_online_cpus+0x2c/0x58
LR is at cpuset_cpus_allowed+0x4c/0x6c
Process taskset (pid: 1420, stack limit = 0xffc06e124020)
Call trace:
[] guarantee_online_cpus+0x2c/0x58
[] cpuset_cpus_allowed+0x4c/0x6c
[] sched_setaffinity+0xc0/0x1ac
[] SyS_sched_setaffinity+0x98/0xac
[] el0_svc_naked+0x24/0x28
The top cpuset's effective_cpus are guaranteed to be identical to
cpu_online_mask eventually. Hence fall back to cpu_online_mask when
there is no intersection between top cpuset's effective_cpus and
cpu_online_mask.
Signed-off-by: Joonwoo Park
Cc: Li Zefan
Cc: Tejun Heo
Cc: cgro...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: # 3.17+
---
v2: fixed changelog and comment.
kernel/cpuset.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 73e93e5..27c6d78 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -325,8 +325,7 @@ static struct file_system_type cpuset_fs_type = {
/*
* Return in pmask the portion of a cpusets's cpus_allowed that
* are online. If none are online, walk up the cpuset hierarchy
- * until we find one that does have some online cpus. The top
- * cpuset always has some cpus online.
+ * until we find one that does have some online cpus.
*
* One way or another, we guarantee to return some non-empty subset
* of cpu_online_mask.
@@ -335,8 +334,20 @@ static struct file_system_type cpuset_fs_type = {
*/
static void guarantee_online_cpus(struct cpuset *cs, struct cpumask *pmask)
{
- while (!cpumask_intersects(cs->effective_cpus, cpu_online_mask))
+ while (!cpumask_intersects(cs->effective_cpus, cpu_online_mask)) {
cs = parent_cs(cs);
+ if (unlikely(!cs)) {
+ /*
+* The top cpuset doesn't have any online cpu as a
+* consequence of a race between cpuset_hotplug_work
+* and cpu hotplug notifier. But we know the top
+* cpuset's effective_cpus is on its way to to be
+* identical to cpu_online_mask.
+*/
+ cpumask_copy(pmask, cpu_online_mask);
+ return;
+ }
+ }
cpumask_and(pmask, cs->effective_cpus, cpu_online_mask);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
Re: [PATCH v2 06/33] Documentation, x86: Documentation for Intel resource allocation user interface
On Sat, Sep 10, 2016 at 12:36:57AM +, Yu, Fenghua wrote:
> > > Hmm, I don't know how applications are going to use the interface.
> > > Nobody knows it right now. But we do have some candicate workloads
> > > which want to configure the cache partition at runtime, so it's not
> > > just a boot time stuff. I'm wondering why we have such limitation. The
> > > framework is there, it's quite easy to implement process move in
> > > kernel but fairly hard to get it right in userspace.
> >
> > You are correct - if there is a need for this, it would be better done in
> > the
> > kernel.
> >
> > I'm just not sure how to explain both a "procs" and "tasks" interface file
> > in a
> > way that won't confuse people.
> >
> > We have:
> >
> > # echo {task-id} > tasks
> > adds a single task to this resource group # cat tasks
> > ... shows all the tasks in this resource group
> >
> > and you want:
> >
> > # echo {process-id} > procs
> >... adds all threads in {process-id} to this resource group # cat procs
> > ... shows all processes (like "cat tasks" above, but only shows main
> > thread in
> > a multi-threads process)
>
> The advantage of "tasks" is user can allocate each thread into its own
> partition.
> The advantage of "procs" is convenience for user to just allocate thread group
> lead pid and rest of the thread group members go with the lead.
>
> If no "procs" is really inconvenience, we may support "procs" in future.
>
> One way to implement this is we can extend the current interface to accept
> a resctrl file system mount parameter to switch b/w "procs" and "tasks" during
> mount time. So the file sytem has either "procs" or "tasks" during run time.
> I don't think it's right to have both of them at the same time in the file
> system.
A mount option doesn't make sense, which just creates more trouble. What's
wrong to have both of 'procs' and 'tasks' at the same time, like cgroup? I
think it's more natural to support both. As for the content of 'procs' and
'tasks', we could follow how cgroup handle them.
Thanks,
Shaohua
[patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform
From: Vadim Pasternak
Enable system support for the Mellanox Technologies platform, which
provides support for the next Mellanox basic systems: "msx6710",
"msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800",
"msn2740", "msn2100" and also various number of derivative systems from
the above basic types.
The Kconfig currently controlling compilation of this code is:
arch/x86/platform:config MLX_PLATFORM
arch/x86/platform: tristate "Mellanox Technologies platform support"
Signed-off-by: Vadim Pasternak
---
MAINTAINERS | 7 +
arch/x86/Kconfig | 23 ++
arch/x86/platform/Makefile| 1 +
arch/x86/platform/mellanox/Makefile | 1 +
arch/x86/platform/mellanox/mlx-platform.c | 501 ++
5 files changed, 533 insertions(+)
create mode 100644 arch/x86/platform/mellanox/Makefile
create mode 100644 arch/x86/platform/mellanox/mlx-platform.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 4705c94..8a675de 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7664,6 +7664,13 @@ W: http://www.mellanox.com
Q: http://patchwork.ozlabs.org/project/netdev/list/
F: drivers/net/ethernet/mellanox/mlxsw/
+MELLANOX PLATFORM DRIVER
+M: Vadim Pasternak
+L: platform-driver-...@vger.kernel.org
+S: Supported
+W: http://www.mellanox.com
+F: arch/x86/platform/mellanox/mlx-platform.c
+
SOFT-ROCE DRIVER (rxe)
M: Moni Shoua
L: linux-r...@vger.kernel.org
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c580d8c..cc7efdd9 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2631,6 +2631,29 @@ config TS5500
endif # X86_32
+config MLX_PLATFORM
+ tristate "Mellanox Technologies platform support"
+ depends on X86_64
+ depends on PCI
+ depends on DMI
+ depends on I2C_MLXCPLD
+ depends on I2C_MUX_REG
+ select HWMON
+ select PMBUS
+ select LM75
+ select NEW_LEDS
+ select LEDS_CLASS
+ select LEDS_TRIGGERS
+ select LEDS_TRIGGER_TIMER
+ select LEDS_MLXCPLD
+ ---help---
+ This option enables system support for the Mellanox Technologies
+ platform.
+
+ Say Y here if you are building a kernel for Mellanox system.
+
+ Otherwise, say N.
+
config AMD_NB
def_bool y
depends on CPU_SUP_AMD && PCI
diff --git a/arch/x86/platform/Makefile b/arch/x86/platform/Makefile
index 184842e..3c3c19e 100644
--- a/arch/x86/platform/Makefile
+++ b/arch/x86/platform/Makefile
@@ -8,6 +8,7 @@ obj-y += iris/
obj-y += intel/
obj-y += intel-mid/
obj-y += intel-quark/
+obj-y += mellanox/
obj-y += olpc/
obj-y += scx200/
obj-y += sfi/
diff --git a/arch/x86/platform/mellanox/Makefile
b/arch/x86/platform/mellanox/Makefile
new file mode 100644
index 000..f43c931
--- /dev/null
+++ b/arch/x86/platform/mellanox/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MLX_PLATFORM) += mlx-platform.o
diff --git a/arch/x86/platform/mellanox/mlx-platform.c
b/arch/x86/platform/mellanox/mlx-platform.c
new file mode 100644
index 000..02afa89
--- /dev/null
+++ b/arch/x86/platform/mellanox/mlx-platform.c
@@ -0,0 +1,501 @@
+/*
+ * arch/x86/platform/mellanox/mlx-platform.c
+ * Copyright (c) 2016 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2016 Vadim Pasternak
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the names of the copyright holders nor the names of its
+ *contributors may be used to endorse or promote products derived from
+ *this software without specific prior written permission.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WA
Re: [patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform
On September 11, 2016 11:29:58 PM PDT, vad...@mellanox.com wrote:
>From: Vadim Pasternak
>
>Enable system support for the Mellanox Technologies platform, which
>provides support for the next Mellanox basic systems: "msx6710",
>"msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800",
>"msn2740", "msn2100" and also various number of derivative systems from
>the above basic types.
>
>The Kconfig currently controlling compilation of this code is:
>arch/x86/platform:config MLX_PLATFORM
>arch/x86/platform: tristate "Mellanox Technologies platform
>support"
>
>Signed-off-by: Vadim Pasternak
>---
> MAINTAINERS | 7 +
> arch/x86/Kconfig | 23 ++
> arch/x86/platform/Makefile| 1 +
> arch/x86/platform/mellanox/Makefile | 1 +
>arch/x86/platform/mellanox/mlx-platform.c | 501
>++
> 5 files changed, 533 insertions(+)
> create mode 100644 arch/x86/platform/mellanox/Makefile
> create mode 100644 arch/x86/platform/mellanox/mlx-platform.c
>
>diff --git a/MAINTAINERS b/MAINTAINERS
>index 4705c94..8a675de 100644
>--- a/MAINTAINERS
>+++ b/MAINTAINERS
>@@ -7664,6 +7664,13 @@ W: http://www.mellanox.com
> Q:http://patchwork.ozlabs.org/project/netdev/list/
> F:drivers/net/ethernet/mellanox/mlxsw/
>
>+MELLANOX PLATFORM DRIVER
>+M: Vadim Pasternak
>+L: platform-driver-...@vger.kernel.org
>+S: Supported
>+W: http://www.mellanox.com
>+F: arch/x86/platform/mellanox/mlx-platform.c
>+
> SOFT-ROCE DRIVER (rxe)
> M:Moni Shoua
> L:linux-r...@vger.kernel.org
>diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>index c580d8c..cc7efdd9 100644
>--- a/arch/x86/Kconfig
>+++ b/arch/x86/Kconfig
>@@ -2631,6 +2631,29 @@ config TS5500
>
> endif # X86_32
>
>+config MLX_PLATFORM
>+ tristate "Mellanox Technologies platform support"
>+ depends on X86_64
>+ depends on PCI
>+ depends on DMI
>+ depends on I2C_MLXCPLD
>+ depends on I2C_MUX_REG
>+ select HWMON
>+ select PMBUS
>+ select LM75
>+ select NEW_LEDS
>+ select LEDS_CLASS
>+ select LEDS_TRIGGERS
>+ select LEDS_TRIGGER_TIMER
>+ select LEDS_MLXCPLD
>+ ---help---
>+This option enables system support for the Mellanox Technologies
>+platform.
>+
>+Say Y here if you are building a kernel for Mellanox system.
>+
>+Otherwise, say N.
>+
> config AMD_NB
> def_bool y
> depends on CPU_SUP_AMD && PCI
>diff --git a/arch/x86/platform/Makefile b/arch/x86/platform/Makefile
>index 184842e..3c3c19e 100644
>--- a/arch/x86/platform/Makefile
>+++ b/arch/x86/platform/Makefile
>@@ -8,6 +8,7 @@ obj-y += iris/
> obj-y += intel/
> obj-y += intel-mid/
> obj-y += intel-quark/
>+obj-y += mellanox/
> obj-y += olpc/
> obj-y += scx200/
> obj-y += sfi/
>diff --git a/arch/x86/platform/mellanox/Makefile
>b/arch/x86/platform/mellanox/Makefile
>new file mode 100644
>index 000..f43c931
>--- /dev/null
>+++ b/arch/x86/platform/mellanox/Makefile
>@@ -0,0 +1 @@
>+obj-$(CONFIG_MLX_PLATFORM)+= mlx-platform.o
>diff --git a/arch/x86/platform/mellanox/mlx-platform.c
>b/arch/x86/platform/mellanox/mlx-platform.c
>new file mode 100644
>index 000..02afa89
>--- /dev/null
>+++ b/arch/x86/platform/mellanox/mlx-platform.c
>@@ -0,0 +1,501 @@
>+/*
>+ * arch/x86/platform/mellanox/mlx-platform.c
>+ * Copyright (c) 2016 Mellanox Technologies. All rights reserved.
>+ * Copyright (c) 2016 Vadim Pasternak
>+ *
>+ * Redistribution and use in source and binary forms, with or without
>+ * modification, are permitted provided that the following conditions
>are met:
>+ *
>+ * 1. Redistributions of source code must retain the above copyright
>+ *notice, this list of conditions and the following disclaimer.
>+ * 2. Redistributions in binary form must reproduce the above
>copyright
>+ *notice, this list of conditions and the following disclaimer in
>the
>+ *documentation and/or other materials provided with the
>distribution.
>+ * 3. Neither the names of the copyright holders nor the names of its
>+ *contributors may be used to endorse or promote products derived
>from
>+ *this software without specific prior written permission.
>+ *
>+ * Alternatively, this software may be distributed under the terms of
>the
>+ * GNU General Public License ("GPL") version 2 as published by the
>Free
>+ * Software Foundation.
>+ *
>+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>"AS IS"
>+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
>TO, THE
>+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>PURPOSE
>+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
>CONTRIBUTORS BE
>+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
>OF
>+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>BUSINESS
Re: [PATCH] drivers/edac: NO_IRQ removal from powerpc-only drivers
Borislav Petkov writes:
> On Sat, Sep 10, 2016 at 07:57:08PM +1000, Michael Ellerman wrote:
>> We'd like to eventually remove NO_IRQ on powerpc, so remove usages of it
>> from powerpc-only drivers.
>>
>> Signed-off-by: Michael Ellerman
>> ---
>> drivers/edac/mpc85xx_edac.c | 6 +++---
>> drivers/edac/mv64x60_edac.c | 8
>> drivers/edac/ppc4xx_edac.c | 6 +++---
>> 3 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
>> index ca63d0da8889..e12b8e166a53 100644
>> --- a/drivers/edac/mpc85xx_edac.c
>> +++ b/drivers/edac/mpc85xx_edac.c
>> @@ -267,7 +267,7 @@ static int mpc85xx_pci_err_probe(struct platform_device
>> *op)
>>
>> pdata = pci->pvt_info;
>> pdata->name = "mpc85xx_pci_err";
>> -pdata->irq = NO_IRQ;
>> +pdata->irq = 0;
>>
>> plat_data = op->dev.platform_data;
>> if (!plat_data) {
>
> So all of those pdata structs come from kzalloc() so you don't really
> have to assign to 0 - simply kill the line.
OK.
>> @@ -1058,7 +1058,7 @@ static int mpc85xx_mc_err_probe(struct platform_device
>> *op)
>>
>> pdata = mci->pvt_info;
>> pdata->name = "mpc85xx_mc_err";
>> -pdata->irq = NO_IRQ;
>> +pdata->irq = 0;
>> mci->pdev = &op->dev;
>> pdata->edac_idx = edac_mc_idx++;
>> dev_set_drvdata(mci->pdev, mci);
>
> That part went into drivers/edac/fsl_ddr_edac.c which is only the
> freescale memory controller being shared between ARM and PPC, see
>
> http://git.kernel.org/cgit/linux/kernel/git/bp/bp.git/log/?h=for-next
>
> But that shouldn't change the issue wrt ->irq as now it is implicitly 0.
Ah OK.
NO_IRQ is -1 on ARM (or at least it can be?), see arch/arm/include/asm/irq.h.
So I'll leave that one alone for now.
> IOW, you can drop this hunk.
>
> Please send v2 against the above branch or linux-next.
OK will do.
cheers
Re: [PATCH] IB/rdmavt: free the userspace memory region with kfree instead of vfree
On Fri, Sep 09, 2016 at 08:15:37AM +0100, Colin King wrote:
> From: Colin Ian King
>
> The userspace memory region 'mr' is allocated with kzalloc in
> __rvt_alloc_mr however it is incorrectly being freed with vfree in
> __rvt_free_mr. Fix this by using kfree to free it.
>
> Signed-off-by: Colin Ian King
Thanks,
Reviewed-by: Leon Romanovsky
> ---
> drivers/infiniband/sw/rdmavt/mr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/sw/rdmavt/mr.c
> b/drivers/infiniband/sw/rdmavt/mr.c
> index 80c4b6b..46b6497 100644
> --- a/drivers/infiniband/sw/rdmavt/mr.c
> +++ b/drivers/infiniband/sw/rdmavt/mr.c
> @@ -294,7 +294,7 @@ static void __rvt_free_mr(struct rvt_mr *mr)
> {
> rvt_deinit_mregion(&mr->mr);
> rvt_free_lkey(&mr->mr);
> - vfree(mr);
> + kfree(mr);
> }
>
> /**
> --
> 2.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
signature.asc
Description: PGP signature
Re: [PATCH 07/26] net/mlx4_core: constify local structures
On Sun, Sep 11, 2016 at 03:05:49PM +0200, Julia Lawall wrote: > For structure types defined in the same file or local header files, find > top-level static structure declarations that have the following > properties: > 1. Never reassigned. > 2. Address never taken > 3. Not passed to a top-level macro call > 4. No pointer or array-typed field passed to a function or stored in a > variable. > Declare structures having all of these properties as const. > > Done using Coccinelle. > Based on a suggestion by Joe Perches . > > Signed-off-by: Julia Lawall Thanks, Reviewed-by: Leon Romanovsky signature.asc Description: PGP signature
Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller
On Sun, Sep 11, 2016 at 11:52:35AM -0600, Jason Gunthorpe wrote:
> On Sun, Sep 11, 2016 at 07:24:45PM +0200, Christoph Hellwig wrote:
> > > > > I've posted some initial work toward a) a while ago, and once we
> > >
> > > Did it get merged? Do you have a pointer?
> >
> > http://www.spinics.net/lists/linux-rdma/msg31958.html
>
> Right, I remember that. Certainly the right direction
>
> > > However, everything under verbs is not straightforward. The files in
> > > userspace are not copies...
> > >
> > > user:
> > >
> > > struct ibv_query_device {
> > >__u32 command;
> > >__u16 in_words;
> > >__u16 out_words;
> > >__u64 response;
> > >__u64 driver_data[0];
> > > };
> > >
> > > kernel:
> > >
> > > struct ib_uverbs_query_device {
> > > __u64 response;
> > > __u64 driver_data[0];
> > > };
> >
> > We'll obviously need different strutures for the libibvers API
> > and the kernel interface in this case, and we'll need to figure out
> > how to properly translate them. I think a cast, plus compile time
> > type checking ala BUILD_BUG_ON is the way to go.
>
> I'm not sure I follow, which would I cast?
>
> BUILD_BUG_ON(sizeof(ibv_query_device) == sizeof(ib_uverbs_cmd_hdr) +
> sizeof(ib_uverbs_query_device))
>
> ?
>
> > > I'm thinking the best way forward might be to use a script and
> > > transform userspace into:
> > >
> > > struct ibv_query_device {
> > > struct ib_uverbs_cmd_hdr hdr;
> > > struct ib_uverbs_query_device cmd;
> > > };
> >
> > That would break the users of the interface.
>
> Sorry, I mean doing this inside rdma-plumbing. Since the change is ABI
> identical the modified libibverbs would still be binary compatible
> with all providers but not source compatible. Since all kernel
> supported providers are in rdma-plumbing we can add the '.cmd.' at the
> same time.
>
> The kernel uapi header would stay the same.
>
> > However automatically generating the user ABI from the kernel one
> > might still be a good idea in the long run.
>
> My preference would be to try and use the kernel headers directly.
I thought the same, especially after realizing that they are almost
copy/paste from the vendor *-abi.h files.
>
> Jason
signature.asc
Description: PGP signature
linux-next: build failure after merge of the v4l-dvb tree
Hi all,
After merging the dax-misc tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/media/platform/soc_camera/built-in.o:(.opd+0x678): multiple definition
of `soc_mbus_config_compatible'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x78): first defined here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x630): multiple definition
of `soc_mbus_image_size'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x30): first defined here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x600): multiple definition
of `soc_mbus_samples_per_pixel'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x0): first defined here
drivers/media/platform/soc_camera/built-in.o: In function
`.soc_mbus_bytes_per_line':
(.text+0x4d20): multiple definition of `.soc_mbus_bytes_per_line'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x120): first defined
here
drivers/media/platform/soc_camera/built-in.o: In function
`.soc_mbus_get_fmtdesc':
(.text+0x4f90): multiple definition of `.soc_mbus_get_fmtdesc'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x390): first defined
here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x660): multiple definition
of `soc_mbus_get_fmtdesc'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x60): first defined here
drivers/media/platform/soc_camera/built-in.o: In function
`.soc_mbus_image_size':
(.text+0x4e10): multiple definition of `.soc_mbus_image_size'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x210): first defined
here
drivers/media/platform/soc_camera/built-in.o: In function
`.soc_mbus_samples_per_pixel':
(.text+0x4c00): multiple definition of `.soc_mbus_samples_per_pixel'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x0): first defined here
drivers/media/platform/soc_camera/built-in.o: In function
`.soc_mbus_config_compatible':
(.text+0x5030): multiple definition of `.soc_mbus_config_compatible'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x430): first defined
here
drivers/media/platform/soc_camera/built-in.o: In function
`.soc_mbus_find_fmtdesc':
(.text+0x4ec0): multiple definition of `.soc_mbus_find_fmtdesc'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x2c0): first defined
here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x648): multiple definition
of `soc_mbus_find_fmtdesc'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x48): first defined here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x618): multiple definition
of `soc_mbus_bytes_per_line'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x18): first defined here
Caused by commit
4bb738f228b3 ("[media] media: platform: pxa_camera: move pxa_camera out of
soc_camera")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
Re: [PATCH] logfs: remove from tree
On Mon, Sep 12, 2016 at 11:53:19AM +1000, Dave Chinner wrote: > Wasn't the lib/btree.c implementation introduced with and only used > by logfs? Should that go as well? The qla2xxx SCSI target driver also uses the btree library.
Use of schedule() function while holding a lock in ql4_nx.c
Hello, I was wondering about the call to schedule in function qla4_82xx_crb_win_lock for driver drivers/scsi/qla4xxx/ql4_nx.c. It is called in 2 functions [qla4_82xx_rd_32 and qla4_82xx_wr_32] while holding a write_lock_irqsave. Normally we avoid using sleeping functions while holding a lock. Is there some reason that I am overlooking? Why it is OK in this case? Are we using schedule() here intentionally? Thank you. -- Vaishali
Re: [PATCH V4] mm: Add sysfs interface to dump each node's zonelist information
On 09/09/2016 07:06 PM, Michal Hocko wrote: > On Thu 08-09-16 08:16:58, Anshuman Khandual wrote: >> > Each individual node in the system has a ZONELIST_FALLBACK zonelist >> > and a ZONELIST_NOFALLBACK zonelist. These zonelists decide fallback >> > order of zones during memory allocations. Sometimes it helps to dump >> > these zonelists to see the priority order of various zones in them. >> > >> > Particularly platforms which support memory hotplug into previously >> > non existing zones (at boot), this interface helps in visualizing >> > which all zonelists of the system at what priority level, the new >> > hot added memory ends up in. POWER is such a platform where all the >> > memory detected during boot time remains with ZONE_DMA for good but >> > then hot plug process can actually get new memory into ZONE_MOVABLE. >> > So having a way to get the snapshot of the zonelists on the system >> > after memory or node hot[un]plug is desirable. This change adds one >> > new sysfs interface (/sys/devices/system/memory/system_zone_details) >> > which will fetch and dump this information. > I am still not sure I understand why this is helpful and who is the > consumer for this interface and how it will benefit from the > information. Dave (who doesn't seem to be on the CC list re-added) had > another objection that this breaks one-value-per-file rule for sysfs > files. It helps in understanding the relative priority of each memory zone of the system during various allocation scenarios. Its particularly helpful after hotplug/unplug of additional memory into previously non existing zone on a node. > > This all smells like a debugging feature to me and so it should go into > debugfs. Sure, will make it a debugfs interface.
RE: [patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform
> -Original Message- > From: H. Peter Anvin [mailto:h...@zytor.com] > Sent: Monday, September 12, 2016 7:42 AM > To: Vadim Pasternak ; t...@linutronix.de > Cc: mi...@redhat.com; da...@davemloft.net; ge...@linux-m68k.org; > a...@linux-foundation.org; gre...@linuxfoundation.org; > kv...@codeaurora.org; mche...@kernel.org; li...@roeck-us.net; > x...@kernel.org; linux-kernel@vger.kernel.org; platform-driver- > x...@vger.kernel.org; j...@resnulli.us > Subject: Re: [patch v1] x86/platform/mellanox: introduce support for Mellanox > systems platform > > On September 11, 2016 11:29:58 PM PDT, vad...@mellanox.com wrote: > >From: Vadim Pasternak > > > >Enable system support for the Mellanox Technologies platform, which > >provides support for the next Mellanox basic systems: "msx6710", > >"msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800", > >"msn2740", "msn2100" and also various number of derivative systems from > >the above basic types. > > > >The Kconfig currently controlling compilation of this code is: > >arch/x86/platform:config MLX_PLATFORM > >arch/x86/platform: tristate "Mellanox Technologies platform > >support" > > > >Signed-off-by: Vadim Pasternak > >--- > > MAINTAINERS | 7 + > > arch/x86/Kconfig | 23 ++ > > arch/x86/platform/Makefile| 1 + > > arch/x86/platform/mellanox/Makefile | 1 + > >arch/x86/platform/mellanox/mlx-platform.c | 501 > >++ > > 5 files changed, 533 insertions(+) > > create mode 100644 arch/x86/platform/mellanox/Makefile > > create mode 100644 arch/x86/platform/mellanox/mlx-platform.c > > > >diff --git a/MAINTAINERS b/MAINTAINERS > >index 4705c94..8a675de 100644 > >--- a/MAINTAINERS > >+++ b/MAINTAINERS > >@@ -7664,6 +7664,13 @@ W:http://www.mellanox.com > > Q: http://patchwork.ozlabs.org/project/netdev/list/ > > F: drivers/net/ethernet/mellanox/mlxsw/ > > > >+MELLANOX PLATFORM DRIVER > >+M: Vadim Pasternak > >+L: platform-driver-...@vger.kernel.org > >+S: Supported > >+W: http://www.mellanox.com > >+F: arch/x86/platform/mellanox/mlx-platform.c > >+ > > SOFT-ROCE DRIVER (rxe) > > M: Moni Shoua > > L: linux-r...@vger.kernel.org > >diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index > >c580d8c..cc7efdd9 100644 > >--- a/arch/x86/Kconfig > >+++ b/arch/x86/Kconfig > >@@ -2631,6 +2631,29 @@ config TS5500 > > > > endif # X86_32 > > > >+config MLX_PLATFORM > >+tristate "Mellanox Technologies platform support" > >+depends on X86_64 > >+depends on PCI > >+depends on DMI > >+depends on I2C_MLXCPLD > >+depends on I2C_MUX_REG > >+select HWMON > >+select PMBUS > >+select LM75 > >+select NEW_LEDS > >+select LEDS_CLASS > >+select LEDS_TRIGGERS > >+select LEDS_TRIGGER_TIMER > >+select LEDS_MLXCPLD > >+---help--- > >+ This option enables system support for the Mellanox Technologies > >+ platform. > >+ > >+ Say Y here if you are building a kernel for Mellanox system. > >+ > >+ Otherwise, say N. > >+ > > config AMD_NB > > def_bool y > > depends on CPU_SUP_AMD && PCI > >diff --git a/arch/x86/platform/Makefile b/arch/x86/platform/Makefile > >index 184842e..3c3c19e 100644 > >--- a/arch/x86/platform/Makefile > >+++ b/arch/x86/platform/Makefile > >@@ -8,6 +8,7 @@ obj-y+= iris/ > > obj-y += intel/ > > obj-y += intel-mid/ > > obj-y += intel-quark/ > >+obj-y += mellanox/ > > obj-y += olpc/ > > obj-y += scx200/ > > obj-y += sfi/ > >diff --git a/arch/x86/platform/mellanox/Makefile > >b/arch/x86/platform/mellanox/Makefile > >new file mode 100644 > >index 000..f43c931 > >--- /dev/null > >+++ b/arch/x86/platform/mellanox/Makefile > >@@ -0,0 +1 @@ > >+obj-$(CONFIG_MLX_PLATFORM) += mlx-platform.o > >diff --git a/arch/x86/platform/mellanox/mlx-platform.c > >b/arch/x86/platform/mellanox/mlx-platform.c > >new file mode 100644 > >index 000..02afa89 > >--- /dev/null > >+++ b/arch/x86/platform/mellanox/mlx-platform.c > >@@ -0,0 +1,501 @@ > >+/* > >+ * arch/x86/platform/mellanox/mlx-platform.c > >+ * Copyright (c) 2016 Mellanox Technologies. All rights reserved. > >+ * Copyright (c) 2016 Vadim Pasternak > >+ * > >+ * Redistribution and use in source and binary forms, with or without > >+ * modification, are permitted provided that the following conditions > >are met: > >+ * > >+ * 1. Redistributions of source code must retain the above copyright > >+ *notice, this list of conditions and the following disclaimer. > >+ * 2. Redistributions in binary form must reproduce the above > >copyright > >+ *notice, this list of conditions and the following disclaimer in > >the > >+ *documentation and/or other materials provided with the > >distribution. > >+ * 3. Neither the names of the copyright holders nor the names of its > >+ *contributors may be used to endorse or promote products derived > >from >
Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)
On Thu, Sep 08, 2016 at 04:56:36PM -0600, Ross Zwisler wrote: > I think this goes back to our previous discussion about support for the PMEM > programming model. Really I think what NVML needs isn't a way to tell if it > is getting a DAX mapping, but whether it is getting a DAX mapping on a > filesystem that fully supports the PMEM programming model. This of course is > defined to be a filesystem where it can do all of its flushes from userspace > safely and never call fsync/msync, and that allocations that happen in page > faults will be synchronized to media before the page fault completes. That's a an easy way to flag: you will never get that from a Linux filesystem, period. NVML folks really need to stop taking crack and dreaming this could happen.
Re: [PATCH V4] mm: Add sysfs interface to dump each node's zonelist information
On 09/09/2016 01:54 AM, Dave Hansen wrote: > On 09/07/2016 07:46 PM, Anshuman Khandual wrote: >> > after memory or node hot[un]plug is desirable. This change adds one >> > new sysfs interface (/sys/devices/system/memory/system_zone_details) >> > which will fetch and dump this information. > Doesn't this violate the "one value per file" sysfs rule? Does it > belong in debugfs instead? Yeah sure. Will make it a debugfs interface. > > I also really question the need to dump kernel addresses out, filtered > or not. What's the point? Hmm, thought it to be an additional information. But yes its additional and can be dropped.
Re: [patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform
On 09/11/2016 11:29 PM, vad...@mellanox.com wrote:
From: Vadim Pasternak
Enable system support for the Mellanox Technologies platform, which
provides support for the next Mellanox basic systems: "msx6710",
"msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800",
"msn2740", "msn2100" and also various number of derivative systems from
the above basic types.
The Kconfig currently controlling compilation of this code is:
arch/x86/platform:config MLX_PLATFORM
arch/x86/platform: tristate "Mellanox Technologies platform support"
Signed-off-by: Vadim Pasternak
---
MAINTAINERS | 7 +
arch/x86/Kconfig | 23 ++
arch/x86/platform/Makefile| 1 +
arch/x86/platform/mellanox/Makefile | 1 +
arch/x86/platform/mellanox/mlx-platform.c | 501 ++
5 files changed, 533 insertions(+)
create mode 100644 arch/x86/platform/mellanox/Makefile
create mode 100644 arch/x86/platform/mellanox/mlx-platform.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 4705c94..8a675de 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7664,6 +7664,13 @@ W: http://www.mellanox.com
Q: http://patchwork.ozlabs.org/project/netdev/list/
F: drivers/net/ethernet/mellanox/mlxsw/
+MELLANOX PLATFORM DRIVER
+M: Vadim Pasternak
+L: platform-driver-...@vger.kernel.org
+S: Supported
+W: http://www.mellanox.com
+F: arch/x86/platform/mellanox/mlx-platform.c
+
SOFT-ROCE DRIVER (rxe)
M: Moni Shoua
L: linux-r...@vger.kernel.org
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c580d8c..cc7efdd9 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2631,6 +2631,29 @@ config TS5500
endif # X86_32
+config MLX_PLATFORM
+ tristate "Mellanox Technologies platform support"
+ depends on X86_64
+ depends on PCI
+ depends on DMI
+ depends on I2C_MLXCPLD
+ depends on I2C_MUX_REG
+ select HWMON
+ select PMBUS
+ select LM75
+ select NEW_LEDS
+ select LEDS_CLASS
+ select LEDS_TRIGGERS
+ select LEDS_TRIGGER_TIMER
+ select LEDS_MLXCPLD
+ ---help---
+ This option enables system support for the Mellanox Technologies
+ platform.
+
+ Say Y here if you are building a kernel for Mellanox system.
+
+ Otherwise, say N.
+
config AMD_NB
def_bool y
depends on CPU_SUP_AMD && PCI
diff --git a/arch/x86/platform/Makefile b/arch/x86/platform/Makefile
index 184842e..3c3c19e 100644
--- a/arch/x86/platform/Makefile
+++ b/arch/x86/platform/Makefile
@@ -8,6 +8,7 @@ obj-y += iris/
obj-y += intel/
obj-y += intel-mid/
obj-y += intel-quark/
+obj-y += mellanox/
obj-y += olpc/
obj-y += scx200/
obj-y += sfi/
diff --git a/arch/x86/platform/mellanox/Makefile
b/arch/x86/platform/mellanox/Makefile
new file mode 100644
index 000..f43c931
--- /dev/null
+++ b/arch/x86/platform/mellanox/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MLX_PLATFORM) += mlx-platform.o
diff --git a/arch/x86/platform/mellanox/mlx-platform.c
b/arch/x86/platform/mellanox/mlx-platform.c
new file mode 100644
index 000..02afa89
--- /dev/null
+++ b/arch/x86/platform/mellanox/mlx-platform.c
@@ -0,0 +1,501 @@
+/*
+ * arch/x86/platform/mellanox/mlx-platform.c
+ * Copyright (c) 2016 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2016 Vadim Pasternak
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the names of the copyright holders nor the names of its
+ *contributors may be used to endorse or promote products derived from
+ *this software without specific prior written permission.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUD
ACPI/APD Making Module
Hi, Current implementation of acpi_apd.c makes AMD I2C,GPIO and UART from acpi devices to platform devices. This is done as part of boot sequence. For some reason i would like to make it kernel module. The current implementation calls acpi_apd_create_device as part of attach callback. Now this entire process is part of acpi bus scan functionality. Can someone please help me if i can make this file into kernel module and still get the same functionality. Thanks Nehal
linux-next: Tree for Sep 12
Hi all, Changes since 20160909: The arm64 tree gained a conflict against Linus' tree. The btrfs-kdave tree lost its build failure. The v4l-dvb tree gained a build failure for which I reverted a commit. The net-next tree gained a conflict against the net tree. The kbuild tree still had its build warnings for PowerPC, for which I reverted a commit and gained a conflict against Linus' tree. The tip tree gained a conflict against the arm64 tree. The gpio tree still had its build failure, so I used the version from next-20160908. Non-merge commits (relative to Linus' tree): 6495 6444 files changed, 311206 insertions(+), 197237 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 241 trees (counting Linus' and 34 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (98ac9a608dc7 Merge branch 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm) Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when not configured) Merging arc-current/for-curr (3eab887a5542 Linux 4.8-rc4) Merging arm-current/fixes (da60626e7d02 ARM: sa1100: clear reset status prior to reboot) Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs for v4.7-rc2) Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init()) Merging powerpc-fixes/fixes (f077aaf0754b powerpc/mm: Don't alias user region to other regions below PAGE_OFFSET) Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support is disabled) Merging net/master (e1487888eccc net: ethernet: renesas: sh_eth: add POST registers for rz) Merging ipsec/master (1fb81e09d487 vti: use right inner_mode for inbound inter address family policy checks) Merging netfilter/master (d1a6cba576fc netfilter: nft_chain_route: re-route before skb is queued to userspace) Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes') Merging wireless-drivers/master (a0714125d11b Merge ath-current from ath.git) Merging mac80211/master (61aaa0e8c1c1 cfg80211: Add stub for cfg80211_get_station()) Merging sound-current/for-linus (3f640970a414 ALSA: hda - Fix headset mic detection problem for several Dell laptops) Merging pci-current/for-linus (6af7e4f77259 PCI: Mark Haswell Power Control Unit as having non-compliant BARs) Merging driver-core.current/driver-core-linus (c6935931c189 Linux 4.8-rc5) Merging tty.current/tty-linus (c6935931c189 Linux 4.8-rc5) Merging usb.current/usb-linus (6b98174b957c Merge tag 'fixes-for-v4.8-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus) Merging usb-gadget-fixes/fixes (696118c016dd usb: dwc3: pci: fix build warning on !PM_SLEEP) Merging usb-serial-fixes/usb-linus (40d9c32525cb USB: serial: option: add WeTelecom 0x6802 and 0x6803 products) Merging usb-chipidea-fixes/ci-for-usb-stable (6f3c4fb6d05e usb: chipidea: udc: fix NULL ptr dereference in isr_setup_status_phase) Merging staging.current/staging-linus (72d508ad488a Merge tag 'iio-fixes-for-4.8b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus) Merging char-misc.current/char-misc-linus (c6935931c189 Linux 4.8-rc5) Merging input-current/for-linus (4af2ff91ec3f Input: silead_gsl1680 - use "silead/
RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
Hi Guenter > -Original Message- > From: Guenter Roeck [mailto:gro...@google.com] > Sent: Saturday, September 10, 2016 10:23 AM > To: Jun Li > Cc: Guenter Roeck ; Felipe Balbi > ; Chandra Sekhar Anagani > ; Bruce Ashfield > ; Bin Gao ; Pranav Tipnis > ; Heikki Krogerus > ; linux-kernel@vger.kernel.org; linux- > u...@vger.kernel.org > Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm) > > On Fri, Sep 9, 2016 at 5:26 PM, Jun Li wrote: > > Hi Guenter, > > > >> -Original Message- > >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- > >> ow...@vger.kernel.org] On Behalf Of Guenter Roeck > >> Sent: Wednesday, August 24, 2016 5:11 AM > >> To: Felipe Balbi > >> Cc: Chandra Sekhar Anagani ; Bruce > >> Ashfield ; Bin Gao ; > >> Pranav Tipnis ; Heikki Krogerus > >> ; linux-kernel@vger.kernel.org; > >> linux- u...@vger.kernel.org; Guenter Roeck > >> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager > >> (tcpm) > >> > >> This driver implements the USB Type-C Power Delivery state machine > >> for both source and sink ports. Alternate mode support is not fully > >> implemented. > >> > >> The driver attaches to the USB Type-C class code implemented in the > >> following patches. > >> > >> usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY > >> usb: USB Type-C connector class > >> > >> This driver only implements the state machine. Lower level drivers > >> are responsible for > >> - Reporting VBUS status and activating VBUS > >> - Setting CC lines and providing CC line status > >> - Setting line polarity > >> - Activating and deactivating VCONN > >> - Setting the current limit > >> - Activating and deactivating PD message transfers > >> - Sending and receiving PD messages > >> > >> The driver provides both a functional API as well as callbacks for > >> lower level drivers. > >> > >> Signed-off-by: Guenter Roeck > >> --- > > > > A specific question, if power sink wants to request a new power level > > after SNK_READY, how to handle it with this tcpm? > > > > So far I have considered the required power level to be static, based on > our curent implementations. That should be easy to change, though, with an > additional API function, to be called from a low level driver. > Do you have that requirement, and would such a function meet your needs ? > So you are going to make port->tcpc->config to be dynamic to meet my need? Li Jun > Thanks, > Guenter
[PATCH] net: inet: diag: Fix an error handling
If 'inet_diag_lock_handler()' returns an error, we should not call
'inet_diag_unlock_handler()' on it.
'handler' is not a valid mutexc in this case.
This has been spotted with the folowing coccinelle script:
@@
expression x;
identifier f;
@@
* if (IS_ERR(x))
{
...
* f(<+... x ...+>);
...
}
Signed-off-by: Christophe JAILLET
---
net/ipv4/inet_diag.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
index abfbe492ebfe..795af25cf84c 100644
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@ -1134,7 +1134,6 @@ int inet_diag_handler_get_info(struct sk_buff *skb,
struct sock *sk)
handler = inet_diag_lock_handler(sk->sk_protocol);
if (IS_ERR(handler)) {
- inet_diag_unlock_handler(handler);
nlmsg_cancel(skb, nlh);
return PTR_ERR(handler);
}
--
2.7.4
Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)
On 09/09/2016 11:40 PM, Dan Williams wrote: On Fri, Sep 9, 2016 at 1:55 AM, Xiao Guangrong wrote: [..] Whether a persistent memory mapping requires an msync/fsync is a filesystem specific question. This mincore proposal is separate from that. Consider device-DAX for volatile memory or mincore() called on an anonymous memory range. In those cases persistence and filesystem metadata are not in the picture, but it would still be useful for userspace to know "is there page cache backing this mapping?" or "what is the TLB geometry of this mapping?". I got a question about msync/fsync which is beyond the topic of this thread :) Whether msync/fsync can make data persistent depends on ADR feature on memory controller, if it exists everything works well, otherwise, we need to have another interface that is why 'Flush hint table' in ACPI comes in. 'Flush hint table' is particularly useful for nvdimm virtualization if we use normal memory to emulate nvdimm with data persistent characteristic (the data will be flushed to a persistent storage, e.g, disk). Does current PMEM programming model fully supports 'Flush hint table'? Is userspace allowed to use these addresses? If you publish flush hint addresses in the virtual NFIT the guest VM will write to them whenever a REQ_FLUSH or REQ_FUA request is sent to the virtual /dev/pmemX device. Yes, seems straightforward to take a VM exit on those events and flush simulated pmem to persistent storage. Thank you, Dan! However REQ_FLUSH or REQ_FUA is handled in kernel space, okay, after following up the discussion in this thread, i understood that currently filesystems have not supported the case that usespace itself make data be persistent without kernel's involvement. So that works. Hmm, Does device-DAX support this case (make data be persistent without msync/fsync)? I guess no, but just want to confirm it. :)
Re: [patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform
On Sun, Sep 11, 2016 at 10:34:27PM -0700, Guenter Roeck wrote:
> > +static int mlxplat_lpc_config(struct mlxplat_priv *priv)
> > +{
> > + struct pci_dev *pdev = NULL;
> > + u16 dev_id;
> > + int err;
> > +
> > + pdev = pci_get_bus_and_slot(MLXPLAT_CPLD_LPC_CTRL_IFC_BUS_ID,
> > + PCI_DEVFN(MLXPLAT_CPLD_LPC_CTRL_IFC_SLOT_ID,
> > + MLXPLAT_CPLD_LPC_CTRL_IFC_FUNC_ID));
> > +
>
> Kind of unusual way to initialize a PCI device. If this can't be implemented
> as PCI driver, maybe it should be initialized using PCI quirks ?
That's a _very old_ way of writing a pci driver, I thought we had gotten
rid of all of that crud.
This needs to be a "normal" PCI driver, no need for it to be a platform
driver at all from what I can tell.
thanks,
greg k-h
RE: Memory fragmentation issue related suggestion request
Dear Ankur,
I would suggest you register to linux...@kvack.org and explain your issues in
details.
There are other experts here, who can guide you.
Few comments are inline below.
> From: Ankur Tank [mailto:ankur.t...@lnttechservices.com]
> Sent: Saturday, September 10, 2016 5:26 PM
> To: pint...@samsung.com
> Cc: artf...@gmail.com
> Subject: Memory fragmentation issue related suggestion request
>
> Hello Pintukumar,
>
> TL;DR
> We have an issue in our Linux box, what looks like memory fragmentation issue,
> while searching on net I referred talk you gave in Embedded Linux Conf.
I have several talks in ELC, not sure which one you are referring to. Please
point out.
> I am facing this issue for couple of weeks so thought to ask you for
> suggestions.
> Please forgive me If I offended you by writing mail to you, Ignore mail if
> you feel so.
>
> Details
> We are facing one issue in our Embedded Linux board, Our board is Beaglebone
> black based custom board, with 4GB eMMC as storage. We are using Linux kernel
> 3.12.
In addition, you may need to provide the following information:
RAM size ?
cat /proc/meminfo (before and after the operation)
cat /proc/buddyinfo (before and after the operation)
cat /proc/vmstat (before and after the operation)
> Our firmware upgrade strategy is using backgup partition for Bootloader,
> Kernel,
> dtb, rootfs.
> So,
> During firmware upgrade with big rootfs and running dd to read the partition
> in raw
> mode.
> In short looks like those operations are overloading the system.
>
I am not sure, but I think this is the crude way of taking the backup.
This will certainly overload your system.
FOTA upgrade experts can give more comments here.
> From below log looks like pages above 32KB size is not available and may be
> because of that rootfs tar on the emmc is failing.
> I have following queries in that regards,
>
> 1. Do you think it is a memory fragmentation ?
Yes, if all above 32KB (2^3 order) pages are not available, and pages are
available in lower orders (2^0/1/2) then its certainly fragmentation problem.
However, as I said, you need to provide the following output to confirm:
cat /proc/buddyinfo
> May be silly to ask so but just to confirm, because I had added the software
> swap
> however with that also we were seeing issue reproducible and swap was not
> full at
> that time ☹
>
Well, adding swap should help a bit but it may not solve the problem completely.
How much swap did you actually allocated?
What kind of swap you used ?
Is it ZRAM/ZSWAP (with compression support) ?
What is the swappiness ratio ? (/proc/sys/vm/swappiness)
> 2. If it is so how do we handle it ? is there a some way similar to
> your shrinker
> utility to reclaim the memory pages ?
>
Not sure which shrinker utility are you referring to ?
Is it : /proc/sys/vm/shrink_memory ?
> Any suggestion would help me move forward,
>
Did you tried enabling CONFIG_COMPACTION ?
Try using ZRAM or ZSWAP (~30% of MemTotal).
Try tuning : /proc/sys/vm/dirty_{background_ratio/bytes} and others.
[Refer kernel/documentation for the same]
>From the logs, I observed the following:
> [ 6676.674219] mmcqd/1: page allocation failure: order:1, mode:0x200020
Order-1 allocation is failing, so pages might be sitting in order-0.
> [ 6676.674739] free_cma:1982
You have around ~7MB of CMA free pages, so this cannot be used for non-movable
allocation.
> [ 6676.674885] 51661 total pagecache pages
You have huge amount of memory sitting in caches. These can be reclaimed in
back ground (with slight performance degradation).
To experiment and debug you can try: echo 3 > /proc/sys/vm/drop_caches
> [ 6676.674925] Total swap = 0kB
Swap is not enabled on your system.
> Regards,
> Ankur
>
> Error log
>
>
> [ 6676.674219] mmcqd/1: page allocation failure: order:1, mode:0x200020
>[ 6676.674256] CPU: 0 PID: 612 Comm: mmcqd/1 Tainted: P O
> 3.12.10-005-
> ts-armv7l #2
> [ 6676.674321] [] (unwind_backtrace+0x0/0xf4) from []
> (show_stack+0x10/0x14)
> [ 6676.674355] [] (show_stack+0x10/0x14) from []
> (warn_alloc_failed+0xe0/0x118)
> [ 6676.674383] [] (warn_alloc_failed+0xe0/0x118) from
> []
> (__alloc_pages_nodemask+0x74c/0x8f8)
> [ 6676.674413] [] (__alloc_pages_nodemask+0x74c/0x8f8) from
> [] (cache_alloc_refill+0x328/0x620)
> [ 6676.674436] [] (cache_alloc_refill+0x328/0x620) from
> [] (__kmalloc+0xa0/0xe8)
> [ 6676.674471] [] (__kmalloc+0xa0/0xe8) from []
> (edma_prep_slave_sg+0x84/0x388)
> [ 6676.674505] [] (edma_prep_slave_sg+0x84/0x388) from
> [] (omap_hsmmc_request+0x414/0x508)
> [ 6676.674544] [] (omap_hsmmc_request+0x414/0x508) from
> [] (mmc_start_request+0xc4/0xe0)
> [ 6676.674568] [] (mmc_start_request+0xc4/0xe0) from
> [] (mmc_start_req+0x2d8/0x38c)
> [ 6676.674589] [] (mmc_start_req+0x2d8/0x38c) from []
> (mmc_blk_issue_rw_rq+0xb4/0x9d8)
> [ 6676.674611] [] (mmc_blk_issue_rw_rq+0xb4/0x9d8) from
> [] (mmc_
Re: [patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform
On Mon, Sep 12, 2016 at 06:29:58AM +, vad...@mellanox.com wrote: > From: Vadim Pasternak > > Enable system support for the Mellanox Technologies platform, which > provides support for the next Mellanox basic systems: "msx6710", > "msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800", > "msn2740", "msn2100" and also various number of derivative systems from > the above basic types. What does "system support" mean? Why can't this just be a "normal" PCI driver, as you are just accessing a PCI device and doing something with it, seems odd to claim it is a "platform" driver. thanks, greg k-h
Re: [PATCH 01/26] ALSA: pci: constify local structures
On Sun, 11 Sep 2016 15:05:43 +0200,
Julia Lawall wrote:
>
> For structure types defined in the same file or local header files, find
> top-level static structure declarations that have the following
> properties:
> 1. Never reassigned.
> 2. Address never taken
> 3. Not passed to a top-level macro call
> 4. No pointer or array-typed field passed to a function or stored in a
> variable.
> Declare structures having all of these properties as const.
>
> Done using Coccinelle.
> Based on a suggestion by Joe Perches .
>
> Signed-off-by: Julia Lawall
Thanks, applied now.
Takashi
> ---
> The semantic patch seems too long for a commit log, but is in the cover
> letter.
>
> sound/pci/ctxfi/ctatc.c |2 +-
> sound/pci/hda/patch_ca0132.c | 10 +-
> sound/pci/riptide/riptide.c |2 +-
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/sound/pci/ctxfi/ctatc.c b/sound/pci/ctxfi/ctatc.c
> index 977a598..908658a 100644
> --- a/sound/pci/ctxfi/ctatc.c
> +++ b/sound/pci/ctxfi/ctatc.c
> @@ -1623,7 +1623,7 @@ static int atc_resume(struct ct_atc *atc)
> }
> #endif
>
> -static struct ct_atc atc_preset = {
> +static const struct ct_atc atc_preset = {
> .map_audio_buffer = ct_map_audio_buffer,
> .unmap_audio_buffer = ct_unmap_audio_buffer,
> .pcm_playback_prepare = atc_pcm_playback_prepare,
> diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c
> index 9ceb2bc..ad06866 100644
> --- a/sound/pci/hda/patch_ca0132.c
> +++ b/sound/pci/hda/patch_ca0132.c
> @@ -4018,7 +4018,7 @@ static int ca0132_build_controls(struct hda_codec
> *codec)
> /*
> * PCM
> */
> -static struct hda_pcm_stream ca0132_pcm_analog_playback = {
> +static const struct hda_pcm_stream ca0132_pcm_analog_playback = {
> .substreams = 1,
> .channels_min = 2,
> .channels_max = 6,
> @@ -4029,7 +4029,7 @@ static struct hda_pcm_stream ca0132_pcm_analog_playback
> = {
> },
> };
>
> -static struct hda_pcm_stream ca0132_pcm_analog_capture = {
> +static const struct hda_pcm_stream ca0132_pcm_analog_capture = {
> .substreams = 1,
> .channels_min = 2,
> .channels_max = 2,
> @@ -4040,7 +4040,7 @@ static struct hda_pcm_stream ca0132_pcm_analog_capture
> = {
> },
> };
>
> -static struct hda_pcm_stream ca0132_pcm_digital_playback = {
> +static const struct hda_pcm_stream ca0132_pcm_digital_playback = {
> .substreams = 1,
> .channels_min = 2,
> .channels_max = 2,
> @@ -4052,7 +4052,7 @@ static struct hda_pcm_stream
> ca0132_pcm_digital_playback = {
> },
> };
>
> -static struct hda_pcm_stream ca0132_pcm_digital_capture = {
> +static const struct hda_pcm_stream ca0132_pcm_digital_capture = {
> .substreams = 1,
> .channels_min = 2,
> .channels_max = 2,
> @@ -4614,7 +4614,7 @@ static void ca0132_free(struct hda_codec *codec)
> kfree(codec->spec);
> }
>
> -static struct hda_codec_ops ca0132_patch_ops = {
> +static const struct hda_codec_ops ca0132_patch_ops = {
> .build_controls = ca0132_build_controls,
> .build_pcms = ca0132_build_pcms,
> .init = ca0132_init,
> diff --git a/sound/pci/riptide/riptide.c b/sound/pci/riptide/riptide.c
> index ae41fcb..ada5f01 100644
> --- a/sound/pci/riptide/riptide.c
> +++ b/sound/pci/riptide/riptide.c
> @@ -644,7 +644,7 @@ static struct lbuspath lbus_play_paths[] = {
>.mono = lbus_play_mono3,
>},
> };
> -static struct lbuspath lbus_rec_path = {
> +static const struct lbuspath lbus_rec_path = {
> .noconv = lbus_rec_noconv1,
> .stereo = lbus_rec_stereo1,
> .mono = lbus_rec_mono1,
>
>
[PATCH 4/7] perf hist: Initialize hierachy tree explicitly
The hroot_in and hroot_out are root of hiearchy tree of hist entry. But as hist entry is initialized by copying existing template entry, it sometimes has non-empty tree and copied it incorrectly. This is a problem especially when event group is used since it creates dummy entries from already-processed entries in other event members. Signed-off-by: Namhyung Kim --- tools/perf/util/hist.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c index 702ba3a8ead6..37a08f20730a 100644 --- a/tools/perf/util/hist.c +++ b/tools/perf/util/hist.c @@ -417,6 +417,8 @@ static int hist_entry__init(struct hist_entry *he, } INIT_LIST_HEAD(&he->pairs.node); thread__get(he->thread); + he->hroot_in = RB_ROOT; + he->hroot_out = RB_ROOT; if (!symbol_conf.report_hierarchy) he->leaf = true; -- 2.9.3
[PATCHSET 0/7] perf tools: Support hierarchy report with event group (v1)
Hello, This patchset implements hierarchy mode with event group. It was disabled due to complexity when I wrote the hierarchy code, but there's no fundamental reason to do it. It's also available on 'perf/hierarchy-group-v1' branch in my tree: git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git Thanks, Namhyung Namhyung Kim (7): perf hists browser: Fix event group display perf hist: Introduce hists__match_hierarchy() perf hist: Introduce hists__link_hierarchy() perf hist: Initialize hierachy tree explicitly perf ui/stdio: Reset output width for hierarchy perf ui/tui: Reset output width for hierarchy perf report: Enable group view with hierarchy tools/perf/builtin-report.c| 1 - tools/perf/ui/browsers/hists.c | 7 +- tools/perf/ui/stdio/hist.c | 6 ++ tools/perf/util/hist.c | 148 + 4 files changed, 160 insertions(+), 2 deletions(-) -- 2.9.3
[PATCH 5/7] perf ui/stdio: Reset output width for hierarchy
When --hierarchy option is used, each entry has its own hpp_list to show
the result. But it missed to update width of each column.
Signed-off-by: Namhyung Kim
---
tools/perf/ui/stdio/hist.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/perf/ui/stdio/hist.c b/tools/perf/ui/stdio/hist.c
index 9b65f4a6b35a..83ca728b6f61 100644
--- a/tools/perf/ui/stdio/hist.c
+++ b/tools/perf/ui/stdio/hist.c
@@ -733,6 +733,7 @@ size_t hists__fprintf(struct hists *hists, bool
show_header, int max_rows,
bool use_callchain)
{
struct perf_hpp_fmt *fmt;
+ struct perf_hpp_list_node *node;
struct rb_node *nd;
size_t ret = 0;
const char *sep = symbol_conf.field_sep;
@@ -745,6 +746,11 @@ size_t hists__fprintf(struct hists *hists, bool
show_header, int max_rows,
hists__for_each_format(hists, fmt)
perf_hpp__reset_width(fmt, hists);
+ /* hierarchy entries have their own hpp list */
+ list_for_each_entry(node, &hists->hpp_formats, list) {
+ perf_hpp_list__for_each_format(&node->hpp, fmt)
+ perf_hpp__reset_width(fmt, hists);
+ }
if (symbol_conf.col_width_list_str)
perf_hpp__set_user_width(symbol_conf.col_width_list_str);
--
2.9.3
[PATCH 3/7] perf hist: Introduce hists__link_hierarchy()
The hists__link_hierarchy() is to support hierarchy report with event
group. When it matches leader event and other members (with the
hists__match_hierarchy), it also needs to link unmatched member entries
with a dummy leader event so that it can show up in the output.
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.c | 95 ++
1 file changed, 95 insertions(+)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index be3f5ce31303..702ba3a8ead6 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -2149,6 +2149,50 @@ static struct hist_entry *hists__add_dummy_entry(struct
hists *hists,
return he;
}
+static struct hist_entry *add_dummy_hierarchy_entry(struct hists *hists,
+ struct rb_root *root,
+ struct hist_entry *pair)
+{
+ struct rb_node **p;
+ struct rb_node *parent = NULL;
+ struct hist_entry *he;
+ struct perf_hpp_fmt *fmt;
+
+ p = &root->rb_node;
+ while (*p != NULL) {
+ int64_t cmp = 0;
+
+ parent = *p;
+ he = rb_entry(parent, struct hist_entry, rb_node_in);
+
+ perf_hpp_list__for_each_sort_list(he->hpp_list, fmt) {
+ cmp = fmt->collapse(fmt, he, pair);
+ if (cmp)
+ break;
+ }
+ if (!cmp)
+ goto out;
+
+ if (cmp < 0)
+ p = &parent->rb_left;
+ else
+ p = &parent->rb_right;
+ }
+
+ he = hist_entry__new(pair, true);
+ if (he) {
+ rb_link_node(&he->rb_node_in, parent, p);
+ rb_insert_color(&he->rb_node_in, root);
+
+ he->dummy = true;
+ he->hists = hists;
+ memset(&he->stat, 0, sizeof(he->stat));
+ hists__inc_stats(hists, he);
+ }
+out:
+ return he;
+}
+
static struct hist_entry *hists__find_entry(struct hists *hists,
struct hist_entry *he)
{
@@ -2248,6 +2292,50 @@ void hists__match(struct hists *leader, struct hists
*other)
}
}
+static int hists__link_hierarchy(struct hists *leader_hists,
+struct hist_entry *parent,
+struct rb_root *leader_root,
+struct rb_root *other_root)
+{
+ struct rb_node *nd;
+ struct hist_entry *pos, *leader;
+
+ for (nd = rb_first(other_root); nd; nd = rb_next(nd)) {
+ pos = rb_entry(nd, struct hist_entry, rb_node_in);
+
+ if (hist_entry__has_pairs(pos)) {
+ bool found = false;
+
+ list_for_each_entry(leader, &pos->pairs.head,
pairs.node) {
+ if (leader->hists == leader_hists) {
+ found = true;
+ break;
+ }
+ }
+ if (!found)
+ return -1;
+ } else {
+ leader = add_dummy_hierarchy_entry(leader_hists,
+ leader_root, pos);
+ if (leader == NULL)
+ return -1;
+
+ /* do not point parent in the pos */
+ leader->parent_he = parent;
+
+ hist_entry__add_pair(pos, leader);
+ }
+
+ if (!pos->leaf) {
+ if (hists__link_hierarchy(leader_hists, leader,
+ &leader->hroot_in,
+ &pos->hroot_in) < 0)
+ return -1;
+ }
+ }
+ return 0;
+}
+
/*
* Look for entries in the other hists that are not present in the leader, if
* we find them, just add a dummy entry on the leader hists, with period=0,
@@ -2259,6 +2347,13 @@ int hists__link(struct hists *leader, struct hists
*other)
struct rb_node *nd;
struct hist_entry *pos, *pair;
+ if (symbol_conf.report_hierarchy) {
+ /* hierarchy report always collapses entries */
+ return hists__link_hierarchy(leader, NULL,
+&leader->entries_collapsed,
+&other->entries_collapsed);
+ }
+
if (hists__has(other, need_collapse))
root = &other->entries_collapsed;
else
--
2.9.3
[PATCH 1/7] perf hists browser: Fix event group display
Milian reported that the event group on TUI shows duplicated overhead.
This was due to a bug on calculating hpp->buf position. The
hpp_advance() was called from __hpp__slsmg_color_printf() on TUI but
it's already called from the hpp__call_print_fn macro in __hpp__fmt().
The end result is that the print function returns number of bytes it
printed but the buffer advanced twice of the length.
This is generally not a problem since it doesn't need to access the
buffer again. But with event group, overhead needs to be printed
multiple times and hist_entry__snprintf_alignment() tries to fill the
space with buffer after it printed. So it (brokenly) showed the last
overhead again.
The bug was there from the beginning, but I think it's only revealed
when the alignment function was added.
Reported-by: Milian Wolff
Fixes: 89fee7094323 ("perf hists: Do column alignment on the format iterator")
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index f0611c937d4b..35e44b1879e3 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1097,7 +1097,6 @@ static int __hpp__slsmg_color_printf(struct perf_hpp
*hpp, const char *fmt, ...)
ret = scnprintf(hpp->buf, hpp->size, fmt, len, percent);
ui_browser__printf(arg->b, "%s", hpp->buf);
- advance_hpp(hpp, ret);
return ret;
}
--
2.9.3
[PATCH 7/7] perf report: Enable group view with hierarchy
Now all missing pieces are implemented, let's enable it. An example
output below:
$ perf report --hierarchy --stdio
...
# Overhead Command / Shared Object / Symbol
# .. ..
#
25.74% 27.18%sh
19.96% 24.14%libc-2.24.so
9.55% 14.64%[.] __strcmp_sse2
1.54% 0.00%[.] __tfind
1.07% 1.13%[.] _int_malloc
0.95% 0.00%[.] __strchr_sse2
0.89% 1.39%[.] __tsearch
0.76% 0.00%[.] strlen
...
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 1a07c4cdf6ed..6e88460cd13d 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -935,7 +935,6 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
if (symbol_conf.report_hierarchy) {
/* disable incompatible options */
- symbol_conf.event_group = false;
symbol_conf.cumulate_callchain = false;
if (field_order) {
--
2.9.3
[PATCH 6/7] perf ui/tui: Reset output width for hierarchy
When --hierarchy option is used, each entry has its own hpp_list to show
the result. But it missed to update width of each column.
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 35e44b1879e3..49db16334814 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -2067,6 +2067,7 @@ void hist_browser__init(struct hist_browser *browser,
struct hists *hists)
{
struct perf_hpp_fmt *fmt;
+ struct perf_hpp_list_node *node;
browser->hists = hists;
browser->b.refresh = hist_browser__refresh;
@@ -2079,6 +2080,11 @@ void hist_browser__init(struct hist_browser *browser,
perf_hpp__reset_width(fmt, hists);
++browser->b.columns;
}
+ /* hierarchy entries have their own hpp list */
+ list_for_each_entry(node, &hists->hpp_formats, list) {
+ perf_hpp_list__for_each_format(&node->hpp, fmt)
+ perf_hpp__reset_width(fmt, hists);
+ }
}
struct hist_browser *hist_browser__new(struct hists *hists)
--
2.9.3
[PATCH 2/7] perf hist: Introduce hists__match_hierarchy()
The hists__match_hierarchy() is to find matching hist entries in a
group. It needs to search all matching children in the hierarchy.
Signed-off-by: Namhyung Kim
---
tools/perf/util/hist.c | 51 ++
1 file changed, 51 insertions(+)
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index de15dbcdcecf..be3f5ce31303 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -2174,6 +2174,51 @@ static struct hist_entry *hists__find_entry(struct hists
*hists,
return NULL;
}
+static struct hist_entry *hists__find_hierarchy_entry(struct rb_root *root,
+ struct hist_entry *he)
+{
+ struct rb_node *n = root->rb_node;
+
+ while (n) {
+ struct hist_entry *iter;
+ struct perf_hpp_fmt *fmt;
+ int64_t cmp = 0;
+
+ iter = rb_entry(n, struct hist_entry, rb_node_in);
+ perf_hpp_list__for_each_sort_list(he->hpp_list, fmt) {
+ cmp = fmt->collapse(fmt, iter, he);
+ if (cmp)
+ break;
+ }
+
+ if (cmp < 0)
+ n = n->rb_left;
+ else if (cmp > 0)
+ n = n->rb_right;
+ else
+ return iter;
+ }
+
+ return NULL;
+}
+
+static void hists__match_hierarchy(struct rb_root *leader_root,
+ struct rb_root *other_root)
+{
+ struct rb_node *nd;
+ struct hist_entry *pos, *pair;
+
+ for (nd = rb_first(leader_root); nd; nd = rb_next(nd)) {
+ pos = rb_entry(nd, struct hist_entry, rb_node_in);
+ pair = hists__find_hierarchy_entry(other_root, pos);
+
+ if (pair) {
+ hist_entry__add_pair(pair, pos);
+ hists__match_hierarchy(&pos->hroot_in, &pair->hroot_in);
+ }
+ }
+}
+
/*
* Look for pairs to link to the leader buckets (hist_entries):
*/
@@ -2183,6 +2228,12 @@ void hists__match(struct hists *leader, struct hists
*other)
struct rb_node *nd;
struct hist_entry *pos, *pair;
+ if (symbol_conf.report_hierarchy) {
+ /* hierarchy report always collapses entries */
+ return hists__match_hierarchy(&leader->entries_collapsed,
+ &other->entries_collapsed);
+ }
+
if (hists__has(leader, need_collapse))
root = &leader->entries_collapsed;
else
--
2.9.3
Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range
On Mon, Sep 12, 2016 at 3:31 AM, Dan Williams wrote: > As evidenced by this bug report [1], userspace libraries are interested > in whether a mapping is DAX mapped, i.e. no intervening page cache. > Rather than using the ambiguous VM_MIXEDMAP flag in smaps, provide an > explicit "is dax" indication as a new flag in the page vector populated > by mincore. > > There are also cases, particularly for testing and validating a > configuration to know the hardware mapping geometry of the pages in a > given process address range. Consider filesystem-dax where a > configuration needs to take care to align partitions and block > allocations before huge page mappings might be used, or > anonymous-transparent-huge-pages where a process is opportunistically > assigned large pages. mincore2() allows these configurations to be > surveyed and validated. > > The implementation takes advantage of the unused bits in the per-page > byte returned for each PAGE_SIZE extent of a given address range. The > new format of each vector byte is: > > (TLB_SHIFT - PAGE_SHIFT) << 2 | vma_is_dax() << 1 | page_present What is userspace expected to do with the information in vec? Whether PMD or THP mappings can be used is going to depend more on the block allocations done by the filesystem rather than anything the an application can directly influence. Returning a vector for each page makes some sense in the mincore() case since the application can touch each page to fault them in, but I don't see what they can do here. Why not just get rid of vec entirely and make mincore2() a yes/no check over the range for whatever is supplied in flags? That would work for NVML's use case and it should be easier to extend if needed. Oliver
Re: linux-next: build failure after merge of the v4l-dvb tree
On 09/12/2016 07:10 AM, Stephen Rothwell wrote:
Hi all,
After merging the dax-misc tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/media/platform/soc_camera/built-in.o:(.opd+0x678): multiple definition
of `soc_mbus_config_compatible'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x78): first defined here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x630): multiple definition
of `soc_mbus_image_size'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x30): first defined here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x600): multiple definition
of `soc_mbus_samples_per_pixel'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x0): first defined here
drivers/media/platform/soc_camera/built-in.o: In function
`.soc_mbus_bytes_per_line':
(.text+0x4d20): multiple definition of `.soc_mbus_bytes_per_line'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x120): first defined
here
drivers/media/platform/soc_camera/built-in.o: In function
`.soc_mbus_get_fmtdesc':
(.text+0x4f90): multiple definition of `.soc_mbus_get_fmtdesc'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x390): first defined
here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x660): multiple definition
of `soc_mbus_get_fmtdesc'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x60): first defined here
drivers/media/platform/soc_camera/built-in.o: In function
`.soc_mbus_image_size':
(.text+0x4e10): multiple definition of `.soc_mbus_image_size'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x210): first defined
here
drivers/media/platform/soc_camera/built-in.o: In function
`.soc_mbus_samples_per_pixel':
(.text+0x4c00): multiple definition of `.soc_mbus_samples_per_pixel'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x0): first defined here
drivers/media/platform/soc_camera/built-in.o: In function
`.soc_mbus_config_compatible':
(.text+0x5030): multiple definition of `.soc_mbus_config_compatible'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x430): first defined
here
drivers/media/platform/soc_camera/built-in.o: In function
`.soc_mbus_find_fmtdesc':
(.text+0x4ec0): multiple definition of `.soc_mbus_find_fmtdesc'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x2c0): first defined
here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x648): multiple definition
of `soc_mbus_find_fmtdesc'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x48): first defined here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x618): multiple definition
of `soc_mbus_bytes_per_line'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x18): first defined here
Caused by commit
4bb738f228b3 ("[media] media: platform: pxa_camera: move pxa_camera out of
soc_camera")
I have reverted that commit for today.
I posted a patch fixing this yesterday. I'll make a pull request today
for Mauro to merge.
Regards,
Hans
Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)
On 09/12/2016 11:44 AM, Rudoff, Andy wrote: Whether msync/fsync can make data persistent depends on ADR feature on memory controller, if it exists everything works well, otherwise, we need to have another interface that is why 'Flush hint table' in ACPI comes in. 'Flush hint table' is particularly useful for nvdimm virtualization if we use normal memory to emulate nvdimm with data persistent characteristic (the data will be flushed to a persistent storage, e.g, disk). Does current PMEM programming model fully supports 'Flush hint table'? Is userspace allowed to use these addresses? The Flush hint table is NOT a replacement for ADR. To support pmem on the x86 architecture, the platform is required to ensure that a pmem store flushed from the CPU caches is in the persistent domain so that the application need not take any additional steps to make it persistent. The most common way to do this is the ADR feature. If the above is not true, then your x86 platform does not support pmem. Understood. However, virtualization is a special case as we can use normal memory to emulate NVDIMM for the vm so that vm can bypass local file-cache, reduce memory usage and io path, etc. Currently, this usage is useful for lightweight virtualization, such as clean container. Under this case, ADR is available on physical platform but it can not help us to make data persistence for the vm. So that virtualizeing 'flush hint table' is a good way to handle it based on the acpi spec: | software can write to any one of these Flush Hint Addresses to | cause any preceding writes to the NVDIMM region to be flushed | out of the intervening platform buffers 1 to the targeted NVDIMM | (to achieve durability) Flush hints are for use by the BIOS and drivers and are not intended to be used in user space. Flush hints provide two things: First, if a driver needs to write to command registers or movable windows on a DIMM, the Flush hint (if provided in the NFIT) is required to flush the command to the DIMM or ensure stores done through the movable window are complete before moving it somewhere else. Second, for the rare case where the kernel wants to flush stores to the smallest possible failure domain (i.e. to the DIMM even though ADR will handle flushing it from a larger domain), the flush hints provide a way to do this. This might be useful for things like file system journals to help ensure the file system is consistent even in the face of ADR failure. We are assuming ADR can fail, however, do we have a way to know whether ADR works correctly? Maybe MCE can work on it? This is necessary to support making data persistent without 'fsync/msync' in userspace. Or do we need to unconditionally use 'flush hint address' if it is available as current nvdimm driver does? Thanks!
[PATCH V2] cpufreq: create link to policy only for registered CPUs
If a cpufreq driver is registered very early in the boot stage (e.g.
registered from postcore_initcall()), then cpufreq core may generate
kernel warnings for it.
In this case, the CPUs are brought online, then the cpufreq driver is
registered, and then the CPU topology devices are registered. However,
by the time cpufreq_add_dev() gets called, the cpu device isn't stored
in the per-cpu variable (cpu_sys_devices,) which is read by
get_cpu_device().
So the cpufreq core fails to get device for the CPU, for which
cpufreq_add_dev() was called in the first place and we will hit a
WARN_ON(!cpu_dev).
Even if we reuse the 'dev' parameter passed to cpufreq_add_dev() to
avoid that warning, there might be other CPUs online that share the
policy with the cpu for which cpufreq_add_dev() is called. Eventually
get_cpu_device() will return NULL for them as well, and we will hit the
same WARN_ON() again.
In order to fix these issues, change cpufreq core to create links to the
policy for a cpu only when cpufreq_add_dev() is called for that CPU.
Reuse the 'real_cpus' mask to track that as well.
Note that cpufreq_remove_dev() already handles removal of the links for
individual CPUs and cpufreq_add_dev() has aligned with that now.
Reported-by: Russell King
Tested-by: Russell King
Signed-off-by: Viresh Kumar
---
V1->V2:
- Updated changelog based on suggestions from Russell
- Tested by from Russell
drivers/cpufreq/cpufreq.c | 89 +++
1 file changed, 28 insertions(+), 61 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 13fb589b6d2c..3a64136bf21b 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -916,58 +916,18 @@ static struct kobj_type ktype_cpufreq = {
.release= cpufreq_sysfs_release,
};
-static int add_cpu_dev_symlink(struct cpufreq_policy *policy, int cpu)
+static int add_cpu_dev_symlink(struct cpufreq_policy *policy,
+ struct device *dev)
{
- struct device *cpu_dev;
-
- pr_debug("%s: Adding symlink for CPU: %u\n", __func__, cpu);
-
- if (!policy)
- return 0;
-
- cpu_dev = get_cpu_device(cpu);
- if (WARN_ON(!cpu_dev))
- return 0;
-
- return sysfs_create_link(&cpu_dev->kobj, &policy->kobj, "cpufreq");
+ dev_dbg(dev, "%s: Adding symlink\n", __func__);
+ return sysfs_create_link(&dev->kobj, &policy->kobj, "cpufreq");
}
-static void remove_cpu_dev_symlink(struct cpufreq_policy *policy, int cpu)
+static void remove_cpu_dev_symlink(struct cpufreq_policy *policy,
+ struct device *dev)
{
- struct device *cpu_dev;
-
- pr_debug("%s: Removing symlink for CPU: %u\n", __func__, cpu);
-
- cpu_dev = get_cpu_device(cpu);
- if (WARN_ON(!cpu_dev))
- return;
-
- sysfs_remove_link(&cpu_dev->kobj, "cpufreq");
-}
-
-/* Add/remove symlinks for all related CPUs */
-static int cpufreq_add_dev_symlink(struct cpufreq_policy *policy)
-{
- unsigned int j;
- int ret = 0;
-
- /* Some related CPUs might not be present (physically hotplugged) */
- for_each_cpu(j, policy->real_cpus) {
- ret = add_cpu_dev_symlink(policy, j);
- if (ret)
- break;
- }
-
- return ret;
-}
-
-static void cpufreq_remove_dev_symlink(struct cpufreq_policy *policy)
-{
- unsigned int j;
-
- /* Some related CPUs might not be present (physically hotplugged) */
- for_each_cpu(j, policy->real_cpus)
- remove_cpu_dev_symlink(policy, j);
+ dev_dbg(dev, "%s: Removing symlink\n", __func__);
+ sysfs_remove_link(&dev->kobj, "cpufreq");
}
static int cpufreq_add_dev_interface(struct cpufreq_policy *policy)
@@ -999,7 +959,7 @@ static int cpufreq_add_dev_interface(struct cpufreq_policy
*policy)
return ret;
}
- return cpufreq_add_dev_symlink(policy);
+ return 0;
}
__weak struct cpufreq_governor *cpufreq_default_governor(void)
@@ -1129,7 +1089,6 @@ static void cpufreq_policy_put_kobj(struct cpufreq_policy
*policy, bool notify)
down_write(&policy->rwsem);
cpufreq_stats_free_table(policy);
- cpufreq_remove_dev_symlink(policy);
kobj = &policy->kobj;
cmp = &policy->kobj_unregister;
up_write(&policy->rwsem);
@@ -1211,8 +1170,8 @@ static int cpufreq_online(unsigned int cpu)
if (new_policy) {
/* related_cpus should at least include policy->cpus. */
cpumask_copy(policy->related_cpus, policy->cpus);
- /* Remember CPUs present at the policy creation time. */
- cpumask_and(policy->real_cpus, policy->cpus, cpu_present_mask);
+ /* Clear mask of registered CPUs */
+ cpumask_clear(policy->real_cpus);
}
/*
@@ -1327,6 +1286,8 @@ static int cpufreq_online(unsigned
Re: [PATCH 19/26] intel_pstate: constify local structures
On 11-09-16, 15:06, Julia Lawall wrote:
> For structure types defined in the same file or local header files, find
> top-level static structure declarations that have the following
> properties:
> 1. Never reassigned.
> 2. Address never taken
> 3. Not passed to a top-level macro call
> 4. No pointer or array-typed field passed to a function or stored in a
> variable.
> Declare structures having all of these properties as const.
>
> Done using Coccinelle.
> Based on a suggestion by Joe Perches .
>
> Signed-off-by: Julia Lawall
>
> ---
> The semantic patch seems too long for a commit log, but is in the cover
> letter.
>
> drivers/cpufreq/intel_pstate.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index bdbe936..4b5f8c3 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -1029,7 +1029,7 @@ static struct cpu_defaults core_params = {
> },
> };
>
> -static struct cpu_defaults silvermont_params = {
> +static const struct cpu_defaults silvermont_params = {
> .pid_policy = {
> .sample_rate_ms = 10,
> .deadband = 0,
> @@ -1050,7 +1050,7 @@ static struct cpu_defaults silvermont_params = {
> },
> };
>
> -static struct cpu_defaults airmont_params = {
> +static const struct cpu_defaults airmont_params = {
> .pid_policy = {
> .sample_rate_ms = 10,
> .deadband = 0,
> @@ -1071,7 +1071,7 @@ static struct cpu_defaults airmont_params = {
> },
> };
>
> -static struct cpu_defaults knl_params = {
> +static const struct cpu_defaults knl_params = {
> .pid_policy = {
> .sample_rate_ms = 10,
> .deadband = 0,
> @@ -1091,7 +1091,7 @@ static struct cpu_defaults knl_params = {
> },
> };
>
> -static struct cpu_defaults bxt_params = {
> +static const struct cpu_defaults bxt_params = {
> .pid_policy = {
> .sample_rate_ms = 10,
> .deadband = 0,
Acked-by: Viresh Kumar
--
viresh
[PATCH] blk-throttle: fix infinite throttling caused by non-cascading timer wheel
Due to commit 500462a9de65 ("timers: Switch to a non-cascading wheel"),
the slack of timer increases when the timeout increases:
So for HZ=250 we end up with the following granularity levels:
Level Offset Granularity Range
0 0 4 ms 0 ms -252 ms
1 64 32 ms 256 ms - 2044 ms (256ms - ~2s)
2128256 ms 2048 ms - 16380 ms (~2s - ~16s)
When the slack is bigger than throtl_slice (100ms), there will be
a problem: throtl_slice_used() will always return true, a new slice
will always be genereated, and the bio will be throttled forever.
The following is a example:
echo 253:0 512 > /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device
fio --readonly --direct=1 --filename=/dev/vda --size=4K --rate=4K \
--rw=read --ioengine=libaio --iodepth=16 --name 1
the slack of 8s-timer is about 302ms.
throtl / [R] bio. bdisp=0 sz=4096 bps=512 iodisp=0 iops=4294967295 queued=0/0
throtl schedule timer. delay=8000 jiffies=4295784850
throtl / dispatch nr_queued=1 read=1 write=0, bdisp=0/0, iodisp=0/0
throtl / [R] new slice start=4295793152 end=4295793252 jiffies=4295793152
throtl / [R] extend slice start=4295793152 end=4295801200 jiffies=4295793152
throtl schedule timer. delay=8000 jiffies=4295793152
throtl / dispatch nr_queued=1 read=1 write=0, bdisp=0/0, iodisp=0/0
throtl / [R] new slice start=4295801344 end=4295801444 jiffies=4295801344
throtl / [R] extend slice start=4295801344 end=4295809400 jiffies=4295801344
throtl schedule timer. delay=8000 jiffies=4295801344
Fix it by checking the delayed dispatch in tg_may_dispatch():
1. If there is any dispatched bio, the time slice must have been used,
so it's OK to renew the time slice.
2. If there is no queued bio, the time slice must have been expired,
so it's Ok to renew the time slice.
Signed-off-by: Hou Tao
---
block/blk-throttle.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index f1aba26..91f8140 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -591,13 +591,20 @@ static inline void throtl_extend_slice(struct throtl_grp
*tg, bool rw,
tg->slice_end[rw], jiffies);
}
+static bool throtl_is_delayed_disp(struct throtl_grp *tg, bool rw)
+{
+ return (time_after(jiffies, tg->slice_end[rw]) &&
+ !tg->bytes_disp[rw] && !tg->io_disp[rw] &&
+ tg->service_queue.nr_queued[rw]) ? true : false;
+}
+
/* Determine if previously allocated or extended slice is complete or not */
static bool throtl_slice_used(struct throtl_grp *tg, bool rw)
{
if (time_in_range(jiffies, tg->slice_start[rw], tg->slice_end[rw]))
return false;
- return 1;
+ return true;
}
/* Trim the used slices and adjust slice start accordingly */
@@ -782,7 +789,7 @@ static bool tg_may_dispatch(struct throtl_grp *tg, struct
bio *bio,
* existing slice to make sure it is at least throtl_slice interval
* long since now.
*/
- if (throtl_slice_used(tg, rw))
+ if (throtl_slice_used(tg, rw) && !throtl_is_delayed_disp(tg, rw))
throtl_start_new_slice(tg, rw);
else {
if (time_before(tg->slice_end[rw], jiffies + throtl_slice))
--
2.5.5
drm/i915: undefined symbol I915_SW_FENCE_CHECK_DAG
Hi Chris,
your commit e68a139f6bf3 ("drm/i915: Add a sw fence for collecting up
dma fences") has shown up in today's linux-next (i.e., 20160912)
adding the following the lines (184++):
+ if (!IS_ENABLED(CONFIG_I915_SW_FENCE_CHECK_DAG))
+ return false;
The Kconfig symbol isn't defined anywhere, so the function will always
return false. I could not find a patch on LKML adding the symbol. Is
there a patch queued somewhere or is the yet unconditional return
intentional?
I found the issue by diffing the last and today's linux-next using
scripts/checkkconfigsymbols.py.
Kind regards,
Valentin
Re: [PATCH] logfs: remove from tree
On Sun, 2016-09-11 at 15:04 +0200, Christoph Hellwig wrote: > Logfs was introduced to the kernel in 2009, and hasn't seen any non > drive-by changes since 2012, while having lots of unsolved issues > including the complete lack of error handling, with more and more > issues popping up without any fixes. > > The logfs.org domain has been bouncing from a mail, and the > maintainer > on the non-logfs.org domain hasn't repsonded to past queries either. > > Signed-off-by: Christoph Hellwig Back in 2008 logfs and UBIFS were in sort of competing projects. I remember we inspected logfs code and tested it - we did not find proper wear-levelling and bad block handling, we did not see proper error handling, and it exploded when we were running relatively simple tests. We indicated this here in a very humble way to avoid the "conflict of interest" perseption: https://lkml.org/lkml/2008/3/31/117 I did not follow logfs since then, but I think there wasn't much development since then and all these issue are still there. I mean, unless I am horribly mistaken, logfs does not really have the basic features of a flash file system and there is no point keeping it in the tree and consuming people's time maintaining it. Artem.
RE: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
Hi Scott,
Thanks for your review :)
See my comment inline.
> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Friday, September 09, 2016 11:47 AM
> To: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Arnd
> Bergmann
> Cc: linuxppc-...@lists.ozlabs.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> foundation.org; net...@vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie
> Subject: Re: [v11, 5/8] soc: fsl: add GUTS driver for QorIQ platforms
>
> On Tue, 2016-09-06 at 16:28 +0800, Yangbo Lu wrote:
> > The global utilities block controls power management, I/O device
> > enabling, power-onreset(POR) configuration monitoring, alternate
> > function selection for multiplexed signals,and clock control.
> >
> > This patch adds a driver to manage and access global utilities block.
> > Initially only reading SVR and registering soc device are supported.
> > Other guts accesses, such as reading RCW, should eventually be moved
> > into this driver as well.
> >
> > Signed-off-by: Yangbo Lu
> > Signed-off-by: Scott Wood
>
> Don't put my signoff on patches that I didn't put it on
> myself. Definitely don't put mine *after* yours on patches that were
> last modified by you.
>
> If you want to mention that the soc_id encoding was my suggestion, then
> do so explicitly.
>
[Lu Yangbo-B47093] I found your 'signoff' on this patch at below link.
http://patchwork.ozlabs.org/patch/649211/
So, let me just change the order in next version ?
Signed-off-by: Scott Wood
Signed-off-by: Yangbo Lu
> > +/* SoC attribute definition for QorIQ platform */ static const struct
> > +soc_device_attribute qoriq_soc[] = { #ifdef CONFIG_PPC
> > + /*
> > + * Power Architecture-based SoCs T Series
> > + */
> > +
> > + /* SoC: T1024/T1014/T1023/T1013 Rev: 1.0 */
> > + { .soc_id = "svr:0x85400010,name:T1024,die:T1024",
> > + .revision = "1.0",
> > + },
> > + { .soc_id = "svr:0x85480010,name:T1024E,die:T1024",
> > + .revision = "1.0",
> > + },
>
> Revision could be computed from the low 8 bits of SVR (just as you do for
> unknown SVRs).
>
[Lu Yangbo-B47093] Yes, you're right. Will remove it here.
> We could move the die name into .family:
>
> {
> .soc_id = "svr:0x85490010,name:T1023E,",
> .family = "QorIQ T1024",
> }
>
> I see you dropped svre (and the trailing comma), though I guess the vast
> majority of potential users will be looking at .family. In which case do
> we even need name? If we just make the soc_id be "svr:0x" then
> we could shrink the table to an svr+mask that identifies each die. I'd
> still want to keep the "svr:" even if we're giving up on the general
> tagging system, to make it clear what the number refers to, and to
> provide some defense against users who match only against soc_id rather
> than soc_id+family. Or we could go further and format soc_id as "QorIQ
> SVR 0x" so that soc_id-only matches are fully acceptable rather
> than just less dangerous.
[Lu Yangbo-B47093] It's a good idea to move die into .family I think.
In my opinion, it's better to keep svr and name in soc_id just like your
suggestion above.
> {
> .soc_id = "svr:0x85490010,name:T1023E,",
> .family = "QorIQ T1024",
> }
The user probably don’t like to learn the svr value. What they want is just to
match the soc they use.
It's convenient to use name+rev for them to match a soc.
Regarding shrinking the table, I think it's hard to use svr+mask. Because I
find many platforms use different masks.
We couldn’t know the mask according svr value.
>
> > +static const struct soc_device_attribute *fsl_soc_device_match(
> > + unsigned int svr, const struct soc_device_attribute *matches) {
> > + char svr_match[50];
> > + int n;
> > +
> > + n = sprintf(svr_match, "*%08x*", svr);
>
> n = sprintf(svr_match, "svr:0x%08x,*", svr);
>
> (according to the current encoding)
>
[Lu Yangbo-B47093] Ok. Will do that.
> > +
> > + do {
> > + if (!matches->soc_id)
> > + return NULL;
> > + if (glob_match(svr_match, matches->soc_id))
> > + break;
> > + } while (matches++);
>
> Are you expecting "matches++" to ever evaluate as false?
[Lu Yangbo-B47093] Yes, this is used to match the soc we use in qoriq_soc array
until getting true.
We need to get the name and die information defined in array.
>
> > + /* Register soc device */
> > + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> > + if (!soc_dev_attr) {
> > + ret = -ENOMEM;
> > + goto out_unmap;
> > + }
>
> Couldn't this be statically allocated?
[Lu Yang
Re: [PATCH] pinctrl: cherryview: Do not mask all interrupts on probe
On Sun, Sep 11, 2016 at 11:05:06AM +0300, Mika Westerberg wrote:
> On Fri, Sep 09, 2016 at 11:58:32AM +0300, Mika Westerberg wrote:
> > On Fri, Sep 09, 2016 at 04:23:58PM +0800, Phidias Chiang wrote:
> >
> > Only other place where we touch INTMASK register is
> > chv_gpio_irq_mask_unmask(). Can you add some debug there to find out the
> > caller?
>
> Something like this:
>
> diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c
> b/drivers/pinctrl/intel/pinctrl-cherryview.c
> index 0fe8fad..95fa3b1 100644
> --- a/drivers/pinctrl/intel/pinctrl-cherryview.c
> +++ b/drivers/pinctrl/intel/pinctrl-cherryview.c
> @@ -1357,6 +1357,11 @@ static void chv_gpio_irq_mask_unmask(struct irq_data
> *d, bool mask)
> value |= BIT(intr_line);
> chv_writel(value, pctrl->regs + CHV_INTMASK);
>
> + if (printk_ratelimit()) {
> + dev_info(pctrl->dev, "%smask pin %u intmask 0x%08x\n",
> + mask ? "" : "un", pin, readl(pctrl->regs +
> CHV_INTMASK));
> + }
> +
> raw_spin_unlock_irqrestore(&chv_lock, flags);
> }
>
With printk_ratelimit():
[2.058485] cherryview-pinctrl INT33FF:00: INTMASK0: 0x0006
[2.058513] cherryview-pinctrl INT33FF:00: mask pin 0 intmask 0x0006
[2.058533] cherryview-pinctrl INT33FF:00: mask pin 1 intmask 0x0006
[2.058551] cherryview-pinctrl INT33FF:00: mask pin 2 intmask 0x0006
[2.058569] cherryview-pinctrl INT33FF:00: mask pin 3 intmask 0x0006
[2.058587] cherryview-pinctrl INT33FF:00: mask pin 4 intmask 0x0006
[2.058604] cherryview-pinctrl INT33FF:00: mask pin 5 intmask 0x0006
[2.058623] cherryview-pinctrl INT33FF:00: mask pin 6 intmask 0x0006
[2.058641] cherryview-pinctrl INT33FF:00: mask pin 7 intmask 0x0006
[2.058663] cherryview-pinctrl INT33FF:00: mask pin 15 intmask 0x0006
[2.059401] cherryview-pinctrl INT33FF:00: INTMASK1: 0x
[2.059551] cherryview-pinctrl INT33FF:01: INTMASK0: 0x4000
[2.061272] cherryview-pinctrl INT33FF:01: INTMASK1: 0x
[2.061516] cherryview-pinctrl INT33FF:02: INTMASK0: 0x
[2.061906] cherryview-pinctrl INT33FF:02: INTMASK1: 0x
[2.062116] cherryview-pinctrl INT33FF:03: INTMASK0: 0x
[2.062956] cherryview-pinctrl INT33FF:03: INTMASK1: 0x
w/o printk_ratelimit():
http://pastebin.com/dLDELDB4
The main difference is the intmask turns to 0x4 on pin 75 and 0x0
afterwards for INT33FF:00. And same thing happened with :01 on pin 25
Re: drm/i915: undefined symbol I915_SW_FENCE_CHECK_DAG
On Mon, Sep 12, 2016 at 08:46:39AM +0200, Valentin Rothberg wrote:
> Hi Chris,
>
> your commit e68a139f6bf3 ("drm/i915: Add a sw fence for collecting up
> dma fences") has shown up in today's linux-next (i.e., 20160912)
> adding the following the lines (184++):
>
> + if (!IS_ENABLED(CONFIG_I915_SW_FENCE_CHECK_DAG))
> + return false;
>
> The Kconfig symbol isn't defined anywhere, so the function will always
> return false. I could not find a patch on LKML adding the symbol. Is
> there a patch queued somewhere or is the yet unconditional return
> intentional?
The patch is queued up elsewhere. It's part of the selftests.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH] ARM: decompressor: reset ttbcr fields to use TTBR0 on ARMv7
If the bootloader uses the long descriptor format and jumps to
kernel decompressor code, TTBCR may not be in a right state.
Before enabling the MMU, it is required to clear the TTBCR.PD0
field to use TTBR0 for translation table walks.
The 'commit dbece45894d3a ("ARM: 7501/1: decompressor:
reset ttbcr for VMSA ARMv7 cores")' does the reset of TTBCR.N, but
doesn't consider all the bits for the size of TTBCR.N.
Clear TTBCR.PD0 field and reset all the three bits of TTBCR.N to
indicate the use of TTBR0 and the correct base address width.
Signed-off-by: Srinivas Ramana
---
arch/arm/boot/compressed/head.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index af11c2f8f3b7..fc6d541549a2 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -779,7 +779,7 @@ __armv7_mmu_cache_on:
orrne r0, r0, #1 @ MMU enabled
movne r1, #0xfffd @ domain 0 = client
bic r6, r6, #1 << 31@ 32-bit translation system
- bic r6, r6, #3 << 0 @ use only ttbr0
+ bic r6, r6, #(7 << 0) | (1 << 4)@ use only ttbr0
mcrne p15, 0, r3, c2, c0, 0 @ load page table pointer
mcrne p15, 0, r1, c3, c0, 0 @ load domain access control
mcrne p15, 0, r6, c2, c0, 2 @ load ttb control
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
arch/mips/include/asm/mach-cavium-octeon/mangle-port.h:19:40: error: right shift count >= width of type
Hi Steven,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 98ac9a608dc79ba8a20cee77fe959a6dfccdaa63
commit: 1685ddbe35cd4637f7f841d5f9755dd0470bd68d MIPS: Octeon: Changes to
support readq()/writeq() usage.
date: 9 weeks ago
config: mips-cavium_octeon_defconfig (attached as .config)
compiler: mips64-linux-gnuabi64-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 1685ddbe35cd4637f7f841d5f9755dd0470bd68d
# save the attached .config to linux build tree
make.cross ARCH=mips
All errors (new ones prefixed by >>):
In file included from arch/mips/include/asm/io.h:32:0,
from arch/mips/include/asm/page.h:176,
from arch/mips/vdso/vdso.h:26,
from arch/mips/vdso/gettimeofday.c:11:
arch/mips/include/asm/mach-cavium-octeon/mangle-port.h: In function
'__should_swizzle_bits':
>> arch/mips/include/asm/mach-cavium-octeon/mangle-port.h:19:40: error: right
>> shift count >= width of type [-Werror=shift-count-overflow]
unsigned long did = ((unsigned long)a >> 40) & 0xff;
^
cc1: all warnings being treated as errors
vim +19 arch/mips/include/asm/mach-cavium-octeon/mangle-port.h
13 #ifdef __BIG_ENDIAN
14
15 static inline bool __should_swizzle_bits(volatile void *a)
16 {
17 extern const bool octeon_should_swizzle_table[];
18
> 19 unsigned long did = ((unsigned long)a >> 40) & 0xff;
20 return octeon_should_swizzle_table[did];
21 }
22
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller
On 10/09/2016 19:12, Christoph Hellwig wrote: On Wed, Sep 07, 2016 at 01:25:13PM +0530, Parav Pandit wrote: a) delay cgroups support until the grand rewrite is done b) add it now and deal with the consequences later Can we do (b) now and differ adding any HW resources to cgroup until they are clearly called out. Architecture and APIs are already in place to support this. Sounds fine to me. The only thing I want to avoid is pie in the sky "future proofing" that leads to horrible architectures. And I assume that's what Matan proposed. NO, that not what I proposed. User-kernel API/ABI should be designed with drivers differences in mind. The internal design or internals APIs could ignore such things as they can be changed later.
Re: UBSAN: Undefined behaviour in arch/powerpc/kernel/cputable.c
> Does this fix it? Yes, thank you! > diff --git a/arch/powerpc/include/asm/cpu_has_feature.h > b/arch/powerpc/include/asm/cpu_has_feature.h > index 2ef55f8968a2..b312b152461b 100644 > --- a/arch/powerpc/include/asm/cpu_has_feature.h > +++ b/arch/powerpc/include/asm/cpu_has_feature.h > @@ -15,7 +15,7 @@ static inline bool early_cpu_has_feature(unsigned long > feature) > #ifdef CONFIG_JUMP_LABEL_FEATURE_CHECKS > #include > > -#define NUM_CPU_FTR_KEYS 64 > +#define NUM_CPU_FTR_KEYS BITS_PER_LONG > > extern struct static_key_true cpu_feature_keys[NUM_CPU_FTR_KEYS]; > > -- Meelis Roos (mr...@linux.ee)
[PATCH 2/3] alpha: merge build rules of division routines
These four objects are generated by the same build rule, with different compile options. The build rules can be merged. Signed-off-by: Masahiro Yamada --- arch/alpha/lib/Makefile | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/arch/alpha/lib/Makefile b/arch/alpha/lib/Makefile index 7b694fe..5f12e9d 100644 --- a/arch/alpha/lib/Makefile +++ b/arch/alpha/lib/Makefile @@ -46,11 +46,6 @@ AFLAGS___remqu.o = -DREM AFLAGS___divlu.o = -DDIV -DINTSIZE AFLAGS___remlu.o = -DREM -DINTSIZE -$(obj)/__divqu.o: $(src)/$(ev6-y)divide.S - $(cmd_as_o_S) -$(obj)/__remqu.o: $(src)/$(ev6-y)divide.S - $(cmd_as_o_S) -$(obj)/__divlu.o: $(src)/$(ev6-y)divide.S - $(cmd_as_o_S) -$(obj)/__remlu.o: $(src)/$(ev6-y)divide.S +$(addprefix $(obj)/,__divqu.o __remqu.o __divlu.o __remlu.o): \ + $(src)/$(ev6-y)divide.S $(cmd_as_o_S) -- 1.9.1
[PATCH 3/3] alpha: make short build log available for division routines
This enables the Kbuild standard log style as follows: AS arch/alpha/lib/__divlu.o AS arch/alpha/lib/__divqu.o AS arch/alpha/lib/__remlu.o AS arch/alpha/lib/__remqu.o Signed-off-by: Masahiro Yamada --- arch/alpha/lib/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/alpha/lib/Makefile b/arch/alpha/lib/Makefile index 5f12e9d..7083434 100644 --- a/arch/alpha/lib/Makefile +++ b/arch/alpha/lib/Makefile @@ -47,5 +47,5 @@ AFLAGS___divlu.o = -DDIV -DINTSIZE AFLAGS___remlu.o = -DREM -DINTSIZE $(addprefix $(obj)/,__divqu.o __remqu.o __divlu.o __remlu.o): \ - $(src)/$(ev6-y)divide.S - $(cmd_as_o_S) + $(src)/$(ev6-y)divide.S FORCE + $(call if_changed_rule,as_o_S) -- 1.9.1
[PATCH 1/3] alpha: add $(src)/ rather than $(obj)/ to make source file path
$(ev6-y)divide.S is a source file, not a build-time generated file. So, it should be prefixed with $(src)/ rather than $(obj)/. Signed-off-by: Masahiro Yamada --- arch/alpha/lib/Makefile | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/alpha/lib/Makefile b/arch/alpha/lib/Makefile index 5966074..7b694fe 100644 --- a/arch/alpha/lib/Makefile +++ b/arch/alpha/lib/Makefile @@ -46,11 +46,11 @@ AFLAGS___remqu.o = -DREM AFLAGS___divlu.o = -DDIV -DINTSIZE AFLAGS___remlu.o = -DREM -DINTSIZE -$(obj)/__divqu.o: $(obj)/$(ev6-y)divide.S +$(obj)/__divqu.o: $(src)/$(ev6-y)divide.S $(cmd_as_o_S) -$(obj)/__remqu.o: $(obj)/$(ev6-y)divide.S +$(obj)/__remqu.o: $(src)/$(ev6-y)divide.S $(cmd_as_o_S) -$(obj)/__divlu.o: $(obj)/$(ev6-y)divide.S +$(obj)/__divlu.o: $(src)/$(ev6-y)divide.S $(cmd_as_o_S) -$(obj)/__remlu.o: $(obj)/$(ev6-y)divide.S +$(obj)/__remlu.o: $(src)/$(ev6-y)divide.S $(cmd_as_o_S) -- 1.9.1
[PATCH 0/3] alpha: improvements of arch/alpha/lib/Makefile
While building for Alpha architecture, I noticed ugly long log for division routines. So, I took a look at the Makefile. Here is a series of build rule cleanups. Masahiro Yamada (3): alpha: add $(src)/ rather than $(obj)/ to make source file path alpha: merge build rules of division routines alpha: make short build log available for division routines arch/alpha/lib/Makefile | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) -- 1.9.1
Re: [PATCH] pinctrl: cherryview: Do not mask all interrupts on probe
On Fri, Sep 09, 2016 at 11:58:32AM +0300, Mika Westerberg wrote:
> On Fri, Sep 09, 2016 at 04:23:58PM +0800, Phidias Chiang wrote:
> > On Fri, Sep 09, 2016 at 09:18:34AM +0300, Mika Westerberg wrote:
> > > On Fri, Sep 09, 2016 at 12:28:43AM +0800, Phidias Chiang wrote:
> > >
> > > Hmm, how can that happen? The patch removes clearing of INTMASK and only
> > > other place where it is cleared temporarily is on resume. Can you add
> > > dev_info() calls like:
> > >
> > > /* Clear all interrupts */
> > > chv_writel(0x, pctrl->regs + CHV_INTSTAT);
> > > dev_info(pctrl->dev, "INTMASK0: 0x%08x\n", readl(pctrl->regs +
> > > CHV_INTMASK));
> > >
> > > ...
> > >
> > > gpiochip_set_chained_irqchip(chip, &chv_gpio_irqchip, irq,
> > >chv_gpio_irq_handler);
> > > dev_info(pctrl->dev, "INTMASK1: 0x%08x\n", readl(pctrl->regs +
> > > CHV_INTMASK));
> > > return 0;
> > >
> > > It should print the same values both time.
> > >
> > > Also which interrupt does not work and can you send me output of
> > > /proc/interrupts?
> >
> > Output in dmesg:
> > [2.054475] cherryview-pinctrl INT33FF:00: INTMASK0: 0x0006
> > [2.055247] cherryview-pinctrl INT33FF:00: INTMASK1: 0x
> > [2.055375] cherryview-pinctrl INT33FF:01: INTMASK0: 0x4000
> > [2.056931] cherryview-pinctrl INT33FF:01: INTMASK1: 0x
> > [2.057036] cherryview-pinctrl INT33FF:02: INTMASK0: 0x
> > [2.057367] cherryview-pinctrl INT33FF:02: INTMASK1: 0x
> > [2.057489] cherryview-pinctrl INT33FF:03: INTMASK0: 0x
> > [2.058337] cherryview-pinctrl INT33FF:03: INTMASK1: 0x
> >
> > So it's somehow got cleared in the process after.
>
> Only other place where we touch INTMASK register is
> chv_gpio_irq_mask_unmask(). Can you add some debug there to find out the
> caller?
Something like this:
diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c
b/drivers/pinctrl/intel/pinctrl-cherryview.c
index 0fe8fad..95fa3b1 100644
--- a/drivers/pinctrl/intel/pinctrl-cherryview.c
+++ b/drivers/pinctrl/intel/pinctrl-cherryview.c
@@ -1357,6 +1357,11 @@ static void chv_gpio_irq_mask_unmask(struct irq_data *d,
bool mask)
value |= BIT(intr_line);
chv_writel(value, pctrl->regs + CHV_INTMASK);
+ if (printk_ratelimit()) {
+ dev_info(pctrl->dev, "%smask pin %u intmask 0x%08x\n",
+mask ? "" : "un", pin, readl(pctrl->regs +
CHV_INTMASK));
+ }
+
raw_spin_unlock_irqrestore(&chv_lock, flags);
}
drivers/media/v4l2-core/videobuf2-dma-contig.c:486:2: error: implicit declaration of function 'dma_get_cache_alignment'
Hi Hans,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 98ac9a608dc79ba8a20cee77fe959a6dfccdaa63
commit: c1023ba74fc77dc56dc317bd98f5060aab889ac1 [media]
drivers/media/platform/Kconfig: fix VIDEO_MEDIATEK_VCODEC dependency
date: 9 weeks ago
config: m32r-allmodconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 4.9.0
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout c1023ba74fc77dc56dc317bd98f5060aab889ac1
# save the attached .config to linux build tree
make.cross ARCH=m32r
All errors (new ones prefixed by >>):
drivers/media/v4l2-core/videobuf2-dma-contig.c: In function
'vb2_dc_get_userptr':
>> drivers/media/v4l2-core/videobuf2-dma-contig.c:486:2: error: implicit
>> declaration of function 'dma_get_cache_alignment'
>> [-Werror=implicit-function-declaration]
unsigned long dma_align = dma_get_cache_alignment();
^
cc1: some warnings being treated as errors
vim +/dma_get_cache_alignment +486
drivers/media/v4l2-core/videobuf2-dma-contig.c
774d2301 drivers/media/v4l2-core/videobuf2-dma-contig.c Marek Szyprowski
2013-06-19 470 {
774d2301 drivers/media/v4l2-core/videobuf2-dma-contig.c Marek Szyprowski
2013-06-19 471 /* really, we cannot do anything better at this point */
774d2301 drivers/media/v4l2-core/videobuf2-dma-contig.c Marek Szyprowski
2013-06-19 472 return (dma_addr_t)(pfn) << PAGE_SHIFT;
774d2301 drivers/media/v4l2-core/videobuf2-dma-contig.c Marek Szyprowski
2013-06-19 473 }
774d2301 drivers/media/v4l2-core/videobuf2-dma-contig.c Marek Szyprowski
2013-06-19 474 #endif
774d2301 drivers/media/v4l2-core/videobuf2-dma-contig.c Marek Szyprowski
2013-06-19 475
36c0f8b3 drivers/media/v4l2-core/videobuf2-dma-contig.c Hans Verkuil
2016-04-15 476 static void *vb2_dc_get_userptr(struct device *dev, unsigned
long vaddr,
cd474037 drivers/media/v4l2-core/videobuf2-dma-contig.c Hans Verkuil
2014-11-18 477 unsigned long size, enum dma_data_direction dma_dir)
1a758d4e drivers/media/video/videobuf2-dma-contig.c Pawel Osciak
2010-10-11 478 {
1a758d4e drivers/media/video/videobuf2-dma-contig.c Pawel Osciak
2010-10-11 479 struct vb2_dc_buf *buf;
fb639eb3 drivers/media/v4l2-core/videobuf2-dma-contig.c Jan Kara
2015-07-13 480 struct frame_vector *vec;
e15dab75 drivers/media/v4l2-core/videobuf2-dma-contig.c Tomasz Stanislawski
2012-06-14 481 unsigned long offset;
fb639eb3 drivers/media/v4l2-core/videobuf2-dma-contig.c Jan Kara
2015-07-13 482 int n_pages, i;
e15dab75 drivers/media/v4l2-core/videobuf2-dma-contig.c Tomasz Stanislawski
2012-06-14 483 int ret = 0;
e15dab75 drivers/media/v4l2-core/videobuf2-dma-contig.c Tomasz Stanislawski
2012-06-14 484 struct sg_table *sgt;
e15dab75 drivers/media/v4l2-core/videobuf2-dma-contig.c Tomasz Stanislawski
2012-06-14 485 unsigned long contig_size;
d81e870d drivers/media/v4l2-core/videobuf2-dma-contig.c Marek Szyprowski
2012-06-12 @486 unsigned long dma_align = dma_get_cache_alignment();
251a79f8 drivers/media/v4l2-core/videobuf2-dma-contig.c Hans Verkuil
2014-11-18 487 DEFINE_DMA_ATTRS(attrs);
251a79f8 drivers/media/v4l2-core/videobuf2-dma-contig.c Hans Verkuil
2014-11-18 488
251a79f8 drivers/media/v4l2-core/videobuf2-dma-contig.c Hans Verkuil
2014-11-18 489 dma_set_attr(DMA_ATTR_SKIP_CPU_SYNC, &attrs);
d81e870d drivers/media/v4l2-core/videobuf2-dma-contig.c Marek Szyprowski
2012-06-12 490
d81e870d drivers/media/v4l2-core/videobuf2-dma-contig.c Marek Szyprowski
2012-06-12 491 /* Only cache aligned DMA transfers are reliable */
d81e870d drivers/media/v4l2-core/videobuf2-dma-contig.c Marek Szyprowski
2012-06-12 492 if (!IS_ALIGNED(vaddr | size, dma_align)) {
d81e870d drivers/media/v4l2-core/videobuf2-dma-contig.c Marek Szyprowski
2012-06-12 493 pr_debug("user data must be aligned to %lu
bytes\n", dma_align);
d81e870d drivers/media/v4l2-core/videobuf2-dma-contig.c Marek Szyprowski
2012-06-12 494 return ERR_PTR(-EINVAL);
:: The code at line 486 was first introduced by commit
:: d81e870d5afa1b0a95ea94c4052d3c7e973fae8c [media] v4l: vb2-dma-contig:
fail if user ptr buffer is not correctly aligned
:: TO: Marek Szyprowski
:: CC: Mauro Carvalho Chehab
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
[PATCH] pinctrl: ret needs to be an int for -ve return value from regmap_update_bits
From: Colin Ian King
Macro regmap_update_bits can return a -ve on an error value so ret
needs to be an integer rather than a bool type.
Fixes warning found by static analysis with cppcheck:
[drivers/pinctrl/aspeed/pinctrl-aspeed.c:192]: (warning) Comparison of
a boolean expression with an integer other than 0 or 1.
Signed-off-by: Colin Ian King
---
drivers/pinctrl/aspeed/pinctrl-aspeed.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
index 7d461fc..75935ab 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
@@ -166,7 +166,7 @@ static bool aspeed_sig_expr_set(const struct
aspeed_sig_expr *expr,
bool enable, struct regmap *map)
{
int i;
- bool ret;
+ int ret;
ret = aspeed_sig_expr_eval(expr, enable, map);
if (ret)
--
2.9.3
Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller
On 10/09/2016 20:01, Jason Gunthorpe wrote:
On Sat, Sep 10, 2016 at 06:14:42PM +0200, Christoph Hellwig wrote:
OFVWG meetings have absolutely zero relevance for Linux development.
Well, to be fair there are a fair number of kernel developers on that
particular call..
More "flexibility" for drivers just means giving up on designing a
coherent API and leaving it to drivers authors to add crap to their
own drivers. That's a major step backwards.
Sadly, it isn't a step backwards, it is status quo - at least as far
as the uapi is concerned.
Every single user space driver has its own private abi file, carefully
hidden in their driver, and dutifully copied over to user space:
providers/cxgb3/iwch-abi.h
providers/cxgb4/cxgb4-abi.h
providers/hfi1verbs/hfi-abi.h
providers/i40iw/i40iw-abi.h
providers/ipathverbs/ipath-abi.h
providers/mlx4/mlx4-abi.h
providers/mlx5/mlx5-abi.h
providers/mthca/mthca-abi.h
providers/nes/nes-abi.h
providers/ocrdma/ocrdma_abi.h
providers/rxe/rxe-abi.h
Just to pick two random examples:
struct mlx5_create_cq {
struct ibv_create_cqibv_cmd;
__u64 buf_addr;
__u64 db_addr;
__u32 cqe_size;
};
struct iwch_create_cq {
struct ibv_create_cq ibv_cmd;
uint64_t user_rptr_addr;
};
Love to hear ideas on a way forward that doesn't involve rewriting
everything :(
Yeah, unfortunately, the RDMA ABI is more driver specific ABI than a
common user-kernel ABI. I guess this will become even worse, as the RDMA
subsystem is evolving to serve more drivers with different object types.
For example, I would like to hear how hfi1 are going to define their
user-kernel ABI (once they leave the custom ioctls).
They should not be using the code in drivers/infiniband. usnic is such
an example of a driver that should never have been added in it's current
form.
+1
Jason
Matan
Re: Linux 3.14.79
diff --git a/Makefile b/Makefile
index 74346f0d89c1..0ed6ce300543 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 14
-SUBLEVEL = 78
+SUBLEVEL = 79
EXTRAVERSION =
NAME = Remembering Coco
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index a413f76e84d4..1b01adf1d406 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1084,7 +1084,7 @@ void hidinput_hid_event(struct hid_device *hid, struct
hid_field *field, struct
return;
/* report the usage code as scancode if the key status has changed */
- if (usage->type == EV_KEY && !!test_bit(usage->code, input->key) !=
value)
+ if (usage->type == EV_KEY && (!!test_bit(usage->code, input->key)) !=
value)
input_event(input, EV_MSC, MSC_SCAN, usage->hid);
input_event(input, usage->type, usage->code, value);
diff --git a/drivers/media/dvb-frontends/stb6100.c
b/drivers/media/dvb-frontends/stb6100.c
index cea175d19890..4ef8a5c7003e 100644
--- a/drivers/media/dvb-frontends/stb6100.c
+++ b/drivers/media/dvb-frontends/stb6100.c
@@ -193,7 +193,7 @@ static int stb6100_write_reg_range(struct stb6100_state
*state, u8 buf[], int st
.len= len + 1
};
- if (1 + len > sizeof(buf)) {
+ if (1 + len > sizeof(cmdbuf)) {
printk(KERN_WARNING
"%s: i2c wr: len=%d is too big!\n",
KBUILD_MODNAME, len);
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index fa78e45a2bee..de333c740203 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -665,9 +665,6 @@ static int can_changelink(struct net_device *dev,
}
}
- if (!data)
- return 0;
-
if (data[IFLA_CAN_CTRLMODE]) {
struct can_ctrlmode *cm;
diff --git a/drivers/s390/char/sclp_ctl.c b/drivers/s390/char/sclp_ctl.c
index 648cb86afd42..ea607a4a1bdd 100644
--- a/drivers/s390/char/sclp_ctl.c
+++ b/drivers/s390/char/sclp_ctl.c
@@ -56,6 +56,7 @@ static int sclp_ctl_ioctl_sccb(void __user *user_area)
{
struct sclp_ctl_sccb ctl_sccb;
struct sccb_header *sccb;
+ unsigned long copied;
int rc;
if (copy_from_user(&ctl_sccb, user_area, sizeof(ctl_sccb)))
@@ -65,14 +66,15 @@ static int sclp_ctl_ioctl_sccb(void __user *user_area)
sccb = (void *) get_zeroed_page(GFP_KERNEL | GFP_DMA);
if (!sccb)
return -ENOMEM;
- if (copy_from_user(sccb, u64_to_uptr(ctl_sccb.sccb), sizeof(*sccb))) {
+ copied = PAGE_SIZE -
+ copy_from_user(sccb, u64_to_uptr(ctl_sccb.sccb), PAGE_SIZE);
+ if (offsetof(struct sccb_header, length) +
+ sizeof(sccb->length) > copied || sccb->length > copied) {
rc = -EFAULT;
goto out_free;
}
- if (sccb->length > PAGE_SIZE || sccb->length < 8)
- return -EINVAL;
- if (copy_from_user(sccb, u64_to_uptr(ctl_sccb.sccb), sccb->length)) {
- rc = -EFAULT;
+ if (sccb->length < 8) {
+ rc = -EINVAL;
goto out_free;
}
rc = sclp_sync_request(ctl_sccb.cmdw, sccb);
diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index f4b9ac4ef16e..872ca84b3789 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -3172,7 +3172,7 @@ be_sgl_create_contiguous(void *virtual_address,
{
WARN_ON(!virtual_address);
WARN_ON(!physical_address);
- WARN_ON(!length > 0);
+ WARN_ON(!length);
WARN_ON(!sgl);
sgl->va = virtual_address;
diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c
b/drivers/staging/comedi/drivers/ni_mio_common.c
index 457b88481db0..3312ae622284 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -4404,7 +4404,7 @@ static int ni_E_init(struct comedi_device *dev)
else
s->maxdata = 0xff;
s->insn_read = ni_tio_insn_read;
- s->insn_write = ni_tio_insn_read;
+ s->insn_write = ni_tio_insn_write;
s->insn_config = ni_tio_insn_config;
#ifdef PCIDMA
s->subdev_flags |= SDF_CMD_READ /* | SDF_CMD_WRITE */;
diff --git a/fs/dcache.c b/fs/dcache.c
index 47c06888dc05..4d170433c647 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -2652,6 +2652,7 @@ static void __d_materialise_dentry(struct dentry *dentry,
struct dentry *anon)
switch_names(dentry, anon);
swap(dentry->d_name.hash, anon->d_name.hash);
+ dentry->d_flags |= DCACHE_RCUACCESS;
dentry->d_parent = dentry;
list_del_init(&dentry->d_child);
anon->d_parent = dparent;
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 4ce824197b81..712f84308bc8 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -2071,6 +2071,7 @@ void ext4_group
Linux 3.14.79
- NOTE - the 3.14.y kernel series is now end-of-life. It will not be receiving any more updates and should no longer be used at all. Please use 4.4 if you want a LTS kernel that will last for another year, or even better yet, just use the normal stable releases as those will always contain the latest fixes and updates. - I'm announcing the release of the 3.14.79 kernel. All users of the 3.14 kernel series must upgrade. The updated 3.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.14.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 +- drivers/hid/hid-input.c|2 +- drivers/media/dvb-frontends/stb6100.c |2 +- drivers/net/can/dev.c |3 --- drivers/s390/char/sclp_ctl.c | 12 +++- drivers/scsi/be2iscsi/be_main.c|2 +- drivers/staging/comedi/drivers/ni_mio_common.c |2 +- fs/dcache.c|1 + fs/ext4/super.c| 18 +- mm/memory.c| 14 -- net/rds/recv.c |2 ++ sound/pci/oxygen/oxygen_mixer.c|2 +- 12 files changed, 45 insertions(+), 17 deletions(-) Alexander Shiyan (1): stb6100: fix buffer length check in stb6100_write_reg_range() Andrea Arcangeli (1): mm: thp: fix SMP race condition between THP page fault and MADV_DONTNEED Greg Kroah-Hartman (2): Revert "can: fix handling of unmodifiable configuration options fix" Linux 3.14.79 Ian Abbott (1): staging: comedi: ni_mio_common: fix wrong insn_write handler James C Boyd (1): HID: hid-input: Add parentheses to quell gcc warning Kangjie Lu (1): rds: fix an infoleak in rds_inc_info_copy Martin Schwidefsky (1): s390/sclp_ctl: fix potential information leak with /dev/sclp Theodore Ts'o (1): ext4: validate that metadata blocks do not overlap superblock Tim Gardner (1): be2iscsi: Fix bogus WARN_ON length check Tomer Barletz (1): ALSA: oxygen: Fix logical-not-parentheses warning Willy Tarreau (1): fix d_walk()/non-delayed __d_free() race signature.asc Description: PGP signature
Re: [v2] musb: omap2430: do not assume balanced enable()/disable()
Hi Tony, On Saturday 10 Sep 2016 06:07:50 Tony Lindgren wrote: > * Andreas Kemnade [160910 04:27]: > > On Fri, 9 Sep 2016 16:40:15 -0700 Tony Lindgren wrote: > >> * Tony Lindgren [160909 14:33]: > >>> * Andreas Kemnade [160909 14:22]: > We have two independant things: > 1. phy-twl4030-usb (and perhaps others) do not enable > > the phy enough to allow charging on pm_runtime_get(). > That is fixed by my phy-related patches. > >>> > >>> OK > >>> > 2. phy_power_off/on() in called in an unbalanced way if > it is called behind musb_platform_enable()/disable() > as it happens in omap2430.c. Two ways to fix it: > a) prevent phy_power_off()/on() to be called in > an unbalanced way in omap240.c > > b) prevent musb_platform_enable() > musb_platform_disable() to be called in an > unbalanced way by fixing musb_core.c > > Fixing 1. is enough on gta04 to fix charging and hide 2. enough to > have gadget working for the most common usecases. (not using > twl4030-charger would not work yet) > But in the longer term 2. has to be fixed too. > >>> > >>> Sounds like option 2b here is the real fix. > >> > >> And doing full option 2b would be intrusive because of musb_stop > >> also calling musb_platform_disable. Here's a suggested fix for > >> v4.8-rc cycle. > > > > musb_platform_disable() in musb_stop() seems to be balanced. > > > > from my list in an earlier mail: > > musb_platform_disable() in musb_remove() called upon module removal > > > > To my analysis this is odd because musb_stop() is also called indirectly > > upon removal. > > But topic that can be left for later. > > OK will update the patch description. You probaby should attempt > to do a patch to make the calls paired as you already know what > needs to be done there.. > > >> Seems to work for me for omap3 torpedo using phy-twl4030-usb, > >> omap4 pandaboard es using phy-twl6030-usb and am335x beaglebone > >> black using dsps glue. Also PM runtime works on omap3. > >> > >> This patch causes a slight merge conlict with Andrea's patches, > >> as listed in #1 above, but we should probably merge this first > >> as a fix. That is assuming it does not cause side effects to > >> Andrea's phy-twl4030-usb charger test case. > > > > Hmm, if the patch will gender-change me, then a clear NAK ;-) > > Sorry typo there, s/Andrea/Andreas/, no need for other radical > changes :) > > >> Can you guys please test? If things work I'll resend the > >> patch with proper tested-bys and acks. > > > > I tested the patch without any other musb/phy-fixes. > > No regressions. It fixes Gadget to be usable. Charging seems > > not to be totally stable. I will check my phy-patches > > on top of that again. > > PM runtime probably still desires some work on it. > > But I give a clear Ack for merging this one first. > > OK good to hear & thanks for testing. Let's see what Laurent > says. I say Tested-by: Laurent Pinchart Acked-by: Laurent Pinchart Thank you for the fix. -- Regards, Laurent Pinchart
[GIT PULL] USB driver fixes for 4.8-rc6
The following changes since commit c6935931c1894ff857616ff8549b61236a19148f:
Linux 4.8-rc5 (2016-09-04 14:31:46 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.8-rc6
for you to fetch changes up to 6b98174b957ce87e0efe7c675d6cfd9e4c7a1912:
Merge tag 'fixes-for-v4.8-rc6' of
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
(2016-09-09 15:11:35 +0200)
USB fixes for 4.8-rc6
Here are some small USB gadget, phy, and xhci fixes for 4.8-rc6.
All of these resolve minor issues that have been reported, and all have
been in linux-next with no reported issues.
Signed-off-by: Greg Kroah-Hartman
Clemens Gruber (1):
usb: chipidea: udc: fix NULL ptr dereference in isr_setup_status_phase
Colin Ian King (1):
usb: gadget: prevent potenial null pointer dereference on skb->len
Fabio Estevam (1):
usb: phy: phy-generic: Check clk_prepare_enable() error
Felipe Balbi (1):
usb: dwc3: pci: fix build warning on !PM_SLEEP
Greg Kroah-Hartman (2):
Merge tag 'usb-ci-v4.8-rc6' of git://git.kernel.org/.../peter.chen/usb
into usb-linus
Merge tag 'fixes-for-v4.8-rc6' of git://git.kernel.org/.../balbi/usb into
usb-linus
John Youn (1):
Revert "usb: dwc3: gadget: always decrement by 1"
Mathias Nyman (1):
xhci: fix null pointer dereference in stop command timeout function
Yoshihiro Shimoda (2):
usb: gadget: udc: renesas-usb3: clear VBOUT bit in DRD_CON
usb: renesas_usbhs: fix clearing the {BRDY,BEMP}STS condition
drivers/usb/chipidea/udc.c| 9 +
drivers/usb/dwc3/dwc3-pci.c | 4 +++-
drivers/usb/dwc3/gadget.c | 5 -
drivers/usb/gadget/function/f_eem.c | 2 +-
drivers/usb/gadget/udc/renesas_usb3.c | 2 ++
drivers/usb/host/xhci-ring.c | 6 +-
drivers/usb/phy/phy-generic.c | 8 ++--
drivers/usb/renesas_usbhs/mod.c | 11 +--
8 files changed, 39 insertions(+), 8 deletions(-)
[GIT PULL] Staging/IIO driver fixes for 4.8-rc6
The following changes since commit c6935931c1894ff857616ff8549b61236a19148f: Linux 4.8-rc5 (2016-09-04 14:31:46 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ tags/staging-4.8-rc6 for you to fetch changes up to 72d508ad488a63678396cf1039fc5a65e04caa9e: Merge tag 'iio-fixes-for-4.8b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus (2016-09-09 13:44:37 +0200) Staging/IIO fixes for 4.8-rc6 Here are a few small IIO fixes for 4.8-rc6. Nothing major, full details are in the shortlog, all of these have been in linux-next with no reported issues. Signed-off-by: Greg Kroah-Hartman Colin Ian King (1): iio: ensure ret is initialized to zero before entering do loop Greg Kroah-Hartman (1): Merge tag 'iio-fixes-for-4.8b' of git://git.kernel.org/.../jic23/iio into staging-linus Gregor Boirie (2): tools:iio:iio_generic_buffer: fix trigger-less mode iio:core: fix IIO_VAL_FRACTIONAL sign handling Kweh, Hock Leong (1): iio: fix pressure data output unit in hid-sensor-attributes Linus Walleij (1): iio: accel: kxsd9: Fix scaling bug Olof Johansson (1): iio: accel: bmc150: reset chip at init time drivers/iio/accel/bmc150-accel-core.c | 11 +++ drivers/iio/accel/kxsd9.c | 1 + drivers/iio/common/hid-sensors/hid-sensor-attributes.c | 4 ++-- drivers/iio/industrialio-buffer.c | 4 ++-- drivers/iio/industrialio-core.c| 5 ++--- tools/iio/iio_generic_buffer.c | 2 +- 6 files changed, 19 insertions(+), 8 deletions(-)
[PATCH kernel.org] 3.14 is now dead
The 3.14 longterm kernel is now end-of-life, so remove it from the website. Signed-off-by: Greg Kroah-Hartman diff --git a/content/releases.rst b/content/releases.rst index fe701e3c543d..3c2eb973f66b 100644 --- a/content/releases.rst +++ b/content/releases.rst @@ -44,7 +44,6 @@ Longterm 4.1 Sasha Levin 2015-06-21 Sep, 2017 3.18 Sasha Levin 2014-12-07 Jan, 2017 3.16 Ben Hutchings2014-08-03 Apr, 2020 -3.14 Greg Kroah-Hartman 2014-03-30 Aug, 2016 3.12 Jiri Slaby 2013-11-03 Jan, 2017 3.10 Willy Tarreau2013-06-30 Oct, 2017 3.4 Li Zefan 2012-05-20 Sep, 2016
Re: [PATCH 3/3] drivers: Add visorbus to the drivers/virt directory
On Tue, Aug 30, 2016 at 04:29:07PM +, Sell, Timothy C wrote: > E.g., so even though no obvious error-recovery occurs above in-response to > kzalloc() failures, the fact that -CONTROLVM_RESP_ERROR_KMALLOC_FAILED is > provided to bus_epilog() is in-fact sufficient to report the error. > > Is this making sense? Yes, it does a bit more, but, you should make this more explicit. > Can you suggest how we might modify our code to make this error-handling / > recovery strategy clearer? Have a real error be returned by the function, and then have the caller handle the error by propagating it back to the firmware through the message. That might save you a lot of boiler-plate error handling logic as well, right? That will make it obvious that if an error happens, it is caught, and how it is handled correctly. Does that help? thanks, greg k-h
STRICTLY CONFIDENTIAL
I have important transaction for you as next of kin to claim US$18.37m Mail me on my private email: chimwia...@gmail.com so i can send you more details Thanks Mr.Chim Wai Kim === DISCLAIMER: This email and any files it contains are confidential and intended for the use of the recipient(s) only. If you are not the intended recipient you should notify the sender immediately and destroy the material from your system.
Re: [PATCH] x86/apic: Use byte array apic_version[], not int array. Saves up to 96k
On Fri, Sep 09, 2016 at 10:32:04AM +0200, Denys Vlasenko wrote:
> This array is [MAX_LOCAL_APIC], and MAX_LOCAL_APIC can easily be up to 32k.
>
> This patch changes apic_version[] array elements from int to u8 -
> APIC version values as of year 2016 are no larger than 0x1f on all known CPUs.
> Version field in the APIC register is 8 bit wide - not likely
> to overflow byte range in foreseeable future.
>
> The "ver" argument of generic_processor_info(id,ver), which goes into
> apic_version[id],
> is also changed from int to u8: make it obvious that assignment can't
> overflow.
>
> generic_processor_info() has four callsites, none of them can put an
> out-of-range value
> into this argument.
Right, so I dug a bit into this and found:
http://marc.info/?l=linux-kernel&m=123230551709711
and
b2b815d80a5c ("x86: put trigger in to detect mismatched apic versions")
It is from 2009 and I don't know how relevant 16-bit APIC IDs are
anymore... I guess you probably want to run this by SGI folk first.
Otherwise I was going to propose to kill that apic_version array
altogether and cache only the version of the previous CPU and compare it
to the current one to catch mismatches...
Adding Mike to CC and leaving in the rest for reference.
> Signed-off-by: Denys Vlasenko
> CC: Ingo Molnar
> CC: Andy Lutomirski
> CC: "H. Peter Anvin"
> CC: Borislav Petkov
> CC: Brian Gerst
> CC: x...@kernel.org
> CC: linux-kernel@vger.kernel.org
> ---
> arch/x86/include/asm/mpspec.h | 4 ++--
> arch/x86/kernel/acpi/boot.c | 2 +-
> arch/x86/kernel/apic/apic.c | 4 ++--
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
> index b07233b..a0bc349 100644
> --- a/arch/x86/include/asm/mpspec.h
> +++ b/arch/x86/include/asm/mpspec.h
> @@ -6,7 +6,7 @@
> #include
> #include
>
> -extern int apic_version[];
> +extern u8 apic_version[];
> extern int pic_mode;
>
> #ifdef CONFIG_X86_32
> @@ -85,7 +85,7 @@ static inline void early_reserve_e820_mpc_new(void) { }
> #define default_get_smp_config x86_init_uint_noop
> #endif
>
> -int generic_processor_info(int apicid, int version);
> +int generic_processor_info(int apicid, u8 version);
>
> #define PHYSID_ARRAY_SIZEBITS_TO_LONGS(MAX_LOCAL_APIC)
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 90d84c3..fde236f 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -168,7 +168,7 @@ static int __init acpi_parse_madt(struct
> acpi_table_header *table)
> */
> static int acpi_register_lapic(int id, u32 acpiid, u8 enabled)
> {
> - unsigned int ver = 0;
> + u8 ver = 0;
> int cpu;
>
> if (id >= MAX_LOCAL_APIC) {
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index 50c95af..d5cc7c6 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -1837,7 +1837,7 @@ void __init register_lapic_address(unsigned long
> address)
> }
> }
>
> -int apic_version[MAX_LOCAL_APIC];
> +u8 apic_version[MAX_LOCAL_APIC];
>
> /*
> * Local APIC interrupts
> @@ -2027,7 +2027,7 @@ void disconnect_bsp_APIC(int virt_wire_setup)
> apic_write(APIC_LVT1, value);
> }
>
> -int generic_processor_info(int apicid, int version)
> +int generic_processor_info(int apicid, u8 version)
> {
> int cpu, max = nr_cpu_ids;
> bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,
> --
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
Re: [RESEND PATCH v7 3/4] usb: dwc2: assert phy reset when waking up in rk3288 platform
Hi Randy, [auto build test ERROR on rockchip/for-next] [also build test ERROR on v4.8-rc5 next-20160909] [cannot apply to phy/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/Randy-Li/the-fix-for-the-USB-HOST1-at-rk3288-platform/20160910-030348 base: https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git for-next config: arm-socfpga_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): drivers/usb/dwc2/core_intr.c: In function 'dwc2_handle_wakeup_detected_intr': >> drivers/usb/dwc2/core_intr.c:391:5: error: implicit declaration of function >> 'phy_reset' [-Werror=implicit-function-declaration] phy_reset(hsotg->phy); ^ cc1: some warnings being treated as errors vim +/phy_reset +391 drivers/usb/dwc2/core_intr.c 385 * It is a quirk in Rockchip RK3288, causing by 386 * a hardware bug. This will propagate out and 387 * eventually we'll re-enumerate the device. 388 * Not great but the best we can do. 389 */ 390 if (of_device_is_compatible(np, "rockchip,rk3288-usb")) > 391 phy_reset(hsotg->phy); 392 393 mod_timer(&hsotg->wkp_timer, 394jiffies + msecs_to_jiffies(71)); --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: DVB: Unable to find symbol dib7000p_attach()
On 08/25/2016 08:31 PM, Toralf Förster wrote: > Aug 25 20:28:27 t44 kernel: DVB: registering new adapter (Terratec Cinergy T > USB XXS (HD)/ T3) > Aug 25 20:28:27 t44 kernel: DVB: Unable to find symbol dib7000p_attach() > Aug 25 20:28:27 t44 kernel: dvb-usb: no frontend was attached by 'Terratec > Cinergy T USB XXS (HD)/ T3' Well, "solved" this with: CONFIG_TRIM_UNUSED_KSYMS=y /me wonders if that kernel options should be mandatory for the DVB-T adapter to not break functionality ? -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7
[PATCH] fs/ncpfs: Fix a build warning when CONFIG_NCPFS_NLS is not set
From: Borislav Petkov
I get this when doing randconfig builds:
fs/ncpfs/dir.c: In function ‘ncp_hash_dentry’:
fs/ncpfs/dir.c:136:23: warning: unused variable ‘sb’ [-Wunused-variable]
struct super_block *sb = dentry->d_sb;
because NCP_IO_TABLE macro is NULL in the !CONFIG_NCPFS_NLS case and @sb
remains unused then.
Sticking it into the macro directly takes care of the warning and the
code is still readable. :)
Signed-off-by: Borislav Petkov
Cc: Petr Vandrovec
Cc: Al Viro
---
fs/ncpfs/dir.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/ncpfs/dir.c b/fs/ncpfs/dir.c
index 17de5c13dfae..f5b594e2457c 100644
--- a/fs/ncpfs/dir.c
+++ b/fs/ncpfs/dir.c
@@ -133,12 +133,11 @@ ncp_hash_dentry(const struct dentry *dentry, struct qstr
*this)
return 0;
if (!ncp_case_sensitive(inode)) {
- struct super_block *sb = dentry->d_sb;
struct nls_table *t;
unsigned long hash;
int i;
- t = NCP_IO_TABLE(sb);
+ t = NCP_IO_TABLE(dentry->d_sb);
hash = init_name_hash(dentry);
for (i=0; ilen ; i++)
hash = partial_name_hash(ncp_tolower(t, this->name[i]),
--
2.10.0
[PATCH] drm/panel: simple: Fix bus_format for the Olimex LCD-OLinuXino-4.3TS
The format is RGB888 not RGB666.
Signed-off-by: Jonathan Liu
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 85143d1..d4aa68e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1186,7 +1186,7 @@ static const struct panel_desc olimex_lcd_olinuxino_43ts
= {
.width = 105,
.height = 67,
},
- .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
};
/*
--
2.9.3
RE: [PATCH] Fix chance of sign extension to nsec after its msb is set during calculation.
>> > > During the calculation of the nsec variable, "delta * tkr->mult" > >> > may cause overflow to the msb, if the suspended time is too long. > >> > In that case, we need to guarantee that the variable will not go > >> > through a sign extension during its shift, and thus it will result > >> > in a much higher value - close to the larget value of 64 bits. > >> > The following commit fixes this problem, which causes the following bug: > >> > Trying to connect through ftp to the os after a long enough > >> > suspended time will cause the nsec variable to get a much higher > >> > value after its shift because of sign extension, and thus the loop > >> > that follows some instructions afterwards, implemented in the > >> > inline function __iter_div_u64_rem, will take too long. > >> > > >> > Signed-off-by: Liav Rehana > >> > --- > >> > kernel/time/timekeeping.c |2 +- > >> > 1 files changed, 1 insertions(+), 1 deletions(-) > >> > > >> > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c > >> > index 479d25c..ddf56a5 100644 > >> > --- a/kernel/time/timekeeping.c > >> > +++ b/kernel/time/timekeeping.c > >> > @@ -305,7 +305,7 @@ static inline s64 timekeeping_delta_to_ns(struct > >> > tk_read_base *tkr, > >> > s64 nsec; > >> > > >> > nsec = delta * tkr->mult + tkr->xtime_nsec; > >> > - nsec >>= tkr->shift; > >> > + nsec = ((u64) nsec) >> tkr->shift; > >> > >> This typecast is just a baindaid. What happens if you double the suspend > >> time? > >> The multiplication will simply overflow. So the proper fix is to > >> sanity check delta and do multiple conversions if delta is big > >> enough. Preferrably this happens somewhere at the call site and not in > >> this hotpath function. > > > > As a side note. John, why is that stuff unsigned at all? Shouldn't we > > use > > u64 for all of this? > >E... My memory is quite foggy here. I think we just started way back when >with s64 to catch cases where there were negative nsec intervals. Looking >through the git logs it seems its > been that way since the beginning of the >generic timekeeping logic. > >For most cases here u64 is fine. There may be a few cases where we do have >valid negative nanosecond intervals, but I can't think of any off the top of >my head, and those can >probably be special cased. In light of your comment for that issue, I would like to change the type of the nsec variable to u64, as it will solve the sign extension problem. For that, I intend to change the type of that variable in the functions that define it, and in the struct that uses it in kernel/time/timekeeping.c. Do you think there are other references I should change. Or do you think there is a better solution ? Please provide your opinion on this matter. Thanks, Liav.
[PATCH v1 1/1] at25: fix debug and error messaging
The patch does the following:
- fixes specifiers and removes explicit casting of the parameters
- joins literals to one line
- increases readability of the parameters
Signed-off-by: Andy Shevchenko
---
drivers/misc/eeprom/at25.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/misc/eeprom/at25.c b/drivers/misc/eeprom/at25.c
index 2c6c7c8..5afe4cd 100644
--- a/drivers/misc/eeprom/at25.c
+++ b/drivers/misc/eeprom/at25.c
@@ -121,9 +121,8 @@ static int at25_ee_read(void *priv, unsigned int offset,
* this chip is clocked very slowly
*/
status = spi_sync(at25->spi, &m);
- dev_dbg(&at25->spi->dev,
- "read %Zd bytes at %d --> %d\n",
- count, offset, (int) status);
+ dev_dbg(&at25->spi->dev, "read %zu bytes at %d --> %zd\n",
+ count, offset, status);
mutex_unlock(&at25->lock);
return status;
@@ -167,8 +166,7 @@ static int at25_ee_write(void *priv, unsigned int off, void
*val, size_t count)
*cp = AT25_WREN;
status = spi_write(at25->spi, cp, 1);
if (status < 0) {
- dev_dbg(&at25->spi->dev, "WREN --> %d\n",
- (int) status);
+ dev_dbg(&at25->spi->dev, "WREN --> %d\n", status);
break;
}
@@ -196,9 +194,8 @@ static int at25_ee_write(void *priv, unsigned int off, void
*val, size_t count)
memcpy(cp, buf, segment);
status = spi_write(at25->spi, bounce,
segment + at25->addrlen + 1);
- dev_dbg(&at25->spi->dev,
- "write %u bytes at %u --> %d\n",
- segment, offset, (int) status);
+ dev_dbg(&at25->spi->dev, "write %u bytes at %u --> %d\n",
+ segment, offset, status);
if (status < 0)
break;
@@ -225,8 +222,7 @@ static int at25_ee_write(void *priv, unsigned int off, void
*val, size_t count)
if ((sr < 0) || (sr & AT25_SR_nRDY)) {
dev_err(&at25->spi->dev,
- "write %d bytes offset %d, "
- "timeout after %u msecs\n",
+ "write %u bytes offset %u, timeout after %u
msecs\n",
segment, offset,
jiffies_to_msecs(jiffies -
(timeout - EE_TIMEOUT)));
@@ -368,9 +364,7 @@ static int at25_probe(struct spi_device *spi)
return PTR_ERR(at25->nvmem);
dev_info(&spi->dev, "%d %s %s eeprom%s, pagesize %u\n",
- (chip.byte_len < 1024)
- ? chip.byte_len
- : (chip.byte_len / 1024),
+ (chip.byte_len < 1024) ? chip.byte_len : (chip.byte_len / 1024),
(chip.byte_len < 1024) ? "Byte" : "KByte",
at25->chip.name,
(chip.flags & EE_READONLY) ? " (readonly)" : "",
--
2.9.3
[PATCH v5] lib/bitmap.c: enhance bitmap syntax
From: Noam Camus
Today there are platforms with many CPUs (up to 4K).
Trying to boot only part of the CPUs may result in too long string.
For example lets take NPS platform that is part of arch/arc.
This platform have SMP system with 256 cores each with
16 HW threads (SMT machine) where HW thread appears as CPU to the kernel.
In this example there is total of 4K CPUs.
When one tries to boot only part of the HW threads from each core the
string representing the map may be long...
For example if for sake of performance we decided to boot only first half
of HW threads of each core the map will look like:
0-7,16-23,32-39,...,4080-4087
This patch introduce new syntax to accommodate with such use case.
I added an optional postfix to a range of CPUs which will choose
according to given modulo the desired range of reminders i.e.:
:sed_size/group_size
For example, above map can be described in new syntax like this:
0-4095:8/16
Note that this patch is backward compatible with current syntax.
Signed-off-by: Noam Camus
---
Documentation/kernel-parameters.txt | 15 ++
lib/bitmap.c| 50 ---
2 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 623502e..4f1e95b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -33,6 +33,21 @@ can also be entered as
Double-quotes can be used to protect spaces in values, e.g.:
param="spaces in here"
+Some of the kernel parameters takes list of CPUs as value e.g.:
+isolcpus, task_isolation, nohz_full, irqaffinity, rcu_nocbs.
+The format of this list is:
+,...,
+or
+-
+(must be a positive range in ascending order)
+or a mixture
+,...,-
+Note that for special case of range one can split range into equal size of
groups
+and for each group to use some amount form the begin of that group.
+-cpu number>:/
+For example one can add to its command line following parameter:
+isolcpus=1,2,10-20,100-2000:2/25
+
This document may not be entirely up to date and comprehensive. The command
"modinfo -p ${modulename}" shows a current list of all parameters of a loadable
module. Loadable modules, after being loaded into the running kernel, also
diff --git a/lib/bitmap.c b/lib/bitmap.c
index c66da50..9fb2cbc 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -496,6 +496,11 @@ EXPORT_SYMBOL(bitmap_print_to_pagebuf);
* ranges. Consecutively set bits are shown as two hyphen-separated
* decimal numbers, the smallest and largest bit numbers set in
* the range.
+ * Optionally each range can be postfixed to denote that only parts of it
+ * should be set. The range will divided to groups of specific size.
+ * From each group will be used only defined amount of bits.
+ * Syntax: range:used_size/group_size
+ * Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769
*
* Returns 0 on success, -errno on invalid input strings.
* Error values:
@@ -507,16 +512,20 @@ static int __bitmap_parselist(const char *buf, unsigned
int buflen,
int is_user, unsigned long *maskp,
int nmaskbits)
{
- unsigned a, b;
+ unsigned int a, b, old_a, old_b;
+ unsigned int group_size, used_size;
int c, old_c, totaldigits, ndigits;
const char __user __force *ubuf = (const char __user __force *)buf;
- int at_start, in_range;
+ int at_start, in_range, in_partial_range;
totaldigits = c = 0;
+ old_a = old_b = 0;
+ group_size = used_size = 0;
bitmap_zero(maskp, nmaskbits);
do {
at_start = 1;
in_range = 0;
+ in_partial_range = 0;
a = b = 0;
ndigits = totaldigits;
@@ -547,6 +556,24 @@ static int __bitmap_parselist(const char *buf, unsigned
int buflen,
if ((totaldigits != ndigits) && isspace(old_c))
return -EINVAL;
+ if (c == '/') {
+ used_size = a;
+ at_start = 1;
+ in_range = 0;
+ a = b = 0;
+ continue;
+ }
+
+ if (c == ':') {
+ old_a = a;
+ old_b = b;
+ at_start = 1;
+ in_range = 0;
+ in_partial_range = 1;
+ a = b = 0;
+ continue;
+ }
+
if (c == '-') {
if (at_start || in_range)
return -EINVAL;
@@ -567,15 +594,30 @@ static int __bitmap_parselist(const char *buf, unsigned
int buflen,
}
if (ndigits == tota
[PATCH] tpm: fix buffer overflow in /dev/tpm0
tpm_write() does not check whether the buffer has at least enough space for the header before passing it to tpm_transmit() so an overflow can happen. Signed-off-by: Jarkko Sakkinen --- drivers/char/tpm/tpm-interface.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index fd863ff..6a67f7f 100644 --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -337,6 +337,9 @@ ssize_t tpm_transmit(struct tpm_chip *chip, const u8 *buf, size_t bufsiz, u32 count, ordinal; unsigned long stop; + if (bufsiz < TPM_HEADER_SIZE) + return -EINVAL; + if (bufsiz > TPM_BUFSIZE) bufsiz = TPM_BUFSIZE; -- 2.7.4
Re: cmsg newgroup alt.sex.fetish.bool (was Re: [PATCH] arch: all: include: asm: bitops: Use bool instead of int for all bit test functions)
On 9/4/16 09:01, Al Viro wrote: > On Sun, Sep 04, 2016 at 06:36:56AM +0800, Chen Gang wrote: > >> And for all: shall I provide the proof for another archs? >> >> For me, Boolean gives additional chance to compiler to improve the code. > > Whereas for compiler it gives nothing. Not in those cases. > >> If the compiler can not improve the code, it can treat it as int simply. >> So theoretically, at least, Boolean should not be worse than int. > > Except for pointless code churn and pandering to irrational beliefs, that > is... For me, it is not quite suitable to get conclusion during discussing. > Please, RTFISO9899 and learn the semantics of _Bool; it's not that > complicated. > Start with 6.2.5[2,6] and 6.3.1.2, then look through 6.8.4 and 6.8.5 to > figure out the semantics of conditions in if/while/for. Note also 6.5.8, > 6.5.9, 6.5.13 and 6.5.14 and observe that type of (x > 5 && y < 1) is *NOT* > _Bool; it's int. > Yes, what you said above is true to me. But for (x > 5 && y < 1) will return 1 for true and 0 for false, although its' type is still int. So for compiler, it can simply treat it as Boolean type internally. For my original saying, I assume 2 things (excuse me, I did not mention originally): - I assume what I said is for pure Boolean functions, in our case, all functions intend to return 'Boolean' value (0 or 1) in most of archs, although they use int type as return value. - What I said is for compiler's optimization at middle language level and at instruction level (internal processing), not for language definition (interface for outside -- for C developers). For me, one way is: in middle language level, bool can be treated as int or long to be processed firstly, then in instruction level, the compiler performs additional optimization and qualification for bool. - So the compiler has additional chance for optimizing in instruction level. - Since for pure Boolean function, it is already sure that related int value must be 0 or 1, and the compiler should be smart enough to know that, so the output code need not additional qualifications. - So, for me, theoretically, bool is equal or better than int for pure bool functions, unless the compiler has performance bugs. > If you can show any improvement or loss in code generation in this case > (static inline int converted to static inline bool), I would really like to > see the details. As in .config/file/function/gcc version/target architecture. > Optimizer bugs happens, but they should be reported when found, and I would > expect _Bool handling to be _less_ exercised than that of normal logical > expressions, so loss is probably more likely. And yes, it also should be > reported. > At least for x86_64 arch, as far as I know, I can find the case which bool is better than int, but I can not find the case which worse than int. Thanks. -- Chen Gang (陈刚) Managing Natural Environments is the Duty of Human Beings.
[PATCH 0/6] constify gpio_chip structures
Constify gpio_chip structures --- drivers/gpio/gpio-arizona.c |2 +- drivers/gpio/gpio-bcm-kona.c |2 +- drivers/gpio/gpio-da9052.c|2 +- drivers/gpio/gpio-da9055.c|2 +- drivers/gpio/gpio-it87.c |2 +- drivers/gpio/gpio-lp873x.c|2 +- drivers/gpio/gpio-lpc18xx.c |2 +- drivers/gpio/gpio-pisosr.c|2 +- drivers/gpio/gpio-sch.c |2 +- drivers/gpio/gpio-stmpe.c |2 +- drivers/gpio/gpio-tc3589x.c |2 +- drivers/gpio/gpio-tpic2810.c |2 +- drivers/gpio/gpio-tps65086.c |2 +- drivers/gpio/gpio-tps65218.c |2 +- drivers/gpio/gpio-tps65912.c |2 +- drivers/gpio/gpio-ts4900.c|2 +- drivers/gpio/gpio-twl4030.c |2 +- drivers/gpio/gpio-wm831x.c|2 +- drivers/gpio/gpio-wm8350.c|2 +- drivers/gpio/gpio-wm8994.c|2 +- drivers/mfd/sm501.c |2 +- drivers/pinctrl/mediatek/pinctrl-mtk-common.c |2 +- drivers/pinctrl/stm32/pinctrl-stm32.c |2 +- sound/soc/codecs/rt5677.c |2 +- sound/soc/codecs/wm5100.c |2 +- sound/soc/codecs/wm8903.c |2 +- sound/soc/codecs/wm8962.c |2 +- sound/soc/codecs/wm8996.c |2 +- sound/soc/soc-ac97.c |2 +- 29 files changed, 29 insertions(+), 29 deletions(-)
[PATCH 2/6] mfd: sm501: constify gpio_chip structures
These structures are only used to copy into other structures, so declare
them as const.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
//
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct gpio_chip i@p = { ... };
@ok@
identifier r.i;
expression e;
position p;
@@
e = i@p;
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct gpio_chip e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct gpio_chip i = { ... };
//
Signed-off-by: Julia Lawall
---
drivers/mfd/sm501.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c
index 65cd0d2..4053435 100644
--- a/drivers/mfd/sm501.c
+++ b/drivers/mfd/sm501.c
@@ -1001,7 +1001,7 @@ static int sm501_gpio_output(struct gpio_chip *chip,
return 0;
}
-static struct gpio_chip gpio_chip_template = {
+static const struct gpio_chip gpio_chip_template = {
.ngpio = 32,
.direction_input= sm501_gpio_input,
.direction_output = sm501_gpio_output,
[PATCH 6/6] ASoC: constify gpio_chip structures
These structures are only used to copy into other structures, so declare
them as const.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
//
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct gpio_chip i@p = { ... };
@ok@
identifier r.i;
expression e;
position p;
@@
e = i@p;
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct gpio_chip e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct gpio_chip i = { ... };
//
Signed-off-by: Julia Lawall
---
sound/soc/codecs/rt5677.c |2 +-
sound/soc/codecs/wm5100.c |2 +-
sound/soc/codecs/wm8903.c |2 +-
sound/soc/codecs/wm8962.c |2 +-
sound/soc/codecs/wm8996.c |2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/wm5100.c b/sound/soc/codecs/wm5100.c
index 278467d..5605750 100644
--- a/sound/soc/codecs/wm5100.c
+++ b/sound/soc/codecs/wm5100.c
@@ -2285,7 +2285,7 @@ static int wm5100_gpio_direction_in(struct gpio_chip
*chip, unsigned offset)
(1 << WM5100_GP1_DIR_SHIFT));
}
-static struct gpio_chip wm5100_template_chip = {
+static const struct gpio_chip wm5100_template_chip = {
.label = "wm5100",
.owner = THIS_MODULE,
.direction_output = wm5100_gpio_direction_out,
diff --git a/sound/soc/codecs/wm8903.c b/sound/soc/codecs/wm8903.c
index 837c8b9..6e887c2 100644
--- a/sound/soc/codecs/wm8903.c
+++ b/sound/soc/codecs/wm8903.c
@@ -1830,7 +1830,7 @@ static void wm8903_gpio_set(struct gpio_chip *chip,
unsigned offset, int value)
!!value << WM8903_GP1_LVL_SHIFT);
}
-static struct gpio_chip wm8903_template_chip = {
+static const struct gpio_chip wm8903_template_chip = {
.label = "wm8903",
.owner = THIS_MODULE,
.request= wm8903_gpio_request,
diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c
index 9f67922..fd2731d 100644
--- a/sound/soc/codecs/wm8962.c
+++ b/sound/soc/codecs/wm8962.c
@@ -3357,7 +3357,7 @@ static int wm8962_gpio_direction_out(struct gpio_chip
*chip,
return 0;
}
-static struct gpio_chip wm8962_template_chip = {
+static const struct gpio_chip wm8962_template_chip = {
.label = "wm8962",
.owner = THIS_MODULE,
.request= wm8962_gpio_request,
diff --git a/sound/soc/codecs/wm8996.c b/sound/soc/codecs/wm8996.c
index 5eba8ff..8affa49 100644
--- a/sound/soc/codecs/wm8996.c
+++ b/sound/soc/codecs/wm8996.c
@@ -2184,7 +2184,7 @@ static int wm8996_gpio_direction_in(struct gpio_chip
*chip, unsigned offset)
(1 << WM8996_GP1_DIR_SHIFT));
}
-static struct gpio_chip wm8996_template_chip = {
+static const struct gpio_chip wm8996_template_chip = {
.label = "wm8996",
.owner = THIS_MODULE,
.direction_output = wm8996_gpio_direction_out,
diff --git a/sound/soc/codecs/rt5677.c b/sound/soc/codecs/rt5677.c
index 68268f2..7df422c 100644
--- a/sound/soc/codecs/rt5677.c
+++ b/sound/soc/codecs/rt5677.c
@@ -4657,7 +4657,7 @@ static int rt5677_to_irq(struct gpio_chip *chip, unsigned
offset)
return regmap_irq_get_virq(data, irq);
}
-static struct gpio_chip rt5677_template_chip = {
+static const struct gpio_chip rt5677_template_chip = {
.label = "rt5677",
.owner = THIS_MODULE,
.direction_output = rt5677_gpio_direction_out,
[PATCH 5/6] ASoC: ac97: constify gpio_chip structures
These structures are only used to copy into other structures, so declare
them as const.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
//
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct gpio_chip i@p = { ... };
@ok@
identifier r.i;
expression e;
position p;
@@
e = i@p;
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct gpio_chip e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct gpio_chip i = { ... };
//
Signed-off-by: Julia Lawall
---
sound/soc/soc-ac97.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/soc-ac97.c b/sound/soc/soc-ac97.c
index bc4a55b..6c8b0b0 100644
--- a/sound/soc/soc-ac97.c
+++ b/sound/soc/soc-ac97.c
@@ -116,7 +116,7 @@ static int snd_soc_ac97_gpio_direction_out(struct gpio_chip
*chip,
return snd_soc_update_bits(codec, AC97_GPIO_CFG, 1 << offset, 0);
}
-static struct gpio_chip snd_soc_ac97_gpio_chip = {
+static const struct gpio_chip snd_soc_ac97_gpio_chip = {
.label = "snd_soc_ac97",
.owner = THIS_MODULE,
.request= snd_soc_ac97_gpio_request,
[PATCH 1/6] gpio: constify gpio_chip structures
These structures are only used to copy into other structures, so declare
them as const.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
//
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct gpio_chip i@p = { ... };
@ok@
identifier r.i;
expression e;
position p;
@@
e = i@p;
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct gpio_chip e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct gpio_chip i = { ... };
//
Signed-off-by: Julia Lawall
---
drivers/gpio/gpio-arizona.c |2 +-
drivers/gpio/gpio-bcm-kona.c |2 +-
drivers/gpio/gpio-da9052.c |2 +-
drivers/gpio/gpio-da9055.c |2 +-
drivers/gpio/gpio-it87.c |2 +-
drivers/gpio/gpio-lp873x.c |2 +-
drivers/gpio/gpio-lpc18xx.c |2 +-
drivers/gpio/gpio-pisosr.c |2 +-
drivers/gpio/gpio-sch.c |2 +-
drivers/gpio/gpio-stmpe.c|2 +-
drivers/gpio/gpio-tc3589x.c |2 +-
drivers/gpio/gpio-tpic2810.c |2 +-
drivers/gpio/gpio-tps65086.c |2 +-
drivers/gpio/gpio-tps65218.c |2 +-
drivers/gpio/gpio-tps65912.c |2 +-
drivers/gpio/gpio-ts4900.c |2 +-
drivers/gpio/gpio-twl4030.c |2 +-
drivers/gpio/gpio-wm831x.c |2 +-
drivers/gpio/gpio-wm8350.c |2 +-
drivers/gpio/gpio-wm8994.c |2 +-
20 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpio/gpio-arizona.c b/drivers/gpio/gpio-arizona.c
index 9913704..4824628 100644
--- a/drivers/gpio/gpio-arizona.c
+++ b/drivers/gpio/gpio-arizona.c
@@ -79,7 +79,7 @@ static void arizona_gpio_set(struct gpio_chip *chip, unsigned
offset, int value)
ARIZONA_GPN_LVL, value);
}
-static struct gpio_chip template_chip = {
+static const struct gpio_chip template_chip = {
.label = "arizona",
.owner = THIS_MODULE,
.direction_input= arizona_gpio_direction_in,
diff --git a/drivers/gpio/gpio-wm831x.c b/drivers/gpio/gpio-wm831x.c
index 21f97bc..533707f 100644
--- a/drivers/gpio/gpio-wm831x.c
+++ b/drivers/gpio/gpio-wm831x.c
@@ -247,7 +247,7 @@ static void wm831x_gpio_dbg_show(struct seq_file *s, struct
gpio_chip *chip)
#define wm831x_gpio_dbg_show NULL
#endif
-static struct gpio_chip template_chip = {
+static const struct gpio_chip template_chip = {
.label = "wm831x",
.owner = THIS_MODULE,
.direction_input= wm831x_gpio_direction_in,
diff --git a/drivers/gpio/gpio-wm8350.c b/drivers/gpio/gpio-wm8350.c
index e976570..e46752e 100644
--- a/drivers/gpio/gpio-wm8350.c
+++ b/drivers/gpio/gpio-wm8350.c
@@ -93,7 +93,7 @@ static int wm8350_gpio_to_irq(struct gpio_chip *chip,
unsigned offset)
return wm8350->irq_base + WM8350_IRQ_GPIO(offset);
}
-static struct gpio_chip template_chip = {
+static const struct gpio_chip template_chip = {
.label = "wm8350",
.owner = THIS_MODULE,
.direction_input= wm8350_gpio_direction_in,
diff --git a/drivers/gpio/gpio-wm8994.c b/drivers/gpio/gpio-wm8994.c
index 2457aac..68410fd 100644
--- a/drivers/gpio/gpio-wm8994.c
+++ b/drivers/gpio/gpio-wm8994.c
@@ -249,7 +249,7 @@ static void wm8994_gpio_dbg_show(struct seq_file *s, struct
gpio_chip *chip)
#define wm8994_gpio_dbg_show NULL
#endif
-static struct gpio_chip template_chip = {
+static const struct gpio_chip template_chip = {
.label = "wm8994",
.owner = THIS_MODULE,
.request= wm8994_gpio_request,
diff --git a/drivers/gpio/gpio-it87.c b/drivers/gpio/gpio-it87.c
index 63a962d..45d29e4 100644
--- a/drivers/gpio/gpio-it87.c
+++ b/drivers/gpio/gpio-it87.c
@@ -273,7 +273,7 @@ exit:
return rc;
}
-static struct gpio_chip it87_template_chip = {
+static const struct gpio_chip it87_template_chip = {
.label = KBUILD_MODNAME,
.owner = THIS_MODULE,
.request= it87_gpio_request,
diff --git a/drivers/gpio/gpio-lp873x.c b/drivers/gpio/gpio-lp873x.c
index f10d49d..134f6b3 100644
--- a/drivers/gpio/gpio-lp873x.c
+++ b/drivers/gpio/gpio-lp873x.c
@@ -124,7 +124,7 @@ static int lp873x_gpio_set_single_ended(struct gpio_chip
*gc,
}
}
-static struct gpio_chip template_chip = {
+static const struct gpio_chip template_chip = {
.label = "lp873x-gpio",
.owner = THIS_MODULE,
.request= lp873x_gpio_request,
diff --git a/drivers/gpio/gpio-pisosr.c b/drivers/gpio/gpio-pisosr.c
index cb14b8d..f5545049 100644
--- a/drivers/gpio/gpio-pisosr.c
+++ b/drivers/gpio/gpio-pisosr.c
@@ -90,7 +90,7 @@ static int pisosr_gpio_get(struct gpio_chip *chip, unsigned
offset)
return (gpio->buffer[offset / 8] >> (offset % 8)) & 0x1;
}
-static struct gpio_chip template_chip = {
+static const stru
[PATCH 4/6] pinctrl: stm32: constify gpio_chip structures
These structures are only used to copy into other structures, so declare
them as const.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
//
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct gpio_chip i@p = { ... };
@ok@
identifier r.i;
expression e;
position p;
@@
e = i@p;
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct gpio_chip e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct gpio_chip i = { ... };
//
Signed-off-by: Julia Lawall
---
drivers/pinctrl/stm32/pinctrl-stm32.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c
b/drivers/pinctrl/stm32/pinctrl-stm32.c
index 4ae596b..6d92351 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -174,7 +174,7 @@ static int stm32_gpio_direction_output(struct gpio_chip
*chip,
return 0;
}
-static struct gpio_chip stm32_gpio_template = {
+static const struct gpio_chip stm32_gpio_template = {
.request= stm32_gpio_request,
.free = stm32_gpio_free,
.get= stm32_gpio_get,
[PATCH 3/6] pinctrl: mediatek: constify gpio_chip structures
These structures are only used to copy into other structures, so declare
them as const.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
//
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct gpio_chip i@p = { ... };
@ok@
identifier r.i;
expression e;
position p;
@@
e = i@p;
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct gpio_chip e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct gpio_chip i = { ... };
//
Signed-off-by: Julia Lawall
---
drivers/pinctrl/mediatek/pinctrl-mtk-common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index ba2b03d..f9aef2a 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -1054,7 +1054,7 @@ static int mtk_gpio_set_debounce(struct gpio_chip *chip,
unsigned offset,
return 0;
}
-static struct gpio_chip mtk_gpio_chip = {
+static const struct gpio_chip mtk_gpio_chip = {
.owner = THIS_MODULE,
.request= gpiochip_generic_request,
.free = gpiochip_generic_free,
Re: [BISECTED REGRESSION] v4.8-rc: DT/OCTEON driver probing broken
Hi! On 30.08.2016 00:39, Rob Herring wrote: > On Sun, Aug 28, 2016 at 7:22 AM, Aaro Koskinen wrote: >> On Sun, Aug 28, 2016 at 12:34:06PM +0200, Thorsten Leemhuis wrote: >> There is a fix proposal here: >> https://patchwork.linux-mips.org/patch/14041/ >> There is still few other boards remaining that use of_platform_bus_probe() >> from device_initcall, but who knows, maybe they are not affected. >> arch/microblaze/kernel/platform.c > xlnx,compound is going to fail to probe. I'm adding this to the default. > >> arch/mips/mti-malta/malta-dt.c > This should be fine. It does probe for "isa", but nothing in mainline > is using that. We can add it to the default when it does. > >> arch/mips/netlogic/xlp/dt.c > Should be okay with default. > >> arch/x86/platform/olpc/olpc_dt.c > This one needs fixing. Rob, did anything happen on this front? This issue is still on the list of regression for 4.8, and it seems to me nothing happened in the past ten days -- or is this discussed somewhere else?. Ciao, Thorsten
Re: [BISECTED REGRESSION] v4.8-rc: gpio-leds broken on OCTEON
Hi! On 25.08.2016 20:24, Aaro Koskinen wrote:
> On Wed, Aug 24, 2016 at 11:42:00AM -0500, Steven J. Hill wrote:
>> It is actually two patches that cause the breakage. The other is:
>>commit e55aeb6ba4e8cc3549bff1e75ea1d029324bce21
>>of/irq: Mark interrupt controllers as populated before initialisation
>> I needed to revert both of these in order to get MMC working on our 71xx and
>> 78xx boards. For our MMC, I got error messages from the MMC core of "Invalid
>> POWER GPIO" until I applied the second patch. I will have a fix worthy of
>> upstreaming today which will be posted today.
>
> The below change works for me...
>
> diff --git a/arch/mips/cavium-octeon/octeon-irq.c
> b/arch/mips/cavium-octeon/octeon-irq.c
> index 5a9b87b..5fd57c2 100644
> --- a/arch/mips/cavium-octeon/octeon-irq.c
> +++ b/arch/mips/cavium-octeon/octeon-irq.c
> @@ -1618,6 +1618,7 @@ static int __init octeon_irq_init_gpio(
> pr_warn("Cannot allocate memory for GPIO irq_domain.\n");
> return -ENOMEM;
> }
> + of_node_clear_flag(gpio_node, OF_POPULATED);
>
> return 0;
> }
This afaics wasn't merged and the discussion looks stalled. Was this
issue discussed elsewhere or even fixed in between? Just asking, because
this issue is on the list of regressions for 4.8.
Ciao, Thorsten
Re: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes
On Sat, Sep 10, 2016 at 07:52:53AM +, Matthew Wilcox wrote: > DAX code over to using iomap requires converting all of ext2 away from > buffer_head; are you saying he's wrong? Not sure if he's really saying that, but it's wrong for sure. Just to prove that I came up with a working ext2 iomap DAX implementation in a few hours today. I'll take a stab at ext4 and the block device as well and will post the updated series early next week - I'll need to take care of a few high priority todo list items first.
Re: [PATCH] tpm: fix buffer overflow in /dev/tpm0
On Sun, Sep 11, 2016 at 03:19:00PM +0300, Jarkko Sakkinen wrote: > tpm_write() does not check whether the buffer has at least enough space > for the header before passing it to tpm_transmit() so an overflow can > happen. > > Signed-off-by: Jarkko Sakkinen This is usable neither as read nor write primitive for an exploit. Still it makes sense to validate the input here. /Jarkko > --- > drivers/char/tpm/tpm-interface.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/char/tpm/tpm-interface.c > b/drivers/char/tpm/tpm-interface.c > index fd863ff..6a67f7f 100644 > --- a/drivers/char/tpm/tpm-interface.c > +++ b/drivers/char/tpm/tpm-interface.c > @@ -337,6 +337,9 @@ ssize_t tpm_transmit(struct tpm_chip *chip, const u8 > *buf, size_t bufsiz, > u32 count, ordinal; > unsigned long stop; > > + if (bufsiz < TPM_HEADER_SIZE) > + return -EINVAL; > + > if (bufsiz > TPM_BUFSIZE) > bufsiz = TPM_BUFSIZE; > > -- > 2.7.4 >
RE: [PATCH v6 2/8] thunderbolt: Updating the register definitions
On Sun, Sep 11 2016, 03:02 AM, Andreas Noever wrote: > On Mon, Aug 1, 2016 at 2:23 PM, Amir Levy wrote: > > Adding more Thunderbolt(TM) register definitions and some helper > > macros. > > Thinking about this again I would prefer it if you would put your definitions > into a separate file under icm/ (even if there is some duplication). The style > (bitfields vs. genmask) is different between the drivers and for a reader it > is > difficult to find out what is actually supposed to be used by the two drivers > (ring_desc vs tbt_buf_desc or the ring RING_INT_EN/DISABLE macros in the > header file vs. ring_interrupt_active in nhi.c). > > This would also completely separate the two drivers. > > Andreas > I'm also in favor of completely separating the drivers, but is it the right thing to do with the register definitions when the underlying registers layout is exactly the same? Note that bitfields are not so recommended when you care about the format/order of bits, like in the ring descriptor. Amir
[PATCH 14/26] spi: dw-pci: constify local structures
For structure types defined in the same file or local header files, find
top-level static structure declarations that have the following
properties:
1. Never reassigned.
2. Address never taken
3. Not passed to a top-level macro call
4. No pointer or array-typed field passed to a function or stored in a
variable.
Declare structures having all of these properties as const.
Done using Coccinelle.
Based on a suggestion by Joe Perches .
Signed-off-by: Julia Lawall
---
The semantic patch seems too long for a commit log, but is in the cover
letter.
drivers/spi/spi-dw-pci.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-dw-pci.c b/drivers/spi/spi-dw-pci.c
index ef7db75..60198a3 100644
--- a/drivers/spi/spi-dw-pci.c
+++ b/drivers/spi/spi-dw-pci.c
@@ -29,13 +29,13 @@ struct spi_pci_desc {
u16 bus_num;
};
-static struct spi_pci_desc spi_pci_mid_desc_1 = {
+static const struct spi_pci_desc spi_pci_mid_desc_1 = {
.setup = dw_spi_mid_init,
.num_cs = 5,
.bus_num = 0,
};
-static struct spi_pci_desc spi_pci_mid_desc_2 = {
+static const struct spi_pci_desc spi_pci_mid_desc_2 = {
.setup = dw_spi_mid_init,
.num_cs = 2,
.bus_num = 1,
[PATCH 13/26] [media]: constify local structures
For structure types defined in the same file or local header files, find
top-level static structure declarations that have the following
properties:
1. Never reassigned.
2. Address never taken
3. Not passed to a top-level macro call
4. No pointer or array-typed field passed to a function or stored in a
variable.
Declare structures having all of these properties as const.
Done using Coccinelle.
Based on a suggestion by Joe Perches .
Signed-off-by: Julia Lawall
---
The semantic patch seems too long for a commit log, but is in the cover
letter.
drivers/media/i2c/tvp514x.c|2 +-
drivers/media/pci/ddbridge/ddbridge-core.c | 18 +-
drivers/media/pci/ngene/ngene-cards.c | 14 +++---
drivers/media/pci/smipcie/smipcie-main.c |8
4 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
index 7cdd948..43a9252 100644
--- a/drivers/media/i2c/tvp514x.c
+++ b/drivers/media/i2c/tvp514x.c
@@ -977,7 +977,7 @@ static const struct v4l2_subdev_ops tvp514x_ops = {
.pad = &tvp514x_pad_ops,
};
-static struct tvp514x_decoder tvp514x_dev = {
+static const struct tvp514x_decoder tvp514x_dev = {
.streaming = 0,
.fmt_list = tvp514x_fmt_list,
.num_fmts = ARRAY_SIZE(tvp514x_fmt_list),
diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c
b/drivers/media/pci/ddbridge/ddbridge-core.c
index 47def73..18e3a4d 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -1643,53 +1643,53 @@ fail:
/**/
/**/
-static struct ddb_info ddb_none = {
+static const struct ddb_info ddb_none = {
.type = DDB_NONE,
.name = "Digital Devices PCIe bridge",
};
-static struct ddb_info ddb_octopus = {
+static const struct ddb_info ddb_octopus = {
.type = DDB_OCTOPUS,
.name = "Digital Devices Octopus DVB adapter",
.port_num = 4,
};
-static struct ddb_info ddb_octopus_le = {
+static const struct ddb_info ddb_octopus_le = {
.type = DDB_OCTOPUS,
.name = "Digital Devices Octopus LE DVB adapter",
.port_num = 2,
};
-static struct ddb_info ddb_octopus_mini = {
+static const struct ddb_info ddb_octopus_mini = {
.type = DDB_OCTOPUS,
.name = "Digital Devices Octopus Mini",
.port_num = 4,
};
-static struct ddb_info ddb_v6 = {
+static const struct ddb_info ddb_v6 = {
.type = DDB_OCTOPUS,
.name = "Digital Devices Cine S2 V6 DVB adapter",
.port_num = 3,
};
-static struct ddb_info ddb_v6_5 = {
+static const struct ddb_info ddb_v6_5 = {
.type = DDB_OCTOPUS,
.name = "Digital Devices Cine S2 V6.5 DVB adapter",
.port_num = 4,
};
-static struct ddb_info ddb_dvbct = {
+static const struct ddb_info ddb_dvbct = {
.type = DDB_OCTOPUS,
.name = "Digital Devices DVBCT V6.1 DVB adapter",
.port_num = 3,
};
-static struct ddb_info ddb_satixS2v3 = {
+static const struct ddb_info ddb_satixS2v3 = {
.type = DDB_OCTOPUS,
.name = "Mystique SaTiX-S2 V3 DVB adapter",
.port_num = 3,
};
-static struct ddb_info ddb_octopusv3 = {
+static const struct ddb_info ddb_octopusv3 = {
.type = DDB_OCTOPUS,
.name = "Digital Devices Octopus V3 DVB adapter",
.port_num = 4,
diff --git a/drivers/media/pci/ngene/ngene-cards.c
b/drivers/media/pci/ngene/ngene-cards.c
index 4e783a6..423e8c8 100644
--- a/drivers/media/pci/ngene/ngene-cards.c
+++ b/drivers/media/pci/ngene/ngene-cards.c
@@ -613,7 +613,7 @@ static struct stv6110x_config tuner_cineS2_1 = {
.clk_div = 1,
};
-static struct ngene_info ngene_info_cineS2 = {
+static const struct ngene_info ngene_info_cineS2 = {
.type = NGENE_SIDEWINDER,
.name = "Linux4Media cineS2 DVB-S2 Twin Tuner",
.io_type= {NGENE_IO_TSIN, NGENE_IO_TSIN},
@@ -627,7 +627,7 @@ static struct ngene_info ngene_info_cineS2 = {
.msi_supported = true,
};
-static struct ngene_info ngene_info_satixS2 = {
+static const struct ngene_info ngene_info_satixS2 = {
.type = NGENE_SIDEWINDER,
.name = "Mystique SaTiX-S2 Dual",
.io_type= {NGENE_IO_TSIN, NGENE_IO_TSIN},
@@ -641,7 +641,7 @@ static struct ngene_info ngene_info_satixS2 = {
.msi_supported = true,
};
-static struct ngene_info ngene_info_satixS2v2 = {
+static const struct ngene_info ngene_info_satixS2v2 = {
.type = NGENE_SIDEWINDER,
.name = "Mystique SaTiX-S2 Dual (v2)",
.io_type= {NGENE_IO_TSIN, NGENE_IO_TSIN, NGENE_IO_TSIN,
NGENE_IO_TSIN,
@@ -656,7 +656,7 @@ static struct ngene_info ngene_inf
[PATCH 02/26] lib: constify local structures
For structure types defined in the same file or local header files, find
top-level static structure declarations that have the following
properties:
1. Never reassigned.
2. Address never taken
3. Not passed to a top-level macro call
4. No pointer or array-typed field passed to a function or stored in a
variable.
Declare structures having all of these properties as const.
Done using Coccinelle.
Based on a suggestion by Joe Perches .
Signed-off-by: Julia Lawall
---
The semantic patch seems too long for a commit log, but is in the cover
letter.
lib/crc64_ecma.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/crc64_ecma.c b/lib/crc64_ecma.c
index 41629ea..d013bf3 100644
--- a/lib/crc64_ecma.c
+++ b/lib/crc64_ecma.c
@@ -44,7 +44,7 @@ struct crc64_table {
};
-static struct crc64_table CRC64_ECMA_182 = {
+static const struct crc64_table CRC64_ECMA_182 = {
CRC64_DEFAULT_INITVAL,
{
0xULL,
[PATCH 01/26] ALSA: pci: constify local structures
For structure types defined in the same file or local header files, find
top-level static structure declarations that have the following
properties:
1. Never reassigned.
2. Address never taken
3. Not passed to a top-level macro call
4. No pointer or array-typed field passed to a function or stored in a
variable.
Declare structures having all of these properties as const.
Done using Coccinelle.
Based on a suggestion by Joe Perches .
Signed-off-by: Julia Lawall
---
The semantic patch seems too long for a commit log, but is in the cover
letter.
sound/pci/ctxfi/ctatc.c |2 +-
sound/pci/hda/patch_ca0132.c | 10 +-
sound/pci/riptide/riptide.c |2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/sound/pci/ctxfi/ctatc.c b/sound/pci/ctxfi/ctatc.c
index 977a598..908658a 100644
--- a/sound/pci/ctxfi/ctatc.c
+++ b/sound/pci/ctxfi/ctatc.c
@@ -1623,7 +1623,7 @@ static int atc_resume(struct ct_atc *atc)
}
#endif
-static struct ct_atc atc_preset = {
+static const struct ct_atc atc_preset = {
.map_audio_buffer = ct_map_audio_buffer,
.unmap_audio_buffer = ct_unmap_audio_buffer,
.pcm_playback_prepare = atc_pcm_playback_prepare,
diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c
index 9ceb2bc..ad06866 100644
--- a/sound/pci/hda/patch_ca0132.c
+++ b/sound/pci/hda/patch_ca0132.c
@@ -4018,7 +4018,7 @@ static int ca0132_build_controls(struct hda_codec *codec)
/*
* PCM
*/
-static struct hda_pcm_stream ca0132_pcm_analog_playback = {
+static const struct hda_pcm_stream ca0132_pcm_analog_playback = {
.substreams = 1,
.channels_min = 2,
.channels_max = 6,
@@ -4029,7 +4029,7 @@ static struct hda_pcm_stream ca0132_pcm_analog_playback =
{
},
};
-static struct hda_pcm_stream ca0132_pcm_analog_capture = {
+static const struct hda_pcm_stream ca0132_pcm_analog_capture = {
.substreams = 1,
.channels_min = 2,
.channels_max = 2,
@@ -4040,7 +4040,7 @@ static struct hda_pcm_stream ca0132_pcm_analog_capture = {
},
};
-static struct hda_pcm_stream ca0132_pcm_digital_playback = {
+static const struct hda_pcm_stream ca0132_pcm_digital_playback = {
.substreams = 1,
.channels_min = 2,
.channels_max = 2,
@@ -4052,7 +4052,7 @@ static struct hda_pcm_stream ca0132_pcm_digital_playback
= {
},
};
-static struct hda_pcm_stream ca0132_pcm_digital_capture = {
+static const struct hda_pcm_stream ca0132_pcm_digital_capture = {
.substreams = 1,
.channels_min = 2,
.channels_max = 2,
@@ -4614,7 +4614,7 @@ static void ca0132_free(struct hda_codec *codec)
kfree(codec->spec);
}
-static struct hda_codec_ops ca0132_patch_ops = {
+static const struct hda_codec_ops ca0132_patch_ops = {
.build_controls = ca0132_build_controls,
.build_pcms = ca0132_build_pcms,
.init = ca0132_init,
diff --git a/sound/pci/riptide/riptide.c b/sound/pci/riptide/riptide.c
index ae41fcb..ada5f01 100644
--- a/sound/pci/riptide/riptide.c
+++ b/sound/pci/riptide/riptide.c
@@ -644,7 +644,7 @@ static struct lbuspath lbus_play_paths[] = {
.mono = lbus_play_mono3,
},
};
-static struct lbuspath lbus_rec_path = {
+static const struct lbuspath lbus_rec_path = {
.noconv = lbus_rec_noconv1,
.stereo = lbus_rec_stereo1,
.mono = lbus_rec_mono1,
