Re: [PATCH 3/3] mmc: tmio: support IP-builtin card detection logic
2017-11-20 4:45 GMT+09:00 Wolfram Sang : > On Wed, Nov 08, 2017 at 07:17:00PM +0900, Masahiro Yamada wrote: >> A card detect GPIO is set up only for platforms with "cd-gpios" >> DT property or TMIO_MMC_USE_GPIO_CD flag. However, the driver >> core always uses mmc_gpio_get_cd, which just fails with -ENOSYS >> if ctx->cd_gpio is unset. >> >> The bit 5 of the status register provides the current signal level >> of the CD line. Allow to use it if the GPIO is unused. > > I might be missing something: Why do we need to report something > sensible in this case? The card insert/eject interrupts calling > mmc_detect_change is not enough? > Not enough. mmc_detect_change() just schedules mmc_rescan(). Without correct ->get_cd(), how can mmc_rescan() know whether a card is inserted or not? -- Best Regards Masahiro Yamada
No check of the size passed to unmap_single in swiotlb
Hi all,
During debug a device only support 32bits DMA(Qualcomm Atheros AP) in our
LS1043A 64bits ARM SOC, we found that the invoke of dma_unmap_single -->
swiotlb_tbl_unmap_single will unmap the passed "size" anyway even when the
"size" is incorrect.
If the size is larger than it should, the extra entries in io_tlb_orig_addr
array will be refilled by INVALID_PHYS_ADDR, and it will cause the bounce
buffer copy not happen when the one who really used the mis-freed entries doing
DMA data transfers, and this will cause further unknow behaviors.
Here we just fix it temporarily by adding a judge of the "size" in the
swiotlb_tbl_unmap_single, if it is larger than it deserves, just unmap the
right size only. Like the code:
[yangyu@titan dash-lts]$ git diff ./lib/swiotlb.c
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index ad1d2962d129..58c97ede9d78 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -591,7 +591,10 @@ void swiotlb_tbl_unmap_single(struct device *hwdev,
phys_addr_t tlb_addr,
*/
for (i = index + nslots - 1; i >= index; i--) {
io_tlb_list[i] = ++count;
- io_tlb_orig_addr[i] = INVALID_PHYS_ADDR;
+ if(io_tlb_orig_addr[i] != orig_addr)
+ printk("==size wrong, ally down ally
down!===\n");
+ else
+ io_tlb_orig_addr[i] = INVALID_PHYS_ADDR;
}
/*
* Step 2: merge the returned slots with the preceding slots,
Although pass a right size of DMA buffer is the responsibility of the drivers,
but Is it useful to add some size check code to prevent real damage happen?
Regards,
Eric
Re: [PATCH 2/6] mmc: tmio: set tmio_mmc_host to driver data
2017-11-20 4:49 GMT+09:00 Wolfram Sang :
> On Tue, Nov 07, 2017 at 05:09:28PM +0900, Masahiro Yamada wrote:
>> The remove, suspend, resume hooks need tmio_mmc_host. It is tedious
>> to get mmc_host from the driver_data and pass it to mmc_priv().
>> We can directly set tmio_mmc_host to driver data to clean up the code.
>>
>> Signed-off-by: Masahiro Yamada
>
> ...
>
>> diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
>> index 64b7e9f..ccfbc15 100644
>> --- a/drivers/mmc/host/tmio_mmc.c
>> +++ b/drivers/mmc/host/tmio_mmc.c
>> @@ -128,15 +128,11 @@ static int tmio_mmc_probe(struct platform_device *pdev)
>> static int tmio_mmc_remove(struct platform_device *pdev)
>> {
>> const struct mfd_cell *cell = mfd_get_cell(pdev);
>> - struct mmc_host *mmc = platform_get_drvdata(pdev);
>> + struct tmio_mmc_host *host = platform_get_drvdata(pdev);
>>
>> - if (mmc) {
>> - struct tmio_mmc_host *host = mmc_priv(mmc);
>> -
>> - tmio_mmc_host_remove(host);
>> - if (cell->disable)
>> - cell->disable(pdev);
>> - }
>> + tmio_mmc_host_remove(host);
>> + if (cell->disable)
>> + cell->disable(pdev);
>
> Hmmm, this changes the code logic. Any reason this driver checks for a
> valid 'mmc' and can we safely drop it?
>
This code has been here since the initial support of TMIO
by commit 4a48998fa16121d0fe3436cce43afd6f47424103.
So, we have no way to know the reason
except asking the author, Ian Molton.
My best guess is unnecessary if-conditional was added
and overlooked in the review process.
mmc has been allocated, and platform_set_drvdata() has been called
in the driver probe.
I do not see any case for mmc==NULL.
--
Best Regards
Masahiro Yamada
Re: [PATCH] mm: fix nodemask printing
On Fri 17-11-17 11:15:45, Arnd Bergmann wrote:
> The cleanup caused build warnings for constant mask pointers:
>
> mm/mempolicy.c: In function ‘mpol_to_str’:
> ./include/linux/nodemask.h:108:11: warning: the comparison will always
> evaluate as ‘true’ for the address of ‘nodes’ will never be NULL [-Waddress]
>
> An earlier workaround I suggested was incorporated in the version that
> got merged, but that only solved the problem for gcc-7 and higher, while
> gcc-4.6 through gcc-6.x still warn.
>
> This changes the printing again to use inline functions that make it
> clear to the compiler that the line that does the NULL check has no
> idea whether the argument is a constant NULL.
>
> Fixes: 0205f75571e3 ("mm: simplify nodemask printing")
> Signed-off-by: Arnd Bergmann
Thanks for the fixup. It is sad how a questionable warning makes the
code worse... Does it make sense to have the warning enabled?
Gcc bug [1] suggests there is no great interest into fixing it.
Anyway to the patch
Acked-by: Michal Hocko
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82963
> ---
> I've done only minimal build testing on this, but did check it with
> all compiler versions this time.
> ---
> include/linux/nodemask.h | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/nodemask.h b/include/linux/nodemask.h
> index 15cab3967d6d..1fbde8a880d9 100644
> --- a/include/linux/nodemask.h
> +++ b/include/linux/nodemask.h
> @@ -104,9 +104,16 @@ extern nodemask_t _unused_nodemask_arg_;
> *
> * Can be used to provide arguments for '%*pb[l]' when printing a nodemask.
> */
> -#define nodemask_pr_args(maskp) \
> - ((maskp) != NULL) ? MAX_NUMNODES : 0, \
> - ((maskp) != NULL) ? (maskp)->bits : NULL
> +#define nodemask_pr_args(maskp) __nodemask_pr_numnodes(maskp), \
> + __nodemask_pr_bits(maskp)
> +static inline unsigned int __nodemask_pr_numnodes(const nodemask_t *m)
> +{
> + return m ? MAX_NUMNODES : 0;
> +}
> +static inline const unsigned long *__nodemask_pr_bits(const nodemask_t *m)
> +{
> + return m ? m->bits : NULL;
> +}
>
> /*
> * The inline keyword gives the compiler room to decide to inline, or
> --
> 2.9.0
--
Michal Hocko
SUSE Labs
Re: [PATCH] ACPI / battery: add quirk for Asus GL502VSK and UX305LA
> On 12 Oct 2017, at 1:16 PM, Kai-Heng Feng wrote:
>
> On Fri, Sep 22, 2017 at 4:27 PM, Kai-Heng Feng
> wrote:
>> On Asus GL502VSK and UX305LA, ACPI incorrectly reports discharging when
>> battery is full and AC is plugged.
>>
>> However rate_now is correct under this circumstance, hence we can use
>> "rate_now == 0" as a predicate to report battery full status correctly.
>>
>> BugLink: https://bugs.launchpad.net/bugs/1482390
>> Signed-off-by: Kai-Heng Feng
>> ---
>> drivers/acpi/battery.c | 29 -
>> 1 file changed, 28 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
>> index 13e7b56e33ae..f9f008cf3da7 100644
>> --- a/drivers/acpi/battery.c
>> +++ b/drivers/acpi/battery.c
>> @@ -70,6 +70,7 @@ static async_cookie_t async_cookie;
>> static bool battery_driver_registered;
>> static int battery_bix_broken_package;
>> static int battery_notification_delay_ms;
>> +static int battery_full_discharging;
>> static unsigned int cache_time = 1000;
>> module_param(cache_time, uint, 0644);
>> MODULE_PARM_DESC(cache_time, "cache time in milliseconds");
>> @@ -214,7 +215,10 @@ static int acpi_battery_get_property(struct
>> power_supply *psy,
>>return -ENODEV;
>>switch (psp) {
>>case POWER_SUPPLY_PROP_STATUS:
>> - if (battery->state & ACPI_BATTERY_STATE_DISCHARGING)
>> + if (battery_full_discharging && battery->rate_now == 0 &&
>> + battery->state & ACPI_BATTERY_STATE_DISCHARGING)
>> + val->intval = POWER_SUPPLY_STATUS_FULL;
>> + else if (battery->state & ACPI_BATTERY_STATE_DISCHARGING)
>>val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
>>else if (battery->state & ACPI_BATTERY_STATE_CHARGING)
>>val->intval = POWER_SUPPLY_STATUS_CHARGING;
>> @@ -1166,6 +1170,13 @@ battery_notification_delay_quirk(const struct
>> dmi_system_id *d)
>>return 0;
>> }
>>
>> +static int __init
>> +battery_full_discharging_quirk(const struct dmi_system_id *d)
>> +{
>> + battery_full_discharging = 1;
>> + return 0;
>> +}
>> +
>> static const struct dmi_system_id bat_dmi_table[] __initconst = {
>>{
>>.callback = battery_bix_broken_package_quirk,
>> @@ -1183,6 +1194,22 @@ static const struct dmi_system_id bat_dmi_table[]
>> __initconst = {
>>DMI_MATCH(DMI_PRODUCT_NAME, "Aspire V5-573G"),
>>},
>>},
>> + {
>> + .callback = battery_full_discharging_quirk,
>> + .ident = "ASUS GL502VSK",
>> + .matches = {
>> + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
>> + DMI_MATCH(DMI_PRODUCT_NAME, "GL502VSK"),
>> + },
>> + },
>> + {
>> + .callback = battery_full_discharging_quirk,
>> + .ident = "ASUS UX305LA",
>> + .matches = {
>> + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
>> + DMI_MATCH(DMI_PRODUCT_NAME, "UX305LA"),
>> + },
>> + },
>>{},
>> };
>>
>
> Hi,
>
> Is there any improvement I can make for this patch?
Another gentle ping…
>
>> --
>> 2.14.1
Re: [PATCH v2 0/4] Quirks cleanup and hid-generic niceness
On Thu, 16 Nov 2017, Benjamin Tissoires wrote: > > I am planning to queue this for 4.16; do you happen to have any followups > > since you posted v2 in october? > > Cool. I did not updated it since, but if you want I can send a v3 > tomorrow based on your for-next branch. Would be perfect; the sooner it gets into my tree the better, so that we could start basing other topic branches on it. That'd avoid a lot of merge conflicts later. Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH] Support TrackStick of Thinkpad L570
On Monday 20 November 2017 16:55:30 Masaki Ota wrote:
> From: Masaki Ota
> - The issue is that Thinkpad L570 TrackStick does not work. Because the main
> interface of Thinkpad L570 device is SMBus, so ALPS overlooked PS2 interface
> Firmware setting of TrackStick. The detail is that TrackStick otp bit is
> disabled.
> - Add the code that checks 0xD7 address value. This value is device number
> information, so we can identify the device by checking this value.
> - If we check 0xD7 value, we need to enable Command mode and after check the
> value we need to disable Command mode, then we have to enable the device(0xF4
> command).
> - Thinkpad L570 device number is 0x0C or 0x1D. If it is TRUE, enable
> ALPS_DUALPOINT flag.
So, the root of this problem is in ALPS firmware which provides wrong
information to kernel?
Masaki, I have two questions:
1) Can ALPS or Lenovo release a new firmware update for this Thinkpad to
fix this issue?
2) Have all Thinkpad L570 machines trackpoint?
Dmitry, as a workaround for firmware bug on particular notebook, would
not be better to check DMI information and DMI based hook?
> Signed-off-by: Masaki Ota
> ---
> drivers/input/mouse/alps.c | 21 ++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
> index 850b00e3ad8e..cce52104ed5a 100644
> --- a/drivers/input/mouse/alps.c
> +++ b/drivers/input/mouse/alps.c
> @@ -2541,13 +2541,28 @@ static int alps_update_btn_info_ss4_v2(unsigned char
> otp[][4],
> }
>
> static int alps_update_dual_info_ss4_v2(unsigned char otp[][4],
> -struct alps_data *priv)
> +struct alps_data *priv,
> + struct psmouse *psmouse)
> {
> bool is_dual = false;
> + int reg_val = 0;
> + struct ps2dev *ps2dev = &psmouse->ps2dev;
>
> - if (IS_SS4PLUS_DEV(priv->dev_id))
> + if (IS_SS4PLUS_DEV(priv->dev_id)) {
> is_dual = (otp[0][0] >> 4) & 0x01;
>
> + /* For support TrackStick of Thinkpad L570 device */
> + if (alps_exit_command_mode(psmouse) == 0 &&
> + alps_enter_command_mode(psmouse) == 0) {
> + reg_val = alps_command_mode_read_reg(psmouse, 0xD7);
> + }
> + alps_exit_command_mode(psmouse);
> + ps2_command(ps2dev, NULL, PSMOUSE_CMD_ENABLE);
> +
> + if (reg_val == 0x0C || reg_val == 0x1D)
> + is_dual = true;
> + }
> +
> if (is_dual)
> priv->flags |= ALPS_DUALPOINT |
> ALPS_DUALPOINT_WITH_PRESSURE;
> @@ -2570,7 +2585,7 @@ static int alps_set_defaults_ss4_v2(struct psmouse
> *psmouse,
>
> alps_update_btn_info_ss4_v2(otp, priv);
>
> - alps_update_dual_info_ss4_v2(otp, priv);
> + alps_update_dual_info_ss4_v2(otp, priv, psmouse);
>
> return 0;
> }
--
Pali Rohár
pali.ro...@gmail.com
Re: [PATCH V10 1/4] dma-mapping: Rework dma_get_cache_alignment()
Please send the scsi fixes on their own for now so that the rework can go into 4.16. If you don't want to do it I'll do it myself and will send them to Martin for now you can the rebase the dma-mapping and mips work after that.
[PATCH v2 0/3] net: ethernet: fec: fix refclk enable for SMSC LAN8710/20
From: Richard Leitner
This patch series fixes the use of the SMSC LAN8710/20 with a Freescale ETH
when the refclk is generated by the FSL.
Changes v2:
- simplify and fix fec_reset_phy function to support multiple calls
- include: linux: phy: harmonize phy_id{,_mask} type
- reset the phy instead of not turning the clock on and off
(which would have caused a power consumption regression)
Richard Leitner (3):
net: ethernet: freescale: simplify fec_reset_phy
include: linux: phy: harmonize phy_id{,_mask} type
net: ethernet: fec: fix refclk enable for SMSC LAN8710/20
drivers/net/ethernet/freescale/fec.h | 4 +
drivers/net/ethernet/freescale/fec_main.c | 125 --
include/linux/phy.h | 2 +-
3 files changed, 88 insertions(+), 43 deletions(-)
--
2.11.0
Re: [RFC v2] prctl: prctl(PR_SET_IDLE, PR_IDLE_MODE_KILLME), for stateless idle loops
On Fri 17-11-17 20:45:03, Shawn Landden wrote: > On Fri, Nov 3, 2017 at 2:09 AM, Michal Hocko wrote: > > > On Thu 02-11-17 23:35:44, Shawn Landden wrote: > > > It is common for services to be stateless around their main event loop. > > > If a process sets PR_SET_IDLE to PR_IDLE_MODE_KILLME then it > > > signals to the kernel that epoll_wait() and friends may not complete, > > > and the kernel may send SIGKILL if resources get tight. > > > > > > See my systemd patch: https://github.com/shawnl/systemd/tree/prctl > > > > > > Android uses this memory model for all programs, and having it in the > > > kernel will enable integration with the page cache (not in this > > > series). > > > > > > 16 bytes per process is kinda spendy, but I want to keep > > > lru behavior, which mem_score_adj does not allow. When a supervisor, > > > like Android's user input is keeping track this can be done in > > user-space. > > > It could be pulled out of task_struct if an cross-indexing additional > > > red-black tree is added to support pid-based lookup. > > > > This is still an abuse and the patch is wrong. We really do have an API > > to use I fail to see why you do not use it. > > > When I looked at wait_queue_head_t it was 20 byes. I do not understand. What I meant to say is that we do have a proper user api to hint OOM killer decisions. -- Michal Hocko SUSE Labs
[PATCH v2 2/3] include: linux: phy: harmonize phy_id{,_mask} type
From: Richard Leitner
Previously phy_id was u32 and phy_id_mask was unsigned int. As the
phy_id_mask defines the important bits of the phy_id (and is therefore the
same size) these two variables should be the same datatype.
Signed-off-by: Richard Leitner
---
include/linux/phy.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index dc82a07cb4fd..e00fd9ce3bce 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -509,7 +509,7 @@ struct phy_driver {
struct mdio_driver_common mdiodrv;
u32 phy_id;
char *name;
- unsigned int phy_id_mask;
+ u32 phy_id_mask;
u32 features;
u32 flags;
const void *driver_data;
--
2.11.0
[PATCH v2 3/3] net: ethernet: fec: fix refclk enable for SMSC LAN8710/20
From: Richard Leitner
Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow turning
the refclk on and off again during operation (according to their
datasheet). Nonetheless exactly this behaviour was introduced for power
saving reasons by commit e8fcfcd5684a ("net: fec: optimize the clock management
to save power").
Therefore after enabling the refclk we detect if an affected PHY is
attached. If so reset and initialize it again.
For a better understanding here's a outline of the time response of the
clock and reset lines before and after this patch:
v--fec_probe() v--fec_enet_open()
v v
w/o patch eCLK: ___|
w/o patch nRST: __--
w/o patch CONF: ___XX___
w/ patch eCLK: ___|
w/ patch nRST: __-__---
w/ patch CONF: ___XX_XX
^ ^
^--fec_probe() ^--fec_enet_open()
Generally speaking this issue is only relevant if the ref clk for the
PHY is generated by the SoC. In our specific case (PCB) this problem
does occur at about every 10th to 50th POR of an LAN8710 connected to an
i.MX6DL SoC. The typical symptom of this problem is a "swinging"
ethernet link. Similar issues were reported by users of the NXP forum:
https://community.nxp.com/thread/389902
https://community.nxp.com/message/309354
With this patch applied the issue didn't occur for at least a few
hundret PORs of our board.
Fixes: e8fcfcd5684a ("net: fec: optimize the clock management to save power")
Signed-off-by: Richard Leitner
---
drivers/net/ethernet/freescale/fec_main.c | 37 +++
1 file changed, 37 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fec_main.c
b/drivers/net/ethernet/freescale/fec_main.c
index 06a7caca0cee..52ec9b29a70e 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -68,6 +68,7 @@
static void set_multicast_list(struct net_device *ndev);
static void fec_enet_itr_coal_init(struct net_device *ndev);
+static int fec_reset_phy(struct net_device *ndev);
#define DRIVER_NAME"fec"
@@ -1833,6 +1834,32 @@ static int fec_enet_mdio_write(struct mii_bus *bus, int
mii_id, int regnum,
return ret;
}
+static int fec_enet_clk_ref_enable_reset_phy_quirk(struct net_device *ndev)
+{
+ struct phy_device *phy_dev = ndev->phydev;
+ u32 real_phy_id;
+ int ret;
+
+ /* some PHYs need a reset after the refclk was enabled, so we
+* reset them here
+*/
+ if (!phy_dev)
+ return 0;
+ if (!phy_dev->drv)
+ return 0;
+ real_phy_id = phy_dev->drv->phy_id & phy_dev->drv->phy_id_mask;
+ switch (real_phy_id) {
+ case 0x0007c0f0: /* SMSC LAN8710/LAN8720 */
+ ret = fec_reset_phy(ndev);
+ if (ret)
+ return ret;
+ ret = phy_init_hw(phy_dev);
+ if (ret)
+ return ret;
+ }
+ return 0;
+}
+
static int fec_enet_clk_enable(struct net_device *ndev, bool enable)
{
struct fec_enet_private *fep = netdev_priv(ndev);
@@ -1862,6 +1889,10 @@ static int fec_enet_clk_enable(struct net_device *ndev,
bool enable)
ret = clk_prepare_enable(fep->clk_ref);
if (ret)
goto failed_clk_ref;
+
+ ret = fec_enet_clk_ref_enable_reset_phy_quirk(ndev);
+ if (ret)
+ netdev_warn(ndev, "Resetting PHY failed, connection may
be unstable\n");
} else {
clk_disable_unprepare(fep->clk_ahb);
clk_disable_unprepare(fep->clk_enet_out);
@@ -2860,11 +2891,17 @@ fec_enet_open(struct net_device *ndev)
if (ret)
goto err_enet_mii_probe;
+ /* as the PHY is connected now, trigger the reset quirk again */
+ ret = fec_enet_clk_ref_enable_reset_phy_quirk(ndev);
+ if (ret)
+ netdev_warn(ndev, "Resetting PHY failed, connection may be
unstable\n");
+
if (fep->quirks & FEC_QUIRK_ERR006687)
imx6q_cpuidle_fec_irqs_used();
napi_enable(&fep->napi);
phy_start(ndev->phydev);
+
netif_tx_start_all_queues(ndev);
device_set_wakeup_enable(&ndev->dev, fep->wol_flag &
--
2.11.0
[PATCH v2 1/3] net: ethernet: freescale: simplify fec_reset_phy
From: Richard Leitner
The fec_reset_phy function allowed only one execution during probeing.
To make it more usable move the dt parsing and gpio allocation to the
probe function. The parameters of the phy reset are added to the
fec_enet_private struct. As a result the fec_reset_phy function may be
called anytime after probe.
One checkpatch.pl warning (too long line) is ignored. This is due to the
fact a string (dt property name) otherwise needs to be split over
multiple lines, which is counterproductive for the readability.
Signed-off-by: Richard Leitner
---
drivers/net/ethernet/freescale/fec.h | 4 ++
drivers/net/ethernet/freescale/fec_main.c | 88 ---
2 files changed, 50 insertions(+), 42 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.h
b/drivers/net/ethernet/freescale/fec.h
index 5385074b3b7d..401c4eabf08a 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -539,6 +539,10 @@ struct fec_enet_private {
int pause_flag;
int wol_flag;
u32 quirks;
+ int phy_reset;
+ int phy_reset_duration;
+ int phy_reset_post_delay;
+ boolphy_reset_active_high;
struct napi_struct napi;
int csum_flags;
diff --git a/drivers/net/ethernet/freescale/fec_main.c
b/drivers/net/ethernet/freescale/fec_main.c
index 610573855213..06a7caca0cee 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -3212,62 +3212,36 @@ static int fec_enet_init(struct net_device *ndev)
}
#ifdef CONFIG_OF
-static int fec_reset_phy(struct platform_device *pdev)
+static int fec_reset_phy(struct net_device *ndev)
{
- int err, phy_reset;
- bool active_high = false;
- int msec = 1, phy_post_delay = 0;
- struct device_node *np = pdev->dev.of_node;
-
- if (!np)
- return 0;
-
- err = of_property_read_u32(np, "phy-reset-duration", &msec);
- /* A sane reset duration should not be longer than 1s */
- if (!err && msec > 1000)
- msec = 1;
+ struct fec_enet_private *fep = netdev_priv(ndev);
- phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0);
- if (phy_reset == -EPROBE_DEFER)
- return phy_reset;
- else if (!gpio_is_valid(phy_reset))
+ if (!fep->phy_reset)
return 0;
- err = of_property_read_u32(np, "phy-reset-post-delay", &phy_post_delay);
- /* valid reset duration should be less than 1s */
- if (!err && phy_post_delay > 1000)
- return -EINVAL;
-
- active_high = of_property_read_bool(np, "phy-reset-active-high");
+ gpio_set_value_cansleep(fep->phy_reset, fep->phy_reset_active_high);
- err = devm_gpio_request_one(&pdev->dev, phy_reset,
- active_high ? GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
- "phy-reset");
- if (err) {
- dev_err(&pdev->dev, "failed to get phy-reset-gpios: %d\n", err);
- return err;
- }
-
- if (msec > 20)
- msleep(msec);
+ if (fep->phy_reset_duration > 20)
+ msleep(fep->phy_reset_duration);
else
- usleep_range(msec * 1000, msec * 1000 + 1000);
+ usleep_range(fep->phy_reset_duration * 1000,
+fep->phy_reset_duration * 1000 + 1000);
- gpio_set_value_cansleep(phy_reset, !active_high);
+ gpio_set_value_cansleep(fep->phy_reset, !fep->phy_reset_active_high);
- if (!phy_post_delay)
+ if (!fep->phy_reset_post_delay)
return 0;
- if (phy_post_delay > 20)
- msleep(phy_post_delay);
+ if (fep->phy_reset_post_delay > 20)
+ msleep(fep->phy_reset_post_delay);
else
- usleep_range(phy_post_delay * 1000,
-phy_post_delay * 1000 + 1000);
+ usleep_range(fep->phy_reset_post_delay * 1000,
+fep->phy_reset_post_delay * 1000 + 1000);
return 0;
}
#else /* CONFIG_OF */
-static int fec_reset_phy(struct platform_device *pdev)
+static int fec_reset_phy(struct net_device *ndev)
{
/*
* In case of platform probe, the reset has been done
@@ -3400,6 +3374,36 @@ fec_probe(struct platform_device *pdev)
}
fep->phy_node = phy_node;
+ fep->phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0);
+ if (gpio_is_valid(fep->phy_reset)) {
+ ret = of_property_read_u32(np, "phy-reset-duration",
+ &fep->phy_reset_duration);
+ /* A sane reset duration should not be longer than 1s */
+ if (!ret && fep->phy_reset_post_delay > 1000)
+ fep->phy_reset_post_delay = 1;
+
+ ret = of_property_read_u32(np, "phy-reset-post-delay",
+
Re: [RFC PATCH for 4.15 04/24] Restartable sequences: x86 32/64 architecture support
On Sun, 19 Nov 2017, Mathieu Desnoyers wrote: > - On Nov 16, 2017, at 4:14 PM, Thomas Gleixner t...@linutronix.de wrote: > > > On Tue, 14 Nov 2017, Mathieu Desnoyers wrote: > > > > Please fix the subject line: > > > > x86: Add support for restartable sequences > > > > or something like that. > > > > And for the actual rseq patches please come up with a proper short > > susbsytem prefix for restartable sequences. There is no point in occupying > > half of the subject space for a prefix. > > ok. done. > > > > > Other than that. > > > > Reviewed-by: Thomas Gleixner > > Thanks! Should I apply the reviewed-by only to the x86 patches, > or patch 01 (rseq: Introduce restartable sequences system call) > as well ? This one of course. I've certainly not yet reviewed your next version :)
Re: [RFC PATCH 1/2] mm: introduce MAP_FIXED_SAFE
On Fri 17-11-17 11:12:51, Matthew Wilcox wrote: > On Thu, Nov 16, 2017 at 04:27:36PM -0800, Kees Cook wrote: > > On Thu, Nov 16, 2017 at 2:18 AM, Michal Hocko wrote: > > > From: Michal Hocko > > > > > > MAP_FIXED is used quite often to enforce mapping at the particular > > > range. The main problem of this flag is, however, that it is inherently > > > dangerous because it unmaps existing mappings covered by the requested > > > range. This can cause silent memory corruptions. Some of them even with > > > serious security implications. While the current semantic might be > > > really desiderable in many cases there are others which would want to > > > enforce the given range but rather see a failure than a silent memory > > > corruption on a clashing range. Please note that there is no guarantee > > > that a given range is obeyed by the mmap even when it is free - e.g. > > > arch specific code is allowed to apply an alignment. > > > > > > Introduce a new MAP_FIXED_SAFE flag for mmap to achieve this behavior. > > > It has the same semantic as MAP_FIXED wrt. the given address request > > > with a single exception that it fails with ENOMEM if the requested > > > address is already covered by an existing mapping. We still do rely on > > > get_unmaped_area to handle all the arch specific MAP_FIXED treatment and > > > check for a conflicting vma after it returns. > > > > I like this much more than special-casing the ELF loader. It is an > > unusual property that MAP_FIXED does _two_ things, so I like having > > this split out. > > > > Bikeshedding: maybe call this MAP_NO_CLOBBER? It's a modifier to > > MAP_FIXED, really... Unfortunatelly doing this as an extension wouldn't work due to backward compatibility issues. See [1] > Way back when, I proposed a new flag called MAP_FIXED_WEAK. I was > dissuaded from it when userspace people said it was just as easy for > them to provide the address hint, then run fixups on their data if the > address they were assigned wasn't the one they asked for. > > The real problem is that MAP_FIXED should have been called MAP_FORCE. > > So ... do we really have users that want failure instead of success at > a different address? I am not really sure but Michael has pointed out to jemalloc [2] which could probably use it. > And if so, is it really a hardship for them to > make a call to unmap on success-at-the-wrong-address? How do you do something like that safely in a multithreaded environment? You do not have any safe way to do atomic probe of a memory range. As I've said, I do not insist on exporting this functionality to the userspace. I can make it an internal flag (outside of the map type) and use it solely in the kernel but considering how MAP_FIXED is tricky I wouldn't be surprised if the userspace can find a use for this. The main question is, are there any downsides to do so? [1] http://lkml.kernel.org/r/20171114092916.ho5mvwc23xnel...@dhcp22.suse.cz [2] http://lkml.kernel.org/r/87efp1w7vy@concordia.ellerman.id.au -- Michal Hocko SUSE Labs
RE: [PATCH] Support TrackStick of Thinkpad L570
Hi, Pali,
1) Yes, but we don't have FW update plan.
And this device works as SMBus in Windows, so this issue happens on only Linux.
2) Yes.
Best Regards,
Masaki Ota
-Original Message-
From: Pali Rohár [mailto:pali.ro...@gmail.com]
Sent: Monday, November 20, 2017 5:30 PM
To: Masaki Ota <012ne...@gmail.com>; dmitry.torok...@gmail.com
Cc: benjamin.tissoi...@redhat.com; aaron...@canonical.com; j...@ristioja.ee; 太田
真喜 Masaki Ota ; linux-in...@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Support TrackStick of Thinkpad L570
On Monday 20 November 2017 16:55:30 Masaki Ota wrote:
> From: Masaki Ota
> - The issue is that Thinkpad L570 TrackStick does not work. Because the main
> interface of Thinkpad L570 device is SMBus, so ALPS overlooked PS2 interface
> Firmware setting of TrackStick. The detail is that TrackStick otp bit is
> disabled.
> - Add the code that checks 0xD7 address value. This value is device number
> information, so we can identify the device by checking this value.
> - If we check 0xD7 value, we need to enable Command mode and after check the
> value we need to disable Command mode, then we have to enable the device(0xF4
> command).
> - Thinkpad L570 device number is 0x0C or 0x1D. If it is TRUE, enable
> ALPS_DUALPOINT flag.
So, the root of this problem is in ALPS firmware which provides wrong
information to kernel?
Masaki, I have two questions:
1) Can ALPS or Lenovo release a new firmware update for this Thinkpad to
fix this issue?
2) Have all Thinkpad L570 machines trackpoint?
Dmitry, as a workaround for firmware bug on particular notebook, would not be
better to check DMI information and DMI based hook?
> Signed-off-by: Masaki Ota
> ---
> drivers/input/mouse/alps.c | 21 ++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
> index 850b00e3ad8e..cce52104ed5a 100644
> --- a/drivers/input/mouse/alps.c
> +++ b/drivers/input/mouse/alps.c
> @@ -2541,13 +2541,28 @@ static int
> alps_update_btn_info_ss4_v2(unsigned char otp[][4], }
>
> static int alps_update_dual_info_ss4_v2(unsigned char otp[][4],
> -struct alps_data *priv)
> +struct alps_data *priv,
> + struct psmouse *psmouse)
> {
> bool is_dual = false;
> + int reg_val = 0;
> + struct ps2dev *ps2dev = &psmouse->ps2dev;
>
> - if (IS_SS4PLUS_DEV(priv->dev_id))
> + if (IS_SS4PLUS_DEV(priv->dev_id)) {
> is_dual = (otp[0][0] >> 4) & 0x01;
>
> + /* For support TrackStick of Thinkpad L570 device */
> + if (alps_exit_command_mode(psmouse) == 0 &&
> + alps_enter_command_mode(psmouse) == 0) {
> + reg_val = alps_command_mode_read_reg(psmouse, 0xD7);
> + }
> + alps_exit_command_mode(psmouse);
> + ps2_command(ps2dev, NULL, PSMOUSE_CMD_ENABLE);
> +
> + if (reg_val == 0x0C || reg_val == 0x1D)
> + is_dual = true;
> + }
> +
> if (is_dual)
> priv->flags |= ALPS_DUALPOINT |
> ALPS_DUALPOINT_WITH_PRESSURE;
> @@ -2570,7 +2585,7 @@ static int alps_set_defaults_ss4_v2(struct
> psmouse *psmouse,
>
> alps_update_btn_info_ss4_v2(otp, priv);
>
> - alps_update_dual_info_ss4_v2(otp, priv);
> + alps_update_dual_info_ss4_v2(otp, priv, psmouse);
>
> return 0;
> }
--
Pali Rohár
pali.ro...@gmail.com
[PATCH] w1: w1-gpio: Convert to use GPIO descriptors
The w1 master driver includes a complete open drain emulation
reimplementation among other things.
This converts the driver and all board files using it to use
GPIO descriptors associated with the device to look up the
GPIO wire, as well ass the optional pull-up GPIO line.
When probed from the device tree, the driver will just pick
descriptors and use them right off. For the two board files
in the kernel, we add descriptor lookups so we do not need
to keep any old platform data handling around for the GPIO
lines.
As the platform data is also a state container for this driver,
we augment it to contain the GPIO descriptors.
w1_gpio_write_bit_dir() and w1_gpio_write_bit_val() are gone
since this pair was a reimplementation of open drain emulation
which is now handled by gpiolib.
The special "linux,open-drain" flag is a bit of mishap here:
it has the same semantic as the same flags in I2C: it means
that something in the platform is setting up the line as
open drain behind our back. We handle this the same way as
in I2C.
To drive the pull-up, we need to bypass open drain emulation
in gpiolib for the line, and this is done by driving it high
using gpiod_set_raw_value() which has been augmented to have
the semantic of overriding the open drain emulation.
We also augment the documentation to reflect the way to pass
GPIO descriptors from the machine.
Signed-off-by: Linus Walleij
---
I don't have a W1-capable system myself so testing would be
appreciated. This needs to be applied to Torvald's HEAD
or v4.15-rc1 when it is tagged to work, as it is using the new
infrastructure updates I merged in the v4.15 merge window.
---
Documentation/w1/masters/w1-gpio| 17 +++-
arch/arm/mach-ixp4xx/vulcan-setup.c | 13 +++-
arch/arm/mach-pxa/raumfeld.c| 16 ++--
drivers/w1/masters/w1-gpio.c| 149 +++-
include/linux/w1-gpio.h | 9 +--
5 files changed, 101 insertions(+), 103 deletions(-)
diff --git a/Documentation/w1/masters/w1-gpio b/Documentation/w1/masters/w1-gpio
index af5d3b4aa851..623961d9e83f 100644
--- a/Documentation/w1/masters/w1-gpio
+++ b/Documentation/w1/masters/w1-gpio
@@ -8,17 +8,27 @@ Description
---
GPIO 1-wire bus master driver. The driver uses the GPIO API to control the
-wire and the GPIO pin can be specified using platform data.
+wire and the GPIO pin can be specified using GPIO machine descriptor tables.
+It is also possible to define the master using device tree, see
+Documentation/devicetree/bindings/w1/w1-gpio.txt
Example (mach-at91)
---
+#include
#include
+static struct gpiod_lookup_table foo_w1_gpiod_table = {
+ .dev_id = "w1-gpio",
+ .table = {
+ GPIO_LOOKUP_IDX("at91-gpio", AT91_PIN_PB20, NULL, 0,
+ GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN),
+ },
+};
+
static struct w1_gpio_platform_data foo_w1_gpio_pdata = {
- .pin= AT91_PIN_PB20,
- .is_open_drain = 1,
+ .ext_pullup_enable_pin = -EINVAL,
};
static struct platform_device foo_w1_device = {
@@ -30,4 +40,5 @@ static struct platform_device foo_w1_device = {
...
at91_set_GPIO_periph(foo_w1_gpio_pdata.pin, 1);
at91_set_multi_drive(foo_w1_gpio_pdata.pin, 1);
+ gpiod_add_lookup_table(&foo_w1_gpiod_table);
platform_device_register(&foo_w1_device);
diff --git a/arch/arm/mach-ixp4xx/vulcan-setup.c
b/arch/arm/mach-ixp4xx/vulcan-setup.c
index 731fb2019ecb..2c03d2f6b647 100644
--- a/arch/arm/mach-ixp4xx/vulcan-setup.c
+++ b/arch/arm/mach-ixp4xx/vulcan-setup.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -162,9 +163,16 @@ static struct platform_device vulcan_max6369 = {
.num_resources = 1,
};
+static struct gpiod_lookup_table vulcan_w1_gpiod_table = {
+ .dev_id = "w1-gpio",
+ .table = {
+ GPIO_LOOKUP_IDX("IXP4XX_GPIO_CHIP", 14, NULL, 0,
+ GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
+ },
+};
+
static struct w1_gpio_platform_data vulcan_w1_gpio_pdata = {
- .pin= 14,
- .ext_pullup_enable_pin = -EINVAL,
+ /* Intentionally left blank */
};
static struct platform_device vulcan_w1_gpio = {
@@ -233,6 +241,7 @@ static void __init vulcan_init(void)
IXP4XX_EXP_BUS_WR_EN |
IXP4XX_EXP_BUS_BYTE_EN;
+ gpiod_add_lookup_table(&vulcan_w1_gpiod_table);
platform_add_devices(vulcan_devices, ARRAY_SIZE(vulcan_devices));
}
diff --git a/arch/arm/mach-pxa/raumfeld.c b/arch/arm/mach-pxa/raumfeld.c
index 9d662fed03ec..feddca7f3540 100644
--- a/arch/arm/mach-pxa/raumfeld.c
+++ b/arch/arm/mach-pxa/raumfeld.c
@@ -506,11 +506,16 @@ static void w1_enable_external_pullup(int enable)
msleep(100);
}
+static struct gpiod_lookup_table raumfeld_w1_gpiod_table = {
+ .dev_id = "w1-gpio",
+ .table = {
+
Re: [PATCH v2] dt-bindings: mtd: Add sst25vf016b to the list of supported chip names
Hi Cyrille,
On Fri, Nov 17, 2017 at 6:36 PM, Cyrille Pitchen
wrote:
> sorry but I won't apply this patch.
>
> New values for the 'compatible' DT properties should only be added for
> memory parts not supporting the JEDEC READ ID (0x9F) command.
I tent to disagree. Documenting part numbers in the DT bindings serves two
purposes:
1. Documenting which parts are supported,
2. Allowing checkpatch to validate compatible values in DTS files (see
below).
Unfortunately the current
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
is useless for the latter, as the values listed don't contain the vendor
prefixes, still causing warnings like
WARNING: DT compatible string "sst,sst25vf016b" appears un-documented
-- check ./Documentation/devicetree/bindings/
#79: FILE: arch/arm/boot/dts/r8a7743-iwg20m.dtsi:79:
+ compatible = "sst,sst25vf016b", "jedec,spi-nor";
So I suggest prepending all part number with the appropriate vendor prefixes
in jedec,spi-nor.txt.
BTW, "sst" (for Silicon Storage Technology) should be added to
Documentation/devicetree/bindings/vendor-prefixes.txt, too, to avoid another
warning:
WARNING: DT compatible string vendor "sst" appears un-documented --
check ./Documentation/devicetree/bindings/vendor-prefixes.txt
#79: FILE: arch/arm/boot/dts/r8a7743-iwg20m.dtsi:79:
+ compatible = "sst,sst25vf016b", "jedec,spi-nor";
> SST25 memories do support this command hence should use the "jedec,spi-nor"
> value alone. For historical reasons, some DT nodes set their 'compatible'
> string to something like ",", "jedec,spi-nor".
> It should work as expected in most case however I discourage from doing so
> in new device trees because it may have some side effects especially when
> the m25p80.c driver is used between the spi-nor.c driver and the SPI
> controller driver.
It is considered good practice to always have in DT a compatible value for
the real part number, not just for a generic fallback.
This allows to discriminate using the real part number, in case an anomaly
shows up later.
How else are you gonna handle e.g. a production batch that accidentally
contains a wrong JEDEC ID? And adding the part-specific compatible value
after the discovery won't help, as it won't be present in existing DTSes.
> It's all about setting the 2nd parameter of spi_nor_scan(), the 'name'
> parameter, as NULL when possible. This parameter should be set to a non NULL
> value only for memories not supporting the JEDEC READ ID op code (0x9F).
>
> Best regards,
>
> Cyrille
>
> Le 24/10/2017 à 15:50, Fabrizio Castro a écrit :
>> There are a few DT files that make use of sst25vf016b in their
>> compatible strings, and the driver supports this chip already.
>> This patch improves the documentation and therefore the result
>> of ./scripts/checkpatch.pl.
>>
>> Signed-off-by: Fabrizio Castro
>> Signed-off-by: Chris Paterson
>> Acked-by: Rob Herring
>> Acked-by: Geert Uytterhoeven
>> ---
>> Thank you Rob, thank you Geert, and sorry for the delay on this one.
>> Here is v2.
>>
>> Changes in v2:
>> * fixed subject prefix
>> * added changelog
>>
>> Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
>> b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
>> index 4cab5d8..bf56d77 100644
>> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
>> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
>> @@ -31,6 +31,7 @@ Required properties:
>> s25sl12801
>> s25fl008k
>> s25fl064k
>> + sst25vf016b
>> sst25vf040b
>> sst25wf040b
>> m25p40
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RFC PATCH 1/2] mm: introduce MAP_FIXED_SAFE
On Fri 17-11-17 08:30:48, Florian Weimer wrote:
> On 11/16/2017 11:18 AM, Michal Hocko wrote:
> > + if (flags & MAP_FIXED_SAFE) {
> > + struct vm_area_struct *vma = find_vma(mm, addr);
> > +
> > + if (vma && vma->vm_start <= addr)
> > + return -ENOMEM;
> > + }
>
> Could you pick a different error code which cannot also be caused by a an
> unrelated, possibly temporary condition? Maybe EBUSY or EEXIST?
Hmm, none of those are described in the man page. I am usually very
careful to not add new and potentially unexpected error codes but it is
true that a new flag should warrant a new error code. I am not sure
which one is more appropriate though. EBUSY suggests that retrying might
help which is true only if some other party unmaps the range. So EEXIST
would sound more natural.
> This would definitely help with application-based randomization of mappings,
> and there, actual ENOMEM and this error would have to be handled
> differently.
I see. Could you be more specific about the usecase you have in mind? I
would incorporate it into the patch description.
--
Michal Hocko
SUSE Labs
[PATCH] xfs: fix memory leak in xfs_iext_free_last_leaf
From: Shu Wang
found the issue by kmemleak.
unreferenced object 0x8800674611c0 (size 16):
xfs_iext_insert+0x82a/0xa90 [xfs]
xfs_bmap_add_extent_hole_delay+0x1e5/0x5b0 [xfs]
xfs_bmapi_reserve_delalloc+0x483/0x530 [xfs]
xfs_file_iomap_begin+0xac8/0xd40 [xfs]
iomap_apply+0xb8/0x1b0
iomap_file_buffered_write+0xac/0xe0
xfs_file_buffered_aio_write+0x198/0x420 [xfs]
xfs_file_write_iter+0x23f/0x2a0 [xfs]
__vfs_write+0x23e/0x340
vfs_write+0xe9/0x240
SyS_write+0xa1/0x120
do_syscall_64+0xda/0x260
Signed-off-by: Shu Wang
---
fs/xfs/libxfs/xfs_iext_tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/xfs/libxfs/xfs_iext_tree.c b/fs/xfs/libxfs/xfs_iext_tree.c
index 19e546a41251..89bf16b4d937 100644
--- a/fs/xfs/libxfs/xfs_iext_tree.c
+++ b/fs/xfs/libxfs/xfs_iext_tree.c
@@ -850,9 +850,9 @@ static void
xfs_iext_free_last_leaf(
struct xfs_ifork*ifp)
{
- ifp->if_u1.if_root = NULL;
ifp->if_height--;
kmem_free(ifp->if_u1.if_root);
+ ifp->if_u1.if_root = NULL;
}
void
--
2.13.5
Re: [RFC PATCH 1/2] mm: introduce MAP_FIXED_SAFE
On Fri 17-11-17 00:37:18, John Hubbard wrote: > On 11/16/2017 02:18 AM, Michal Hocko wrote: [...] > > diff --git a/arch/powerpc/include/uapi/asm/mman.h > > b/arch/powerpc/include/uapi/asm/mman.h > > index 03c06ba7464f..d97342ca25b1 100644 > > --- a/arch/powerpc/include/uapi/asm/mman.h > > +++ b/arch/powerpc/include/uapi/asm/mman.h > > @@ -28,5 +28,6 @@ > > #define MAP_NONBLOCK 0x1 /* do not block on IO */ > > #define MAP_STACK 0x2 /* give out an address that is best > > suited for process/thread stacks */ > > #define MAP_HUGETLB0x4 /* create a huge page mapping */ > > +#define MAP_FIXED_SAFE 0x80/* MAP_FIXED which doesn't > > unmap underlying mapping */ > > > Hi Michal, > > 1. The powerpc change, above, has one too many zeroes. It should be 0x8, > not 0x80. OK, I will fix it. It shouldn't matter much, because we only care about non-clashing address but I agree that we should consume them from bottom bits. > 2. For the one-line comments, if you phrase them like this: > > /* Like MAP_FIXED, except that it doesn't unmap pre-existing mappings */ > > ...I think that would be a little clearer. I do not have any strong preference here. [...] > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 680506faceae..89af0b5839a5 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -1342,6 +1342,10 @@ unsigned long do_mmap(struct file *file, unsigned > > long addr, > > if (!(file && path_noexec(&file->f_path))) > > prot |= PROT_EXEC; > > > > + /* force arch specific MAP_FIXED handling in get_unmapped_area */ > > + if (flags & MAP_FIXED_SAFE) > > + flags |= MAP_FIXED; > > Hooking in at this point is a nice way to solve the problem. :) > > For the naming and implementation, I see a couple of things that might improve > it slightly: > > a) Change MAP_FIXED_SAFE to MAP_NO_CLOBBER (as per Kees' idea), but keep the > new flag independent, by omitting the above two lines. Instead of forcing > MAP_FIXED as a result of the new flag, you could simply fail to take any > action > on MAP_NO_CLOBBER *unless* MAP_FIXED is set. > > This is a bit easier to explain and reason about, as compared to a flag that > auto-sets another flag. I like this approach best. As I've exaplained in other email I do not think we can make this a modifier. > or > > b) Change MAP_FIXED_SAFE to MAP_FIXED_NO_CLOBBER (also a variation on Kees' > name > idea, but a little longer, a bit uglier, and clearer), and leave the > implementation > the same. I do not have a _strong_ preference on the name itself. But I think that _SAFE reflects the behavior slightly better because _NO_CLOBBER is not very specific _when_ and _what_ we do not clobber while _SAFE is clear on that it doesn't perform any unsafe operations. But if the majority think that _NO_CLOBBER is better i will change it. -- Michal Hocko SUSE Labs
Re: [PATCH v3 3/3] perf, tools, script: Allow computing metrics in perf script
On Fri, Nov 17, 2017 at 01:43:00PM -0800, Andi Kleen wrote: SNIP > --- > tools/perf/Documentation/perf-script.txt | 10 +++- > tools/perf/builtin-script.c | 97 > +++- > tools/perf/util/metricgroup.c| 4 ++ > 3 files changed, 108 insertions(+), 3 deletions(-) > > diff --git a/tools/perf/Documentation/perf-script.txt > b/tools/perf/Documentation/perf-script.txt > index 2811fcf684cb..974ceb12c7f3 100644 > --- a/tools/perf/Documentation/perf-script.txt > +++ b/tools/perf/Documentation/perf-script.txt > @@ -117,7 +117,7 @@ OPTIONS > Comma separated list of fields to print. Options are: > comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, symoff, > srcline, period, iregs, uregs, brstack, brstacksym, flags, > bpf-output, brstackinsn, > -brstackoff, callindent, insn, insnlen, synth, phys_addr. > + brstackoff, callindent, insn, insnlen, synth, phys_addr, metric. > Field list can be prepended with the type, trace, sw or hw, > to indicate to which event type the field list applies. > e.g., -F sw:comm,tid,time,ip,sym and -F trace:time,cpu,trace > @@ -217,6 +217,14 @@ OPTIONS > > The brstackoff field will print an offset into a specific dso/binary. > > + With the metric option perf script can compute metrics for > + sampling periods, similar to perf stat. This requires > + specifying a group with multiple metrics with the :S option > + for perf record. perf will sample on the first event, and > + compute metrics for all the events in the group. Please note > + that the metric computed is averaged over the whole sampling > + period, not just for the sample point. hum, is it? I see you call perf_stat__reset_shadow_stats for every group start.. which I'd think means you see metric for current leader sample point jirka
Re: [PATCH 1/2] sched: force update of blocked load of idle cpus
On 24 October 2017 at 14:25, Brendan Jackman wrote:
> From: Vincent Guittot
>
> When idle, the blocked load of CPUs will be updated only when an idle
> load balance is triggered which may never happen. Because of this
> uncertainty on the execution of idle load balance, the utilization,
> the load and the shares of idle cfs_rq can stay artificially high and
> steal shares and running time to busy cfs_rqs of the task group.
> Add a new light idle load balance state which ensures that blocked loads
> are periodically updated and decayed but does not perform any task
> migration.
>
> The remote load udpates are rate-limited, so that they are not
> performed with a shorter period than LOAD_AVG_PERIOD (i.e. PELT
> half-life). This is the period after which we have a known 50% error
> in stale load.
>
> Cc: Dietmar Eggemann
> Cc: Vincent Guittot
> Cc: Ingo Molnar
> Cc: Morten Rasmussen
> Cc: Peter Zijlstra
> Signed-off-by: Vincent Guittot
> [Switched remote update interval to use PELT half life]
> [Moved update_blocked_averges call outside rebalance_domains
> to simplify code]
> Signed-off-by: Brendan Jackman
> ---
> kernel/sched/fair.c | 71
> +---
> kernel/sched/sched.h | 1 +
> 2 files changed, 63 insertions(+), 9 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 85d1ec1c3b39..9085caf49c76 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5976,6 +5976,9 @@ static int wake_cap(struct task_struct *p, int cpu, int
> prev_cpu)
> return min_cap * 1024 < task_util(p) * capacity_margin;
> }
>
> +static inline bool nohz_kick_needed(struct rq *rq, bool only_update);
> +static void nohz_balancer_kick(bool only_update);
> +
> /*
> * select_task_rq_fair: Select target runqueue for the waking task in domains
> * that have the 'sd_flag' flag set. In practice, this is SD_BALANCE_WAKE,
> @@ -6074,6 +6077,11 @@ select_task_rq_fair(struct task_struct *p, int
> prev_cpu, int sd_flag, int wake_f
> }
> rcu_read_unlock();
>
> +#ifdef CONFIG_NO_HZ_COMMON
> + if (nohz_kick_needed(cpu_rq(new_cpu), true))
> + nohz_balancer_kick(true);
> +#endif
> +
> return new_cpu;
> }
>
> @@ -8653,6 +8661,7 @@ static struct {
> cpumask_var_t idle_cpus_mask;
> atomic_t nr_cpus;
> unsigned long next_balance; /* in jiffy units */
> + unsigned long next_update; /* in jiffy units */
> } nohz cacheline_aligned;
>
> static inline int find_new_ilb(void)
> @@ -8670,7 +8679,7 @@ static inline int find_new_ilb(void)
> * nohz_load_balancer CPU (if there is one) otherwise fallback to any idle
> * CPU (if there is one).
> */
> -static void nohz_balancer_kick(void)
> +static void nohz_balancer_kick(bool only_update)
> {
> int ilb_cpu;
>
> @@ -8683,6 +8692,10 @@ static void nohz_balancer_kick(void)
>
> if (test_and_set_bit(NOHZ_BALANCE_KICK, nohz_flags(ilb_cpu)))
> return;
> +
> + if (only_update)
> + set_bit(NOHZ_STATS_KICK, nohz_flags(ilb_cpu));
> +
> /*
> * Use smp_send_reschedule() instead of resched_cpu().
> * This way we generate a sched IPI on the target cpu which
> @@ -8770,6 +8783,8 @@ void nohz_balance_enter_idle(int cpu)
> atomic_inc(&nohz.nr_cpus);
> set_bit(NOHZ_TICK_STOPPED, nohz_flags(cpu));
> }
> +#else
> +static inline void nohz_balancer_kick(bool only_update) {}
> #endif
>
> static DEFINE_SPINLOCK(balancing);
> @@ -8801,8 +8816,6 @@ static void rebalance_domains(struct rq *rq, enum
> cpu_idle_type idle)
> int need_serialize, need_decay = 0;
> u64 max_cost = 0;
>
> - update_blocked_averages(cpu);
> -
> rcu_read_lock();
> for_each_domain(cpu, sd) {
> /*
> @@ -8901,6 +8914,7 @@ static void nohz_idle_balance(struct rq *this_rq, enum
> cpu_idle_type idle)
> {
> int this_cpu = this_rq->cpu;
> struct rq *rq;
> + struct sched_domain *sd;
> int balance_cpu;
> /* Earliest time when we have to do rebalance again */
> unsigned long next_balance = jiffies + 60*HZ;
> @@ -8910,6 +8924,23 @@ static void nohz_idle_balance(struct rq *this_rq, enum
> cpu_idle_type idle)
> !test_bit(NOHZ_BALANCE_KICK, nohz_flags(this_cpu)))
> goto end;
>
> + /*
> +* This cpu is going to update the blocked load of idle CPUs either
> +* before doing a rebalancing or just to keep metrics up to date. we
> +* can safely update the next update timestamp
> +*/
> + rcu_read_lock();
> + sd = rcu_dereference(this_rq->sd);
> + /*
> +* Check whether there is a sched_domain available for this cpu.
> +* The last other cpu can have been unplugged since the ILB has been
> +* triggered and the sched_domain can now be null. The idle balance
> +* sequence will quickly be a
Re: [RFC PATCH 0/2] mm: introduce MAP_FIXED_SAFE
On Fri 17-11-17 00:45:49, John Hubbard wrote: > On 11/16/2017 04:14 AM, Michal Hocko wrote: > > [Ups, managed to screw the subject - fix it] > > > > On Thu 16-11-17 11:18:58, Michal Hocko wrote: > >> Hi, > >> this has started as a follow up discussion [1][2] resulting in the > >> runtime failure caused by hardening patch [3] which removes MAP_FIXED > >> from the elf loader because MAP_FIXED is inherently dangerous as it > >> might silently clobber and existing underlying mapping (e.g. stack). The > >> reason for the failure is that some architectures enforce an alignment > >> for the given address hint without MAP_FIXED used (e.g. for shared or > >> file backed mappings). > >> > >> One way around this would be excluding those archs which do alignment > >> tricks from the hardening [4]. The patch is really trivial but it has > >> been objected, rightfully so, that this screams for a more generic > >> solution. We basically want a non-destructive MAP_FIXED. > >> > >> The first patch introduced MAP_FIXED_SAFE which enforces the given > >> address but unlike MAP_FIXED it fails with ENOMEM if the given range > >> conflicts with an existing one. The flag is introduced as a completely > >> new flag rather than a MAP_FIXED extension because of the backward > >> compatibility. We really want a never-clobber semantic even on older > >> kernels which do not recognize the flag. Unfortunately mmap sucks wrt. > >> flags evaluation because we do not EINVAL on unknown flags. On those > >> kernels we would simply use the traditional hint based semantic so the > >> caller can still get a different address (which sucks) but at least not > >> silently corrupt an existing mapping. I do not see a good way around > >> that. Except we won't export expose the new semantic to the userspace at > >> all. It seems there are users who would like to have something like that > >> [5], though. Atomic address range probing in the multithreaded programs > >> sounds like an interesting thing to me as well, although I do not have > >> any specific usecase in mind. > > Hi Michal, > > From looking at the patchset, it seems to me that the new MAP_FIXED_SAFE > (or whatever it ends up being named) *would* be passed through from > user space. When you say that "we won't export expose the new semantic > to the userspace at all", do you mean that glibc won't add it? Or > is there something I'm missing, that prevents that flag from getting > from the syscall, to do_mmap()? I meant that I could make it an internal flag outside of the map_type space. So the userspace will not be able to use it. > On the usage: there are cases in user space that could probably make > good use of a no-clobber hint to MAP_FIXED. The user space code > that surrounds HMM (speaking loosely there--it's really any user space > code that manages a unified memory address space, across devices) > often ends up using MAP_FIXED, but MAP_FIXED crams several features > into one flag: an exact address, an "atomic" switch to the new mapping, > and unmapping the old mappings. That's pretty overloaded, so being > able to split it up a bit, by removing one of those features, seems > useful. Yes, atomic address range probing sounds useful. I cannot comment on HMM usage but if you have any more specific I would welcome any links to add them to the changelog. -- Michal Hocko SUSE Labs
Re: [PATCH 2/2 v2] misc: atmel-ssc: Fix platform_get_irq's error checking
On 18/11/2017 at 10:10, Arvind Yadav wrote:
> The platform_get_irq() function returns negative if an error occurs.
> zero or positive number on success. platform_get_irq() error checking
> for zero is not correct.
>
> Signed-off-by: Arvind Yadav
> ---
> changes in v2 :
> Add failure case '<= 0' instead of '< 0'. IRQ 0 is not valid.
>
> drivers/misc/atmel-ssc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
> index b2a0340..9d9eeae 100644
> --- a/drivers/misc/atmel-ssc.c
> +++ b/drivers/misc/atmel-ssc.c
> @@ -235,9 +235,9 @@ static int ssc_probe(struct platform_device *pdev)
> clk_disable_unprepare(ssc->clk);
>
> ssc->irq = platform_get_irq(pdev, 0);
> - if (!ssc->irq) {
> + if (ssc->irq <= 0) {
> dev_dbg(&pdev->dev, "could not get irq\n");
> - return -ENXIO;
> + return ssc->irq;
if ssc->irq = 0, I believe that returning 0 is not the right thing to do.
Regards,
> }
>
> spin_lock(&user_lock);
>
--
Nicolas Ferre
Re: "swap_free: Bad swap file entry" and "BUG: Bad page map in process" but no swap configured
Hi, Chris
I have met the same issue too, did you have found out the root cause ?
Thanks a lot.
Huaitong Han
2016-10-12 0:02 GMT+08:00 Chris Friesen :
> On 10/08/2016 02:05 AM, Hillf Danton wrote:
>>
>> On Friday, October 07, 2016 5:01 AM Chris Friesen
>>>
>>>
>>> I have Linux host running as a kvm hypervisor. It's running CentOS. (So
>>> the
>>> kernel is based on 3.10 but with loads of stuff backported by RedHat.) I
>>> realize this is not a mainline kernel, but I was wondering if anyone is
>>> aware of
>>> similar issues that had been fixed in mainline.
>>>
>> Hey, dunno if you're looking for commit
>> 6dec97dc929 ("mm: move_ptes -- Set soft dirty bit depending on pte
>> type")
>> Hillf
>
>
> CONFIG_MEM_SOFT_DIRTY doesn't exist in our kernel so I don't think this is
> the issue. Thanks for the suggestion though.
>
> Chris
Re: [PATCH 2/2 v3] misc: atmel-ssc: Fix platform_get_irq's error checking
On 19/11/2017 at 05:34, Arvind Yadav wrote:
> The platform_get_irq() function returns negative if an error occurs.
> zero or positive number on success. platform_get_irq() error checking
> for zero is not correct.
>
> Signed-off-by: Arvind Yadav
> ---
> changes in v2 :
> Add failure case '<= 0' instead of '< 0'. IRQ 0 is not valid.
> changes in v3:
> Return -ENODEV instead of ssc->irq.
Okay, I didn't see this v3 before commenting on v2...
>
> drivers/misc/atmel-ssc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
> index b2a0340..2ec0f9e 100644
> --- a/drivers/misc/atmel-ssc.c
> +++ b/drivers/misc/atmel-ssc.c
> @@ -235,7 +235,7 @@ static int ssc_probe(struct platform_device *pdev)
> clk_disable_unprepare(ssc->clk);
>
> ssc->irq = platform_get_irq(pdev, 0);
> - if (!ssc->irq) {
> + if (ssc->irq <= 0) {
> dev_dbg(&pdev->dev, "could not get irq\n");
> return -ENXIO;
> }
>
--
Nicolas Ferre
Re: Improving documentation of parent-ID field in /proc/PID/mountinfo
Hi Miklos,
Sorry for the slow follow-up.
On 14 November 2017 at 17:16, Miklos Szeredi wrote:
> On Tue, Nov 14, 2017 at 8:08 AM, Michael Kerrisk (man-pages)
> wrote:
>> Hi Miklos, Ram
>>
>> Thanks for your comments. A question below.
>>
>> On 13 November 2017 at 09:11, Miklos Szeredi wrote:
>>> On Mon, Nov 13, 2017 at 8:55 AM, Ram Pai wrote:
On Mon, Nov 13, 2017 at 07:02:21AM +0100, Michael Kerrisk (man-pages)
wrote:
> Hello Ram,
>
> Long ago (2.6.29) you added the /proc/PID/mountinfo file and
> associated documentation in Documentation/filesystems/proc.txt. Later,
> I pasted much of that documentation into the proc(5) manual page.
>
> That documentation says of the second field in the file:
>
> [[
> This file contains lines of the form:
>
> 36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root
> rw,errors=continue
> (1)(2)(3) (4) (5) (6) (7) (8) (9) (10) (11)
>
> (1) mount ID: unique identifier of the mount (may be reused after umount)
> (2) parent ID: ID of parent (or of self for the top of the mount tree)
> ...
> ]]
>
> The last piece of the description of field (2) doesn't seem to be
> correct, or is at least rather unclear. I take this to be saying that
> that for the root mount point, /, field (2) will have the same value
> as field (1). I never actually looked at this detail closely, but
> Alexander pointed out that this is obviously not so, as one can
> immediately verify:
>
> $ grep '/ / ' /proc/$$/mountinfo
> 65 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,seclabel,data=order
>
> I dug around in the kernel source for a bit. I do not have an exact
> handle on the details, but I can see roughly what is going on.
> Internally, there seems to be one ("hidden") mount ID reserved to each
> mount namespace, and that ID is the parent of the root mount point.
>
> Looking through the (4.14) kernel source, mount IDs are allocated by
> mnt_alloc_id() (in fs/namespace.c), which is in turn called by
> alloc_vfsmnt() which is in turn called by clone_mnt().
>
> A new mount namespace is created by the kernel function copy_mnt_ns()
> (in fs/namespace.c, called by create_new_namespaces() in
> kernel/nsproxy.c). The copy_mnt_ns() function calls copy_tree() (in
> fs/namespace.c), and copy_tree() calls clone_mnt() in *two* places.
> The first of these is the call that creates the "hidden" mount ID that
> becomes the parent of the root mount point. (I verified this by
> instrumenting the kernel with a few printk() calls to display the
> IDs.) The second place where copy_tree() calls clone_mnt() is in a
> loop that replicates each of the mount points (including the root
> mount point) in the source mount namespace.
We used to report that mount, ones upon a time. Something has changed
the behavior since then and its not reported any more, thus making it
hidden.
>>>
>>> The hidden one is the initramfs, I believe. That's the root of the
>>> mount namespace, and the when a namespace is cloned, the tree is
>>> copied from the namespace root.
>>>
>>> It is "hidden" because no process has its root there. Note the
>>> difference between namespace root and process root: the first is the
>>> real root of the mount tree and is unchangeable, the second is
>>> pointing to some place in a mount tree and can be changed (chroot).
>>>
>>> So there's nothing special in this rootfs, it is just hidden because
>>> it's not the root of any task.
>>>
>>> The description of field (2) is correct, it just does not make it
>>> clear what it means by "root".
>>
>> Sorry -- do you mean the old description is correct, or my new
>> description (below)?
>
> Well, both are correct, yours just describes the same thing at the
> higher level. But I think rootfs is an implementation detail, so is
> the fact that it gets a zero mount ID, so I think the original
> description better captures the essence of the interface. Except it
> needs to clarify what "top of the mount tree" means. It doesn't mean
> current process's root, rather it means the root of the mount tree in
> the current mount namespace.
Thanks for the further info.
But, the problem is that the existing description is at best misleading:
(2) parent ID: the ID of the parent mount (or of self for
the top of the mount tree).
That implies that we'll find one line in the list where field 1 and
field 2 are the same. But we don't, because the mountns rootfs entry
is not shown in mountinfo. On top of that, the reader is left
confused, because when they look at mountinfo, they see one entry
where the parent-ID doesn't exist in the list. So, something more than
the current text is required. After digging around in the kernel
source and noticing that chroot() will also cause this scenario, a
Re: [PATCH 2/2] sched/fair: Update blocked load from newly idle balance
On 24 October 2017 at 14:25, Brendan Jackman wrote:
> We now have a NOHZ kick to avoid the load of idle CPUs becoming stale. This is
> good, but it brings about CPU wakeups, which have an energy cost. As an
> alternative to waking CPUs up to do decay blocked load, we can sometimes do it
> from newly idle balance. If the newly idle balance is on a domain that covers
> all the currently nohz-idle CPUs, we push the value of nohz.next_update into
> the
> future. That means that if such newly idle balances happen often enough, we
> never need wake up a CPU just to update load.
>
> Since we're doing this new update inside a for_each_domain, we need to do
> something to avoid doing multiple updates on the same CPU in the same
> idle_balance. A tick stamp is set on the rq in update_blocked_averages as a
> simple way to do this. Using a simple jiffies-based timestamp, as opposed to
> the
> last_update_time of the root cfs_rq's sched_avg, means we can do this without
> taking the rq lock.
>
> Cc: Dietmar Eggemann
> Cc: Vincent Guittot
> Cc: Ingo Molnar
> Cc: Morten Rasmussen
> Cc: Peter Zijlstra
> Signed-off-by: Brendan Jackman
> ---
> kernel/sched/core.c | 1 +
> kernel/sched/fair.c | 41 +++--
> kernel/sched/sched.h | 1 +
> 3 files changed, 37 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index d17c5da523a0..d8e71fd27806 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5923,6 +5923,7 @@ void __init sched_init(void)
> rq_attach_root(rq, &def_root_domain);
> #ifdef CONFIG_NO_HZ_COMMON
> rq->last_load_update_tick = jiffies;
> + rq->last_blocked_load_update_tick = jiffies;
> rq->nohz_flags = 0;
> #endif
> #ifdef CONFIG_NO_HZ_FULL
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 9085caf49c76..45e9c8056161 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -7062,6 +7062,7 @@ static void update_blocked_averages(int cpu)
> if (cfs_rq_is_decayed(cfs_rq))
> list_del_leaf_cfs_rq(cfs_rq);
> }
> + rq->last_blocked_load_update_tick = jiffies;
last_blocked_load_update_tick is defined under CONFIG_NO_HZ_COMMON and
CONFIG_SMP
whereas update_blocked_averages() is not. This generates a compilation error
> rq_unlock_irqrestore(rq, &rf);
> }
>
> @@ -7121,6 +7122,7 @@ static inline void update_blocked_averages(int cpu)
> rq_lock_irqsave(rq, &rf);
> update_rq_clock(rq);
> update_cfs_rq_load_avg(cfs_rq_clock_task(cfs_rq), cfs_rq);
> + rq->last_blocked_load_update_tick = jiffies;
> rq_unlock_irqrestore(rq, &rf);
> }
>
> @@ -7615,6 +7617,15 @@ static inline enum fbq_type fbq_classify_rq(struct rq
> *rq)
> }
> #endif /* CONFIG_NUMA_BALANCING */
>
> +#ifdef CONFIG_NO_HZ_COMMON
> +static struct {
> + cpumask_var_t idle_cpus_mask;
> + atomic_t nr_cpus;
> + unsigned long next_balance; /* in jiffy units */
> + unsigned long next_update; /* in jiffy units */
> +} nohz cacheline_aligned;
> +#endif
> +
> /**
> * update_sd_lb_stats - Update sched_domain's statistics for load balancing.
> * @env: The load balancing environment.
> @@ -7633,6 +7644,30 @@ static inline void update_sd_lb_stats(struct lb_env
> *env, struct sd_lb_stats *sd
> if (child && child->flags & SD_PREFER_SIBLING)
> prefer_sibling = 1;
>
> +#ifdef CONFIG_NO_HZ_COMMON
> + if (env->idle == CPU_NEWLY_IDLE) {
> + int cpu;
> +
> + /* Update the stats of NOHZ idle CPUs in the sd */
> + for_each_cpu_and(cpu, sched_domain_span(env->sd),
> +nohz.idle_cpus_mask) {
> + struct rq *rq = cpu_rq(cpu);
> +
> + /* ... Unless we've already done since the last tick
> */
> + if (time_after(jiffies,
> + rq->last_blocked_load_update_tick))
> + update_blocked_averages(cpu);
> + }
> + }
> + /*
> +* If we've just updated all of the NOHZ idle CPUs, then we can push
> +* back the next nohz.next_update, which will prevent an unnecessary
> +* wakeup for the nohz stats kick
> +*/
> + if (cpumask_subset(nohz.idle_cpus_mask, sched_domain_span(env->sd)))
> + nohz.next_update = jiffies + LOAD_AVG_PERIOD;
> +#endif
> +
> load_idx = get_sd_load_idx(env->sd, env->idle);
>
> do {
> @@ -8657,12 +8692,6 @@ static inline int on_null_domain(struct rq *rq)
> * needed, they will kick the idle load balancer, which then does idle
> * load balancing for all the idle CPUs.
> */
> -static struct {
> - cpumask_var_t idle_cpus_mask;
> - atomic_t nr_cpus;
> - unsigned long next_balance; /* in jiffy units */
> - un
Re: [RFC PATCH 1/2] mm: introduce MAP_FIXED_SAFE
On 11/20/2017 09:55 AM, Michal Hocko wrote:
On Fri 17-11-17 08:30:48, Florian Weimer wrote:
On 11/16/2017 11:18 AM, Michal Hocko wrote:
+ if (flags & MAP_FIXED_SAFE) {
+ struct vm_area_struct *vma = find_vma(mm, addr);
+
+ if (vma && vma->vm_start <= addr)
+ return -ENOMEM;
+ }
Could you pick a different error code which cannot also be caused by a an
unrelated, possibly temporary condition? Maybe EBUSY or EEXIST?
Hmm, none of those are described in the man page. I am usually very
careful to not add new and potentially unexpected error codes but it is
I think this is a bad idea. It leads to bizarre behavior, like open
failing with EOVERFLOW with certain namespace configurations (which have
nothing to do with file sizes).
Most of the manual pages are incomplete regarding error codes, and with
seccomp filters and security modules, what error codes you actually get
is anyone's guess.
true that a new flag should warrant a new error code. I am not sure
which one is more appropriate though. EBUSY suggests that retrying might
help which is true only if some other party unmaps the range. So EEXIST
would sound more natural.
Sure, EEXIST is completely fine.
This would definitely help with application-based randomization of mappings,
and there, actual ENOMEM and this error would have to be handled
differently.
I see. Could you be more specific about the usecase you have in mind? I
would incorporate it into the patch description.
glibc ld.so currently maps DSOs without hints. This means that the
kernel will map right next to each other, and the offsets between them a
completely predictable. We would like to change that and supply a
random address in a window of the address space. If there is a
conflict, we do not want the kernel to pick a non-random address.
Instead, we would try again with a random address.
Thanks,
Florian
RE: [PATCH 3/3] arm: dts: owl-s500: Add Sparky
Acked-by : sudeep
-Original Message-
From: Andreas Färber [mailto:afaer...@suse.de]
Sent: Tuesday, November 14, 2017 11:31 PM
To: linux-arm-ker...@lists.infradead.org
Cc: Thomas Liau ; Jeff Chen
; 张东风 ; 刘炜
; 张天益 ; 梅利
; Ioan B ; Sudeep Kumar
; linux-kernel@vger.kernel.org; Andreas Färber
; Rob Herring ; Mark Rutland
; Russell King ;
devicet...@vger.kernel.org
Subject: [PATCH 3/3] arm: dts: owl-s500: Add Sparky
Add a Device Tree for the Allo.com Sparky SBC.
Signed-off-by: Andreas Färber
---
arch/arm/boot/dts/Makefile| 3 ++-
arch/arm/boot/dts/owl-s500-sparky.dts | 44 +++
2 files changed, 46 insertions(+), 1 deletion(-) create mode 100644
arch/arm/boot/dts/owl-s500-sparky.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index
d0381e9caf21..ad77f7656a70 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -707,7 +707,8 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
orion5x-rd88f5182-nas.dtb
dtb-$(CONFIG_ARCH_ACTIONS) += \
owl-s500-cubieboard6.dtb \
- owl-s500-guitar-bb-rev-b.dtb
+ owl-s500-guitar-bb-rev-b.dtb \
+ owl-s500-sparky.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += \
prima2-evb.dtb
dtb-$(CONFIG_ARCH_OXNAS) += \
diff --git a/arch/arm/boot/dts/owl-s500-sparky.dts
b/arch/arm/boot/dts/owl-s500-sparky.dts
new file mode 100644
index ..f620548c6c0b
--- /dev/null
+++ b/arch/arm/boot/dts/owl-s500-sparky.dts
@@ -0,0 +1,44 @@
+/*
+ * Allo.com Sparky
+ *
+ * Copyright (c) 2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
+
+/dts-v1/;
+
+#include "owl-s500.dtsi"
+
+/ {
+ compatible = "allo,sparky", "actions,s500";
+ model = "Allo.com Sparky";
+
+ aliases {
+ serial3 = &uart3;
+ };
+
+ chosen {
+ stdout-path = "serial3:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x4000>; /* 1 or 2 GiB */
+ };
+
+ uart3_clk: uart3-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <921600>;
+ #clock-cells = <0>;
+ };
+};
+
+&timer {
+ clocks = <&hosc>;
+};
+
+&uart3 {
+ status = "okay";
+ clocks = <&uart3_clk>;
+};
--
2.13.6
[PATCH] KVM: VMX: Fix rflags cache during vCPU reset
From: Wanpeng Li Reported by syzkaller: *** Guest State *** CR0: actual=0x80010031, shadow=0x6010, gh_mask=fff7 CR4: actual=0x2061, shadow=0x, gh_mask=e8f1 CR3 = 0x2081e000 RSP = 0xfffa RIP = 0x RFLAGS=0x00023000 DR7 = 0x0002 .. [ cut here ] WARNING: CPU: 6 PID: 24431 at /home/kernel/linux/arch/x86/kvm//x86.c:7302 kvm_arch_vcpu_ioctl_run+0x651/0x2ea0 [kvm] CPU: 6 PID: 24431 Comm: reprotest Tainted: GW OE 4.14.0+ #26 RIP: 0010:kvm_arch_vcpu_ioctl_run+0x651/0x2ea0 [kvm] RSP: 0018:880291d179e0 EFLAGS: 00010202 Call Trace: ? synchronize_rcu.part.59+0x9b/0xf0 ? synchronize_rcu_expedited+0xa0/0xa0 ? kfree_call_rcu+0x20/0x20 ? trace_raw_output_rcu_utilization+0x70/0x70 ? kvm_arch_vcpu_runnable+0x220/0x220 [kvm] ? wait_for_completion+0x222/0x2a0 ? __wait_rcu_gp+0x1d3/0x230 ? kvm_vcpu_ioctl+0x479/0x880 [kvm] kvm_vcpu_ioctl+0x479/0x880 [kvm] ? kvm_dev_ioctl+0xba0/0xba0 [kvm] ? pick_next_task_fair+0x629/0xce0 ? sched_clock+0x1b/0x20 ? check_chain_key+0x131/0x1e0 ? lock_acquire+0x2c0/0x2c0 ? check_flags.part.44+0x62/0x250 ? check_chain_key+0x131/0x1e0 ? __lock_acquire+0xd2e/0x1cb0 do_vfs_ioctl+0x142/0x9a0 ? ioctl_preallocate+0x150/0x150 ? lock_acquire+0x2c0/0x2c0 ? lock_acquire+0x118/0x2c0 ? __lock_is_held+0x4b/0xe0 ? __fget+0x16a/0x250 SyS_ioctl+0x74/0x80 entry_SYSCALL_64_fastpath+0x23/0x9a The syzkaller testcase tries to setup the processor specific debug registers and configure vCPU for handling guest debug events through KVM_SET_GUEST_DEBUG. The KVM_SET_GUEST_DEBUG ioctl will get and set rflags in order to set TF bit if single step is needed. All regs' caches are reset to avail and GUEST_RFLAGS vmcs field is reset to 0x2 during vCPU reset. However, the cache of rflags is not reset during vCPU reset. The function vmx_get_rflags() returns an unreset rflags cache value since the cache is marked avail, it is 0 after boot. Vmentry fails if the rflags reserved bit 1 is 0. This patch fixes it by resetting both the GUEST_RFLAGS vmcs field and its cache to 0x2 during vCPU reset. Reported-by: Dmitry Vyukov Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Nadav Amit Cc: Dmitry Vyukov Signed-off-by: Wanpeng Li --- arch/x86/kvm/vmx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index b348920..131fa1c 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -5590,6 +5590,7 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event) vmcs_write64(GUEST_IA32_DEBUGCTL, 0); } + vmx->rflags = 0x02; vmcs_writel(GUEST_RFLAGS, 0x02); kvm_rip_write(vcpu, 0xfff0); -- 2.7.4
Re: WARNING in kvm_arch_vcpu_ioctl_run (2)
Hi Dmitry, 2017-11-20 12:09 GMT+08:00 Wanpeng Li : > 2017-11-18 4:22 GMT+08:00 syzbot > : >> Hello, >> >> syzbot has tested the proposed patch but the reproducer still triggered >> crash: >> WARNING in kvm_arch_vcpu_ioctl_run >> >> VMExit: intr_info= errcode= ilen= >> reason=8021 qualification= >> IDTVectoring: info= errcode= >> TSC Offset = 0xffeeb46bc6ac >> EPT pointer = 0x0001ce37601e >> WARNING: CPU: 0 PID: 3023 at arch/x86/kvm/x86.c:7293 >> kvm_arch_vcpu_ioctl_run+0x213/0x5d20 >> Kernel panic - not syncing: panic_on_warn set ... >> >> CPU: 0 PID: 3023 Comm: syz-executor4 Not tainted 4.14.0-next-20171117+ #9 >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS >> Google 01/01/2011 >> Call Trace: >> dump_stack+0x173/0x237 >> panic+0x1e4/0x41c >> __warn+0x1d9/0x1f0 >> report_bug+0x20a/0x2d0 >> fixup_bug.part.10+0x32/0x80 >> do_error_trap+0x29c/0x370 >> invalid_op+0x18/0x20 >> RIP: 0010:kvm_arch_vcpu_ioctl_run+0x213/0x5d20 >> RSP: 0018:8801ce197680 EFLAGS: 00010293 >> RAX: 8801ce588440 RBX: 8801d5b8f000 RCX: 810d4003 >> RDX: RSI: RDI: 8801ce0e02b8 >> RBP: 8801ce197a50 R08: 0001 R09: 0001 >> R10: R11: 0001 R12: >> R13: 8801ce0e0168 R14: 8801cec10980 R15: 8801ce0e0080 >> kvm_vcpu_ioctl+0x619/0xf80 >> do_vfs_ioctl+0x18b/0x13e0 >> SyS_ioctl+0x7e/0xb0 >> entry_SYSCALL_64_fastpath+0x1f/0x96 >> RIP: 0033:0x452879 >> RSP: 002b:7f4bc97fdbe8 EFLAGS: 0212 ORIG_RAX: 0010 >> RAX: ffda RBX: 0082 RCX: 00452879 >> RDX: RSI: ae80 RDI: 0004 >> RBP: 7ffce1993510 R08: R09: >> R10: R11: 0212 R12: >> R13: 7ffce199348f R14: 7f4bc97fe9c0 R15: 0006 >> Dumping ftrace buffer: >>(ftrace buffer empty) >> Kernel Offset: disabled >> Rebooting in 86400 seconds.. > > I will have a look. Please have a try. https://lkml.org/lkml/2017/11/20/118 Regards, Wanpeng Li
Re: [PATCH 2/6] mmc: tmio: set tmio_mmc_host to driver data
Yamada-san, > My best guess is unnecessary if-conditional was added > and overlooked in the review process. I agree. So, from visual review, most patches look good to me. I will give them testing on HW this evening and add my Reviewed-by tags then. I'll also reply to the driver rename thread later today. Thanks! Wolfram signature.asc Description: PGP signature
Re: Improving documentation of parent-ID field in /proc/PID/mountinfo
On Mon, Nov 20, 2017 at 10:07 AM, Michael Kerrisk (man-pages) wrote: > But, the problem is that the existing description is at best misleading: > > (2) parent ID: the ID of the parent mount (or of self for >the top of the mount tree). > > That implies that we'll find one line in the list where field 1 and > field 2 are the same. But we don't, because the mountns rootfs entry > is not shown in mountinfo. On top of that, the reader is left > confused, because when they look at mountinfo, they see one entry > where the parent-ID doesn't exist in the list. So, something more than > the current text is required. After digging around in the kernel > source and noticing that chroot() will also cause this scenario, and > taking into account your comments, I revised the text to: > > (2) parent ID: the ID of the parent mount (or of self for >the root of this mount namespace's mount tree). > >If the parent mount point lies outside the process's >root directory (see chroot(2)), the ID shown here >won't have a corresponding record in mountinfo whose >mount ID (field 1) matches this parent mount ID >(because mount points that lie outside the process's >root directory are not shown in mountinfo). As a spe‐ >cial case of this point, the process's root mount >point may have a parent mount (for the initramfs >filesystem) that lies outside the process's root >directory, and an entry for that mount point will not >appear in mountinfo. > > How does that seem? Perfect. Thanks, Miklos
Re: WARNING in kvm_arch_vcpu_ioctl_run (2)
On Mon, Nov 20, 2017 at 10:19 AM, Wanpeng Li wrote: > Hi Dmitry, > 2017-11-20 12:09 GMT+08:00 Wanpeng Li : >> 2017-11-18 4:22 GMT+08:00 syzbot >> : >>> Hello, >>> >>> syzbot has tested the proposed patch but the reproducer still triggered >>> crash: >>> WARNING in kvm_arch_vcpu_ioctl_run >>> >>> VMExit: intr_info= errcode= ilen= >>> reason=8021 qualification= >>> IDTVectoring: info= errcode= >>> TSC Offset = 0xffeeb46bc6ac >>> EPT pointer = 0x0001ce37601e >>> WARNING: CPU: 0 PID: 3023 at arch/x86/kvm/x86.c:7293 >>> kvm_arch_vcpu_ioctl_run+0x213/0x5d20 >>> Kernel panic - not syncing: panic_on_warn set ... >>> >>> CPU: 0 PID: 3023 Comm: syz-executor4 Not tainted 4.14.0-next-20171117+ #9 >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS >>> Google 01/01/2011 >>> Call Trace: >>> dump_stack+0x173/0x237 >>> panic+0x1e4/0x41c >>> __warn+0x1d9/0x1f0 >>> report_bug+0x20a/0x2d0 >>> fixup_bug.part.10+0x32/0x80 >>> do_error_trap+0x29c/0x370 >>> invalid_op+0x18/0x20 >>> RIP: 0010:kvm_arch_vcpu_ioctl_run+0x213/0x5d20 >>> RSP: 0018:8801ce197680 EFLAGS: 00010293 >>> RAX: 8801ce588440 RBX: 8801d5b8f000 RCX: 810d4003 >>> RDX: RSI: RDI: 8801ce0e02b8 >>> RBP: 8801ce197a50 R08: 0001 R09: 0001 >>> R10: R11: 0001 R12: >>> R13: 8801ce0e0168 R14: 8801cec10980 R15: 8801ce0e0080 >>> kvm_vcpu_ioctl+0x619/0xf80 >>> do_vfs_ioctl+0x18b/0x13e0 >>> SyS_ioctl+0x7e/0xb0 >>> entry_SYSCALL_64_fastpath+0x1f/0x96 >>> RIP: 0033:0x452879 >>> RSP: 002b:7f4bc97fdbe8 EFLAGS: 0212 ORIG_RAX: 0010 >>> RAX: ffda RBX: 0082 RCX: 00452879 >>> RDX: RSI: ae80 RDI: 0004 >>> RBP: 7ffce1993510 R08: R09: >>> R10: R11: 0212 R12: >>> R13: 7ffce199348f R14: 7f4bc97fe9c0 R15: 0006 >>> Dumping ftrace buffer: >>>(ftrace buffer empty) >>> Kernel Offset: disabled >>> Rebooting in 86400 seconds.. >> >> I will have a look. > > Please have a try. https://lkml.org/lkml/2017/11/20/118 Hi Wanpeng, There is shiny new feature being rolled for syzbot, see "#syz test" here: https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication-with-syzbot Please have a try ;)
Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.
On Fri 17-11-17 09:35:21, Christoph Hellwig wrote: > On Tue, Nov 14, 2017 at 06:37:42AM +0900, Tetsuo Handa wrote: > > Since do_shrink_slab() can reschedule, we cannot protect shrinker_list > > using one RCU section. But using atomic_inc()/atomic_dec() for each > > do_shrink_slab() call will not impact so much. > > But you could use SRCU.. Davidlohr has tried that already http://lkml.kernel.org/r/1434398602.1903.15.ca...@stgolabs.net and failed. Doing SRCU inside core kernel is not seen with a great support... -- Michal Hocko SUSE Labs
Re: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation fails
On 11/19/2017 04:27 PM, Jason Gunthorpe wrote: > On Sat, Nov 18, 2017 at 01:53:49AM +0100, Javier Martinez Canillas wrote: > >> What I fail to understand is why that's not a problem when the TPM spaces >> infrastructure isn't used, tpm_validate_command() function just returns >> true if space is NULL. So when sending command to /dev/tpm0 directly, a >> rogue user-space program can send any arbitrary data to the TPM. > > tpm spaces was designed to allow unprivileged user space access to Ah, I didn't know about that design decision. This isn't documented anywhere AFAICT, it would be nice to add some notes to Documentation/security/tpm/ so people are aware of this. > the TPM so it has additional protection designed to keep the TPM > secure. > > Allowing unprivileged user space to send send garbage to the TPM seems > like a good way to trigger a TPM bug in parsing. > Well, I don't think that unprivileged user-space should have any access to the TPM. Since a rogue user-space can abuse the TPM anyway even when using a well constructed command (which is the only validation that's done IIUC). In other words, only trusted software should have access to the TPM device. I thought the TPM spaces was about exposing a virtualized TPM that didn't have the limitation of only allowing to store a small set of transient objects (so user-space didn't have to deal with the handles flushing and context save/load), rather than relaxing the access control to the TPM. > When spaces are not used /dev/tpm0 is root only and has full > unrestricted access. > The Linux motto is that it should provide mechanisms and not policy, so I wonder if is up to user-space to decide who should access the devices. For example on my Fedora machine, the /dev/tpm* char devices are owned by the "tss" user and group. That's because the tpm2-abrmd package installs an udev rule to change the permissions, since the resource manager is run as the unprivileged tss user. The /dev/tpmrm* on the other hand are owned by root. So on this distro at least, is the opposite of what you described. Having said that, I'm happy to implement the synthesized response when the command is not supported, if that's the correct way to resolve this. > Jason > Best regards, -- Javier Martinez Canillas Software Engineer - Desktop Hardware Enablement Red Hat
Re: [PATCH v1 0/9] perf stat: Enable '--per-thread' on all threads
On Mon, Nov 20, 2017 at 10:43:35PM +0800, Jin Yao wrote: > perf stat --per-thread is useful to break down data per thread. > But it currently requires specifying --pid/--tid to limit it to a process. > > For analysis it would be useful to do it globally for the whole system. I can't compile this: builtin-script.c: In function ‘perf_sample__fprint_metric’: builtin-script.c:1549:2: error: too few arguments to function ‘perf_stat__update_shadow_stats’ perf_stat__update_shadow_stats(evsel, ^~ In file included from builtin-script.c:24:0: util/stat.h:134:6: note: declared here void perf_stat__update_shadow_stats(struct perf_evsel *counter, u64 count, ^~ builtin-script.c:1555:4: error: too few arguments to function ‘perf_stat__print_shadow_stats’ perf_stat__print_shadow_stats(ev2, ^ In file included from builtin-script.c:24:0: util/stat.h:143:6: note: declared here void perf_stat__print_shadow_stats(struct perf_evsel *evsel, ^ mv: cannot stat './.builtin-script.o.tmp': No such file or directory thanks, jirka
[PATCH] net: qmi_wwan: add Dell DW5818, DW5819
Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
series modems which will by default boot with vid 0x413c and pid's
0x81cf, 0x81d0, 0x81d1,0x81d2. Along with qcserial, these modems support
qmi_wwan on the usb interface #12.
Signed-off-by: Shrirang Bagul
---
drivers/net/usb/qmi_wwan.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8d4a6f7cba61..bdf1fae38af2 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1234,6 +1234,10 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x413c, 0x81b3, 8)},/* Dell Wireless 5809e Gobi(TM)
4G LTE Mobile Broadband Card (rev3) */
{QMI_FIXED_INTF(0x413c, 0x81b6, 8)},/* Dell Wireless 5811e */
{QMI_FIXED_INTF(0x413c, 0x81b6, 10)}, /* Dell Wireless 5811e */
+ {QMI_FIXED_INTF(0x413c, 0x81cf, 12)}, /* Dell Wireless 5819 */
+ {QMI_FIXED_INTF(0x413c, 0x81d0, 12)}, /* Dell Wireless 5819 */
+ {QMI_FIXED_INTF(0x413c, 0x81d1, 12)}, /* Dell Wireless 5818 */
+ {QMI_FIXED_INTF(0x413c, 0x81d2, 12)}, /* Dell Wireless 5818 */
{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)},/* HP lt4111 LTE/EV-DO/HSPA+
Gobi 4G Module */
{QMI_FIXED_INTF(0x22de, 0x9061, 3)},/* WeTelecom WPD-600N */
{QMI_FIXED_INTF(0x1e0e, 0x9001, 5)},/* SIMCom 7230E */
--
2.14.1
Re: [PATCH] xfs: fix memory leak in xfs_iext_free_last_leaf
Oops. Looks good: Reviewed-by: Christoph Hellwig
Re: [PATCH 2/6] mmc: tmio: set tmio_mmc_host to driver data
2017-11-20 18:20 GMT+09:00 Wolfram Sang : > Yamada-san, > >> My best guess is unnecessary if-conditional was added >> and overlooked in the review process. > > I agree. > > So, from visual review, most patches look good to me. I will give them > testing on HW this evening and add my Reviewed-by tags then. I'll also > reply to the driver rename thread later today. > > Thanks! > >Wolfram > Last week I was working on the TMIO driver and I have more bug-fix and clean-up patches in hand now. (about 20 patches) The patch order is getting a mess, so I am planning to put all patches in one series. If not in hurry, can you wait for a little? -- Best Regards Masahiro Yamada
Re: [RFC PATCH 1/2] mm: introduce MAP_FIXED_SAFE
On Mon 20-11-17 10:10:32, Florian Weimer wrote:
> On 11/20/2017 09:55 AM, Michal Hocko wrote:
> > On Fri 17-11-17 08:30:48, Florian Weimer wrote:
> > > On 11/16/2017 11:18 AM, Michal Hocko wrote:
> > > > + if (flags & MAP_FIXED_SAFE) {
> > > > + struct vm_area_struct *vma = find_vma(mm, addr);
> > > > +
> > > > + if (vma && vma->vm_start <= addr)
> > > > + return -ENOMEM;
> > > > + }
> > >
> > > Could you pick a different error code which cannot also be caused by a an
> > > unrelated, possibly temporary condition? Maybe EBUSY or EEXIST?
> >
> > Hmm, none of those are described in the man page. I am usually very
> > careful to not add new and potentially unexpected error codes but it is
>
> I think this is a bad idea. It leads to bizarre behavior, like open failing
> with EOVERFLOW with certain namespace configurations (which have nothing to
> do with file sizes).
Ohh, I agree but breaking userspace is, you know, no-no. And an
unexpected error codes can break things terribly.
> Most of the manual pages are incomplete regarding error codes, and with
> seccomp filters and security modules, what error codes you actually get is
> anyone's guess.
>
> > true that a new flag should warrant a new error code. I am not sure
> > which one is more appropriate though. EBUSY suggests that retrying might
> > help which is true only if some other party unmaps the range. So EEXIST
> > would sound more natural.
>
> Sure, EEXIST is completely fine.
OK, I will use it.
> > > This would definitely help with application-based randomization of
> > > mappings,
> > > and there, actual ENOMEM and this error would have to be handled
> > > differently.
> >
> > I see. Could you be more specific about the usecase you have in mind? I
> > would incorporate it into the patch description.
>
> glibc ld.so currently maps DSOs without hints. This means that the kernel
> will map right next to each other, and the offsets between them a completely
> predictable. We would like to change that and supply a random address in a
> window of the address space. If there is a conflict, we do not want the
> kernel to pick a non-random address. Instead, we would try again with a
> random address.
This makes sense to me. Thanks, I will add it to the cover letter.
--
Michal Hocko
SUSE Labs
Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.
On Mon, Nov 20, 2017 at 10:25:26AM +0100, Michal Hocko wrote: > On Fri 17-11-17 09:35:21, Christoph Hellwig wrote: > > On Tue, Nov 14, 2017 at 06:37:42AM +0900, Tetsuo Handa wrote: > > > Since do_shrink_slab() can reschedule, we cannot protect shrinker_list > > > using one RCU section. But using atomic_inc()/atomic_dec() for each > > > do_shrink_slab() call will not impact so much. > > > > But you could use SRCU.. > > Davidlohr has tried that already > http://lkml.kernel.org/r/1434398602.1903.15.ca...@stgolabs.net > and failed. Doing SRCU inside core kernel is not seen with a great > support... I can't actually find any objection in that thread. What's the problem Davidlohr ran into?
[PATCH] eeprom: New ee1004 driver for DDR4 memory
The EEPROMs which hold the SPD data on DDR4 memory modules are no
longer standard AT24C02-compatible EEPROMs. They are 512-byte EEPROMs
which use only 1 I2C address for data access. You need to switch
between the lower page and the upper page of data by sending commands
on the SMBus.
Signed-off-by: Jean Delvare
---
drivers/misc/eeprom/Kconfig | 11 +
drivers/misc/eeprom/Makefile |1
drivers/misc/eeprom/ee1004.c | 281 +++
3 files changed, 293 insertions(+)
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-4.14/drivers/misc/eeprom/ee1004.c 2017-11-19 20:53:48.088700027
+0100
@@ -0,0 +1,281 @@
+/*
+ * ee1004 - driver for DDR4 SPD EEPROMs
+ *
+ * Copyright (C) 2017 Jean Delvare
+ *
+ * Based on the at24 driver:
+ * Copyright (C) 2005-2007 David Brownell
+ * Copyright (C) 2008 Wolfram Sang, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * DDR4 memory modules use special EEPROMs following the Jedec EE1004
+ * specification. These are 512-byte EEPROMs using a single I2C address
+ * in the 0x50-0x57 range for data. One of two 256-byte page is selected
+ * by writing a command to I2C address 0x36 or 0x37 on the same I2C bus.
+ *
+ * Therefore we need to request these 2 additional addresses, and serialize
+ * access to all such EEPROMs with a single mutex.
+ *
+ * We assume it is safe to read up to 32 bytes at once from these EEPROMs.
+ * We use SMBus access even if I2C is available, these EEPROMs are small
+ * enough, and reading from them infrequent enough, that we favor simplicity
+ * over performance.
+ */
+
+#define EE1004_ADDR_SET_PAGE 0x36
+#define EE1004_EEPROM_SIZE 512
+#define EE1004_PAGE_SIZE 256
+#define EE1004_PAGE_SHIFT 8
+
+/*
+ * Mutex protects ee1004_set_page and ee1004_dev_count, and must be held
+ * from page selection to end of read.
+ */
+static DEFINE_MUTEX(ee1004_bus_lock);
+static struct i2c_client *ee1004_set_page[2];
+static unsigned int ee1004_dev_count;
+static int ee1004_current_page;
+
+static const struct i2c_device_id ee1004_ids[] = {
+ { "ee1004", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, ee1004_ids);
+
+/*-*/
+
+static ssize_t ee1004_eeprom_read(struct i2c_client *client, char *buf,
+ unsigned int offset, size_t count)
+{
+ int status;
+
+ if (count > I2C_SMBUS_BLOCK_MAX)
+ count = I2C_SMBUS_BLOCK_MAX;
+ /* Can't cross page boundaries */
+ if (unlikely(offset + count > EE1004_PAGE_SIZE))
+ count = EE1004_PAGE_SIZE - offset;
+
+ status = i2c_smbus_read_i2c_block_data_or_emulated(client, offset,
+ count, buf);
+ dev_dbg(&client->dev, "read %zu@%d --> %d\n", count, offset, status);
+
+ return status;
+}
+
+static ssize_t ee1004_read(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf, loff_t off, size_t count)
+{
+ struct device *dev = kobj_to_dev(kobj);
+ struct i2c_client *client = to_i2c_client(dev);
+ size_t requested = count;
+ int page;
+
+ if (unlikely(!count))
+ return count;
+
+ page = off >> EE1004_PAGE_SHIFT;
+ if (unlikely(page > 1))
+ return 0;
+ off &= (1 << EE1004_PAGE_SHIFT) - 1;
+
+ /*
+* Read data from chip, protecting against concurrent access to
+* other EE1004 SPD EEPROMs on the same adapter.
+*/
+ mutex_lock(&ee1004_bus_lock);
+
+ while (count) {
+ int status;
+
+ /* Select page */
+ if (page != ee1004_current_page) {
+ /* Data is ignored */
+ status = i2c_smbus_write_byte(ee1004_set_page[page],
+ 0x00);
+ if (status < 0) {
+ dev_err(dev, "Failed to select page %d (%d)\n",
+ page, status);
+ mutex_unlock(&ee1004_bus_lock);
+ return status;
+ }
+ dev_dbg(dev, "Selected page %d\n", page);
+ ee1004_current_page = page;
+ }
+
+ status = ee1004_eeprom_read(client, buf, off, count);
+ if (status < 0) {
+ mutex_unlock(&ee1004_bus_lock);
+ return status;
+ }
+
Documentation patch for namespaced file capabilities
Hi Serge, At the moment man-pages lacks documentation of the namespaced file capability feature that you added with commit 8db6c34f1dbc8e06aa016a9b829b06902c3e1340. Would you be able to send a patch describing the feature? Presumably, the patch would be for the capabilities(7) page (or perhaps for the user_namespaces(7) page, if that seems more appropriate), As well as documenting the semantics, it would be good to include an example or two of the notation that is used for the xattr names. Presumably also there will be some changes in userspace tools (setcap/getcap?). Do you know anything about what's happening there? Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
RE: [PATCH v2 1/3] net: ethernet: freescale: simplify fec_reset_phy
From: Richard Leitner Sent: Monday, November 20, 2017 4:34 PM
>The fec_reset_phy function allowed only one execution during probeing.
>To make it more usable move the dt parsing and gpio allocation to the probe
>function. The parameters of the phy reset are added to the fec_enet_private
>struct. As a result the fec_reset_phy function may be called anytime after
>probe.
>
>One checkpatch.pl warning (too long line) is ignored. This is due to the fact a
>string (dt property name) otherwise needs to be split over multiple lines,
>which is counterproductive for the readability.
>
>Signed-off-by: Richard Leitner
>---
It is better to convert to gpio descriptor, and use dts gpio flag as the gpio
polarity instead of extra phy_reset_active_high variable.
Regards,
Andy
> drivers/net/ethernet/freescale/fec.h | 4 ++
> drivers/net/ethernet/freescale/fec_main.c | 88 --
>-
> 2 files changed, 50 insertions(+), 42 deletions(-)
>
>diff --git a/drivers/net/ethernet/freescale/fec.h
>b/drivers/net/ethernet/freescale/fec.h
>index 5385074b3b7d..401c4eabf08a 100644
>--- a/drivers/net/ethernet/freescale/fec.h
>+++ b/drivers/net/ethernet/freescale/fec.h
>@@ -539,6 +539,10 @@ struct fec_enet_private {
> int pause_flag;
> int wol_flag;
> u32 quirks;
>+ int phy_reset;
>+ int phy_reset_duration;
>+ int phy_reset_post_delay;
>+ boolphy_reset_active_high;
>
> struct napi_struct napi;
> int csum_flags;
>diff --git a/drivers/net/ethernet/freescale/fec_main.c
>b/drivers/net/ethernet/freescale/fec_main.c
>index 610573855213..06a7caca0cee 100644
>--- a/drivers/net/ethernet/freescale/fec_main.c
>+++ b/drivers/net/ethernet/freescale/fec_main.c
>@@ -3212,62 +3212,36 @@ static int fec_enet_init(struct net_device *ndev) }
>
> #ifdef CONFIG_OF
>-static int fec_reset_phy(struct platform_device *pdev)
>+static int fec_reset_phy(struct net_device *ndev)
> {
>- int err, phy_reset;
>- bool active_high = false;
>- int msec = 1, phy_post_delay = 0;
>- struct device_node *np = pdev->dev.of_node;
>-
>- if (!np)
>- return 0;
>-
>- err = of_property_read_u32(np, "phy-reset-duration", &msec);
>- /* A sane reset duration should not be longer than 1s */
>- if (!err && msec > 1000)
>- msec = 1;
>+ struct fec_enet_private *fep = netdev_priv(ndev);
>
>- phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0);
>- if (phy_reset == -EPROBE_DEFER)
>- return phy_reset;
>- else if (!gpio_is_valid(phy_reset))
>+ if (!fep->phy_reset)
> return 0;
>
>- err = of_property_read_u32(np, "phy-reset-post-delay",
>&phy_post_delay);
>- /* valid reset duration should be less than 1s */
>- if (!err && phy_post_delay > 1000)
>- return -EINVAL;
>-
>- active_high = of_property_read_bool(np, "phy-reset-active-high");
>+ gpio_set_value_cansleep(fep->phy_reset, fep-
>>phy_reset_active_high);
>
>- err = devm_gpio_request_one(&pdev->dev, phy_reset,
>- active_high ? GPIOF_OUT_INIT_HIGH :
>GPIOF_OUT_INIT_LOW,
>- "phy-reset");
>- if (err) {
>- dev_err(&pdev->dev, "failed to get phy-reset-gpios: %d\n",
>err);
>- return err;
>- }
>-
>- if (msec > 20)
>- msleep(msec);
>+ if (fep->phy_reset_duration > 20)
>+ msleep(fep->phy_reset_duration);
> else
>- usleep_range(msec * 1000, msec * 1000 + 1000);
>+ usleep_range(fep->phy_reset_duration * 1000,
>+ fep->phy_reset_duration * 1000 + 1000);
>
>- gpio_set_value_cansleep(phy_reset, !active_high);
>+ gpio_set_value_cansleep(fep->phy_reset, !fep-
>>phy_reset_active_high);
>
>- if (!phy_post_delay)
>+ if (!fep->phy_reset_post_delay)
> return 0;
>
>- if (phy_post_delay > 20)
>- msleep(phy_post_delay);
>+ if (fep->phy_reset_post_delay > 20)
>+ msleep(fep->phy_reset_post_delay);
> else
>- usleep_range(phy_post_delay * 1000,
>- phy_post_delay * 1000 + 1000);
>+ usleep_range(fep->phy_reset_post_delay * 1000,
>+ fep->phy_reset_post_delay * 1000 + 1000);
>
> return 0;
> }
> #else /* CONFIG_OF */
>-static int fec_reset_phy(struct platform_device *pdev)
>+static int fec_reset_phy(struct net_device *ndev)
> {
> /*
>* In case of platform probe, the reset has been done @@ -3400,6
>+3374,36 @@ fec_probe(struct platform_device *pdev)
> }
> fep->phy_node = phy_node;
>
>+ fep->phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0);
>+ if (gpio_is_valid(fep->phy_reset)) {
>+ ret = of_property_read_u32(np, "phy-reset-duration",
>+ &fep->phy_reset_duration);
>+ /* A sane r
Re: Improving documentation of parent-ID field in /proc/PID/mountinfo
Hello Miklos, On 20 November 2017 at 10:22, Miklos Szeredi wrote: > On Mon, Nov 20, 2017 at 10:07 AM, Michael Kerrisk (man-pages) > wrote: > >> But, the problem is that the existing description is at best misleading: >> >> (2) parent ID: the ID of the parent mount (or of self for >>the top of the mount tree). >> >> That implies that we'll find one line in the list where field 1 and >> field 2 are the same. But we don't, because the mountns rootfs entry >> is not shown in mountinfo. On top of that, the reader is left >> confused, because when they look at mountinfo, they see one entry >> where the parent-ID doesn't exist in the list. So, something more than >> the current text is required. After digging around in the kernel >> source and noticing that chroot() will also cause this scenario, and >> taking into account your comments, I revised the text to: >> >> (2) parent ID: the ID of the parent mount (or of self for >>the root of this mount namespace's mount tree). >> >>If the parent mount point lies outside the process's >>root directory (see chroot(2)), the ID shown here >>won't have a corresponding record in mountinfo whose >>mount ID (field 1) matches this parent mount ID >>(because mount points that lie outside the process's >>root directory are not shown in mountinfo). As a spe‐ >>cial case of this point, the process's root mount >>point may have a parent mount (for the initramfs >>filesystem) that lies outside the process's root >>directory, and an entry for that mount point will not >>appear in mountinfo. >> >> How does that seem? > > Perfect. Thanks! And thanks for the fast review and response. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH v2 06/15] ima: add parser of digest lists metadata
On 11/19/2017 12:23 AM, Mimi Zohar wrote: Hi Serge, On Fri, 2017-11-17 at 22:20 -0600, Serge E. Hallyn wrote: On Tue, Nov 07, 2017 at 11:37:01AM +0100, Roberto Sassu wrote: from a predefined position (/etc/ima/digest_lists/metadata), when rootfs becomes available. Digest lists must be loaded before IMA appraisal is in enforcing mode. I'm sure there's a good reason for it, but this seems weird to me. Why read it from a file on disk instead of accepting it through say a securityfile write? There are two reasons. Digest lists must be loaded before any file is accessed, otherwise IMA will deny the operation if appraisal is in enforcing mode. With digest lists it is possible to appraise files in the initial ram disk without including extended attributes (the default policy excludes those files). The second reason is that appraisal has to be temporarily disabled because the file containing digest list metadata is not signed. The same happens when loading a public key (check ima_load_x509() in ima_init.c). The file containing digest list metadata is not signed because its content depends on the list of installed packages. I thought it is acceptable to load it without verification, as providing the path of digest lists is similar to writing the path of a policy to a securityfs file. The important point is that no digest is added to the hash table without verifying the signature first. The alternative would be to load signed digest lists directly. But, the main issue is that there would be a PCR extend for each digest list, while with digest list metadata there is only one. Assuming that the concept of a white list is something we want to support, then at minimum the list needs to be signed and verified. Instead of defining a new Kconfig pathname option, a securityfs file could read it, like the IMA policy. Both methods are supported (patch 9/15 introduces 'digest_lists' in the securityfs filesystem). The securityfs file can be used to load digest lists for files not in the initial ram disk, and for system updates. Roberto -- HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Bo PENG, Qiuen PENG, Shengli WANG
Re: [PATCH] KVM: VMX: Fix rflags cache during vCPU reset
On 20.11.2017 10:17, Wanpeng Li wrote: > From: Wanpeng Li > > Reported by syzkaller: > >*** Guest State *** >CR0: actual=0x80010031, shadow=0x6010, > gh_mask=fff7 >CR4: actual=0x2061, shadow=0x, > gh_mask=e8f1 >CR3 = 0x2081e000 >RSP = 0xfffa RIP = 0x >RFLAGS=0x00023000 DR7 = 0x0002 >.. >[ cut here ] >WARNING: CPU: 6 PID: 24431 at /home/kernel/linux/arch/x86/kvm//x86.c:7302 > kvm_arch_vcpu_ioctl_run+0x651/0x2ea0 [kvm] >CPU: 6 PID: 24431 Comm: reprotest Tainted: GW OE 4.14.0+ #26 >RIP: 0010:kvm_arch_vcpu_ioctl_run+0x651/0x2ea0 [kvm] >RSP: 0018:880291d179e0 EFLAGS: 00010202 >Call Trace: > ? synchronize_rcu.part.59+0x9b/0xf0 > ? synchronize_rcu_expedited+0xa0/0xa0 > ? kfree_call_rcu+0x20/0x20 > ? trace_raw_output_rcu_utilization+0x70/0x70 > ? kvm_arch_vcpu_runnable+0x220/0x220 [kvm] > ? wait_for_completion+0x222/0x2a0 > ? __wait_rcu_gp+0x1d3/0x230 > ? kvm_vcpu_ioctl+0x479/0x880 [kvm] > kvm_vcpu_ioctl+0x479/0x880 [kvm] > ? kvm_dev_ioctl+0xba0/0xba0 [kvm] > ? pick_next_task_fair+0x629/0xce0 > ? sched_clock+0x1b/0x20 > ? check_chain_key+0x131/0x1e0 > ? lock_acquire+0x2c0/0x2c0 > ? check_flags.part.44+0x62/0x250 > ? check_chain_key+0x131/0x1e0 > ? __lock_acquire+0xd2e/0x1cb0 > do_vfs_ioctl+0x142/0x9a0 > ? ioctl_preallocate+0x150/0x150 > ? lock_acquire+0x2c0/0x2c0 > ? lock_acquire+0x118/0x2c0 > ? __lock_is_held+0x4b/0xe0 > ? __fget+0x16a/0x250 > SyS_ioctl+0x74/0x80 > entry_SYSCALL_64_fastpath+0x23/0x9a > > The syzkaller testcase tries to setup the processor specific debug registers > and configure vCPU for handling guest debug events through > KVM_SET_GUEST_DEBUG. > The KVM_SET_GUEST_DEBUG ioctl will get and set rflags in order to set TF bit > if single step is needed. All regs' caches are reset to avail and > GUEST_RFLAGS > vmcs field is reset to 0x2 during vCPU reset. However, the cache of rflags is > not reset during vCPU reset. The function vmx_get_rflags() returns an unreset > rflags cache value since the cache is marked avail, it is 0 after boot. > Vmentry > fails if the rflags reserved bit 1 is 0. > > This patch fixes it by resetting both the GUEST_RFLAGS vmcs field and its > cache > to 0x2 during vCPU reset. > > Reported-by: Dmitry Vyukov > Cc: Paolo Bonzini > Cc: Radim Krčmář > Cc: Nadav Amit > Cc: Dmitry Vyukov > Signed-off-by: Wanpeng Li > --- > arch/x86/kvm/vmx.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c > index b348920..131fa1c 100644 > --- a/arch/x86/kvm/vmx.c > +++ b/arch/x86/kvm/vmx.c > @@ -5590,6 +5590,7 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool > init_event) > vmcs_write64(GUEST_IA32_DEBUGCTL, 0); > } Indeed, looks like the right think to do when looking at vmx_set_rflags(). Reviewed-by: David Hildenbrand > > + vmx->rflags = 0x02; > vmcs_writel(GUEST_RFLAGS, 0x02); > kvm_rip_write(vcpu, 0xfff0); > > -- Thanks, David / dhildenb
[PATCH] devres: use MACRO instead of function for devm_ioremap_nocache
Define ioremap is ioremap_nocache, so devm_ioremap has the same function
with devm_ioremap_nocache, which may just be killed. However, there
are many places which use devm_ioremap_nocache instead of devm_ioremap.
This patch is to use MACRO for devm_ioremap_nocache, which will reduce
the size of devres.o from 206824 Bytes to 203912 Bytes.
Signed-off-by: Yisheng Xie
---
include/linux/io.h | 3 +--
lib/devres.c | 29 -
2 files changed, 1 insertion(+), 31 deletions(-)
diff --git a/include/linux/io.h b/include/linux/io.h
index 32e30e8..1516ccd 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -75,14 +75,13 @@ static inline void devm_ioport_unmap(struct device *dev,
void __iomem *addr)
void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
resource_size_t size);
-void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
- resource_size_t size);
void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
resource_size_t size);
void devm_iounmap(struct device *dev, void __iomem *addr);
int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
void devm_ioremap_release(struct device *dev, void *res);
+#define devm_ioremap_nocache devm_ioremap
void *devm_memremap(struct device *dev, resource_size_t offset,
size_t size, unsigned long flags);
diff --git a/lib/devres.c b/lib/devres.c
index 5f2aedd..f818fcf 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -44,35 +44,6 @@ void __iomem *devm_ioremap(struct device *dev,
resource_size_t offset,
EXPORT_SYMBOL(devm_ioremap);
/**
- * devm_ioremap_nocache - Managed ioremap_nocache()
- * @dev: Generic device to remap IO address for
- * @offset: Resource address to map
- * @size: Size of map
- *
- * Managed ioremap_nocache(). Map is automatically unmapped on driver
- * detach.
- */
-void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
- resource_size_t size)
-{
- void __iomem **ptr, *addr;
-
- ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
- if (!ptr)
- return NULL;
-
- addr = ioremap_nocache(offset, size);
- if (addr) {
- *ptr = addr;
- devres_add(dev, ptr);
- } else
- devres_free(ptr);
-
- return addr;
-}
-EXPORT_SYMBOL(devm_ioremap_nocache);
-
-/**
* devm_ioremap_wc - Managed ioremap_wc()
* @dev: Generic device to remap IO address for
* @offset: Resource address to map
--
1.7.12.4
Re: [PATCH] net: qmi_wwan: add Dell DW5818, DW5819
Shrirang Bagul writes: > Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74 > series modems which will by default boot with vid 0x413c and pid's > 0x81cf, 0x81d0, 0x81d1,0x81d2. Along with qcserial, these modems support > qmi_wwan on the usb interface #12. NAK, Interace #12 is MBIM, as shown by the device descriptors. Please provide those descriptors and you will see that this interface is clearly a CDC MBIM class interface. Yes, I know these modems probe the control protocol so that you can make QMI work on an MBIM control interface by sending it a QMI request as the first messsage. This is still wrong, abusing a quirky firmware feature. You need to reconfigure the modem for QMI using the Sierra specific AT command or QMI request (tunneled in MBIM!) to properly switch it to QMI mode, which will appear as a vendor specific interface number 8 (and 10 if you enable both QMI functions). Bjørn
Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.
On Mon 20-11-17 01:33:09, Christoph Hellwig wrote: > On Mon, Nov 20, 2017 at 10:25:26AM +0100, Michal Hocko wrote: > > On Fri 17-11-17 09:35:21, Christoph Hellwig wrote: > > > On Tue, Nov 14, 2017 at 06:37:42AM +0900, Tetsuo Handa wrote: > > > > Since do_shrink_slab() can reschedule, we cannot protect shrinker_list > > > > using one RCU section. But using atomic_inc()/atomic_dec() for each > > > > do_shrink_slab() call will not impact so much. > > > > > > But you could use SRCU.. > > > > Davidlohr has tried that already > > http://lkml.kernel.org/r/1434398602.1903.15.ca...@stgolabs.net > > and failed. Doing SRCU inside core kernel is not seen with a great > > support... > > I can't actually find any objection in that thread. What's the problem > Davidlohr ran into? The patch has been dropped because allnoconfig failed to compile back then http://lkml.kernel.org/r/CAP=VYLr0rPWi1aeuk4w1On9CYRNmnEWwJgGtaX=wevgabur...@mail.gmail.com I have problem to find the follow up discussion though. The main argument was that SRC is not generally available and so the core kernel should rely on it. -- Michal Hocko SUSE Labs
Re: Fwd: stable-rc/linux-4.4.y build: 182 builds: 60 failed, 122 passed, 60 errors, 60 warnings (v4.4.99-60-g803704b287d8)
Hi Arnd, Greg,
On 19.11.2017 21:55, Arnd Bergmann wrote:
[Adding the others to cc]
-- Forwarded message --
From: Arnd Bergmann
Date: Sun, Nov 19, 2017 at 9:53 PM
Subject: Re: stable-rc/linux-4.4.y build: 182 builds: 60 failed, 122
passed, 60 errors, 60 warnings (v4.4.99-60-g803704b287d8)
To: "kernelci.org bot" , gregkh
Cc: Tom Gall , Sumit Semwal
, Amit Pundir , Arnd
Bergmann , Anmar Oueja
On Sun, Nov 19, 2017 at 5:35 PM, kernelci.org bot wrote:
stable-rc/linux-4.4.y build: 182 builds: 60 failed, 122 passed, 60 errors, 60
warnings (v4.4.99-60-g803704b287d8)
Full Build Summary:
https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.99-60-g803704b287d8/
Tree: stable-rc
Branch: linux-4.4.y
Git Describe: v4.4.99-60-g803704b287d8
Git Commit: 803704b287d89efcd70fade9e650176282a1d766
Git URL:
http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Built: 4 unique architectures
Build Failures Detected:
mips:gcc version 6.3.0 (GCC)
allnoconfig: FAIL
ar7_defconfig: FAIL
ath79_defconfig: FAIL
bcm47xx_defconfig: FAIL
...
Errors summary:
60 arch/mips/kernel/setup.c:439:8: error: implicit declaration of
function 'PHYS_PFN' [-Werror=implicit-function-declaration]
All mips builds failed with this error, apparently caused by the
backport of d9b5b658210f2 ("MIPS: init: Ensure bootmem does not
corrupt reserved memory").
The following change:
8f235d1a3eb71 ('mm: add PHYS_PFN, use it in __phys_to_pfn()')
needs to be backported prior to d9b5b658210f2 to add the missing macro
definition.
thanks,
Marcin
Re: [patch V2 02/11] LICENSES: Add the GPL 2.0 license
On Sat, 18 Nov 2017, Charlemagne Lasse wrote: > 2017-11-16 19:33 GMT+01:00 Thomas Gleixner : > > Add the full text of the GPL 2.0 license to the kernel tree. It was > > copied directly from: > > > >https://spdx.org/licenses/GPL-2.0.html#licenseText > > > > Add the required tags for reference and tooling. > > > > Signed-off-by: Thomas Gleixner > > NACKed-by: Charlemagne Lasse > > This is neither the GPL-2.0 from https://www.gnu.org/licenses/gpl-2.0.txt > (which you should have used) or > https://spdx.org/licenses/GPL-2.0.html#licenseText > > Please download the correct ASCII version from gnu.org and add your SPDX > info in front of it. But I have also added detailed info about > non-whitespace changes in your patch. Indeed. I messed that up when I noticed that the license from the SPDX site is indeed different from the COPYING file in a few minor aspects. I started to rumage around to find out why and found the matching one on https://opensource.org/licenses/GPL-2.0 which is linked to from the SPDX page. I downloaded that version to check the differences. The opensource page has the original version of the GPLv2 and not the one which got modified by FSF later on without changing the version number. I then decided to copy the text from COPYING, which is the right thing to do as Jonas pointed, got dragged into dealing with a regression and forgot about it. Neither did I update the changelog. Thanks for spotting it! I'll send out a revised version later. Thanks, tglx
RE: [PATCH v2] dt-bindings: mtd: Add sst25vf016b to the list of supported chip names
Dear All,
> Subject: Re: [PATCH v2] dt-bindings: mtd: Add sst25vf016b to the list of
> supported chip names
>
> Hi Cyrille,
>
> On Fri, Nov 17, 2017 at 6:36 PM, Cyrille Pitchen
> wrote:
> > sorry but I won't apply this patch.
> >
> > New values for the 'compatible' DT properties should only be added for
> > memory parts not supporting the JEDEC READ ID (0x9F) command.
>
> I tent to disagree. Documenting part numbers in the DT bindings serves two
> purposes:
> 1. Documenting which parts are supported,
> 2. Allowing checkpatch to validate compatible values in DTS files (see
> below).
that's precisely why we decided to submit the patch, thank you Geert!
>
> Unfortunately the current
> Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> is useless for the latter, as the values listed don't contain the vendor
> prefixes, still causing warnings like
>
> WARNING: DT compatible string "sst,sst25vf016b" appears un-documented
> -- check ./Documentation/devicetree/bindings/
> #79: FILE: arch/arm/boot/dts/r8a7743-iwg20m.dtsi:79:
> + compatible = "sst,sst25vf016b", "jedec,spi-nor";
>
> So I suggest prepending all part number with the appropriate vendor prefixes
> in jedec,spi-nor.txt.
>
> BTW, "sst" (for Silicon Storage Technology) should be added to
> Documentation/devicetree/bindings/vendor-prefixes.txt, too, to avoid another
> warning:
>
> WARNING: DT compatible string vendor "sst" appears un-documented --
> check ./Documentation/devicetree/bindings/vendor-prefixes.txt
> #79: FILE: arch/arm/boot/dts/r8a7743-iwg20m.dtsi:79:
> + compatible = "sst,sst25vf016b", "jedec,spi-nor";
we did submit a patch to fix this ("of: add vendor prefix for Silicon Storage
Technology Inc."):
https://patchwork.kernel.org/patch/9946889/
a while ago
>
> > SST25 memories do support this command hence should use the "jedec,spi-nor"
> > value alone. For historical reasons, some DT nodes set their 'compatible'
> > string to something like ",", "jedec,spi-nor".
> > It should work as expected in most case however I discourage from doing so
> > in new device trees because it may have some side effects especially when
> > the m25p80.c driver is used between the spi-nor.c driver and the SPI
> > controller driver.
>
> It is considered good practice to always have in DT a compatible value for
> the real part number, not just for a generic fallback.
> This allows to discriminate using the real part number, in case an anomaly
> shows up later.
> How else are you gonna handle e.g. a production batch that accidentally
> contains a wrong JEDEC ID? And adding the part-specific compatible value
> after the discovery won't help, as it won't be present in existing DTSes.
Totally agree with Geert.
Thanks,
Fab
>
> > It's all about setting the 2nd parameter of spi_nor_scan(), the 'name'
> > parameter, as NULL when possible. This parameter should be set to a non NULL
> > value only for memories not supporting the JEDEC READ ID op code (0x9F).
> >
> > Best regards,
> >
> > Cyrille
> >
> > Le 24/10/2017 à 15:50, Fabrizio Castro a écrit :
> >> There are a few DT files that make use of sst25vf016b in their
> >> compatible strings, and the driver supports this chip already.
> >> This patch improves the documentation and therefore the result
> >> of ./scripts/checkpatch.pl.
> >>
> >> Signed-off-by: Fabrizio Castro
> >> Signed-off-by: Chris Paterson
> >> Acked-by: Rob Herring
> >> Acked-by: Geert Uytterhoeven
> >> ---
> >> Thank you Rob, thank you Geert, and sorry for the delay on this one.
> >> Here is v2.
> >>
> >> Changes in v2:
> >> * fixed subject prefix
> >> * added changelog
> >>
> >> Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> >> b/Documentation/devicetree/bindings/mtd/jedec,spi-
> nor.txt
> >> index 4cab5d8..bf56d77 100644
> >> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> >> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> >> @@ -31,6 +31,7 @@ Required properties:
> >> s25sl12801
> >> s25fl008k
> >> s25fl064k
> >> + sst25vf016b
> >> sst25vf040b
> >> sst25wf040b
> >> m25p40
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Regi
Re: [RFC PATCH 1/2] mm: introduce MAP_FIXED_SAFE
On 11/20/2017 10:33 AM, Michal Hocko wrote:
On Mon 20-11-17 10:10:32, Florian Weimer wrote:
On 11/20/2017 09:55 AM, Michal Hocko wrote:
On Fri 17-11-17 08:30:48, Florian Weimer wrote:
On 11/16/2017 11:18 AM, Michal Hocko wrote:
+ if (flags & MAP_FIXED_SAFE) {
+ struct vm_area_struct *vma = find_vma(mm, addr);
+
+ if (vma && vma->vm_start <= addr)
+ return -ENOMEM;
+ }
Could you pick a different error code which cannot also be caused by a an
unrelated, possibly temporary condition? Maybe EBUSY or EEXIST?
Hmm, none of those are described in the man page. I am usually very
careful to not add new and potentially unexpected error codes but it is
I think this is a bad idea. It leads to bizarre behavior, like open failing
with EOVERFLOW with certain namespace configurations (which have nothing to
do with file sizes).
Ohh, I agree but breaking userspace is, you know, no-no. And an
unexpected error codes can break things terribly.
On the glibc side, we see a lot of changes in error codes depending on
kernel version, build and run-time configuration. It never occurred to
me that you guys think the precise error code is part of the userspace
ABI. Personally, I even assume that failure itself can disappear at any
time (evidence: the f* functions which accept O_PATH in their non-*at
variants).
Thanks,
Florian
RE: [PATCH v2 3/3] net: ethernet: fec: fix refclk enable for SMSC LAN8710/20
From: Richard Leitner Sent: Monday, November 20, 2017 4:34 PM
>To: f.faine...@gmail.com; Andy Duan ;
>and...@lunn.ch
>Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org;
>richard.leit...@skidata.com
>Subject: [PATCH v2 3/3] net: ethernet: fec: fix refclk enable for SMSC
>LAN8710/20
>
>From: Richard Leitner
>
>Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow turning
>the refclk on and off again during operation (according to their datasheet).
>Nonetheless exactly this behaviour was introduced for power saving reasons
>by commit e8fcfcd5684a ("net: fec: optimize the clock management to save
>power").
>Therefore after enabling the refclk we detect if an affected PHY is attached.
>If
>so reset and initialize it again.
>
>For a better understanding here's a outline of the time response of the clock
>and reset lines before and after this patch:
>
> v--fec_probe() v--fec_enet_open()
> v v
> w/o patch eCLK:
>___|
> w/o patch nRST: __--
> w/o patch CONF:
>___XX___
>
> w/ patch eCLK:
>___|
> w/ patch nRST: __-__---
> w/ patch CONF:
>___XX_XX
> ^ ^
> ^--fec_probe() ^--fec_enet_open()
>
>Generally speaking this issue is only relevant if the ref clk for the PHY is
>generated by the SoC. In our specific case (PCB) this problem does occur at
>about every 10th to 50th POR of an LAN8710 connected to an i.MX6DL SoC.
>The typical symptom of this problem is a "swinging"
>ethernet link. Similar issues were reported by users of the NXP forum:
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F
>%2Fcommunity.nxp.com%2Fthread%2F389902&data=02%7C01%7Cfugang.du
>an%40nxp.com%7C507c7aafbd4744f81ebf08d52ff1acff%7C686ea1d3bc2b4c6f
>a92cd99c5c301635%7C0%7C0%7C636467637399145483&sdata=RNXVGpPrlrcyL
>0SoQl8%2BI0k8Oc8BM0Iwykd1O%2Bjmvcc%3D&reserved=0
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F
>%2Fcommunity.nxp.com%2Fmessage%2F309354&data=02%7C01%7Cfugang.d
>uan%40nxp.com%7C507c7aafbd4744f81ebf08d52ff1acff%7C686ea1d3bc2b4c6
>fa92cd99c5c301635%7C0%7C0%7C636467637399145483&sdata=pjeJEZGuBpb9
>uCMKGr70qa%2FmsNoak6v3nCID2vbNAeg%3D&reserved=0
>With this patch applied the issue didn't occur for at least a few hundret PORs
>of our board.
>
>Fixes: e8fcfcd5684a ("net: fec: optimize the clock management to save
>power")
>Signed-off-by: Richard Leitner
>---
> drivers/net/ethernet/freescale/fec_main.c | 37
>+++
> 1 file changed, 37 insertions(+)
>
>diff --git a/drivers/net/ethernet/freescale/fec_main.c
>b/drivers/net/ethernet/freescale/fec_main.c
>index 06a7caca0cee..52ec9b29a70e 100644
>--- a/drivers/net/ethernet/freescale/fec_main.c
>+++ b/drivers/net/ethernet/freescale/fec_main.c
>@@ -68,6 +68,7 @@
>
> static void set_multicast_list(struct net_device *ndev); static void
>fec_enet_itr_coal_init(struct net_device *ndev);
>+static int fec_reset_phy(struct net_device *ndev);
>
> #define DRIVER_NAME "fec"
>
>@@ -1833,6 +1834,32 @@ static int fec_enet_mdio_write(struct mii_bus *bus,
>int mii_id, int regnum,
> return ret;
> }
>
>+static int fec_enet_clk_ref_enable_reset_phy_quirk(struct net_device
>+*ndev) {
>+ struct phy_device *phy_dev = ndev->phydev;
>+ u32 real_phy_id;
>+ int ret;
>+
>+ /* some PHYs need a reset after the refclk was enabled, so we
>+ * reset them here
>+ */
>+ if (!phy_dev)
>+ return 0;
>+ if (!phy_dev->drv)
>+ return 0;
>+ real_phy_id = phy_dev->drv->phy_id & phy_dev->drv->phy_id_mask;
>+ switch (real_phy_id) {
>+ case 0x0007c0f0: /* SMSC LAN8710/LAN8720 */
Don't hard code here...
I believe there have many other phys also do such operation, hardcode is
unacceptable...
And these code can be put into phy_device.c as common interface.
>+ ret = fec_reset_phy(ndev);
>+ if (ret)
>+ return ret;
>+ ret = phy_init_hw(phy_dev);
>+ if (ret)
>+ return ret;
>+ }
>+ return 0;
>+}
>+
> static int fec_enet_clk_enable(struct net_device *ndev, bool enable) {
> struct fec_enet_private *fep = netdev_priv(ndev); @@ -1862,6
>+1889,10 @@ static int fec_enet_clk_enable(struct net_device *ndev, bool
>enable)
> ret = clk_prepare_enable(fep->clk_ref);
> if (ret)
> goto failed_clk_ref;
>+
>+ ret = fec_enet_clk_ref_enable_reset_phy_quirk(ndev);
>+ if (ret)
>+ netdev_warn(ndev, "Resetting PHY failed, connect
Re: [PATCH] kmemcheck: add scheduling point to kmemleak_scan
Hi Catalin, On 2017/11/18 2:27, Catalin Marinas wrote: > Please fix the subject as the tool is called "kmemleak" rather than > "kmemcheck". Yeah, this really is a terrible typo. > > On Fri, Nov 17, 2017 at 03:03:56PM +0800, Yisheng Xie wrote: >> diff --git a/mm/kmemleak.c b/mm/kmemleak.c >> index e4738d5..e9f2e86 100644 >> --- a/mm/kmemleak.c >> +++ b/mm/kmemleak.c >> @@ -1523,6 +1523,8 @@ static void kmemleak_scan(void) >> if (page_count(page) == 0) >> continue; >> scan_block(page, page + 1, NULL); >> +if (!(pfn % 1024)) >> +cond_resched(); > > For consistency with the other places where we call cond_resched() in > kmemleak, I would use MAX_SCAN_SIZE. Something like > > if (!(pfn % (MAX_SCAN_SIZE / sizeof(page > cont_resched(); Yes, this will keep it consistency with the other places. I will take both of these suggestion in next version. Thanks Yisheng Xie > > Thanks. >
Re: [PATCH -next] fork.c: Check error and return early
On Thu 16-11-17 22:28:08, Marcos Paulo de Souza wrote:
> Thus reducing one indentation level while maintaining the same
> rationale.
>
> Signed-off-by: Marcos Paulo de Souza
looks reasonable to me
Acked-by: Michal Hocko
> ---
> kernel/fork.c | 51 +--
> 1 file changed, 25 insertions(+), 26 deletions(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 3cefe81b50f2..2113e252cb9d 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -2068,6 +2068,8 @@ long _do_fork(unsigned long clone_flags,
> int __user *child_tidptr,
> unsigned long tls)
> {
> + struct completion vfork;
> + struct pid *pid;
> struct task_struct *p;
> int trace = 0;
> long nr;
> @@ -2093,43 +2095,40 @@ long _do_fork(unsigned long clone_flags,
> p = copy_process(clone_flags, stack_start, stack_size,
>child_tidptr, NULL, trace, tls, NUMA_NO_NODE);
> add_latent_entropy();
> +
> + if (IS_ERR(p))
> + return PTR_ERR(p);
> +
> /*
>* Do this prior waking up the new thread - the thread pointer
>* might get invalid after that point, if the thread exits quickly.
>*/
> - if (!IS_ERR(p)) {
> - struct completion vfork;
> - struct pid *pid;
> -
> - trace_sched_process_fork(current, p);
> + trace_sched_process_fork(current, p);
>
> - pid = get_task_pid(p, PIDTYPE_PID);
> - nr = pid_vnr(pid);
> + pid = get_task_pid(p, PIDTYPE_PID);
> + nr = pid_vnr(pid);
>
> - if (clone_flags & CLONE_PARENT_SETTID)
> - put_user(nr, parent_tidptr);
> -
> - if (clone_flags & CLONE_VFORK) {
> - p->vfork_done = &vfork;
> - init_completion(&vfork);
> - get_task_struct(p);
> - }
> + if (clone_flags & CLONE_PARENT_SETTID)
> + put_user(nr, parent_tidptr);
>
> - wake_up_new_task(p);
> + if (clone_flags & CLONE_VFORK) {
> + p->vfork_done = &vfork;
> + init_completion(&vfork);
> + get_task_struct(p);
> + }
>
> - /* forking complete and child started to run, tell ptracer */
> - if (unlikely(trace))
> - ptrace_event_pid(trace, pid);
> + wake_up_new_task(p);
>
> - if (clone_flags & CLONE_VFORK) {
> - if (!wait_for_vfork_done(p, &vfork))
> - ptrace_event_pid(PTRACE_EVENT_VFORK_DONE, pid);
> - }
> + /* forking complete and child started to run, tell ptracer */
> + if (unlikely(trace))
> + ptrace_event_pid(trace, pid);
>
> - put_pid(pid);
> - } else {
> - nr = PTR_ERR(p);
> + if (clone_flags & CLONE_VFORK) {
> + if (!wait_for_vfork_done(p, &vfork))
> + ptrace_event_pid(PTRACE_EVENT_VFORK_DONE, pid);
> }
> +
> + put_pid(pid);
> return nr;
> }
>
> --
> 2.13.6
>
--
Michal Hocko
SUSE Labs
Re: [PATCH for 4.4-stable] KVM: x86: fix singlestepping over syscall
On 16.11.2017 19:07, Paolo Bonzini wrote:
> [ Upstream commit c8401dda2f0a00cd25c0af6a95ed50e478d25de4 ]
>
> TF is handled a bit differently for syscall and sysret, compared
> to the other instructions: TF is checked after the instruction completes,
> so that the OS can disable #DB at a syscall by adding TF to FMASK.
> When the sysret is executed the #DB is taken "as if" the syscall insn
> just completed.
>
> KVM emulates syscall so that it can trap 32-bit syscall on Intel processors.
> Fix the behavior, otherwise you could get #DB on a user stack which is not
> nice. This does not affect Linux guests, as they use an IST or task gate
> for #DB.
>
> This fixes CVE-2017-7518.
>
> Cc: sta...@vger.kernel.org
> Reported-by: Andy Lutomirski
> Signed-off-by: Paolo Bonzini
> Signed-off-by: Radim Krčmář
>
> Conflicts:
> arch/x86/kvm/x86.c
> ---
> arch/x86/include/asm/kvm_emulate.h | 1 +
> arch/x86/kvm/emulate.c | 1 +
> arch/x86/kvm/x86.c | 52
> --
> 3 files changed, 24 insertions(+), 30 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_emulate.h
> b/arch/x86/include/asm/kvm_emulate.h
> index 19d14ac23ef9..fc3c7e49c8e4 100644
> --- a/arch/x86/include/asm/kvm_emulate.h
> +++ b/arch/x86/include/asm/kvm_emulate.h
> @@ -296,6 +296,7 @@ struct x86_emulate_ctxt {
>
> bool perm_ok; /* do not check permissions if true */
> bool ud;/* inject an #UD if host doesn't support insn */
> + bool tf;/* TF value before instruction (after for
> syscall/sysret) */
>
> bool have_exception;
> struct x86_exception exception;
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index 04b2f3cad7ba..684edebb4a0c 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -2726,6 +2726,7 @@ static int em_syscall(struct x86_emulate_ctxt *ctxt)
> ctxt->eflags &= ~(X86_EFLAGS_VM | X86_EFLAGS_IF);
> }
>
> + ctxt->tf = (ctxt->eflags & X86_EFLAGS_TF) != 0;
> return X86EMUL_CONTINUE;
> }
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 8e526c6fd784..3ffd5900da5b 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5095,6 +5095,8 @@ static void init_emulate_ctxt(struct kvm_vcpu *vcpu)
> kvm_x86_ops->get_cs_db_l_bits(vcpu, &cs_db, &cs_l);
>
> ctxt->eflags = kvm_get_rflags(vcpu);
> + ctxt->tf = (ctxt->eflags & X86_EFLAGS_TF) != 0;
> +
> ctxt->eip = kvm_rip_read(vcpu);
> ctxt->mode = (!is_protmode(vcpu)) ? X86EMUL_MODE_REAL :
>(ctxt->eflags & X86_EFLAGS_VM) ? X86EMUL_MODE_VM86 :
> @@ -5315,37 +5317,26 @@ static int kvm_vcpu_check_hw_bp(unsigned long addr,
> u32 type, u32 dr7,
> return dr6;
> }
>
> -static void kvm_vcpu_check_singlestep(struct kvm_vcpu *vcpu, unsigned long
> rflags, int *r)
> +static void kvm_vcpu_do_singlestep(struct kvm_vcpu *vcpu, int *r)
> {
> struct kvm_run *kvm_run = vcpu->run;
>
> - /*
> - * rflags is the old, "raw" value of the flags. The new value has
> - * not been saved yet.
> - *
> - * This is correct even for TF set by the guest, because "the
> - * processor will not generate this exception after the instruction
> - * that sets the TF flag".
> - */
> - if (unlikely(rflags & X86_EFLAGS_TF)) {
> - if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
> - kvm_run->debug.arch.dr6 = DR6_BS | DR6_FIXED_1 |
> - DR6_RTM;
> - kvm_run->debug.arch.pc = vcpu->arch.singlestep_rip;
> - kvm_run->debug.arch.exception = DB_VECTOR;
> - kvm_run->exit_reason = KVM_EXIT_DEBUG;
> - *r = EMULATE_USER_EXIT;
> - } else {
> - vcpu->arch.emulate_ctxt.eflags &= ~X86_EFLAGS_TF;
> - /*
> - * "Certain debug exceptions may clear bit 0-3. The
> - * remaining contents of the DR6 register are never
> - * cleared by the processor".
> - */
> - vcpu->arch.dr6 &= ~15;
> - vcpu->arch.dr6 |= DR6_BS | DR6_RTM;
> - kvm_queue_exception(vcpu, DB_VECTOR);
> - }
> + if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
> + kvm_run->debug.arch.dr6 = DR6_BS | DR6_FIXED_1 | DR6_RTM;
> + kvm_run->debug.arch.pc = vcpu->arch.singlestep_rip;
> + kvm_run->debug.arch.exception = DB_VECTOR;
> + kvm_run->exit_reason = KVM_EXIT_DEBUG;
> + *r = EMULATE_USER_EXIT;
> + } else {
> + vcpu->arch.emulate_ctxt.eflags &= ~X86_EFLAGS_TF;
> + /*
> + * "Certain debug exceptions may clear bit 0-3. The
> + * remaining contents of the DR6 register are never
> +
[PATCH v7 3/5] fw_cfg: do DMA read operation
Modify fw_cfg_read_blob() to use DMA if the device supports it.
Return errors, because the operation may fail.
The DMA operation is expected to run synchronously with today qemu,
but the specification states that it may become async, so we run
"control" field check in a loop for eventual changes.
We may want to switch all the *buf addresses to use only kmalloc'ed
buffers (instead of using stack/image addresses with dma=false).
Signed-off-by: Marc-André Lureau
---
drivers/firmware/qemu_fw_cfg.c | 140 -
1 file changed, 123 insertions(+), 17 deletions(-)
diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c
index 740df0df2260..e0fe6ff037c3 100644
--- a/drivers/firmware/qemu_fw_cfg.c
+++ b/drivers/firmware/qemu_fw_cfg.c
@@ -33,6 +33,8 @@
#include
#include
#include
+#include
+#include
MODULE_AUTHOR("Gabriel L. Somlo ");
MODULE_DESCRIPTION("QEMU fw_cfg sysfs support");
@@ -43,12 +45,25 @@ MODULE_LICENSE("GPL");
#define FW_CFG_ID 0x01
#define FW_CFG_FILE_DIR 0x19
+#define FW_CFG_VERSION_DMA 0x02
+#define FW_CFG_DMA_CTL_ERROR 0x01
+#define FW_CFG_DMA_CTL_READ0x02
+#define FW_CFG_DMA_CTL_SKIP0x04
+#define FW_CFG_DMA_CTL_SELECT 0x08
+#define FW_CFG_DMA_CTL_WRITE 0x10
+
/* size in bytes of fw_cfg signature */
#define FW_CFG_SIG_SIZE 4
/* fw_cfg "file name" is up to 56 characters (including terminating nul) */
#define FW_CFG_MAX_FILE_PATH 56
+/* platform device for dma mapping */
+static struct device *dev;
+
+/* fw_cfg revision attribute, in /sys/firmware/qemu_fw_cfg top-level dir. */
+static u32 fw_cfg_rev;
+
/* fw_cfg file directory entry type */
struct fw_cfg_file {
u32 size;
@@ -57,6 +72,12 @@ struct fw_cfg_file {
char name[FW_CFG_MAX_FILE_PATH];
};
+struct fw_cfg_dma {
+ u32 control;
+ u32 length;
+ u64 address;
+} __packed;
+
/* fw_cfg device i/o register addresses */
static bool fw_cfg_is_mmio;
static phys_addr_t fw_cfg_p_base;
@@ -75,12 +96,79 @@ static inline u16 fw_cfg_sel_endianness(u16 key)
return fw_cfg_is_mmio ? cpu_to_be16(key) : cpu_to_le16(key);
}
+static inline bool fw_cfg_dma_enabled(void)
+{
+ return fw_cfg_rev & FW_CFG_VERSION_DMA && fw_cfg_reg_dma;
+}
+
+/* qemu fw_cfg device is sync today, but spec says it may become async */
+static void fw_cfg_wait_for_control(struct fw_cfg_dma *d, dma_addr_t dma)
+{
+ do {
+ dma_sync_single_for_cpu(dev, dma, sizeof(*d), DMA_FROM_DEVICE);
+ if ((be32_to_cpu(d->control) & ~FW_CFG_DMA_CTL_ERROR) == 0)
+ return;
+
+ usleep_range(50, 100);
+ } while (true);
+}
+
+static ssize_t fw_cfg_dma_transfer(void *address, u32 length, u32 control)
+{
+ dma_addr_t dma_addr = 0;
+ static struct fw_cfg_dma d;
+ dma_addr_t dma;
+ ssize_t ret = length;
+ enum dma_data_direction dir =
+ (control & FW_CFG_DMA_CTL_READ ? DMA_FROM_DEVICE : 0);
+
+ if (address && length) {
+ dma_addr = dma_map_single(dev, address, length, dir);
+ if (dma_mapping_error(NULL, dma_addr)) {
+ WARN(1, "%s: failed to map address\n", __func__);
+ return -EFAULT;
+ }
+ }
+
+ d = (struct fw_cfg_dma) {
+ .address = cpu_to_be64(dma_addr),
+ .length = cpu_to_be32(length),
+ .control = cpu_to_be32(control)
+ };
+
+ dma = dma_map_single(dev, &d, sizeof(d), DMA_BIDIRECTIONAL);
+ if (dma_mapping_error(NULL, dma)) {
+ WARN(1, "%s: failed to map fw_cfg_dma\n", __func__);
+ ret = -EFAULT;
+ goto end;
+ }
+
+ iowrite32be((u64)dma >> 32, fw_cfg_reg_dma);
+ iowrite32be(dma, fw_cfg_reg_dma + 4);
+
+ fw_cfg_wait_for_control(&d, dma);
+
+ if (be32_to_cpu(d.control) & FW_CFG_DMA_CTL_ERROR) {
+ ret = -EIO;
+ }
+
+ dma_unmap_single(dev, dma, sizeof(d), DMA_BIDIRECTIONAL);
+
+end:
+ if (dma_addr)
+ dma_unmap_single(dev, dma_addr, length, dir);
+
+ return ret;
+}
+
/* read chunk of given fw_cfg blob (caller responsible for sanity-check) */
-static inline void fw_cfg_read_blob(u16 key,
- void *buf, loff_t pos, size_t count)
+static ssize_t fw_cfg_read_blob(u16 key,
+ void *buf, loff_t pos, size_t count,
+ bool dma)
{
u32 glk = -1U;
acpi_status status;
+ ssize_t ret = count;
/* If we have ACPI, ensure mutual exclusion against any potential
* device access by the firmware, e.g. via AML methods:
@@ -90,17 +178,36 @@ static inline void fw_cfg_read_blob(u16 key,
/* Should never get here */
WARN(1, "fw_cfg_read_blob: Failed to lock ACPI!\n");
memset(buf, 0, count);
-
[PATCH v7 2/5] fw_cfg: add DMA register
Add an optional kernel module (or command line) parameter
using the following syntax:
[qemu_fw_cfg.]ioport=@[::[:]]
or
[qemu_fw_cfg.]mmio=@[::[:]]
and initializes the register address using given or default offset.
Signed-off-by: Marc-André Lureau
Reviewed-by: Gabriel Somlo
---
drivers/firmware/qemu_fw_cfg.c | 53 --
1 file changed, 41 insertions(+), 12 deletions(-)
diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c
index deb483064f53..740df0df2260 100644
--- a/drivers/firmware/qemu_fw_cfg.c
+++ b/drivers/firmware/qemu_fw_cfg.c
@@ -10,20 +10,21 @@
* and select subsets of aarch64), a Device Tree node (on arm), or using
* a kernel module (or command line) parameter with the following syntax:
*
- * [qemu_fw_cfg.]ioport=@[::]
+ * [qemu_fw_cfg.]ioport=@[::[:]]
* or
- * [qemu_fw_cfg.]mmio=@[::]
+ * [qemu_fw_cfg.]mmio=@[::[:]]
*
* where:
* := size of ioport or mmio range
* := physical base address of ioport or mmio range
* := (optional) offset of control register
* := (optional) offset of data register
+ * := (optional) offset of dma register
*
* e.g.:
- * qemu_fw_cfg.ioport=2@0x510:0:1 (the default on x86)
+ * qemu_fw_cfg.ioport=12@0x510:0:1:4 (the default on x86)
* or
- * qemu_fw_cfg.mmio=0xA@0x902:8:0 (the default on arm)
+ * qemu_fw_cfg.mmio=16@0x902:8:0:16 (the default on arm)
*/
#include
@@ -63,6 +64,7 @@ static resource_size_t fw_cfg_p_size;
static void __iomem *fw_cfg_dev_base;
static void __iomem *fw_cfg_reg_ctrl;
static void __iomem *fw_cfg_reg_data;
+static void __iomem *fw_cfg_reg_dma;
/* atomic access to fw_cfg device (potentially slow i/o, so using mutex) */
static DEFINE_MUTEX(fw_cfg_dev_lock);
@@ -118,12 +120,14 @@ static void fw_cfg_io_cleanup(void)
# if (defined(CONFIG_ARM) || defined(CONFIG_ARM64))
# define FW_CFG_CTRL_OFF 0x08
# define FW_CFG_DATA_OFF 0x00
+# define FW_CFG_DMA_OFF 0x10
# elif (defined(CONFIG_PPC_PMAC) || defined(CONFIG_SPARC32)) /* ppc/mac,sun4m
*/
# define FW_CFG_CTRL_OFF 0x00
# define FW_CFG_DATA_OFF 0x02
# elif (defined(CONFIG_X86) || defined(CONFIG_SPARC64)) /* x86, sun4u */
# define FW_CFG_CTRL_OFF 0x00
# define FW_CFG_DATA_OFF 0x01
+# define FW_CFG_DMA_OFF 0x04
# else
# error "QEMU FW_CFG not available on this architecture!"
# endif
@@ -133,7 +137,7 @@ static void fw_cfg_io_cleanup(void)
static int fw_cfg_do_platform_probe(struct platform_device *pdev)
{
char sig[FW_CFG_SIG_SIZE];
- struct resource *range, *ctrl, *data;
+ struct resource *range, *ctrl, *data, *dma;
/* acquire i/o range details */
fw_cfg_is_mmio = false;
@@ -170,6 +174,7 @@ static int fw_cfg_do_platform_probe(struct platform_device
*pdev)
/* were custom register offsets provided (e.g. on the command line)? */
ctrl = platform_get_resource_byname(pdev, IORESOURCE_REG, "ctrl");
data = platform_get_resource_byname(pdev, IORESOURCE_REG, "data");
+ dma = platform_get_resource_byname(pdev, IORESOURCE_REG, "dma");
if (ctrl && data) {
fw_cfg_reg_ctrl = fw_cfg_dev_base + ctrl->start;
fw_cfg_reg_data = fw_cfg_dev_base + data->start;
@@ -179,6 +184,13 @@ static int fw_cfg_do_platform_probe(struct platform_device
*pdev)
fw_cfg_reg_data = fw_cfg_dev_base + FW_CFG_DATA_OFF;
}
+ if (dma)
+ fw_cfg_reg_dma = fw_cfg_dev_base + dma->start;
+#ifdef FW_CFG_DMA_OFF
+ else
+ fw_cfg_reg_dma = fw_cfg_dev_base + FW_CFG_DMA_OFF;
+#endif
+
/* verify fw_cfg device signature */
fw_cfg_read_blob(FW_CFG_SIGNATURE, sig, 0, FW_CFG_SIG_SIZE);
if (memcmp(sig, "QEMU", FW_CFG_SIG_SIZE) != 0) {
@@ -629,6 +641,7 @@ static struct platform_device *fw_cfg_cmdline_dev;
/* use special scanf/printf modifier for phys_addr_t, resource_size_t */
#define PH_ADDR_SCAN_FMT "@%" __PHYS_ADDR_PREFIX "i%n" \
":%" __PHYS_ADDR_PREFIX "i" \
+":%" __PHYS_ADDR_PREFIX "i%n" \
":%" __PHYS_ADDR_PREFIX "i%n"
#define PH_ADDR_PR_1_FMT "0x%" __PHYS_ADDR_PREFIX "x@" \
@@ -638,12 +651,15 @@ static struct platform_device *fw_cfg_cmdline_dev;
":%" __PHYS_ADDR_PREFIX "u" \
":%" __PHYS_ADDR_PREFIX "u"
+#define PH_ADDR_PR_4_FMT PH_ADDR_PR_3_FMT \
+":%" __PHYS_ADDR_PREFIX "u"
+
static int fw_cfg_cmdline_set(const char *arg, const struct kernel_param *kp)
{
- struct resource res[3] = {};
+ struct resource res[4] = {};
char *str;
phys_addr_t base;
- resource_size_t size, ctrl_off, data_off;
+ resource_size_t size, ctrl_off, data_off, dma_off;
int processed, consumed = 0;
/* only one fw_cfg device can exist system-wide, so if
[PATCH v7 1/5] fw_cfg: fix driver remove
On driver remove(), all objects created during probe() should be
removed, but sysfs qemu_fw_cfg/rev file was left. Also reorder
functions to match probe() error cleanup code.
Signed-off-by: Marc-André Lureau
---
drivers/firmware/qemu_fw_cfg.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c
index 5cfe39f7a45f..deb483064f53 100644
--- a/drivers/firmware/qemu_fw_cfg.c
+++ b/drivers/firmware/qemu_fw_cfg.c
@@ -582,9 +582,10 @@ static int fw_cfg_sysfs_remove(struct platform_device
*pdev)
{
pr_debug("fw_cfg: unloading.\n");
fw_cfg_sysfs_cache_cleanup();
+ sysfs_remove_file(fw_cfg_top_ko, &fw_cfg_rev_attr.attr);
+ fw_cfg_io_cleanup();
fw_cfg_kset_unregister_recursive(fw_cfg_fname_kset);
fw_cfg_kobj_cleanup(fw_cfg_sel_ko);
- fw_cfg_io_cleanup();
return 0;
}
--
2.15.0.277.ga3d2ad2c43
[PATCH v7 5/5] fw_cfg: write vmcoreinfo details
If the "etc/vmcoreinfo" fw_cfg file is present and we are not running
the kdump kernel, write the addr/size of the vmcoreinfo ELF note.
Signed-off-by: Marc-André Lureau
Reviewed-by: Gabriel Somlo
---
drivers/firmware/qemu_fw_cfg.c | 82 +-
1 file changed, 81 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c
index e0fe6ff037c3..66d2fd6e9452 100644
--- a/drivers/firmware/qemu_fw_cfg.c
+++ b/drivers/firmware/qemu_fw_cfg.c
@@ -35,6 +35,8 @@
#include
#include
#include
+#include
+#include
MODULE_AUTHOR("Gabriel L. Somlo ");
MODULE_DESCRIPTION("QEMU fw_cfg sysfs support");
@@ -58,6 +60,8 @@ MODULE_LICENSE("GPL");
/* fw_cfg "file name" is up to 56 characters (including terminating nul) */
#define FW_CFG_MAX_FILE_PATH 56
+#define VMCOREINFO_FORMAT_ELF 0x1
+
/* platform device for dma mapping */
static struct device *dev;
@@ -120,7 +124,8 @@ static ssize_t fw_cfg_dma_transfer(void *address, u32
length, u32 control)
dma_addr_t dma;
ssize_t ret = length;
enum dma_data_direction dir =
- (control & FW_CFG_DMA_CTL_READ ? DMA_FROM_DEVICE : 0);
+ (control & FW_CFG_DMA_CTL_READ ? DMA_FROM_DEVICE : 0) |
+ (control & FW_CFG_DMA_CTL_WRITE ? DMA_TO_DEVICE : 0);
if (address && length) {
dma_addr = dma_map_single(dev, address, length, dir);
@@ -210,6 +215,48 @@ static ssize_t fw_cfg_read_blob(u16 key,
return ret;
}
+#ifdef CONFIG_CRASH_CORE
+/* write chunk of given fw_cfg blob (caller responsible for sanity-check) */
+static ssize_t fw_cfg_write_blob(u16 key,
+void *buf, loff_t pos, size_t count)
+{
+ u32 glk = -1U;
+ acpi_status status;
+ ssize_t ret = count;
+
+ /* If we have ACPI, ensure mutual exclusion against any potential
+* device access by the firmware, e.g. via AML methods:
+*/
+ status = acpi_acquire_global_lock(ACPI_WAIT_FOREVER, &glk);
+ if (ACPI_FAILURE(status) && status != AE_NOT_CONFIGURED) {
+ /* Should never get here */
+ WARN(1, "%s: Failed to lock ACPI!\n", __func__);
+ memset(buf, 0, count);
+ return -EINVAL;
+ }
+
+ mutex_lock(&fw_cfg_dev_lock);
+ if (pos == 0) {
+ ret = fw_cfg_dma_transfer(buf, count, key << 16
+ | FW_CFG_DMA_CTL_SELECT
+ | FW_CFG_DMA_CTL_WRITE);
+ } else {
+ iowrite16(fw_cfg_sel_endianness(key), fw_cfg_reg_ctrl);
+ ret = fw_cfg_dma_transfer(NULL, pos, FW_CFG_DMA_CTL_SKIP);
+ if (ret < 0)
+ goto end;
+ ret = fw_cfg_dma_transfer(buf, count, FW_CFG_DMA_CTL_WRITE);
+ }
+
+end:
+ mutex_unlock(&fw_cfg_dev_lock);
+
+ acpi_release_global_lock(glk);
+
+ return ret;
+}
+#endif /* CONFIG_CRASH_CORE */
+
/* clean up fw_cfg device i/o */
static void fw_cfg_io_cleanup(void)
{
@@ -328,6 +375,32 @@ struct fw_cfg_sysfs_entry {
struct list_head list;
};
+#ifdef CONFIG_CRASH_CORE
+static ssize_t write_vmcoreinfo(const struct fw_cfg_file *f)
+{
+ struct vmci {
+ __le16 host_format;
+ __le16 guest_format;
+ __le32 size;
+ __le64 paddr;
+ } __packed;
+ static struct vmci data;
+ ssize_t ret;
+
+ data = (struct vmci) {
+ .guest_format = cpu_to_le16(VMCOREINFO_FORMAT_ELF),
+ .size = cpu_to_le32(VMCOREINFO_NOTE_SIZE),
+ .paddr = cpu_to_le64(paddr_vmcoreinfo_note())
+ };
+ /* spare ourself reading host format support for now since we
+* don't know what else to format - host may ignore ours
+*/
+ ret = fw_cfg_write_blob(f->select, &data, 0, sizeof(struct vmci));
+
+ return ret;
+}
+#endif /* CONFIG_CRASH_CORE */
+
/* get fw_cfg_sysfs_entry from kobject member */
static inline struct fw_cfg_sysfs_entry *to_entry(struct kobject *kobj)
{
@@ -567,6 +640,13 @@ static int fw_cfg_register_file(const struct fw_cfg_file
*f)
int err;
struct fw_cfg_sysfs_entry *entry;
+#ifdef CONFIG_CRASH_CORE
+ if (strcmp(f->name, "etc/vmcoreinfo") == 0 && !is_kdump_kernel()) {
+ if (write_vmcoreinfo(f) < 0)
+ pr_warn("fw_cfg: failed to write vmcoreinfo");
+ }
+#endif
+
/* allocate new entry */
entry = kzalloc(sizeof(*entry), GFP_KERNEL);
if (!entry)
--
2.15.0.277.ga3d2ad2c43
[PATCH v7 0/5] fw_cfg: add DMA operations & etc/vmcoreinfo support
Hi, This series adds DMA operations support to the qemu fw_cfg kernel module and populates "etc/vmcoreinfo" with vmcoreinfo location details. Note: the support for this entry handling has been merged for upcoming qemu release (2.11). v7: - add a patch to fix driver remove() - remove DMA operatiom timeout (qemu finishes sync today) - synchronize the DMA transfer before reading from CPU - removed kmalloc() use static allocation instead - drop some r-b tags v6: - change acpi_acquire_global_lock() error to return EINVAL (instead of EBUSY) - replace 0 as pointer argument for NULL - add Gabriel r-b/a-b tags v5: - resent to CC kdump people on the paddr_vmcoreinfo_note() export patch v4: - export paddr_vmcoreinfo_note() to fix fw_cfg.ko build - fix build with !CONFIG_CRASH_CORE - replace the unbounded yield() loop with a usleep_range() loop and a 200ms timeout - do not write vmcoreinfo entry when running the kdump kernel (D. Hatayama) - drop the experimental sysfs write support patch from this series v3: (thanks kbuild) - add "fw_cfg: fix the command line module name" patch - fix build of "fw_cfg: add DMA register" with CONFIG_FW_CFG_SYSFS_CMDLINE=y - fix 'Wshift-count-overflow' v2: - use platform device for dma mapping - add etc/vmcoreinfo patch - some code cleanups Marc-André Lureau (5): fw_cfg: fix driver remove fw_cfg: add DMA register fw_cfg: do DMA read operation crash: export paddr_vmcoreinfo_note() fw_cfg: write vmcoreinfo details drivers/firmware/qemu_fw_cfg.c | 276 - kernel/crash_core.c| 1 + 2 files changed, 247 insertions(+), 30 deletions(-) -- 2.15.0.277.ga3d2ad2c43
[PATCH v7 4/5] crash: export paddr_vmcoreinfo_note()
The following patch is going to use the symbol from the fw_cfg module,
to call the function and write the note location details in the
vmcoreinfo entry, so qemu can produce dumps with the vmcoreinfo note.
CC: Andrew Morton
CC: Baoquan He
CC: Dave Young
CC: Dave Young
CC: Hari Bathini
CC: Tony Luck
CC: Vivek Goyal
Signed-off-by: Marc-André Lureau
Acked-by: Gabriel Somlo
---
kernel/crash_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index b3663896278e..2394f0501c65 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -376,6 +376,7 @@ phys_addr_t __weak paddr_vmcoreinfo_note(void)
{
return __pa(vmcoreinfo_note);
}
+EXPORT_SYMBOL(paddr_vmcoreinfo_note);
static int __init crash_save_vmcoreinfo_init(void)
{
--
2.15.0.277.ga3d2ad2c43
Re: [PATCH] net: qmi_wwan: add Dell DW5818, DW5819
On Mon, 2017-11-20 at 10:41 +0100, Bjørn Mork wrote: > Shrirang Bagul writes: > > > Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74 > > series modems which will by default boot with vid 0x413c and pid's > > 0x81cf, 0x81d0, 0x81d1,0x81d2. Along with qcserial, these modems support > > qmi_wwan on the usb interface #12. > > NAK, > > Interace #12 is MBIM, as shown by the device descriptors. Please provide > those descriptors and you will see that this interface is clearly a CDC > MBIM class interface. > > Yes, I know these modems probe the control protocol so that you can make > QMI work on an MBIM control interface by sending it a QMI request as the > first messsage. This is still wrong, abusing a quirky firmware > feature. > > You need to reconfigure the modem for QMI using the Sierra specific AT > command or QMI request (tunneled in MBIM!) to properly switch it to QMI > mode, which will appear as a vendor specific interface number 8 (and 10 > if you enable both QMI functions). Understood. Needs more work, will resend with fixes. - Shrirang > > > > > > Bjørn signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 3/3] net: ethernet: fec: fix refclk enable for SMSC LAN8710/20
On 11/20/2017 10:47 AM, Andy Duan wrote:
> From: Richard Leitner Sent: Monday, November 20, 2017 4:34
> PM
>> To: f.faine...@gmail.com; Andy Duan ;
>> and...@lunn.ch
>> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> richard.leit...@skidata.com
>> Subject: [PATCH v2 3/3] net: ethernet: fec: fix refclk enable for SMSC
>> LAN8710/20
>>
>> From: Richard Leitner
>>
>> Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow turning
>> the refclk on and off again during operation (according to their datasheet).
>> Nonetheless exactly this behaviour was introduced for power saving reasons
>> by commit e8fcfcd5684a ("net: fec: optimize the clock management to save
>> power").
>> Therefore after enabling the refclk we detect if an affected PHY is
>> attached. If
>> so reset and initialize it again.
...
>> +static int fec_enet_clk_ref_enable_reset_phy_quirk(struct net_device
>> +*ndev) {
>> +struct phy_device *phy_dev = ndev->phydev;
>> +u32 real_phy_id;
>> +int ret;
>> +
>> +/* some PHYs need a reset after the refclk was enabled, so we
>> + * reset them here
>> + */
>> +if (!phy_dev)
>> +return 0;
>> +if (!phy_dev->drv)
>> +return 0;
>> +real_phy_id = phy_dev->drv->phy_id & phy_dev->drv->phy_id_mask;
>> +switch (real_phy_id) {
>> +case 0x0007c0f0: /* SMSC LAN8710/LAN8720 */
>
> Don't hard code here...
> I believe there have many other phys also do such operation, hardcode is
> unacceptable...
>
> And these code can be put into phy_device.c as common interface.
Ok. Thank you for the feedback.
So it would be fine to hardcode the affected phy_id's in a common
function in phy_device.c?
Another possible solution that came to my mind is to add a flag called
something like "PHY_RST_AFTER_CLK_EN" to the flags variable in struct
phy_driver. This flag could then be set in the smsc PHY driver for
affected PHYs.
Then instead of comparing the phy_id in the MAC driver this flag could
be checked:
if (phydev->drv->flags & PHY_RST_AFTER_CLK_EN) {
ret = fec_reset_phy(ndev);
...
}
Would checking the flag be OK in fec_main.c?
What would be the "better" approach?
>
>> +ret = fec_reset_phy(ndev);
>> +if (ret)
>> +return ret;
>> +ret = phy_init_hw(phy_dev);
>> +if (ret)
>> +return ret;
>> +}
>> +return 0;
>> +}
>> +
>> static int fec_enet_clk_enable(struct net_device *ndev, bool enable) {
>> struct fec_enet_private *fep = netdev_priv(ndev); @@ -1862,6
>> +1889,10 @@ static int fec_enet_clk_enable(struct net_device *ndev, bool
>> enable)
>> ret = clk_prepare_enable(fep->clk_ref);
>> if (ret)
>> goto failed_clk_ref;
>> +
>> +ret = fec_enet_clk_ref_enable_reset_phy_quirk(ndev);
>> +if (ret)
>> +netdev_warn(ndev, "Resetting PHY failed, connection
>> may be
>> +unstable\n");
>> } else {
>> clk_disable_unprepare(fep->clk_ahb);
>> clk_disable_unprepare(fep->clk_enet_out);
>> @@ -2860,11 +2891,17 @@ fec_enet_open(struct net_device *ndev)
>> if (ret)
>> goto err_enet_mii_probe;
>>
>> +/* as the PHY is connected now, trigger the reset quirk again */
>> +ret = fec_enet_clk_ref_enable_reset_phy_quirk(ndev);
>> +if (ret)
>> +netdev_warn(ndev, "Resetting PHY failed, connection may be
>> +unstable\n");
>> +
>> if (fep->quirks & FEC_QUIRK_ERR006687)
>> imx6q_cpuidle_fec_irqs_used();
>>
>> napi_enable(&fep->napi);
>> phy_start(ndev->phydev);
>> +
>
> No need blank line here...
>> netif_tx_start_all_queues(ndev);
>>
>> device_set_wakeup_enable(&ndev->dev, fep->wol_flag &
>> --
>> 2.11.0
Re: [PATCH v2] dt-bindings: mtd: Add sst25vf016b to the list of supported chip names
Hi Fabrizio,
On Mon, Nov 20, 2017 at 10:43 AM, Fabrizio Castro
wrote:
>> On Fri, Nov 17, 2017 at 6:36 PM, Cyrille Pitchen
>> wrote:
>> BTW, "sst" (for Silicon Storage Technology) should be added to
>> Documentation/devicetree/bindings/vendor-prefixes.txt, too, to avoid another
>> warning:
>>
>> WARNING: DT compatible string vendor "sst" appears un-documented --
>> check ./Documentation/devicetree/bindings/vendor-prefixes.txt
>> #79: FILE: arch/arm/boot/dts/r8a7743-iwg20m.dtsi:79:
>> + compatible = "sst,sst25vf016b", "jedec,spi-nor";
>
> we did submit a patch to fix this ("of: add vendor prefix for Silicon Storage
> Technology Inc."):
> https://patchwork.kernel.org/patch/9946889/
>
> a while ago
And it is queued in dt-rh/for-next (I thought I had that tree included, but
apparently I hadn't. Fixed ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v2 2/2] pinctrl: meson-axg: Add new pinctrl driver for Meson AXG SoC
From: Xingyu Chen
Add new pinctrl driver for Amlogic's Meson-AXG SoC.
Reviewed-by: Neil Armstrong
Signed-off-by: Xingyu Chen
Signed-off-by: Yixun Lan
---
drivers/pinctrl/meson/Kconfig | 6 +
drivers/pinctrl/meson/Makefile| 1 +
drivers/pinctrl/meson/pinctrl-meson-axg.c | 975 ++
include/dt-bindings/gpio/meson-axg-gpio.h | 116
4 files changed, 1098 insertions(+)
create mode 100644 drivers/pinctrl/meson/pinctrl-meson-axg.c
create mode 100644 include/dt-bindings/gpio/meson-axg-gpio.h
diff --git a/drivers/pinctrl/meson/Kconfig b/drivers/pinctrl/meson/Kconfig
index fe5e6ca88412..c80951d6caff 100644
--- a/drivers/pinctrl/meson/Kconfig
+++ b/drivers/pinctrl/meson/Kconfig
@@ -38,6 +38,12 @@ config PINCTRL_MESON_GXL
config PINCTRL_MESON8_PMX
bool
+config PINCTRL_MESON_AXG
+ bool "Meson axg Soc pinctrl driver"
+ depends on ARM64
+ select PINCTRL_MESON_AXG_PMX
+ default y
+
config PINCTRL_MESON_AXG_PMX
bool
diff --git a/drivers/pinctrl/meson/Makefile b/drivers/pinctrl/meson/Makefile
index 8de839512677..3c6580c2d9d7 100644
--- a/drivers/pinctrl/meson/Makefile
+++ b/drivers/pinctrl/meson/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_PINCTRL_MESON8B) += pinctrl-meson8b.o
obj-$(CONFIG_PINCTRL_MESON_GXBB) += pinctrl-meson-gxbb.o
obj-$(CONFIG_PINCTRL_MESON_GXL) += pinctrl-meson-gxl.o
obj-$(CONFIG_PINCTRL_MESON_AXG_PMX) += pinctrl-meson-axg-pmx.o
+obj-$(CONFIG_PINCTRL_MESON_AXG) += pinctrl-meson-axg.o
diff --git a/drivers/pinctrl/meson/pinctrl-meson-axg.c
b/drivers/pinctrl/meson/pinctrl-meson-axg.c
new file mode 100644
index ..a1a7d42afd42
--- /dev/null
+++ b/drivers/pinctrl/meson/pinctrl-meson-axg.c
@@ -0,0 +1,975 @@
+/*
+ * Pin controller and GPIO driver for Amlogic Meson AXG SoC.
+ *
+ * Copyright (c) 2017 Amlogic, Inc. All rights reserved.
+ * Author: Xingyu Chen
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ or MIT)
+ */
+
+#include
+#include "pinctrl-meson.h"
+#include "pinctrl-meson-axg-pmx.h"
+
+static const struct pinctrl_pin_desc meson_axg_periphs_pins[] = {
+ MESON_PIN(GPIOZ_0),
+ MESON_PIN(GPIOZ_1),
+ MESON_PIN(GPIOZ_2),
+ MESON_PIN(GPIOZ_3),
+ MESON_PIN(GPIOZ_4),
+ MESON_PIN(GPIOZ_5),
+ MESON_PIN(GPIOZ_6),
+ MESON_PIN(GPIOZ_7),
+ MESON_PIN(GPIOZ_8),
+ MESON_PIN(GPIOZ_9),
+ MESON_PIN(GPIOZ_10),
+ MESON_PIN(BOOT_0),
+ MESON_PIN(BOOT_1),
+ MESON_PIN(BOOT_2),
+ MESON_PIN(BOOT_3),
+ MESON_PIN(BOOT_4),
+ MESON_PIN(BOOT_5),
+ MESON_PIN(BOOT_6),
+ MESON_PIN(BOOT_7),
+ MESON_PIN(BOOT_8),
+ MESON_PIN(BOOT_9),
+ MESON_PIN(BOOT_10),
+ MESON_PIN(BOOT_11),
+ MESON_PIN(BOOT_12),
+ MESON_PIN(BOOT_13),
+ MESON_PIN(BOOT_14),
+ MESON_PIN(GPIOA_0),
+ MESON_PIN(GPIOA_1),
+ MESON_PIN(GPIOA_2),
+ MESON_PIN(GPIOA_3),
+ MESON_PIN(GPIOA_4),
+ MESON_PIN(GPIOA_5),
+ MESON_PIN(GPIOA_6),
+ MESON_PIN(GPIOA_7),
+ MESON_PIN(GPIOA_8),
+ MESON_PIN(GPIOA_9),
+ MESON_PIN(GPIOA_10),
+ MESON_PIN(GPIOA_11),
+ MESON_PIN(GPIOA_12),
+ MESON_PIN(GPIOA_13),
+ MESON_PIN(GPIOA_14),
+ MESON_PIN(GPIOA_15),
+ MESON_PIN(GPIOA_16),
+ MESON_PIN(GPIOA_17),
+ MESON_PIN(GPIOA_18),
+ MESON_PIN(GPIOA_19),
+ MESON_PIN(GPIOA_20),
+ MESON_PIN(GPIOX_0),
+ MESON_PIN(GPIOX_1),
+ MESON_PIN(GPIOX_2),
+ MESON_PIN(GPIOX_3),
+ MESON_PIN(GPIOX_4),
+ MESON_PIN(GPIOX_5),
+ MESON_PIN(GPIOX_6),
+ MESON_PIN(GPIOX_7),
+ MESON_PIN(GPIOX_8),
+ MESON_PIN(GPIOX_9),
+ MESON_PIN(GPIOX_10),
+ MESON_PIN(GPIOX_11),
+ MESON_PIN(GPIOX_12),
+ MESON_PIN(GPIOX_13),
+ MESON_PIN(GPIOX_14),
+ MESON_PIN(GPIOX_15),
+ MESON_PIN(GPIOX_16),
+ MESON_PIN(GPIOX_17),
+ MESON_PIN(GPIOX_18),
+ MESON_PIN(GPIOX_19),
+ MESON_PIN(GPIOX_20),
+ MESON_PIN(GPIOX_21),
+ MESON_PIN(GPIOX_22),
+ MESON_PIN(GPIOY_0),
+ MESON_PIN(GPIOY_1),
+ MESON_PIN(GPIOY_2),
+ MESON_PIN(GPIOY_3),
+ MESON_PIN(GPIOY_4),
+ MESON_PIN(GPIOY_5),
+ MESON_PIN(GPIOY_6),
+ MESON_PIN(GPIOY_7),
+ MESON_PIN(GPIOY_8),
+ MESON_PIN(GPIOY_9),
+ MESON_PIN(GPIOY_10),
+ MESON_PIN(GPIOY_11),
+ MESON_PIN(GPIOY_12),
+ MESON_PIN(GPIOY_13),
+ MESON_PIN(GPIOY_14),
+ MESON_PIN(GPIOY_15),
+};
+
+static const struct pinctrl_pin_desc meson_axg_aobus_pins[] = {
+ MESON_PIN(GPIOAO_0),
+ MESON_PIN(GPIOAO_1),
+ MESON_PIN(GPIOAO_2),
+ MESON_PIN(GPIOAO_3),
+ MESON_PIN(GPIOAO_4),
+ MESON_PIN(GPIOAO_5),
+ MESON_PIN(GPIOAO_6),
+ MESON_PIN(GPIOAO_7),
+ MESON_PIN(GPIOAO_8),
+ MESON_PIN(GPIOAO_9),
+ MESON_PIN(GPIOAO_10),
+ MESON_PIN(GPIOAO_11),
+ MESON_PIN(GPIOAO_12),
+ ME
[PATCH v2 0/2] add pinctrl driver for Meson-AXG SoC
This patchset adds pinctrl support for the Amlogic's Meson-AXG SoC. While the gpio and pin configuration part is the same the as previous meson SoCs, the pinmux part is different. This requires slightly different pinmux operations along with the actual pinctrl driver description. Changes since v1 at [1]: -- Rename i2c_m0 to i2c0 style (no logic changed) -- Rename uart_tx_ao_XX to uart_ao_tx, etc .. (no logic changed) -- Separate DT part patches -- Add Neil Armstrong's Ack [1] http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005270.html http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005271.html http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005272.html http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005273.html http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005274.html Xingyu Chen (2): pinctrl: meson-axg: Introduce a pinctrl pinmux ops for Meson-AXG SoC pinctrl: meson-axg: Add new pinctrl driver for Meson AXG SoC drivers/pinctrl/meson/Kconfig | 9 + drivers/pinctrl/meson/Makefile| 2 + drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c | 118 drivers/pinctrl/meson/pinctrl-meson-axg-pmx.h | 62 ++ drivers/pinctrl/meson/pinctrl-meson-axg.c | 975 ++ drivers/pinctrl/meson/pinctrl-meson.h | 1 + include/dt-bindings/gpio/meson-axg-gpio.h | 116 +++ 7 files changed, 1283 insertions(+) create mode 100644 drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c create mode 100644 drivers/pinctrl/meson/pinctrl-meson-axg-pmx.h create mode 100644 drivers/pinctrl/meson/pinctrl-meson-axg.c create mode 100644 include/dt-bindings/gpio/meson-axg-gpio.h -- 2.15.0
[PATCH v2 0/2] dt: add pinctrl driver for Meson-AXG SoC
This is DT part patchset for adding pinctrl support for the Amlogic's Meson-AXG SoC. Changes since v1 at [1]: -- Separate DT part patches -- Add Neil Armstrong's Ack [1] http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005270.html http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005271.html http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005272.html http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005273.html http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005274.html Xingyu Chen (2): documentation: Add compatibles for Amlogic Meson AXG pin controllers ARM64: dts: meson-axg: add pinctrl DT info for Meson-AXG SoC .../devicetree/bindings/pinctrl/meson,pinctrl.txt | 2 + arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 44 ++ 2 files changed, 46 insertions(+) -- 2.15.0
[PATCH v2 1/2] documentation: Add compatibles for Amlogic Meson AXG pin controllers
From: Xingyu Chen Add compatibles for Amlogic Meson AXG pin controllers Reviewed-by: Neil Armstrong Signed-off-by: Xingyu Chen Signed-off-by: Yixun Lan --- Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt index 2392557ede27..2c12f9789116 100644 --- a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt @@ -9,6 +9,8 @@ Required properties for the root node: "amlogic,meson-gxbb-aobus-pinctrl" "amlogic,meson-gxl-periphs-pinctrl" "amlogic,meson-gxl-aobus-pinctrl" + "amlogic,meson-axg-periphs-pinctrl" + "amlogic,meson-axg-aobus-pinctrl" - reg: address and size of registers controlling irq functionality === GPIO sub-nodes === -- 2.15.0
[PATCH v2 1/2] pinctrl: meson-axg: Introduce a pinctrl pinmux ops for Meson-AXG SoC
From: Xingyu Chen
The pin controller has been updated in the Amlogic Meson AXG series,
which use continuous 4-bit register to select function for each pin.
In order to support this, a new pinmux operations "meson_axg_pmx_ops"
has been added.
Reviewed-by: Neil Armstrong
Signed-off-by: Xingyu Chen
Signed-off-by: Yixun Lan
---
drivers/pinctrl/meson/Kconfig | 3 +
drivers/pinctrl/meson/Makefile| 1 +
drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c | 118 ++
drivers/pinctrl/meson/pinctrl-meson-axg-pmx.h | 62 ++
drivers/pinctrl/meson/pinctrl-meson.h | 1 +
5 files changed, 185 insertions(+)
create mode 100644 drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c
create mode 100644 drivers/pinctrl/meson/pinctrl-meson-axg-pmx.h
diff --git a/drivers/pinctrl/meson/Kconfig b/drivers/pinctrl/meson/Kconfig
index 1a51778759ea..fe5e6ca88412 100644
--- a/drivers/pinctrl/meson/Kconfig
+++ b/drivers/pinctrl/meson/Kconfig
@@ -38,4 +38,7 @@ config PINCTRL_MESON_GXL
config PINCTRL_MESON8_PMX
bool
+config PINCTRL_MESON_AXG_PMX
+ bool
+
endif
diff --git a/drivers/pinctrl/meson/Makefile b/drivers/pinctrl/meson/Makefile
index cbd47bb74549..8de839512677 100644
--- a/drivers/pinctrl/meson/Makefile
+++ b/drivers/pinctrl/meson/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_PINCTRL_MESON8) += pinctrl-meson8.o
obj-$(CONFIG_PINCTRL_MESON8B) += pinctrl-meson8b.o
obj-$(CONFIG_PINCTRL_MESON_GXBB) += pinctrl-meson-gxbb.o
obj-$(CONFIG_PINCTRL_MESON_GXL) += pinctrl-meson-gxl.o
+obj-$(CONFIG_PINCTRL_MESON_AXG_PMX) += pinctrl-meson-axg-pmx.o
diff --git a/drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c
b/drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c
new file mode 100644
index ..e8931d9cf863
--- /dev/null
+++ b/drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c
@@ -0,0 +1,118 @@
+/*
+ * Second generation of pinmux driver for Amlogic Meson-AXG SoC.
+ *
+ * Copyright (c) 2017 Baylibre SAS.
+ * Author: Jerome Brunet
+ *
+ * Copyright (c) 2017 Amlogic, Inc. All rights reserved.
+ * Author: Xingyu Chen
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ or MIT)
+ */
+
+/*
+ * This new generation of pinctrl IP is mainly adopted by the
+ * Meson-AXG SoC and later series, which use 4-width continuous
+ * register bit to select the function for each pin.
+ *
+ * The value 0 is always selecting the GPIO mode, while other
+ * values (start from 1) for selecting the function mode.
+ */
+#include
+#include
+#include
+#include
+
+#include "pinctrl-meson.h"
+#include "pinctrl-meson-axg-pmx.h"
+
+static int meson_axg_pmx_get_bank(struct meson_pinctrl *pc,
+ unsigned int pin,
+ struct meson_pmx_bank **bank)
+{
+ int i;
+ struct meson_axg_pmx_data *pmx = pc->data->pmx_data;
+
+ for (i = 0; i < pmx->num_pmx_banks; i++)
+ if (pin >= pmx->pmx_banks[i].first &&
+ pin <= pmx->pmx_banks[i].last) {
+ *bank = &pmx->pmx_banks[i];
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+static int meson_pmx_calc_reg_and_offset(struct meson_pmx_bank *bank,
+ unsigned int pin, unsigned int *reg,
+ unsigned int *offset)
+{
+ int shift;
+
+ shift = pin - bank->first;
+
+ *reg = bank->reg + (bank->offset + (shift << 2)) / 32;
+ *offset = (bank->offset + (shift << 2)) % 32;
+
+ return 0;
+}
+
+static int meson_axg_pmx_update_function(struct meson_pinctrl *pc,
+ unsigned int pin, unsigned int func)
+{
+ int ret;
+ int reg;
+ int offset;
+ struct meson_pmx_bank *bank;
+
+ ret = meson_axg_pmx_get_bank(pc, pin, &bank);
+ if (ret)
+ return ret;
+
+ meson_pmx_calc_reg_and_offset(bank, pin, ®, &offset);
+
+ ret = regmap_update_bits(pc->reg_mux, reg << 2,
+ 0xf << offset, (func & 0xf) << offset);
+
+ return ret;
+}
+
+static int meson_axg_pmx_set_mux(struct pinctrl_dev *pcdev,
+ unsigned int func_num, unsigned int group_num)
+{
+ int i;
+ int ret;
+ struct meson_pinctrl *pc = pinctrl_dev_get_drvdata(pcdev);
+ struct meson_pmx_func *func = &pc->data->funcs[func_num];
+ struct meson_pmx_group *group = &pc->data->groups[group_num];
+ struct meson_pmx_axg_data *pmx_data =
+ (struct meson_pmx_axg_data *)group->data;
+
+ dev_dbg(pc->dev, "enable function %s, group %s\n", func->name,
+ group->name);
+
+ for (i = 0; i < group->num_pins; i++) {
+ ret = meson_axg_pmx_update_function(pc, group->pins[i],
+ pmx_data->func);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int meson_axg_pmx_request_gpio(struct pinctrl_dev *pcdev,
+ struct pinctrl_gpio_range *range, unsi
Re: [PATCH] gpu: gma500: remove unneeded DRIVER_LICENSE #define
On Fri, Nov 17, 2017 at 03:50:25PM +0100, Philippe Ombredanne wrote: > On Fri, Nov 17, 2017 at 3:16 PM, Greg Kroah-Hartman > wrote: > > There is no need to #define the license of the driver, just put it in > > the MODULE_LICENSE() line directly as a text string. > > > > This allows tools that check that the module license matches the source > > code license to work properly, as there is no need to unwind the > > unneeded dereference, especially when the string is defined in a .h file > > far away from the .c file it is used in. > > > > Cc: Patrik Jakobsson > > Cc: David Airlie > > Reported-by: Philippe Ombredanne > > Signed-off-by: Greg Kroah-Hartman > > Reviewed-by: Philippe Ombredanne Queued for 4.16, it'll pop up in linux-next as soon as -rc1 is tagged. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [RFC v5 00/11] V4L2 Explicit Synchronization
Hi Gustavo, I am currently referring to your implementation for explicit synchronisation. For the same I needed your testapp, but I am unable to download the same at the link provided “https://gitlab.collabora.com/padovan/v4l2-fences-test” Could you please help me out with the same. Regards Smitha On Wednesday, November 15, 2017, Gustavo Padovan wrote: > > From: Gustavo Padovan > > Hi, > > After the comments received in the last patchset[1] and > during the media summit [2] here is the new and improved version > of the patchset. The implementation is simpler, smaller and cover > a lot more cases. > > If you look to the last patchset I got rid of a few things, the main > one is the OUT_FENCE event, one thing that we decided in Prague was > that, when using fences, we would keep ordering of all buffers queued > to vb2. That means they would be queued to the drivers in the same order > that the QBUF calls happen, just like it already happens when not using > fences. Fences can signal in whatever order, so we need this guarantee > here. Drivers can, however, not keep ordering when processing the > buffers. > > But there is one conclusion of that that we didn't reached at the > summit, maybe because of the order we discussed things, and that is: we do > not need the OUT_FENCE event anymore, because now at the QBUF call time > we *always* know the order in which the buffers will be queued to the > v4l2 driver. So the out-fence fd is now returned using the fence_fd > field as a return argument, thus the event is not necessary anymore. > > The fence_fd field is now used to comunicate both in-fences and > out-fences, just like we do for GPU drivers. We pass in-fences as input > arguments and get out-fences as return arguments on the QBUF call. > The approach is documented. > > I also added a capability flag, V4L2_CAP_ORDERED, to tell userspace if > the v4l2 drivers keep the buffers ordered or not. > > We still have the 'ordered_in_driver' property for queues, but its > meaning has changed. When set videobuf2 will know that the driver can > keep the order of the buffers, thus videobuf2 can use the same fence > context for all out-fences. Fences inside the same context should signal > in order, so 'ordered_in_driver' is a optimization for that case. > When not set, a context for each out-fence is created. > > So now explicit synchronization also works for drivers that do not keep > the ordering of buffers. > > Another thing is that we do not allow videobuf2 to requeue buffers > internally when using fences, they have a fence associated to it and > we need to finish the job on them, i.e., signal the fence, even if an > error happened. > > The rest of the changes are documented in each patch separated. > > There a test app at: > > https://gitlab.collabora.com/padovan/v4l2-fences-test > > Among my next steps is to create a v4l2->drm test app using fences as a > PoC, and also look into how to support it in ChromeOS. > > Open Questions > -- > > * Do drivers reorder buffers internally? How to handle that with fences? > > * How to handle audio/video syncronization? Fences aren't enough, we need > to know things like the start of capture timestamp. > > Regards, > > Gustavo > -- > > [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1518928.html > [2] http://muistio.tieke.fi/p/media-summit-2017 > > Gustavo Padovan (10): > [media] v4l: add V4L2_CAP_ORDERED to the uapi > [media] vivid: add the V4L2_CAP_ORDERED capability > [media] vb2: add 'ordered_in_driver' property to queues > [media] vivid: mark vivid queues as ordered_in_driver > [media] vb2: check earlier if stream can be started > [media] vb2: add explicit fence user API > [media] vb2: add in-fence support to QBUF > [media] vb2: add infrastructure to support out-fences > [media] vb2: add out-fence support to QBUF > [media] v4l: Document explicit synchronization behavior > > Javier Martinez Canillas (1): > [media] vb2: add videobuf2 dma-buf fence helpers > > Documentation/media/uapi/v4l/buffer.rst | 15 ++ > Documentation/media/uapi/v4l/vidioc-qbuf.rst | 42 +++- > Documentation/media/uapi/v4l/vidioc-querybuf.rst | 9 +- > Documentation/media/uapi/v4l/vidioc-querycap.rst | 3 + > drivers/media/platform/vivid/vivid-core.c | 24 +- > drivers/media/usb/cpia2/cpia2_v4l.c | 2 +- > drivers/media/v4l2-core/Kconfig | 1 + > drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 4 +- > drivers/media/v4l2-core/videobuf2-core.c | 274 > +-- > drivers/media/v4l2-core/videobuf2-v4l2.c | 48 +++- > include/media/videobuf2-core.h | 44 +++- > include/media/videobuf2-fence.h | 48 > include/uapi/linux/videodev2.h | 8 +- > 13 files changed, 485 insertions(+), 37 deletions(-) > create mode 100644 include/media/videobuf2-fence.h > > -- > 2.13.6 >
Re: [PATCH] ioctl_tty.2: add TIOCGPTPEER documentation
On 08/16/2017 07:14 PM, Eric W. Biederman wrote: > Aleksa Sarai writes: > >>> A couple of things to note on the bigger picture. >>> >>> The glibc library on all distributions has been changed to not have a >>> setuid binary pt_chown, that uses ptsname. This was the primary fix >>> for the security issue. >>> >>> The behavior of opening /dev/ptmx has been changed to perform a path >>> lookup relative to the location of /dev/ptmx of ./pts/ptmx and open >>> it it is a devpts filesystem and to fail otherwise.This further >>> makes it hard to confuse userspace this way as /dev/ptmx always >>> corresponds to /dev/pts/ptmx. Even in chroots and in other mount >>> namespaces. >> >> I have a feeling that there might be a way to trick glibc if you use >> FUSE, but I haven't actually tried to create a PoC for it. Fair point >> though. > > To trick glibc fuse would have to be mounted somewhere on /dev. > >>> That makes TIOCGPTPEER a very nice addition, but not something people >>> have to scramble to use to ensure their system is secure. As a hostile >>> environment now has to work very hard to confuse the existing mechanisms. >> >> There are usecases where you simply need TIOCGPTPEER, and no other >> userspace alternative will do, but maybe if we modified the paragraph >> to read (as suggested): >> >> Security-conscious programs interacting with namespaces may >> wish to use this operation rather than open(2) with the >> pathname returned by ptsname(3). >> >> This would clarify that there are usecases where you need this >> particular feature, without saying causing people to panic over >> inaccurate claims of glibc being broken. Does that sound better? > > I think your original words sounded fine. I would even go for new > programs may want to use the new ioctl as it fundamentally less racy > and more of what is actually trying to be implemented with the userspace > pieces. > > I just wanted to point out that TIOCGPTPEER while being the interface > that it would have been nice had we had since the beginning (and would > have avoided all of the problems) is actually not something we need to > scramble and use it is just a very nice to have. As the immediate > issues have been fixed in other ways.It was not clear to me from the > other discussions if you and Michael Kerrisk were aware of the > mitigations that had been made to address the security issue. So, my takeaway is that we leave this text: Security-conscious programs interacting with namespaces may wish to use this operation rather than open(2) with the pathname returned by ptsname(3), and similar library func‐ tions that have insecure APIs. (For example, confusion can occur in some cases using ptsname(3) with a pathname where a devpts filesystem has been mounted in a different mount namespace.) as is? > The change to the behavior of /dev/ptmx may need to be documented > somewhere. I am not certain if anything has been documented since > devpts has started allowing multiple mounts. Eric can you say more about this. When did this change occur? What is the model: mount devpts once in each mount namespace? Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
[RESEND PATCH v3 0/2] dt: add pinctrl driver for Meson-AXG SoC
This is DT part patchset for adding pinctrl support for the Amlogic's Meson-AXG SoC. Changes since v2 at [2]: -- Resend this patch series due to fail to send patch [2/2] Changes since v1 at [1]: -- Separate DT part patches -- Add Neil Armstrong's Ack [2] http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005390.html [1] http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005270.html http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005271.html http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005272.html http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005273.html http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005274.html Xingyu Chen (2): documentation: Add compatibles for Amlogic Meson AXG pin controllers ARM64: dts: meson-axg: add pinctrl DT info for Meson-AXG SoC .../devicetree/bindings/pinctrl/meson,pinctrl.txt | 2 + arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 44 ++ 2 files changed, 46 insertions(+) -- 2.15.0
[RESEND PATCH v3 1/2] documentation: Add compatibles for Amlogic Meson AXG pin controllers
From: Xingyu Chen Add compatibles for Amlogic Meson AXG pin controllers Reviewed-by: Neil Armstrong Signed-off-by: Xingyu Chen Signed-off-by: Yixun Lan --- Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt index 2392557ede27..2c12f9789116 100644 --- a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt @@ -9,6 +9,8 @@ Required properties for the root node: "amlogic,meson-gxbb-aobus-pinctrl" "amlogic,meson-gxl-periphs-pinctrl" "amlogic,meson-gxl-aobus-pinctrl" + "amlogic,meson-axg-periphs-pinctrl" + "amlogic,meson-axg-aobus-pinctrl" - reg: address and size of registers controlling irq functionality === GPIO sub-nodes === -- 2.15.0
[RESEND PATCH v3 2/2] ARM64: dts: meson-axg: add pinctrl DT info for Meson-AXG SoC
From: Xingyu Chen
Add new pinctrl DT info for the Amlogic's Meson-AXG SoC.
Reviewed-by: Neil Armstrong
Signed-off-by: Xingyu Chen
Signed-off-by: Yixun Lan
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 44 ++
1 file changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 5fc33b76b91c..e0fb860e12c5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
/ {
compatible = "amlogic,meson-axg";
@@ -173,6 +174,32 @@
#mbox-cells = <1>;
};
+ periphs: periphs@ff634000 {
+ compatible = "simple-bus";
+ reg = <0x0 0xff634000 0x0 0x2000>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x0 0x0 0x0 0xff634000 0x0 0x2000>;
+
+ pinctrl_periphs: pinctrl@480 {
+ compatible =
"amlogic,meson-axg-periphs-pinctrl";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gpio: bank@480 {
+ reg = <0x0 0x00480 0x0 0x40>,
+ <0x0 0x004e8 0x0 0x14>,
+ <0x0 0x00520 0x0 0x14>,
+ <0x0 0x00430 0x0 0x3c>;
+ reg-names = "mux", "pull",
"pull-enable", "gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl_periphs 0 0 86>;
+ };
+ };
+ };
+
sram: sram@fffc {
compatible = "amlogic,meson-axg-sram", "mmio-sram";
reg = <0x0 0xfffc 0x0 0x2>;
@@ -209,6 +236,23 @@
};
};
+ pinctrl_aobus: pinctrl@14 {
+ compatible = "amlogic,meson-axg-aobus-pinctrl";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gpio_ao: bank@14 {
+ reg = <0x0 0x00014 0x0 0x8>,
+ <0x0 0x0002c 0x0 0x4>,
+ <0x0 0x00024 0x0 0x8>;
+ reg-names = "mux", "pull", "gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl_aobus 0 0 15>;
+ };
+ };
+
uart_AO: serial@3000 {
compatible = "amlogic,meson-gx-uart",
"amlogic,meson-ao-uart";
reg = <0x0 0x3000 0x0 0x18>;
--
2.15.0
Re: [22/26] MIPS: generic: Introduce generic DT-based board support
On Sat, Nov 18, 2017 at 07:43:25PM -0800, Guenter Roeck wrote: > On Fri, Aug 26, 2016 at 04:37:21PM +0100, Paul Burton wrote: > > Introduce a "generic" platform, which aims to be board-agnostic by > > making use of device trees passed by the boot protocol defined in the > > MIPS UHI (Universal Hosting Interface) specification. Provision is made > > for supporting boards which use a legacy boot protocol that can't be > > changed, but adding support for such boards or any others is left to > > followon patches. > > > > Right now the built kernels expect to be loaded to 0x8010, ie. in > > kseg0. This is fine for the vast majority of MIPS platforms, but > > nevertheless it would be good to remove this limitation in the future by > > mapping the kernel via the TLB such that it can be loaded anywhere & map > > itself appropriately. > > > > Configuration is handled by dynamically generating configs using > > scripts/kconfig/merge_config.sh, somewhat similar to the way powerpc > > makes use of it. This allows for variations upon the configuration, eg. > > differing architecture revisions or subsets of driver support for > > differing boards, to be handled without having a large number of > > defconfig files. > > > > Signed-off-by: Paul Burton > > Guess it is known that this patch causes failures when building > "allmodconfig" on test systems such as 0day; it was reported by 0day > some two months ago. nevertheless, the patch found its way into mainline > without fix. Does anyone care, or should I simply disable "allmodconfig" > test builds for mips ? Hi Guenter, I can't find any emails from 0day in relation to this patch (I've also dug about on the kbuild-all archives without success). Could you link to or quote the build failure you're referring to. Thanks James
Re: [RFC PATCH 0/3] restructure memfd code
Hi On Thu, Nov 9, 2017 at 2:41 AM, Mike Kravetz wrote: > With the addition of memfd hugetlbfs support, we now have the situation > where memfd depends on TMPFS -or- HUGETLBFS. Previously, memfd was only > supported on tmpfs, so it made sense that the code resides in shmem.c. > > This patch series moves the memfd code to separate files (memfd.c and > memfd.h). It creates a new config option MEMFD_CREATE that is defined > if either TMPFS or HUGETLBFS is defined. That looks good to me > > In the current code, memfd is only functional if TMPFS is defined. If > HUGETLFS is defined and TMPFS is not defined, then memfd functionality > will not be available for hugetlbfs. This does not cause BUGs, just a > potential lack of desired functionality. > Indeed > Another way to approach this issue would be to simply make HUGETLBFS > depend on TMPFS. > > This patch series is built on top of the Marc-André Lureau v3 series > "memfd: add sealing to hugetlb-backed memory": > http://lkml.kernel.org/r/20171107122800.25517-1-marcandre.lur...@redhat.com Are you waiting for this series to be merged before resending as non-rfc? > > Mike Kravetz (3): > mm: hugetlbfs: move HUGETLBFS_I outside #ifdef CONFIG_HUGETLBFS > mm: memfd: split out memfd for use by multiple filesystems > mm: memfd: remove memfd code from shmem files and use new memfd files > > fs/Kconfig | 3 + > fs/fcntl.c | 2 +- > include/linux/hugetlb.h | 27 ++-- > include/linux/memfd.h| 16 +++ > include/linux/shmem_fs.h | 13 -- > mm/Makefile | 1 + > mm/memfd.c | 341 > +++ > mm/shmem.c | 323 > 8 files changed, 378 insertions(+), 348 deletions(-) > create mode 100644 include/linux/memfd.h > create mode 100644 mm/memfd.c > > -- > 2.13.6 > Thanks -- Marc-André Lureau
Re: [PATCH] net: qmi_wwan: add Dell DW5818, DW5819
On 11/20/2017 16:27, Shrirang Bagul wrote:
Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
series modems which will by default boot with vid 0x413c and pid's
0x81cf, 0x81d0, 0x81d1,0x81d2. Along with qcserial, these modems support
qmi_wwan on the usb interface #12.
Signed-off-by: Shrirang Bagul
---
drivers/net/usb/qmi_wwan.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8d4a6f7cba61..bdf1fae38af2 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1234,6 +1234,10 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x413c, 0x81b3, 8)},/* Dell Wireless 5809e Gobi(TM)
4G LTE Mobile Broadband Card (rev3) */
{QMI_FIXED_INTF(0x413c, 0x81b6, 8)},/* Dell Wireless 5811e */
{QMI_FIXED_INTF(0x413c, 0x81b6, 10)}, /* Dell Wireless 5811e */
+ {QMI_FIXED_INTF(0x413c, 0x81cf, 12)}, /* Dell Wireless 5819 */
+ {QMI_FIXED_INTF(0x413c, 0x81d0, 12)}, /* Dell Wireless 5819 */
+ {QMI_FIXED_INTF(0x413c, 0x81d1, 12)}, /* Dell Wireless 5818 */
+ {QMI_FIXED_INTF(0x413c, 0x81d2, 12)}, /* Dell Wireless 5818 */
{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)},/* HP lt4111 LTE/EV-DO/HSPA+
Gobi 4G Module */
{QMI_FIXED_INTF(0x22de, 0x9061, 3)},/* WeTelecom WPD-600N */
{QMI_FIXED_INTF(0x1e0e, 0x9001, 5)},/* SIMCom 7230E */
NAK
413c:81cf and 413c:81d1 do not have a net interface, they only have a
single serial interface (QDL) for firmware update.
Please do not add usb id's for which you have not confirmed the
interface composition.
br
Lars
Re: [PATCH v2] staging: comedi: add missing MODULE_DESCRIPTION/LICENSE
On 20/11/17 07:50, Jesse Chan wrote:
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in
drivers/staging/comedi/drivers/ni_atmio.o
see include/linux/module.h for more information
This adds the license as "GPL", which matches the header of the file.
MODULE_DESCRIPTION is also added.
Signed-off-by: Jesse Chan
---
drivers/staging/comedi/drivers/ni_atmio.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/comedi/drivers/ni_atmio.c
b/drivers/staging/comedi/drivers/ni_atmio.c
index 2d62a8c57332..b61d56367773 100644
--- a/drivers/staging/comedi/drivers/ni_atmio.c
+++ b/drivers/staging/comedi/drivers/ni_atmio.c
@@ -361,3 +361,6 @@ static struct comedi_driver ni_atmio_driver = {
.detach = ni_atmio_detach,
};
module_comedi_driver(ni_atmio_driver);
+
+MODULE_DESCRIPTION("Comedi low-level driver");
+MODULE_LICENSE("GPL");
Thanks! I wonder how I managed to miss out this driver in commit
3c323c01b6bd ("Staging: comedi: Add MODULE_LICENSE and similar to NI
modules")?
Reviewed-by: Ian Abbott
--
-=( Ian Abbott @ MEV Ltd.E-mail: )=-
-=( Web: http://www.mev.co.uk/ )=-
Re: [GIT PULL 2nd resend] leaking_addresses updates for 4.15
On Thu, Nov 16, 2017 at 01:16:28PM +1100, Michael Ellerman wrote: > "Tobin C. Harding" writes: > > > Clearly I am unable to use email. > > > > Adding to CC: Greg, Steve, Paul - kernel developers CC'd on leaking > > addresses stuff that may know my face. > > > > Adding to CC: Michael - closest kernel developer by proximity that I > > have had direct correspondence with. > > > > Adding to CC: Konstantin - previous correspondence re kernel.org tree > > hosting. > > > > On Tue, Nov 14, 2017 at 02:45:59PM -0800, Linus Torvalds wrote: > >> On Tue, Nov 14, 2017 at 1:03 PM, Tobin C. Harding wrote: > >> > > >> > I did not sign the tag, it looks like you have not processed this yet. > >> > Do you want me to re-do the pull request on a signed tag? > >> > >> When pulling from github? Absolutely. > > > > Linus I'm not in the web of trust, pulling a tag signed by an _unknown_ > > key is not secure is it? Would it not be better to get into the web of > > trust first before requesting you pull any code from me. > > Linus will probably respond, but in short it's good to be in the web of > trust, but until you are it's still worth signing your tags. > > When you do get some signatures on your key, then we'll be able to see > that all your existing pull requests were really from you. > > At the end of the day what matters is that you send good code over a > period of time - and whether the Australian Government agrees that your > name is "Tobin Harding" is somewhat orthogonal to that. > > > Web of trust presents a social problem that I am not versed in. With my > > limited knowledge I can present the following solutions. > > > > 1. Get my key signed at linux.conf.au in January in Sydney. > > Sounds good, maybe we should have a 15 minute key signing slot at the > kernel miniconf. I'll contact the organizer. > > 2. Request a video call with _some_ number of kernel developers to sign > >key (suggested by Konstantin). > > 3. Drive to Canberra and meet face to face with Michael to sign key > >(if he would agree to that). > > Yeah if you want to that's no problem, just give me some notice :) I understand that there is no rush now so driving seems silly. See you in Sydney. thanks, Tobin.
Re: [PATCH v2 1/2] pinctrl: meson-axg: Introduce a pinctrl pinmux ops for Meson-AXG SoC
On Mon, 2017-11-20 at 18:08 +0800, Yixun Lan wrote: > From: Xingyu Chen > > The pin controller has been updated in the Amlogic Meson AXG series, > which use continuous 4-bit register to select function for each pin. > In order to support this, a new pinmux operations "meson_axg_pmx_ops" > has been added. > > Reviewed-by: Neil Armstrong Reviewed-by: Jerome Brunet > Signed-off-by: Xingyu Chen > Signed-off-by: Yixun Lan
Re: [PATCH v2 2/2] pinctrl: meson-axg: Add new pinctrl driver for Meson AXG SoC
On Mon, 2017-11-20 at 18:08 +0800, Yixun Lan wrote: > From: Xingyu Chen > > Add new pinctrl driver for Amlogic's Meson-AXG SoC. > > Reviewed-by: Neil Armstrong Reviewed-by: Jerome Brunet > Signed-off-by: Xingyu Chen > Signed-off-by: Yixun Lan
RE: [PATCH v2 3/3] net: ethernet: fec: fix refclk enable for SMSC LAN8710/20
From: Richard Leitner Sent: Monday, November 20,
2017 5:57 PM
>To: Andy Duan ; f.faine...@gmail.com;
>and...@lunn.ch
>Cc: Richard Leitner ; net...@vger.kernel.org; linux-
>ker...@vger.kernel.org
>Subject: Re: [PATCH v2 3/3] net: ethernet: fec: fix refclk enable for SMSC
>LAN8710/20
>
>
>On 11/20/2017 10:47 AM, Andy Duan wrote:
>> From: Richard Leitner Sent: Monday, November 20, 2017
>> 4:34 PM
>>> To: f.faine...@gmail.com; Andy Duan ;
>>> and...@lunn.ch
>>> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org;
>>> richard.leit...@skidata.com
>>> Subject: [PATCH v2 3/3] net: ethernet: fec: fix refclk enable for
>>> SMSC
>>> LAN8710/20
>>>
>>> From: Richard Leitner
>>>
>>> Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow
>>> turning the refclk on and off again during operation (according to their
>datasheet).
>>> Nonetheless exactly this behaviour was introduced for power saving
>>> reasons by commit e8fcfcd5684a ("net: fec: optimize the clock
>>> management to save power").
>>> Therefore after enabling the refclk we detect if an affected PHY is
>>> attached. If so reset and initialize it again.
>
>...
>
>>> +static int fec_enet_clk_ref_enable_reset_phy_quirk(struct net_device
>>> +*ndev) {
>>> + struct phy_device *phy_dev = ndev->phydev;
>>> + u32 real_phy_id;
>>> + int ret;
>>> +
>>> + /* some PHYs need a reset after the refclk was enabled, so we
>>> +* reset them here
>>> +*/
>>> + if (!phy_dev)
>>> + return 0;
>>> + if (!phy_dev->drv)
>>> + return 0;
>>> + real_phy_id = phy_dev->drv->phy_id & phy_dev->drv->phy_id_mask;
>>> + switch (real_phy_id) {
>>> + case 0x0007c0f0: /* SMSC LAN8710/LAN8720 */
>>
>> Don't hard code here...
>> I believe there have many other phys also do such operation, hardcode is
>unacceptable...
>>
>> And these code can be put into phy_device.c as common interface.
>
>Ok. Thank you for the feedback.
>So it would be fine to hardcode the affected phy_id's in a common function in
>phy_device.c?
>
>
>Another possible solution that came to my mind is to add a flag called
>something like "PHY_RST_AFTER_CLK_EN" to the flags variable in struct
>phy_driver. This flag could then be set in the smsc PHY driver for affected
>PHYs.
>
>Then instead of comparing the phy_id in the MAC driver this flag could be
>checked:
>
>if (phydev->drv->flags & PHY_RST_AFTER_CLK_EN) {
>ret = fec_reset_phy(ndev);
>...
>}
>
>Would checking the flag be OK in fec_main.c?
Yes, it is better than previous solution.
But add new common API in phy_device.c is much better like:
1. add a flag called "PHY_RST_AFTER_CLK_EN" to the flags variable in struct
phy_driver, all phy driver that need reset can set the flag.
2. add new common api interface phy_reset_after_clk_enable() in phy_device.c
driver
3. add reset gpio descriptor for common phy device driver.
4. then any mac driver can directly call the common interface
.phy_reset_after_clk_enable().
That is only my suggestion, maybe there have better idea.
Thanks.
>
>What would be the "better" approach?
>
>>
>>> + ret = fec_reset_phy(ndev);
>>> + if (ret)
>>> + return ret;
>>> + ret = phy_init_hw(phy_dev);
>>> + if (ret)
>>> + return ret;
>>> + }
>>> + return 0;
>>> +}
>>> +
>>> static int fec_enet_clk_enable(struct net_device *ndev, bool enable) {
>>> struct fec_enet_private *fep = netdev_priv(ndev); @@ -1862,6
>>> +1889,10 @@ static int fec_enet_clk_enable(struct net_device *ndev,
>>> +bool
>>> enable)
>>> ret = clk_prepare_enable(fep->clk_ref);
>>> if (ret)
>>> goto failed_clk_ref;
>>> +
>>> + ret = fec_enet_clk_ref_enable_reset_phy_quirk(ndev);
>>> + if (ret)
>>> + netdev_warn(ndev, "Resetting PHY failed, connection
>>> may be
>>> +unstable\n");
>>> } else {
>>> clk_disable_unprepare(fep->clk_ahb);
>>> clk_disable_unprepare(fep->clk_enet_out);
>>> @@ -2860,11 +2891,17 @@ fec_enet_open(struct net_device *ndev)
>>> if (ret)
>>> goto err_enet_mii_probe;
>>>
>>> + /* as the PHY is connected now, trigger the reset quirk again */
>>> + ret = fec_enet_clk_ref_enable_reset_phy_quirk(ndev);
>>> + if (ret)
>>> + netdev_warn(ndev, "Resetting PHY failed, connection may be
>>> +unstable\n");
>>> +
>>> if (fep->quirks & FEC_QUIRK_ERR006687)
>>> imx6q_cpuidle_fec_irqs_used();
>>>
>>> napi_enable(&fep->napi);
>>> phy_start(ndev->phydev);
>>> +
>>
>> No need blank line here...
>>> netif_tx_start_all_queues(ndev);
>>>
>>> device_set_wakeup_enable(&ndev->dev, fep->wol_flag &
>>> --
>>> 2.11.0
mmotm git tree since-4.14 branch created (was: mmotm 2017-11-17-16-17 uploaded)
I have just created since-4.14 branch in mm git tree
(http://git.kernel.org/?p=linux/kernel/git/mhocko/mm.git;a=summary). It
is based on v4.14 tag in Linus tree and mmotm-2017-11-17-16-17. I have
pulled ext4/dev and tip/x86/asm to satisfy dependencies. I wanted to
pull nvdimm tree as well but there were other dependeces I didn't feel
comfortable to resolve. If there are more trees to pull, please let me
know
As usual mmotm trees are tagged with signed tag
(finger print BB43 1E25 7FB8 660F F2F1 D22D 48E2 09A2 B310 E347)
The shortlog says:
Aaron Lu (1):
mm/page_alloc: make sure __rmqueue() etc are always inline
Alexandru Moise (1):
mm/madvise: enable soft offline of HugeTLB pages at PUD level
Alexey Dobriyan (4):
slab, slub, slob: add slab_flags_t
slab, slub, slob: convert slab_flags_t to 32-bit
proc: : uninline name_to_int()
proc: use do-while in name_to_int()
Andi Kleen (2):
kernel debug: support resetting WARN*_ONCE
kernel debug: support resetting WARN_ONCE for all architectures
Andrew Morton (1):
include/linux/sched/mm.h: uninline mmdrop_async(), etc
Andrey Ryabinin (2):
mm: remove unused pgdat->inactive_ratio
x86/mm/kasan: don't use vmemmap_populate() to initialize shadow
Andrey Vostrikov (1):
lib/crc-ccitt: add CCITT-FALSE CRC16 variant
Anshuman Khandual (1):
fs/hugetlbfs/inode.c: remove redundant -ENIVAL return from
hugetlbfs_setattr()
Arnd Bergmann (1):
mm: fix nodemask printing
Ayush Mittal (1):
mm/page_owner.c: reduce page_owner structure size
Changbin Du (2):
mm: update comments for struct page.mapping
mm/swap_state.c: declare a few variables as __read_mostly
Colin Ian King (3):
mm/rmap.c: remove redundant variable cend
drivers/block/zram/zram_drv.c: make zram_page_end_io() static
mm/hmm: remove redundant variable align_end
Corentin Labbe (1):
mm: shmem: remove unused info variable
Dan Williams (4):
mm: fix device-dax pud write-faults triggered by get_user_pages()
mm: replace pud_write with pud_access_permitted in fault + gup paths
mm: replace pmd_write with pmd_access_permitted in fault + gup paths
mm: replace pte_write with pte_access_permitted in fault + gup paths
David Rientjes (3):
mm/slab.c: only set __GFP_RECLAIMABLE once
mm, compaction: kcompactd should not ignore pageblock skip
mm, compaction: persistently skip hugetlbfs pageblocks
Fan Du (1):
memory hotplug: fix comments when adding section
Gioh Kim (1):
mm/memblock.c: make the index explicit argument of for_each_memblock_type
Gustavo A. R. Silva (2):
mm/shmem.c: mark expected switch fall-through
mm/list_lru.c: mark expected switch fall-through
Huang Ying (1):
mm, swap: fix false error message in __swp_swapcount()
Jaewon Kim (1):
mm/page_ext.c: check if page_ext is not prepared
Jan Kara (24):
mm: implement find_get_pages_range_tag()
btrfs: use pagevec_lookup_range_tag()
ceph: use pagevec_lookup_range_tag()
ext4: use pagevec_lookup_range_tag()
f2fs: use pagevec_lookup_range_tag()
f2fs: simplify page iteration loops
f2fs: use find_get_pages_tag() for looking up single page
gfs2: use pagevec_lookup_range_tag()
nilfs2: use pagevec_lookup_range_tag()
mm: use pagevec_lookup_range_tag() in __filemap_fdatawait_range()
mm: use pagevec_lookup_range_tag() in write_cache_pages()
mm: add variant of pagevec_lookup_range_tag() taking number of pages
ceph: use pagevec_lookup_range_nr_tag()
mm: remove nr_pages argument from pagevec_lookup_{,range}_tag()
afs: use find_get_pages_range_tag()
cifs: use find_get_pages_range_tag()
mm: speed up cancel_dirty_page() for clean pages
mm: refactor truncate_complete_page()
mm: factor out page cache page freeing into a separate function
mm: move accounting updates before page_cache_tree_delete()
mm: move clearing of page->mapping to page_cache_tree_delete()
mm: factor out checks and accounting from __delete_from_page_cache()
mm: batch radix tree operations when truncating pages
mm: readahead: increase maximum readahead window
Jason Baron (2):
epoll: avoid calling ep_call_nested() from ep_poll_safewake()
epoll: remove ep_call_nested() from ep_eventpoll_poll()
Joe Lawrence (4):
pipe: match pipe_max_size data type with procfs
pipe: avoid round_pipe_size() nr_pages overflow on 32-bit
pipe: add proc_dopipe_max_size() to safely assign pipe_max_size
sysctl: check for UINT_MAX before unsigned int min/max
Joe Perches (1):
spelling.txt: add "unnecessary" typo variants
Johannes Thumshirn (6):
include/linux/slab.h: add kmalloc_array_node() and kcalloc_node()
block/blk-mq.c: use kmalloc_array_node()
drivers/infiniband/hw/qib/qib_init.c: use kmalloc_array_node()
drivers/infiniband/sw/rdmavt/qp.c: us
Re: intel-gpio interrupts stop firing with Focaltech I2C-HID touchpad
On Mon, Nov 20, 2017 at 01:18:51PM +0800, Chris Chiu wrote:
> On Fri, Nov 17, 2017 at 9:52 PM, Mika Westerberg
> wrote:
> > On Fri, Nov 17, 2017 at 03:35:18PM +0200, Mika Westerberg wrote:
> >> > pin 18 (GPIO_18) GPIO 0x40900100 0x00024075
> >
> > Hmm,
> >
> > If I decode 0x40900100 correctly PADCFG0_GPIROUTIOXAPIC (BIT 20) flag is
> > set for the pin. This means the interrupt is routed to IO-APIC instead.
> >
> > Now, we do clear that flag along with the others when the GPIO is
> > requested through gpio_request() but in this case we go through irqchip
> > instead so the flag is not cleared.
> >
> > I wonder if the following patch changes anything?
> >
> > diff --git a/drivers/pinctrl/intel/pinctrl-intel.c
> > b/drivers/pinctrl/intel/pinctrl-intel.c
> > index 71df0f70b61f..06af096f5768 100644
> > --- a/drivers/pinctrl/intel/pinctrl-intel.c
> > +++ b/drivers/pinctrl/intel/pinctrl-intel.c
> > @@ -939,6 +939,10 @@ static int intel_gpio_irq_type(struct irq_data *d,
> > unsigned type)
> >
> > value &= ~(PADCFG0_RXEVCFG_MASK | PADCFG0_RXINV);
> >
> > + /* Disable SCI/SMI/NMI generation */
> > + value &= ~(PADCFG0_GPIROUTIOXAPIC | PADCFG0_GPIROUTSCI);
> > + value &= ~(PADCFG0_GPIROUTSMI | PADCFG0_GPIROUTNMI);
> > +
> > if ((type & IRQ_TYPE_EDGE_BOTH) == IRQ_TYPE_EDGE_BOTH) {
> > value |= PADCFG0_RXEVCFG_EDGE_BOTH << PADCFG0_RXEVCFG_SHIFT;
> > } else if (type & IRQ_TYPE_EDGE_FALLING) {
>
> It does change after the patch. I didn't have the touchpad stopping
> things after a long time test.
> The INT3452:00/pins under /sys/kernel/debug/pinctrl shows the
> following for GPIO 18.
> pin 18 (GPIO_18) GPIO 0x40800102 0x00024075
Great, thanks for testing!
> Anything else you need from me?
Nope, I'll make a proper patch and send it out this week.
[PATCH] xen-netfront: remove warning when unloading module
When unloading module xen_netfront from guest, dmesg would output
warning messages like below:
[ 105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use!
[ 105.236839] deferring g.e. 0x903 (pfn 0x35805)
This problem relies on netfront and netback being out of sync. By the time
netfront revokes the g.e.'s netback didn't have enough time to free all of
them, hence displaying the warnings on dmesg.
The trick here is to make netfront to wait until netback frees all the g.e.'s
and only then continue to cleanup for the module removal, and this is done by
manipulating both device states.
Signed-off-by: Eduardo Otubo
---
drivers/net/xen-netfront.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 8b8689c6d887..b948e2a1ce40 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -2130,6 +2130,17 @@ static int xennet_remove(struct xenbus_device *dev)
dev_dbg(&dev->dev, "%s\n", dev->nodename);
+ xenbus_switch_state(dev, XenbusStateClosing);
+ while (xenbus_read_driver_state(dev->otherend) != XenbusStateClosing){
+ cpu_relax();
+ schedule();
+ }
+ xenbus_switch_state(dev, XenbusStateClosed);
+ while (dev->xenbus_state != XenbusStateClosed){
+ cpu_relax();
+ schedule();
+ }
+
xennet_disconnect_backend(info);
unregister_netdev(info->netdev);
--
2.13.6
Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.
On Mon, Nov 20, 2017 at 10:42:37AM +0100, Michal Hocko wrote: > The patch has been dropped because allnoconfig failed to compile back > then > http://lkml.kernel.org/r/CAP=VYLr0rPWi1aeuk4w1On9CYRNmnEWwJgGtaX=wevgabur...@mail.gmail.com > I have problem to find the follow up discussion though. The main > argument was that SRC is not generally available and so the core > kernel should rely on it. Paul, isthere any good reason to not use SRCU in the core kernel and instead try to reimplement it using atomic counters?
Re: question about usb_rebind_intf
Am Freitag, den 17.11.2017, 13:21 -0500 schrieb Alan Stern: > > The real fix would be to change the interface drivers by adding proper > support for reset-resume. Otherwise there will always be a time window > following resume during which the interface is non-functional. Very hard to do with btusb. The connection is messed up if we lose power. Regards Oliver
Re: [PATCH] staging: comedi: ni_atmio: fix license warning.
On 18/11/17 16:26, Matthew Giassa wrote:
Resolving license check warning for drivers/staging/comedi. Added the
license definitions present in the rest of the module and made sure it's
aligned with the license (GPL) in the comments for the affected file
(ni_atmio.c). Original warning:
WARNING: modpost: missing MODULE_LICENSE() in
drivers/staging/comedi//drivers/ni_atmio.o
see include/linux/module.h for more information.
No longer present after change.
Signed-off-by: Matthew Giassa
---
drivers/staging/comedi/drivers/ni_atmio.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/staging/comedi/drivers/ni_atmio.c
b/drivers/staging/comedi/drivers/ni_atmio.c
index 2d62a8c..ae6ed96 100644
--- a/drivers/staging/comedi/drivers/ni_atmio.c
+++ b/drivers/staging/comedi/drivers/ni_atmio.c
@@ -361,3 +361,8 @@ static struct comedi_driver ni_atmio_driver = {
.detach = ni_atmio_detach,
};
module_comedi_driver(ni_atmio_driver);
+
+MODULE_AUTHOR("Comedi http://www.comedi.org";);
+MODULE_DESCRIPTION("Comedi low-level driver");
+MODULE_LICENSE("GPL");
+
Thanks. I already reviewed a similar patch for the same driver by Jesse
Chan, but that one never had the MODULE_AUTHOR line. Also, your patch
arrived earlier, so should take precedence.
Reviewed-by: Ian Abbott
--
-=( Ian Abbott @ MEV Ltd.E-mail: )=-
-=( Web: http://www.mev.co.uk/ )=-
[PATCH v2 4/4] backlight: as3711_bl: fix device-tree node leaks
Two framebuffer device-node names were looked up during probe, but were
only used as flags to indicate the presence of two framebuffer device.
Drop the unused framebuffer name along with a likewise unused device
pointer from the driver data, and update the platform data to pass in
booleans instead of the framebuffer strings. This allows us do drop the
node references acquired during probe, which would otherwise leak.
Note that there are no other in-kernel users of the modified
platform-data fields.
Fixes: 59eb2b5e57ea ("drivers/video/backlight/as3711_bl.c: add OF support")
Cc: Guennadi Liakhovetski
Signed-off-by: Johan Hovold
---
drivers/video/backlight/as3711_bl.c | 12 ++--
include/linux/mfd/as3711.h | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/video/backlight/as3711_bl.c
b/drivers/video/backlight/as3711_bl.c
index e55304d5cf07..ca544aa764b8 100644
--- a/drivers/video/backlight/as3711_bl.c
+++ b/drivers/video/backlight/as3711_bl.c
@@ -28,8 +28,6 @@ enum as3711_bl_type {
struct as3711_bl_data {
bool powered;
- const char *fb_name;
- struct device *fb_dev;
enum as3711_bl_type type;
int brightness;
struct backlight_device *bl;
@@ -273,7 +271,9 @@ static int as3711_backlight_parse_dt(struct device *dev)
fb = of_parse_phandle(bl, "su1-dev", 0);
if (fb) {
- pdata->su1_fb = fb->full_name;
+ of_node_put(fb);
+
+ pdata->su1_fb = true;
ret = of_property_read_u32(bl, "su1-max-uA",
&pdata->su1_max_uA);
if (pdata->su1_max_uA <= 0)
@@ -286,7 +286,9 @@ static int as3711_backlight_parse_dt(struct device *dev)
if (fb) {
int count = 0;
- pdata->su2_fb = fb->full_name;
+ of_node_put(fb);
+
+ pdata->su2_fb = true;
ret = of_property_read_u32(bl, "su2-max-uA",
&pdata->su2_max_uA);
if (pdata->su2_max_uA <= 0)
@@ -425,7 +427,6 @@ static int as3711_backlight_probe(struct platform_device
*pdev)
if (pdata->su1_fb) {
su = &supply->su1;
- su->fb_name = pdata->su1_fb;
su->type = AS3711_BL_SU1;
max_brightness = min(pdata->su1_max_uA, 31);
@@ -436,7 +437,6 @@ static int as3711_backlight_probe(struct platform_device
*pdev)
if (pdata->su2_fb) {
su = &supply->su2;
- su->fb_name = pdata->su2_fb;
su->type = AS3711_BL_SU2;
switch (pdata->su2_fbprot) {
diff --git a/include/linux/mfd/as3711.h b/include/linux/mfd/as3711.h
index 34cc85864be5..ddd0b953323b 100644
--- a/include/linux/mfd/as3711.h
+++ b/include/linux/mfd/as3711.h
@@ -108,9 +108,9 @@ struct as3711_regulator_pdata {
};
struct as3711_bl_pdata {
- const char *su1_fb;
+ bool su1_fb;
int su1_max_uA;
- const char *su2_fb;
+ bool su2_fb;
int su2_max_uA;
enum as3711_su2_feedback su2_feedback;
enum as3711_su2_fbprot su2_fbprot;
--
2.15.0
[PATCH v2 1/4] backlight: as3711_bl: fix device-tree node lookup
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.
To make things worse, the parent mfd node was also prematurely freed.
Fixes: 59eb2b5e57ea ("drivers/video/backlight/as3711_bl.c: add OF support")
Cc: stable # 3.10
Cc: Guennadi Liakhovetski
Signed-off-by: Johan Hovold
---
drivers/video/backlight/as3711_bl.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/video/backlight/as3711_bl.c
b/drivers/video/backlight/as3711_bl.c
index 734a9158946b..e55304d5cf07 100644
--- a/drivers/video/backlight/as3711_bl.c
+++ b/drivers/video/backlight/as3711_bl.c
@@ -262,10 +262,10 @@ static int as3711_bl_register(struct platform_device
*pdev,
static int as3711_backlight_parse_dt(struct device *dev)
{
struct as3711_bl_pdata *pdata = dev_get_platdata(dev);
- struct device_node *bl =
- of_find_node_by_name(dev->parent->of_node, "backlight"), *fb;
+ struct device_node *bl, *fb;
int ret;
+ bl = of_get_child_by_name(dev->parent->of_node, "backlight");
if (!bl) {
dev_dbg(dev, "backlight node not found\n");
return -ENODEV;
@@ -279,7 +279,7 @@ static int as3711_backlight_parse_dt(struct device *dev)
if (pdata->su1_max_uA <= 0)
ret = -EINVAL;
if (ret < 0)
- return ret;
+ goto err_put_bl;
}
fb = of_parse_phandle(bl, "su2-dev", 0);
@@ -292,7 +292,7 @@ static int as3711_backlight_parse_dt(struct device *dev)
if (pdata->su2_max_uA <= 0)
ret = -EINVAL;
if (ret < 0)
- return ret;
+ goto err_put_bl;
if (of_find_property(bl, "su2-feedback-voltage", NULL)) {
pdata->su2_feedback = AS3711_SU2_VOLTAGE;
@@ -314,8 +314,10 @@ static int as3711_backlight_parse_dt(struct device *dev)
pdata->su2_feedback = AS3711_SU2_CURR_AUTO;
count++;
}
- if (count != 1)
- return -EINVAL;
+ if (count != 1) {
+ ret = -EINVAL;
+ goto err_put_bl;
+ }
count = 0;
if (of_find_property(bl, "su2-fbprot-lx-sd4", NULL)) {
@@ -334,8 +336,10 @@ static int as3711_backlight_parse_dt(struct device *dev)
pdata->su2_fbprot = AS3711_SU2_GPIO4;
count++;
}
- if (count != 1)
- return -EINVAL;
+ if (count != 1) {
+ ret = -EINVAL;
+ goto err_put_bl;
+ }
count = 0;
if (of_find_property(bl, "su2-auto-curr1", NULL)) {
@@ -355,11 +359,20 @@ static int as3711_backlight_parse_dt(struct device *dev)
* At least one su2-auto-curr* must be specified iff
* AS3711_SU2_CURR_AUTO is used
*/
- if (!count ^ (pdata->su2_feedback != AS3711_SU2_CURR_AUTO))
- return -EINVAL;
+ if (!count ^ (pdata->su2_feedback != AS3711_SU2_CURR_AUTO)) {
+ ret = -EINVAL;
+ goto err_put_bl;
+ }
}
+ of_node_put(bl);
+
return 0;
+
+err_put_bl:
+ of_node_put(bl);
+
+ return ret;
}
static int as3711_backlight_probe(struct platform_device *pdev)
--
2.15.0
[PATCH v2 0/4] backlight: fix device-tree node lookups
A number of drivers have been using the wrong OF helper when doing child-node lookups during probe. This meant that they were doing tree-wide searches rather than matching on child nodes and that the parent node could end up being prematurely freed. Johan v2 - add patch 4/4 which fixes two node leaks in as3711_bl instead of marking the leaks using FIXMEs in patch 1/4 Johan Hovold (4): backlight: as3711_bl: fix device-tree node lookup backlight: max8925_bl: fix device-tree node lookup backlight: tps65217_bl: fix device-tree node lookup backlight: as3711_bl: fix device-tree node leaks drivers/video/backlight/as3711_bl.c | 45 ++- drivers/video/backlight/max8925_bl.c | 4 +++- drivers/video/backlight/tps65217_bl.c | 4 ++-- include/linux/mfd/as3711.h| 4 ++-- 4 files changed, 36 insertions(+), 21 deletions(-) -- 2.15.0
Re: [PATCH v2] staging: comedi: add missing MODULE_DESCRIPTION/LICENSE
On 20/11/17 10:29, Ian Abbott wrote:
On 20/11/17 07:50, Jesse Chan wrote:
This change resolves a new compile-time warning
when built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in
drivers/staging/comedi/drivers/ni_atmio.o
see include/linux/module.h for more information
This adds the license as "GPL", which matches the header of the file.
MODULE_DESCRIPTION is also added.
Signed-off-by: Jesse Chan
---
drivers/staging/comedi/drivers/ni_atmio.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/comedi/drivers/ni_atmio.c
b/drivers/staging/comedi/drivers/ni_atmio.c
index 2d62a8c57332..b61d56367773 100644
--- a/drivers/staging/comedi/drivers/ni_atmio.c
+++ b/drivers/staging/comedi/drivers/ni_atmio.c
@@ -361,3 +361,6 @@ static struct comedi_driver ni_atmio_driver = {
.detach = ni_atmio_detach,
};
module_comedi_driver(ni_atmio_driver);
+
+MODULE_DESCRIPTION("Comedi low-level driver");
+MODULE_LICENSE("GPL");
Thanks! I wonder how I managed to miss out this driver in commit
3c323c01b6bd ("Staging: comedi: Add MODULE_LICENSE and similar to NI
modules")?
Reviewed-by: Ian Abbott
Despite my above comment, we should probably give precedence to Matthew
Giassa's patch for the same issue, since it was sent earlier.
--
-=( Ian Abbott @ MEV Ltd.E-mail: )=-
-=( Web: http://www.mev.co.uk/ )=-
[PATCH v2 2/4] backlight: max8925_bl: fix device-tree node lookup
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.
To make things worse, the parent mfd node was also prematurely freed,
while the child backlight node was leaked.
Fixes: 47ec340cb8e2 ("mfd: max8925: Support dt for backlight")
Cc: stable # 3.9
Cc: Qing Xu
Cc: Haojian Zhuang
Signed-off-by: Johan Hovold
---
drivers/video/backlight/max8925_bl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/max8925_bl.c
b/drivers/video/backlight/max8925_bl.c
index 7b738d60ecc2..f3aa6088f1d9 100644
--- a/drivers/video/backlight/max8925_bl.c
+++ b/drivers/video/backlight/max8925_bl.c
@@ -116,7 +116,7 @@ static void max8925_backlight_dt_init(struct
platform_device *pdev)
if (!pdata)
return;
- np = of_find_node_by_name(nproot, "backlight");
+ np = of_get_child_by_name(nproot, "backlight");
if (!np) {
dev_err(&pdev->dev, "failed to find backlight node\n");
return;
@@ -125,6 +125,8 @@ static void max8925_backlight_dt_init(struct
platform_device *pdev)
if (!of_property_read_u32(np, "maxim,max8925-dual-string", &val))
pdata->dual_string = val;
+ of_node_put(np);
+
pdev->dev.platform_data = pdata;
}
--
2.15.0
