* Re: [PATCH 2/2] PCI: NVMe device specific reset quirk
From: Alex Williamson @ 2018-07-23 23:08 UTC (permalink / raw)
To: Keith Busch; +Cc: linux-pci, linux-kernel, linux-nvme
In-Reply-To: <20180723224507.GA11656@localhost.localdomain>
On Mon, 23 Jul 2018 16:45:08 -0600
Keith Busch <keith.busch@intel.com> wrote:
> On Mon, Jul 23, 2018 at 04:24:31PM -0600, Alex Williamson wrote:
> > Take advantage of NVMe devices using a standard interface to quiesce
> > the controller prior to reset, including device specific delays before
> > and after that reset. This resolves several NVMe device assignment
> > scenarios with two different vendors. The Intel DC P3700 controller
> > has been shown to only work as a VM boot device on the initial VM
> > startup, failing after reset or reboot, and also fails to initialize
> > after hot-plug into a VM. Adding a delay after FLR resolves these
> > cases. The Samsung SM961/PM961 (960 EVO) sometimes fails to return
> > from FLR with the PCI config space reading back as -1. A reproducible
> > instance of this behavior is resolved by clearing the enable bit in
> > the configuration register and waiting for the ready status to clear
> > (disabling the NVMe controller) prior to FLR.
> >
> > As all NVMe devices make use of this standard interface and the NVMe
> > specification also requires PCIe FLR support, we can apply this quirk
> > to all devices with matching class code.
>
> Shouldn't this go in the nvme driver's reset_prepare/reset_done callbacks?
The scenario I'm trying to fix is device assignment, the nvme driver
isn't in play there. The device is bound to the vfio-pci driver at the
time of these resets. Thanks,
Alex
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* [PATCH 2/2] PCI: NVMe device specific reset quirk
From: Alex Williamson @ 2018-07-23 23:08 UTC (permalink / raw)
In-Reply-To: <20180723224507.GA11656@localhost.localdomain>
On Mon, 23 Jul 2018 16:45:08 -0600
Keith Busch <keith.busch@intel.com> wrote:
> On Mon, Jul 23, 2018@04:24:31PM -0600, Alex Williamson wrote:
> > Take advantage of NVMe devices using a standard interface to quiesce
> > the controller prior to reset, including device specific delays before
> > and after that reset. This resolves several NVMe device assignment
> > scenarios with two different vendors. The Intel DC P3700 controller
> > has been shown to only work as a VM boot device on the initial VM
> > startup, failing after reset or reboot, and also fails to initialize
> > after hot-plug into a VM. Adding a delay after FLR resolves these
> > cases. The Samsung SM961/PM961 (960 EVO) sometimes fails to return
> > from FLR with the PCI config space reading back as -1. A reproducible
> > instance of this behavior is resolved by clearing the enable bit in
> > the configuration register and waiting for the ready status to clear
> > (disabling the NVMe controller) prior to FLR.
> >
> > As all NVMe devices make use of this standard interface and the NVMe
> > specification also requires PCIe FLR support, we can apply this quirk
> > to all devices with matching class code.
>
> Shouldn't this go in the nvme driver's reset_prepare/reset_done callbacks?
The scenario I'm trying to fix is device assignment, the nvme driver
isn't in play there. The device is bound to the vfio-pci driver at the
time of these resets. Thanks,
Alex
^ permalink raw reply
* Re: cgroup-aware OOM killer, how to move forward
From: David Rientjes @ 2018-07-23 23:06 UTC (permalink / raw)
To: Roman Gushchin; +Cc: Tejun Heo, Michal Hocko, linux-mm, akpm, hannes, gthelen
In-Reply-To: <20180720204746.GA23478@castle.DHCP.thefacebook.com>
On Fri, 20 Jul 2018, Roman Gushchin wrote:
> > > > process chosen for oom kill. I know that you care about the latter. My
> > > > *only* suggestion was for the tunable to take a string instead of a
> > > > boolean so it is extensible for future use. This seems like something so
> > > > trivial.
> > >
> > > So, I'd much prefer it as boolean. It's a fundamentally binary
> > > property, either handle the cgroup as a unit when chosen as oom victim
> > > or not, nothing more.
> >
> > With the single hierarchy mandate of cgroup v2, the need arises to
> > separate processes from a single job into subcontainers for use with
> > controllers other than mem cgroup. In that case, we have no functionality
> > to oom kill all processes in the subtree.
> >
> > A boolean can kill all processes attached to the victim's mem cgroup, but
> > cannot kill all processes in a subtree if the limit of a common ancestor
> > is reached.
>
> Why so?
>
> Once again my proposal:
> as soon as the OOM killer selected a victim task,
> we'll look at the victim task's memory cgroup.
> If memory.oom.group is not set, we're done.
> Otherwise let's traverse the memory cgroup tree up to
> the OOMing cgroup (or root) as long as memory.oom.group is set.
> Kill the last cgroup entirely (including all children).
>
I know this is your proposal, I'm suggesting a context-based extension
based on which mem cgroup is oom: the common ancestor or the leaf.
Consider /A, /A/b, and /A/c, and memory.oom_group is 1 for all of them.
When /A, /A/b, or /A/c is oom, all processes attached to /A and its
subtree are oom killed per your semantic. That occurs when any of the
three mem cgroups are oom.
I'm suggesting that it may become useful to kill an entire subtree when
the common ancestor, /A, is oom, but not when /A/b or /A/c is oom. There
is no way to specify this with the proposal and trees where the limits of
/A/b + /A/c > /A exist. We want all processes killed in /A/b or /A/c if
they reach their individual limits. We want all processes killed in /A's
subtree if /A reaches its limit.
I am not asking for that support to be implemented immediately if you do
not have a need for it. But I am asking that your interface to do so is
extensible so that we may implement it. Given the no internal process
constraint of cgroup v2, defining this as two separate tunables would
always have one be effective and the other be irrelevant, so I suggest it
is overloaded.
^ permalink raw reply
* linux-next: build warning after merge of the arm64 tree
From: Stephen Rothwell @ 2018-07-23 23:05 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
AKASHI Takahiro, Ard Biesheuvel
[-- Attachment #1: Type: text/plain, Size: 531 bytes --]
Hi all,
After merging the arm64 tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/acpi/Kconfig:6:error: recursive dependency detected!
drivers/acpi/Kconfig:6: symbol ACPI depends on EFI
arch/x86/Kconfig:1920: symbol EFI depends on ACPI
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
Introduced by commit
5bcd44083a08 ("drivers: acpi: add dependency of EFI for arm64")
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v6] drm/i915/dp: Limit link training clock recovery loop
From: Rodrigo Vivi @ 2018-07-23 23:05 UTC (permalink / raw)
To: Nathan Ciobanu; +Cc: intel-gfx, Marc Herbert, Dhinakaran Pandiyan
In-Reply-To: <1532117759-20119-1-git-send-email-nathan.d.ciobanu@linux.intel.com>
On Fri, Jul 20, 2018 at 01:15:59PM -0700, Nathan Ciobanu wrote:
> Limit the link training clock recovery loop to 10 attempts at
> LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2 and 80 attempts for
> pre-DP 1.4 (4 voltage levels x 4 preemphasis levels x
> x 5 identical voltages tries). Some faulty USB-C MST hubs can
> cause us to get stuck in this loop indefinitely requesting something
> like:
>
> voltage swing: 0, pre-emphasis level: 2
> voltage swing: 1, pre-emphasis level: 2
> voltage swing: 0, pre-emphasis level: 3
>
> over and over so max_vswing would never be reached,
> drm_dp_clock_recovery_ok() would never return true and voltage_tries
> would always get reset to 1. The driver sends those values to the hub
> but the hub keeps requesting new values every time.
>
> Changes in v2:
> - updated commit message (DK, Manasi)
> - defined DP_DP14_MAX_CR_TRIES (Marc)
> - made the loop iterate for max 10 times (Rodrigo, Marc)
>
> Changes in v3:
> - changed error message to use DP_DP14_MAX_CR_TRIES
>
> Changes in v4:
> - Updated the title to reflect the change
> - Updated the commit message
> - Added 80 attempts for pre-DP 1.4 devices
>
> Changes in v5:
> - Removed DP_DP14_MAX_CR_TRIES from drm
>
> v6: Updated comment to match kernel style (Rodrigo)
series pushed to dinq. Thanks.
>
> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Marc Herbert <marc.herbert@intel.com>
> Cc: Manasi Navare <manasi.d.navare@intel.com>
> Signed-off-by: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com>
> ---
> drivers/gpu/drm/i915/intel_dp_link_training.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 4da6e33c7fa1..299cad5632ed 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -129,7 +129,7 @@ static bool intel_dp_link_max_vswing_reached(struct intel_dp *intel_dp)
> intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> {
> uint8_t voltage;
> - int voltage_tries, max_vswing_tries;
> + int voltage_tries, max_vswing_tries, cr_tries, max_cr_tries;
> uint8_t link_config[2];
> uint8_t link_bw, rate_select;
>
> @@ -170,9 +170,20 @@ static bool intel_dp_link_max_vswing_reached(struct intel_dp *intel_dp)
> return false;
> }
>
> + /*
> + * DP 1.4 spec clock recovery retries defined but
> + * for devices pre-DP 1.4 we set the retry limit
> + * to 4 (voltage levels) x 4 (preemphasis levels) x
> + * x 5 (same voltage retries) = 80 (max iterations)
> + */
> + if (intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
> + max_cr_tries = 10;
> + else
> + max_cr_tries = 80;
> +
> voltage_tries = 1;
> max_vswing_tries = 0;
> - for (;;) {
> + for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
> uint8_t link_status[DP_LINK_STATUS_SIZE];
>
> drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
> @@ -216,6 +227,8 @@ static bool intel_dp_link_max_vswing_reached(struct intel_dp *intel_dp)
> ++max_vswing_tries;
>
> }
> + DRM_ERROR("Failed clock recovery %d times, giving up!\n", max_cr_tries);
> + return false;
> }
>
> /*
> --
> 1.9.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 1/5] mfd: rk808: Add RK817 and RK809 support
From: kbuild test robot @ 2018-07-23 21:59 UTC (permalink / raw)
To: Tony Xie
Cc: kbuild-all, heiko, broonie, lee.jones, a.zummo, alexandre.belloni,
sboyd, linux-clk, linux-rtc, linux-arm-kernel, linux-rockchip,
devicetree, linux-kernel, chenjh, xsf, zhangqing, huangtao,
tony.xie
In-Reply-To: <1532315945-1094-2-git-send-email-tony.xie@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 11770 bytes --]
Hi Tony,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on ljones-mfd/for-mfd-next]
[also build test WARNING on v4.18-rc6 next-20180723]
[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/Tony-Xie/mfd-rk808-Add-RK817-and-RK809-support/20180724-040547
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=xtensa
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers//mfd/rk808.c: In function 'rk808_probe':
>> drivers//mfd/rk808.c:715:16: warning: 'pm_pwroff_fn' may be used uninitialized in this function [-Wmaybe-uninitialized]
pm_power_off = pm_pwroff_fn;
~~~~~~~~~~~~~^~~~~~~~~~~~~~
vim +/pm_pwroff_fn +715 drivers//mfd/rk808.c
2eedcbfc0 Wadim Egorov 2016-08-29 581
f69a7cf74 Chris Zhong 2014-09-03 582 static int rk808_probe(struct i2c_client *client,
f69a7cf74 Chris Zhong 2014-09-03 583 const struct i2c_device_id *id)
f69a7cf74 Chris Zhong 2014-09-03 584 {
f69a7cf74 Chris Zhong 2014-09-03 585 struct device_node *np = client->dev.of_node;
f69a7cf74 Chris Zhong 2014-09-03 586 struct rk808 *rk808;
2eedcbfc0 Wadim Egorov 2016-08-29 587 const struct rk808_reg_data *pre_init_reg;
2eedcbfc0 Wadim Egorov 2016-08-29 588 const struct mfd_cell *cells;
b2e2c8509 Jianhong Chen 2016-10-17 589 void (*pm_pwroff_fn)(void);
2eedcbfc0 Wadim Egorov 2016-08-29 590 int nr_pre_init_regs;
2eedcbfc0 Wadim Egorov 2016-08-29 591 int nr_cells;
9d6105e19 Elaine Zhang 2017-08-21 592 int pm_off = 0, msb, lsb;
1e99c2e53 Tony Xie 2018-07-23 593 unsigned char pmic_id_msb = RK808_ID_MSB, pmic_id_lsb = RK808_ID_LSB;
f69a7cf74 Chris Zhong 2014-09-03 594 int ret;
f69a7cf74 Chris Zhong 2014-09-03 595 int i;
f69a7cf74 Chris Zhong 2014-09-03 596
f69a7cf74 Chris Zhong 2014-09-03 597 rk808 = devm_kzalloc(&client->dev, sizeof(*rk808), GFP_KERNEL);
f69a7cf74 Chris Zhong 2014-09-03 598 if (!rk808)
f69a7cf74 Chris Zhong 2014-09-03 599 return -ENOMEM;
f69a7cf74 Chris Zhong 2014-09-03 600
1e99c2e53 Tony Xie 2018-07-23 601 if (of_device_is_compatible(np, "rockchip,rk817") ||
1e99c2e53 Tony Xie 2018-07-23 602 of_device_is_compatible(np, "rockchip,rk809")) {
1e99c2e53 Tony Xie 2018-07-23 603 pmic_id_msb = RK817_ID_MSB;
1e99c2e53 Tony Xie 2018-07-23 604 pmic_id_lsb = RK817_ID_LSB;
1e99c2e53 Tony Xie 2018-07-23 605 }
9d6105e19 Elaine Zhang 2017-08-21 606 /* Read chip variant */
1e99c2e53 Tony Xie 2018-07-23 607 msb = i2c_smbus_read_byte_data(client, pmic_id_msb);
9d6105e19 Elaine Zhang 2017-08-21 608 if (msb < 0) {
9d6105e19 Elaine Zhang 2017-08-21 609 dev_err(&client->dev, "failed to read the chip id at 0x%x\n",
2eedcbfc0 Wadim Egorov 2016-08-29 610 RK808_ID_MSB);
9d6105e19 Elaine Zhang 2017-08-21 611 return msb;
2eedcbfc0 Wadim Egorov 2016-08-29 612 }
2eedcbfc0 Wadim Egorov 2016-08-29 613
1e99c2e53 Tony Xie 2018-07-23 614 lsb = i2c_smbus_read_byte_data(client, pmic_id_lsb);
9d6105e19 Elaine Zhang 2017-08-21 615 if (lsb < 0) {
9d6105e19 Elaine Zhang 2017-08-21 616 dev_err(&client->dev, "failed to read the chip id at 0x%x\n",
9d6105e19 Elaine Zhang 2017-08-21 617 RK808_ID_LSB);
9d6105e19 Elaine Zhang 2017-08-21 618 return lsb;
9d6105e19 Elaine Zhang 2017-08-21 619 }
9d6105e19 Elaine Zhang 2017-08-21 620
9d6105e19 Elaine Zhang 2017-08-21 621 rk808->variant = ((msb << 8) | lsb) & RK8XX_ID_MSK;
9d6105e19 Elaine Zhang 2017-08-21 622 dev_info(&client->dev, "chip id: 0x%x\n", (unsigned int)rk808->variant);
2eedcbfc0 Wadim Egorov 2016-08-29 623
2eedcbfc0 Wadim Egorov 2016-08-29 624 switch (rk808->variant) {
990f05f6a Elaine Zhang 2017-08-21 625 case RK805_ID:
990f05f6a Elaine Zhang 2017-08-21 626 rk808->regmap_cfg = &rk805_regmap_config;
990f05f6a Elaine Zhang 2017-08-21 627 rk808->regmap_irq_chip = &rk805_irq_chip;
990f05f6a Elaine Zhang 2017-08-21 628 pre_init_reg = rk805_pre_init_reg;
990f05f6a Elaine Zhang 2017-08-21 629 nr_pre_init_regs = ARRAY_SIZE(rk805_pre_init_reg);
990f05f6a Elaine Zhang 2017-08-21 630 cells = rk805s;
990f05f6a Elaine Zhang 2017-08-21 631 nr_cells = ARRAY_SIZE(rk805s);
990f05f6a Elaine Zhang 2017-08-21 632 pm_pwroff_fn = rk805_device_shutdown;
990f05f6a Elaine Zhang 2017-08-21 633 break;
2eedcbfc0 Wadim Egorov 2016-08-29 634 case RK808_ID:
2eedcbfc0 Wadim Egorov 2016-08-29 635 rk808->regmap_cfg = &rk808_regmap_config;
2eedcbfc0 Wadim Egorov 2016-08-29 636 rk808->regmap_irq_chip = &rk808_irq_chip;
2eedcbfc0 Wadim Egorov 2016-08-29 637 pre_init_reg = rk808_pre_init_reg;
2eedcbfc0 Wadim Egorov 2016-08-29 638 nr_pre_init_regs = ARRAY_SIZE(rk808_pre_init_reg);
2eedcbfc0 Wadim Egorov 2016-08-29 639 cells = rk808s;
2eedcbfc0 Wadim Egorov 2016-08-29 640 nr_cells = ARRAY_SIZE(rk808s);
b2e2c8509 Jianhong Chen 2016-10-17 641 pm_pwroff_fn = rk808_device_shutdown;
2eedcbfc0 Wadim Egorov 2016-08-29 642 break;
2eedcbfc0 Wadim Egorov 2016-08-29 643 case RK818_ID:
2eedcbfc0 Wadim Egorov 2016-08-29 644 rk808->regmap_cfg = &rk818_regmap_config;
2eedcbfc0 Wadim Egorov 2016-08-29 645 rk808->regmap_irq_chip = &rk818_irq_chip;
2eedcbfc0 Wadim Egorov 2016-08-29 646 pre_init_reg = rk818_pre_init_reg;
2eedcbfc0 Wadim Egorov 2016-08-29 647 nr_pre_init_regs = ARRAY_SIZE(rk818_pre_init_reg);
2eedcbfc0 Wadim Egorov 2016-08-29 648 cells = rk818s;
2eedcbfc0 Wadim Egorov 2016-08-29 649 nr_cells = ARRAY_SIZE(rk818s);
b2e2c8509 Jianhong Chen 2016-10-17 650 pm_pwroff_fn = rk818_device_shutdown;
2eedcbfc0 Wadim Egorov 2016-08-29 651 break;
1e99c2e53 Tony Xie 2018-07-23 652 case RK809_ID:
1e99c2e53 Tony Xie 2018-07-23 653 case RK817_ID:
1e99c2e53 Tony Xie 2018-07-23 654 rk808->regmap_cfg = &rk817_regmap_config;
1e99c2e53 Tony Xie 2018-07-23 655 rk808->regmap_irq_chip = &rk817_irq_chip;
1e99c2e53 Tony Xie 2018-07-23 656 pre_init_reg = rk817_pre_init_reg;
1e99c2e53 Tony Xie 2018-07-23 657 nr_pre_init_regs = ARRAY_SIZE(rk817_pre_init_reg);
1e99c2e53 Tony Xie 2018-07-23 658 cells = rk817s;
1e99c2e53 Tony Xie 2018-07-23 659 nr_cells = ARRAY_SIZE(rk817s);
1e99c2e53 Tony Xie 2018-07-23 660 pm_power_off_prepare = rk8xx_device_shutdown_prepare;
1e99c2e53 Tony Xie 2018-07-23 661 break;
2eedcbfc0 Wadim Egorov 2016-08-29 662 default:
2eedcbfc0 Wadim Egorov 2016-08-29 663 dev_err(&client->dev, "Unsupported RK8XX ID %lu\n",
2eedcbfc0 Wadim Egorov 2016-08-29 664 rk808->variant);
2eedcbfc0 Wadim Egorov 2016-08-29 665 return -EINVAL;
2eedcbfc0 Wadim Egorov 2016-08-29 666 }
2eedcbfc0 Wadim Egorov 2016-08-29 667
2eedcbfc0 Wadim Egorov 2016-08-29 668 rk808->i2c = client;
2eedcbfc0 Wadim Egorov 2016-08-29 669 i2c_set_clientdata(client, rk808);
2eedcbfc0 Wadim Egorov 2016-08-29 670
2eedcbfc0 Wadim Egorov 2016-08-29 671 rk808->regmap = devm_regmap_init_i2c(client, rk808->regmap_cfg);
f69a7cf74 Chris Zhong 2014-09-03 672 if (IS_ERR(rk808->regmap)) {
f69a7cf74 Chris Zhong 2014-09-03 673 dev_err(&client->dev, "regmap initialization failed\n");
f69a7cf74 Chris Zhong 2014-09-03 674 return PTR_ERR(rk808->regmap);
f69a7cf74 Chris Zhong 2014-09-03 675 }
f69a7cf74 Chris Zhong 2014-09-03 676
2eedcbfc0 Wadim Egorov 2016-08-29 677 if (!client->irq) {
2eedcbfc0 Wadim Egorov 2016-08-29 678 dev_err(&client->dev, "No interrupt support, no core IRQ\n");
2eedcbfc0 Wadim Egorov 2016-08-29 679 return -EINVAL;
f69a7cf74 Chris Zhong 2014-09-03 680 }
f69a7cf74 Chris Zhong 2014-09-03 681
f69a7cf74 Chris Zhong 2014-09-03 682 ret = regmap_add_irq_chip(rk808->regmap, client->irq,
f69a7cf74 Chris Zhong 2014-09-03 683 IRQF_ONESHOT, -1,
2eedcbfc0 Wadim Egorov 2016-08-29 684 rk808->regmap_irq_chip, &rk808->irq_data);
f69a7cf74 Chris Zhong 2014-09-03 685 if (ret) {
f69a7cf74 Chris Zhong 2014-09-03 686 dev_err(&client->dev, "Failed to add irq_chip %d\n", ret);
f69a7cf74 Chris Zhong 2014-09-03 687 return ret;
f69a7cf74 Chris Zhong 2014-09-03 688 }
f69a7cf74 Chris Zhong 2014-09-03 689
2eedcbfc0 Wadim Egorov 2016-08-29 690 for (i = 0; i < nr_pre_init_regs; i++) {
2eedcbfc0 Wadim Egorov 2016-08-29 691 ret = regmap_update_bits(rk808->regmap,
2eedcbfc0 Wadim Egorov 2016-08-29 692 pre_init_reg[i].addr,
2eedcbfc0 Wadim Egorov 2016-08-29 693 pre_init_reg[i].mask,
2eedcbfc0 Wadim Egorov 2016-08-29 694 pre_init_reg[i].value);
2eedcbfc0 Wadim Egorov 2016-08-29 695 if (ret) {
2eedcbfc0 Wadim Egorov 2016-08-29 696 dev_err(&client->dev,
2eedcbfc0 Wadim Egorov 2016-08-29 697 "0x%x write err\n",
2eedcbfc0 Wadim Egorov 2016-08-29 698 pre_init_reg[i].addr);
2eedcbfc0 Wadim Egorov 2016-08-29 699 return ret;
2eedcbfc0 Wadim Egorov 2016-08-29 700 }
2eedcbfc0 Wadim Egorov 2016-08-29 701 }
f69a7cf74 Chris Zhong 2014-09-03 702
2eedcbfc0 Wadim Egorov 2016-08-29 703 ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_NONE,
2eedcbfc0 Wadim Egorov 2016-08-29 704 cells, nr_cells, NULL, 0,
d5623161a Laxman Dewangan 2016-04-08 705 regmap_irq_get_domain(rk808->irq_data));
f69a7cf74 Chris Zhong 2014-09-03 706 if (ret) {
f69a7cf74 Chris Zhong 2014-09-03 707 dev_err(&client->dev, "failed to add MFD devices %d\n", ret);
f69a7cf74 Chris Zhong 2014-09-03 708 goto err_irq;
f69a7cf74 Chris Zhong 2014-09-03 709 }
f69a7cf74 Chris Zhong 2014-09-03 710
f69a7cf74 Chris Zhong 2014-09-03 711 pm_off = of_property_read_bool(np,
f69a7cf74 Chris Zhong 2014-09-03 712 "rockchip,system-power-controller");
f69a7cf74 Chris Zhong 2014-09-03 713 if (pm_off && !pm_power_off) {
f69a7cf74 Chris Zhong 2014-09-03 714 rk808_i2c_client = client;
b2e2c8509 Jianhong Chen 2016-10-17 @715 pm_power_off = pm_pwroff_fn;
f69a7cf74 Chris Zhong 2014-09-03 716 }
f69a7cf74 Chris Zhong 2014-09-03 717
f69a7cf74 Chris Zhong 2014-09-03 718 return 0;
f69a7cf74 Chris Zhong 2014-09-03 719
f69a7cf74 Chris Zhong 2014-09-03 720 err_irq:
f69a7cf74 Chris Zhong 2014-09-03 721 regmap_del_irq_chip(client->irq, rk808->irq_data);
f69a7cf74 Chris Zhong 2014-09-03 722 return ret;
f69a7cf74 Chris Zhong 2014-09-03 723 }
f69a7cf74 Chris Zhong 2014-09-03 724
:::::: The code at line 715 was first introduced by commit
:::::: b2e2c85091710159b305735d557f4ef4695f5dff mfd: rk808: RK818 uses DEV_OFF to power off supplies
:::::: TO: Jianhong Chen <chenjh@rock-chips.com>
:::::: CC: Lee Jones <lee.jones@linaro.org>
---
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: 54212 bytes --]
^ permalink raw reply
* Re: [**EXTERNAL**] Re: VRF with enslaved L3 enabled bridge
From: David Ahern @ 2018-07-23 22:00 UTC (permalink / raw)
To: D'Souza, Nelson, netdev@vger.kernel.org
In-Reply-To: <F8810C2E-7791-43B8-AB64-6FC843431FEA@ciena.com>
On 7/20/18 1:03 PM, D'Souza, Nelson wrote:
> Setup is as follows:
>
> ethUSB(ingress port) -> mgmtbr0 (bridge) -> mgmtvrf (vrf)
| netns foo
[ test-vrf ] |
| |
[ br0 ] 172.16.1.1 |
| |
[ veth1 ] ============|======= [ veth2 ] lo
| 172.16.1.2 172.16.2.2
|
Copy and paste the following into your environment:
ip netns add foo
ip li add veth1 type veth peer name veth2
ip li set veth2 netns foo
ip -netns foo li set lo up
ip -netns foo li set veth2 up
ip -netns foo addr add 172.16.1.2/24 dev veth2
ip li add test-vrf type vrf table 123
ip li set test-vrf up
ip ro add vrf test-vrf unreachable default
ip li add br0 type bridge
ip li set veth1 master br0
ip li set veth1 up
ip li set br0 up
ip addr add dev br0 172.16.1.1/24
ip li set br0 master test-vrf
ip -netns foo addr add 172.16.2.2/32 dev lo
ip ro add vrf test-vrf 172.16.2.2/32 via 172.16.1.2
Does ping work?
# ping -I test-vrf 172.16.2.2
ping: Warning: source address might be selected on device other than
test-vrf.
PING 172.16.2.2 (172.16.2.2) from 172.16.1.1 test-vrf: 56(84) bytes of data.
64 bytes from 172.16.2.2: icmp_seq=1 ttl=64 time=0.228 ms
64 bytes from 172.16.2.2: icmp_seq=2 ttl=64 time=0.263 ms
and:
# ping -I br0 172.16.2.2
PING 172.16.2.2 (172.16.2.2) from 172.16.1.1 br0: 56(84) bytes of data.
64 bytes from 172.16.2.2: icmp_seq=1 ttl=64 time=0.227 ms
64 bytes from 172.16.2.2: icmp_seq=2 ttl=64 time=0.223 ms
^C
--- 172.16.2.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.223/0.225/0.227/0.002 ms
^ permalink raw reply
* Re: [PATCH] tpm: add support for partial reads
From: Tadeusz Struk @ 2018-07-23 22:00 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: James Bottomley, Jarkko Sakkinen, linux-integrity,
linux-security-module, linux-kernel
In-Reply-To: <20180723215620.GH532@ziepe.ca>
On 07/23/2018 02:56 PM, Jason Gunthorpe wrote:
> The proposed patch doesn't clear the data_pending if the entire buffer
> is not consumed, so of course it is ABI breaking, that really isn't OK.
The data_pending will be cleared by the timeout handler if the user doesn't
read the response fully before the timeout expires. The is the same situation
if the user would not read the response at all.
Thanks,
--
Tadeusz
^ permalink raw reply
* Re: [PATCH] firmware/shim : filter output files during Xen tree setup
From: Christopher Clark @ 2018-07-23 23:00 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, Wei Liu, Ian Jackson, Roger Pau Monné
In-Reply-To: <398ca3b0-6d16-0434-449d-c9bae7b0c4ea@citrix.com>
[-- Attachment #1.1: Type: text/plain, Size: 2256 bytes --]
On Mon, Jul 23, 2018 at 2:26 AM, Andrew Cooper <andrew.cooper3@citrix.com>
wrote:
> On 23/07/18 10:09, Roger Pau Monné wrote:
> > On Fri, Jul 20, 2018 at 02:15:05PM -0700, Christopher Clark wrote:
> >> Exclude named output files from the Xen tree setup.
> >>
> >> The linkfarm.stamp content will differ between top level "make"
> >> and "make install" invocations, due to the introduction of these
> >> output files that are produced during the "make" build.
> >>
> >> Filter these out to prevent an unnecessary rebuild of the shim during
> >> "make install".
> >>
> >> Signed-off-by: Christopher Clark <christopher.clark6@baesystems.com>
> >> ---
> >> tools/firmware/xen-dir/Makefile | 6 +++++-
> >> 1 file changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/tools/firmware/xen-dir/Makefile b/tools/firmware/xen-dir/
> Makefile
> >> index 84648c3..e490dca 100644
> >> --- a/tools/firmware/xen-dir/Makefile
> >> +++ b/tools/firmware/xen-dir/Makefile
> >> @@ -11,6 +11,9 @@ D=xen-root
> >> LINK_DIRS=config xen
> >> LINK_FILES=Config.mk
> >>
> >> +# Files to exclude from the link farm
> >> +EXCLUDE_FILES=xen xen.gz xen-syms xen-syms.map efi.lds xen.lds mkelf32
> mkreloc
> > I don't really like to list the files here, since it's very easy for
> > them to get out of sync. The alternative I have is also not very nice
> > however, since it relies on .gitignore:
> >
> > EXCLUDE_FILES:=$(patsubst xen/%,%,$(filter xen/%,$(shell cat
> $(XEN_ROOT)/.gitignore)))
>
> The correct way to fix this is to rip the current build system to
> shreds, start again, and get it to support out-of-tree builds.
>
> This linkfarm logic exists only to work around a hole which we couldn't
> fix at the time.
>
As Andrew observes, the linkfarm code is a temporary solution until Xen
supports out of tree builds.
The proposed patch is localized and easy to understand.
If the list of files is not maintained, it will break in obvious ways
(either an unnecessary shim rebuild, or a non-rebuild when it should but
only in a developer environment) and it will serve as a reminder to fix
support for out of tree builds.
So, I'd like to request inclusion of the original patch proposed.
Christopher
[-- Attachment #1.2: Type: text/html, Size: 3416 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH] fetch-pack: mark die strings for translation
From: Brandon Williams @ 2018-07-23 23:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqlga136es.fsf@gitster-ct.c.googlers.com>
On 07/23, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Brandon Williams <bmwill@google.com> writes:
> >
> >> Signed-off-by: Brandon Williams <bmwill@google.com>
> >> ---
> >> fetch-pack.c | 16 ++++++++--------
> >> 1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > I do think this is a good idea, but what release does this target?
> > It does not seem to apply to master@{4.hours.ago}, and I do not
> > think a change as trivial like this wants to be taken of a hostage
> > of _all_ topics that are in 'next'.
> >
>
> Answering myself, this would come on top of (and would become part
> of) bw/ref-in-want topic, I would think. And I am perfectly OK for
> this change to be hostage of that topic ;-)
haha yes sorry for not mention it, but yes I built it on top of
bw/ref-in-want because it was in response to this topic :)
--
Brandon Williams
^ permalink raw reply
* Re: [PATCH 07/14] range-diff: respect diff_option.file rather than assuming 'stdout'
From: Stefan Beller @ 2018-07-23 22:59 UTC (permalink / raw)
To: Eric Sunshine
Cc: git, Johannes Schindelin, Duy Nguyen,
Ævar Arnfjörð Bjarmason
In-Reply-To: <20180722095717.17912-8-sunshine@sunshineco.com>
On Sun, Jul 22, 2018 at 2:58 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
>
> The actual diffs output by range-diff respect diff_option.file, which
> range-diff passes down the call-chain, thus are destination-agnostic.
> However, output_pair_header() is hard-coded to emit to 'stdout'. Fix
> this by making output_pair_header() respect diff_option.file, as well.
>
> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Depending how much the range diff series has progressed
already, it might make sense to squash it there?
Thanks,
Stefan
> ---
> range-diff.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/range-diff.c b/range-diff.c
> index 347b4a79f2..76e053c2b2 100644
> --- a/range-diff.c
> +++ b/range-diff.c
> @@ -328,7 +328,7 @@ static void output_pair_header(struct diff_options *diffopt,
> }
> strbuf_addf(buf, "%s\n", color_reset);
>
> - fwrite(buf->buf, buf->len, 1, stdout);
> + fwrite(buf->buf, buf->len, 1, diffopt->file);
> }
>
> static struct userdiff_driver no_func_name = {
> --
> 2.18.0.345.g5c9ce644c3
>
^ permalink raw reply
* Re: [PATCH] tpm: add support for partial reads
From: Jason Gunthorpe @ 2018-07-23 21:56 UTC (permalink / raw)
To: Tadeusz Struk
Cc: James Bottomley, Jarkko Sakkinen, linux-integrity,
linux-security-module, linux-kernel
In-Reply-To: <7441b5ef-18d8-13aa-ef4d-40fe684c9218@intel.com>
On Mon, Jul 23, 2018 at 02:38:08PM -0700, Tadeusz Struk wrote:
> On 07/23/2018 02:13 PM, James Bottomley wrote:
> > The current patch does, you even provided a use case in your last email
> > (it's do command to get sizing followed by do command with correctly
> > sized buffer).
>
> The example I provided was: #1 send a command, #2 read the response header
> (10 bytes), get the actual response size from the header and then #3 read
> the full response (response size - size of the header bytes).
The proposed patch doesn't clear the data_pending if the entire buffer
is not consumed, so of course it is ABI breaking, that really isn't OK.
> > However, if you tie it to O_NONBLOCK, it won't because no-one currently
> > opens the TPM device non blocking so it's an ABI conformant
> > discriminator of the uses. Tying to O_NONBLOCK should be simple
> > because it's in file->f_flags.
>
> I think that it might be an option. Especially that I have this on top of
> the async patch. Let's discuss this when Jarkko is back.
Maybe you could do this by requiring the userspace to call pread()
with a non-zero offset to get the trailing segment of the last
executed command and leave normal read/pread(off=0) with the semantics
as they have today.
Jason
^ permalink raw reply
* Re: [PATCH] fetch-pack: mark die strings for translation
From: Junio C Hamano @ 2018-07-23 22:59 UTC (permalink / raw)
To: Brandon Williams; +Cc: git
In-Reply-To: <xmqqpnzd36hy.fsf@gitster-ct.c.googlers.com>
Junio C Hamano <gitster@pobox.com> writes:
> Brandon Williams <bmwill@google.com> writes:
>
>> Signed-off-by: Brandon Williams <bmwill@google.com>
>> ---
>> fetch-pack.c | 16 ++++++++--------
>> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> I do think this is a good idea, but what release does this target?
> It does not seem to apply to master@{4.hours.ago}, and I do not
> think a change as trivial like this wants to be taken of a hostage
> of _all_ topics that are in 'next'.
>
Answering myself, this would come on top of (and would become part
of) bw/ref-in-want topic, I would think. And I am perfectly OK for
this change to be hostage of that topic ;-)
^ permalink raw reply
* Re: [PATCH] fetch-pack: mark die strings for translation
From: Junio C Hamano @ 2018-07-23 22:57 UTC (permalink / raw)
To: Brandon Williams; +Cc: git
In-Reply-To: <20180723175635.31323-1-bmwill@google.com>
Brandon Williams <bmwill@google.com> writes:
> Signed-off-by: Brandon Williams <bmwill@google.com>
> ---
> fetch-pack.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
I do think this is a good idea, but what release does this target?
It does not seem to apply to master@{4.hours.ago}, and I do not
think a change as trivial like this wants to be taken of a hostage
of _all_ topics that are in 'next'.
> diff --git a/fetch-pack.c b/fetch-pack.c
> index 0b4a9f288f..51abee6181 100644
> --- a/fetch-pack.c
> +++ b/fetch-pack.c
> @@ -1245,13 +1245,13 @@ static int process_section_header(struct packet_reader *reader,
> int ret;
>
> if (packet_reader_peek(reader) != PACKET_READ_NORMAL)
> - die("error reading section header '%s'", section);
> + die(_("error reading section header '%s'"), section);
>
> ret = !strcmp(reader->line, section);
>
> if (!peek) {
> if (!ret)
> - die("expected '%s', received '%s'",
> + die(_("expected '%s', received '%s'"),
> section, reader->line);
> packet_reader_read(reader);
> }
> @@ -1289,12 +1289,12 @@ static int process_acks(struct packet_reader *reader, struct oidset *common)
> continue;
> }
>
> - die("unexpected acknowledgment line: '%s'", reader->line);
> + die(_("unexpected acknowledgment line: '%s'"), reader->line);
> }
>
> if (reader->status != PACKET_READ_FLUSH &&
> reader->status != PACKET_READ_DELIM)
> - die("error processing acks: %d", reader->status);
> + die(_("error processing acks: %d"), reader->status);
>
> /* return 0 if no common, 1 if there are common, or 2 if ready */
> return received_ready ? 2 : (received_ack ? 1 : 0);
> @@ -1331,7 +1331,7 @@ static void receive_shallow_info(struct fetch_pack_args *args,
>
> if (reader->status != PACKET_READ_FLUSH &&
> reader->status != PACKET_READ_DELIM)
> - die("error processing shallow info: %d", reader->status);
> + die(_("error processing shallow info: %d"), reader->status);
>
> setup_alternate_shallow(&shallow_lock, &alternate_shallow_file, NULL);
> args->deepen = 1;
> @@ -1346,7 +1346,7 @@ static void receive_wanted_refs(struct packet_reader *reader, struct ref *refs)
> struct ref *r = NULL;
>
> if (parse_oid_hex(reader->line, &oid, &end) || *end++ != ' ')
> - die("expected wanted-ref, got '%s'", reader->line);
> + die(_("expected wanted-ref, got '%s'"), reader->line);
>
> for (r = refs; r; r = r->next) {
> if (!strcmp(end, r->name)) {
> @@ -1356,11 +1356,11 @@ static void receive_wanted_refs(struct packet_reader *reader, struct ref *refs)
> }
>
> if (!r)
> - die("unexpected wanted-ref: '%s'", reader->line);
> + die(_("unexpected wanted-ref: '%s'"), reader->line);
> }
>
> if (reader->status != PACKET_READ_DELIM)
> - die("error processing wanted refs: %d", reader->status);
> + die(_("error processing wanted refs: %d"), reader->status);
> }
>
> enum fetch_state {
^ permalink raw reply
* [merged] mm-memcg-fix-use-after-free-in-mem_cgroup_iter.patch removed from -mm tree
From: akpm @ 2018-07-23 21:52 UTC (permalink / raw)
To: chunyan.zhang, hannes, jing.xia.mail, mhocko, mm-commits,
shakeelb, stable, vdavydov.dev
The patch titled
Subject: mm: memcg: fix use after free in mem_cgroup_iter()
has been removed from the -mm tree. Its filename was
mm-memcg-fix-use-after-free-in-mem_cgroup_iter.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Jing Xia <jing.xia.mail@gmail.com>
Subject: mm: memcg: fix use after free in mem_cgroup_iter()
It was reported that a kernel crash happened in mem_cgroup_iter(), which
can be triggered if the legacy cgroup-v1 non-hierarchical mode is used.
Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b8f
......
Call trace:
mem_cgroup_iter+0x2e0/0x6d4
shrink_zone+0x8c/0x324
balance_pgdat+0x450/0x640
kswapd+0x130/0x4b8
kthread+0xe8/0xfc
ret_from_fork+0x10/0x20
mem_cgroup_iter():
......
if (css_tryget(css)) <-- crash here
break;
......
The crashing reason is that mem_cgroup_iter() uses the memcg object whose
pointer is stored in iter->position, which has been freed before and
filled with POISON_FREE(0x6b).
And the root cause of the use-after-free issue is that
invalidate_reclaim_iterators() fails to reset the value of iter->position
to NULL when the css of the memcg is released in non- hierarchical mode.
Link: http://lkml.kernel.org/r/1531994807-25639-1-git-send-email-jing.xia@unisoc.com
Fixes: 6df38689e0e9 ("mm: memcontrol: fix possible memcg leak due to interrupted reclaim")
Signed-off-by: Jing Xia <jing.xia.mail@gmail.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: <chunyan.zhang@unisoc.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/memcontrol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/memcontrol.c~mm-memcg-fix-use-after-free-in-mem_cgroup_iter mm/memcontrol.c
--- a/mm/memcontrol.c~mm-memcg-fix-use-after-free-in-mem_cgroup_iter
+++ a/mm/memcontrol.c
@@ -850,7 +850,7 @@ static void invalidate_reclaim_iterators
int nid;
int i;
- while ((memcg = parent_mem_cgroup(memcg))) {
+ for (; memcg; memcg = parent_mem_cgroup(memcg)) {
for_each_node(nid) {
mz = mem_cgroup_nodeinfo(memcg, nid);
for (i = 0; i <= DEF_PRIORITY; i++) {
_
Patches currently in -mm which might be from jing.xia.mail@gmail.com are
^ permalink raw reply
* Re: [PATCH] media: staging: omap4iss: Include asm/cacheflush.h after generic includes
From: David Miller @ 2018-07-23 21:52 UTC (permalink / raw)
To: linux
Cc: laurent.pinchart, mchehab, gregkh, linux-media, devel,
linux-kernel, torvalds, rdunlap
In-Reply-To: <1532381973-11856-1-git-send-email-linux@roeck-us.net>
From: Guenter Roeck <linux@roeck-us.net>
Date: Mon, 23 Jul 2018 14:39:33 -0700
> Including asm/cacheflush.h first results in the following build error when
> trying to build sparc32:allmodconfig.
...
> Include generic includes files first to fix the problem.
>
> Fixes: fc96d58c10162 ("[media] v4l: omap4iss: Add support for OMAP4 camera interface - Video devices")
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: David Miller <davem@davemloft.net>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [merged] thp-fix-data-loss-when-splitting-a-file-pmd.patch removed from -mm tree
From: akpm @ 2018-07-23 21:52 UTC (permalink / raw)
To: ashwinch, hughd, kirill.shutemov, mm-commits, stable, yang.shi,
ying.huang
The patch titled
Subject: mm/huge_memory.c: fix data loss when splitting a file pmd
has been removed from the -mm tree. Its filename was
thp-fix-data-loss-when-splitting-a-file-pmd.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Hugh Dickins <hughd@google.com>
Subject: mm/huge_memory.c: fix data loss when splitting a file pmd
__split_huge_pmd_locked() must check if the cleared huge pmd was dirty,
and propagate that to PageDirty: otherwise, data may be lost when a huge
tmpfs page is modified then split then reclaimed.
How has this taken so long to be noticed? Because there was no problem
when the huge page is written by a write system call (shmem_write_end()
calls set_page_dirty()), nor when the page is allocated for a write fault
(fault_dirty_shared_page() calls set_page_dirty()); but when allocated for
a read fault (which MAP_POPULATE simulates), no set_page_dirty().
Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1807111741430.1106@eggly.anvils
Fixes: d21b9e57c74c ("thp: handle file pages in split_huge_pmd()")
Signed-off-by: Hugh Dickins <hughd@google.com>
Reported-by: Ashwin Chaugule <ashwinch@google.com>
Reviewed-by: Yang Shi <yang.shi@linux.alibaba.com>
Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: "Huang, Ying" <ying.huang@intel.com>
Cc: <stable@vger.kernel.org> [4.8+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/huge_memory.c | 2 ++
1 file changed, 2 insertions(+)
diff -puN mm/huge_memory.c~thp-fix-data-loss-when-splitting-a-file-pmd mm/huge_memory.c
--- a/mm/huge_memory.c~thp-fix-data-loss-when-splitting-a-file-pmd
+++ a/mm/huge_memory.c
@@ -2084,6 +2084,8 @@ static void __split_huge_pmd_locked(stru
if (vma_is_dax(vma))
return;
page = pmd_page(_pmd);
+ if (!PageDirty(page) && pmd_dirty(_pmd))
+ set_page_dirty(page);
if (!PageReferenced(page) && pmd_young(_pmd))
SetPageReferenced(page);
page_remove_rmap(page, true);
_
Patches currently in -mm which might be from hughd@google.com are
^ permalink raw reply
* [merged] fat-fix-memory-allocation-failure-handling-of-match_strdup.patch removed from -mm tree
From: akpm @ 2018-07-23 21:52 UTC (permalink / raw)
To: hirofumi, mm-commits, stable
The patch titled
Subject: fat: fix memory allocation failure handling of match_strdup()
has been removed from the -mm tree. Its filename was
fat-fix-memory-allocation-failure-handling-of-match_strdup.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Subject: fat: fix memory allocation failure handling of match_strdup()
In parse_options(), if match_strdup() failed, parse_options() leaves
opts->iocharset in unexpected state (i.e. still pointing the freed
string). And this can be the cause of double free.
To fix, this initialize opts->iocharset always when freeing.
Link: http://lkml.kernel.org/r/8736wp9dzc.fsf@mail.parknet.co.jp
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Reported-by: syzbot+90b8e10515ae88228a92@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/fat/inode.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff -puN fs/fat/inode.c~fat-fix-memory-allocation-failure-handling-of-match_strdup fs/fat/inode.c
--- a/fs/fat/inode.c~fat-fix-memory-allocation-failure-handling-of-match_strdup
+++ a/fs/fat/inode.c
@@ -707,13 +707,21 @@ static void fat_set_state(struct super_b
brelse(bh);
}
+static void fat_reset_iocharset(struct fat_mount_options *opts)
+{
+ if (opts->iocharset != fat_default_iocharset) {
+ /* Note: opts->iocharset can be NULL here */
+ kfree(opts->iocharset);
+ opts->iocharset = fat_default_iocharset;
+ }
+}
+
static void delayed_free(struct rcu_head *p)
{
struct msdos_sb_info *sbi = container_of(p, struct msdos_sb_info, rcu);
unload_nls(sbi->nls_disk);
unload_nls(sbi->nls_io);
- if (sbi->options.iocharset != fat_default_iocharset)
- kfree(sbi->options.iocharset);
+ fat_reset_iocharset(&sbi->options);
kfree(sbi);
}
@@ -1132,7 +1140,7 @@ static int parse_options(struct super_bl
opts->fs_fmask = opts->fs_dmask = current_umask();
opts->allow_utime = -1;
opts->codepage = fat_default_codepage;
- opts->iocharset = fat_default_iocharset;
+ fat_reset_iocharset(opts);
if (is_vfat) {
opts->shortname = VFAT_SFN_DISPLAY_WINNT|VFAT_SFN_CREATE_WIN95;
opts->rodir = 0;
@@ -1289,8 +1297,7 @@ static int parse_options(struct super_bl
/* vfat specific */
case Opt_charset:
- if (opts->iocharset != fat_default_iocharset)
- kfree(opts->iocharset);
+ fat_reset_iocharset(opts);
iocharset = match_strdup(&args[0]);
if (!iocharset)
return -ENOMEM;
@@ -1881,8 +1888,7 @@ out_fail:
iput(fat_inode);
unload_nls(sbi->nls_io);
unload_nls(sbi->nls_disk);
- if (sbi->options.iocharset != fat_default_iocharset)
- kfree(sbi->options.iocharset);
+ fat_reset_iocharset(&sbi->options);
sb->s_fs_info = NULL;
kfree(sbi);
return error;
_
Patches currently in -mm which might be from hirofumi@mail.parknet.co.jp are
fat-validate-i_start-before-using.patch
^ permalink raw reply
* [PATCH] hinic: Link the logical network device to the pci device in sysfs
From: dann frazier @ 2018-07-23 22:55 UTC (permalink / raw)
To: Aviad Krawczyk, David S. Miller; +Cc: Zhao Chen, netdev, linux-kernel
Otherwise interfaces get exposed under /sys/devices/virtual, which
doesn't give udev the context it needs for PCI-based predictable
interface names.
Signed-off-by: dann frazier <dann.frazier@canonical.com>
---
drivers/net/ethernet/huawei/hinic/hinic_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_main.c b/drivers/net/ethernet/huawei/hinic/hinic_main.c
index 5b122728dcb47..09e9da10b7865 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_main.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_main.c
@@ -983,6 +983,7 @@ static int nic_dev_init(struct pci_dev *pdev)
hinic_hwdev_cb_register(nic_dev->hwdev, HINIC_MGMT_MSG_CMD_LINK_STATUS,
nic_dev, link_status_event_handler);
+ SET_NETDEV_DEV(netdev, &pdev->dev);
err = register_netdev(netdev);
if (err) {
dev_err(&pdev->dev, "Failed to register netdev\n");
--
2.18.0
^ permalink raw reply related
* Re: kernel BUG at mm/shmem.c:LINE!
From: Matthew Wilcox @ 2018-07-23 22:54 UTC (permalink / raw)
To: Hugh Dickins
Cc: syzbot, Kirill A. Shutemov, Andrew Morton, linux-kernel, linux-mm,
syzkaller-bugs
In-Reply-To: <alpine.LSU.2.11.1807231531240.2545@eggly.anvils>
On Mon, Jul 23, 2018 at 03:42:22PM -0700, Hugh Dickins wrote:
> On Mon, 23 Jul 2018, Matthew Wilcox wrote:
> > I figured out a fix and pushed it to the 'ida' branch in
> > git://git.infradead.org/users/willy/linux-dax.git
>
> Great, thanks a lot for sorting that out so quickly. But I've cloned
> the tree and don't see today's patch, so assume you've folded the fix
> into an existing commit? If possible, please append the diff of today's
> fix to this thread so that we can try it out. Or if that's difficult,
> please at least tell which files were modified, then I can probably
> work it out from the diff of those files against mmotm.
Sure! It's just this:
diff --git a/lib/xarray.c b/lib/xarray.c
index 32a9c2a6a9e9..383c410997eb 100644
--- a/lib/xarray.c
+++ b/lib/xarray.c
@@ -660,6 +660,8 @@ void xas_create_range(struct xa_state *xas)
unsigned char sibs = xas->xa_sibs;
xas->xa_index |= ((sibs + 1) << shift) - 1;
+ if (!xas_top(xas->xa_node) && xas->xa_node->shift == xas->xa_shift)
+ xas->xa_offset |= sibs;
xas->xa_shift = 0;
xas->xa_sibs = 0;
The only other things changed are the test suite, and removing an
unnecessary change, so they can be ignored:
diff --git a/lib/test_xarray.c b/lib/test_xarray.c
index 8a67d4bb1788..ec06c3ca19e9 100644
--- a/lib/test_xarray.c
+++ b/lib/test_xarray.c
@@ -695,19 +695,20 @@ static noinline void check_move(struct xarray *xa)
check_move_small(xa, (1UL << i) - 1);
}
-static noinline void check_create_range_1(struct xarray *xa,
+static noinline void xa_store_many_order(struct xarray *xa,
unsigned long index, unsigned order)
{
XA_STATE_ORDER(xas, xa, index, order);
- unsigned int i;
+ unsigned int i = 0;
do {
xas_lock(&xas);
+ XA_BUG_ON(xa, xas_find_conflict(&xas));
xas_create_range(&xas);
if (xas_error(&xas))
goto unlock;
for (i = 0; i < (1U << order); i++) {
- xas_store(&xas, xa + i);
+ XA_BUG_ON(xa, xas_store(&xas, xa_mk_value(index + i)));
xas_next(&xas);
}
unlock:
@@ -715,7 +716,29 @@ static noinline void check_create_range_1(struct xarray *xa,
} while (xas_nomem(&xas, GFP_KERNEL));
XA_BUG_ON(xa, xas_error(&xas));
- xa_destroy(xa);
+}
+
+static noinline void check_create_range_1(struct xarray *xa,
+ unsigned long index, unsigned order)
+{
+ unsigned long i;
+
+ xa_store_many_order(xa, index, order);
+ for (i = index; i < index + (1UL << order); i++)
+ xa_erase_value(xa, i);
+ XA_BUG_ON(xa, !xa_empty(xa));
+}
+
+static noinline void check_create_range_2(struct xarray *xa, unsigned order)
+{
+ unsigned long i;
+ unsigned long nr = 1UL << order;
+
+ for (i = 0; i < nr * nr; i += nr)
+ xa_store_many_order(xa, i, order);
+ for (i = 0; i < nr * nr; i++)
+ xa_erase_value(xa, i);
+ XA_BUG_ON(xa, !xa_empty(xa));
}
static noinline void check_create_range(struct xarray *xa)
@@ -729,6 +752,8 @@ static noinline void check_create_range(struct xarray *xa)
check_create_range_1(xa, 2U << order, order);
check_create_range_1(xa, 3U << order, order);
check_create_range_1(xa, 1U << 24, order);
+ if (order < 10)
+ check_create_range_2(xa, order);
}
}
diff --git a/mm/shmem.c b/mm/shmem.c
index af2d7fa05af7..3ac507803787 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -589,8 +589,8 @@ static int shmem_add_to_page_cache(struct page *page,
VM_BUG_ON(expected && PageTransHuge(page));
page_ref_add(page, nr);
- page->index = index;
page->mapping = mapping;
+ page->index = index;
do {
void *entry;
^ permalink raw reply related
* Re: [PATCH] net/9p/trans_fd.c: fix race by holding the lock
From: Dominique Martinet @ 2018-07-23 22:54 UTC (permalink / raw)
To: Tomas Bortoli
Cc: ericvh, rminnich, lucho, davem, v9fs-developer, netdev,
linux-kernel, syzkaller
In-Reply-To: <20180723184253.6682-1-tomasbortoli@gmail.com>
Tomas Bortoli wrote on Mon, Jul 23, 2018:
> It may be possible to run p9_fd_cancel() with a deleted req->req_list
> and incur in a double del. To fix hold the client->lock while changing
> the status, so the other threads will be synchronized.
>
> Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
> Reported-by: syzbot+735d926e9d1317c3310c@syzkaller.appspotmail.com
OK, taking this one.
> ---
> net/9p/trans_fd.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
> index 588bf88c3305..f9f96d50d96d 100644
> --- a/net/9p/trans_fd.c
> +++ b/net/9p/trans_fd.c
> @@ -197,15 +197,14 @@ static void p9_mux_poll_stop(struct p9_conn *m)
> static void p9_conn_cancel(struct p9_conn *m, int err)
> {
> struct p9_req_t *req, *rtmp;
> - unsigned long flags;
> LIST_HEAD(cancel_list);
>
> p9_debug(P9_DEBUG_ERROR, "mux %p err %d\n", m, err);
>
> - spin_lock_irqsave(&m->client->lock, flags);
> + spin_lock(&m->client->lock);
>
> if (m->err) {
> - spin_unlock_irqrestore(&m->client->lock, flags);
> + spin_unlock(&m->client->lock);
> return;
> }
>
> @@ -217,7 +216,6 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
> list_for_each_entry_safe(req, rtmp, &m->unsent_req_list, req_list) {
> list_move(&req->req_list, &cancel_list);
> }
> - spin_unlock_irqrestore(&m->client->lock, flags);
>
> list_for_each_entry_safe(req, rtmp, &cancel_list, req_list) {
> p9_debug(P9_DEBUG_ERROR, "call back req %p\n", req);
> @@ -226,6 +224,7 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
> req->t_err = err;
> p9_client_cb(m->client, req, REQ_STATUS_ERROR);
> }
> + spin_unlock(&m->client->lock);
> }
>
> static __poll_t
> @@ -373,8 +372,9 @@ static void p9_read_work(struct work_struct *work)
> if (m->req->status != REQ_STATUS_ERROR)
> status = REQ_STATUS_RCVD;
> list_del(&m->req->req_list);
> - spin_unlock(&m->client->lock);
> + /* update req->status while holding client->lock */
> p9_client_cb(m->client, m->req, status);
> + spin_unlock(&m->client->lock);
> m->rc.sdata = NULL;
> m->rc.offset = 0;
> m->rc.capacity = 0;
^ permalink raw reply
* [PATCH v7 12/12] Add maintainers for the PECI subsystem
From: Jae Hyun Yoo @ 2018-07-23 21:47 UTC (permalink / raw)
To: Jean Delvare, Guenter Roeck, Rob Herring, Mark Rutland, Lee Jones,
Joel Stanley, Andrew Jeffery, Jonathan Corbet, Greg Kroah-Hartman,
Gustavo Pimentel, Kishon Vijay Abraham I, Lorenzo Pieralisi,
Darrick J . Wong, Eric Sandeen, Arnd Bergmann, Wu Hao,
Tomohiro Kusumi, Bryant G . Ly, Frederic Barrat, David S . Miller,
Mauro Carvalho Chehab, Andrew Morton, Randy Dunlap,
Philippe Ombredanne, Vinod Koul, Stephen Boyd, David Kershner,
Uwe Kleine-Konig, Sagar Dharia, Johan Hovold, Thomas Gleixner,
Juergen Gross, Cyrille Pitchen
Cc: linux-hwmon, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-doc, openbmc, Jae Hyun Yoo, Linus Walleij,
Jason M Biils
In-Reply-To: <20180723214751.1733-1-jae.hyun.yoo@linux.intel.com>
This commit adds maintainer information for the PECI subsystem.
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
Reviewed-by: James Feist <james.feist@linux.intel.com>
Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Jason M Biils <jason.m.bills@linux.intel.com>
---
MAINTAINERS | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7afb9ad5a85c..28a87cb77723 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1266,6 +1266,14 @@ F: arch/arm/mach-aspeed/
F: arch/arm/boot/dts/aspeed-*
N: aspeed
+ARM/ASPEED PECI DRIVER
+M: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
+M: Jason M Biils <jason.m.bills@linux.intel.com>
+L: linux-aspeed@lists.ozlabs.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/peci/peci-aspeed.txt
+F: drivers/peci/peci-aspeed.c
+
ARM/CALXEDA HIGHBANK ARCHITECTURE
M: Rob Herring <robh@kernel.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
@@ -11254,6 +11262,19 @@ L: platform-driver-x86@vger.kernel.org
S: Maintained
F: drivers/platform/x86/peaq-wmi.c
+PECI SUBSYSTEM
+M: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
+M: Jason M Biils <jason.m.bills@linux.intel.com>
+L: openbmc@lists.ozlabs.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/peci/
+F: drivers/mfd/intel-peci-client.c
+F: drivers/peci/
+F: drivers/hwmon/peci-*.c
+F: include/linux/mfd/intel-peci-client.h
+F: include/linux/peci.h
+F: include/uapi/linux/peci-ioctl.h
+
PER-CPU MEMORY ALLOCATOR
M: Tejun Heo <tj@kernel.org>
M: Christoph Lameter <cl@linux.com>
--
2.18.0
^ permalink raw reply related
* [PATCH v7 09/12] Documentation: hwmon: Add documents for PECI hwmon client drivers
From: Jae Hyun Yoo @ 2018-07-23 21:47 UTC (permalink / raw)
To: Jean Delvare, Guenter Roeck, Rob Herring, Mark Rutland, Lee Jones,
Joel Stanley, Andrew Jeffery, Jonathan Corbet, Greg Kroah-Hartman,
Gustavo Pimentel, Kishon Vijay Abraham I, Lorenzo Pieralisi,
Darrick J . Wong, Eric Sandeen, Arnd Bergmann, Wu Hao,
Tomohiro Kusumi, Bryant G . Ly, Frederic Barrat, David S . Miller,
Mauro Carvalho Chehab, Andrew Morton, Randy Dunlap,
Philippe Ombredanne, Vinod Koul, Stephen Boyd, David Kershner,
Uwe Kleine-Konig, Sagar Dharia, Johan Hovold, Thomas Gleixner,
Juergen Gross, Cyrille Pitchen
Cc: linux-hwmon, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-doc, openbmc, Jae Hyun Yoo, Jason M Biils
In-Reply-To: <20180723214751.1733-1-jae.hyun.yoo@linux.intel.com>
This commit adds hwmon documents for PECI cputemp and dimmtemp drivers.
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
Reviewed-by: James Feist <james.feist@linux.intel.com>
Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Jason M Biils <jason.m.bills@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
---
Documentation/hwmon/peci-cputemp | 78 +++++++++++++++++++++++++++++++
Documentation/hwmon/peci-dimmtemp | 50 ++++++++++++++++++++
2 files changed, 128 insertions(+)
create mode 100644 Documentation/hwmon/peci-cputemp
create mode 100644 Documentation/hwmon/peci-dimmtemp
diff --git a/Documentation/hwmon/peci-cputemp b/Documentation/hwmon/peci-cputemp
new file mode 100644
index 000000000000..821a9258f2e6
--- /dev/null
+++ b/Documentation/hwmon/peci-cputemp
@@ -0,0 +1,78 @@
+Kernel driver peci-cputemp
+==========================
+
+Supported chips:
+ One of Intel server CPUs listed below which is connected to a PECI bus.
+ * Intel Xeon E5/E7 v3 server processors
+ Intel Xeon E5-14xx v3 family
+ Intel Xeon E5-24xx v3 family
+ Intel Xeon E5-16xx v3 family
+ Intel Xeon E5-26xx v3 family
+ Intel Xeon E5-46xx v3 family
+ Intel Xeon E7-48xx v3 family
+ Intel Xeon E7-88xx v3 family
+ * Intel Xeon E5/E7 v4 server processors
+ Intel Xeon E5-16xx v4 family
+ Intel Xeon E5-26xx v4 family
+ Intel Xeon E5-46xx v4 family
+ Intel Xeon E7-48xx v4 family
+ Intel Xeon E7-88xx v4 family
+ * Intel Xeon Scalable server processors
+ Intel Xeon Bronze family
+ Intel Xeon Silver family
+ Intel Xeon Gold family
+ Intel Xeon Platinum family
+ Addresses scanned: PECI client address 0x30 - 0x37
+ Datasheet: Available from http://www.intel.com/design/literature.htm
+
+Author:
+ Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
+
+Description
+-----------
+
+This driver implements a generic PECI hwmon feature which provides Digital
+Thermal Sensor (DTS) thermal readings of the CPU package and CPU cores that are
+accessible using the PECI Client Command Suite via the processor PECI client.
+
+All temperature values are given in millidegree Celsius and will be measurable
+only when the target CPU is powered on.
+
+sysfs attributes
+----------------
+
+temp1_label "Die"
+temp1_input Provides current die temperature of the CPU package.
+temp1_max Provides thermal control temperature of the CPU package
+ which is also known as Tcontrol.
+temp1_crit Provides shutdown temperature of the CPU package which
+ is also known as the maximum processor junction
+ temperature, Tjmax or Tprochot.
+temp1_crit_hyst Provides the hysteresis value from Tcontrol to Tjmax of
+ the CPU package.
+
+temp2_label "Tcontrol"
+temp2_input Provides current Tcontrol temperature of the CPU
+ package which is also known as Fan Temperature target.
+ Indicates the relative value from thermal monitor trip
+ temperature at which fans should be engaged.
+temp2_crit Provides Tcontrol critical value of the CPU package
+ which is same to Tjmax.
+
+temp3_label "Tthrottle"
+temp3_input Provides current Tthrottle temperature of the CPU
+ package. Used for throttling temperature. If this value
+ is allowed and lower than Tjmax - the throttle will
+ occur and reported at lower than Tjmax.
+
+temp4_label "Tjmax"
+temp4_input Provides the maximum junction temperature, Tjmax of the
+ CPU package.
+
+temp[5-*]_label Provides string "Core X", where X is resolved core
+ number.
+temp[5-*]_input Provides current temperature of each core.
+temp[5-*]_max Provides thermal control temperature of the core.
+temp[5-*]_crit Provides shutdown temperature of the core.
+temp[5-*]_crit_hyst Provides the hysteresis value from Tcontrol to Tjmax of
+ the core.
diff --git a/Documentation/hwmon/peci-dimmtemp b/Documentation/hwmon/peci-dimmtemp
new file mode 100644
index 000000000000..c54f2526188c
--- /dev/null
+++ b/Documentation/hwmon/peci-dimmtemp
@@ -0,0 +1,50 @@
+Kernel driver peci-dimmtemp
+===========================
+
+Supported chips:
+ One of Intel server CPUs listed below which is connected to a PECI bus.
+ * Intel Xeon E5/E7 v3 server processors
+ Intel Xeon E5-14xx v3 family
+ Intel Xeon E5-24xx v3 family
+ Intel Xeon E5-16xx v3 family
+ Intel Xeon E5-26xx v3 family
+ Intel Xeon E5-46xx v3 family
+ Intel Xeon E7-48xx v3 family
+ Intel Xeon E7-88xx v3 family
+ * Intel Xeon E5/E7 v4 server processors
+ Intel Xeon E5-16xx v4 family
+ Intel Xeon E5-26xx v4 family
+ Intel Xeon E5-46xx v4 family
+ Intel Xeon E7-48xx v4 family
+ Intel Xeon E7-88xx v4 family
+ * Intel Xeon Scalable server processors
+ Intel Xeon Bronze family
+ Intel Xeon Silver family
+ Intel Xeon Gold family
+ Intel Xeon Platinum family
+ Addresses scanned: PECI client address 0x30 - 0x37
+ Datasheet: Available from http://www.intel.com/design/literature.htm
+
+Author:
+ Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
+
+Description
+-----------
+
+This driver implements a generic PECI hwmon feature which provides Digital
+Thermal Sensor (DTS) thermal readings of DIMM components that are accessible
+using the PECI Client Command Suite via the processor PECI client.
+
+All temperature values are given in millidegree Celsius and will be measurable
+only when the target CPU is powered on.
+
+sysfs attributes
+----------------
+
+temp[N]_label Provides string "DIMM CI", where C is DIMM channel and
+ I is DIMM index of the populated DIMM.
+temp[N]_input Provides current temperature of the populated DIMM.
+
+Note:
+ DIMM temperature attributes will appear when the client CPU's BIOS
+ completes memory training and testing.
--
2.18.0
^ permalink raw reply related
* Re: [PATCH] tpm: add support for partial reads
From: Jason Gunthorpe @ 2018-07-23 21:48 UTC (permalink / raw)
To: Tadeusz Struk
Cc: jarkko.sakkinen, linux-integrity, linux-security-module,
linux-kernel
In-Reply-To: <153201555276.20155.1352499992826895966.stgit@tstruk-mobl1.jf.intel.com>
On Thu, Jul 19, 2018 at 08:52:32AM -0700, Tadeusz Struk wrote:
> Currently to read a response from the TPM device an application needs
> provide "big enough" buffer for the whole response and read it in one go.
> The application doesn't know how big the response it beforehand so it
> always needs to maintain a 4K buffer and read the max (4K).
> In case if the user of the TSS library doesn't provide big enough buffer
> the TCTI spec says that the library should set the required size and return
> TSS2_TCTI_RC_INSUFFICIENT_BUFFER error code so that the application could
> allocate a bigger buffer and call receive again.
> To make it possible in the TSS library this requires being able to do
> partial reads from the driver.
> The library would read the header first to get the actual size of the
> response from the header and then read the rest of the response.
> This patch adds support for partial reads.
You should solve this in user space, the kernel API requires a full
sized buffer here, the tss library should always provide such an
internal buffer and then implement whatever scheme TSS wants by
memcpying from that buffer..
Jason
^ permalink raw reply
* [PATCH v7 02/12] Documentation: ioctl: Add ioctl numbers for PECI subsystem
From: Jae Hyun Yoo @ 2018-07-23 21:47 UTC (permalink / raw)
To: Jean Delvare, Guenter Roeck, Rob Herring, Mark Rutland, Lee Jones,
Joel Stanley, Andrew Jeffery, Jonathan Corbet, Greg Kroah-Hartman,
Gustavo Pimentel, Kishon Vijay Abraham I, Lorenzo Pieralisi,
Darrick J . Wong, Eric Sandeen, Arnd Bergmann, Wu Hao,
Tomohiro Kusumi, Bryant G . Ly, Frederic Barrat, David S . Miller,
Mauro Carvalho Chehab, Andrew Morton, Randy Dunlap,
Philippe Ombredanne, Vinod Koul, Stephen Boyd, David Kershner,
Uwe Kleine-Konig, Sagar Dharia, Johan Hovold, Thomas Gleixner,
Juergen Gross, Cyrille Pitchen
Cc: linux-hwmon, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-doc, openbmc, Jae Hyun Yoo, James Feist,
Jason M Biils, Vernon Mauery
In-Reply-To: <20180723214751.1733-1-jae.hyun.yoo@linux.intel.com>
This commit updates ioctl-number.txt to reflect ioctl numbers used
by the PECI subsystem.
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Cc: Darrick J. Wong <darrick.wong@oracle.com>
Cc: Tomohiro Kusumi <kusumi.tomohiro@gmail.com>
Cc: Eric Sandeen <sandeen@redhat.com>
Cc: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Cc: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: James Feist <james.feist@linux.intel.com>
Cc: Jason M Biils <jason.m.bills@linux.intel.com>
Cc: Vernon Mauery <vernon.mauery@linux.intel.com>
---
Documentation/ioctl/ioctl-number.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index 7a471381a0c8..9e47d223f15c 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -324,6 +324,8 @@ Code Seq#(hex) Include File Comments
0xB4 00-0F linux/gpio.h <mailto:linux-gpio@vger.kernel.org>
0xB5 00-0F uapi/linux/rpmsg.h <mailto:linux-remoteproc@vger.kernel.org>
0xB6 all linux/fpga-dfl.h
+0xB7 00-0F uapi/linux/peci-ioctl.h PECI subsystem
+ <mailto:jae.hyun.yoo@linux.intel.com>
0xC0 00-0F linux/usb/iowarrior.h
0xCA 00-0F uapi/misc/cxl.h
0xCA 10-2F uapi/misc/ocxl.h
--
2.18.0
^ permalink raw reply related
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.