* Re: [PATCH v4 1/3] leds: Introduce userspace leds driver
From: Pavel Machek @ 2016-11-09 7:05 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: David Lechner, Richard Purdie, linux-kernel, linux-leds,
Marcel Holtmann
In-Reply-To: <0bfdfd46-35e5-321c-5759-0cc96be862fd@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]
Hi!
> >+struct uleds_device {
> >+ struct uleds_user_dev user_dev;
> >+ struct led_classdev led_cdev;
> >+ struct mutex mutex;
> >+ enum uleds_state state;
> >+ wait_queue_head_t waitq;
> >+ unsigned char brightness;
>
> I've just noticed that this is wrong, since LED subsystem
> brightness type is enum led_brightness, i.e. int.
> LED_FULL (255) value is a legacy enum value that can be overridden
> by max_brightness property.
>
> Please submit a fix so that I could merge it with the original
> patch before sending it upstream.
Actually... perhaps you want to wait with merging the userspace driver
till the locking is solved in the LED subsystem? Maybe I'm wrong, but
I have feeling that userspace driver will have unusual requirements
w.r.t. locking, and that it would be good to have that solved,
first...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [Buildroot] [PATCH] php: fix bfin compile issue
From: Waldemar Brodkorb @ 2016-11-09 7:05 UTC (permalink / raw)
To: buildroot
Fixes:
http://autobuild.buildroot.net/results/8326f24511d3b109d22a76660adc017bbcaca197
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
---
package/php/0007-avoid-bfin-gcc-segfault.patch | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
create mode 100644 package/php/0007-avoid-bfin-gcc-segfault.patch
diff --git a/package/php/0007-avoid-bfin-gcc-segfault.patch b/package/php/0007-avoid-bfin-gcc-segfault.patch
new file mode 100644
index 0000000..4dccb25
--- /dev/null
+++ b/package/php/0007-avoid-bfin-gcc-segfault.patch
@@ -0,0 +1,16 @@
+Avoid gcc segmentation fault
+
+Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
+
+diff -Nur php-7.0.12.orig/Zend/zend_portability.h php-7.0.12/Zend/zend_portability.h
+--- php-7.0.12.orig/Zend/zend_portability.h 2016-10-13 16:04:17.000000000 +0200
++++ php-7.0.12/Zend/zend_portability.h 2016-11-08 02:49:39.118388999 +0100
+@@ -97,7 +97,7 @@
+
+ #if defined(ZEND_WIN32) && !defined(__clang__)
+ # define ZEND_ASSUME(c) __assume(c)
+-#elif ((defined(__GNUC__) && ZEND_GCC_VERSION >= 4005) || __has_builtin(__builtin_unreachable)) && PHP_HAVE_BUILTIN_EXPECT
++#elif ((defined(__GNUC__) && ZEND_GCC_VERSION >= 4005) || __has_builtin(__builtin_unreachable)) && PHP_HAVE_BUILTIN_EXPECT && !defined(__bfin__)
+ # define ZEND_ASSUME(c) do { \
+ if (__builtin_expect(!(c), 0)) __builtin_unreachable(); \
+ } while (0)
--
2.1.4
^ permalink raw reply related
* Re: esp_scsi, was Re: Modified Linux 4.1.20 (mac+scsi) on Quadra 660av
From: Michael Schmitz @ 2016-11-09 7:06 UTC (permalink / raw)
To: Finn Thain; +Cc: linux-m68k, Tuomas Vainikka
In-Reply-To: <alpine.LNX.2.00.1611022052170.12008@nippy.intranet>
Hi Finn,
got sidetracked once again ...
>> Where? In esp_reconnect, we don't get to that point when returning from
>> esp_reconnect_with_tag() after timeout.
>
> Well, the point is, we potentially release ACK (either after the
> Information Transfer command or after the Accept Message command) with ATN
> still asserted.
Who asserts ATN in case of reselection? I always thought that the
target, by initiating reselection, assumes the role of initiator and is
in charge of driving bus phase changes (including control of ATN).
>> How does the target signal end of message in phase? Stop handshaking, or
>> change phase?
>
> Either would do. To stop handshaking would imply entering bus free phase.
>
>> ATN going false?
>
> AIUI, only the initiator can drive ATN.
So the initiator would have to read two tag message bytes if a target
reselects that had a tagged command disconnected? From the initiator
side, that should work (if an untagged commmand has been issued, no
tagged commands are sent so we expect either tagged or untagged
reselections).
>> With the DMA programmed for two tag bytes, and the reselection
>> originating from a tagged command, I would expect the target to send the
>> two tag bytes.
>
> Sure, but I think the initator is messing it up along the way.
Can't see how - reconnect_with_tag() is only used if no untagged command
is on record for the target.
>
>> Would it help to do the message transfer without DMA?
>
> I would, just to see more clearly what was going on (command queue,
> control lines, bus phase).
Not sure we can get control lines read - bus phases are available IIRC.
> Recall that Tuomas said he tried PIO for this with zorro_esp without any
> improvement. And I first saw this bug on a Quadra 660av, on which mac_esp
> uses PIO for all transfers.
PIO does get set up for the expected number of message bytes though. Is
there a check for phase mismatch during PIO?
>>> What use could an initiator have for the QTAG Control bit
>>> (ESP_CONFIG3_TBMS) when the target never controls /ATN? (I only
>>> remembered this yesterday, so please ignore my earlier comments about
>>> reselection and SEL-with-ATN.)
>>
>> I had thought the reselection process similar to selection. But if the
>> target does not signal further message bytes by keepin ATN asserted,
>> that bit might not matter here.
>
> If only the initator drives ATN, the documentation can only be referring
> to an ESP device in target mode.
The documentation mentions a command descriptor block to be transferred
- would only apply to ESP in target mode again.
> My recollection from 2009 is that this particular disk did work with
> mac_esp on one of my Quadras, but not on my 660av. And three people have
> reported the problem now (to my knowledge) so I don't blame the disks.
What ESP versions are used in the Quadras vs 660av?
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH] mmc: sdhci-pci: Add support for HS200 tuning mode, on AMD eMMC-4.5.1
From: kbuild test robot @ 2016-11-09 7:06 UTC (permalink / raw)
To: Shyam Sundar S K
Cc: kbuild-all, adrian.hunter, Ulf Hansson, linux-mmc, Pankaj.Sen,
Nehal-bakulchandra.Shah, Agrawal, Nitesh-kumar
In-Reply-To: <23bdf5b6-08ef-4de7-c612-49861b6693a1@amd.com>
[-- Attachment #1: Type: text/plain, Size: 9141 bytes --]
Hi Shyam,
[auto build test ERROR on ulf.hansson-mmc/next]
[also build test ERROR on v4.9-rc4 next-20161109]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Shyam-Sundar-S-K/mmc-sdhci-pci-Add-support-for-HS200-tuning-mode-on-AMD-eMMC-4-5-1/20161109-145027
base: https://git.linaro.org/people/ulf.hansson/mmc next
config: i386-randconfig-x006-201645 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
drivers/mmc/host/sdhci-pci-core.c: In function 'amd_find_good_phase':
>> drivers/mmc/host/sdhci-pci-core.c:877:37: error: implicit declaration of function 'sdhci_pci_priv' [-Werror=implicit-function-declaration]
struct amd_tuning_descriptor *td = sdhci_pci_priv(slot);
^~~~~~~~~~~~~~
>> drivers/mmc/host/sdhci-pci-core.c:877:37: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
drivers/mmc/host/sdhci-pci-core.c: In function 'amd_execute_tuning':
drivers/mmc/host/sdhci-pci-core.c:946:37: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
struct amd_tuning_descriptor *td = sdhci_pci_priv(slot);
^~~~~~~~~~~~~~
Cyclomatic Complexity 1 arch/x86/include/asm/paravirt.h:arch_local_save_flags
Cyclomatic Complexity 1 arch/x86/include/asm/paravirt.h:arch_local_irq_restore
Cyclomatic Complexity 1 arch/x86/include/asm/paravirt.h:arch_local_irq_disable
Cyclomatic Complexity 1 arch/x86/include/asm/paravirt.h:arch_local_irq_save
Cyclomatic Complexity 1 include/linux/err.h:ERR_PTR
Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
Cyclomatic Complexity 2 include/linux/err.h:IS_ERR
Cyclomatic Complexity 1 include/linux/err.h:ERR_CAST
Cyclomatic Complexity 1 arch/x86/include/asm/irqflags.h:arch_irqs_disabled_flags
Cyclomatic Complexity 1 arch/x86/include/asm/preempt.h:should_resched
Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check
Cyclomatic Complexity 3 include/linux/spinlock.h:spin_unlock_irqrestore
Cyclomatic Complexity 1 arch/x86/include/asm/io.h:readb
Cyclomatic Complexity 1 arch/x86/include/asm/io.h:readw
Cyclomatic Complexity 1 arch/x86/include/asm/io.h:readl
Cyclomatic Complexity 1 arch/x86/include/asm/io.h:writeb
Cyclomatic Complexity 1 arch/x86/include/asm/io.h:writew
Cyclomatic Complexity 1 arch/x86/include/asm/io.h:writel
Cyclomatic Complexity 1 include/linux/kobject.h:kobject_name
Cyclomatic Complexity 1 include/linux/device.h:devm_kzalloc
Cyclomatic Complexity 3 include/linux/device.h:dev_name
Cyclomatic Complexity 1 include/linux/device.h:dev_get_drvdata
Cyclomatic Complexity 1 include/linux/device.h:dev_set_drvdata
Cyclomatic Complexity 1 include/linux/pci.h:pci_read_config_byte
Cyclomatic Complexity 1 include/linux/pci.h:pci_read_config_dword
Cyclomatic Complexity 1 include/linux/pci.h:pci_write_config_byte
Cyclomatic Complexity 1 include/linux/pci.h:pci_write_config_dword
Cyclomatic Complexity 1 include/linux/pci.h:pci_get_drvdata
Cyclomatic Complexity 1 include/linux/pci.h:pci_set_drvdata
Cyclomatic Complexity 1 include/linux/mmc/host.h:mmc_priv
Cyclomatic Complexity 1 include/asm-generic/gpio.h:gpio_is_valid
Cyclomatic Complexity 1 include/asm-generic/gpio.h:gpio_direction_output
Cyclomatic Complexity 1 include/asm-generic/gpio.h:gpio_set_value_cansleep
Cyclomatic Complexity 1 include/linux/pm_runtime.h:pm_runtime_allow
Cyclomatic Complexity 1 include/linux/pm_runtime.h:pm_runtime_forbid
Cyclomatic Complexity 1 include/linux/pm_runtime.h:pm_suspend_ignore_children
Cyclomatic Complexity 1 include/linux/pm_runtime.h:pm_runtime_get_noresume
Cyclomatic Complexity 1 include/linux/pm_runtime.h:pm_runtime_put_noidle
Cyclomatic Complexity 1 include/linux/pm_runtime.h:__pm_runtime_use_autosuspend
Cyclomatic Complexity 1 include/linux/pm_runtime.h:pm_runtime_set_autosuspend_delay
Cyclomatic Complexity 1 include/linux/pm_runtime.h:pm_runtime_use_autosuspend
Cyclomatic Complexity 1 drivers/mmc/host/sdhci.h:sdhci_writel
Cyclomatic Complexity 1 drivers/mmc/host/sdhci.h:sdhci_writew
Cyclomatic Complexity 1 drivers/mmc/host/sdhci.h:sdhci_writeb
Cyclomatic Complexity 1 drivers/mmc/host/sdhci.h:sdhci_readl
Cyclomatic Complexity 1 drivers/mmc/host/sdhci.h:sdhci_readw
Cyclomatic Complexity 1 drivers/mmc/host/sdhci.h:sdhci_readb
Cyclomatic Complexity 1 drivers/mmc/host/sdhci.h:sdhci_priv
Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:ricoh_mmc_probe_slot
Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:mrst_hc_probe_slot
Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:mrst_hc_probe
Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:pch_hc_probe_slot
Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_add_own_cd
Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_remove_own_cd
Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:mfd_emmc_probe_slot
Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:mfd_sdio_probe_slot
Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:byt_sdio_probe_slot
Cyclomatic Complexity 4 drivers/mmc/host/sdhci-pci-core.c:intel_mrfld_mmc_probe_slot
Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:rtsx_probe_slot
Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:amd_enable_manual_tuning
Cyclomatic Complexity 3 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_set_bus_width
Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_runtime_pm_allow
Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_runtime_pm_forbid
Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:sdhci_driver_init
Cyclomatic Complexity 3 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_select_drive_strength
Cyclomatic Complexity 3 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_hw_reset
Cyclomatic Complexity 12 drivers/mmc/host/sdhci-pci-core.c:byt_sd_probe_slot
Cyclomatic Complexity 5 drivers/mmc/host/sdhci-pci-core.c:spt_select_drive_strength
Cyclomatic Complexity 3 drivers/mmc/host/sdhci-pci-core.c:via_probe
Cyclomatic Complexity 3 drivers/mmc/host/sdhci-pci-core.c:syskt_probe
Cyclomatic Complexity 3 drivers/mmc/host/sdhci-pci-core.c:jmicron_enable_mmc
Cyclomatic Complexity 5 drivers/mmc/host/sdhci-pci-core.c:jmicron_pmos
Cyclomatic Complexity 10 drivers/mmc/host/sdhci-pci-core.c:jmicron_suspend
Cyclomatic Complexity 11 drivers/mmc/host/sdhci-pci-core.c:jmicron_remove_slot
Cyclomatic Complexity 15 drivers/mmc/host/sdhci-pci-core.c:jmicron_probe_slot
Cyclomatic Complexity 9 drivers/mmc/host/sdhci-pci-core.c:ricoh_probe
Cyclomatic Complexity 19 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_remove_slot
Cyclomatic Complexity 4 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_remove
Cyclomatic Complexity 12 drivers/mmc/host/sdhci-pci-core.c:jmicron_resume
Cyclomatic Complexity 69 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_probe_slot
Cyclomatic Complexity 33 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_probe
Cyclomatic Complexity 29 drivers/mmc/host/sdhci-pci-core.c:spt_read_drive_strength
Cyclomatic Complexity 5 drivers/mmc/host/sdhci-pci-core.c:byt_emmc_probe_slot
Cyclomatic Complexity 8 drivers/mmc/host/sdhci-pci-core.c:syskt_probe_slot
Cyclomatic Complexity 2 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_gpio_hw_reset
Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_int_hw_reset
Cyclomatic Complexity 12 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_enable_dma
Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:amd_tuning_reset
Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:amd_config_tuning_phase
Cyclomatic Complexity 42 drivers/mmc/host/sdhci-pci-core.c:amd_find_good_phase
Cyclomatic Complexity 3 drivers/mmc/host/sdhci-pci-core.c:amd_execute_tuning
Cyclomatic Complexity 9 drivers/mmc/host/sdhci-pci-core.c:amd_probe
Cyclomatic Complexity 6 drivers/mmc/host/sdhci-pci-core.c:sdhci_intel_set_power
Cyclomatic Complexity 5 drivers/mmc/host/sdhci-pci-core.c:bxt_get_cd
Cyclomatic Complexity 24 drivers/mmc/host/sdhci-pci-core.c:jmicron_probe
Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:ricoh_mmc_resume
vim +/sdhci_pci_priv +877 drivers/mmc/host/sdhci-pci-core.c
871 }
872
873 static int amd_find_good_phase(struct sdhci_host *host)
874 {
875 struct sdhci_pci_slot *slot = sdhci_priv(host);
876 struct pci_dev *pdev = slot->chip->pdev;
> 877 struct amd_tuning_descriptor *td = sdhci_pci_priv(slot);
878
879 unsigned int val;
880 unsigned long flags;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 26284 bytes --]
^ permalink raw reply
* [PATCH v2 2/2] mm: hugetlb: support gigantic surplus pages
From: Huang Shijie @ 2016-11-09 7:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478141499-13825-3-git-send-email-shijie.huang@arm.com>
When testing the gigantic page whose order is too large for the buddy
allocator, the libhugetlbfs test case "counter.sh" will fail.
The failure is caused by:
1) kernel fails to allocate a gigantic page for the surplus case.
And the gather_surplus_pages() will return NULL in the end.
2) The condition checks for "over-commit" is wrong.
This patch adds code to allocate the gigantic page in the
__alloc_huge_page(). After this patch, gather_surplus_pages()
can return a gigantic page for the surplus case.
This patch changes the condition checks for:
return_unused_surplus_pages()
nr_overcommit_hugepages_store()
hugetlb_overcommit_handler()
This patch also set @nid with proper value when NUMA_NO_NODE is
passed to alloc_gigantic_page().
After this patch, the counter.sh can pass for the gigantic page.
Acked-by: Steve Capper <steve.capper@arm.com>
Signed-off-by: Huang Shijie <shijie.huang@arm.com>
---
1. fix the wrong check in hugetlb_overcommit_handler();
2. try to fix the s390 issue.
---
mm/hugetlb.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 9fdfc24..5dbfd62 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1095,6 +1095,9 @@ static struct page *alloc_gigantic_page(int nid, unsigned int order)
unsigned long ret, pfn, flags;
struct zone *z;
+ if (nid == NUMA_NO_NODE)
+ nid = numa_mem_id();
+
z = NODE_DATA(nid)->node_zones;
for (; z - NODE_DATA(nid)->node_zones < MAX_NR_ZONES; z++) {
spin_lock_irqsave(&z->lock, flags);
@@ -1578,7 +1581,7 @@ static struct page *__alloc_huge_page(struct hstate *h,
struct page *page;
unsigned int r_nid;
- if (hstate_is_gigantic(h))
+ if (hstate_is_gigantic(h) && !gigantic_page_supported())
return NULL;
/*
@@ -1623,7 +1626,13 @@ static struct page *__alloc_huge_page(struct hstate *h,
}
spin_unlock(&hugetlb_lock);
- page = __hugetlb_alloc_buddy_huge_page(h, vma, addr, nid);
+ if (hstate_is_gigantic(h)) {
+ page = alloc_gigantic_page(nid, huge_page_order(h));
+ if (page)
+ prep_compound_gigantic_page(page, huge_page_order(h));
+ } else {
+ page = __hugetlb_alloc_buddy_huge_page(h, vma, addr, nid);
+ }
spin_lock(&hugetlb_lock);
if (page) {
@@ -1790,8 +1799,7 @@ static void return_unused_surplus_pages(struct hstate *h,
/* Uncommit the reservation */
h->resv_huge_pages -= unused_resv_pages;
- /* Cannot return gigantic pages currently */
- if (hstate_is_gigantic(h))
+ if (hstate_is_gigantic(h) && !gigantic_page_supported())
return;
nr_pages = min(unused_resv_pages, h->surplus_huge_pages);
@@ -2443,7 +2451,7 @@ static ssize_t nr_overcommit_hugepages_store(struct kobject *kobj,
unsigned long input;
struct hstate *h = kobj_to_hstate(kobj, NULL);
- if (hstate_is_gigantic(h))
+ if (hstate_is_gigantic(h) && !gigantic_page_supported())
return -EINVAL;
err = kstrtoul(buf, 10, &input);
@@ -2884,7 +2892,7 @@ int hugetlb_overcommit_handler(struct ctl_table *table, int write,
tmp = h->nr_overcommit_huge_pages;
- if (write && hstate_is_gigantic(h))
+ if (write && hstate_is_gigantic(h) && !gigantic_page_supported())
return -EINVAL;
table->data = &tmp;
--
2.1.4
^ permalink raw reply related
* Re: gcc-4.6.3, was Re: Debian on mac68k
From: Finn Thain @ 2016-11-09 7:08 UTC (permalink / raw)
To: Michael Schmitz; +Cc: John Paul Adrian Glaubitz, debian-68k, linux-m68k
In-Reply-To: <b731fd59-03b7-a443-650b-c023c1190385@gmail.com>
On Wed, 9 Nov 2016, Michael Schmitz wrote:
> Not for Mac, but Geert usually boots kernels using ARAnyM. Pretty basic,
> for sure, but it's been good enough so have something to work from.
I thought Geert still used gcc-4.1 (?)
>
> Having something like ARAnyM for Mac or Amiga would increase coverage,
> but the varied and quirky Mac hardware out there makes that almost
> pointless again.
AFAIK, MAME/MESS is the only thing that would be accurate enough.
For the Mac models that I was interested in (LC III for Egret and LC 520
for Cuda), I was able to patch some of the known bugs in MAME/MESS to get
the ROM to boot to a flashing question mark, but I didn't try to boot any
further. I will try loading EMILE.
--
>
> Cheers,
>
> Michael
>
>
^ permalink raw reply
* [Intel-wired-lan] [PATCH v3] ixgbevf: handle race between close and suspend on shutdown
From: Alexander Duyck @ 2016-11-09 7:09 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <87618083B2453E4A8714035B62D6799250709CDF@FMSMSX105.amr.corp.intel.com>
On Tuesday, November 8, 2016, Tantilov, Emil S <emil.s.tantilov@intel.com>
wrote:
> >-----Original Message-----
> >From: Alexander Duyck [mailto:alexander.duyck at gmail.com <javascript:;>]
> >Sent: Tuesday, November 08, 2016 7:24 PM
> >To: Tantilov, Emil S <emil.s.tantilov@intel.com <javascript:;>>
> >Cc: intel-wired-lan <intel-wired-lan@lists.osuosl.org <javascript:;>>
> >Subject: Re: [Intel-wired-lan] [PATCH v3] ixgbevf: handle race between
> >close and suspend on shutdown
> >
> >On Tue, Nov 8, 2016 at 12:18 PM, Emil Tantilov
> ><emil.s.tantilov@intel.com <javascript:;>> wrote:
> >> When an interface is part of a namespace it is possible that
> >> ixgbevf_close() may be called while ixgbevf_suspend() is running
> >> which ends up in a double free WARN and/or a BUG in free_msi_irqs()
> >>
> >> To handle this situation we extend the rtnl_lock() to protect the
> >> call to netif_device_detach() and check for !netif_device_present()
> >> to avoid entering close while in suspend.
> >>
> >> Also added rtnl locks to ixgbevf_queue_reset_subtask().
> >>
> >> -v2 handle the race with netif_device_detach/present() and rtnl
> >> locks as suggested by Alex Duyck
> >>
> >> -v3 add rtnl locks and check in ixgbevf_remove()
> >
> >I'm not sure where you got the idea that you needed to add the checks
> >to ixgbevf_remove, but I'm pretty sure you don't need to.
>
> When injecting PCIe AER error and the device fails to recover we end up
> in a situation where removing the driver (rmmod) will trigger BUG_ON in
> free_msi_irqs(), so not exactly a race and the rtnl locks may not be
> needed,
> but we need the check to make sure we don't double free.
>
> If netif_device_present() is not a good check I suppose we can check for
> __IXGBEVF_DISABLED.
>
> Thanks,
> Emil
The problem is that I don't think we free the irq in the AER detach case.
The error paths need to be updated to match the state of the suspend/resume
state.
- Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20161108/d1787b9c/attachment.html>
^ permalink raw reply
* [PATCH v2 2/2] mm: hugetlb: support gigantic surplus pages
From: Huang Shijie @ 2016-11-09 7:08 UTC (permalink / raw)
To: akpm, catalin.marinas
Cc: n-horiguchi, mhocko, kirill.shutemov, aneesh.kumar,
gerald.schaefer, mike.kravetz, linux-mm, will.deacon,
steve.capper, kaly.xin, nd, linux-arm-kernel, Huang Shijie
In-Reply-To: <1478141499-13825-3-git-send-email-shijie.huang@arm.com>
When testing the gigantic page whose order is too large for the buddy
allocator, the libhugetlbfs test case "counter.sh" will fail.
The failure is caused by:
1) kernel fails to allocate a gigantic page for the surplus case.
And the gather_surplus_pages() will return NULL in the end.
2) The condition checks for "over-commit" is wrong.
This patch adds code to allocate the gigantic page in the
__alloc_huge_page(). After this patch, gather_surplus_pages()
can return a gigantic page for the surplus case.
This patch changes the condition checks for:
return_unused_surplus_pages()
nr_overcommit_hugepages_store()
hugetlb_overcommit_handler()
This patch also set @nid with proper value when NUMA_NO_NODE is
passed to alloc_gigantic_page().
After this patch, the counter.sh can pass for the gigantic page.
Acked-by: Steve Capper <steve.capper@arm.com>
Signed-off-by: Huang Shijie <shijie.huang@arm.com>
---
1. fix the wrong check in hugetlb_overcommit_handler();
2. try to fix the s390 issue.
---
mm/hugetlb.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 9fdfc24..5dbfd62 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1095,6 +1095,9 @@ static struct page *alloc_gigantic_page(int nid, unsigned int order)
unsigned long ret, pfn, flags;
struct zone *z;
+ if (nid == NUMA_NO_NODE)
+ nid = numa_mem_id();
+
z = NODE_DATA(nid)->node_zones;
for (; z - NODE_DATA(nid)->node_zones < MAX_NR_ZONES; z++) {
spin_lock_irqsave(&z->lock, flags);
@@ -1578,7 +1581,7 @@ static struct page *__alloc_huge_page(struct hstate *h,
struct page *page;
unsigned int r_nid;
- if (hstate_is_gigantic(h))
+ if (hstate_is_gigantic(h) && !gigantic_page_supported())
return NULL;
/*
@@ -1623,7 +1626,13 @@ static struct page *__alloc_huge_page(struct hstate *h,
}
spin_unlock(&hugetlb_lock);
- page = __hugetlb_alloc_buddy_huge_page(h, vma, addr, nid);
+ if (hstate_is_gigantic(h)) {
+ page = alloc_gigantic_page(nid, huge_page_order(h));
+ if (page)
+ prep_compound_gigantic_page(page, huge_page_order(h));
+ } else {
+ page = __hugetlb_alloc_buddy_huge_page(h, vma, addr, nid);
+ }
spin_lock(&hugetlb_lock);
if (page) {
@@ -1790,8 +1799,7 @@ static void return_unused_surplus_pages(struct hstate *h,
/* Uncommit the reservation */
h->resv_huge_pages -= unused_resv_pages;
- /* Cannot return gigantic pages currently */
- if (hstate_is_gigantic(h))
+ if (hstate_is_gigantic(h) && !gigantic_page_supported())
return;
nr_pages = min(unused_resv_pages, h->surplus_huge_pages);
@@ -2443,7 +2451,7 @@ static ssize_t nr_overcommit_hugepages_store(struct kobject *kobj,
unsigned long input;
struct hstate *h = kobj_to_hstate(kobj, NULL);
- if (hstate_is_gigantic(h))
+ if (hstate_is_gigantic(h) && !gigantic_page_supported())
return -EINVAL;
err = kstrtoul(buf, 10, &input);
@@ -2884,7 +2892,7 @@ int hugetlb_overcommit_handler(struct ctl_table *table, int write,
tmp = h->nr_overcommit_huge_pages;
- if (write && hstate_is_gigantic(h))
+ if (write && hstate_is_gigantic(h) && !gigantic_page_supported())
return -EINVAL;
table->data = &tmp;
--
2.1.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [PATCH v2 2/2] hwmon: new driver for ST stts751 thermal sensor
From: Andrea Merello @ 2016-11-09 7:09 UTC (permalink / raw)
To: Guenter Roeck; +Cc: linux-hwmon, LABBE Corentin, Jean Delvare
In-Reply-To: <20161104160141.GA28466@roeck-us.net>
On Fri, Nov 4, 2016 at 5:01 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> On Fri, Nov 04, 2016 at 04:43:46PM +0100, Andrea Merello wrote:
>> On Fri, Nov 4, 2016 at 4:09 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>> > On Fri, Nov 04, 2016 at 09:24:25AM +0100, Andrea Merello wrote:
>> >> On Thu, Nov 3, 2016 at 10:16 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>> >> > On Thu, Nov 03, 2016 at 08:35:27AM +0100, Andrea Merello wrote:
>> >> >> On Wed, Nov 2, 2016 at 11:48 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>> >> >> > On Wed, Nov 02, 2016 at 09:11:35AM +0100, Andrea Merello wrote:
>> >> >> >> On Mon, Oct 31, 2016 at 5:18 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>> >> >> >> > On 10/31/2016 08:27 AM, Andrea Merello wrote:
>> >> >> >> >
>> >> >> >> >>>>
>> >> >> >> >>>>>> + if (ret < 0)
>> >> >> >> >>>>>> + return ret;
>> >> >> >> >>>>>> +
>> >> >> >> >>>>>> + priv->max_alert = priv->max_alert || !!(ret &
>> >> >> >> >>>>>> STTS751_STATUS_TRIPH);
>> >> >> >> >>>>>> + priv->min_alert = priv->min_alert || !!(ret &
>> >> >> >> >>>>>> STTS751_STATUS_TRIPL);
>> >> >> >> >>>>>> +
>> >> >> >> >>>>>
>> >> >> >> >>>>>
>> >> >> >> >>>>> I am not really happy about the caching of alert values. This isn't
>> >> >> >> >>>>> really
>> >> >> >> >>>>> common. Usually we report current alert values when reading. I don't
>> >> >> >> >>>>> really
>> >> >> >> >>>>> see why this driver should be different to all the others.
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>> OK
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> I've tried to avoid caching, but as soon as I read the status register
>> >> >> >> >> in the alert handler, the device clears that reg, and it will remain
>> >> >> >> >> cleared up to the next conversion.
>> >> >> >> >>
>> >> >> >> >> So for example if the reader is blocked on poll over the alert
>> >> >> >> >> attribute, it gets unblocked on alert, and it will very likely read
>> >> >> >> >> zero..
>> >> >> >> >>
>> >> >> >> >> The only way I can see for avoiding caching, and for changing the API
>> >> >> >> >> about clearing events as you asked below, is performing a temperature
>> >> >> >> >> read from the temperature registers and doing software compare with
>> >> >> >> >> the limits in show_[max/min]_alert.
>> >> >> >> >>
>> >> >> >> >> Does this sounds OK for you ?
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> > Not really. That could be done from user space by just reading the
>> >> >> >> > temperature
>> >> >> >> > and comparing it against limits.
>> >> >> >>
>> >> >> >> Sorry, I don't see the point here.. Why the fact that something could
>> >> >> >> be done in userspace should suggest we don't want to do it in the
>> >> >> >> driver? We do, for example, a simple calculation to give an absolute
>> >> >> >> value for the hysteresis; we could do this also in userspace, but we
>> >> >> >> do this in the driver in order to support the proper API..
>> >> >> >>
>> >> >> > Datasheet says:
>> >> >> >
>> >> >> > T HIGH : [6] Bit = 1 indicates temperature high limit has been exceeded (T A >
>> >> >> > high limit). T HIGH is cleared when the status register is read, provided
>> >> >> > the condition no longer exists.
>> >> >> > T LOW : [5] Bit = 1 indicates the is at or below the low limit (T A ≤ low
>> >> >> > limit). T LOW is cleared when the status register is read, provided the
>> >> >> > condition no longer exists.
>> >> >> >
>> >> >> > This isn't exactly what you are claiming, since it says "cleared ... provided
>> >> >> > that the condition no longer exists", which would be more in line with other
>> >> >> > chips.
>> >> >>
>> >> >> Yes, I know.. I've also read that on the datasheet.. And I tried
>> >> >> reading the status register in both the alert handler and the show
>> >> >> function, but it didn't worked :/
>> >> >>
>> >> >> So I started to suspect the status register got actually clear after
>> >> >> reading up to the next conversion, and to test this, I simply read it
>> >> >> twice in the alert handler. The first read always read 1, as expected;
>> >> >> the second time I always got zero, even if the temperature was still
>> >> >> over-limit.. And I soon got another event, that behaved in the same
>> >> >> manner.
>> >> >>
>> >> > Question is if the event bit is set again after the next conversion; this would
>> >> > be relatively easy to handle (cache the status register for one conversion
>> >> > time).
>> >>
>> >> Yes, I meant the HW does exactly this. But it seems to me that caching
>> >> could end up in subtle races here..
>> >>
>> >> For example suppose that user is reading the lower limit alarm file,
>> >> or therm, and this will trigger read of the status reg; but a
>> >> conversion is just ended and set the high limit alarm just before
>> >> reading the status reg. Then the event handler is invoked but it will
>> >> find out the status reg to be (incorrectly) zero, (or rely on a value
>> >> cached when reading the lower limit, that was zero); thus a thread
>> >> blocked on poll on the high alarm would not be woken up. (ok, this
>> >> probably will happen in next conversions, but this doesn't sound quite
>> >> sane to me..).
>> >>
>> > Good catch and thinking, but there is a workaround. If the cache time
>> > has not expired, just logically or the cached status value with the current
>> > value in the alert function, and update the time stamp. This way nothing
>> > gets lost.
>>
>> Hmm, it seems OK; thanks for suggesting this :) I'll try to go this way..
>>
>> BTW I would say that the cache time for the alert should be
>> coservatively a bit longer than the conversion time (to avoid early
>> expiration when the status register has been not restored yet). On the
>> other hand for the temperature reading I'm using a cache time that is
>> shorter (I think it is 1/4) than the conversion interval, so that the
>> user gets a reasonably fresh value (becasue the chip sampling freq is
>> asyncrhronous wrt the reads we do). Do you think it's worth to keep
>> doing this (so we have two different cache time for alarms and temp
>> value), or do you think that it's pointless, and better to unify it
>> (at the longer one, I would say)?
>>
>
> I would suggest to use a single cache time, in line with the real cache time,
> using the maximum as per the datasheet and possibly rounded up. If the user
> wants faster readings, that can be made configurable using the 'update-interval'
> attribute. If the chip is configured to only read the temperature once per,
> say, 16 seconds, this is what the user wanted, and real-time accuracy is not
> guaranteed anyway.
Ok, I'll come back with a new version of the patch changed as discussed.
Thanks
Andrea
>
>> >>
>> >> >> (also I'm thinking about a way to mask events once we know that we are
>> >> >> in a out-of-limit condition, to avoid having a lot of them, but simply
>> >> >> disabling events and re-enabling them after userspace reads the alarm
>> >> >> and find it to be zero, like lm90 driver does, IMHO wouldn't be good
>> >> >> here, because we have a single bit to disable both high and low
>> >> >> limits..)
>> >> >>
>> >> >> > The THRM bit doesn't seem to self-clean either, at least not according to the
>> >> >> > datasheet.
>> >> >>
>> >> >> I need to test this.. But this doesn't generate any event, it seems
>> >> >> only inteded to drive an external circuit, say a fan, and not to
>> >> >> notify SW.. And currently I even have no show function to read it's
>> >> >> status (now that I'm on it, I think I should add it...)..
>> >> >>
>> >> > Yes. Note that this pin might be wired to an interrupt.
>> >>
>> >> IMHO it isn't straightforward to handle this..
>> >>
>> >> AFAIK what is done by the smbus code to allow handling smbus events
>> >> lines with regular interrupt lines is to briefly disabling the IRQ
>> >> line until the event can be acknowledged with the ARA (in non atomic
>> >> context).
>> >>
>> >> But here is even worse because there is no ARA; it seems that the
>> >> therm line can't be "cleared" at all.
>> >>
>> >> Maybe it's possible to do hacks similar to what the smbus code does,
>> >> but keeping the IRQ line disabled (given that it must not be shared)..
>> >> Maybe if the IRQ controller could be set in edge-triggered mode it
>> >> would be easier..
>> >>
>> >> But does it really worth struggling supporting this scenario? There's
>> >> the event pin explicitly designed for events, and there is code that
>> >> make it possible to use this even with regular IRQs.. Using also the
>> >> therm pin as interrupt seems honestly a bit pointless and
>> >> inappropriate..
>> >>
>> > Correct, one would use an edge triggered interrupt in this case. But
>> > you are right, this should only be implemented if that use case is
>> > actually encountered.
>> >
>> > Thanks,
>> > Guenter
^ permalink raw reply
* [PATCH 2/2] mm: hugetlb: support gigantic surplus pages
From: Huang Shijie @ 2016-11-09 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108202742.57ed120d@thinkpad>
On Tue, Nov 08, 2016 at 08:27:42PM +0100, Gerald Schaefer wrote:
> On Tue, 8 Nov 2016 17:17:28 +0800
> Huang Shijie <shijie.huang@arm.com> wrote:
>
> > > I will look at the lockdep issue.
> > I tested the new patch (will be sent out later) on the arm64 platform,
> > and I did not meet the lockdep issue when I enabled the lockdep.
> > The following is my config:
> >
> > CONFIG_LOCKD=y
> > CONFIG_LOCKD_V4=y
> > CONFIG_LOCKUP_DETECTOR=y
> > # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
> > CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
> > CONFIG_DEBUG_SPINLOCK=y
> > CONFIG_DEBUG_LOCK_ALLOC=y
> > CONFIG_PROVE_LOCKING=y
> > CONFIG_LOCKDEP=y
> > CONFIG_LOCK_STAT=y
> > CONFIG_DEBUG_LOCKDEP=y
> > CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
> >
> > So do I miss something?
>
> Those options should be OK. Meanwhile I looked into this a little more,
> and the problematic line/lock is spin_lock_irqsave(&z->lock, flags) at
> the top of alloc_gigantic_page(). From the lockdep trace we see that
> it is triggered by an mmap(), and then hugetlb_acct_memory() ->
> __alloc_huge_page() -> alloc_gigantic_page().
>
> However, in between those functions (inside gather_surplus_pages())
> a NUMA_NO_NODE node id comes into play. And this finally results in
> alloc_gigantic_page() being called with NUMA_NO_NODE as nid (which is
> -1), and NODE_DATA(nid)->node_zones will then reach into Nirvana.
Thanks for pointing this.
I sent out the new patch just now. Could you please try it again?
I added a NUMA_NO_NODE check in the alloc_gigantic_page();
thanks
Huang Shijie
^ permalink raw reply
* Re: [PATCH 2/2] mm: hugetlb: support gigantic surplus pages
From: Huang Shijie @ 2016-11-09 7:12 UTC (permalink / raw)
To: Gerald Schaefer
Cc: akpm, catalin.marinas, n-horiguchi, mhocko, kirill.shutemov,
aneesh.kumar, mike.kravetz, linux-mm, will.deacon, steve.capper,
kaly.xin, nd, linux-arm-kernel
In-Reply-To: <20161108202742.57ed120d@thinkpad>
On Tue, Nov 08, 2016 at 08:27:42PM +0100, Gerald Schaefer wrote:
> On Tue, 8 Nov 2016 17:17:28 +0800
> Huang Shijie <shijie.huang@arm.com> wrote:
>
> > > I will look at the lockdep issue.
> > I tested the new patch (will be sent out later) on the arm64 platform,
> > and I did not meet the lockdep issue when I enabled the lockdep.
> > The following is my config:
> >
> > CONFIG_LOCKD=y
> > CONFIG_LOCKD_V4=y
> > CONFIG_LOCKUP_DETECTOR=y
> > # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
> > CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
> > CONFIG_DEBUG_SPINLOCK=y
> > CONFIG_DEBUG_LOCK_ALLOC=y
> > CONFIG_PROVE_LOCKING=y
> > CONFIG_LOCKDEP=y
> > CONFIG_LOCK_STAT=y
> > CONFIG_DEBUG_LOCKDEP=y
> > CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
> >
> > So do I miss something?
>
> Those options should be OK. Meanwhile I looked into this a little more,
> and the problematic line/lock is spin_lock_irqsave(&z->lock, flags) at
> the top of alloc_gigantic_page(). From the lockdep trace we see that
> it is triggered by an mmap(), and then hugetlb_acct_memory() ->
> __alloc_huge_page() -> alloc_gigantic_page().
>
> However, in between those functions (inside gather_surplus_pages())
> a NUMA_NO_NODE node id comes into play. And this finally results in
> alloc_gigantic_page() being called with NUMA_NO_NODE as nid (which is
> -1), and NODE_DATA(nid)->node_zones will then reach into Nirvana.
Thanks for pointing this.
I sent out the new patch just now. Could you please try it again?
I added a NUMA_NO_NODE check in the alloc_gigantic_page();
thanks
Huang Shijie
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Qemu-devel] Concerning " [PULL 6/6] curses: Use cursesw instead of curses"
From: Sergey Smolov @ 2016-11-09 7:12 UTC (permalink / raw)
To: Cornelia Huck; +Cc: Stefan Hajnoczi, QEMU Developers
In-Reply-To: <20161108182841.512094fb.cornelia.huck@de.ibm.com>
On 08.11.2016 20:28, Cornelia Huck wrote:
> On Tue, 8 Nov 2016 16:49:51 +0000
> Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
>> On Tue, Nov 08, 2016 at 10:40:20AM +0300, Sergey Smolov wrote:
>>> Dear List!
>>>
>>> I've encountered the same problem as was discussed in this thread:
>>> https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg07898.html
>>>
>>> Does anybody succeeded in solving the problem?
>>>
>>> From my side, the problem appears when I run the 'configure' script with
>>> '--target-list=aarch64-softmmu' option. The script returns the following
>>> message to me:
>>>
>>> ERROR: configure test passed without -Werror but failed with -Werror.
>>> This is probably a bug in the configure script. The failing command
>>> will be at the bottom of config.log.
>>> You can run configure with --disable-werror to bypass this check.
>>>
>>> I've attached a config.log to this e-mail.
>> [...]
>>
>>> cc -Werror -fPIE -DPIE -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng14 -o config-temp/qemu-conf.exe config-temp/qemu-conf.c -Wl,-z,relro -Wl,-z,now -pie -m64 -g -lncursesw
>>> config-temp/qemu-conf.c: In function ‘main’:
>>> config-temp/qemu-conf.c:9:3: error: implicit declaration of function ‘addwstr’ [-Werror=implicit-function-declaration]
>>> config-temp/qemu-conf.c:9:3: error: nested extern declaration of ‘addwstr’ [-Werror=nested-externs]
>>> config-temp/qemu-conf.c:10:3: error: implicit declaration of function ‘addnwstr’ [-Werror=implicit-function-declaration]
>>> config-temp/qemu-conf.c:10:3: error: nested extern declaration of ‘addnwstr’ [-Werror=nested-externs]
>>> cc1: all warnings being treated as errors
>> http://pdcurses.sourceforge.net/doc/PDCurses.txt:
>>
>> Wide-character functions from the X/Open standard -- these are only
>> available when PDCurses is built with PDC_WIDE defined, and the
>> prototypes are only available from curses.h when PDC_WIDE is defined
>> before its inclusion in your app:
>>
>> addnwstr addstr
>> addwstr addstr
>>
>> QEMU does not define PDC_WIDE. Try adding ./configure
>> --extra-flags=-DPDC_WIDE.
> I think the problem is rather the incorrect include detection in
> configure -- see <20161107133833.3681-1-msuchanek@suse.de> ("[PATCH]
> Fix legacy ncurses detection.") and the following thread.
>
> Sergey: Are you running on SLES?
>
>
Dear Cornelia,
I'm running on OpenSUSE 12.2 x86_64.
I've tried to use this patch, but the situation keeps the same.
--
Thanks,
Sergey Smolov
^ permalink raw reply
* Re: [PATCH] mmc: sdhci-pci: Add support for HS200 tuning mode, on AMD eMMC-4.5.1
From: Shyam Sundar S K @ 2016-11-09 7:14 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, adrian.hunter, Ulf Hansson, linux-mmc, Pankaj.Sen,
Nehal-bakulchandra.Shah, Agrawal, Nitesh-kumar
In-Reply-To: <201611091506.s29MX9Hj%fengguang.wu@intel.com>
Hi Ulf, Adrian
> drivers/mmc/host/sdhci-pci-core.c: In function 'amd_find_good_phase':
>>> drivers/mmc/host/sdhci-pci-core.c:877:37: error: implicit declaration of function 'sdhci_pci_priv' [-Werror=implicit-function-declaration]
> struct amd_tuning_descriptor *td = sdhci_pci_priv(slot);
This build error is because, it has dependency on Adrian patch "mmc: sdhci-pci: Let devices define their own private data".
Kindly add our patch on top of Adrian's patch and that will resolve the build error.
Thanks,
Shyam
On 11/9/2016 12:36 PM, kbuild test robot wrote:
> Hi Shyam,
>
> [auto build test ERROR on ulf.hansson-mmc/next]
> [also build test ERROR on v4.9-rc4 next-20161109]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Shyam-Sundar-S-K/mmc-sdhci-pci-Add-support-for-HS200-tuning-mode-on-AMD-eMMC-4-5-1/20161109-145027
> base: https://git.linaro.org/people/ulf.hansson/mmc next
> config: i386-randconfig-x006-201645 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All error/warnings (new ones prefixed by >>):
>
> drivers/mmc/host/sdhci-pci-core.c: In function 'amd_find_good_phase':
>>> drivers/mmc/host/sdhci-pci-core.c:877:37: error: implicit declaration of function 'sdhci_pci_priv' [-Werror=implicit-function-declaration]
> struct amd_tuning_descriptor *td = sdhci_pci_priv(slot);
> ^~~~~~~~~~~~~~
>>> drivers/mmc/host/sdhci-pci-core.c:877:37: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
> drivers/mmc/host/sdhci-pci-core.c: In function 'amd_execute_tuning':
> drivers/mmc/host/sdhci-pci-core.c:946:37: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
> struct amd_tuning_descriptor *td = sdhci_pci_priv(slot);
> ^~~~~~~~~~~~~~
> Cyclomatic Complexity 1 arch/x86/include/asm/paravirt.h:arch_local_save_flags
> Cyclomatic Complexity 1 arch/x86/include/asm/paravirt.h:arch_local_irq_restore
> Cyclomatic Complexity 1 arch/x86/include/asm/paravirt.h:arch_local_irq_disable
> Cyclomatic Complexity 1 arch/x86/include/asm/paravirt.h:arch_local_irq_save
> Cyclomatic Complexity 1 include/linux/err.h:ERR_PTR
> Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
> Cyclomatic Complexity 2 include/linux/err.h:IS_ERR
> Cyclomatic Complexity 1 include/linux/err.h:ERR_CAST
> Cyclomatic Complexity 1 arch/x86/include/asm/irqflags.h:arch_irqs_disabled_flags
> Cyclomatic Complexity 1 arch/x86/include/asm/preempt.h:should_resched
> Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check
> Cyclomatic Complexity 3 include/linux/spinlock.h:spin_unlock_irqrestore
> Cyclomatic Complexity 1 arch/x86/include/asm/io.h:readb
> Cyclomatic Complexity 1 arch/x86/include/asm/io.h:readw
> Cyclomatic Complexity 1 arch/x86/include/asm/io.h:readl
> Cyclomatic Complexity 1 arch/x86/include/asm/io.h:writeb
> Cyclomatic Complexity 1 arch/x86/include/asm/io.h:writew
> Cyclomatic Complexity 1 arch/x86/include/asm/io.h:writel
> Cyclomatic Complexity 1 include/linux/kobject.h:kobject_name
> Cyclomatic Complexity 1 include/linux/device.h:devm_kzalloc
> Cyclomatic Complexity 3 include/linux/device.h:dev_name
> Cyclomatic Complexity 1 include/linux/device.h:dev_get_drvdata
> Cyclomatic Complexity 1 include/linux/device.h:dev_set_drvdata
> Cyclomatic Complexity 1 include/linux/pci.h:pci_read_config_byte
> Cyclomatic Complexity 1 include/linux/pci.h:pci_read_config_dword
> Cyclomatic Complexity 1 include/linux/pci.h:pci_write_config_byte
> Cyclomatic Complexity 1 include/linux/pci.h:pci_write_config_dword
> Cyclomatic Complexity 1 include/linux/pci.h:pci_get_drvdata
> Cyclomatic Complexity 1 include/linux/pci.h:pci_set_drvdata
> Cyclomatic Complexity 1 include/linux/mmc/host.h:mmc_priv
> Cyclomatic Complexity 1 include/asm-generic/gpio.h:gpio_is_valid
> Cyclomatic Complexity 1 include/asm-generic/gpio.h:gpio_direction_output
> Cyclomatic Complexity 1 include/asm-generic/gpio.h:gpio_set_value_cansleep
> Cyclomatic Complexity 1 include/linux/pm_runtime.h:pm_runtime_allow
> Cyclomatic Complexity 1 include/linux/pm_runtime.h:pm_runtime_forbid
> Cyclomatic Complexity 1 include/linux/pm_runtime.h:pm_suspend_ignore_children
> Cyclomatic Complexity 1 include/linux/pm_runtime.h:pm_runtime_get_noresume
> Cyclomatic Complexity 1 include/linux/pm_runtime.h:pm_runtime_put_noidle
> Cyclomatic Complexity 1 include/linux/pm_runtime.h:__pm_runtime_use_autosuspend
> Cyclomatic Complexity 1 include/linux/pm_runtime.h:pm_runtime_set_autosuspend_delay
> Cyclomatic Complexity 1 include/linux/pm_runtime.h:pm_runtime_use_autosuspend
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci.h:sdhci_writel
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci.h:sdhci_writew
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci.h:sdhci_writeb
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci.h:sdhci_readl
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci.h:sdhci_readw
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci.h:sdhci_readb
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci.h:sdhci_priv
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:ricoh_mmc_probe_slot
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:mrst_hc_probe_slot
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:mrst_hc_probe
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:pch_hc_probe_slot
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_add_own_cd
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_remove_own_cd
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:mfd_emmc_probe_slot
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:mfd_sdio_probe_slot
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:byt_sdio_probe_slot
> Cyclomatic Complexity 4 drivers/mmc/host/sdhci-pci-core.c:intel_mrfld_mmc_probe_slot
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:rtsx_probe_slot
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:amd_enable_manual_tuning
> Cyclomatic Complexity 3 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_set_bus_width
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_runtime_pm_allow
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_runtime_pm_forbid
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:sdhci_driver_init
> Cyclomatic Complexity 3 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_select_drive_strength
> Cyclomatic Complexity 3 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_hw_reset
> Cyclomatic Complexity 12 drivers/mmc/host/sdhci-pci-core.c:byt_sd_probe_slot
> Cyclomatic Complexity 5 drivers/mmc/host/sdhci-pci-core.c:spt_select_drive_strength
> Cyclomatic Complexity 3 drivers/mmc/host/sdhci-pci-core.c:via_probe
> Cyclomatic Complexity 3 drivers/mmc/host/sdhci-pci-core.c:syskt_probe
> Cyclomatic Complexity 3 drivers/mmc/host/sdhci-pci-core.c:jmicron_enable_mmc
> Cyclomatic Complexity 5 drivers/mmc/host/sdhci-pci-core.c:jmicron_pmos
> Cyclomatic Complexity 10 drivers/mmc/host/sdhci-pci-core.c:jmicron_suspend
> Cyclomatic Complexity 11 drivers/mmc/host/sdhci-pci-core.c:jmicron_remove_slot
> Cyclomatic Complexity 15 drivers/mmc/host/sdhci-pci-core.c:jmicron_probe_slot
> Cyclomatic Complexity 9 drivers/mmc/host/sdhci-pci-core.c:ricoh_probe
> Cyclomatic Complexity 19 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_remove_slot
> Cyclomatic Complexity 4 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_remove
> Cyclomatic Complexity 12 drivers/mmc/host/sdhci-pci-core.c:jmicron_resume
> Cyclomatic Complexity 69 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_probe_slot
> Cyclomatic Complexity 33 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_probe
> Cyclomatic Complexity 29 drivers/mmc/host/sdhci-pci-core.c:spt_read_drive_strength
> Cyclomatic Complexity 5 drivers/mmc/host/sdhci-pci-core.c:byt_emmc_probe_slot
> Cyclomatic Complexity 8 drivers/mmc/host/sdhci-pci-core.c:syskt_probe_slot
> Cyclomatic Complexity 2 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_gpio_hw_reset
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_int_hw_reset
> Cyclomatic Complexity 12 drivers/mmc/host/sdhci-pci-core.c:sdhci_pci_enable_dma
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:amd_tuning_reset
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:amd_config_tuning_phase
> Cyclomatic Complexity 42 drivers/mmc/host/sdhci-pci-core.c:amd_find_good_phase
> Cyclomatic Complexity 3 drivers/mmc/host/sdhci-pci-core.c:amd_execute_tuning
> Cyclomatic Complexity 9 drivers/mmc/host/sdhci-pci-core.c:amd_probe
> Cyclomatic Complexity 6 drivers/mmc/host/sdhci-pci-core.c:sdhci_intel_set_power
> Cyclomatic Complexity 5 drivers/mmc/host/sdhci-pci-core.c:bxt_get_cd
> Cyclomatic Complexity 24 drivers/mmc/host/sdhci-pci-core.c:jmicron_probe
> Cyclomatic Complexity 1 drivers/mmc/host/sdhci-pci-core.c:ricoh_mmc_resume
>
> vim +/sdhci_pci_priv +877 drivers/mmc/host/sdhci-pci-core.c
>
> 871 }
> 872
> 873 static int amd_find_good_phase(struct sdhci_host *host)
> 874 {
> 875 struct sdhci_pci_slot *slot = sdhci_priv(host);
> 876 struct pci_dev *pdev = slot->chip->pdev;
> > 877 struct amd_tuning_descriptor *td = sdhci_pci_priv(slot);
> 878
> 879 unsigned int val;
> 880 unsigned long flags;
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
^ permalink raw reply
* Re: Virtio_net support vxlan encapsulation package TSO offload discuss
From: Jason Wang @ 2016-11-09 7:14 UTC (permalink / raw)
To: Zhangming (James, Euler), netdev@vger.kernel.org
Cc: Michael S. Tsirkin, Vlad Yasevic
In-Reply-To: <DBCD2614ECF3FF4087A2C27CA80E34DD5401ADA8@SZXEMA501-MBX.china.huawei.com>
On 2016年11月08日 19:58, Zhangming (James, Euler) wrote:
> On 2016年11月08日 19:17, Jason Wang wrote:
>
>> On 2016年11月08日 19:13, Jason Wang wrote:
>>> Cc Michael
>>>
>>> On 2016年11月08日 16:34, Zhangming (James, Euler) wrote:
>>>> In container scenario, OVS is installed in the Virtual machine, and
>>>> all the containers connected to the OVS will communicated through
>>>> VXLAN encapsulation.
>>>>
>>>> By now, virtio_net does not support TSO offload for VXLAN
>>>> encapsulated TSO package. In this condition, the performance is not
>>>> good, sender is bottleneck
>>>>
>>>> I googled this scenario, but I didn’t find any information. Will
>>>> virtio_net support VXLAN encapsulation package TSO offload later?
>>>>
>>> Yes and for both sender and receiver.
>>>
>>>> My idea is virtio_net open encapsulated TSO offload, and transport
>>>> encapsulation info to TUN, TUN will parse the info and build skb with
>>>> encapsulation info.
>>>>
>>>> OVS or kernel on the host should be modified to support this. Using
>>>> this method, the TCP performance aremore than 2x as before.
>>>>
>>>> Any advice and suggestions for this idea or new idea will be greatly
>>>> appreciated!
>>>>
>>>> Best regards,
>>>>
>>>> James zhang
>>>>
>>> Sounds very good. And we may also need features bits
>>> (VIRTIO_NET_F_GUEST|HOST_GSO_X) for this.
>>>
>>> This is in fact one of items in networking todo list. (See
>>> http://www.linux-kvm.org/page/NetworkingTodo). While at it, we'd
>>> better support not only VXLAN but also other tunnels.
>> Cc Vlad who is working on extending virtio-net headers.
>>
>>> We can start with the spec work, or if you've already had some bits
>>> you can post them as RFC for early review.
>>>
>>> Thanks
> Below is my demo code
> Virtio_net.c
> static int virtnet_probe(struct virtio_device *vdev), add belows codes:
> if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF) || // avoid gso segment, it should be negotiation later, because in the demo I reuse num_buffers.
> virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
> dev->hw_enc_features |= NETIF_F_TSO;
> dev->hw_enc_features |= NETIF_F_ALL_CSUM;
> dev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL;
> dev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL_CSUM;
> dev->hw_enc_features |= NETIF_F_GSO_TUNNEL_REMCSUM;
>
> dev->features |= NETIF_F_GSO_UDP_TUNNEL;
> dev->features |= NETIF_F_GSO_UDP_TUNNEL_CSUM;
> dev->features |= NETIF_F_GSO_TUNNEL_REMCSUM;
> }
>
> static int xmit_skb(struct send_queue *sq, struct sk_buff *skb), add below to pieces of codes
>
> if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL)
> hdr->hdr.gso_type |= VIRTIO_NET_HDR_GSO_TUNNEL;
> if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL_CSUM)
> hdr->hdr.gso_type |= VIRTIO_NET_HDR_GSO_TUNNEL_CSUM;
> if (skb_shinfo(skb)->gso_type & SKB_GSO_TUNNEL_REMCSUM)
> hdr->hdr.gso_type |= VIRTIO_NET_HDR_GSO_TUNNEL_REMCSUM;
>
> if (skb->encapsulation && skb_is_gso(skb)) {
> inner_mac_len = skb_inner_network_header(skb) - skb_inner_mac_header(skb);
> tnl_len = skb_inner_mac_header(skb) - skb_mac_header(skb);
> if ( !(inner_mac_len >> DATA_LEN_SHIFT) && !(tnl_len >> DATA_LEN_SHIFT) ) {
> hdr->hdr.flags |= VIRTIO_NET_HDR_F_ENCAPSULATION;
> hdr->num_buffers = (__virtio16)((inner_mac_len << DATA_LEN_SHIFT) | tnl_len); //we reuse num_buffers for simple , we should add extend member for later.
> } else
> hdr->num_buffers = 0;
> }
>
> Tun.c
> if (memcpy_fromiovecend((void *)&hdr, iv, offset, tun->vnet_hdr_sz)) //read header with negotiation length
> return -EFAULT;
>
> if (hdr.gso_type & VIRTIO_NET_HDR_GSO_TUNNEL) //set tunnel gso info
> skb_shinfo(skb)->gso_type |= SKB_GSO_UDP_TUNNEL;
> if (hdr.gso_type & VIRTIO_NET_HDR_GSO_TUNNEL_CSUM)
> skb_shinfo(skb)->gso_type |= SKB_GSO_UDP_TUNNEL_CSUM;
> if (hdr.gso_type & VIRTIO_NET_HDR_GSO_TUNNEL_REMCSUM)
> skb_shinfo(skb)->gso_type |= SKB_GSO_TUNNEL_REMCSUM;
>
> if (hdr.flags & VIRTIO_NET_HDR_F_ENCAPSULATION) { //read tunnel info from header and set to built skb.
> tnl_len = tun16_to_cpu(tun, hdr.num_buffers) & TUN_TNL_LEN_MASK;
> payload_mac_len = tun16_to_cpu(tun, hdr.num_buffers) >> TUN_DATA_LEN_SHIFT;
> mac_len = skb_network_header(skb) - skb_mac_header(skb);
> skb_set_inner_mac_header(skb, tnl_len - mac_len);
> skb_set_inner_network_header(skb, tnl_len + payload_mac_len - mac_len);
> skb->encapsulation = 1;
> }
>
>
Something like this, and you probably need do something more:
- use net-next.git to generate the patch (for the latest code)
- add feature negotiation
- tun/macvtap/qemu patches for this, you can start with tun/macvtap patches
- support for all other SKB_GSO_* types which is not supported
- use a new field instead of num_buffers
- a virtio spec patch to describe the support for encapsulation offload
Thanks
^ permalink raw reply
* Re: [PATCH] arm64:renesas: Introduce early console for Salvator-X board
From: Dirk Behme @ 2016-11-09 7:14 UTC (permalink / raw)
To: Iurii Mykhalskyi; +Cc: Julien Grall, Stefano Stabellini, Dirk Behme, xen-devel
In-Reply-To: <CAC+yBMsY_dje3q8Fkm5zAigR+1ZS=YUONGi=ovMJP2UK9WncHA@mail.gmail.com>
Hi Iurii,
On 08.11.2016 16:41, Iurii Mykhalskyi wrote:
> Hello Dirk,
>
> I have made only single change - I recompile ATF to leave CPU in EL2
> mode and reflash it.
Yes, this is what I meant with 'modifying firmware' ;)
You are loading Xen with U-Boot running in EL2, then?
With this modification, do all other use cases still work? E.g. load and
boot U-Boot and native Linux kernel without Xen?
> Looks like this way are the mostly "correct" approach for this board.
>
> All changes are made in publicly available sources, based on official
> Renesas H3 yocto layer - https://github.com/renesas-rcar/meta-renesas
>
> If you don't mind - I can create & handle documentation page about board
> setup and take ownership about further board support.
I'm fine with that. Thanks!
Best regards
Dirk
> On Tue, Nov 8, 2016 at 5:22 PM, Dirk Behme <dirk.behme@gmail.com
> <mailto:dirk.behme@gmail.com>> wrote:
>
> On 08.11.2016 15:30, Julien Grall wrote:
>
> Hello Iurii,
>
> Dirk (in CC) sent a similar patch few months ago to add support for
> this board (see [1]).
>
> I didn't ack the patch back then because I wanted to see
> documentation
> on the wiki to bring up Xen on this board (see [2] for the
> requirements). I didn't see any follow-up since then for this board.
>
> Can one of you write a documentation for this board
>
>
>
> Yes, that would be nice.
>
> As mentioned, I couldn't find an 'easy' way to load Xen without
> modifying the firmware (U-Boot or ATF) or using a JTAG debugger.
> Therefore I hesitated to write that documentation.
>
> Maybe Iurii found an easier, more user compatible way?
>
> Best regards
>
> Dirk
>
>
>
> and take
>
> "ownership" on this board?
>
> Regards,
>
> [1]
> https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00315.html
> <https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00315.html>
>
> [2]
> https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00130.html
> <https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00130.html>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH linux v2 2/3] drivers: hwmon: ASPEED AST2500 PWM driver
From: Joel Stanley @ 2016-11-09 7:15 UTC (permalink / raw)
To: Jaghathiswari Rankappagounder Natarajan; +Cc: OpenBMC Maillist
In-Reply-To: <1478657505-23109-3-git-send-email-jaghu@google.com>
Hello Jaghu,
On Wed, Nov 9, 2016 at 12:41 PM, Jaghathiswari Rankappagounder
Natarajan <jaghu@google.com> wrote:
> The ASPEED AST2500 PWM controller can support upto 8 PWM output ports.
I noticed that the ast2500 and ast2400 share the same PWM IP, so we
can use the same driver for both. You should reflect this in the
naming of the Kconfig, filename, commit message and the code itself.
> There are three different PWM sources(types M, N and O)
> and each PWM output port can be assigned a particular PWM source.
> There is a sysfs file through which the user can control
> the duty cycle of a particular PWM port. The duty cycle can range from 0 to
> 100 percent.
Can you explain why this is a hwmon driver and not a pwm driver?
>
> v2:
> - Merged the drivers for PWM controller and PWM device as one PWM driver.
Thanks for adding the changelog. This should go below the --, two
lines lower. We do this to ensure the changelog is not part of the
committed patch.
>
> Signed-off-by: Jaghathiswari Rankappagounder Natarajan <jaghu@google.com>
> ---
> drivers/hwmon/Kconfig | 5 +
> drivers/hwmon/Makefile | 2 +-
> drivers/hwmon/aspeed_ast2500_pwm.c | 662 +++++++++++++++++++++++++++++++++++++
> drivers/hwmon/aspeed_ast2500_pwm.h | 128 +++++++
> 4 files changed, 796 insertions(+), 1 deletion(-)
> create mode 100644 drivers/hwmon/aspeed_ast2500_pwm.c
> create mode 100644 drivers/hwmon/aspeed_ast2500_pwm.h
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 3b34ba9..7edd94e 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1800,6 +1800,11 @@ config SENSORS_ULTRA45
> This driver provides support for the Ultra45 workstation environmental
> sensors.
>
> +config ASPEED_AST2500_PWM
> + tristate "ASPEED AST2500 PWM driver"
> + help
> + This driver provides support for ASPEED AST2500 PWM output ports.
> +
> if ACPI
>
> comment "ACPI drivers"
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index c0f3201..23529c2 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -163,7 +163,7 @@ obj-$(CONFIG_SENSORS_W83L785TS) += w83l785ts.o
> obj-$(CONFIG_SENSORS_W83L786NG) += w83l786ng.o
> obj-$(CONFIG_SENSORS_WM831X) += wm831x-hwmon.o
> obj-$(CONFIG_SENSORS_WM8350) += wm8350-hwmon.o
> -
> +obj-$(CONFIG_ASPEED_AST2500_PWM) += aspeed_ast2500_pwm.o
> obj-$(CONFIG_PMBUS) += pmbus/
>
> ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
> diff --git a/drivers/hwmon/aspeed_ast2500_pwm.c b/drivers/hwmon/aspeed_ast2500_pwm.c
> new file mode 100644
> index 0000000..fda49d7
> --- /dev/null
> +++ b/drivers/hwmon/aspeed_ast2500_pwm.c
> @@ -0,0 +1,662 @@
> +/*
> + * Aspeed AST2500 PWM device driver
most of the time we don't add the name at the top of hte file.
> + * * Copyright (c) 2016 Google, Inc
> + *
> + * * This program is free software; you can redistribute it and/or modify
> + * * it under the terms of the GNU General Public License version 2 as
> + * * published by the Free Software Foundation.
Lose the second row of stars.
The new drivers we contribute are v2 or later. This is your choice,
but if there's no issue adding the or later it would be nice for all
of the Aspeed code to be consistent.
> + *
> + */
> +
> +#include <linux/platform_device.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_device.h>
> +#include <linux/io.h>
> +#include <linux/hwmon-sysfs.h>
> +#include <linux/hwmon.h>
> +#include <linux/sysfs.h>
> +
> +#include "aspeed_pwm.h"
> +
> +struct ast_pwm_port_data {
For better or worse, we've settled on "aspeed" as the prefix for all
of the drivers. Please use that instead of ast.
> + u8 pwm_port;
> + u8 pwm_enable;
> + u8 pwm_type;
> + u8 pwm_duty_cycle;
> + void __iomem *base;
> +};
> +
> +struct ast_pwm_controller_data {
> + void __iomem *base;
> +};
> +
> +static inline void
> +ast_pwm_write(void __iomem *base, u32 val, u32 reg)
> +{
> + writel(val, base + reg);
> +}
> +
> +static inline u32
> +ast_pwm_read(void __iomem *base, u32 reg)
> +{
> + u32 val = readl(base + reg);
> + return val;
> +}
> +
> +static void
> +ast_set_pwm_clock_enable(struct ast_pwm_controller_data *priv, u8 val)
val is a boolean.
> +{
> + if (val) {
> + ast_pwm_write(priv->base,
> + ast_pwm_read(priv->base, AST_PTCR_CTRL) |
> + AST_PTCR_CTRL_CLK_EN, AST_PTCR_CTRL);
> + } else {
> + ast_pwm_write(priv->base,
> + ast_pwm_read(priv->base, AST_PTCR_CTRL) &
> + ~AST_PTCR_CTRL_CLK_EN, AST_PTCR_CTRL);
> + }
> +}
> +static void
> +ast_set_pwm_enable(struct ast_pwm_port_data *priv, u8 enable)
> +{
> + u8 pwm_ch = priv->pwm_port;
> +
The switch statements where you read-modify-write are hard to read. I
suggest reading the register value into a variable, modify it in your
switch statement, and write it at the end. This makes it easier to
read what operations you're performing on the bits.
u32 reg = ast_pwm_read(priv->base, AST_PTCR_CTRL);
switch (pwm_ch) {
case PWMA:
port = AST_PTCR_CTRL_PWMA_EN;
break;
case PWMB:
port = AST_PTCR_CTRL_PWMB_EN;
break;
...
}
if (enable)
reg |= port;
else
reg &= ~port;
ast_pwm_write(priv->base, reg, AST_PTCR_CTRL);
I think this structure will make this more readable. You could store
the AST_PTCR_CTRL_PWMx_EN value as priv->pwm_port, and lose the switch
statement all together.
This suggestion wont work for the other switch statements obviously.
Can you think of a representation that would allow you to look up the
values without requiring a switch statement? Take a look at some of
the other pwm drivers for inspiration.
> + switch (pwm_ch) {
> + case PWMA:
> + if (enable)
> + ast_pwm_write(priv->base,
> + ast_pwm_read(priv->base,
> + AST_PTCR_CTRL) |
> + AST_PTCR_CTRL_PWMA_EN,
> + AST_PTCR_CTRL);
> +static void
> +ast_set_pwm_type(struct ast_pwm_port_data *priv, u8 type)
> +{
> + u32 tmp1, tmp2;
> + u8 pwm_ch = priv->pwm_port;
> +
> + tmp1 = ast_pwm_read(priv->base, AST_PTCR_CTRL);
> + tmp2 = ast_pwm_read(priv->base, AST_PTCR_CTRL_EXT);
I think we can do better than tmp1 and tmp2. perhaps ctrl and ctrl_ext?
> +
> + switch (pwm_ch) {
As with pwm_type, pwm_ch could be an enum. That way you get warnings
if you omit an option in your switch statement.
> + case PWMA:
> + tmp1 &= ~AST_PTCR_CTRL_SET_PWMA_TYPE_MASK;
> + tmp1 |= AST_PTCR_CTRL_SET_PWMA_TYPE(type);
> + ast_pwm_write(priv->base, tmp1, AST_PTCR_CTRL);
> +
> + break;
> +static int
> +aspeed_create_pwm_port(struct device *dev, struct device_node *child,
> + void __iomem *base)
> +{
> + struct device *hwmon;
> + u8 val;
> + struct ast_pwm_port_data *priv;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + hwmon = devm_hwmon_device_register_with_groups(dev, "pwm_port",
"aspeed_pwm"?
> + priv, pwm_dev_groups);
> + if (IS_ERR(hwmon)) {
> + dev_err(dev, "Failed to register hwmon device\n");
> + return PTR_ERR(hwmon);
> + }
> + priv->base = base;
> +
> + of_property_read_u8(child, "pwm_port", &val);
> + priv->pwm_port = val;
> +
> + of_property_read_u8(child, "pwm_enable", &val);
> + priv->pwm_enable = val;
> + ast_set_pwm_enable(priv, val);
> +
> + of_property_read_u8(child, "pwm_type", &val);
> + priv->pwm_type = val;
> + ast_set_pwm_type(priv, val);
> +
> + of_property_read_u8(child, "pwm_duty_cycle_percent", &val);
> + priv->pwm_duty_cycle = val;
> + ast_set_pwm_duty_cycle(priv, val);
> + return 0;
> +}
> +
> +static int
> +aspeed_ast2500_pwm_probe(struct platform_device *pdev)
> +{
> + u32 buf[4];
> + struct device_node *np, *child;
> + struct resource *res;
> + u8 val;
> + int err;
> + struct ast_pwm_controller_data *priv;
> +
> + np = pdev->dev.of_node;
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(struct ast_pwm_controller_data),
> + GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
Can you explain why you chose to allocate structure here? You don't
seem to use it outside of the probe function which suggests it's
unnecessary.
You can just get the base address, map it in (ioremap) to configure
the state and then discard the mapping in the probe.
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (res == NULL) {
> + return -ENOENT;
> + }
> +
> + priv->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> + if (!priv->base)
> + return -ENOMEM;
> +
> + of_property_read_u8(np, "clock_enable", &val);
> + ast_set_pwm_clock_enable(priv, val);
> + of_property_read_u8(np, "clock_source", &val);
> + ast_set_pwm_clock_source(priv, val);
This needs reworking. I will comment on the bindings which will lead
to changes in this code.
> +
> + of_property_read_u32_array(np, "typem_pwm_clock", buf, 4);
> + if (buf[0] == 1) {
> + ast_set_pwm_clock_division_l(priv, PWM_TYPE_M, buf[1]);
> + ast_set_pwm_clock_division_h(priv, PWM_TYPE_M, buf[2]);
> + ast_set_pwm_clock_unit(priv, PWM_TYPE_M, buf[3]);
> + }
> +
> + of_property_read_u32_array(np, "typen_pwm_clock", buf, 4);
> + if (buf[0] == 1) {
> + ast_set_pwm_clock_division_l(priv, PWM_TYPE_N, buf[1]);
> + ast_set_pwm_clock_division_h(priv, PWM_TYPE_N, buf[2]);
> + ast_set_pwm_clock_unit(priv, PWM_TYPE_N, buf[3]);
> + }
> +
> + of_property_read_u32_array(np, "typeo_pwm_clock", buf, 4);
> + if (buf[0] == 1) {
> + ast_set_pwm_clock_division_l(priv, PWM_TYPE_O, buf[1]);
> + ast_set_pwm_clock_division_h(priv, PWM_TYPE_O, buf[2]);
> + ast_set_pwm_clock_unit(priv, PWM_TYPE_O, buf[3]);
> + }
> +
> + for_each_child_of_node(np, child) {
> + aspeed_create_pwm_port(&pdev->dev,
> + child, priv->base);
> + of_node_put(child);
> + }
> + of_node_put(np);
> + return 0;
> +}
> +
> +static int
> +aspeed_ast2500_pwm_remove(struct platform_device *pdev)
> +{
> + return 0;
> +}
> +
> +static const struct of_device_id of_pwm_match_table[] = {
> + { .compatible = "aspeed,ast2500-pwm", },
As discussed above, this should contain the ast2400 string as well.
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, of_pwm_match_table);
> +
> +static struct platform_driver aspeed_ast2500_pwm_driver = {
> + .probe = aspeed_ast2500_pwm_probe,
> + .remove = aspeed_ast2500_pwm_remove,
Your remove does nothing, you can omit it.
> + .driver = {
> + .name = "aspeed_ast2500_pwm",
> + .owner = THIS_MODULE,
> + .of_match_table = of_pwm_match_table,
> + },
> +};
> +
> +module_platform_driver(aspeed_ast2500_pwm_driver);
> +
> +MODULE_AUTHOR("Jaghathiswari Rankappagounder Natarajan <jaghu@google.com>");
> +MODULE_DESCRIPTION("ASPEED AST2500 PWM device driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/hwmon/aspeed_ast2500_pwm.h b/drivers/hwmon/aspeed_ast2500_pwm.h
> new file mode 100644
> index 0000000..1986fd2
> --- /dev/null
> +++ b/drivers/hwmon/aspeed_ast2500_pwm.h
Headers in the kernel are generally only used when we need to share
details between parts of the kernel. Given there isn't a lot here, I
think these definitions should be in the c file.
> +#define DUTY_CTRL_PWM2_FALL_POINT (24)
> +#define DUTY_CTRL_PWM2_FALL_POINT_MASK (0xff<<24)
> +#define DUTY_CTRL_PWM2_RISE_POINT (16)
> +#define DUTY_CTRL_PWM2_RISE_POINT_MASK (0xff<<16)
> +#define DUTY_CTRL_PWM1_FALL_POINT (8)
> +#define DUTY_CTRL_PWM1_FALL_POINT_MASK (0xff<<8)
Try using GENMASK. For this it would be GENMASK(15, 8).
Do you really need the mask definitions?
> +#define DUTY_CTRL_PWM1_RISE_POINT (0)
> +#define DUTY_CTRL_PWM1_RISE_POINT_MASK (0xff)
> +
> +/* AST_PTCR_CTRL : 0x00 - General Control Register */
> +#define AST_PTCR_CTRL_SET_PWMD_TYPE(x) ((x & 0x1) << 15 | \
> + (x & 0x2) << 6)
> +#define AST_PTCR_CTRL_SET_PWMD_TYPE_MASK ((0x1 << 7) | (0x1 << 15))
You can use BIT(7) | BIT(15).
> +
> +#define AST_PTCR_CTRL_SET_PWMC_TYPE(x) ((x & 0x1) << 14 | \
> + (x & 0x2) << 5)
> +#define AST_PTCR_CTRL_PWMD (11)
> +#define AST_PTCR_CTRL_PWMD_EN (0x1 << 11)
> +#define AST_PTCR_CTRL_PWMC (10)
> +#define AST_PTCR_CTRL_PWMC_EN (0x1 << 10)
> +#define AST_PTCR_CTRL_PWMB (9)
> +#define AST_PTCR_CTRL_PWMB_EN (0x1 << 9)
> +#define AST_PTCR_CTRL_PWMA (8)
> +#define AST_PTCR_CTRL_PWMA_EN (0x1 << 8)
Consider only having the bit defintiions or the _EN. One can be
derived from the other.
You don't need to guard the integers with ( ).
> +
> +/*0:24Mhz, 1:MCLK */
> +#define AST_PTCR_CTRL_CLK_SRC 0x2
> +#define AST_PTCR_CTRL_CLK_EN 0x1
^ permalink raw reply
* [PATCH xf86-video-ati 1/2] Refactor radeon_mode_hotplug
From: Michel Dänzer @ 2016-11-09 7:16 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
From: Michel Dänzer <michel.daenzer@amd.com>
Preparation for the next change, no functional change intended.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
---
src/drmmode_display.c | 58 ++++++++++++++++++++++++++++++---------------------
1 file changed, 34 insertions(+), 24 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 28b932e..fd5c80e 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -2543,6 +2543,37 @@ Bool drmmode_setup_colormap(ScreenPtr pScreen, ScrnInfoPtr pScrn)
return TRUE;
}
+static Bool
+drmmode_find_output(ScrnInfoPtr scrn, int output_id, int *num_dvi,
+ int *num_hdmi)
+{
+ xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(scrn);
+ int i;
+
+ for (i = 0; i < config->num_output; i++) {
+ xf86OutputPtr output = config->output[i];
+ drmmode_output_private_ptr drmmode_output = output->driver_private;
+
+ if (drmmode_output->output_id == output_id) {
+ switch(drmmode_output->mode_output->connector_type) {
+ case DRM_MODE_CONNECTOR_DVII:
+ case DRM_MODE_CONNECTOR_DVID:
+ case DRM_MODE_CONNECTOR_DVIA:
+ (*num_dvi)++;
+ break;
+ case DRM_MODE_CONNECTOR_HDMIA:
+ case DRM_MODE_CONNECTOR_HDMIB:
+ (*num_hdmi)++;
+ break;
+ }
+
+ return TRUE;
+ }
+ }
+
+ return FALSE;
+}
+
void
radeon_mode_hotplug(ScrnInfoPtr scrn, drmmode_ptr drmmode)
{
@@ -2590,35 +2621,14 @@ restart_destroy:
for (s = 0; !found && s < xf86NumScreens; s++) {
ScrnInfoPtr loop_scrn = xf86Screens[s];
- xf86CrtcConfigPtr loop_config =
- XF86_CRTC_CONFIG_PTR(loop_scrn);
if (strcmp(loop_scrn->driverName, scrn->driverName) ||
RADEONEntPriv(loop_scrn) != pRADEONEnt)
continue;
- for (j = 0; !found && j < loop_config->num_output; j++) {
- xf86OutputPtr output = loop_config->output[j];
- drmmode_output_private_ptr drmmode_output;
-
- drmmode_output = output->driver_private;
- if (mode_res->connectors[i] ==
- drmmode_output->output_id) {
- found = TRUE;
-
- switch(drmmode_output->mode_output->connector_type) {
- case DRM_MODE_CONNECTOR_DVII:
- case DRM_MODE_CONNECTOR_DVID:
- case DRM_MODE_CONNECTOR_DVIA:
- num_dvi++;
- break;
- case DRM_MODE_CONNECTOR_HDMIA:
- case DRM_MODE_CONNECTOR_HDMIB:
- num_hdmi++;
- break;
- }
- }
- }
+ found = drmmode_find_output(loop_scrn,
+ mode_res->connectors[i],
+ &num_dvi, &num_hdmi);
}
if (found)
continue;
--
2.10.2
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related
* [PATCH xf86-video-ati 2/2] Use pRADEONEnt to find both screens of a GPU in radeon_mode_hotplug
From: Michel Dänzer @ 2016-11-09 7:17 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <20161109071700.24235-1-michel-otUistvHUpPR7s880joybQ@public.gmane.org>
From: Michel Dänzer <michel.daenzer@amd.com>
Fixes misbehaviour when hotplugging DisplayPort connectors on secondary
GPUs.
Fixes: c801f9f10a5d ("Handle Zaphod mode correctly in radeon_mode_hotplug")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98626
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
---
src/drmmode_display.c | 23 ++++++++---------------
src/radeon_kms.c | 5 +++++
src/radeon_probe.h | 2 ++
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index fd5c80e..070979d 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -2580,7 +2580,7 @@ radeon_mode_hotplug(ScrnInfoPtr scrn, drmmode_ptr drmmode)
xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(scrn);
RADEONEntPtr pRADEONEnt = RADEONEntPriv(scrn);
drmModeResPtr mode_res;
- int i, j, s;
+ int i, j;
Bool found;
Bool changed = FALSE;
int num_dvi = 0, num_hdmi = 0;
@@ -2617,20 +2617,13 @@ restart_destroy:
/* find new output ids we don't have outputs for */
for (i = 0; i < mode_res->count_connectors; i++) {
- found = FALSE;
-
- for (s = 0; !found && s < xf86NumScreens; s++) {
- ScrnInfoPtr loop_scrn = xf86Screens[s];
-
- if (strcmp(loop_scrn->driverName, scrn->driverName) ||
- RADEONEntPriv(loop_scrn) != pRADEONEnt)
- continue;
-
- found = drmmode_find_output(loop_scrn,
- mode_res->connectors[i],
- &num_dvi, &num_hdmi);
- }
- if (found)
+ if (drmmode_find_output(pRADEONEnt->primary_scrn,
+ mode_res->connectors[i],
+ &num_dvi, &num_hdmi) ||
+ (pRADEONEnt->secondary_scrn &&
+ drmmode_find_output(pRADEONEnt->secondary_scrn,
+ mode_res->connectors[i],
+ &num_dvi, &num_hdmi)))
continue;
if (drmmode_output_init(scrn, drmmode, mode_res, i, &num_dvi,
diff --git a/src/radeon_kms.c b/src/radeon_kms.c
index 6927f58..ee2becd 100644
--- a/src/radeon_kms.c
+++ b/src/radeon_kms.c
@@ -1659,6 +1659,11 @@ Bool RADEONPreInit_KMS(ScrnInfoPtr pScrn, int flags)
}
}
+ if (info->IsSecondary)
+ pRADEONEnt->secondary_scrn = pScrn;
+ else
+ pRADEONEnt->primary_scrn = pScrn;
+
info->PciInfo = xf86GetPciInfoForEntity(info->pEnt->index);
pScrn->monitor = pScrn->confScreen->monitor;
diff --git a/src/radeon_probe.h b/src/radeon_probe.h
index 258c7be..573d988 100644
--- a/src/radeon_probe.h
+++ b/src/radeon_probe.h
@@ -139,6 +139,8 @@ typedef struct
unsigned long fd_wakeup_registered; /* server generation for which fd has been registered for wakeup handling */
int fd_wakeup_ref;
unsigned int assigned_crtcs;
+ ScrnInfoPtr primary_scrn;
+ ScrnInfoPtr secondary_scrn;
#ifdef XSERVER_PLATFORM_BUS
struct xf86_platform_device *platform_dev;
#endif
--
2.10.2
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH for-2.8] migration: Fix return code of ram_save_iterate()
From: Amit Shah @ 2016-11-09 7:18 UTC (permalink / raw)
To: Thomas Huth
Cc: Juan Quintela, qemu-devel, Dr. David Alan Gilbert, David Gibson
In-Reply-To: <1478265017-5700-1-git-send-email-thuth@redhat.com>
On (Fri) 04 Nov 2016 [14:10:17], Thomas Huth wrote:
> qemu_savevm_state_iterate() expects the iterators to return 1
> when they are done, and 0 if there is still something left to do.
> However, ram_save_iterate() does not obey this rule and returns
> the number of saved pages instead. This causes a fatal hang with
> ppc64 guests when you run QEMU like this (also works with TCG):
"works with" -- does that mean reproduces with?
> qemu-img create -f qcow2 /tmp/test.qcow2 1M
> qemu-system-ppc64 -nographic -nodefaults -m 256 \
> -hda /tmp/test.qcow2 -serial mon:stdio
>
> ... then switch to the monitor by pressing CTRL-a c and try to
> save a snapshot with "savevm test1" for example.
>
> After the first iteration, ram_save_iterate() always returns 0 here,
> so that qemu_savevm_state_iterate() hangs in an endless loop and you
> can only "kill -9" the QEMU process.
> Fix it by using proper return values in ram_save_iterate().
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
> migration/ram.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/migration/ram.c b/migration/ram.c
> index fb9252d..a1c8089 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -1987,7 +1987,7 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
> int ret;
> int i;
> int64_t t0;
> - int pages_sent = 0;
> + int done = 0;
>
> rcu_read_lock();
> if (ram_list.version != last_version) {
> @@ -2007,9 +2007,9 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
> pages = ram_find_and_save_block(f, false, &bytes_transferred);
> /* no more pages to sent */
> if (pages == 0) {
> + done = 1;
> break;
> }
> - pages_sent += pages;
> acct_info.iterations++;
>
> /* we want to check in the 1st loop, just in case it was the 1st time
> @@ -2044,7 +2044,7 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
> return ret;
> }
>
> - return pages_sent;
> + return done;
> }
I agree with David, we can just remove the return value. The first
patch of the series can do that; and this one could become the 2nd
patch. Should be OK for the soft freeze.
Amit
^ permalink raw reply
* Re: linux-next: build warning after merge of the akpm-current tree
From: Huang Shijie @ 2016-11-09 7:18 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, nd
In-Reply-To: <20161109151006.7354dfae@canb.auug.org.au>
On Wed, Nov 09, 2016 at 03:10:06PM +1100, Stephen Rothwell wrote:
Hi Stephen,
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> mm/hugetlb.c:1166:21: warning: 'alloc_gigantic_page' defined but not used [-Wunused-function]
> static struct page *alloc_gigantic_page(int nid, unsigned int order)
The warning should be fixed by the patch (or next version of this patch):
http://marc.info/?l=linux-mm&m=147867535926059&w=2
Thanks
Huang Shijie
^ permalink raw reply
* [PATCHv3] ARM: dts: socfpga: Enable QSPI on the Cyclone5 sockit
From: Steffen Trumtrar @ 2016-11-09 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108022830.29303-1-dinguyen@kernel.org>
On Mon, Nov 07, 2016 at 08:28:30PM -0600, Dinh Nguyen wrote:
> From: Dinh Nguyen <dinguyen@opensource.altera.com>
>
> Enable the QSPI node and add the flash chip.
>
> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
> ---
> v3: Use n25q00 for the compatible entry for the flash part and
> tested on SoCKit
> v2: Remove partition entries for the SoCKIT
> ---
> arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
> index 02e22f5..d59f6f2 100644
> --- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
> +++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
> @@ -175,6 +175,27 @@
> status = "okay";
> };
>
> +&qspi {
> + status = "okay";
> +
> + flash: flash at 0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "n25q00";
> + reg = <0>;
> + spi-max-frequency = <100000000>;
> +
> + m25p,fast-read;
> + cdns,page-size = <256>;
> + cdns,block-size = <16>;
> + cdns,read-delay = <4>;
> + cdns,tshsl-ns = <50>;
> + cdns,tsd2d-ns = <50>;
> + cdns,tchsh-ns = <4>;
> + cdns,tslch-ns = <4>;
> + };
> +};
> +
> &usb1 {
> status = "okay";
> };
Looks good to me.
Thanks,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH for-next 03/11] IB/hns: Optimize the logic of allocating memory using APIs
From: Leon Romanovsky @ 2016-11-09 7:21 UTC (permalink / raw)
To: Salil Mehta
Cc: dledford, xavier.huwei, oulijun, mehta.salil.lnk, linux-rdma,
netdev, linux-kernel, linuxarm, Ping Zhang
In-Reply-To: <20161104163633.141880-4-salil.mehta@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]
On Fri, Nov 04, 2016 at 04:36:25PM +0000, Salil Mehta wrote:
> From: "Wei Hu (Xavier)" <xavier.huwei@huawei.com>
>
> This patch modified the logic of allocating memory using APIs in
> hns RoCE driver. We used kcalloc instead of kmalloc_array and
> bitmap_zero. And When kcalloc failed, call vzalloc to alloc
> memory.
>
> Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
> Signed-off-by: Ping Zhang <zhangping5@huawei.com>
> Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
> ---
> drivers/infiniband/hw/hns/hns_roce_mr.c | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/infiniband/hw/hns/hns_roce_mr.c b/drivers/infiniband/hw/hns/hns_roce_mr.c
> index fb87883..d3dfb5f 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_mr.c
> +++ b/drivers/infiniband/hw/hns/hns_roce_mr.c
> @@ -137,11 +137,12 @@ static int hns_roce_buddy_init(struct hns_roce_buddy *buddy, int max_order)
>
> for (i = 0; i <= buddy->max_order; ++i) {
> s = BITS_TO_LONGS(1 << (buddy->max_order - i));
> - buddy->bits[i] = kmalloc_array(s, sizeof(long), GFP_KERNEL);
> - if (!buddy->bits[i])
> - goto err_out_free;
> -
> - bitmap_zero(buddy->bits[i], 1 << (buddy->max_order - i));
> + buddy->bits[i] = kcalloc(s, sizeof(long), GFP_KERNEL);
> + if (!buddy->bits[i]) {
> + buddy->bits[i] = vzalloc(s * sizeof(long));
I wonder, why don't you use directly vzalloc instead of kcalloc fallback?
> + if (!buddy->bits[i])
> + goto err_out_free;
> + }
> }
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH for-next 09/11] IB/hns: Change qpn allocation to round-robin mode.
From: Leon Romanovsky @ 2016-11-09 7:24 UTC (permalink / raw)
To: Salil Mehta
Cc: dledford, xavier.huwei, oulijun, mehta.salil.lnk, linux-rdma,
netdev, linux-kernel, linuxarm
In-Reply-To: <20161104163633.141880-10-salil.mehta@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 650 bytes --]
On Fri, Nov 04, 2016 at 04:36:31PM +0000, Salil Mehta wrote:
> From: "Wei Hu (Xavier)" <xavier.huwei@huawei.com>
>
> When using CM to establish connections, qp number that was freed
> just now will be rejected by ib core. To fix these problem, We
> change qpn allocation to round-robin mode. We added the round-robin
> mode for allocating resources using bitmap. We use round-robin mode
> for qp number and non round-robing mode for other resources like
> cq number, pd number etc.
>
> Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
> Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] iwlwifi: mvm: rs: Remove unused 'mvmvif'/'mvmsta' variables
From: Luca Coelho @ 2016-11-09 7:25 UTC (permalink / raw)
To: Kirtika Ruchandani
Cc: linux-wireless, Arnd Bergmann, Kalle Valo, Emmanuel Grumbach,
Johannes Berg, Sara Sharon, Liad Kaufman, Eyal Shapira,
Alexander Bondar
In-Reply-To: <20161109055015.GA27416@google.com>
(removed Erarn Harary from the Cc list, since this email is not valid
anymore)
Hi Kirtika,
Just a couple of nitpicks, nothing important, so no need to resend.
On Tue, 2016-11-08 at 21:50 -0800, Kirtika Ruchandani wrote:
> mvmvif is defined and set in rs_mimo_allow but not used. Compiling
> iwlwifi with W=1 gives the following warning, remove it. mvmsta is used only to
> obtain mvmvif so remove it as well.
>
> iwlwifi/mvm/rs.c: In function 'rs_mimo_allow':
> iwlwifi/mvm/rs.c:165:22: warning: variable 'mvmvif' set but not used.[-Wunused-but-set-variable]
>
> This fix removes calls to iwl_mvm_sta_from_mac & iwl_mvm_vif_from_mac. They are
> both accessors, and do not have any side-effects.
> Commit e621c2282 removed a workaround that disabled MIMO on P2P, 'mvmvif' was
> used for that workaround, but not removed with it.
>
> Fixes: e621c2282e31 ("iwlwifi: rs: Remove workaround that disables MIMO on P2P")
>
Usually the Fixes: tag is together with the other tags (such as Cc,
Signed-off-by), i.e. no empty line here.
> Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
> Cc: Alexander Bondar <alexander.bondar@intel.com>
> Cc: Emmanuel Grumbach <emmmanuel.grumbach@intel.com>
And the Signed-off-by tag is usually the last one here, after all Cc's
and stuff. But it doesn't matter much.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH rdma-rc 2/9] IB/mlx4: Check gid_index return value
From: Leon Romanovsky @ 2016-11-09 7:26 UTC (permalink / raw)
To: Yuval Shaia
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Daniel Jurgens
In-Reply-To: <20161106072503.GB3799-Hxa29pjIrETwm8eLU6eYyt+IiqhCXseY@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 219 bytes --]
On Sun, Nov 06, 2016 at 09:25:04AM +0200, Yuval Shaia wrote:
> FWIW
> Reviewed-by: Yuval Shaia <yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Thanks Yuval,
As I wrote earlier, we will address all your comments.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.