[PATCH 1/1] serial: 8250_pci: add RS485 for F81504/508/512
Add RS485 control for Fintek F81504/508/512
F81504/508/512 can control their RTS with H/W mode.
PCI configuration space for each port is 0x40 + idx * 8 + 7.
When it set with 0x01, it's configured with RS232 mode.
RTS is controlled by MCR.
When it set with 0x11, it's configured with RS485 mode.
RTS is controlled by H/W, RTS high with idle & RX, low with TX.
When it set with 0x31, it's configured with RS485 mode.
RTS is controlled by H/W, RTS low with idle & RX, high with TX.
We will force 0x01 on pci_fintek_setup().
Signed-off-by: Peter Hung
---
drivers/tty/serial/8250/8250_pci.c | 44 ++
1 file changed, 44 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_pci.c
b/drivers/tty/serial/8250/8250_pci.c
index e55f18b..36280fa 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1685,11 +1685,43 @@ pci_brcm_trumanage_setup(struct serial_private *priv,
return ret;
}
+static int pci_fintek_rs485_config(struct uart_port *port,
+ struct serial_rs485 *rs485)
+{
+ u8 setting;
+ u8 *index = (u8 *) port->private_data;
+ struct pci_dev *pci_dev = container_of(port->dev, struct pci_dev,
+ dev);
+
+ pci_read_config_byte(pci_dev, 0x40 + 8 * *index + 7, );
+
+ if (rs485->flags & SER_RS485_ENABLED) {
+ /* Enable RTS H/W control mode */
+ setting |= BIT(4);
+
+ if (rs485->flags & SER_RS485_RTS_ON_SEND) {
+ /* RTS driving high on TX */
+ setting |= BIT(5);
+ } else {
+ /* RTS driving low on TX */
+ setting &= ~BIT(5);
+ }
+ } else {
+ /* Disable RTS H/W control mode */
+ setting &= ~(BIT(4) | BIT(5));
+ }
+
+ pci_write_config_byte(pci_dev, 0x40 + 8 * *index + 7, setting);
+ port->rs485 = *rs485;
+ return 0;
+}
+
static int pci_fintek_setup(struct serial_private *priv,
const struct pciserial_board *board,
struct uart_8250_port *port, int idx)
{
struct pci_dev *pdev = priv->dev;
+ u8 *data;
u8 config_base;
u16 iobase;
@@ -1702,6 +1734,15 @@ static int pci_fintek_setup(struct serial_private *priv,
port->port.iotype = UPIO_PORT;
port->port.iobase = iobase;
+ port->port.rs485_config = pci_fintek_rs485_config;
+
+ data = devm_kzalloc(>dev, sizeof(u8), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ /* preserve index in PCI configuration space */
+ *data = idx;
+ port->port.private_data = data;
return 0;
}
@@ -1752,6 +1793,9 @@ static int pci_fintek_init(struct pci_dev *dev)
(u8)((iobase & 0xff00) >> 8));
pci_write_config_byte(dev, config_base + 0x06, dev->irq);
+
+ /* force init to RS232 Mode */
+ pci_write_config_byte(dev, config_base + 0x07, 0x01);
}
return max_port;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jul 24
Hi all, Changes since 20150723: The ext4 tree still had its build failure so I used the version from next-20150722. The next-next tree lost its build failure. The wireless-drivers-next tree still had its build failure so I used the version from next-20150721. The input tree gained a build failure so I used the version from next-20150723. The mmc-uh tree gained a conflict against the imx-mxs tree. The vhost tree gained a conflict against Linus' tree. The akpm-current tree gained 2 build failures for which I reverted 2 commits. Non-merge commits (relative to Linus' tree): 3545 3550 files changed, 158080 insertions(+), 90948 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 224 trees (counting Linus' and 33 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (45b4b782e848 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace) Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (0871b7248113 ARM: fix __virt_to_idmap build error on !MMU) Merging m68k-current/for-linus (1214c525484c m68k: Use for_each_sg()) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (bc0195aad0da Linux 4.2-rc2) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging powerpc-merge-benh/merge (c517d838eb7d Linux 4.0-rc1) Merging sparc/master (4a10a91756ef Merge branch 'upstream' of git://git.infradead.org/users/pcmoore/audit) Merging net/master (c5dfd654d0ec Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging ipsec/master (31a418986a58 xen: netback: read hotplug script once at start of day.) Merging sound-current/for-linus (cba59972a119 ALSA: hda - Add headset mic pin quirk for a Dell device) Merging pci-current/for-linus (c9ddbac9c891 PCI: Restore PCI_MSIX_FLAGS_BIRMASK definition) Merging wireless-drivers/master (df2cd4586f17 Merge tag 'iwlwifi-for-kalle-2015-06-12' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging driver-core.current/driver-core-linus (52721d9d3334 Linux 4.2-rc3) Merging tty.current/tty-linus (dec273ecc116 sc16is7xx: fix FIFO address of secondary UART) Merging usb.current/usb-linus (1209544d8a2a USB: OHCI: fix bad #define in ohci-tmio.c) Merging usb-gadget-fixes/fixes (aebda6187181 usb: dwc3: Reset the transfer resource index on SET_INTERFACE) Merging usb-serial-fixes/usb-linus (6da3700c98cd USB: qcserial: Add support for Dell Wireless 5809e 4G Modem) Merging staging.current/staging-linus (00243b1d180b Merge tag 'iio-fixes-for-4.2c' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus) Merging char-misc.current/char-misc-linus (154322f47376 mei: prevent unloading mei hw modules while the device is opened.) Merging input-current/for-linus (968491709e5b Input: usbtouchscreen - avoid unresponsive TSC-30 touch screen) Merging crypto-current/master (f898c522f0e9 crypto: ixp4xx - Remove bogus BUG_ON on scattered dst buffer) Merging ide/master (d681f1166919 ide: remove deprecated use
[PATCH net v2 2/3] r8152: fix wakeup settings
Avoid the driver to enable WOL if the device doesn't support it.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index e3a0110..d537c30 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2378,6 +2378,13 @@ static void r8153_power_cut_en(struct r8152 *tp, bool
enable)
ocp_write_word(tp, MCU_TYPE_USB, USB_MISC_0, ocp_data);
}
+static bool rtl_can_wakeup(struct r8152 *tp)
+{
+ struct usb_device *udev = tp->udev;
+
+ return (udev->actconfig->desc.bmAttributes & USB_CONFIG_ATT_WAKEUP);
+}
+
static void rtl_runtime_suspend_enable(struct r8152 *tp, bool enable)
{
if (enable) {
@@ -3417,12 +3424,15 @@ static void rtl8152_get_wol(struct net_device *dev,
struct ethtool_wolinfo *wol)
if (usb_autopm_get_interface(tp->intf) < 0)
return;
- mutex_lock(>control);
-
- wol->supported = WAKE_ANY;
- wol->wolopts = __rtl_get_wol(tp);
-
- mutex_unlock(>control);
+ if (!rtl_can_wakeup(tp)) {
+ wol->supported = 0;
+ wol->wolopts = 0;
+ } else {
+ mutex_lock(>control);
+ wol->supported = WAKE_ANY;
+ wol->wolopts = __rtl_get_wol(tp);
+ mutex_unlock(>control);
+ }
usb_autopm_put_interface(tp->intf);
}
@@ -3432,6 +3442,9 @@ static int rtl8152_set_wol(struct net_device *dev, struct
ethtool_wolinfo *wol)
struct r8152 *tp = netdev_priv(dev);
int ret;
+ if (!rtl_can_wakeup(tp))
+ return -EOPNOTSUPP;
+
ret = usb_autopm_get_interface(tp->intf);
if (ret < 0)
goto out_set_wol;
@@ -4073,6 +4086,9 @@ static int rtl8152_probe(struct usb_interface *intf,
goto out1;
}
+ if (!rtl_can_wakeup(tp))
+ __rtl_set_wol(tp, 0);
+
tp->saved_wolopts = __rtl_get_wol(tp);
if (tp->saved_wolopts)
device_set_wakeup_enable(>dev, true);
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net v2 1/3] r8152: fix the issue about U1/U2
- Disable U1/U2 during initialization.
- Disable lpm when linking is on, and enable it when linking is off.
- Disable U1/U2 when enabling runtime suspend.
It is possible to let hw stop working, if the U1/U2 request occurs
during some situations. The patch is used to avoid it.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 94 -
1 file changed, 54 insertions(+), 40 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 7f6419e..e3a0110 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2166,6 +2166,7 @@ static int rtl8153_enable(struct r8152 *tp)
if (test_bit(RTL8152_UNPLUG, >flags))
return -ENODEV;
+ usb_disable_lpm(tp->udev);
set_tx_qlen(tp);
rtl_set_eee_plus(tp);
r8153_set_rx_early_timeout(tp);
@@ -2337,11 +2338,54 @@ static void __rtl_set_wol(struct r8152 *tp, u32 wolopts)
device_set_wakeup_enable(>udev->dev, false);
}
+static void r8153_u1u2en(struct r8152 *tp, bool enable)
+{
+ u8 u1u2[8];
+
+ if (enable)
+ memset(u1u2, 0xff, sizeof(u1u2));
+ else
+ memset(u1u2, 0x00, sizeof(u1u2));
+
+ usb_ocp_write(tp, USB_TOLERANCE, BYTE_EN_SIX_BYTES, sizeof(u1u2), u1u2);
+}
+
+static void r8153_u2p3en(struct r8152 *tp, bool enable)
+{
+ u32 ocp_data;
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_U2P3_CTRL);
+ if (enable && tp->version != RTL_VER_03 && tp->version != RTL_VER_04)
+ ocp_data |= U2P3_ENABLE;
+ else
+ ocp_data &= ~U2P3_ENABLE;
+ ocp_write_word(tp, MCU_TYPE_USB, USB_U2P3_CTRL, ocp_data);
+}
+
+static void r8153_power_cut_en(struct r8152 *tp, bool enable)
+{
+ u32 ocp_data;
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_POWER_CUT);
+ if (enable)
+ ocp_data |= PWR_EN | PHASE2_EN;
+ else
+ ocp_data &= ~(PWR_EN | PHASE2_EN);
+ ocp_write_word(tp, MCU_TYPE_USB, USB_POWER_CUT, ocp_data);
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_MISC_0);
+ ocp_data &= ~PCUT_STATUS;
+ ocp_write_word(tp, MCU_TYPE_USB, USB_MISC_0, ocp_data);
+}
+
static void rtl_runtime_suspend_enable(struct r8152 *tp, bool enable)
{
if (enable) {
u32 ocp_data;
+ r8153_u1u2en(tp, false);
+ r8153_u2p3en(tp, false);
+
__rtl_set_wol(tp, WAKE_ANY);
ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_CONFIG);
@@ -2353,6 +2397,8 @@ static void rtl_runtime_suspend_enable(struct r8152 *tp,
bool enable)
ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_NORAML);
} else {
__rtl_set_wol(tp, tp->saved_wolopts);
+ r8153_u2p3en(tp, true);
+ r8153_u1u2en(tp, true);
}
}
@@ -2599,46 +2645,6 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
set_bit(PHY_RESET, >flags);
}
-static void r8153_u1u2en(struct r8152 *tp, bool enable)
-{
- u8 u1u2[8];
-
- if (enable)
- memset(u1u2, 0xff, sizeof(u1u2));
- else
- memset(u1u2, 0x00, sizeof(u1u2));
-
- usb_ocp_write(tp, USB_TOLERANCE, BYTE_EN_SIX_BYTES, sizeof(u1u2), u1u2);
-}
-
-static void r8153_u2p3en(struct r8152 *tp, bool enable)
-{
- u32 ocp_data;
-
- ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_U2P3_CTRL);
- if (enable)
- ocp_data |= U2P3_ENABLE;
- else
- ocp_data &= ~U2P3_ENABLE;
- ocp_write_word(tp, MCU_TYPE_USB, USB_U2P3_CTRL, ocp_data);
-}
-
-static void r8153_power_cut_en(struct r8152 *tp, bool enable)
-{
- u32 ocp_data;
-
- ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_POWER_CUT);
- if (enable)
- ocp_data |= PWR_EN | PHASE2_EN;
- else
- ocp_data &= ~(PWR_EN | PHASE2_EN);
- ocp_write_word(tp, MCU_TYPE_USB, USB_POWER_CUT, ocp_data);
-
- ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_MISC_0);
- ocp_data &= ~PCUT_STATUS;
- ocp_write_word(tp, MCU_TYPE_USB, USB_MISC_0, ocp_data);
-}
-
static void r8153_first_init(struct r8152 *tp)
{
u32 ocp_data;
@@ -2781,6 +2787,7 @@ static void rtl8153_disable(struct r8152 *tp)
r8153_disable_aldps(tp);
rtl_disable(tp);
r8153_enable_aldps(tp);
+ usb_enable_lpm(tp->udev);
}
static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u16 speed, u8
duplex)
@@ -2901,9 +2908,13 @@ static void rtl8153_up(struct r8152 *tp)
if (test_bit(RTL8152_UNPLUG, >flags))
return;
+ r8153_u1u2en(tp, false);
r8153_disable_aldps(tp);
r8153_first_init(tp);
r8153_enable_aldps(tp);
+ r8153_u2p3en(tp, true);
+ r8153_u1u2en(tp, true);
+ usb_enable_lpm(tp->udev);
}
static void rtl8153_down(struct r8152 *tp)
@@ -2914,6 +2925,7 @@ static void
[PATCH net v2 0/3] r8152: issues fix
v2: Replace patch #2 with "r8152: fix wakeup settings". v1: These patches are used to fix issues. Hayes Wang (3): r8152: fix the issue about U1/U2 - r8152: fix remote wakeup + r8152: fix wakeup settings r8152: don't enable napi before rx ready drivers/net/usb/r8152.c | 103 1 file changed, 60 insertions(+), 43 deletions(-) -- 2.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net v2 3/3] r8152: don't enable napi before rx ready
Adjust napi_disable() and napi_enable() to avoid r8152_poll() start
working before rx ready. Otherwise, it may have race condition for
rx_agg.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index d537c30..144dc64 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2075,7 +2075,6 @@ static int rtl_start_rx(struct r8152 *tp)
{
int i, ret = 0;
- napi_disable(>napi);
INIT_LIST_HEAD(>rx_done);
for (i = 0; i < RTL8152_MAX_RX; i++) {
INIT_LIST_HEAD(>rx_info[i].list);
@@ -2083,7 +2082,6 @@ static int rtl_start_rx(struct r8152 *tp)
if (ret)
break;
}
- napi_enable(>napi);
if (ret && ++i < RTL8152_MAX_RX) {
struct list_head rx_queue;
@@ -2951,8 +2949,10 @@ static void set_carrier(struct r8152 *tp)
if (!netif_carrier_ok(netdev)) {
tp->rtl_ops.enable(tp);
set_bit(RTL8152_SET_RX_MODE, >flags);
+ napi_disable(>napi);
netif_carrier_on(netdev);
rtl_start_rx(tp);
+ napi_enable(>napi);
}
} else {
if (netif_carrier_ok(netdev)) {
@@ -3395,9 +3395,11 @@ static int rtl8152_resume(struct usb_interface *intf)
if (test_bit(SELECTIVE_SUSPEND, >flags)) {
rtl_runtime_suspend_enable(tp, false);
clear_bit(SELECTIVE_SUSPEND, >flags);
+ napi_disable(>napi);
set_bit(WORK_ENABLE, >flags);
if (netif_carrier_ok(tp->netdev))
rtl_start_rx(tp);
+ napi_enable(>napi);
} else {
tp->rtl_ops.up(tp);
rtl8152_set_speed(tp, AUTONEG_ENABLE,
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: question about drivers/dma/dma-jz4780.c
> Yes for dmaengine drivers I do ask this question which typically ends up in > driver invoking devm_irq_free() in driver's remove callback > > IMHO don't think devm irq calls are very useful, they do make stuff > complicate Would it be better then to just go back to request_irq (or whatever is appropriate in this case). It would seem that the devm property can never be relied on, so there is no point to use it. julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH 2/6] soc: Mediatek: Add SCPSYS CPU power domain driver
On Fri, Jul 24, 2015 at 10:02:03AM +0800, Scott Shu wrote: > On Tue, 2015-06-23 at 07:53 +0200, Sascha Hauer wrote: > > Hi Scott, > > > > On Fri, Jun 19, 2015 at 02:01:17AM +0800, Scott Shu wrote: > > > This adds a CPU power domain driver for the Mediatek SCPSYS unit on > > > MT6580. > > > > This seems to be support for the very same hardware as I am posting > > here: > > > > https://lkml.org/lkml/2015/6/22/41 > > > > We should consolidate this. > > > > My driver is currently handles all power domains except the CPUs while > > yours handles only the CPUs. > > I currently haven't looked whether CPUs can just be part of a power > > domain aswell, but if that works this would probably be the way to go. > > > > Sascha > > > > > Hi Sascga, > > We had posted new patch set in following link, but still keep our > original framework. > http://lists.infradead.org/pipermail/linux-mediatek/2015-July/001498.html > > As we mentioned in the new email thread, the SMP operations > (smp_boot_secondary) > will be executed before registering the scpsys_drv driver, so the CPUs power > domain is controlled on arch/arm/mach-$(MACHINE) directory. > > Please kindly provide your comments and suggestion. Thank you very much. I think that instead of explaining why have to duplicate the code you should rather search for ways how the code can be shared. Yes, we'll need a second (early) entry point to the driver. Maybe we even have to create the shared code which is then called from the driver and your early architecture code. You'll probably have to do this separation between early code and regular driver code in your driver anyway, since I bet the MT6580 also has some power domains which shall be controlled by the regular Linux power domain code later. Also we probably could control the CPU power domains for the MT8173 in the SCPSYS driver aswell, we just don't have to because we use PSCI there. You see we are approaching the same problem from two different corners. Let's find a way to share the code. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (i386
defconfig) failed like this:
fs/hugetlbfs/inode.c: In function 'hugetlbfs_fallocate':
fs/hugetlbfs/inode.c:578:13: error: 'struct vm_area_struct' has no member named
'vm_policy'
pseudo_vma.vm_policy =
^
fs/hugetlbfs/inode.c:579:4: error: implicit declaration of function
'mpol_shared_policy_lookup' [-Werror=implicit-function-declaration]
mpol_shared_policy_lookup(_I(inode)->policy,
^
fs/hugetlbfs/inode.c:595:28: error: 'struct vm_area_struct' has no member named
'vm_policy'
mpol_cond_put(pseudo_vma.vm_policy);
^
fs/hugetlbfs/inode.c:601:27: error: 'struct vm_area_struct' has no member named
'vm_policy'
mpol_cond_put(pseudo_vma.vm_policy);
^
Caused by commit
6b2ac4455b3d ("hugetlbfs: add hugetlbfs_fallocate()")
vm_policy and mpol_shared_policy_lookup are only defined when CONFIG_NUMA
is set.
I have reverted that commit for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/6] iommu/mediatek: Add mt8173 IOMMU driver
On Tue, 2015-07-21 at 15:59 +0100, Will Deacon wrote:
> Hi Yong Wu,
>
> On Thu, Jul 16, 2015 at 10:04:34AM +0100, Yong Wu wrote:
> > This patch adds support for mediatek m4u (MultiMedia Memory Management
> > Unit).
>
> [...]
>
> > +static void mtk_iommu_tlb_flush_all(void *cookie)
> > +{
> > + struct mtk_iommu_domain *domain = cookie;
> > + void __iomem *base;
> > +
> > + base = domain->data->base;
> > + writel(F_INVLD_EN1 | F_INVLD_EN0, base + REG_MMU_INV_SEL);
> > + writel(F_ALL_INVLD, base + REG_MMU_INVALIDATE);
>
> This needs to be synchronous, so you probably want to call
> mtk_iommu_tlb_sync at the end.
>From our spec, we have to wait until HW done after tlb flush range.
But it don't need wait after tlb flush all.
so It isn't necessary to add mtk_iommu_tlb_sync in tlb_flush_all here.
>
> > +}
> > +
> > +static void mtk_iommu_tlb_add_flush(unsigned long iova, size_t size,
> > + bool leaf, void *cookie)
> > +{
> > + struct mtk_iommu_domain *domain = cookie;
> > + void __iomem *base = domain->data->base;
> > + unsigned int iova_start = iova, iova_end = iova + size - 1;
> > +
> > + writel(F_INVLD_EN1 | F_INVLD_EN0, base + REG_MMU_INV_SEL);
> > +
> > + writel(iova_start, base + REG_MMU_INVLD_START_A);
> > + writel(iova_end, base + REG_MMU_INVLD_END_A);
> > + writel(F_MMU_INV_RANGE, base + REG_MMU_INVALIDATE);
>
> Why are you using writel instead of writel_relaxed? I asked this before
> but I don't think you replied.
Sorry, I didn't notice _relax last time. I will improve in next version.
Thanks very much.
>
> Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/2] dt-bindings: regulator: mt6311: Add document for mt6311 regulator
This patch adds a list of supported regulator names to the devicetree
binding documentation for Mediatek MT6311 PMIC.
Signed-off-by: Henry Chen
---
.../bindings/regulator/mt6311-regulator.txt| 35 ++
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
b/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
new file mode 100644
index 000..02649d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
@@ -0,0 +1,35 @@
+Mediatek MT6311 Regulator Driver
+
+Required properties:
+- compatible: "mediatek,mt6311-regulator"
+- reg: I2C slave address, usually 0x6b.
+- regulators: List of regulators provided by this controller. It is named
+ to VDVFS and VBIASN.
+ The definition for each of these nodes is defined using the standard binding
+ for regulators at Documentation/devicetree/bindings/regulator/regulator.txt.
+
+The valid names for regulators are:
+BUCK:
+ VDVFS
+LDO:
+ VBIASN
+
+Example:
+ mt6311: pmic@6b {
+ compatible = "mediatek,mt6311-regulator";
+ reg = <0x6b>;
+
+ regulators {
+ mt6311_vcpu_reg: VDVFS {
+ regulator-name = "VDVFS";
+ regulator-min-microvolt = < 60>;
+ regulator-max-microvolt = <140>;
+ regulator-ramp-delay = <1>;
+ };
+ mt6311_ldo_reg: VBIASN {
+ regulator-name = "VBIASN";
+ regulator-min-microvolt = <20>;
+ regulator-max-microvolt = <80>;
+ };
+ };
+ };
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/2] regulator: mt6311: Add support for mt6311 regulator
Add regulator support for mt6311.
It has 2 regulaotrs - Buck and LDO, provide the related buck/ldo voltage
data to the driver, and creates the regulator_desc table. Supported
operations for Buck are enabled/disabled and voltage change, only
enabled/disabled for LDO.
Signed-off-by: Henry Chen
---
drivers/regulator/Kconfig| 9 ++
drivers/regulator/Makefile | 1 +
drivers/regulator/mt6311-regulator.c | 180 +++
drivers/regulator/mt6311-regulator.h | 65 +
include/linux/regulator/mt6311.h | 29 ++
5 files changed, 284 insertions(+)
create mode 100644 drivers/regulator/mt6311-regulator.c
create mode 100644 drivers/regulator/mt6311-regulator.h
create mode 100644 include/linux/regulator/mt6311.h
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index bef3bde..aab09ac 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -451,6 +451,15 @@ config REGULATOR_MC13892
Say y here to support the regulators found on the Freescale MC13892
PMIC.
+config REGULATOR_MT6311
+ tristate "MediaTek MT6311 PMIC"
+ depends on I2C
+ help
+ Say y here to select this option to enable the power regulator of
+ MediaTek MT6311 PMIC.
+ This driver supports the control of different power rails of device
+ through regulator interface.
+
config REGULATOR_MT6397
tristate "MediaTek MT6397 PMIC"
depends on MFD_MT6397
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 91bf762..45e790f 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_REGULATOR_MAX77843) += max77843.o
obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
obj-$(CONFIG_REGULATOR_MC13XXX_CORE) += mc13xxx-regulator-core.o
+obj-$(CONFIG_REGULATOR_MT6311) += mt6311-regulator.o
obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o
diff --git a/drivers/regulator/mt6311-regulator.c
b/drivers/regulator/mt6311-regulator.c
new file mode 100644
index 000..096e620
--- /dev/null
+++ b/drivers/regulator/mt6311-regulator.c
@@ -0,0 +1,180 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Henry Chen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "mt6311-regulator.h"
+
+static const struct regmap_config mt6311_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = MT6311_FQMTR_CON4,
+};
+
+/* Default limits measured in millivolts and milliamps */
+#define MT6311_MIN_UV 60
+#define MT6311_MAX_UV 140
+#define MT6311_STEP_UV 6250
+
+static const struct regulator_linear_range buck_volt_range[] = {
+ REGULATOR_LINEAR_RANGE(MT6311_MIN_UV, 0, 0x7f, MT6311_STEP_UV),
+};
+
+static struct regulator_ops mt6311_buck_ops = {
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage = regulator_map_voltage_linear_range,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+};
+
+static struct regulator_ops mt6311_ldo_ops = {
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+};
+
+#define MT6311_BUCK(_id) \
+{\
+ .name = #_id,\
+ .ops = _buck_ops,\
+ .of_match = of_match_ptr(#_id),\
+ .regulators_node = of_match_ptr("regulators"),\
+ .type = REGULATOR_VOLTAGE,\
+ .id = MT6311_ID_##_id,\
+ .n_voltages = (MT6311_MAX_UV - MT6311_MIN_UV) / MT6311_STEP_UV + 1,\
+ .min_uV = MT6311_MIN_UV,\
+ .uV_step = MT6311_STEP_UV,\
+ .owner = THIS_MODULE,\
+ .linear_ranges = buck_volt_range, \
+ .n_linear_ranges = ARRAY_SIZE(buck_volt_range), \
+ .enable_reg = MT6311_VDVFS11_CON9,\
+ .enable_mask = MT6311_PMIC_VDVFS11_EN_MASK,\
+ .vsel_reg = MT6311_VDVFS11_CON12,\
+ .vsel_mask = MT6311_PMIC_VDVFS11_VOSEL_MASK,\
+}
+
+#define MT6311_LDO(_id) \
+{\
+ .name = #_id,\
+
Re: question about drivers/dma/dma-jz4780.c
On Thu, Jul 23, 2015 at 07:24:10PM +0200, Julia Lawall wrote: > > > On Thu, 23 Jul 2015, Vinod Koul wrote: > > > On Wed, Jul 22, 2015 at 03:26:01PM +0100, Alex Smith wrote: > > > > > >>>I think the explicit devm_free_irq() here is unnecessary, as when > > > >>>remove is > > > >>>called there should be no remaining users of the DMA controller and > > > >>>therefore > > > >>>no chance of an IRQ occurring between the controller being > > > >>>unregistered and an > > > >>>implicit IRQ release afterwards. > > > >Are you ensuring that device can no longer sent interrupts and all > > > >instances > > > >of tasklet running or either completed are terminated and no further > > > >tasklet > > > >can be spawned? > > > > > > Hi Vinod, > > > > > > If I understand correctly, when remove() is called, there should be > > > no more users of the DMA controller, enforced by the module > > > reference count. > > > > > > Wouldn't that guarantee that there are no more transactions running > > > and therefore no chance of an interrupt from the controller or a > > > tasklet still running? > > > > That will only guarantee no new requests are recieved, but you may have > > tasklet already scheduled or irq sent from HW how do you prevent that? > > More genrally, I have seen another driver with synchronize_irq in the > remove function (dma/img-mdc-dma.c). Would that be safe enough? On the > other hand, if one is going to go to the trouble of putting that, maybe > one would do just as well to drop the devm for irqs and use free_irq in > place of synchronize_irq instead? synchronize_irq() will take care of irq but not tasklet right. Also irq can be triggered again as you haven't disabled that yet. Is it really worth the trouble going though hoops to ensure your device is in right state, so might be simpler to free the irq and kill tasklet Yes for dmaengine drivers I do ask this question which typically ends up in driver invoking devm_irq_free() in driver's remove callback IMHO don't think devm irq calls are very useful, they do make stuff complicated -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] regulator: mt6311: Add support for MT6311 regulator
This patch set adds support for the MediaTek PMIC mt6311 regulator driver, which adds mt6311 related buck/ldo voltage data to the driver, and creates the regulator_desc table. Changes in v4: - Removed the unnscessary check before return on mt6311_i2c_probe(). - Change the label on mt6311-regulator.txt. Changes in v3: - Removed the struct mt6311 since the members of mt6311 were not be necessary. Changes in v2: - Re-ordered the sequence of makefile and Kconfig. - Specifying the regulator DT bindings by providing of_match and regulators_node in the regulator_desc and delete the DT handling code. Henry Chen (2): dt-bindings: regulator: mt6311: Add document for mt6311 regulator regulator: mt6311: Add support for mt6311 regulator .../bindings/regulator/mt6311-regulator.txt| 35 drivers/regulator/Kconfig | 9 ++ drivers/regulator/Makefile | 1 + drivers/regulator/mt6311-regulator.c | 180 + drivers/regulator/mt6311-regulator.h | 65 include/linux/regulator/mt6311.h | 29 6 files changed, 319 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/mt6311-regulator.txt create mode 100644 drivers/regulator/mt6311-regulator.c create mode 100644 drivers/regulator/mt6311-regulator.h create mode 100644 include/linux/regulator/mt6311.h -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] drm fixes
Hi Linus, some amdgpu, one i915, one ttm and one hlcdc, nothing too scary, all seems fine for about this time. Dave. The following changes since commit 45b4b782e8489bcf45a4331ee32f0f3037c5c3aa: Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace (2015-07-23 13:16:21 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 02bbc4dc6874df0e865aa0977f0046c5c1afd498: Merge tag 'drm-atmel-hlcdc/fixes-for-4.2' of https://github.com/bbrezillon/linux-at91 into drm-fixes (2015-07-24 14:27:44 +1000) Alex Deucher (3): drm/amdgpu: implement VCE 3.0 harvesting support (v4) drm/amdgpu/cz: implement voltage validation properly drm/amdgpu/cz/dpm: properly report UVD and VCE clock levels Alexandre Courbot (1): drm/ttm: recognize ARM64 arch in ioprot handler Boris Brezillon (1): drm: atmel-hlcdc: fix vblank initial state Chris Wilson (1): drm/i915: Use two 32bit reads for select 64bit REG_READ ioctls Daniel Vetter (1): drm: Stop resetting connector state to unknown Dave Airlie (4): Merge branch 'drm-fixes-4.2' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2015-07-23' of git://anongit.freedesktop.org/drm-intel into drm-fixes Merge tag 'topic/drm-fixes-2015-07-23' of git://anongit.freedesktop.org/drm-intel into drm-fixes Merge tag 'drm-atmel-hlcdc/fixes-for-4.2' of https://github.com/bbrezillon/linux-at91 into drm-fixes Leo Liu (1): drm/amdgpu: add VCE harvesting instance query Michel Dänzer (2): drm/amdgpu/dce11: Re-set VBLANK interrupt state when enabling a CRTC drm/amdgpu/dce10: Re-set VBLANK interrupt state when enabling a CRTC drivers/gpu/drm/amd/amdgpu/amdgpu.h| 4 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 1 + drivers/gpu/drm/amd/amdgpu/cz_dpm.c| 70 -- drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 4 ++ drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 4 ++ drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 48 ++ drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 1 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 12 ++--- drivers/gpu/drm/drm_crtc.c | 5 +- drivers/gpu/drm/i915/intel_uncore.c| 26 +++--- drivers/gpu/drm/ttm/ttm_bo_util.c | 3 +- include/uapi/drm/amdgpu_drm.h | 2 + include/uapi/drm/i915_drm.h| 8 +++ 13 files changed, 154 insertions(+), 34 deletions(-)
linux-next: build failure after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (powerpc
allnoconfig) failed like this:
mm/built-in.o: In function `shrink_slab.part.73.constprop.83':
vmscan.c:(.text+0xf760): undefined reference to `__srcu_read_lock'
vmscan.c:(.text+0xf924): undefined reference to `__srcu_read_unlock'
mm/built-in.o: In function `unregister_shrinker':
(.text+0xfa60): undefined reference to `synchronize_srcu'
mm/built-in.o:(.data+0x1e8): undefined reference to `process_srcu'
Caused by commit
dab937da82f9 ("mm: srcu-ify shrinkers")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel broken on processors without performance counters
On Thu, Jul 23, 2015 at 09:02:14PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 23, 2015 at 07:54:36PM +0200, Borislav Petkov wrote:
> > On Thu, Jul 23, 2015 at 07:08:11PM +0200, Peter Zijlstra wrote:
> > > That would be bad, how can we force it to emit 5 bytes?
> >
> > .byte 0xe9 like we used to do in static_cpu_has_safe().
>
> Like so then?
>
> static __always_inline bool arch_static_branch_jump(struct static_key *key,
> bool inv)
> {
> unsigned long kval = (unsigned long)key + inv;
>
> asm_volatile_goto("1:"
> ".byte 0xe9\n\t .long %l[l_yes]\n\t"
> ".pushsection __jump_table, \"aw\" \n\t"
> _ASM_ALIGN "\n\t"
> _ASM_PTR "1b, %l[l_yes], %c0 \n\t"
> ".popsection \n\t"
> : : "i" (kval) : : l_yes);
>
> return false;
> l_yes:
> return true;
> }
Yap.
But, we can do even better and note down what kind of JMP the compiler
generated and teach __jump_label_transform() to generate the right one.
Maybe this struct jump_entry would get a flags member or so. This way
we're optimal.
Methinks...
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] mm, compaction: introduce kcompactd
On Thu, Jul 23, 2015 at 01:58:20PM -0700, David Rientjes wrote: > On Thu, 23 Jul 2015, Joonsoo Kim wrote: > > > > The slub allocator does try to allocate its high-order memory with > > > __GFP_WAIT before falling back to lower orders if possible. I would > > > think > > > that this would be the greatest sign of on-demand memory compaction being > > > a problem, especially since CONFIG_SLUB is the default, but I haven't > > > seen > > > such reports. > > > > In fact, some of our product had trouble with slub's high order > > allocation 5 months ago. At that time, compaction didn't make high order > > page and compaction attempts are frequently deferred. It also causes many > > reclaim to make high order page so I suggested masking out __GFP_WAIT > > and adding __GFP_NO_KSWAPD when trying slub's high order allocation to > > reduce reclaim/compaction overhead. Although using high order page in slub > > has some gains that reducing internal fragmentation and reducing management > > overhead, benefit is marginal compared to the cost at making high order > > page. This solution improves system response time for our case. I planned > > to submit the patch but it is delayed due to my laziness. :) > > > > Hi Joonsoo, Hello David. > > On a fragmented machine I can certainly understand that the overhead > involved in allocating the high-order page outweighs the benefit later and > it's better to fallback more quickly to page orders if the cache allows > it. > > I believe that this would be improved by the suggestion of doing > background synchronous compaction. So regardless of whether __GFP_WAIT is > set, if the allocation fails then we can kick off background compaction > that will hopefully defragment memory for future callers. That should > make high-order atomic allocations more successful as well. Yep! I also think __GFP_NO_KSWAPD isn't appropriate for general case. Reason I suggested __GFP_NO_KSWAPD to our system is that reclaim/compaction continually fails to make high order page so we don't want to invoke reclaim/compaction even though it works in background. But, on almost of other system, reclaim/compaction could succeed so adding __GFP_NO_KSWAPD doens't make sense for general case. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/6] iommu: add ARM short descriptor page table allocator.
Hi Will, Thanks for your review so detail. When you are free, please help me check whether it's ok if it's changed like below. Thanks very much. On Tue, 2015-07-21 at 18:11 +0100, Will Deacon wrote: > Hello, > > This is looking better, but I still have some concerns. > > On Thu, Jul 16, 2015 at 10:04:32AM +0100, Yong Wu wrote: > > This patch is for ARM Short Descriptor Format. > > > > Signed-off-by: Yong Wu > > --- > > drivers/iommu/Kconfig| 18 + > > drivers/iommu/Makefile |1 + > > drivers/iommu/io-pgtable-arm-short.c | 742 > > ++ > > drivers/iommu/io-pgtable-arm.c |3 - > > drivers/iommu/io-pgtable.c |4 + > > drivers/iommu/io-pgtable.h | 13 + > > 6 files changed, 778 insertions(+), 3 deletions(-) > > create mode 100644 drivers/iommu/io-pgtable-arm-short.c > > [...] > > > +#define ARM_SHORT_PGDIR_SHIFT 20 > > +#define ARM_SHORT_PAGE_SHIFT 12 > > +#define ARM_SHORT_PTRS_PER_PTE \ > > + (1 << (ARM_SHORT_PGDIR_SHIFT - ARM_SHORT_PAGE_SHIFT)) > > +#define ARM_SHORT_BYTES_PER_PTE\ > > + (ARM_SHORT_PTRS_PER_PTE * sizeof(arm_short_iopte)) > > + > > +/* level 1 pagetable */ > > +#define ARM_SHORT_PGD_TYPE_PGTABLE BIT(0) > > +#define ARM_SHORT_PGD_SECTION_XN (BIT(0) | BIT(4)) > > +#define ARM_SHORT_PGD_TYPE_SECTION BIT(1) > > +#define ARM_SHORT_PGD_PGTABLE_XN BIT(2) > > This should be PXN, but I'm not even sure why we care for a table at > level 1. I will delete it. > > > +#define ARM_SHORT_PGD_BBIT(2) > > +#define ARM_SHORT_PGD_CBIT(3) > > +#define ARM_SHORT_PGD_PGTABLE_NS BIT(3) > > +#define ARM_SHORT_PGD_IMPLEBIT(9) > > +#define ARM_SHORT_PGD_TEX0 BIT(12) > > +#define ARM_SHORT_PGD_SBIT(16) > > +#define ARM_SHORT_PGD_nG BIT(17) > > +#define ARM_SHORT_PGD_SUPERSECTION BIT(18) > > +#define ARM_SHORT_PGD_SECTION_NS BIT(19) > > + > > +#define ARM_SHORT_PGD_TYPE_SUPERSECTION\ > > + (ARM_SHORT_PGD_TYPE_SECTION | ARM_SHORT_PGD_SUPERSECTION) > > +#define ARM_SHORT_PGD_SECTION_TYPE_MSK \ > > + (ARM_SHORT_PGD_TYPE_SECTION | ARM_SHORT_PGD_SUPERSECTION) > > +#define ARM_SHORT_PGD_PGTABLE_TYPE_MSK \ > > + (ARM_SHORT_PGD_TYPE_SECTION | ARM_SHORT_PGD_TYPE_PGTABLE) > > +#define ARM_SHORT_PGD_TYPE_IS_PGTABLE(pgd) \ > > + (((pgd) & ARM_SHORT_PGD_PGTABLE_TYPE_MSK) == > > ARM_SHORT_PGD_TYPE_PGTABLE) > > +#define ARM_SHORT_PGD_TYPE_IS_SECTION(pgd) \ > > + (((pgd) & ARM_SHORT_PGD_SECTION_TYPE_MSK) == > > ARM_SHORT_PGD_TYPE_SECTION) > > +#define ARM_SHORT_PGD_TYPE_IS_SUPERSECTION(pgd)\ > > + (((pgd) & ARM_SHORT_PGD_SECTION_TYPE_MSK) == \ > > + ARM_SHORT_PGD_TYPE_SUPERSECTION) > > +#define ARM_SHORT_PGD_PGTABLE_MSK 0xfc00 > > +#define ARM_SHORT_PGD_SECTION_MSK (~(SZ_1M - 1)) > > +#define ARM_SHORT_PGD_SUPERSECTION_MSK (~(SZ_16M - 1)) > > + > > +/* level 2 pagetable */ > > +#define ARM_SHORT_PTE_TYPE_LARGE BIT(0) > > +#define ARM_SHORT_PTE_SMALL_XN BIT(0) > > +#define ARM_SHORT_PTE_TYPE_SMALL BIT(1) > > +#define ARM_SHORT_PTE_BBIT(2) > > +#define ARM_SHORT_PTE_CBIT(3) > > +#define ARM_SHORT_PTE_SMALL_TEX0 BIT(6) > > +#define ARM_SHORT_PTE_IMPLEBIT(9) > > This is AP[2] for small pages. Sorry, In our pagetable bit9 in PGD and PTE is PA[32] that is for the dram size over 4G. I didn't care it is different in PTE of the standard spec. And I don't use the AP[2] currently, so I only delete this line in next time. > > > +#define ARM_SHORT_PTE_SBIT(10) > > +#define ARM_SHORT_PTE_nG BIT(11) > > +#define ARM_SHORT_PTE_LARGE_TEX0 BIT(12) > > +#define ARM_SHORT_PTE_LARGE_XN BIT(15) > > +#define ARM_SHORT_PTE_LARGE_MSK(~(SZ_64K - 1)) > > +#define ARM_SHORT_PTE_SMALL_MSK(~(SZ_4K - 1)) > > +#define ARM_SHORT_PTE_TYPE_MSK \ > > + (ARM_SHORT_PTE_TYPE_LARGE | ARM_SHORT_PTE_TYPE_SMALL) > > +#define ARM_SHORT_PTE_TYPE_IS_SMALLPAGE(pte) \ > > + (pte) & ARM_SHORT_PTE_TYPE_MSK) >> 1) << 1)\ > > + == ARM_SHORT_PTE_TYPE_SMALL) > > I see what you're trying to do here, but the shifting is confusing. I > think it's better doing something like: > > ((pte) & ARM_SHORT_PTE_TYPE_SMALL) == ARM_SHORT_PTE_TYPE_SMALL > > or even just: > > (pte) & ARM_SHORT_PTE_TYPE_SMALL Thanks. I will use this: ((pte) & ARM_SHORT_PTE_TYPE_SMALL) ==
[PATCH 1/2] kbuild: fixdep: optimize code slightly
If the target string matches "CONFIG_", move the pointer p
forward. This saves several 7-chars adjustments.
Signed-off-by: Masahiro Yamada
---
scripts/basic/fixdep.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index b304068..46cc1b3 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -251,7 +251,8 @@ static void parse_config_file(const char *map, size_t len)
continue;
if (memcmp(p, "CONFIG_", 7))
continue;
- for (q = p + 7; q < map + len; q++) {
+ p += 7;
+ for (q = p; q < map + len; q++) {
if (!(isalnum(*q) || *q == '_'))
goto found;
}
@@ -260,9 +261,9 @@ static void parse_config_file(const char *map, size_t len)
found:
if (!memcmp(q - 7, "_MODULE", 7))
q -= 7;
- if( (q-p-7) < 0 )
+ if (q - p < 0)
continue;
- use_config(p+7, q-p-7);
+ use_config(p, q - p);
}
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] kbuild: fixdep: drop meaningless hash table initialization
The clear_config() is called just once at the beginning of this
program, but the global variable hashtab[] is already zero-filled
at the start-up.
Signed-off-by: Masahiro Yamada
---
scripts/basic/fixdep.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index 46cc1b3..c68fd61 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -192,23 +192,6 @@ static void define_config(const char *name, int len,
unsigned int hash)
}
/*
- * Clear the set of configuration strings.
- */
-static void clear_config(void)
-{
- struct item *aux, *next;
- unsigned int i;
-
- for (i = 0; i < HASHSZ; i++) {
- for (aux = hashtab[i]; aux; aux = next) {
- next = aux->next;
- free(aux);
- }
- hashtab[i] = NULL;
- }
-}
-
-/*
* Record the use of a CONFIG_* word.
*/
static void use_config(const char *m, int slen)
@@ -325,8 +308,6 @@ static void parse_dep_file(void *map, size_t len)
int saw_any_target = 0;
int is_first_dep = 0;
- clear_config();
-
while (m < end) {
/* Skip any "white space" */
while (m < end && (*m == ' ' || *m == '\\' || *m == '\n'))
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] kbuild: Minor cleanups of fixdep
Masahiro Yamada (2): kbuild: fixdep: optimize code slightly kbuild: fixdep: drop meaningless hash table initialization scripts/basic/fixdep.c | 26 -- 1 file changed, 4 insertions(+), 22 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] input: cyapa: add of match device support and description document
Add of_match_device mechanism support for Cypress trackpad device, and
add the sample description document on how to adding the trackpad device node
in the device tree.
Signed-off-by: Dudley Du
---
.../devicetree/bindings/input/cypress,cyapa.txt| 44 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
drivers/input/mouse/cyapa.c| 10 +
3 files changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/cypress,cyapa.txt
diff --git a/Documentation/devicetree/bindings/input/cypress,cyapa.txt
b/Documentation/devicetree/bindings/input/cypress,cyapa.txt
new file mode 100644
index 000..9be2b44
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cypress,cyapa.txt
@@ -0,0 +1,44 @@
+Cypress I2C Touchpad
+
+Required properties:
+- compatible: must be "cypress,cyapa".
+- reg: I2C address of the chip.
+- interrupt-parent: a phandle for the interrupt controller (see interrupt
+ binding[0]).
+- interrupts: interrupt to which the chip is connected (see interrupt
+ binding[0]).
+
+Optional properties:
+- wakeup-source: touchpad can be used as a wakeup source.
+- pinctrl-names: should be "default" (see pinctrl binding [1]).
+- pinctrl-0: a phandle pointing to the pin settings for the device (see
+ pinctrl binding [1]).
+- vcc-supply: a phandle for the regulator supplying 3.3V power.
+
+[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+[1]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+
+Example:
+{
+ /* ... */
+
+ /* Cypress Gen3 touchpad */
+ touchpad@67 {
+ compatible = "cypress,cyapa";
+ reg = <0x24>;
+ interrupt-parent = <>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>; /* GPIO 2 */
+ wakeup-source;
+ };
+
+ /* Cypress Gen5 and later touchpad */
+ touchpad@24 {
+ compatible = "cypress,cyapa";
+ reg = <0x24>;
+ interrupt-parent = <>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>; /* GPIO 2 */
+ wakeup-source;
+ };
+
+ /* ... */
+ };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d444757..57c0f5f 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -54,6 +54,7 @@ cortina Cortina Systems, Inc.
cosmic Cosmic Circuits
crystalfontz Crystalfontz America, Inc.
cubietech Cubietech, Ltd.
+cypressCypress Semiconductor Corporation
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
davicomDAVICOM Semiconductor, Inc.
delta Delta Electronics, Inc.
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 2159c5e..3431510 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "cyapa.h"
@@ -1486,11 +1487,20 @@ static const struct acpi_device_id cyapa_acpi_id[] = {
MODULE_DEVICE_TABLE(acpi, cyapa_acpi_id);
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id cyapa_of_match[] = {
+ { .compatible = "cypress,cyapa" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, cyapa_of_match);
+#endif
+
static struct i2c_driver cyapa_driver = {
.driver = {
.name = "cyapa",
.pm = _pm_ops,
.acpi_match_table = ACPI_PTR(cyapa_acpi_id),
+ .of_match_table = of_match_ptr(cyapa_of_match),
},
.probe = cyapa_probe,
--
1.9.1
---
This message and any attachments may contain Cypress (or its
subsidiaries) confidential information. If it has been received
in error, please advise the sender and immediately delete this
message.
---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] input: cyapa: add regulator vcc support
Add power management regulator vcc support.
It's described to be supported in the cypress,cyapa.txt document.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 28
drivers/input/mouse/cyapa.h | 1 +
2 files changed, 29 insertions(+)
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 6195ccb..2159c5e 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -1241,6 +1241,13 @@ static void cyapa_remove_sysfs_group(void *data)
sysfs_remove_group(>client->dev.kobj, _sysfs_group);
}
+static void cyapa_disable_regulator(void *data)
+{
+ struct cyapa *cyapa = data;
+
+ regulator_disable(cyapa->vcc);
+}
+
static int cyapa_probe(struct i2c_client *client,
const struct i2c_device_id *dev_id)
{
@@ -1274,6 +1281,27 @@ static int cyapa_probe(struct i2c_client *client,
sprintf(cyapa->phys, "i2c-%d-%04x/input0", client->adapter->nr,
client->addr);
+ cyapa->vcc = devm_regulator_get(dev, "vcc");
+ if (IS_ERR(cyapa->vcc)) {
+ error = PTR_ERR(cyapa->vcc);
+ dev_err(dev, "failed to get vcc regulator: %d\n", error);
+ return error;
+ }
+
+ error = regulator_enable(cyapa->vcc);
+ if (error) {
+ dev_err(dev, "failed to enable regulator: %d\n", error);
+ return error;
+ }
+
+ error = devm_add_action(dev, cyapa_disable_regulator, cyapa);
+ if (error) {
+ cyapa_disable_regulator(cyapa);
+ dev_err(dev, "failed to add disable regulator action: %d\n",
+ error);
+ return error;
+ }
+
error = cyapa_initialize(cyapa);
if (error) {
dev_err(dev, "failed to detect and initialize tp device.\n");
diff --git a/drivers/input/mouse/cyapa.h b/drivers/input/mouse/cyapa.h
index af12536..b812bba 100644
--- a/drivers/input/mouse/cyapa.h
+++ b/drivers/input/mouse/cyapa.h
@@ -321,6 +321,7 @@ struct cyapa {
u8 status[BL_STATUS_SIZE];
bool operational; /* true: ready for data reporting; false: not. */
+ struct regulator *vcc;
struct i2c_client *client;
struct input_dev *input;
char phys[32]; /* Device physical location */
--
1.9.1
---
This message and any attachments may contain Cypress (or its
subsidiaries) confidential information. If it has been received
in error, please advise the sender and immediately delete this
message.
---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] input: cyapa: fix output unwanted warning issue
Avoid the driver generate warning message when the cyapa driver working
with the old Gen5 trackpad device which does not support the proximity function.
Those old Gen5 trackpad device all have the platform version less than 2.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa_gen5.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/input/mouse/cyapa_gen5.c b/drivers/input/mouse/cyapa_gen5.c
index 6d7abbe..118ba97 100644
--- a/drivers/input/mouse/cyapa_gen5.c
+++ b/drivers/input/mouse/cyapa_gen5.c
@@ -2519,10 +2519,13 @@ static int cyapa_gen5_do_operational_check(struct cyapa
*cyapa)
__func__);
/* By default, the trackpad proximity function is enabled. */
- error = cyapa_pip_set_proximity(cyapa, true);
- if (error)
- dev_warn(dev, "%s: failed to enable proximity.\n",
- __func__);
+ if (cyapa->platform_ver >= 2) {
+ error = cyapa_pip_set_proximity(cyapa, true);
+ if (error)
+ dev_warn(dev,
+ "%s: failed to enable proximity.\n",
+ __func__);
+ }
/* Get trackpad product information. */
error = cyapa_gen5_get_query_data(cyapa);
--
1.9.1
---
This message and any attachments may contain Cypress (or its
subsidiaries) confidential information. If it has been received
in error, please advise the sender and immediately delete this
message.
---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] cyapa patches instruction
These patches are made based on Dmitry's next tree. It's aimed to add regulator vcc and of match device tree supported, and also fix the output unwanted wanring message issue when working with old Gen5 Trackpad device that doesn't support the proximity function. Dudley Du (3): input: cyapa: add regulator vcc support input: cyapa: add of match device support and description document input: cyapa: fix output unwanted warning issue .../devicetree/bindings/input/cypress,cyapa.txt| 44 ++ .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/input/mouse/cyapa.c| 38 +++ drivers/input/mouse/cyapa.h| 1 + drivers/input/mouse/cyapa_gen5.c | 11 -- 5 files changed, 91 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/cypress,cyapa.txt -- 1.9.1 --- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. --- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mailbox: switch to hrtimer for tx_complete polling
On Wed, Jul 22, 2015 at 5:58 PM, Sudeep Holla wrote: > we might end-up waiting > for atleast a jiffy even though the response for that message from the > remote is received via interrupt and processed in relatively smaller > time granularity. > That is wrong. If the controller supports TX interrupt it should set txdone_irq, which prevents polling i.e, controller driver calls mbox_chan_txdone. If the controller doesn't support TX interrupt but the client receives some ack packet, then the client should set knows_txdone and call mbox_client_txdone. Again you don't have to wait on polling. If there's neither TX interrupt nor some ack packet, only then it has to rely on polling. In which case, I doubt if we can desire some functionality that requires sub-jiffy notification of TX_done. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] staging: rtl8712: remove duplicate struct
struct ndis_wlan_bssid_ex is a dopelganger of
struct wlan_bssid_ex, and is used about a third as often
Switch all instances to wlan_bssid_ex
This also gets rid of a use of typedef NDIS_802_11_RATES_EX
Signed-off-by: Joshua Clayton
---
drivers/staging/rtl8712/rtl871x_cmd.c | 17 ++---
drivers/staging/rtl8712/rtl871x_cmd.h | 4 +--
drivers/staging/rtl8712/rtl871x_event.h | 2 +-
drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 10
drivers/staging/rtl8712/rtl871x_mlme.c| 35
+--
drivers/staging/rtl8712/rtl871x_mlme.h| 2 +-
drivers/staging/rtl8712/rtl871x_mp_ioctl.c| 6 ++---
drivers/staging/rtl8712/wlan_bssdef.h | 23 ++
8 files changed, 38 insertions(+), 61 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_cmd.c
b/drivers/staging/rtl8712/rtl871x_cmd.c
index f07050d..ef71829 100644
--- a/drivers/staging/rtl8712/rtl871x_cmd.c
+++ b/drivers/staging/rtl8712/rtl871x_cmd.c
@@ -456,9 +456,7 @@ u8 r8712_createbss_cmd(struct _adapter *padapter)
INIT_LIST_HEAD(>list);
pcmd->cmdcode = _CreateBss_CMD_;
pcmd->parmbuf = (unsigned char *)pdev_network;
- pcmd->cmdsz = r8712_get_ndis_wlan_bssid_ex_sz((
- struct ndis_wlan_bssid_ex *)
- pdev_network);
+ pcmd->cmdsz = r8712_get_wlan_bssid_ex_sz(pdev_network);
pcmd->rsp = NULL;
pcmd->rspsz = 0;
/* notes: translate IELength & Length after assign to cmdsz; */
@@ -471,7 +469,7 @@ u8 r8712_createbss_cmd(struct _adapter *padapter)
u8 r8712_joinbss_cmd(struct _adapter *padapter, struct wlan_network
*pnetwork)
{
- struct ndis_wlan_bssid_ex *psecnetwork;
+ struct wlan_bssid_ex *psecnetwork;
struct cmd_obj *pcmd;
struct cmd_priv *pcmdpriv = >cmdpriv;
struct mlme_priv*pmlmepriv = >mlmepriv;
@@ -502,7 +500,7 @@ u8 r8712_joinbss_cmd(struct _adapter *padapter, struct
wlan_network *pnetwork)
break;
}
}
- psecnetwork = (struct ndis_wlan_bssid_ex *)>sec_bss;
+ psecnetwork = >sec_bss;
if (psecnetwork == NULL) {
kfree(pcmd);
return _FAIL;
@@ -566,7 +564,7 @@ u8 r8712_joinbss_cmd(struct _adapter *padapter, struct
wlan_network *pnetwork)
memcpy(>supplicant_ie[1], >IEs[0],
255);
/* get cmdsz before endian conversion */
- pcmd->cmdsz = r8712_get_ndis_wlan_bssid_ex_sz(psecnetwork);
+ pcmd->cmdsz = r8712_get_wlan_bssid_ex_sz(psecnetwork);
#ifdef __BIG_ENDIAN
/* wlan_network endian conversion */
psecnetwork->Length = cpu_to_le32(psecnetwork->Length);
@@ -894,8 +892,7 @@ void r8712_createbss_cmd_callback(struct _adapter
*padapter,
struct sta_info *psta = NULL;
struct wlan_network *pwlan = NULL;
struct mlme_priv *pmlmepriv = >mlmepriv;
- struct ndis_wlan_bssid_ex *pnetwork = (struct ndis_wlan_bssid_ex *)
- pcmd->parmbuf;
+ struct wlan_bssid_ex *pnetwork = (struct wlan_bssid_ex *)pcmd->parmbuf;
struct wlan_network *tgt_network = &(pmlmepriv->cur_network);
if (pcmd->res != H2C_SUCCESS)
@@ -949,11 +946,11 @@ void r8712_createbss_cmd_callback(struct _adapter
*padapter,
} else
list_add_tail(&(pwlan->list),
>scanned_queue.queue);
- pnetwork->Length = r8712_get_ndis_wlan_bssid_ex_sz(pnetwork);
+ pnetwork->Length = r8712_get_wlan_bssid_ex_sz(pnetwork);
memcpy(&(pwlan->network), pnetwork, pnetwork->Length);
pwlan->fixed = true;
memcpy(_network->network, pnetwork,
- (r8712_get_ndis_wlan_bssid_ex_sz(pnetwork)));
+ (r8712_get_wlan_bssid_ex_sz(pnetwork)));
if (pmlmepriv->fw_state & _FW_UNDER_LINKING)
pmlmepriv->fw_state ^= _FW_UNDER_LINKING;
/* we will set _FW_LINKED when there is one more sat to
diff --git a/drivers/staging/rtl8712/rtl871x_cmd.h
b/drivers/staging/rtl8712/rtl871x_cmd.h
index cb8225b..8a91b80 100644
--- a/drivers/staging/rtl8712/rtl871x_cmd.h
+++ b/drivers/staging/rtl8712/rtl871x_cmd.h
@@ -128,7 +128,7 @@ struct usb_suspend_parm {
* Command Event Mode
*/
struct joinbss_parm {
- struct ndis_wlan_bssid_ex network;
+ struct wlan_bssid_ex network;
};
/*
@@ -146,7 +146,7 @@ struct disconnect_parm {
* Command Mode
*/
struct createbss_parm {
- struct ndis_wlan_bssid_ex network;
+ struct wlan_bssid_ex network;
};
/*
diff --git a/drivers/staging/rtl8712/rtl871x_event.h
b/drivers/staging/rtl8712/rtl871x_event.h
index e03ee90..697c8d7 100644
--- a/drivers/staging/rtl8712/rtl871x_event.h
+++ b/drivers/staging/rtl8712/rtl871x_event.h
@@ -36,7 +36,7
[PATCH 5/5] staging: rtl8712: style fix:
change instances SupportedRates to compliant and sane "rates"
This change in no way harms readability, and brings several lines
under the 80 character limit.
Signed-off-by: Joshua Clayton
---
drivers/staging/rtl8712/ieee80211.c | 22 +++---
drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 21 +
drivers/staging/rtl8712/wlan_bssdef.h | 4 ++--
3 files changed, 22 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/rtl8712/ieee80211.c
b/drivers/staging/rtl8712/ieee80211.c
index 5786808..ca9dcaf 100644
--- a/drivers/staging/rtl8712/ieee80211.c
+++ b/drivers/staging/rtl8712/ieee80211.c
@@ -134,22 +134,22 @@ u8 *r8712_get_ie(u8 *pbuf, sint index, sint *len, sint
limit)
return NULL;
}
-static void set_supported_rate(u8 *SupportedRates, uint mode)
+static void set_supported_rate(u8 *rates, uint mode)
{
- memset(SupportedRates, 0, NDIS_802_11_LENGTH_RATES_EX);
+ memset(rates, 0, NDIS_802_11_LENGTH_RATES_EX);
switch (mode) {
case WIRELESS_11B:
- memcpy(SupportedRates, WIFI_CCKRATES,
+ memcpy(rates, WIFI_CCKRATES,
IEEE80211_CCK_RATE_LEN);
break;
case WIRELESS_11G:
case WIRELESS_11A:
- memcpy(SupportedRates, WIFI_OFDMRATES,
+ memcpy(rates, WIFI_OFDMRATES,
IEEE80211_NUM_OFDM_RATESLEN);
break;
case WIRELESS_11BG:
- memcpy(SupportedRates, WIFI_CCKRATES, IEEE80211_CCK_RATE_LEN);
- memcpy(SupportedRates + IEEE80211_CCK_RATE_LEN, WIFI_OFDMRATES,
+ memcpy(rates, WIFI_CCKRATES, IEEE80211_CCK_RATE_LEN);
+ memcpy(rates + IEEE80211_CCK_RATE_LEN, WIFI_OFDMRATES,
IEEE80211_NUM_OFDM_RATESLEN);
break;
}
@@ -195,17 +195,17 @@ int r8712_generate_ie(struct registry_priv *pregistrypriv)
ie = r8712_set_ie(ie, _SSID_IE_, pdev_network->Ssid.SsidLength,
pdev_network->Ssid.Ssid, );
/*supported rates*/
- set_supported_rate(pdev_network->SupportedRates,
+ set_supported_rate(pdev_network->rates,
pregistrypriv->wireless_mode);
- rateLen = r8712_get_rateset_len(pdev_network->SupportedRates);
+ rateLen = r8712_get_rateset_len(pdev_network->rates);
if (rateLen > 8) {
ie = r8712_set_ie(ie, _SUPPORTEDRATES_IE_, 8,
- pdev_network->SupportedRates, );
+ pdev_network->rates, );
ie = r8712_set_ie(ie, _EXT_SUPPORTEDRATES_IE_, (rateLen - 8),
- (pdev_network->SupportedRates + 8), );
+ (pdev_network->rates + 8), );
} else
ie = r8712_set_ie(ie, _SUPPORTEDRATES_IE_,
- rateLen, pdev_network->SupportedRates, );
+ rateLen, pdev_network->rates, );
/*DS parameter set*/
ie = r8712_set_ie(ie, _DSSET_IE_, 1,
(u8 *)&(pdev_network->Configuration.DSConfig), );
diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index 087fbf1..219239c 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -203,14 +203,12 @@ static inline char *translate_scan(struct _adapter
*padapter,
}
/* Add the protocol name */
iwe.cmd = SIOCGIWNAME;
- if ((r8712_is_cckratesonly_included((u8 *)>network.
-SupportedRates)) == true) {
+ if (r8712_is_cckratesonly_included(pnetwork->network.rates)) {
if (ht_cap == true)
snprintf(iwe.u.name, IFNAMSIZ, "IEEE 802.11bn");
else
snprintf(iwe.u.name, IFNAMSIZ, "IEEE 802.11b");
- } else if ((r8712_is_cckrates_included((u8 *)>network.
- SupportedRates)) == true) {
+ } else if (r8712_is_cckrates_included(pnetwork->network.rates)) {
if (ht_cap == true)
snprintf(iwe.u.name, IFNAMSIZ, "IEEE 802.11bgn");
else
@@ -270,9 +268,9 @@ static inline char *translate_scan(struct _adapter
*padapter,
iwe.u.bitrate.disabled = 0;
iwe.u.bitrate.value = 0;
i = 0;
- while (pnetwork->network.SupportedRates[i] != 0) {
+ while (pnetwork->network.rates[i] != 0) {
/* Bit rate given in 500 kb/s units */
- iwe.u.bitrate.value = (pnetwork->network.SupportedRates[i++] &
+ iwe.u.bitrate.value = (pnetwork->network.rates[i++] &
0x7F) * 50;
current_val = iwe_stream_add_value(info, start, current_val,
stop, , IW_EV_PARAM_LEN);
@@ -644,15 +642,15 @@ static int r8711_wx_get_name(struct net_device *dev,
[PATCH 4/5] staging: rtl8712: remove typedefs
Coding style fix.
Get rid of typedefs NDIS_802_11_RATES and NDIS_802_11_RATES_EX
Signed-off-by: Joshua Clayton
---
drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 4 ++--
drivers/staging/rtl8712/wlan_bssdef.h | 7 +--
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index 4f5f69c..087fbf1 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -635,7 +635,7 @@ static int r8711_wx_get_name(struct net_device *dev,
u8 ht_cap = false;
struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
struct wlan_bssid_ex *pcur_bss = >cur_network.network;
- NDIS_802_11_RATES_EX *prates = NULL;
+ u8 *prates;
if (check_fwstate(pmlmepriv, _FW_LINKED|WIFI_ADHOC_MASTER_STATE) ==
true) {
@@ -644,7 +644,7 @@ static int r8711_wx_get_name(struct net_device *dev,
_ielen, pcur_bss->IELength - 12);
if (p && ht_ielen > 0)
ht_cap = true;
- prates = _bss->SupportedRates;
+ prates = pcur_bss->SupportedRates;
if (r8712_is_cckratesonly_included((u8 *)prates) == true) {
if (ht_cap == true)
snprintf(wrqu->name, IFNAMSIZ,
diff --git a/drivers/staging/rtl8712/wlan_bssdef.h
b/drivers/staging/rtl8712/wlan_bssdef.h
index 7d769e8..7a410b5 100644
--- a/drivers/staging/rtl8712/wlan_bssdef.h
+++ b/drivers/staging/rtl8712/wlan_bssdef.h
@@ -32,11 +32,6 @@
#define NDIS_802_11_LENGTH_RATES8
#define NDIS_802_11_LENGTH_RATES_EX 16
-/* Set of 8 data rates*/
-typedef unsigned char NDIS_802_11_RATES[NDIS_802_11_LENGTH_RATES];
-/* Set of 16 data rates */
-typedef unsigned char NDIS_802_11_RATES_EX[NDIS_802_11_LENGTH_RATES_EX];
-
struct ndis_802_11_ssid {
u32 SsidLength;
u8 Ssid[32];
@@ -104,7 +99,7 @@ struct wlan_bssid_ex {
enum NDIS_802_11_NETWORK_TYPE NetworkTypeInUse;
struct NDIS_802_11_CONFIGURATION Configuration;
enum NDIS_802_11_NETWORK_INFRASTRUCTURE InfrastructureMode;
- NDIS_802_11_RATES_EX SupportedRates;
+ u8 SupportedRates[NDIS_802_11_LENGTH_RATES_EX];
u32 IELength;
/*(timestamp, beacon interval, and capability information) */
u8 IEs[MAX_IE_SZ];
--
2.4.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/3] docs: dts: Added documentation for Xilinx Zynq PL Reset bindings.
On 07/24/2015 12:51 AM, Moritz Fischer wrote:
> Signed-off-by: Moritz Fischer
> ---
> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt | 13 +
> 1 file changed, 13 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>
> diff --git a/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
> b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
> new file mode 100644
> index 000..ac4499e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
> @@ -0,0 +1,13 @@
> +Xilinx Zynq PL Reset Manager
I think there is no reason to be just PL specific.
> +
> +Required properties:
> +- compatible: "xlnx,zynq-reset-pl"
> +- syscon <>;
> +- #reset-cells: 1
> +
> +Example:
> + rstc: rstc@240 {
@200 then here
> + #reset-cells = <1>;
> + compatible = "xlnx,zynq-reset-pl";
Compatible should be first below node name.
You should add also reg property 0x200 0x50
> + syscon = <>;
> + };
>
Thanks,
Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] staging: rtl8712: simplify size calculation
replace item-by-item size calculation of a struct
with the size of the struct.
This gets rid of a use of typedef NDIS_802_11_RATES_EX
Signed-off-by: Joshua Clayton
---
drivers/staging/rtl8712/rtl871x_cmd.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_cmd.c
b/drivers/staging/rtl8712/rtl871x_cmd.c
index e35854d..f07050d 100644
--- a/drivers/staging/rtl8712/rtl871x_cmd.c
+++ b/drivers/staging/rtl8712/rtl871x_cmd.c
@@ -471,7 +471,6 @@ u8 r8712_createbss_cmd(struct _adapter *padapter)
u8 r8712_joinbss_cmd(struct _adapter *padapter, struct wlan_network *pnetwork)
{
- uint t_len = 0;
struct ndis_wlan_bssid_ex *psecnetwork;
struct cmd_obj *pcmd;
struct cmd_priv *pcmdpriv = >cmdpriv;
@@ -486,14 +485,6 @@ u8 r8712_joinbss_cmd(struct _adapter *padapter, struct
wlan_network *pnetwork)
pcmd = kmalloc(sizeof(*pcmd), GFP_ATOMIC);
if (pcmd == NULL)
return _FAIL;
- t_len = sizeof(u32) + 6 * sizeof(unsigned char) + 2 +
- sizeof(struct ndis_802_11_ssid) + sizeof(u32) +
- sizeof(s32) +
- sizeof(enum NDIS_802_11_NETWORK_TYPE) +
- sizeof(struct NDIS_802_11_CONFIGURATION) +
- sizeof(enum NDIS_802_11_NETWORK_INFRASTRUCTURE) +
- sizeof(NDIS_802_11_RATES_EX) +
- sizeof(u32) + MAX_IE_SZ;
/* for hidden ap to set fw_state here */
if (check_fwstate(pmlmepriv, WIFI_STATION_STATE|WIFI_ADHOC_STATE) !=
@@ -516,7 +507,7 @@ u8 r8712_joinbss_cmd(struct _adapter *padapter, struct
wlan_network *pnetwork)
kfree(pcmd);
return _FAIL;
}
- memcpy(psecnetwork, >network, t_len);
+ memcpy(psecnetwork, >network, sizeof(*psecnetwork));
psecuritypriv->authenticator_ie[0] = (unsigned char)
psecnetwork->IELength;
if ((psecnetwork->IELength-12) < (256 - 1))
--
2.4.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5]
The main goal of this series is to get rid of a needless and ugly typedef in the rtl8712 wlan driver. In the course of fixing that, I found a bug thati will can might (at least in theory) lead to a overrun during a memcpy, as well as a duplicate struct. Finally after cleaning up the typedef, I could not bring myself to leave a variable called SupportedRates in the kernel with my name on it. I have tested this on amd64. cwthe module loads and doesn't explode Joshua Clayton (5): staging: rtl8712: fix buggy size calculation staging: rtl8712: simplify size calculation staging: rtl8712: remove duplicate struct staging: rtl8712: remove typedefs staging: rtl8712: style fix: drivers/staging/rtl8712/ieee80211.c | 22 ++--- drivers/staging/rtl8712/rtl871x_cmd.c | 28 +--- drivers/staging/rtl8712/rtl871x_cmd.h | 4 +-- drivers/staging/rtl8712/rtl871x_event.h | 2 +- drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 33 +-- drivers/staging/rtl8712/rtl871x_mlme.c| 47 ++- drivers/staging/rtl8712/rtl871x_mlme.h| 2 +- drivers/staging/rtl8712/rtl871x_mp_ioctl.c| 6 ++-- drivers/staging/rtl8712/wlan_bssdef.h | 32 +++--- 9 files changed, 63 insertions(+), 113 deletions(-) -- 2.4.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] staging: rtl8712: fix buggy size calculation
r8712_get_ndis_wlan_bssid_ex_sz has a "6 * sizeof(unsigned long)"
where the underlying struct has a 6 * unsigned char.
Simplify the calculation by just subtracting the variable part from
the size of the struct.
This also gets rid of a use of typedef NDIS_802_11_RATES_EX
Signed-off-by: Joshua Clayton
---
drivers/staging/rtl8712/rtl871x_mlme.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_mlme.c
b/drivers/staging/rtl8712/rtl871x_mlme.c
index c044b0e..6b3451f 100644
--- a/drivers/staging/rtl8712/rtl871x_mlme.c
+++ b/drivers/staging/rtl8712/rtl871x_mlme.c
@@ -210,17 +210,7 @@ void r8712_generate_random_ibss(u8 *pibss)
uint r8712_get_ndis_wlan_bssid_ex_sz(struct ndis_wlan_bssid_ex *bss)
{
- uint t_len;
-
- t_len = sizeof(u32) + 6 * sizeof(unsigned long) + 2 +
- sizeof(struct ndis_802_11_ssid) + sizeof(u32) +
- sizeof(s32) +
- sizeof(enum NDIS_802_11_NETWORK_TYPE) +
- sizeof(struct NDIS_802_11_CONFIGURATION) +
- sizeof(enum NDIS_802_11_NETWORK_INFRASTRUCTURE) +
- sizeof(NDIS_802_11_RATES_EX) +
- sizeof(u32) + bss->IELength;
- return t_len;
+ return sizeof(*bss) + bss->IELength - MAX_IE_SZ;
}
u8 *r8712_get_capability_from_ie(u8 *ie)
--
2.4.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] PM / devfreq: exynos-ppmu: Add the support of PPMUv2
This patch-set add the support of PPMU ((Platform Performance Monitoring Unit)
version 2.0 which is used on Exynos5433. The exynos-ppmu.c driver supports
both PPMUv1.1 and PPMUv2. This patch-set is testd on Exynos5433-based board.
The SoC list using PPMUv1.1
- Exynos4210/4212/4412, Exynos3250, Exynos5260
The SoC list using PPMUv2
- Exynos5433, Exynos7420
Changes from v1:
(https://lkml.org/lkml/2015/7/22/834)
- Add const keyword to the instance of struct devfreq_event_ops/of_device_id
- Modify the register name of PPMU v2 ('PPMUv2_*' -> 'PPMU_V2_*')
- Reduce the unneed call function of exynos_bus_get_ops()
Chanwoo Choi (2):
PM / devfreq: exynos-ppmu: Add the support of PPMUv2 for Exynos5433
PM / devfreq: exynos-ppmu: Update documentation to support PPMUv2
.../bindings/devfreq/event/exynos-ppmu.txt | 42 -
drivers/devfreq/event/exynos-ppmu.c| 170 -
drivers/devfreq/event/exynos-ppmu.h| 70 +
3 files changed, 273 insertions(+), 9 deletions(-)
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] PM / devfreq: exynos-ppmu: Add the support of PPMUv2 for Exynos5433
This patch adds the support for PPMU (Platform Performance Monitoring Unit)
version 2.0 for Exynos5433 SoC. Exynos5433 SoC must need PPMUv2 which is
quite different from PPMUv1.1. The exynos-ppmu.c driver supports both PPMUv1.1
and PPMUv2.
Cc: MyungJoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/event/exynos-ppmu.c | 170 ++--
drivers/devfreq/event/exynos-ppmu.h | 70 +++
2 files changed, 233 insertions(+), 7 deletions(-)
diff --git a/drivers/devfreq/event/exynos-ppmu.c
b/drivers/devfreq/event/exynos-ppmu.c
index 7d99d13bacd8..f9901f52a225 100644
--- a/drivers/devfreq/event/exynos-ppmu.c
+++ b/drivers/devfreq/event/exynos-ppmu.c
@@ -1,7 +1,7 @@
/*
* exynos_ppmu.c - EXYNOS PPMU (Platform Performance Monitoring Unit) support
*
- * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2014-2015 Samsung Electronics Co., Ltd.
* Author : Chanwoo Choi
*
* This program is free software; you can redistribute it and/or modify
@@ -82,6 +82,15 @@ struct __exynos_ppmu_events {
PPMU_EVENT(mscl),
PPMU_EVENT(fimd0x),
PPMU_EVENT(fimd1x),
+
+ /* Only for Exynos5433 SoCs */
+ PPMU_EVENT(d0-cpu),
+ PPMU_EVENT(d0-general),
+ PPMU_EVENT(d0-rt),
+ PPMU_EVENT(d1-cpu),
+ PPMU_EVENT(d1-general),
+ PPMU_EVENT(d1-rt),
+
{ /* sentinel */ },
};
@@ -96,6 +105,9 @@ static int exynos_ppmu_find_ppmu_id(struct devfreq_event_dev
*edev)
return -EINVAL;
}
+/*
+ * The devfreq-event ops structure for PPMU v1.1
+ */
static int exynos_ppmu_disable(struct devfreq_event_dev *edev)
{
struct exynos_ppmu *info = devfreq_event_get_drvdata(edev);
@@ -200,10 +212,158 @@ static const struct devfreq_event_ops exynos_ppmu_ops = {
.get_event = exynos_ppmu_get_event,
};
+/*
+ * The devfreq-event ops structure for PPMU v2.0
+ */
+static int exynos_ppmu_v2_disable(struct devfreq_event_dev *edev)
+{
+ struct exynos_ppmu *info = devfreq_event_get_drvdata(edev);
+ u32 pmnc, clear;
+
+ /* Disable all counters */
+ clear = (PPMU_CCNT_MASK | PPMU_PMCNT0_MASK | PPMU_PMCNT1_MASK
+ | PPMU_PMCNT2_MASK | PPMU_PMCNT3_MASK);
+
+ __raw_writel(clear, info->ppmu.base + PPMU_V2_FLAG);
+ __raw_writel(clear, info->ppmu.base + PPMU_V2_INTENC);
+ __raw_writel(clear, info->ppmu.base + PPMU_V2_CNTENC);
+ __raw_writel(clear, info->ppmu.base + PPMU_V2_CNT_RESET);
+
+ __raw_writel(0x0, info->ppmu.base + PPMU_V2_CIG_CFG0);
+ __raw_writel(0x0, info->ppmu.base + PPMU_V2_CIG_CFG1);
+ __raw_writel(0x0, info->ppmu.base + PPMU_V2_CIG_CFG2);
+ __raw_writel(0x0, info->ppmu.base + PPMU_V2_CIG_RESULT);
+ __raw_writel(0x0, info->ppmu.base + PPMU_V2_CNT_AUTO);
+ __raw_writel(0x0, info->ppmu.base + PPMU_V2_CH_EV0_TYPE);
+ __raw_writel(0x0, info->ppmu.base + PPMU_V2_CH_EV1_TYPE);
+ __raw_writel(0x0, info->ppmu.base + PPMU_V2_CH_EV2_TYPE);
+ __raw_writel(0x0, info->ppmu.base + PPMU_V2_CH_EV3_TYPE);
+ __raw_writel(0x0, info->ppmu.base + PPMU_V2_SM_ID_V);
+ __raw_writel(0x0, info->ppmu.base + PPMU_V2_SM_ID_A);
+ __raw_writel(0x0, info->ppmu.base + PPMU_V2_SM_OTHERS_V);
+ __raw_writel(0x0, info->ppmu.base + PPMU_V2_SM_OTHERS_A);
+ __raw_writel(0x0, info->ppmu.base + PPMU_V2_INTERRUPT_RESET);
+
+ /* Disable PPMU */
+ pmnc = __raw_readl(info->ppmu.base + PPMU_V2_PMNC);
+ pmnc &= ~PPMU_PMNC_ENABLE_MASK;
+ __raw_writel(pmnc, info->ppmu.base + PPMU_V2_PMNC);
+
+ return 0;
+}
+
+static int exynos_ppmu_v2_set_event(struct devfreq_event_dev *edev)
+{
+ struct exynos_ppmu *info = devfreq_event_get_drvdata(edev);
+ int id = exynos_ppmu_find_ppmu_id(edev);
+ u32 pmnc, cntens;
+
+ /* Enable all counters */
+ cntens = __raw_readl(info->ppmu.base + PPMU_V2_CNTENS);
+ cntens |= (PPMU_CCNT_MASK | (PPMU_ENABLE << id));
+ __raw_writel(cntens, info->ppmu.base + PPMU_V2_CNTENS);
+
+ /* Set the event of Read/Write data count */
+ switch (id) {
+ case PPMU_PMNCNT0:
+ case PPMU_PMNCNT1:
+ case PPMU_PMNCNT2:
+ __raw_writel(PPMU_V2_RO_DATA_CNT | PPMU_V2_WO_DATA_CNT,
+ info->ppmu.base + PPMU_V2_CH_EVx_TYPE(id));
+ break;
+ case PPMU_PMNCNT3:
+ __raw_writel(PPMU_V2_EVT3_RW_DATA_CNT,
+ info->ppmu.base + PPMU_V2_CH_EVx_TYPE(id));
+ break;
+ }
+
+ /* Reset cycle counter/performance counter and enable PPMU */
+ pmnc = __raw_readl(info->ppmu.base + PPMU_V2_PMNC);
+ pmnc &= ~(PPMU_PMNC_ENABLE_MASK
+ | PPMU_PMNC_COUNTER_RESET_MASK
+ | PPMU_PMNC_CC_RESET_MASK
+ | PPMU_PMNC_CC_DIVIDER_MASK
+ | PPMU_V2_PMNC_START_MODE_MASK);
+ pmnc |= (PPMU_ENABLE <<
[PATCH v2 2/2] PM / devfreq: exynos-ppmu: Update documentation to support PPMUv2
This patch updates the documentation to include the information of PPMUv2.
The PPMUv2 is used for Exynos5433 and Exynos7420 to monitor the performance
of each IP in Exynos SoC.
Cc: MyungJoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
.../bindings/devfreq/event/exynos-ppmu.txt | 42 --
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
index b54bf3a2ff57..e8fa6b6a1827 100644
--- a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
+++ b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
@@ -11,7 +11,7 @@ to various devfreq devices. The devfreq devices would use the
event data when
derterming the current state of each IP.
Required properties:
-- compatible: Should be "samsung,exynos-ppmu".
+- compatible: Should be "samsung,exynos-ppmu" or "samsung,exynos-ppmu-v2.
- reg: physical base address of each PPMU and length of memory mapped region.
Optional properties:
@@ -19,7 +19,7 @@ Optional properties:
- clocks : phandles for clock specified in "clock-names" property
- #clock-cells: should be 1.
-Example1 : PPMU nodes in exynos3250.dtsi are listed below.
+Example1 : PPMUv1 nodes in exynos3250.dtsi are listed below.
ppmu_dmc0: ppmu_dmc0@106a {
compatible = "samsung,exynos-ppmu";
@@ -108,3 +108,41 @@ Example2 : Events of each PPMU node in
exynos3250-rinato.dts are listed below.
};
};
};
+
+Example3 : PPMUv2 nodes in exynos5433.dtsi are listed below.
+
+ ppmu_d0_cpu: ppmu_d0_cpu@1048 {
+ compatible = "samsung,exynos-ppmu-v2";
+ reg = <0x1048 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_d0_general: ppmu_d0_general@1049 {
+ compatible = "samsung,exynos-ppmu-v2";
+ reg = <0x1049 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_d0_rt: ppmu_d0_rt@104a {
+ compatible = "samsung,exynos-ppmu-v2";
+ reg = <0x104a 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_d1_cpu: ppmu_d1_cpu@104b {
+ compatible = "samsung,exynos-ppmu-v2";
+ reg = <0x104b 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_d1_general: ppmu_d1_general@104c {
+ compatible = "samsung,exynos-ppmu-v2";
+ reg = <0x104c 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_d1_rt: ppmu_d1_rt@104d {
+ compatible = "samsung,exynos-ppmu-v2";
+ reg = <0x104d 0x2000>;
+ status = "disabled";
+ };
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
Hi, Alexei
On 2015/7/24 11:20, Alexei Starovoitov wrote:
On 7/23/15 1:49 PM, Alexei Starovoitov wrote:
On 7/23/15 4:54 AM, He Kuang wrote:
trimmed cc-list, since it's not related to kernel.
Thank you for your guidence, and by referencing your last mail
and other llvm backends, I found setting
BPFMCAsmInfo::SupportsDebugInformation = true in BPFMCAsmInfo.h
thanks! yes. it was missing.
and fix some unhandeled switch can make llc output debug_info,
what do you mean ?
but important information is missing in the result:
hmm. I see slightly different picture.
With 'clang -O2 -target bpf -g -S a.c'
I see all the right info inside .s file.
with '-c a.c' for some reasons it produces bogus offset:
Abbrev Offset: 0x
Pointer Size: 8
/usr/local/bin/objdump: Warning: Debug info is corrupted, abbrev offset
() is larger than abbrev section size (4b)
and objdump fails to parse .o
I'm using llvm trunk 3.8. Do you see this as well?
there were few issues related to relocations.
Fixed it up and pushed to llvm trunk r243087.
Please pull and give it a try.
AT_location should be correct, but AT_name still looks buggy.
I've pulled the lastest version "[bpf] initial support for
debug_info" and tested it. This version can output debug_info but
still not generate correct AT_location, I tested as following:
$ cat > main.c < test.obj.x86.dump
$ objdump --dwarf=info test.obj.bpf > test.obj.bpf.dump
Compare those two dump files:
test.obj.x86.dump:
<2><43>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<44> DW_AT_location: 3 byte block: 55 93 4(DW_OP_reg5 (rdi);
DW_OP_piece: 4)
<48> DW_AT_name: (indirect string, offset: 0xdc): myvar_a
<4c> DW_AT_decl_file : 1
<4d> DW_AT_decl_line : 1
<4e> DW_AT_type: <0x71>
test.obj.bpf.dump:
<2><43>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<44> DW_AT_name : (indirect string, offset: 0x0): clang
version 3.8.0 (http://llvm.org/git/clang.git
3a7c733b80f156a547f3f1517e6fbce9c0a33026)
(http://llvm.org/git/llvm.git
90908cb34d73460d3 a83e2194a58d82c6d1f199)
<48> DW_AT_decl_file : 1
<49> DW_AT_decl_line : 1
<4a> DW_AT_type: <0x65>
No DW_AT_location info for formal parameters, but if we change
the function 'testprog' to 'main', DW_AT_location of formal
parameters appear but that of local variables are still missed,
don't know why..
$ cat > main.c <
int main(int argc, char *argv[])
{
int myvar_a, myvar_b;
int myvar_c;
myvar_c = myvar_a + myvar_b;
return myvar_c;
}
test.obj.bpf.dump:
<2><43>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<44> DW_AT_location: 1 byte block: 51 (DW_OP_reg1 (r1))
<46> DW_AT_name: (indirect string, offset: 0x0): clang version 3.8.
..
<2><5d>: Abbrev Number: 4 (DW_TAG_variable)
<5e> DW_AT_name: (indirect string, offset: 0x0): clang version 3.8.
test.obj.x86.dump:
<2><43>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<44> DW_AT_location: 3 byte block: 55 93 4(DW_OP_reg5 (rdi);
DW_OP_piece: 4)
<48> DW_AT_name: (indirect string, offset: 0xd8): argc
..
<2><5f>: Abbrev Number: 4 (DW_TAG_variable)
<60> DW_AT_name: (indirect string, offset: 0xe7): myvar_a
..
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] can: xilinx: fix RX FIFO overflow error handling
+ Kedar
On 07/23/2015 11:13 PM, Andrea Scian wrote:
> Simply resetting the peripheral on RX FIFO overflow in not enough,
> because we also need to re-initialize the whole device.
> Also always enable RX FIFO overflow interrupt otherwise we may hang
> until another interrupt arrives (this happens if FIFO overrun and just
> read from CAN bus with candump)
>
> Signed-off-by: Andrea Scian
> ---
>
> You can reproduce the problem with the following test-bed
> * connect a Zynq based board to a PC with a CAN bus adapter (e.g. PCAN USB)
> * start sending lots of CAN messages to Zynq system
> * configure and start xilinx CAN driver
> ** canconfig can0 bitrate 100
> ** canconfig can0 start
> * try to send/receive messages (cansend/candump)
> * if you send a CAN message you'll get the RX FIFO error and additional
> messages
> will not be received
> * if you try to get messages you simple don't receive them (no interrupt
> triggered)
> * with canconfig stop/start the hang goes away (if the others peers stop
> sending
> send lots of messages ;-) )
>
> I tested the patch over xilinx-2014.04 kernel, but the patch applies cleanly
> to
> mainline too.
>
> If someone has a better understanding of Xilinx CAN driver, please let me
> know if
> it's better to handle the error in a different manner.
>
> Maybe the bus off handler need the same threadment too.
>
> TIA,
>
> Andrea Scian
>
> ---
> drivers/net/can/xilinx_can.c |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
> index 5e8b560..c278177 100644
> --- a/drivers/net/can/xilinx_can.c
> +++ b/drivers/net/can/xilinx_can.c
> @@ -100,6 +100,7 @@ enum xcan_reg {
> #define XCAN_INTR_ALL(XCAN_IXR_TXOK_MASK |
> XCAN_IXR_BSOFF_MASK |\
>XCAN_IXR_WKUP_MASK | XCAN_IXR_SLP_MASK | \
>XCAN_IXR_RXNEMP_MASK | XCAN_IXR_ERROR_MASK | \
> + XCAN_IXR_RXOFLW_MASK | \
>XCAN_IXR_ARBLST_MASK | XCAN_IXR_RXOK_MASK)
>
> /* CAN register bit shift - XCAN___SHIFT */
> @@ -526,6 +527,7 @@ static int xcan_rx(struct net_device *ndev)
> return 1;
> }
>
> +static void xcan_chip_stop(struct net_device *ndev);
> /**
> * xcan_err_interrupt - error frame Isr
> * @ndev:net_device pointer
> @@ -597,7 +599,8 @@ static void xcan_err_interrupt(struct net_device *ndev,
> u32 isr)
> if (isr & XCAN_IXR_RXOFLW_MASK) {
> stats->rx_over_errors++;
> stats->rx_errors++;
> - priv->write_reg(priv, XCAN_SRR_OFFSET, XCAN_SRR_RESET_MASK);
> + xcan_chip_stop(ndev);
> + xcan_chip_start(ndev);
> if (skb) {
> cf->can_id |= CAN_ERR_CRTL;
> cf->data[1] |= CAN_ERR_CRTL_RX_OVERFLOW;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] irqchip: bcm2835: If a parent interrupt is registered, chain from it.
On 07/22/2015 12:17 PM, Eric Anholt wrote: > Stephen Warren writes: > >> On 07/13/2015 07:35 PM, Eric Anholt wrote: >>> The BCM2836 (Raspberry Pi 2) uses two levels of interrupt >>> handling with the CPU-local interrupts being the root, so we >>> need to register ours as chained off of the CPU's local >>> interrupt. >> >> Sorry for the slow review; laziness after vacation! >> >>> diff --git >>> a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt >>> b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt >> >>> >>> +The BCM2836 contains the same interrupt controller with the same >>> +interrupts, but the per-CPU interrupt controller is the root, >>> and an +interrupt there indicates that the ARMCTRL has an >>> interrupt to handle. + Required properties: >>> >>> - compatible : should be "brcm,bcm2835-armctrl-ic" >> >> Since there are some differences between the bcm2835 and bcm2836 >> HW blocks, I'd expect the compatible value to be different for >> each. In particular... > > Well, there are actually no differences within this block of the HW > (HDL is unmodified), it's just where the output interrupt line gets > consumed. But it's not much extra to add a new compatible value, so > sure. Mmm. I suppose that's true indeed. So, I guess either of the following is fine for bcm2836 by me: compatible = "brcm,bcm2836-armctrl-ic"; compatible = "brcm,bcm2836-armctrl-ic", "brcm,bcm2835-armctrl-ic"; The 2836 value is always needed since DT should contain the most specific compatible value for the implementation. The 2835 value is optional based on whether the HW block is 100% backwards-compatible with the older HW block; a driver for the old block can run unmodified against the new block. It's debatable whether that's true here; the interface to this HW block itself is unchanged between implementations, yet the way the driver for it integrates into the system differs since it either is/isn't a top-level IRQ chip. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] usb/gadget: make composite gadget meet usb compliance for vbus draw
Thanks, Pietrasiewicz.
> From: Andrzej Pietrasiewicz [mailto:andrze...@samsung.com]
> W dniu 23.07.2015 o 14:34, Du, Changbin pisze:
> >>From 0a8e0d63a9887735c6782d7b0c15c2c1fdf1952a Mon Sep 17 00:00:00
> > void composite_disconnect(struct usb_gadget *gadget)
> > {
> > struct usb_composite_dev*cdev = get_gadget_data(gadget);
> > @@ -2095,7 +2119,7 @@ void composite_suspend(struct usb_gadget
> *gadget)
> >
> > cdev->suspended = 1;
> >
> > - usb_gadget_vbus_draw(gadget, 2);
> > + usb_gadget_vbus_draw(gadget, USB_VBUS_DRAW_SUSPEND);
> > }
>
> This looks like an unrelated change. I think it should go first
> in a separate patch which eliminates usage of "magic" numbers.
>
This change does make sense. As you know, when device is reset, it is in a
'unconfigured'
state. Compliance Test equipment may also measure vbus current at this moment.
> > }
> > @@ -2132,7 +2157,7 @@ static const struct usb_gadget_driver
> composite_driver_template = {
> > .unbind = composite_unbind,
> >
> > .setup = composite_setup,
> > - .reset = composite_disconnect,
> > + .reset = composite_reset,
> > .disconnect = composite_disconnect,
> >
>
> A similar "template" is in drivers/usb/gadget/configfs.c. Shouldn't the
> "reset"
> method be changed there as well?
>
Yes, it also need to change. I will change it as well.
>
> >
> > +/* USB2 compliance requires that un-configured current draw <= 100mA,
> > + * USB3 requires it <= 150mA, OTG requires it <= 2.5mA.
> > + */
> > +#define USB2_VBUS_DRAW_UNCONF 100
> > +#define USB3_VBUS_DRAW_UNCONF 150
> > +#define USB_OTG_VBUS_DRAW_UNCONF 2
>
>
> > +#define USB_VBUS_DRAW_SUSPEND 2
>
> separate patch
>
Sorry, I didn't get your idea. Why separate these macros definition?
>
> Thanks,
>
> AP
Regards
Changbin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] RTC: make rtc_does_wakealarm() return boolean
On 24.07.2015 08:01, Dmitry Torokhov wrote: > Users of rtc_does_wakealarm() return value treat it as boolean so let's > change the signature accordingly. > > Signed-off-by: Dmitry Torokhov > --- > drivers/rtc/rtc-sysfs.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) Thanks for splitting this. Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] RTC: switch to using is_visible() to control sysfs attributes
On 24.07.2015 08:01, Dmitry Torokhov wrote: > Instead of creating wakealarm attribute manually, after the device has been > registered, let's rely on facilities provided by the attribute groups to > control which attributes are visible and which are not. This allows to to > create all needed attributes at once, at the same time that we register RTC > class device. > > Signed-off-by: Dmitry Torokhov > --- > drivers/rtc/class.c | 4 +--- > drivers/rtc/rtc-core.h | 19 +++- > drivers/rtc/rtc-sysfs.c | 59 > + > 3 files changed, 34 insertions(+), 48 deletions(-) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] RTC: switch wakealarm attribute to DEVICE_ATTR_RW
On 24.07.2015 08:01, Dmitry Torokhov wrote: > Instead of using older style DEVICE_ATTR for wakealarm attribute let's > switch to using DEVICE_ATTR_RW that ensures consistent across the kernel > permissions on the attribute. > > Signed-off-by: Dmitry Torokhov > --- > drivers/rtc/rtc-sysfs.c | 8 +++- > 1 file changed, 3 insertions(+), 5 deletions(-) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/3] cpufreq: Use cpufreq-dt driver for Exynos3250
On 07/24/15 12:40, Kukjin Kim wrote: > On 07/24/15 09:30, Michael Turquette wrote: >> Quoting Kukjin Kim (2015-07-07 07:43:31) >>> Bartlomiej Zolnierkiewicz wrote: > > [...] > > Chanwoo Choi (3): > clk: samsung: exynos3250: Add cpu clock configuration data and > instaniate cpu clock > ARM: dts: Add CPU OPP and regulator supply property for Exynos3250 > ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver > > arch/arm/boot/dts/exynos3250-monk.dts | 4 > arch/arm/boot/dts/exynos3250-rinato.dts | 4 > arch/arm/boot/dts/exynos3250.dtsi | 15 +++ > arch/arm/mach-exynos/exynos.c | 1 + > drivers/clk/samsung/clk-exynos3250.c| 32 > ++-- > include/dt-bindings/clock/exynos3250.h | 1 + > 6 files changed, 55 insertions(+), 2 deletions(-) Reviewed-by: Bartlomiej Zolnierkiewicz Thank you for working on this. >>> +1 Thanks. >>> >>> Mike and Sylwester, if you're OK on this series, I'd like to pick up in >>> Samsung >>> tree together. And if you want, I could provide topic branch for clk tree. >> >> Kukjin, >> >> A topic branch would be great. >> > Sure, BTW it means you did 'ack' on this clk change? If not, please let > em know ;-) I'll let you know once the topic branch is ready. > Mike, Done, the topic branch 'v4.3-topic/clk-samsung' in samsung tree is for your clk tree. Thanks, Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] clk: remove duplicated code with __clk_set_parent_after
On Thu, Jul 23, 2015 at 05:11:35PM -0700, Michael Turquette wrote:
> Quoting Dong Aisheng (2015-07-22 07:08:10)
> > Ping...
> >
> > On Wed, Jul 15, 2015 at 08:29:56PM +0800, Dong Aisheng wrote:
> > > On Wed, Jul 15, 2015 at 08:25:24PM +0800, Dong Aisheng wrote:
> > > > Hi Mike,
> > > >
> > > > On Wed, May 27, 2015 at 09:09:19PM -0700, Michael Turquette wrote:
> > > > > Quoting Dong Aisheng (2015-05-14 06:28:59)
> > > > > > __clk_set_parent_after() actually used the second argument then we
> > > > > > could put this duplicate logic in there and call it with a different
> > > > > > order of arguments in the success vs. error paths in this function.
> > > > > >
> > > > > > Cc: Mike Turquette
> > > > > > Cc: Stephen Boyd
> > > > > > Suggested-by: Stephen Boyd
> > > > > > Signed-off-by: Dong Aisheng
> > > > >
> > > > > Patch looks good to me.
> > > > >
> > > > > Also just noticed that the second argument to __clk_set_parent_after
> > > > > is
> > > > > never used :-(
> > > > >
> > > >
> > > > Ping...
> > > >
> > > > I did not see this patch series in your tree for v4.2 rc.
> > > > Is this got missed?
>
> Dong Aisheng,
>
> Yes it was missed. My apologies. Can you refresh it and re-send?
>
Will do it.
Thanks
Regards
Dong Aisheng
> Thanks,
> Mike
>
> > > >
> > >
> > > Updated Mike's email address.
> > >
> > > Regards
> > > Dong Aisheng
> > >
> > > > Regards
> > > > Dong Aisheng
> > > >
> > > > > Regards,
> > > > > Mike
> > > > >
> > > > > > ---
> > > > > > drivers/clk/clk.c | 8 +---
> > > > > > 1 file changed, 1 insertion(+), 7 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > > > > > index 659f2b0..0e813ea 100644
> > > > > > --- a/drivers/clk/clk.c
> > > > > > +++ b/drivers/clk/clk.c
> > > > > > @@ -1159,14 +1159,8 @@ static int __clk_set_parent(struct clk_core
> > > > > > *core, struct clk_core *parent,
> > > > > > flags = clk_enable_lock();
> > > > > > clk_reparent(core, old_parent);
> > > > > > clk_enable_unlock(flags);
> > > > > > + __clk_set_parent_after(core, old_parent, parent);
> > > > > >
> > > > > > - if (core->prepare_count) {
> > > > > > - flags = clk_enable_lock();
> > > > > > - clk_core_disable(core);
> > > > > > - clk_core_disable(parent);
> > > > > > - clk_enable_unlock(flags);
> > > > > > - clk_core_unprepare(parent);
> > > > > > - }
> > > > > > return ret;
> > > > > > }
> > > > > >
> > > > > > --
> > > > > > 1.9.1
> > > > > >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irqchip: bcm2835: Add FIQ support
On 07/22/2015 08:07 AM, Noralf Trønnes wrote: > > Den 18.06.2015 04:26, skrev Stephen Warren: >> On 06/12/2015 11:26 AM, Noralf Trønnes wrote: >>> Add a duplicate irq range with an offset on the hwirq's so the >>> driver can detect that enable_fiq() is used. >>> Tested with downstream dwc_otg USB controller driver. >> This basically looks OK, but a few comments/thoughts: >> >> a) Should the Kconfig change be a separate patch since it's a separate >> subsystem? > > Is this a yes since you haven't acked it? I didn't ack it because I thought there were still outstanding review comments. Looking back at the thread, everything is resolved. Acked-by: Stephen Warren Whether the driver and Kconfig patch need to be in separate patches largely depends on who will merge it. If there's a desire to merge the two parts through separate subsystems, separate patches will be needed, else not. I'll leave that up to the IRQ subsystem maintainers and Lee (or Eric) since they're actually merging the bcm2835 patches. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the vhost tree with Linus' tree
Hi Michael,
Today's linux-next merge of the vhost tree got a conflict in:
drivers/vhost/vhost.c
between commit:
4de7255f7d2b ("vhost: extend memory regions allocation to vmalloc")
from Linus' tree and commit:
a4883f62470c ("vhost: extend memory regions allocation to vmalloc")
from the vhost tree.
These are two slightly different versions of the same patch. I used
the version from Linus' tree. Please clean your tree up.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] arm64:use set_fixmap_offset to make it more clear
> On Jul 23, 2015, at 21:03, Catalin Marinas wrote: > > On Thu, Jul 23, 2015 at 07:45:53PM +0800, yalin wang wrote: >> A little change to patch_map() function, >> use set_fixmap_offset() to make code more clear. >> >> Signed-off-by: yalin wang >> --- >> arch/arm64/kernel/insn.c | 5 ++--- >> 1 file changed, 2 insertions(+), 3 deletions(-) >> >> diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c >> index dd9671c..7dafd5a 100644 >> --- a/arch/arm64/kernel/insn.c >> +++ b/arch/arm64/kernel/insn.c >> @@ -101,9 +101,8 @@ static void __kprobes *patch_map(void *addr, int fixmap) >> return addr; >> >> BUG_ON(!page); >> -set_fixmap(fixmap, page_to_phys(page)); >> - >> -return (void *) (__fix_to_virt(fixmap) + (uintaddr & ~PAGE_MASK)); >> +return (void *)set_fixmap_offset(fixmap, page_to_phys(page) + >> +(addr & ~PAGE_MASK)); > > It looks fine. Do you get any compiler warning for the automatic pointer > to long conversion? You may want to add some explicit casts, otherwise: > > Acked-by: Catalin Marinas i have build it, there is no warning about this change. :) Thanks-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
A problem about OX_ID reused by FCoE driver
From: Wu Yanjiang Hi all, On a system that was running 3.0.13-0.27-default, a problem that the OX_ID is reused by FCoE driver occurred. Which can be confirmed is that the problem is occurred at initiator side, but the reason how does it happen is unknown. By the trace captured by JDSU protocol analyzer, the initiator initiated a read command about 10 seconds after the virtual link resumed . But about 10ms later, the initiator send ABTS to abort the read command. Then the OX_ID was reused for a new command immediately without abort response from target side and RRQ process. Test environment ： Initiator OS: SLES 11 SP2 (3.0.13-0.27-default) Initiator CNA: INTEL X520-SR2 Test step： 1.INTEL X520-SR2 connect to intel 82599 card in target directly 2.Initiator initiates write and read command to target by FCoE VN2VN protect 3.Disconnect the physical link then reconnect it Any advice is welcome. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/3] clk: samsung: exynos3250: Add cpu clock configuration data and instaniate cpu clock
On 07/20/15 09:23, Chanwoo Choi wrote:
> Hi Sylwester,
>
Hi Chanwoo,
> Please review this patch.
>
Applied with Mike's ack BTW please make sure your patch has no problem
with checkpatch before submittingI've fixed them when I applied.
Thanks,
Kukjin
ERROR: code indent should use tabs where possible
#49: FILE: drivers/clk/samsung/clk-exynos3250.c:779:
+ (((apll) << 24) | ((pclk_dbg) << 20) | ((atb) << 16) | \$
WARNING: please, no spaces at the start of a line
#49: FILE: drivers/clk/samsung/clk-exynos3250.c:779:
+ (((apll) << 24) | ((pclk_dbg) << 20) | ((atb) << 16) | \$
ERROR: code indent should use tabs where possible
#50: FILE: drivers/clk/samsung/clk-exynos3250.c:780:
+ ((corem) << 4))$
WARNING: please, no spaces at the start of a line
#50: FILE: drivers/clk/samsung/clk-exynos3250.c:780:
+ ((corem) << 4))$
WARNING: please, no spaces at the start of a line
#55: FILE: drivers/clk/samsung/clk-exynos3250.c:785:
+ { 100, E3250_CPU_DIV0(1, 7, 4, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#56: FILE: drivers/clk/samsung/clk-exynos3250.c:786:
+ { 90, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#57: FILE: drivers/clk/samsung/clk-exynos3250.c:787:
+ { 80, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#58: FILE: drivers/clk/samsung/clk-exynos3250.c:788:
+ { 70, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#59: FILE: drivers/clk/samsung/clk-exynos3250.c:789:
+ { 60, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#60: FILE: drivers/clk/samsung/clk-exynos3250.c:790:
+ { 50, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#61: FILE: drivers/clk/samsung/clk-exynos3250.c:791:
+ { 40, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#62: FILE: drivers/clk/samsung/clk-exynos3250.c:792:
+ { 30, E3250_CPU_DIV0(1, 5, 3, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#63: FILE: drivers/clk/samsung/clk-exynos3250.c:793:
+ { 20, E3250_CPU_DIV0(1, 3, 3, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#64: FILE: drivers/clk/samsung/clk-exynos3250.c:794:
+ { 10, E3250_CPU_DIV0(1, 1, 1, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#65: FILE: drivers/clk/samsung/clk-exynos3250.c:795:
+ { 0 },$
total: 2 errors, 13 warnings, 63 lines checked
NOTE: Whitespace errors detected.
You may wish to use scripts/cleanpatch or scripts/cleanfile
[PATCH v6 1_3] clk: samsung: exynos3250: Add cpu clock configuration
data and instaniate cpu clock.eml has style problems, please review.
> Best Regards,
> Chanwoo Choi
>
> On 07/16/2015 04:46 PM, Krzysztof Kozlowski wrote:
>> 2015-07-02 9:42 GMT+09:00 Chanwoo Choi :
>>> This patch add CPU clock configuration data and instantiate the CPU clock
>>> type
>>> for Exynos3250 to support Samsung specific cpu-clock type.
>>>
>>> Cc: Sylwester Nawrocki
>>> Cc: Tomasz Figa
>>> Signed-off-by: Chanwoo Choi
>>> Acked-by: Kyungmin Park
>>> Reviewed-by: Krzysztof Kozlowski
>>> ---
>>> drivers/clk/samsung/clk-exynos3250.c | 32
>>> ++--
>>> include/dt-bindings/clock/exynos3250.h | 1 +
>>
>> Sylwester,
>>
>> I think this patch also waits for your review or ack.
>> The patchset is rebased on Bartlomiej's series for Exynos5250 cpufreq
>> so the easiest way would be to take it through samsung-soc tree.
>>
>> Best regards,
>> Krzysztof
>>
>>
>>> 2 files changed, 31 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/clk/samsung/clk-exynos3250.c
>>> b/drivers/clk/samsung/clk-exynos3250.c
>>> index 538de66a759e..378ad5ad3492 100644
>>> --- a/drivers/clk/samsung/clk-exynos3250.c
>>> +++ b/drivers/clk/samsung/clk-exynos3250.c
>>> @@ -19,6 +19,7 @@
>>> #include
>>>
>>> #include "clk.h"
>>> +#include "clk-cpu.h"
>>> #include "clk-pll.h"
>>>
>>> #define SRC_LEFTBUS0x4200
>>> @@ -319,8 +320,10 @@ static struct samsung_mux_clock mux_clks[] __initdata
>>> = {
>>> MUX(CLK_MOUT_MPLL_USER_C, "mout_mpll_user_c", mout_mpll_user_p,
>>> SRC_CPU, 24, 1),
>>> MUX(CLK_MOUT_HPM, "mout_hpm", mout_hpm_p, SRC_CPU, 20, 1),
>>> - MUX(CLK_MOUT_CORE, "mout_core", mout_core_p, SRC_CPU, 16, 1),
>>> - MUX(CLK_MOUT_APLL, "mout_apll", mout_apll_p, SRC_CPU, 0, 1),
>>> + MUX_F(CLK_MOUT_CORE, "mout_core", mout_core_p, SRC_CPU, 16, 1,
>>> + CLK_SET_RATE_PARENT, 0),
>>> + MUX_F(CLK_MOUT_APLL, "mout_apll", mout_apll_p, SRC_CPU, 0, 1,
>>> +
Re: [Patch V4 1/3] usb: Add Xen pvUSB protocol description
On 07/23/2015 09:08 PM, Greg KH wrote: On Thu, Jul 23, 2015 at 08:46:17AM +0200, Juergen Gross wrote: On 07/23/2015 06:36 AM, Greg KH wrote: On Thu, Jul 23, 2015 at 06:04:39AM +0200, Juergen Gross wrote: On 07/23/2015 01:46 AM, Greg KH wrote: On Tue, Jun 23, 2015 at 08:53:23AM +0200, Juergen Gross wrote: Add the definition of pvUSB protocol used between the pvUSB frontend in a Xen domU and the pvUSB backend in a Xen driver domain (usually Dom0). This header was originally provided by Fujitsu for Xen based on Linux 2.6.18. Changes are: - adapt to Linux style guide Signed-off-by: Juergen Gross --- include/xen/interface/io/usbif.h | 252 +++ Why is this a different interface than the existing ones we have today (i.e. usbip?) Where is it documented? Do the Xen developers / The interface definition is living in the Xen git repository for several years now: git://xenbits.xen.org/xen.git -> xen/include/public/io/usbif.h That's header file, not a document describing the api here. I suppose you want to tell me I should add something like: Documentation/DocBook/usb/API-struct-urb.html Somewhere that people can refer to that describes this public-facing API that "must not ever be broken or changed". If you want to put it in a documentation file, or a .h file, I don't care. > It is used e.g. in SUSE's xen kernel since 2.6.18. I am very aware of the amount of Xen crap in SuSE's kernel, don't use that as an excuse for me to merge it to mainline :) :-) Wasn't meant as an excuse, just a hint why the interface can't be the same as for usbip. We have to ensure compatibility with those kernels This shouldn't be a kernel/kernel compability issue, as the api talks between Xen and the OS, not between different OSs, right? Depends on where the backend is living. It's the backend the frontend is talking to. There is a backend in SUSE's kernels up to SLE12. So compatibility is to be maintained to those kernels. Looks as if in future there will be one in qemu. and possibly other operating systems (BSD?, Windows?) which already might be using pvUSB with a Dom0 based on the SUSE xen kernel. Are there other operating system drivers today that use this API? Is this an API in the Xen core today that we have to support? Yes. Some more background / descriptions would be nice to have. I guess a documentation file giving a brief explanation about the interfaces of Xen wouldn't be a bad idea. This could avoid discussions like this. It shouldn't define each interface, but the classes of interfaces which are existing (between kernel and hypervisor, frontends and backends) and the stability requirements. Headers like the one we are discussing here could then refer to this document. Juergen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] clk: samsung: exynos5250: add cpu clock configuration data and instantiate cpu clock
On 07/24/15 09:39, Michael Turquette wrote: > Quoting Bartlomiej Zolnierkiewicz (2015-07-01 06:10:35) >> From: Thomas Abraham >> >> With the addition of the new Samsung specific cpu-clock type, the >> arm clock can be represented as a cpu-clock type. Add the CPU clock >> configuration data and instantiate the CPU clock type for Exynos5250. >> >> Changes by Bartlomiej: >> - split Exynos5250 support from the original patch >> - moved E5250_CPU_DIV[0,1]() macros to clk-exynos5250.c >> >> Cc: Tomasz Figa >> Cc: Michael Turquette >> Cc: Javier Martinez Canillas >> Signed-off-by: Thomas Abraham >> Signed-off-by: Bartlomiej Zolnierkiewicz > > Acked-by: Michael Turquette > Thanks, Mike. > If Kukjin wants to merge this through the samsung tree then an immutable > branch would be much appreciated. > Here is the topic branch for clk tree and it will not be rebased. git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v4.3-topic/clk-samsung If any problems, please kindly let me know. Thanks, Kukjin > Regards, > Mike > >> --- >> drivers/clk/samsung/clk-exynos5250.c | 31 +++ >> include/dt-bindings/clock/exynos5250.h | 1 + >> 2 files changed, 32 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 6/7] staging: add simple-fpga-bus
On Thu, 23 Jul 2015, Jason Gunthorpe wrote: > On Thu, Jul 23, 2015 at 02:55:52PM -0700, Moritz Fischer wrote: > > Hi Alan, > > > > I saw that your socfpga driver doesn't support the partial reconfig > > use case (not a big deal). > > What I currently do for Zynq is if I'm doing a non-partial reconfig is > > that I disable input > > level shifters and assert *all* resets while reprogramming in my FPGA > > manager .write_init() and .write_complete(). > > I do this as well, but it is a bit more complex.. FPGA specific code > has to run around and ensure all DMA is shut off, then we need to make > sure no CPU issued AXI transactions can happen, then we can tear down > the FPGA side. > > If the FPGA is torn down while an AXI op is inprogress things go > sideways, we have to work to prevent that :) > > This happens almost for free, I use DT and the device model to > disconnect the drivers. The drivers are careful to synchronously fence > off in-progress DMA. Then drop the DT nodes associated with the > FPGA, finally the actual FPGA cells can be reset. Yes, the kernel gives us this almost for free. That's what I like about using DT overlays to control FPGA programming. > > > In a partial reconfiguration situation, would I have separate > > simple-fpga buses for each of the parts that I swap out, each with > > it's own reset and bitfile attached? > > I'd think of partial reconfiguration as another nested FPGA. The > resets and so forth could be attached to soft controllers in the > unswappable part of the FPGA. > > DT nodes have to surround it in some way... > > Jason > Yes, in this way each PR chunk will need its own reset so it won't wiggle busses and affect the rest of the system during PR. I noticed that currently simple-fpga-bus.c holds an exclusive ref of the fpga manager. This would keep a 2nd pr from being able to access the same fpga manager, so I'll have to change it so that simple-fpga-bus.c will put the ref before exiting probe. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/9] arm: twr-k70f120m: clock driver for Kinetis SoC
Quoting Paul Osmialowski (2015-07-04 14:50:03)
> Hi Arnd,
>
> I'm attaching excerpt from Kinetis reference manual that may make
> situation clearer.
Hi Paul,
Can you please post the patch in the body of the email instead of an
attachment? It makes it easier to review. Another small nitpick is that
the $SUBJECT for this patch might be better off as something like:
clk: mcg and sim clock drivers for twr-k70f120m Kinetis SoC
At least it helps me find the patch I care about when skimming the
series ;-)
>
> These MCG and SIM registers are used only to determine configuration
> (clock fixed rates and clock signal origins) at run time.
>
> Namely, the real MCGOUTCLK source (in the middle) which is the parent for
> core clock (CCLK) and peripheral clock (PCLK) is determined at run time by
> reading MCG registers, let me quote commit message from Emcraft git repo:
>
> * Determine in run-time what oscillator module (OSC0 or OSC1) is used
> as clock source for the main PLL.
According to [0] there are three options: a 32k RTC osc clock and osc0
both feed into a mux. You should model this 32k clock with the
fixed-rate binding.
> * When OSC1 is selected, assume its frequency to be 12 MHz on all
> boards (there is a 12 MHz oscillator on XTAL1/EXTAL1 on K70-SOM and
> TWR-K70F120M boards).
>
> In my .dts I'm trying to possibly follow real clock hierarchy, but to go
> anywhere behind MCGOUTCLK would require ability to rewrite .dtb e.g. by
> U-boot. But that's too demanding for any potential users of this BSP. So
> let's asume that MCGOUTCLK is the root clock and a parent for CCLK and
> PCLK.
I'm confused. The point of device tree is to solve problems like this;
i.e. board-specific differences such as different oscillator
frequencies.
OSC0 and OSC1 should each be a fixed-rate clock in your board-specific
TWR-K70F120M DTS (not a chip-specific file). They do not belong in the
cmu node, and they should use the "fixed-clock" binding. The 32k RTC osc
can probably go in your chip-specific .dtsi as a fixed-rate clock since
it appears to mandated in the reference manual[0].
These three fixed-rate clocks are your root clock nodes. Customers only
need to worry about this if they spin a board, and then they will need
to populate the frequencies of OSC0 and OSC1 in their board-specific
.dts.
Please break clk-kinetis.c into two files:
drivers/clk/kinetis/clk-mcg.c
drivers/clk/kinetis/clk-sim.c
Below is what your binding/dts should look like:
{
osc0: clock {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <5000>;
};
osc1: clock {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <1200>;
};
rtc: clock {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <32768>;
};
soc: soc {
mcg: clock-controller@40064000 {
compatible = "fsl,kinetis-mcg";
clock-cells = <1>;
reg = <0x40064000 0x14>;
clocks = <>, <>, <>;
clock-names = "osc0", "osc1", "rtc";
};
sim: clock-controller@40047000 {
compatible = "fsl,kinetis-sim";
clock-cells = <1>;
reg = <0x40047000 0x1100>;
clocks = < MCG_MCGOUTCLK_DIV1>, <
MCG_MCGOUTCLK_DIV2>, < MCG_MCGOUTCLK_DIV3> < MCG_MCGOUTCLK_DIV4>;
clock-names = "core", "bus", "flexbus", "flash";
};
};
uart0: serial@4006a000 {
compatible = "fsl,kinetis-lpuart";
reg = <0x4006a000 0x1000>;
clocks = < SIM_SCGC4_UART1_CLK>;
clock-names = "gate";
};
I removed the interrupts and dma stuff from the uart0 node for clarity.
The above is the only style of binding that I have been accepting for
some time; first declare the clock controller and establish its register
space, and then consumers can consume clocks by providing the phandle to
the controller plus an offset corresponding to a unique clock. The
clock-names property makes it really easy to use with the clkdev stuff
(e.g. clk_get()).
I've covered this before on the mailing list so here is a link
describing how the qcom bindings do it in detail:
http://lkml.kernel.org/r/<20150416192014.19585.9663@quantum>
Technically you could encode the same bits as sub-nodes of the mcg and
sim nodes, but the shared header is how the magic happens with the
driver so it's best to keep the clock controller binding small and
light.
I think this means you can also get rid of kinetis_of_clk_get_name and
kinetis_clk_gate_get but my brain is tired so I'll leave that as an
exercise to the reader.
[0]
Re: [PATCH v6 0/3] cpufreq: Use cpufreq-dt driver for Exynos3250
On 07/24/15 09:30, Michael Turquette wrote: > Quoting Kukjin Kim (2015-07-07 07:43:31) >> Bartlomiej Zolnierkiewicz wrote: [...] Chanwoo Choi (3): clk: samsung: exynos3250: Add cpu clock configuration data and instaniate cpu clock ARM: dts: Add CPU OPP and regulator supply property for Exynos3250 ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver arch/arm/boot/dts/exynos3250-monk.dts | 4 arch/arm/boot/dts/exynos3250-rinato.dts | 4 arch/arm/boot/dts/exynos3250.dtsi | 15 +++ arch/arm/mach-exynos/exynos.c | 1 + drivers/clk/samsung/clk-exynos3250.c| 32 ++-- include/dt-bindings/clock/exynos3250.h | 1 + 6 files changed, 55 insertions(+), 2 deletions(-) >>> >>> Reviewed-by: Bartlomiej Zolnierkiewicz >>> >>> Thank you for working on this. >>> >> +1 Thanks. >> >> Mike and Sylwester, if you're OK on this series, I'd like to pick up in >> Samsung >> tree together. And if you want, I could provide topic branch for clk tree. > > Kukjin, > > A topic branch would be great. > Sure, BTW it means you did 'ack' on this clk change? If not, please let em know ;-) I'll let you know once the topic branch is ready. Thanks, Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs
On Wed, 2015-07-22 at 11:25 -0400, Tejun Heo wrote:
> Hello,
>
> On Wed, Jul 22, 2015 at 05:19:00PM +0200, Mike Galbraith wrote:
> > Ew, looking at the numbers, they may prefer to either a) pretend to not
> > notice, or b) scurry off to HPC'R'US store if a) won't fly ;-)
>
> Yeah, there are a lot of them. The sad part is that only very few of
> them would actually need local binding for correctness. :(
I'm going to end this thread with an under my breath mutter. Before I
do that, note that I went and beat up three different boxen over days
before turning trivial little patchlet loose, ie I was quite paranoid
despite the below, "No way Jose" was not entirely unexpected.
Mutter: WORK_CPU_UNBOUND is about as far from a local execution
guarantee as it gets, and not only is it prominently displayed for all
to see...
/**
* queue_work - queue work on a workqueue
* @wq: workqueue to use
* @work: work to queue
*
* Returns %false if @work was already on a queue, %true otherwise.
*
* We queue the work to the CPU on which it was submitted, but if the CPU dies
* it can be processed by another CPU.
*/
static inline bool queue_work(struct workqueue_struct *wq,
struct work_struct *work)
{
return queue_work_on(WORK_CPU_UNBOUND, wq, work);
}
...there's nothing ambiguous about that. While it states that we queue
locally, it also clearly states that local execution is NOT guaranteed,
making assumption thereof a BUG, which in turn makes it seem a bit odd
to tie fixing up nohz_full a little to auditing and fixing every booboo
ever made (unlikely to ever happen). It would appear that the only way
anyone could ever have sanely assume local execution, WORK_CPU_UNBOUND
aside, is to have called get_online_cpus() before queueing any work.
Mutter expressed, it's not a big hairy deal, anyone using an SMP kernel
with an expectation of zero perturbation is doomed to be disappointed
anyway, patchlet just reduced noise a bit.
-Mike (mutter mutter mutter;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] dt-bindings: regulator: mt6311: Add document for mt6311 regulator
Hi Javier,
On Thu, 2015-07-23 at 10:43 +0200, Javier Martinez Canillas wrote:
> Hello Henry,
>
> On Thu, Jul 23, 2015 at 5:39 AM, Henry Chen wrote:
> > This patch adds a list of supported regulator names to the devicetree
> > binding documentation for Mediatek MT6311 PMIC.
> >
> > Signed-off-by: Henry Chen
> > ---
> > .../bindings/regulator/mt6311-regulator.txt| 35
> > ++
> > 1 file changed, 35 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
> > b/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
> > new file mode 100644
> > index 000..9387d6d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
> > @@ -0,0 +1,35 @@
> > +Mediatek MT6311 Regulator Driver
> > +
> > +Required properties:
> > +- compatible: "mediatek,mt6311-regulator"
> > +- reg: I2C slave address, usually 0x6b.
> > +- regulators: List of regulators provided by this controller. It is named
> > + to VDVFS and VBIASN.
> > + The definition for each of these nodes is defined using the standard
> > binding
> > + for regulators at
> > Documentation/devicetree/bindings/regulator/regulator.txt.
> > +
> > +The valid names for regulators are:
> > +BUCK:
> > + VDVFS
> > +LDO:
> > + VBIASN
> > +
> > +Example:
>
> Sorry, I missed this in the previous revision but the ePAPR document
> says "the name of a node should be somewhat generic, reflecting the
> function of the device and not its precise programming model."
>
> > + pmic: mt6311@6B {
>
> So this should be:
>
> mt6311: pmic@
Ok, I will change it, thanks for reviewing.
Henry
>
> > + compatible = "mediatek,mt6311-regulator";
> > + reg = <0x6B>;
> > +
> > + regulators {
> > + mt6311_vcpu_reg: VDVFS {
> > + regulator-name = "VDVFS";
> > + regulator-min-microvolt = < 60>;
> > + regulator-max-microvolt = <140>;
> > + regulator-ramp-delay = <1>;
> > + };
> > + mt6311_ldo_reg: VBIASN {
> > + regulator-name = "VBIASN";
> > + regulator-min-microvolt = <20>;
> > + regulator-max-microvolt = <80>;
> > + };
> > + };
> > + };
> > --
>
> Besides the comment above, it looks good to me.
>
> Reviewed-by: Javier Martinez Canillas
>
> Best regards,
> Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 1/5] drm/layerscape: Add Freescale DCU DRM driver
Hi Dave,
I think Freescale DCU DRM driver is ready now, can it land?
I have worked on this driver for about nine month. Daniel Vetter,
Thierry Reding, Mark yao,
Alexander Stein, Paul Bolle, Alison Wang, Stefan Agner reviewed this
pathset. The latest
version v11 has been send out about an week, and no more comments any more.
BR.
Jianwei
On Mon, Jul 20, 2015 at 5:53 PM, Jianwei Wang
wrote:
> This patch add support for Two Dimensional Animation and Compositing
> Engine (2D-ACE) on the Freescale SoCs.
>
> 2D-ACE is a Freescale display controller. 2D-ACE describes
> the functionality of the module extremely well its name is a value
> that cannot be used as a token in programming languages.
> Instead the valid token "DCU" is used to tag the register names and
> function names.
>
> The Display Controller Unit (DCU) module is a system master that
> fetches graphics stored in internal or external memory and displays
> them on a TFT LCD panel. A wide range of panel sizes is supported
> and the timing of the interface signals is highly configurable.
> Graphics are read directly from memory and then blended in real-time,
> which allows for dynamic content creation with minimal CPU
> intervention.
>
> The features:
> (1) Full RGB888 output to TFT LCD panel.
> (2) Blending of each pixel using up to 4 source layers
> dependent
> on size of panel.
> (3) Each graphic layer can be placed with one pixel resolution
> in either axis.
> (4) Each graphic layer support RGB565 and RGB888 direct colors
> without alpha channel and BGRA BGRA ARGB1555 direct
> colors
> with an alpha channel and YUV422 format.
> (5) Each graphic layer support alpha blending with 8-bit
> resolution.
>
> This is a simplified version, only one primary plane, one
> framebuffer, one crtc, one connector and one encoder for TFT
> LCD panel.
>
> Signed-off-by: Alison Wang
> Signed-off-by: Xiubo Li
> Signed-off-by: Jianwei Wang
> Acked-by: Daniel Vetter
> Reviewed-by: Alison Wang
> ---
>
>
> Changed in V11
> -set regmap_config.cache_type to REGCACHE_FLAT
> Advanced by Alexander Stein
>
> Changed in V10
> -adjust commit log, remove meaningless statement
> -cleanup code for it's format and style.
> -remove platform related code out, including of tcon(vf610) and scfg(ls1021a)
> -remove useless sentences: encoder->crtc = crtc; and connector->encoder =
> encoder; and so on
> -add vendor prefix for panel pandle
> -make a DCU_CTRLDESCLN(x, y) to avoid high repetition
> -introduce per-SoC capability structure to avoid check on the OF node's
> compatible string
> -Implement some functions: crtc enable and disable, enable and disable
> VBLANK, plane atomic_disable and atomic_enable -atomic_check and so on
> -move DCU config sentence to the right place
> -move get resources functions to ->probe()
> -move fsl,dcu.txt to video/ folder
> -add big-endian describe
> All advaced by Thierry Reding
>
> Changed in V9
>
> -put node after calling of_drm_find_panel
> -split clk_prepare_enable() to clk_prepare() and clk_enable(), just call
> clk_prepare once, and check return value
> -check regmap_write/regmap_read return return value
> -remove useless ".owner= THIS_MODULE,"
> All advanced by Mark Yao
>
> Changed in V8
>
> - Remove useless code
> #define DRIVER_NAME "fsl-dcu-drm"
> MODULE_ALIAS("platform:fsl-dcu-drm");
> Adviced by Paul Bolle
>
> Changed in V7
>
> - Remove redundant functions and replace deprecated hooker
> Adviced by Daniel Vetter
> - Replace drm_platform_init with drm_dev_alloc/register
> Adviced by Daniel Vetter
>
> Changed in V6
>
> - Add NEC nl4827hc19_05b panel to panel-simple.c
> Adviced by Mark Yao
> - Add DRIVER_ATOMIC for driver_features
> Adviced by Mark Yao
> - check fsl_dev if it's NULL at PM suspend/resume
> Adviced by Mark Yao
>
> Changed in V5
>
> - Update commit message
> - Add layer registers initialization
> - Remove unused functions
> - Rename driver folder
> Adviced by Stefan Agner
> - Move pixel clock control functions to fsl_dcu_drm_drv.c
> - remove redundant enable the clock implicitly using regmap
> - Add maintainer message
>
> Changed in V4:
>
> -This version doesn't have functionality changed
> Just a minor adjustment.
>
> Changed in V3:
>
> - Test driver on Vybrid board and add compatible string
> - Remove unused functions
> - set default crtc for encoder
> - replace legacy functions with atomic help functions
> Adviced by Daniel Vetter
> - Set the unique name of the DRM device
> - Implement irq handle function for vblank interrupt
>
> Changed in v2:
> - Add atomic support
> Adviced by Daniel Vetter
> - Modify bindings file
> - Rename node for compatibility
> - Move platform related code out for compatibility
> Adviced by Stefan Agner
>
>
> .../devicetree/bindings/video/fsl,dcu.txt | 22 ++
> MAINTAINERS| 8 +
> drivers/gpu/drm/Kconfig| 2 +
> drivers/gpu/drm/Makefile | 1 +
>
Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
On 7/23/15 1:49 PM, Alexei Starovoitov wrote: On 7/23/15 4:54 AM, He Kuang wrote: trimmed cc-list, since it's not related to kernel. Thank you for your guidence, and by referencing your last mail and other llvm backends, I found setting BPFMCAsmInfo::SupportsDebugInformation = true in BPFMCAsmInfo.h thanks! yes. it was missing. and fix some unhandeled switch can make llc output debug_info, what do you mean ? but important information is missing in the result: hmm. I see slightly different picture. With 'clang -O2 -target bpf -g -S a.c' I see all the right info inside .s file. with '-c a.c' for some reasons it produces bogus offset: Abbrev Offset: 0x Pointer Size: 8 /usr/local/bin/objdump: Warning: Debug info is corrupted, abbrev offset () is larger than abbrev section size (4b) and objdump fails to parse .o I'm using llvm trunk 3.8. Do you see this as well? there were few issues related to relocations. Fixed it up and pushed to llvm trunk r243087. Please pull and give it a try. AT_location should be correct, but AT_name still looks buggy. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] leds/class: Check snprintf return value
On Mon, Mar 30, 2015 at 4:08 AM, Ricardo Ribalda Delgado
wrote:
> If the final name does not fit the string there is a potential
> endless-loop.
>
> Reported-by: Geert Uytterhoeven
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> drivers/leds/led-class.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index 294d6d6..2ffe8b1 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -223,12 +223,17 @@ static int led_classdev_next_name(const char
> *init_name, char *name,
> size_t len)
> {
> int i = 0;
> + int ret = 0;
>
> strlcpy(name, init_name, len);
>
> - while (class_find_device(leds_class, NULL, name, match_name))
> + while (class_find_device(leds_class, NULL, name, match_name) &&
> + (ret < len))
> snprintf(name, len, "%s_%d", init_name, ++i);
class_find_device will get a reference for a device. That reference must be
dropped using put_device(). See the definition for class_find_device in
drivers/base/class.c and other usage examples in the kernel. So this
function call will only work the first time.
Alan Tull
>
> + if (ret >= len)
> + return -ENOMEM;
> +
> return i;
> }
>
> @@ -243,6 +248,9 @@ int led_classdev_register(struct device *parent, struct
> led_classdev *led_cdev)
> int ret;
>
> ret = led_classdev_next_name(led_cdev->name, name, sizeof(name));
> + if (ret < 0)
> + return ret;
> +
> led_cdev->dev = device_create_with_groups(leds_class, parent, 0,
> led_cdev, led_cdev->groups, "%s", name);
> if (IS_ERR(led_cdev->dev))
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86/mm/pat: Do a small optimization when dump PAT memtype list
From: Pan Xinhui
There are many nodes in the PAT memtype rb-tree. When we dump this tree
we call kzalloc every time to copy nodes. Actually these kzalloc are not
necessary. Lets do a optimization now.
Let seq_file core create an *entry* when open and free it when release.
*entry* is stored as seq->private, so we can use it in seq_operations
callback who traverse/output the PAT memtype rb-tree only. Lots of
unnecessary kzalloc could be avoided now.
Signed-off-by: Pan Xinhui
---
v1 -> v2:
Use seq_open/release_private. let seq_file core handle memory
alloc/free.
seq_operations callbacks now only traverse/output the PAT rb-tree.
---
arch/x86/mm/pat.c | 28 ++--
1 file changed, 10 insertions(+), 18 deletions(-)
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 268b2c8..53920be 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -1001,41 +1001,33 @@ EXPORT_SYMBOL_GPL(pgprot_writethrough);
#if defined(CONFIG_DEBUG_FS) && defined(CONFIG_X86_PAT)
-static struct memtype *memtype_get_idx(loff_t pos)
+static struct memtype *memtype_get_idx(struct memtype *entry, loff_t pos)
{
- struct memtype *print_entry;
int ret;
- print_entry = kzalloc(sizeof(struct memtype), GFP_KERNEL);
- if (!print_entry)
- return NULL;
-
spin_lock(_lock);
- ret = rbt_memtype_copy_nth_element(print_entry, pos);
+ ret = rbt_memtype_copy_nth_element(entry, pos);
spin_unlock(_lock);
- if (!ret) {
- return print_entry;
- } else {
- kfree(print_entry);
- return NULL;
- }
+ return ret ? NULL : entry;
}
static void *memtype_seq_start(struct seq_file *seq, loff_t *pos)
{
+ struct memtype *entry = seq->private;
+
if (*pos == 0) {
++*pos;
seq_puts(seq, "PAT memtype list:\n");
}
- return memtype_get_idx(*pos);
+ return memtype_get_idx(entry, *pos);
}
static void *memtype_seq_next(struct seq_file *seq, void *v, loff_t *pos)
{
++*pos;
- return memtype_get_idx(*pos);
+ return memtype_get_idx((struct memtype *)v, *pos);
}
static void memtype_seq_stop(struct seq_file *seq, void *v)
@@ -1048,7 +1040,6 @@ static int memtype_seq_show(struct seq_file *seq, void *v)
seq_printf(seq, "%s @ 0x%Lx-0x%Lx\n", cattr_name(print_entry->type),
print_entry->start, print_entry->end);
- kfree(print_entry);
return 0;
}
@@ -1062,14 +1053,15 @@ static const struct seq_operations memtype_seq_ops = {
static int memtype_seq_open(struct inode *inode, struct file *file)
{
- return seq_open(file, _seq_ops);
+ return seq_open_private(file, _seq_ops,
+ sizeof(struct memtype));
}
static const struct file_operations memtype_fops = {
.open= memtype_seq_open,
.read= seq_read,
.llseek = seq_lseek,
- .release = seq_release,
+ .release = seq_release_private,
};
static int __init pat_memtype_list_init(void)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for reading SMBIOS Slot number for PCI devices
On Thu, Jul 23, 2015 at 9:31 PM, Jordan Hargrave wrote:
> On Thu, Jul 23, 2015 at 12:24 PM, Bjorn Helgaas wrote:
>> [+cc Matthew for PCIe-SSD perspective]
>>
>> On Wed, Jul 22, 2015 at 03:07:46PM -0500, Jordan Hargrave wrote:
>>> On Tue, Jul 21, 2015 at 8:09 PM, Bjorn Helgaas wrote:
>>> > On Tue, Jul 21, 2015 at 12:31:35PM -0500, Jordan Hargrave wrote:
>>> >> On Tue, Jul 21, 2015 at 11:57 AM, Bjorn Helgaas
>>> >> wrote:
>>> >> > On Mon, Jul 13, 2015 at 09:57:32AM -0500, Jordan Hargrave wrote:
>>> >> >> On Mon, Jul 13, 2015 at 2:35 AM, Jean Delvare
>>> >> >> wrote:
>>> >> >>
>>> >> >> > Hi Jordan,
>>> >> >> >
>>> >> >> > On Fri, 10 Jul 2015 17:02:46 -0500, Jordan Hargrave wrote:
>>> >> >> > > From: Jordan Hargrave
>>> >> >> > >
>>> >> >> > > There currently isn't an easy way to determine which PCI devices
>>> >> >> > > belong
>>> >> >> > to
>>> >> >> > > system slots. This patch adds support to read SMBIOS Type 9
>>> >> >> > > (System
>>> >> >> > Slots).
>>> >> >> >
>>> >> >> > I'm wondering, can't you use dmidecode or libsmbios to retrieve the
>>> >> >> > same information?
>>> >> >> >
>>> >> >> > --
>>> >> >> > Jean Delvare
>>> >> >> > SUSE L3 Support
>>> >> >> >
>>> >> >>
>>> >> >> You can but it's as not easy to determine the slot number for leaf
>>> >> >> devices
>>> >> >> on bridges. Eventually planning on using this for pulling slot
>>> >> >> number for
>>> >> >> identifying network cards and disk numbering for systemd
>>> >> >
>>> >> > Can you outline the problems with using dmidecode or libsmbios?
>>> >>
>>> >> Neither dmidecode nor libsmbios report the slot number for devices
>>> >> behind bridges in a slot.
>>> >
>>> > True, but it's straightforward to walk up the PCI tree in sysfs, e.g.,
>>> > given a path like /sys/devices/pci:00/:00:1c.5/:03:00.0/, it's
>>> > easy to see what the upstream bridges are.
>>> >
>>> It makes it more complicated I think. You have to check all functions
>>> on all devices as well on the walk to the root.
>>>
>>> Would it look something like this?
>>> while (pdev) {
>>> if (pdev->bus->number == dslot->bus && PCI_SLOT(pdev->devfn) ==
>>> PCI_SLOT(dslot->devfn) &&
>>> (pci_pcie_type(pdev) != PCI_ROOT_PORT || PCI_FUNC(pdev->devfn) ==
>>> PCI_FUNC(dslot->devfn))
>>> return dslot->instance;
>>> if (!pdev->bus->parent)
>>> break;
>>> pdev = pdev->bus->parent->self;
>>> }
>>>
>>> >> I'm wanting to use this sysfs variable to
>>> >> get slot numbers for systemd, so using libsmbios and dmidecode aren't
>>> >> very useful.
>>> >
>>> > If you want this in systemd, I see why you wouldn't want a command like
>>> > dmidecode. Help me understand the problem with libsmbios. Is it not
>>> > useful because (a) systemd doesn't want to link with it, or (b) libsmbios
>>> > doesn't have the right information, or (c) something else?
>>> >
>>> Linking with libsmbios would be a problem, and libsmbios doesn't have
>>> this info anyway.
>>>
>>> > It doesn't *look* like this is using any information that is only
>>> > available
>>> > in the kernel, so in principle it seems like this could be done in
>>> > user-space.
>>> >
>>>
>>> I actually just got an email from someone who needs to determine the
>>> card slot number in their driver... so I've added an external callable
>>> 'pci_get_smbios_slot' function to enable this.
>>>
>>> >> We already report the index for embedded devices in
>>> >> pci-label.c, this code should have gone in at the same time.
>>> >>
>>> >> For example. The SMBIOS entry for slot 3 is 40:00.0 There is a
>>> >> quad-port NIC in the slot with a bridge at 40:00.0
>>> >>
>>> >> 42:00.0 Bridge (sec=43, sub=45)
>>> >> 43:02.0 Bridge (sec=44, sub=44)
>>> >> 43:04.0 Bridge (sec=45, sub=45)
>>> >> 44:00.0 Ethernet
>>> >> 44:00.1 Ethernet
>>> >> 45:00.0 Ethernet
>>> >> 45:00.1 Ethernet
>>> >>
>>> >> So dmidecode only returns the slot number for 42:00.0 but not any
>>> >> child devices. This code will provide a 'slot' sysfs variable that
>>> >> reports '3' for all devices under and including the bridge.
>>> >
>>> > What if the card in slot 3 is an adapter leading to an external PCI
>>> > chassis? Wouldn't we then have a 'slot' file for every card in that
>>> > chassis, all containing '3'? This sounds confusing, although it is true
>>> > that they all would be connected via the system board slot 3.
>>> >
>>> Yes that is correct. Unless SMBIOS had a table of the second chassis.
>>>
>>> > Also, we do have the /sys/bus/pci/slots/ hierarchy already. If we do put
>>> > something like this in the kernel, how would it relate to that hierarchy?
>>> > Could this SMBIOS stuff be integrated into that somehow?
>>> >
>>>
>>> /sys/bus/pci/slots only map a slot to a single PCI device. systemd
>>> does use /sys/bus/pci/slots but it can't see the slot number on cards
>>> with bridges as the actual slot number is a parent. And that's not
>>> easily to determine a parent device from the slots interface. I'd
>>> really like something generic here.
RE: [PATCH] target: add support for START_STOP_UNIT SCSI opcode
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Spencer Baugh
> Sent: Thursday, July 23, 2015 5:28 PM
> To: Christoph Hellwig ; Spencer Baugh
>
...
> Subject: Re: [PATCH] target: add support for START_STOP_UNIT SCSI opcode
>
> From: Brian Bunker
>
> AIX servers using VIOS servers that virtualize FC cards will have a
> problem booting without support for START_STOP_UNIT.
>
> v2: Cite sb3r36 exactly, clean up if conditions
>
> Signed-off-by: Brian Bunker
> Signed-off-by: Spencer Baugh
...
> v2: Cite sb3r36 exactly, clean up if conditions
>
...
> diff --git a/drivers/target/target_core_sbc.c
> b/drivers/target/target_core_sbc.c
> index e318ddb..85c3c0a 100644
> --- a/drivers/target/target_core_sbc.c
> +++ b/drivers/target/target_core_sbc.c
> @@ -154,6 +154,38 @@ sbc_emulate_readcapacity_16(struct se_cmd *cmd)
> return 0;
> }
>
> +static sense_reason_t
> +sbc_emulate_startstop(struct se_cmd *cmd)
> +{
> + unsigned char *cdb = cmd->t_task_cdb;
> +
> + /*
> + * See sb3r36 section 5.25
Global typo in this patch - sb3 should be sbc3.
Editorial comment:
Note that the officially published versions of the ISO and ANSI
standards don't carry that revision number r36; they just have
the standard name and year. SBC-3 revision 36 became
"ANSI INCITS 514-2014 Information technology - SCSI Block
Commands - 3 (SBC-3)".
T10 isn't really obligated to keep making particular working
drafts available, although the ones that have been assigned
version descriptors (in SPC-n) are more likely to stick
around. For SBC-3, only revisions 35 and 36 earned those.
Section numbers are quite volatile, too, so you might be
better off including the section name. It's starting to
become standardese, but this kind of wording might be better:
"See the SBC-3 START STOP UNIT command description
(e.g., sbc3r36 5.25)"
> + /* From SBC-3:
> + * Immediate bit should be set since there is nothing to complete
> + * POWER CONDITION MODIFIER 0h
> + */
> + if (!(cdb[1] & 1) || (cdb[2] | cdb[3]))
> + return TCM_INVALID_CDB_FIELD;
Technical comment:
The application client is not obligated to set the IMMED bit here.
In fact, that's an unusual choice. Using the IMMED bit means the
application client must handle the initial status for the
command, then poll for the functional results with REQUEST SENSE
and TEST UNIT READY commands, which is much more complicated.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH v3] PCI: move pci_read_bridge_bases to the generic PCI layer
On 07/23/2015 10:52 AM, Lorenzo Pieralisi wrote: For alpha, PCI_PROBE_ONLY is set for two platforms, marvel and titan, out of ~20. mips sets the flag for 6 platforms out of >25. Unlikely that those are the only relevant ones. I could try to run some qemu tests for both architectures, but I have no idea what to look out for. Ideas, anyone ? As I replied to Bjorn, I would not expect pci_read_bridge_bases() to be a disruptive operation on !PCI_PROBE_ONLY systems, I will check again alpha and mips code but it is really hard to say, I will inspect the code again to try to figure it out. I finally got around to apply the patch to our system (ppc and x86). I also applied it on top of Linus' tree and ran it through my test farm. No problems found, works fine as far as I can see. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/7] clk: mediatek: Fix rate and dependency of MT8173 clocks
Remove the dependency from clk_null, and give all root clocks a
typical rate, include clkph_mck_o, usb_syspll_125m and hdmitx_dig_cts.
dpi_ck was removed due to no clock reference to it.
Replace parent clock of infra_cpum with cpum_ck, which is an external
clock and can be defined in the deivce tree.
Signed-off-by: James Liao
---
drivers/clk/mediatek/clk-mt8173.c | 13 ++---
include/dt-bindings/clock/mt8173-clk.h | 1 -
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt8173.c
b/drivers/clk/mediatek/clk-mt8173.c
index 4b9e04c..50b3266 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -24,11 +24,9 @@
static DEFINE_SPINLOCK(mt8173_clk_lock);
-static const struct mtk_fixed_factor root_clk_alias[] __initconst = {
- FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
- FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
- FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
- FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
+static const struct mtk_fixed_clk fixed_clks[] __initconst = {
+ FIXED_CLK(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk26m", 400 * MHZ),
+ FIXED_CLK(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk26m", 125 *
MHZ),
};
static const struct mtk_fixed_factor top_divs[] __initconst = {
@@ -53,6 +51,7 @@ static const struct mtk_fixed_factor top_divs[] __initconst =
{
FACTOR(CLK_TOP_CLKRTC_INT, "clkrtc_int", "clk26m", 1, 793),
FACTOR(CLK_TOP_FPC, "fpc_ck", "clk26m", 1, 1),
+ FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "tvdpll_445p5m", 1, 3),
FACTOR(CLK_TOP_HDMITXPLL_D2, "hdmitxpll_d2", "hdmitx_dig_cts", 1, 2),
FACTOR(CLK_TOP_HDMITXPLL_D3, "hdmitxpll_d3", "hdmitx_dig_cts", 1, 3),
@@ -611,7 +610,7 @@ static const struct mtk_gate infra_clks[] __initconst = {
GATE_ICG(CLK_INFRA_GCE, "infra_gce", "axi_sel", 6),
GATE_ICG(CLK_INFRA_L2C_SRAM, "infra_l2c_sram", "axi_sel", 7),
GATE_ICG(CLK_INFRA_M4U, "infra_m4u", "mem_sel", 8),
- GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "clk_null", 15),
+ GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "cpum_ck", 15),
GATE_ICG(CLK_INFRA_KP, "infra_kp", "axi_sel", 16),
GATE_ICG(CLK_INFRA_CEC, "infra_cec", "clk26m", 18),
GATE_ICG(CLK_INFRA_PMICSPI, "infra_pmicspi", "pmicspi_sel", 22),
@@ -714,7 +713,7 @@ static void __init mtk_topckgen_init(struct device_node
*node)
clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
- mtk_clk_register_factors(root_clk_alias, ARRAY_SIZE(root_clk_alias),
clk_data);
+ mtk_clk_register_fixed_clks(fixed_clks, ARRAY_SIZE(fixed_clks),
clk_data);
mtk_clk_register_factors(top_divs, ARRAY_SIZE(top_divs), clk_data);
mtk_clk_register_composites(top_muxes, ARRAY_SIZE(top_muxes), base,
_clk_lock, clk_data);
diff --git a/include/dt-bindings/clock/mt8173-clk.h
b/include/dt-bindings/clock/mt8173-clk.h
index 4ad76ed..7230c38 100644
--- a/include/dt-bindings/clock/mt8173-clk.h
+++ b/include/dt-bindings/clock/mt8173-clk.h
@@ -18,7 +18,6 @@
/* TOPCKGEN */
#define CLK_TOP_CLKPH_MCK_O1
-#define CLK_TOP_DPI2
#define CLK_TOP_USB_SYSPLL_125M3
#define CLK_TOP_HDMITX_DIG_CTS 4
#define CLK_TOP_ARMCA7PLL_754M 5
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 7/7] arm64: dts: mt8173: Add subsystem clock controller device nodes
This patch adds device nodes providing subsystem clocks on MT8173,
includes mmsys, imgsys, vdecsys, vencsys and vencltsys.
Signed-off-by: James Liao
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 37
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index a2f63e4..8731d24 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -88,6 +88,13 @@
#clock-cells = <0>;
};
+ cpum_ck: dummy_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ clock-output-names = "cpum_ck";
+ };
+
clk26m: oscillator@0 {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -227,6 +234,36 @@
clocks = <_clk>;
status = "disabled";
};
+
+ mmsys: clock-controller@1400 {
+ compatible = "mediatek,mt8173-mmsys", "syscon";
+ reg = <0 0x1400 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ imgsys: clock-controller@1500 {
+ compatible = "mediatek,mt8173-imgsys", "syscon";
+ reg = <0 0x1500 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ vdecsys: clock-controller@1600 {
+ compatible = "mediatek,mt8173-vdecsys", "syscon";
+ reg = <0 0x1600 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ vencsys: clock-controller@1800 {
+ compatible = "mediatek,mt8173-vencsys", "syscon";
+ reg = <0 0x1800 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ vencltsys: clock-controller@1900 {
+ compatible = "mediatek,mt8173-vencltsys", "syscon";
+ reg = <0 0x1900 0 0x1000>;
+ #clock-cells = <1>;
+ };
};
};
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 5/7] clk: mediatek: Add subsystem clocks of MT8173
Most multimedia subsystem clocks will be accessed by multiple
drivers, so it's a better way to manage these clocks in CCF.
This patch adds clock support for MM, IMG, VDEC, VENC and VENC_LT
subsystems.
Signed-off-by: James Liao
---
drivers/clk/mediatek/clk-mt8173.c | 267 +
include/dt-bindings/clock/mt8173-clk.h | 97 +++-
2 files changed, 361 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt8173.c
b/drivers/clk/mediatek/clk-mt8173.c
index a72ce82..2cf6620 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -27,6 +27,10 @@ static DEFINE_SPINLOCK(mt8173_clk_lock);
static const struct mtk_fixed_clk fixed_clks[] __initconst = {
FIXED_CLK(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk26m", 400 * MHZ),
FIXED_CLK(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk26m", 125 *
MHZ),
+ FIXED_CLK(CLK_TOP_DSI0_DIG, "dsi0_dig", "clk26m", 130 * MHZ),
+ FIXED_CLK(CLK_TOP_DSI1_DIG, "dsi1_dig", "clk26m", 130 * MHZ),
+ FIXED_CLK(CLK_TOP_LVDS_PXL, "lvds_pxl", "lvdspll", 148.5 * MHZ),
+ FIXED_CLK(CLK_TOP_LVDS_CTS, "lvds_cts", "lvdspll", 51.975 * MHZ),
};
static const struct mtk_fixed_factor top_divs[] __initconst = {
@@ -699,6 +703,183 @@ static const struct mtk_composite peri_clks[] __initconst
= {
MUX(CLK_PERI_UART3_SEL, "uart3_ck_sel", uart_ck_sel_parents, 0x40c, 3,
1),
};
+static const struct mtk_gate_regs cg_regs_4_8_0 = {
+ .set_ofs = 0x0004,
+ .clr_ofs = 0x0008,
+ .sta_ofs = 0x,
+};
+
+#define GATE_IMG(_id, _name, _parent, _shift) {\
+ .id = _id, \
+ .name = _name, \
+ .parent_name = _parent, \
+ .regs = _regs_4_8_0, \
+ .shift = _shift,\
+ .ops = _clk_gate_ops_setclr,\
+ }
+
+static const struct mtk_gate img_clks[] __initconst = {
+ GATE_IMG(CLK_IMG_LARB2_SMI, "img_larb2_smi", "mm_sel", 0),
+ GATE_IMG(CLK_IMG_CAM_SMI, "img_cam_smi", "mm_sel", 5),
+ GATE_IMG(CLK_IMG_CAM_CAM, "img_cam_cam", "mm_sel", 6),
+ GATE_IMG(CLK_IMG_SEN_TG, "img_sen_tg", "camtg_sel", 7),
+ GATE_IMG(CLK_IMG_SEN_CAM, "img_sen_cam", "mm_sel", 8),
+ GATE_IMG(CLK_IMG_CAM_SV, "img_cam_sv", "mm_sel", 9),
+ GATE_IMG(CLK_IMG_FD, "img_fd", "mm_sel", 11),
+};
+
+static const struct mtk_gate_regs mm0_cg_regs = {
+ .set_ofs = 0x0104,
+ .clr_ofs = 0x0108,
+ .sta_ofs = 0x0100,
+};
+
+static const struct mtk_gate_regs mm1_cg_regs = {
+ .set_ofs = 0x0114,
+ .clr_ofs = 0x0118,
+ .sta_ofs = 0x0110,
+};
+
+#define GATE_MM0(_id, _name, _parent, _shift) {\
+ .id = _id, \
+ .name = _name, \
+ .parent_name = _parent, \
+ .regs = _cg_regs, \
+ .shift = _shift,\
+ .ops = _clk_gate_ops_setclr,\
+ }
+
+#define GATE_MM1(_id, _name, _parent, _shift) {\
+ .id = _id, \
+ .name = _name, \
+ .parent_name = _parent, \
+ .regs = _cg_regs, \
+ .shift = _shift,\
+ .ops = _clk_gate_ops_setclr,\
+ }
+
+static const struct mtk_gate mm_clks[] __initconst = {
+ /* MM0 */
+ GATE_MM0(CLK_MM_SMI_COMMON, "mm_smi_common", "mm_sel", 0),
+ GATE_MM0(CLK_MM_SMI_LARB0, "mm_smi_larb0", "mm_sel", 1),
+ GATE_MM0(CLK_MM_CAM_MDP, "mm_cam_mdp", "mm_sel", 2),
+ GATE_MM0(CLK_MM_MDP_RDMA0, "mm_mdp_rdma0", "mm_sel", 3),
+ GATE_MM0(CLK_MM_MDP_RDMA1, "mm_mdp_rdma1", "mm_sel", 4),
+ GATE_MM0(CLK_MM_MDP_RSZ0, "mm_mdp_rsz0", "mm_sel", 5),
+ GATE_MM0(CLK_MM_MDP_RSZ1, "mm_mdp_rsz1", "mm_sel", 6),
+ GATE_MM0(CLK_MM_MDP_RSZ2, "mm_mdp_rsz2", "mm_sel", 7),
+ GATE_MM0(CLK_MM_MDP_TDSHP0, "mm_mdp_tdshp0", "mm_sel", 8),
+ GATE_MM0(CLK_MM_MDP_TDSHP1, "mm_mdp_tdshp1", "mm_sel", 9),
+ GATE_MM0(CLK_MM_MDP_WDMA, "mm_mdp_wdma", "mm_sel", 11),
+ GATE_MM0(CLK_MM_MDP_WROT0, "mm_mdp_wrot0", "mm_sel", 12),
+ GATE_MM0(CLK_MM_MDP_WROT1, "mm_mdp_wrot1", "mm_sel", 13),
+ GATE_MM0(CLK_MM_FAKE_ENG, "mm_fake_eng", "mm_sel", 14),
+ GATE_MM0(CLK_MM_MUTEX_32K, "mm_mutex_32k", "rtc_sel", 15),
+ GATE_MM0(CLK_MM_DISP_OVL0, "mm_disp_ovl0", "mm_sel", 16),
+ GATE_MM0(CLK_MM_DISP_OVL1, "mm_disp_ovl1", "mm_sel", 17),
+ GATE_MM0(CLK_MM_DISP_RDMA0,
[PATCH v4 6/7] clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS
Add REF2USB_TX clock support into MT8173 APMIXEDSYS. This clock
is needed by USB 3.0.
Signed-off-by: James Liao
---
drivers/clk/mediatek/Makefile | 2 +-
drivers/clk/mediatek/clk-apmixed.c | 137 +
drivers/clk/mediatek/clk-mt8173.c | 15 +++-
drivers/clk/mediatek/clk-mtk.h | 26 +++
drivers/clk/mediatek/clk-pll.c | 7 +-
include/dt-bindings/clock/mt8173-clk.h | 3 +-
6 files changed, 180 insertions(+), 10 deletions(-)
create mode 100644 drivers/clk/mediatek/clk-apmixed.c
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 8e4b2a4..95fdfac 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,4 +1,4 @@
-obj-y += clk-mtk.o clk-pll.o clk-gate.o
+obj-y += clk-mtk.o clk-pll.o clk-gate.o clk-apmixed.o
obj-$(CONFIG_RESET_CONTROLLER) += reset.o
obj-y += clk-mt8135.o
obj-y += clk-mt8173.o
diff --git a/drivers/clk/mediatek/clk-apmixed.c
b/drivers/clk/mediatek/clk-apmixed.c
new file mode 100644
index 000..09f2a7c
--- /dev/null
+++ b/drivers/clk/mediatek/clk-apmixed.c
@@ -0,0 +1,137 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: James Liao
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+
+#include "clk-mtk.h"
+
+#define REF2USB_TX_EN BIT(0)
+#define REF2USB_TX_LPF_EN BIT(1)
+#define REF2USB_TX_OUT_EN BIT(2)
+#define REF2USB_EN_MASK(REF2USB_TX_EN | REF2USB_TX_LPF_EN | \
+REF2USB_TX_OUT_EN)
+
+struct mtk_ref2usb_tx {
+ struct clk_hw hw;
+ void __iomem*base_addr;
+};
+
+static inline struct mtk_ref2usb_tx *to_mtk_ref2usb_tx(struct clk_hw *hw)
+{
+ return container_of(hw, struct mtk_ref2usb_tx, hw);
+}
+
+static int mtk_ref2usb_tx_is_prepared(struct clk_hw *hw)
+{
+ struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
+
+ return (readl(tx->base_addr) & REF2USB_EN_MASK) == REF2USB_EN_MASK;
+}
+
+static int mtk_ref2usb_tx_prepare(struct clk_hw *hw)
+{
+ struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
+ u32 val;
+
+ val = readl(tx->base_addr);
+
+ val |= REF2USB_TX_EN;
+ writel(val, tx->base_addr);
+ udelay(100);
+
+ val |= REF2USB_TX_LPF_EN;
+ writel(val, tx->base_addr);
+
+ val |= REF2USB_TX_OUT_EN;
+ writel(val, tx->base_addr);
+
+ return 0;
+}
+
+static void mtk_ref2usb_tx_unprepare(struct clk_hw *hw)
+{
+ struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
+ u32 val;
+
+ val = readl(tx->base_addr);
+ val &= ~REF2USB_EN_MASK;
+ writel(val, tx->base_addr);
+}
+
+static const struct clk_ops mtk_ref2usb_tx_ops = {
+ .is_prepared= mtk_ref2usb_tx_is_prepared,
+ .prepare= mtk_ref2usb_tx_prepare,
+ .unprepare = mtk_ref2usb_tx_unprepare,
+};
+
+struct clk *mtk_clk_register_ref2usb_tx(const char *name,
+ const char *parent_name, void __iomem *reg)
+{
+ struct mtk_ref2usb_tx *tx;
+ struct clk_init_data init = {};
+ struct clk *clk;
+
+ tx = kzalloc(sizeof(*tx), GFP_KERNEL);
+ if (!tx)
+ return ERR_PTR(-ENOMEM);
+
+ tx->base_addr = reg;
+ tx->hw.init =
+
+ init.name = name;
+ init.ops = _ref2usb_tx_ops;
+ init.parent_names = _name;
+ init.num_parents = 1;
+
+ clk = clk_register(NULL, >hw);
+
+ if (IS_ERR(clk)) {
+ pr_err("Failed to register clk %s: %ld\n", name, PTR_ERR(clk));
+ kfree(tx);
+ }
+
+ return clk;
+}
+
+void __init mtk_clk_register_apmixed_ex(struct device_node *node,
+ const struct mtk_clk_ex *clks, int num_clks,
+ struct clk_onecell_data *clk_data)
+{
+ void __iomem *base;
+ struct clk *clk;
+ int i;
+
+ base = of_iomap(node, 0);
+ if (!base) {
+ pr_err("%s(): ioremap failed\n", __func__);
+ return;
+ }
+
+ for (i = 0; i < num_clks; i++) {
+ const struct mtk_clk_ex *cke = [i];
+
+ clk = cke->reg_clk_ex(cke->name, cke->parent,
+ base + cke->reg_ofs);
+
+ if (IS_ERR(clk)) {
+ pr_err("Failed to register clk %s: %ld\n", cke->name,
+ PTR_ERR(clk));
+ continue;
+ }
+
+ clk_data->clks[cke->id] = clk;
+ }
+}
diff --git
[PATCH v4 3/7] clk: mediatek: mt8173: Fix enabling of critical clocks
From: Sascha Hauer
On the MT8173 the clocks are provided by different units. To enable
the critical clocks we must be sure that all parent clocks are already
registered, otherwise the parents of the critical clocks end up being
unused and get disabled later.
On MT8173, for example, it is the CLK_TOP clocks that have CLK_APMIXED
PLLs as their parents, so we cannot enable the CLK_TOP critical clocks
until the CLK_APMIXED clocks have all been registered.
To find a place where all parents are registered we try each time
after we've registered some clocks if all known providers are present
now and only then we enable the critical clocks.
Signed-off-by: Sascha Hauer
Signed-off-by: James Liao
---
drivers/clk/mediatek/clk-mt8173.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt8173.c
b/drivers/clk/mediatek/clk-mt8173.c
index 50b3266..a72ce82 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -699,6 +699,22 @@ static const struct mtk_composite peri_clks[] __initconst
= {
MUX(CLK_PERI_UART3_SEL, "uart3_ck_sel", uart_ck_sel_parents, 0x40c, 3,
1),
};
+static struct clk_onecell_data *mt8173_top_clk_data;
+static struct clk_onecell_data *mt8173_pll_clk_data;
+
+static void __init mtk_clk_enable_critical(void)
+{
+ if (!mt8173_top_clk_data || !mt8173_pll_clk_data)
+ return;
+
+ clk_prepare_enable(mt8173_pll_clk_data->clks[CLK_APMIXED_ARMCA15PLL]);
+ clk_prepare_enable(mt8173_pll_clk_data->clks[CLK_APMIXED_ARMCA7PLL]);
+ clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_MEM_SEL]);
+ clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_DDRPHYCFG_SEL]);
+ clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_CCI400_SEL]);
+ clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_RTC_SEL]);
+}
+
static void __init mtk_topckgen_init(struct device_node *node)
{
struct clk_onecell_data *clk_data;
@@ -711,19 +727,19 @@ static void __init mtk_topckgen_init(struct device_node
*node)
return;
}
- clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
+ mt8173_top_clk_data = clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
mtk_clk_register_fixed_clks(fixed_clks, ARRAY_SIZE(fixed_clks),
clk_data);
mtk_clk_register_factors(top_divs, ARRAY_SIZE(top_divs), clk_data);
mtk_clk_register_composites(top_muxes, ARRAY_SIZE(top_muxes), base,
_clk_lock, clk_data);
- clk_prepare_enable(clk_data->clks[CLK_TOP_CCI400_SEL]);
-
r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
if (r)
pr_err("%s(): could not register clock provider: %d\n",
__func__, r);
+
+ mtk_clk_enable_critical();
}
CLK_OF_DECLARE(mtk_topckgen, "mediatek,mt8173-topckgen", mtk_topckgen_init);
@@ -817,13 +833,13 @@ static void __init mtk_apmixedsys_init(struct device_node
*node)
{
struct clk_onecell_data *clk_data;
- clk_data = mtk_alloc_clk_data(CLK_APMIXED_NR_CLK);
+ mt8173_pll_clk_data = clk_data = mtk_alloc_clk_data(CLK_APMIXED_NR_CLK);
if (!clk_data)
return;
mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
- clk_prepare_enable(clk_data->clks[CLK_APMIXED_ARMCA15PLL]);
+ mtk_clk_enable_critical();
}
CLK_OF_DECLARE(mtk_apmixedsys, "mediatek,mt8173-apmixedsys",
mtk_apmixedsys_init);
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/7] clk: mediatek: Add fixed clocks support for Mediatek SoC.
This patch adds fixed clocks support by using CCF fixed-rate
clock implementation.
Signed-off-by: James Liao
---
drivers/clk/mediatek/clk-mtk.c | 23 +++
drivers/clk/mediatek/clk-mtk.h | 19 ++-
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 18444ae..f8307c3 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -49,6 +49,29 @@ err_out:
return NULL;
}
+void mtk_clk_register_fixed_clks(const struct mtk_fixed_clk *clks, int num,
+ struct clk_onecell_data *clk_data)
+{
+ int i;
+ struct clk *clk;
+
+ for (i = 0; i < num; i++) {
+ const struct mtk_fixed_clk *rc = [i];
+
+ clk = clk_register_fixed_rate(NULL, rc->name, rc->parent,
+ rc->parent ? 0 : CLK_IS_ROOT, rc->rate);
+
+ if (IS_ERR(clk)) {
+ pr_err("Failed to register clk %s: %ld\n",
+ rc->name, PTR_ERR(clk));
+ continue;
+ }
+
+ if (clk_data)
+ clk_data->clks[rc->id] = clk;
+ }
+}
+
void mtk_clk_register_factors(const struct mtk_fixed_factor *clks, int num,
struct clk_onecell_data *clk_data)
{
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index 9dda9d8..f083dfc 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -25,6 +25,23 @@
#define MHZ (1000 * 1000)
+struct mtk_fixed_clk {
+ int id;
+ const char *name;
+ const char *parent;
+ unsigned long rate;
+};
+
+#define FIXED_CLK(_id, _name, _parent, _rate) {\
+ .id = _id, \
+ .name = _name, \
+ .parent = _parent, \
+ .rate = _rate, \
+ }
+
+void mtk_clk_register_fixed_clks(const struct mtk_fixed_clk *clks,
+ int num, struct clk_onecell_data *clk_data);
+
struct mtk_fixed_factor {
int id;
const char *name;
@@ -41,7 +58,7 @@ struct mtk_fixed_factor {
.div = _div,\
}
-extern void mtk_clk_register_factors(const struct mtk_fixed_factor *clks,
+void mtk_clk_register_factors(const struct mtk_fixed_factor *clks,
int num, struct clk_onecell_data *clk_data);
struct mtk_composite {
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 4/7] dt-bindings: ARM: Mediatek: Document devicetree bindings for clock controllers
This adds the binding documentation for the mmsys, imgsys, vdecsys,
vencsys and vencltsys controllers found on Mediatek SoCs.
Signed-off-by: James Liao
---
.../bindings/arm/mediatek/mediatek,imgsys.txt | 22 ++
.../bindings/arm/mediatek/mediatek,mmsys.txt | 22 ++
.../bindings/arm/mediatek/mediatek,vdecsys.txt | 22 ++
.../bindings/arm/mediatek/mediatek,vencltsys.txt | 22 ++
.../bindings/arm/mediatek/mediatek,vencsys.txt | 22 ++
5 files changed, 110 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
new file mode 100644
index 000..b1f2ce1
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
@@ -0,0 +1,22 @@
+Mediatek imgsys controller
+
+
+The Mediatek imgsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+ - "mediatek,mt8173-imgsys", "syscon"
+- #clock-cells: Must be 1
+
+The imgsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+imgsys: clock-controller@1500 {
+ compatible = "mediatek,mt8173-imgsys", "syscon";
+ reg = <0 0x1500 0 0x1000>;
+ #clock-cells = <1>;
+};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
new file mode 100644
index 000..4385946
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
@@ -0,0 +1,22 @@
+Mediatek mmsys controller
+
+
+The Mediatek mmsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+ - "mediatek,mt8173-mmsys", "syscon"
+- #clock-cells: Must be 1
+
+The mmsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+mmsys: clock-controller@1400 {
+ compatible = "mediatek,mt8173-mmsys", "syscon";
+ reg = <0 0x1400 0 0x1000>;
+ #clock-cells = <1>;
+};
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
new file mode 100644
index 000..1faacf1
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
@@ -0,0 +1,22 @@
+Mediatek vdecsys controller
+
+
+The Mediatek vdecsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+ - "mediatek,mt8173-vdecsys", "syscon"
+- #clock-cells: Must be 1
+
+The vdecsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+vdecsys: clock-controller@1600 {
+ compatible = "mediatek,mt8173-vdecsys", "syscon";
+ reg = <0 0x1600 0 0x1000>;
+ #clock-cells = <1>;
+};
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
new file mode 100644
index 000..3cc299f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
@@ -0,0 +1,22 @@
+Mediatek vencltsys controller
+
+
+The Mediatek vencltsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+ - "mediatek,mt8173-vencltsys", "syscon"
+- #clock-cells: Must be 1
+
+The vencltsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+vencltsys: clock-controller@1900 {
+ compatible = "mediatek,mt8173-vencltsys", "syscon";
+ reg = <0 0x1900 0 0x1000>;
+ #clock-cells = <1>;
+};
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
new file mode 100644
index 000..5bb2866
--- /dev/null
+++
[PATCH v4 0/7] Add Mediatek MT8173 subsystem clocks support
This patchset is based on 4.2-rc1 and [1], and contains subsystem clocks support for Mediatek MT8173. Previous reviews can be found in [2][3]. This patchset merge the 2 patchsets because of the dependency. The most different from previous patchset are removing clk_null and split usb clock support into a separated source file. changes since v3: - Remove clk_null dependency from root clocks. - Use fixed-rate clocks with typical rate to replace clk_null. - Add clk-apmixed.c to implement ref2usb_tx. - Use clock-controller as the name of clock providers. changes since v2: - Rebase to 4.2-rc1. - Add device tree nodes for subsystem clocks. - Fine tune comments of patches. - Add __init, __initconst and const to init data and functions. - Removed unused code from init functions of subsystem clocks. changes since v1: - Add CA7PLL and CA15PLL as critical clocks. - Use the same register descriptor for imgsys, vensys and vencltsys. - Generalize apmixedsys special clocks registration. [1] https://patchwork.kernel.org/patch/6446341/ [2] https://lkml.org/lkml/2015/7/10/254 [3] https://lkml.org/lkml/2015/7/10/230 James Liao (6): clk: mediatek: Add fixed clocks support for Mediatek SoC. clk: mediatek: Fix rate and dependency of MT8173 clocks dt-bindings: ARM: Mediatek: Document devicetree bindings for clock controllers clk: mediatek: Add subsystem clocks of MT8173 clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS arm64: dts: mt8173: Add subsystem clock controller device nodes Sascha Hauer (1): clk: mediatek: mt8173: Fix enabling of critical clocks .../bindings/arm/mediatek/mediatek,imgsys.txt | 22 ++ .../bindings/arm/mediatek/mediatek,mmsys.txt | 22 ++ .../bindings/arm/mediatek/mediatek,vdecsys.txt | 22 ++ .../bindings/arm/mediatek/mediatek,vencltsys.txt | 22 ++ .../bindings/arm/mediatek/mediatek,vencsys.txt | 22 ++ arch/arm64/boot/dts/mediatek/mt8173.dtsi | 37 +++ drivers/clk/mediatek/Makefile | 2 +- drivers/clk/mediatek/clk-apmixed.c | 137 + drivers/clk/mediatek/clk-mt8173.c | 321 - drivers/clk/mediatek/clk-mtk.c | 23 ++ drivers/clk/mediatek/clk-mtk.h | 45 ++- drivers/clk/mediatek/clk-pll.c | 7 +- include/dt-bindings/clock/mt8173-clk.h | 101 ++- 13 files changed, 756 insertions(+), 27 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt create mode 100644 drivers/clk/mediatek/clk-apmixed.c -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7 4/5] arm64: apei: implement arch_apei_get_mem_attributes()
On 07/22/2015 05:59 AM, Jonathan (Zhixiong) Zhang wrote:
From: "Jonathan (Zhixiong) Zhang"
If the physical address has memory attributes defined by EFI
memmap as EFI_MEMORY_UC, the page protection type is
PROT_DEVICE_nGnRE. Otherwise, the page protection type is
PAGE_KERNEL.
...
[...]
+#ifdef CONFIG_ACPI_APEI
+/*
+ * According to "Table 8 Map: EFI memory types to AArch64 memory types"
+ * of UEFI 2.5 section 2.3.6.1, each EFI memory type is mapped to
+ * corresponding MAIR attribute encoding.
+ */
+static inline pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+{
+ pgprot_t prot;
+
+ prot = efi_mem_attributes(addr);
+ if (prot & EFI_MEMORY_UC)
+ return PROT_DEVICE_nGnRnE;
+ if (prot & EFI_MEMORY_WC)
+ return PROT_NORMAL_NC;
+ if (prot & EFI_MEMORY_WT)
+ return PROT_NORMAL_WT;
+ return PAGE_KERNEL;
+}
The change log is not matching the code here, and the PROT_DEVICE_nGnRE
in the change log is wrong, if you fix that,
Acked-by: Hanjun Guo
Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c
Hi Christian,
here's what Finn asked me to run as tests:
# dmesg | grep this_id > nvram.out
# cat /proc/driver/nvram >> nvram.out
# hexdump -C /dev/nvram >> nvram.out
# cp /dev/nvram /tmp/nvram
# cp /tmp/nvram /dev/nvram
# md5sum /dev/nvram /tmp/nvram >> nvram.out
What you sent so far looks OK. I've tested the change of SCSI ID
(using EmuTOS) along with a trivial patch to atari_scsi.c (replace
offset 14 by 16) and the driver now uses the stored ID properly. I'll
sent kernels to test Finn's NVRAM patch for regression ASAP.
Thanks for your offer of help!
Cheers,
Michael
On Thu, Jul 23, 2015 at 9:21 PM, Christian T. Steigies wrote:
> On Wed, Jul 22, 2015 at 02:22:21PM +1000, Finn Thain wrote:
>>
>> Anyone with a suitable Atari, i.e. ATARIHW_PRESENT(TT_CLK), who can boot
>> both TOS and Linux could resolve the question. (Perhaps with an emulator?)
>>
>> Any old kernel binary would do, since atari_scsi should print either
>> "HOSTID=n" or "this_id n" at startup.
>>
>> If n doesn't agree with what TOS says about the host's SCSI ID, then I
>> think a trivial patch is safe enough. Especially if cat /proc/driver/nvram
>> produces a "SCSI host ID : m" that does agree with TOS.
>
> root@garkin:~>cat /proc/hardware
> Model: Atari Falcon
> System Memory: 522752K
> 510 MB at 0x0100 (alternate RAM)
> Detected hardware:
> Falcon Shifter
> Programmable Sound Generator
> PCM 8 Bit Sound
> CODEC Sound
> SCSI Controller NCR5380 (Falcon style)
> IDE Interface
> 8/16 Mhz Switch for FDC
> Multi Function Peripheral MFP 68901
> Serial Communications Controller SCC 8530
> Paddle Interface
> DMA Controller for SCC
> Clock Chip MC146818A
> Blitter
> DSP56001 processor
>
> root@garkin:~>dmesg |grep SCSI
> [0.00] Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC
> DSP56K SCC_DMA SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED
> [0.41] SCSI subsystem initialized
> [0.85] Block layer SCSI generic (bsg) driver version 0.4 loaded
> (major 251)
> [4.23] Atari SCSI: resetting the SCSI bus... done
> [6.75] scsi host0: Atari native SCSI, io_port 0x0, n_io_port 0, base
> 0x0, irq 15, can_queue 8, cmd_per_lun 1, sg_tablesize 0, this_id 7, flags {
> }, options { REAL_DMA SUPPORT_TAGS }
>
> root@garkin:~>cat /proc/driver/nvram
> Checksum status : not valid
> Boot preference : 0xff (undefined)
> SCSI arbitration : on
> SCSI host ID : 7
> OS language : 255 (undefined)
> Keyboard language: 255 (undefined)
> Date format : 7 (undefined), 24h clock
> Boot delay : 255s
> Video mode : 4 colors, 40 columns, TV NTSC monitor
>no overscan, compat. mode off
>
>
> Let me know if you need more info.
>
> Christian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7 3/5] arm64: mm: add PROT_DEVICE_nGnRnE and PROT_NORMAL_WT
+Cc Ard and Leif. On 07/22/2015 05:59 AM, Jonathan (Zhixiong) Zhang wrote: From: "Jonathan (Zhixiong) Zhang" UEFI spec 2.5 section 2.3.6.1 defines that EFI_MEMORY_[UC|WC|WT|WB] are possible EFI memory types for AArch64. Each of those EFI memory types is mapped to a corresponding AArch64 memory type. So we need to define PROT_DEVICE_nGnRnE and PROT_NORMWL_WT. MT_NORMAL_WT is defined, and its encoding is added to MAIR_EL1 when initializing cpu. Change-Id: I20ac71ddf74c17e41769ecbb5f8c60eeefbb398a Signed-off-by: Jonathan (Zhixiong) Zhang --- arch/arm64/include/asm/memory.h | 1 + arch/arm64/include/asm/pgtable.h | 2 ++ arch/arm64/mm/proc.S | 6 -- 3 files changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h index f800d45ea226..4112b3d7468e 100644 --- a/arch/arm64/include/asm/memory.h +++ b/arch/arm64/include/asm/memory.h @@ -100,6 +100,7 @@ #define MT_DEVICE_GRE 2 #define MT_NORMAL_NC 3 #define MT_NORMAL 4 +#define MT_NORMAL_WT 5 /* * Memory types for Stage-2 translation diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h index 800ec0e87ed9..5c108ad13558 100644 --- a/arch/arm64/include/asm/pgtable.h +++ b/arch/arm64/include/asm/pgtable.h @@ -61,8 +61,10 @@ extern void __pgd_error(const char *file, int line, unsigned long val); #define PROT_SECT_DEFAULT (PMD_TYPE_SECT | PMD_SECT_AF) #endif +#define PROT_DEVICE_nGnRnE (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_ATTRINDX(MT_DEVICE_nGnRnE)) #define PROT_DEVICE_nGnRE (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_ATTRINDX(MT_DEVICE_nGnRE)) #define PROT_NORMAL_NC(PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_ATTRINDX(MT_NORMAL_NC)) +#define PROT_NORMAL_WT (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_ATTRINDX(MT_NORMAL_WT)) #define PROT_NORMAL (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_ATTRINDX(MT_NORMAL)) #define PROT_SECT_DEVICE_nGnRE(PROT_SECT_DEFAULT | PMD_SECT_PXN | PMD_SECT_UXN | PMD_ATTRINDX(MT_DEVICE_nGnRE)) diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S index 838266f5b056..23e265d732f8 100644 --- a/arch/arm64/mm/proc.S +++ b/arch/arm64/mm/proc.S @@ -294,7 +294,7 @@ ENTRY(__cpu_setup) msr cpacr_el1, x0 // Enable FP/ASIMD msr mdscr_el1, xzr // Reset mdscr_el1 /* -* Memory region attributes for LPAE: +* Memory region attributes for LPAE and EFI: * * n = AttrIndx[2:0] * n MAIR @@ -303,12 +303,14 @@ ENTRY(__cpu_setup) * DEVICE_GRE 010 1100 * NORMAL_NC 011 01000100 * NORMAL 100 +* NORMAL_WT 101 10111011 */ ldr x5, =MAIR(0x00, MT_DEVICE_nGnRnE) | \ MAIR(0x04, MT_DEVICE_nGnRE) | \ MAIR(0x0c, MT_DEVICE_GRE) | \ MAIR(0x44, MT_NORMAL_NC) | \ -MAIR(0xff, MT_NORMAL) +MAIR(0xff, MT_NORMAL) | \ +MAIR(0xbb, MT_NORMAL_WT) msr mair_el1, x5 /* * Prepare SCTLR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/mm/pat: Do a small optimization when dump PAT memtype list
hi, Elliott
thanks for your reply. :)
On 2015年07月23日 22:53, Elliott, Robert (Server Storage) wrote:
>> -Original Message-
>> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
>> ow...@vger.kernel.org] On Behalf Of Pan Xinhui
>> Sent: Thursday, July 23, 2015 4:54 AM
>> To: linux-kernel@vger.kernel.org
>> Subject: [PATCH] x86/mm/pat: Do a small optimization when dump PAT memtype
>> list
> ...
>> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
>> index 268b2c8..6302119 100644
>> --- a/arch/x86/mm/pat.c
>> +++ b/arch/x86/mm/pat.c
>> @@ -1001,45 +1001,42 @@ EXPORT_SYMBOL_GPL(pgprot_writethrough);
>>
>> #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_X86_PAT)
>>
>> -static struct memtype *memtype_get_idx(loff_t pos)
>> +static struct memtype *memtype_get_idx(struct memtype *entry, loff_t pos)
>> {
>> - struct memtype *print_entry;
>> int ret;
>>
>> - print_entry = kzalloc(sizeof(struct memtype), GFP_KERNEL);
>> - if (!print_entry)
>> - return NULL;
>> -
>> spin_lock(_lock);
>> - ret = rbt_memtype_copy_nth_element(print_entry, pos);
>> + ret = rbt_memtype_copy_nth_element(entry, pos);
>> spin_unlock(_lock);
>>
>> - if (!ret) {
>> - return print_entry;
>> - } else {
>> - kfree(print_entry);
>> - return NULL;
>> - }
>> + return ret ? NULL : entry;
>> }
>>
> ...
>> static void memtype_seq_stop(struct seq_file *seq, void *v)
>> {
>> + kfree(seq->private);
>> }
>>
>
> Consider adding
> seq->private = NULL;
> so the stale pointer isn't left around. There's probably not
> much risk of accessing it, but NULL is safer in case it is.
>
I know exactly what are you worrying about.
start and stop callback is still not the best place to alloc/free the *entry*.
you are worrying about that some codes might touch it.
seq_file.c has offered seq_open_private and seq_release_private. we can make
use of them. :)
I will work out patch v2, this time I will Cc you. I am very happy if you could
review it at any free time. :)
thanks
xinhui
> ---
> Robert Elliott, HP Server Storage
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 4.2-rc3: APM xgene2: ethernet doesn't work
Hi Ming, On Thu, Jul 23, 2015 at 2:37 PM, Ming Lei wrote: > Hi Guys, > > When booting from UEFI/ACPI, sometimes there is a crash[1] > from rx path, sometimes there isn't any rx packets comming. > > Firmware version: 2.02.10 > > Thanks, > > [1], crash log > Call trace: > skbuff: skb_over_panic: text:ffc00048094c len:85 put:60 > head: data: (null) tail:0x3c end:0x0 > dev: > Kernel panic - not syncing: BUG! > CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 4.2.0-rc3+ #76 > Hardware name: AppliedMicro Mustang/Mustang, BIOS 2.0.0 Jun 9 2015 > Call trace: > [] dump_backtrace+0x0/0x12c > [] show_stack+0x10/0x1c > [] dump_stack+0x8c/0xdc > [] panic+0xe4/0x220 > [] skb_panic+0x74/0x78 > [] skb_put+0x88/0x8c > [] xgene_enet_process_ring+0xcc/0x394 > [] xgene_enet_napi+0x1c/0x54 > [] net_rx_action+0x124/0x2c0 > [] __do_softirq+0x110/0x238 > [] irq_exit+0x88/0xf0 > [] __handle_domain_irq+0x68/0xb4 > [] gic_handle_irq+0x30/0x7c > Exception stack(0xffc000877dc0 to 0xffc000877ee0) > 7dc0: 00874000 ffc0 0087a648 ffc0 00877f00 ffc0 000869e0 ffc0 > 7de0: 00877f10 ffc0 fffbcb38 ffc7 fffbcb44 ffc7 > 7e00: 0100 da24b9c8 ffc7 fffbe0d9 ffc7 fffbe0d8 ffc7 > 7e20: 008813a0 ffc0 9429 0750 008c93a9 ffc0 > 7e40: 007a1b38 ffc0 007a1b20 ffc0 df5d7500 ffbe > 7e60: 98ab6000 007f 98a9d440 007f 00874000 ffc0 > 7e80: 0087a648 ffc0 00867b00 ffc0 0001 00877f20 ffc0 > 7ea0: 00614500 ffc0 00785000 ffc0 008c9000 ffc0 0087a6cc ffc0 > 7ec0: ffa01348 0047 00877f00 ffc0 000869dc ffc0 00877f00 ffc0 > [] el1_irq+0x64/0xd8 > [] default_idle_call+0x18/0x2c > [] cpu_startup_entry+0xfc/0x180 > [] rest_init+0x80/0x8c > [] start_kernel+0x3c0/0x3d8 > Rebooting in 1 seconds..[DRAM: PHY calibrating ...ignored] > ECC init *ignored] It will be fixed in next release as it is a fix in firmware. -- Thanks, with regards, Suman Tripathi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] block: xfs: dm thin: train XFS to give up on retrying IO if thinp is out of space
On Fri, Jul 24, 2015 at 09:00:54AM +1000, Dave Chinner wrote: > On Thu, Jul 23, 2015 at 12:43:58PM -0400, Vivek Goyal wrote: > > On Thu, Jul 23, 2015 at 03:10:43PM +1000, Dave Chinner wrote: > > > > [..] > > > I don't think knowing the bdev timeout is necessary because the > > > default is most likely to be "fail fast" in this case. i.e. no > > > retries, just shut down. IOWs, if we describe the configs and > > > actions in neutral terms, then the default configurations easy for > > > users to understand. i.e: > > > > > > bdev enospc XFS default > > > --- --- > > > Fail slow Fail fast > > > Fail fast Fail slow > > > Fail neverFail never, Record in log > > > EOPNOTSUPPFail never > > > > > > With that in mind, I'm thinking I should drop the > > > "permanent/transient" error classifications, and change it "failure > > > behaviour" with the options "fast slow [never]" and only the slow > > > option has retry/timeout configuration options. I think the "never" > > > option still needs to "fail at unmount" config variable, but we > > > enable it by default rather than hanging unmount and requiring a > > > manual shutdown like we do now > > > > I am wondering instead of 4 knobs (fast,slow,never,retry-timeout) can > > we just do with one knob per error type and that is retry-timout. > > "retry-timeout" == "fail slow". i.e. a 5 minute retry timeout is > configured as: > > # echo slow > fail_method > # echo 0 > max_retries > # echo 300 > retry_timeout Hi Dave, I am sure I am missing something but I will anyway ask. Why do we need this knob "fail_method". Isn't it sort of implied in other two knobs based on their values. max_retries=0 retry_timeout=0 implies fail_method=fast. A non-zero value of max_retries or retry_timeout implies fail_method=slow A very high value (-1) of either max_retries or retry_timeout implies fail_method="almost never". > > retry-timeout=0 (Fail fast) > > retry-timeout=X (Fail slow) > > retry-timeout=-1 (Never Give up). > > What do we do when we want to add a different failure type > with different configuration requirements? Ok, got it. So we are targettting something very generic so that other cases can be handled too. > > > Also do we really need this timeout per error type. > > I don't follow your logic here. What do need a timeout for with > either the "never" or "fast" failure configurations? Ignore this. I had misunderstood it. > > > Also would be nice if this timeout was configurable using a mount > > option. Then we can just specify it during mount time and be done > > with it. > > That way lies madness. The error configuration iinfrastructure we > need is not just for ENOSPC errors on metadata buffers. We need > configurable error behaviour for multiple different errors in > multiple different subsystems (e.g. data IO failure vs metadata > buffer IO failure vs memory allocation failure vs inode corruption > vs freespace corruption vs ). > > And we still would need the sysfs interface for querying and > configuring at runtime, so mount options are just a bad idea. And > with sysfs, the potential future route for automatic configuration > at mount time is via udev events and configuration files, similar to > block devices. Agreed that sysfs provides lots of flexibility here. I guess I was just thinking in terms of solving this particular issue we are facing. > > > Idea of auto tuning based on what block device is doing sounds reasonable > > but that should not be a requirement for this patch and can go in even > > later. It is one of those nice to have features. > > "this patch"? Just the core infrastructure so far: I was referring to Mike's patch where we add additional method to block device operations. > > 11 files changed, 290 insertions(+), 60 deletions(-) > > and that will need to be split into 4-5 patches for review. There's > a bunch of cleanup that preceeds this, and then there's a patch per > error type we are going to handle in metadata buffer IO completion. > IOWs, the dm-thinp autotuning is just a simple, small patch at the > end of a much larger series - it's maybe 10 lines of code in XFS... Ok. I will wait for the final patches. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the input tree
Hi Stephen,
On July 23, 2015 6:49:36 PM PDT, Stephen Rothwell wrote:
>Hi Dmitry,
>
>After merging the input tree, today's linux-next build (arm
>multi_v7_defconfig) failed like this:
>
>drivers/input/keyboard/samsung-keypad.c: In function
>'samsung_keypad_parse_dt':
>drivers/input/keyboard/samsung-keypad.c:302:40: error: 'pp' undeclared
>(first use in this function)
> pdata->wakeup = of_property_read_bool(pp, "wakeup-source") ||
>^
>
>Caused by commit
>
>7e324dd6cc21 ("Input: samsung-keypad - change name of wakeup property")
Sorry about this, you managed to grab the tree in the couple of hours while the
bad commit was there, it should all be corrected now.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for reading SMBIOS Slot number for PCI devices
On Thu, Jul 23, 2015 at 12:24 PM, Bjorn Helgaas wrote:
> [+cc Matthew for PCIe-SSD perspective]
>
> On Wed, Jul 22, 2015 at 03:07:46PM -0500, Jordan Hargrave wrote:
>> On Tue, Jul 21, 2015 at 8:09 PM, Bjorn Helgaas wrote:
>> > On Tue, Jul 21, 2015 at 12:31:35PM -0500, Jordan Hargrave wrote:
>> >> On Tue, Jul 21, 2015 at 11:57 AM, Bjorn Helgaas
>> >> wrote:
>> >> > On Mon, Jul 13, 2015 at 09:57:32AM -0500, Jordan Hargrave wrote:
>> >> >> On Mon, Jul 13, 2015 at 2:35 AM, Jean Delvare wrote:
>> >> >>
>> >> >> > Hi Jordan,
>> >> >> >
>> >> >> > On Fri, 10 Jul 2015 17:02:46 -0500, Jordan Hargrave wrote:
>> >> >> > > From: Jordan Hargrave
>> >> >> > >
>> >> >> > > There currently isn't an easy way to determine which PCI devices
>> >> >> > > belong
>> >> >> > to
>> >> >> > > system slots. This patch adds support to read SMBIOS Type 9
>> >> >> > > (System
>> >> >> > Slots).
>> >> >> >
>> >> >> > I'm wondering, can't you use dmidecode or libsmbios to retrieve the
>> >> >> > same information?
>> >> >> >
>> >> >> > --
>> >> >> > Jean Delvare
>> >> >> > SUSE L3 Support
>> >> >> >
>> >> >>
>> >> >> You can but it's as not easy to determine the slot number for leaf
>> >> >> devices
>> >> >> on bridges. Eventually planning on using this for pulling slot number
>> >> >> for
>> >> >> identifying network cards and disk numbering for systemd
>> >> >
>> >> > Can you outline the problems with using dmidecode or libsmbios?
>> >>
>> >> Neither dmidecode nor libsmbios report the slot number for devices
>> >> behind bridges in a slot.
>> >
>> > True, but it's straightforward to walk up the PCI tree in sysfs, e.g.,
>> > given a path like /sys/devices/pci:00/:00:1c.5/:03:00.0/, it's
>> > easy to see what the upstream bridges are.
>> >
>> It makes it more complicated I think. You have to check all functions
>> on all devices as well on the walk to the root.
>>
>> Would it look something like this?
>> while (pdev) {
>> if (pdev->bus->number == dslot->bus && PCI_SLOT(pdev->devfn) ==
>> PCI_SLOT(dslot->devfn) &&
>> (pci_pcie_type(pdev) != PCI_ROOT_PORT || PCI_FUNC(pdev->devfn) ==
>> PCI_FUNC(dslot->devfn))
>> return dslot->instance;
>> if (!pdev->bus->parent)
>> break;
>> pdev = pdev->bus->parent->self;
>> }
>>
>> >> I'm wanting to use this sysfs variable to
>> >> get slot numbers for systemd, so using libsmbios and dmidecode aren't
>> >> very useful.
>> >
>> > If you want this in systemd, I see why you wouldn't want a command like
>> > dmidecode. Help me understand the problem with libsmbios. Is it not
>> > useful because (a) systemd doesn't want to link with it, or (b) libsmbios
>> > doesn't have the right information, or (c) something else?
>> >
>> Linking with libsmbios would be a problem, and libsmbios doesn't have
>> this info anyway.
>>
>> > It doesn't *look* like this is using any information that is only available
>> > in the kernel, so in principle it seems like this could be done in
>> > user-space.
>> >
>>
>> I actually just got an email from someone who needs to determine the
>> card slot number in their driver... so I've added an external callable
>> 'pci_get_smbios_slot' function to enable this.
>>
>> >> We already report the index for embedded devices in
>> >> pci-label.c, this code should have gone in at the same time.
>> >>
>> >> For example. The SMBIOS entry for slot 3 is 40:00.0 There is a
>> >> quad-port NIC in the slot with a bridge at 40:00.0
>> >>
>> >> 42:00.0 Bridge (sec=43, sub=45)
>> >> 43:02.0 Bridge (sec=44, sub=44)
>> >> 43:04.0 Bridge (sec=45, sub=45)
>> >> 44:00.0 Ethernet
>> >> 44:00.1 Ethernet
>> >> 45:00.0 Ethernet
>> >> 45:00.1 Ethernet
>> >>
>> >> So dmidecode only returns the slot number for 42:00.0 but not any
>> >> child devices. This code will provide a 'slot' sysfs variable that
>> >> reports '3' for all devices under and including the bridge.
>> >
>> > What if the card in slot 3 is an adapter leading to an external PCI
>> > chassis? Wouldn't we then have a 'slot' file for every card in that
>> > chassis, all containing '3'? This sounds confusing, although it is true
>> > that they all would be connected via the system board slot 3.
>> >
>> Yes that is correct. Unless SMBIOS had a table of the second chassis.
>>
>> > Also, we do have the /sys/bus/pci/slots/ hierarchy already. If we do put
>> > something like this in the kernel, how would it relate to that hierarchy?
>> > Could this SMBIOS stuff be integrated into that somehow?
>> >
>>
>> /sys/bus/pci/slots only map a slot to a single PCI device. systemd
>> does use /sys/bus/pci/slots but it can't see the slot number on cards
>> with bridges as the actual slot number is a parent. And that's not
>> easily to determine a parent device from the slots interface. I'd
>> really like something generic here. I'm also looking for some method
>> for reporting bay/enclosure ID for PCIe-SSD devices.
>>
>> > We have a bit of a hodge-podge of slot names already, and I'd like to
>> > simplify things if we
Re: [PATCH v3 1/3] bpf: Add new bpf map type to store the pointer to struct perf_event
On 7/23/15 7:22 PM, xiakaixu wrote: +/* check if the value is already stored */ >>+if (array->events[index]) >>+return -EINVAL; >>+ >>+/* convert the fd to the pointer to struct perf_event */ >>+event = convert_map_with_perf_event(value); > >imo helper name is misleading and it's too short to be separate >function. Just inline it and you can reuse 'index' variable. > >>+if (!event) >>+return -EBADF; >>+ >>+xchg(array->events + index, event); > >refcnt leak of old event! Please think it through. >This type of bugs I shouldn't be finding. Maybe the commit message is not elaborate. Here I prevent user space from updating the existed event, so the return value of xchg() is NULL and no refcnt leak of old event. I will do the same as prog_array in next version. I see then it's even worse. You think that above check: +if (array->events[index]) +return -EINVAL; will protect the double insert? It won't, since there are no locks here. You can have two processes both seeing empty slot and racing to do xchg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] bpf: Add new bpf map type to store the pointer to struct perf_event
于 2015/7/24 6:54, Alexei Starovoitov 写道:
> On 7/23/15 2:42 AM, Kaixu Xia wrote:
>> Introduce a new bpf map type 'BPF_MAP_TYPE_PERF_EVENT_ARRAY'.
>> This map only stores the pointer to struct perf_event. The
>> user space event FDs from perf_event_open() syscall are converted
>> to the pointer to struct perf_event and stored in map.
> ...
>> +static struct bpf_map *perf_event_array_map_alloc(union bpf_attr *attr)
>> +{
>> +/* only the pointer to struct perf_event can be stored in
>> + * perf_event_array map
>> + */
>> +if (attr->value_size != sizeof(u32))
>> +return ERR_PTR(-EINVAL);
>> +
>> +return array_map_alloc(attr);
>> +}
>
> since it's exactly the same as prog_array_map_alloc(),
> just rename it to something like 'fd_array_map_alloc'
> and use for both types.
>
>> +static int perf_event_array_map_get_next_key(struct bpf_map *map, void *key,
>> + void *next_key)
>> +{
>> +return -EINVAL;
>> +}
>> +
>> +static void *perf_event_array_map_lookup_elem(struct bpf_map *map, void
>> *key)
>> +{
>> +return NULL;
>> +}
>
> same for the above two.
> rename prog_array_map_* into fd_array_map_* and use for both map types.
>
>> +static struct perf_event *convert_map_with_perf_event(void *value)
>> +{
>> +struct perf_event *event;
>> +u32 fd;
>> +
>> +fd = *(u32 *)value;
>> +
>> +event = perf_event_get(fd);
>> +if (IS_ERR(event))
>> +return NULL;
>
> don't lose error code, do 'return event' instead.
>
>> +
>> +/* limit the event type to PERF_TYPE_RAW
>> + * and PERF_TYPE_HARDWARE.
>> + */
>> +if (event->attr.type != PERF_TYPE_RAW &&
>> +event->attr.type != PERF_TYPE_HARDWARE)
>> +return NULL;
>
> perf_event refcnt leak? need to do put_event.
> and return ERR_PTR(-EINVAL)
>
>> +
>> +return event;
>> +}
>> +
>> +/* only called from syscall */
>> +static int perf_event_array_map_update_elem(struct bpf_map *map, void *key,
>> +void *value, u64 map_flags)
>> +{
>> +struct bpf_array *array = container_of(map, struct bpf_array, map);
>> +struct perf_event *event;
>> +u32 index = *(u32 *)key;
>> +
>> +if (map_flags != BPF_ANY)
>> +return -EINVAL;
>> +
>> +if (index >= array->map.max_entries)
>> +return -E2BIG;
>> +
>> +/* check if the value is already stored */
>> +if (array->events[index])
>> +return -EINVAL;
>> +
>> +/* convert the fd to the pointer to struct perf_event */
>> +event = convert_map_with_perf_event(value);
>
> imo helper name is misleading and it's too short to be separate
> function. Just inline it and you can reuse 'index' variable.
>
>> +if (!event)
>> +return -EBADF;
>> +
>> +xchg(array->events + index, event);
>
> refcnt leak of old event! Please think it through.
> This type of bugs I shouldn't be finding.
Maybe the commit message is not elaborate. Here I prevent
user space from updating the existed event, so the return
value of xchg() is NULL and no refcnt leak of old event.
I will do the same as prog_array in next version.
>
>> +static int perf_event_array_map_delete_elem(struct bpf_map *map, void *key)
>> +{
>> +return -EINVAL;
>> +}
>
> no way to dec refcnt of perf_event from user space?
> why not to do the same as prog_array_delete?
Will follow them in V4.
>
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] samples/bpf: example of get selected PMU counter value
On 7/23/15 6:54 PM, xiakaixu wrote:
于 2015/7/24 6:59, Alexei Starovoitov 写道:
On 7/23/15 2:42 AM, Kaixu Xia wrote:
This is a simple example and shows how to use the new ability
to get the selected Hardware PMU counter value.
Signed-off-by: Kaixu Xia
...
+struct bpf_map_def SEC("maps") my_map = {
+.type = BPF_MAP_TYPE_PERF_EVENT_ARRAY,
+.key_size = sizeof(int),
+.value_size = sizeof(unsigned long),
+.max_entries = 32,
+};
wait. how did it work here? value_size should be u32.
I tested the whole thing on ARM board. You are ringt, it
should be u32.
When create the array map, we choose the array->elem_size as
round_up(attr->value_size, 8), why 8?
because from user space point of view we're storing FDs
which are u32, but kernel stores pointers.
but round_up(attr->value_size, 8) is done because there
can be 8 byte fields in there and we have 8-byte load/store insns.
So whether pointer is 32 or 64-bit they still fit.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] cpufreq: Separate CPU device removal from CPU online
On 23-07-15, 22:56, Rafael J. Wysocki wrote:
> > > + if (policy && policy->kobj_cpu != cpu) {
> >
> > Why are you comparing cpu against kobj_cpu ? I don't think it can ever
> > be false.
So what I meant was that the expression 'policy->kobj_cpu != cpu' will
never return 'false'. Because policy->kobj_cpu is going to get set to
the cpu for which we allocated the policy. And so it wouldn't match
for any other CPU.
> It can. When we're adding a CPU that has a policy already, because it is
> "related" to a previously registered CPU.
In this case also the expression will return true.
> > > + ret = sysfs_create_link(>kobj, >kobj, "cpufreq");
> > > + if (ret) {
> > > + dev_dbg(dev, "%s: Failed to create link (%d)\n",
> >
> > dev_err
>
> Well, I'm wondering about this. Why does this have to be dev_err()?
Isn't this an error? We need to create a symlink, we failed and
atleast the user should know about it. Why hide such failures ?
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 31/42] x86, efi: Copy SETUP_EFI data and access directly
Hi,
On 07/07/15 at 01:20pm, Yinghai Lu wrote:
> The copy will be in __initdata, and it is small.
>
> We can use pointer to access the setup_data instead of using early_memmap
> everywhere.
Looks good to me except one issue about missing checking memremap return value.
see the comment inline
>
> Cc: Matt Fleming
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Yinghai Lu
> ---
[snip]
> --- a/arch/x86/platform/efi/efi_64.c
> +++ b/arch/x86/platform/efi/efi_64.c
> @@ -295,9 +295,17 @@ void __iomem *__init efi_ioremap(unsigned long
> phys_addr, unsigned long size,
> return (void __iomem *)__va(phys_addr);
> }
>
> +static struct efi_setup_data efi_setup_data __initdata;
> +
> void __init parse_efi_setup(u64 phys_addr, u32 data_len)
> {
> - efi_setup = phys_addr + sizeof(struct setup_data);
> + struct efi_setup_data *data;
> +
> + data = early_memremap(phys_addr + sizeof(struct setup_data),
> + sizeof(*data));
There should be a checking for return value here..
> + efi_setup_data = *data;
> + early_memunmap(data, sizeof(*data));
> + efi_setup = _setup_data;
> }
>
[snip]
Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/18] perf: Add PERF_RECORD_SWITCH to indicate context switches
From: Adrian Hunter
There are already two events for context switches, namely the tracepoint
sched:sched_switch and the software event context_switches.
Unfortunately neither are suitable for use by non-privileged users for
the purpose of synchronizing hardware trace data (e.g. Intel PT) to the
context switch.
Tracepoints are no good at all for non-privileged users because they
need either CAP_SYS_ADMIN or /proc/sys/kernel/perf_event_paranoid <= -1.
On the other hand, kernel software events need either CAP_SYS_ADMIN or
/proc/sys/kernel/perf_event_paranoid <= 1.
Now many distributions do default perf_event_paranoid to 1 making
context_switches a contender, except it has another problem (which is
also shared with sched:sched_switch) which is that it happens before
perf schedules events out instead of after perf schedules events in.
Whereas a privileged user can see all the events anyway, a
non-privileged user only sees events for their own processes, in other
words they see when their process was scheduled out not when it was
scheduled in. That presents two problems to use the event:
1. the information comes too late, so tools have to look ahead in the
event stream to find out what the current state is
2. if they are unlucky tracing might have stopped before the
context-switches event is recorded.
This new PERF_RECORD_SWITCH event does not have those problems
and it also has a couple of other small advantages.
It is easier to use because it is an auxiliary event (like mmap, comm
and task events) which can be enabled by setting a single bit. It is
smaller than sched:sched_switch and easier to parse.
To make the event useful for privileged users also, if the
context is cpu-wide then the event record will be
PERF_RECORD_SWITCH_CPU_WIDE which is the same as
PERF_RECORD_SWITCH except it also provides the next or
previous pid/tid.
Signed-off-by: Adrian Hunter
Acked-by: Peter Zijlstra (Intel)
Tested-by: Jiri Olsa
Cc: Andi Kleen
Cc: Mathieu Poirier
Cc: Pawel Moll
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1437471846-26995-2-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
include/uapi/linux/perf_event.h | 31 +++-
kernel/events/core.c| 103
2 files changed, 133 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index d97f84c080da..022d0acf7df0 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -330,7 +330,8 @@ struct perf_event_attr {
mmap2 : 1, /* include mmap with inode
data */
comm_exec : 1, /* flag comm events that
are due to an exec */
use_clockid: 1, /* use @clockid for time
fields */
- __reserved_1 : 38;
+ context_switch : 1, /* context switch data */
+ __reserved_1 : 37;
union {
__u32 wakeup_events;/* wakeup every n events */
@@ -572,9 +573,11 @@ struct perf_event_mmap_page {
/*
* PERF_RECORD_MISC_MMAP_DATA and PERF_RECORD_MISC_COMM_EXEC are used on
* different events so can reuse the same bit position.
+ * Ditto PERF_RECORD_MISC_SWITCH_OUT.
*/
#define PERF_RECORD_MISC_MMAP_DATA (1 << 13)
#define PERF_RECORD_MISC_COMM_EXEC (1 << 13)
+#define PERF_RECORD_MISC_SWITCH_OUT(1 << 13)
/*
* Indicates that the content of PERF_SAMPLE_IP points to
* the actual instruction that triggered the event. See also
@@ -818,6 +821,32 @@ enum perf_event_type {
*/
PERF_RECORD_LOST_SAMPLES= 13,
+ /*
+* Records a context switch in or out (flagged by
+* PERF_RECORD_MISC_SWITCH_OUT). See also
+* PERF_RECORD_SWITCH_CPU_WIDE.
+*
+* struct {
+* struct perf_event_headerheader;
+* struct sample_idsample_id;
+* };
+*/
+ PERF_RECORD_SWITCH = 14,
+
+ /*
+* CPU-wide version of PERF_RECORD_SWITCH with next_prev_pid and
+* next_prev_tid that are the next (switching out) or previous
+* (switching in) pid/tid.
+*
+* struct {
+* struct perf_event_headerheader;
+* u32 next_prev_pid;
+* u32 next_prev_tid;
+* struct sample_idsample_id;
+* };
+*/
+ PERF_RECORD_SWITCH_CPU_WIDE = 15,
+
PERF_RECORD_MAX,/* non-ABI */
};
diff --git a/kernel/events/core.c b/kernel/events/core.c
index d3dae3419b99..ce21143c0d9e 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -163,6 +163,7 @@ static atomic_t nr_mmap_events
[PATCH 05/18] perf header: Use argv style storage for cmdline feature data
From: Jiri Olsa
We will reuse argv style data in following change to display counters
header showing monitored command line.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1437481927-29538-12-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/header.c | 35 ---
tools/perf/util/header.h | 1 +
tools/perf/util/session.c | 1 +
3 files changed, 22 insertions(+), 15 deletions(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 03ace57a800c..179b2bdd157d 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -923,17 +923,13 @@ static void print_cmdline(struct perf_header *ph, int fd
__maybe_unused,
FILE *fp)
{
int nr, i;
- char *str;
nr = ph->env.nr_cmdline;
- str = ph->env.cmdline;
fprintf(fp, "# cmdline : ");
- for (i = 0; i < nr; i++) {
- fprintf(fp, "%s ", str);
- str += strlen(str) + 1;
- }
+ for (i = 0; i < nr; i++)
+ fprintf(fp, "%s ", ph->env.cmdline_argv[i]);
fputc('\n', fp);
}
@@ -1541,14 +1537,13 @@ process_event_desc(struct perf_file_section *section
__maybe_unused,
return 0;
}
-static int process_cmdline(struct perf_file_section *section __maybe_unused,
+static int process_cmdline(struct perf_file_section *section,
struct perf_header *ph, int fd,
void *data __maybe_unused)
{
ssize_t ret;
- char *str;
- u32 nr, i;
- struct strbuf sb;
+ char *str, *cmdline = NULL, **argv = NULL;
+ u32 nr, i, len = 0;
ret = readn(fd, , sizeof(nr));
if (ret != sizeof(nr))
@@ -1558,22 +1553,32 @@ static int process_cmdline(struct perf_file_section
*section __maybe_unused,
nr = bswap_32(nr);
ph->env.nr_cmdline = nr;
- strbuf_init(, 128);
+
+ cmdline = zalloc(section->size + nr + 1);
+ if (!cmdline)
+ return -1;
+
+ argv = zalloc(sizeof(char *) * (nr + 1));
+ if (!argv)
+ goto error;
for (i = 0; i < nr; i++) {
str = do_read_string(fd, ph);
if (!str)
goto error;
- /* include a NULL character at the end */
- strbuf_add(, str, strlen(str) + 1);
+ argv[i] = cmdline + len;
+ memcpy(argv[i], str, strlen(str) + 1);
+ len += strlen(str) + 1;
free(str);
}
- ph->env.cmdline = strbuf_detach(, NULL);
+ ph->env.cmdline = cmdline;
+ ph->env.cmdline_argv = (const char **) argv;
return 0;
error:
- strbuf_release();
+ free(argv);
+ free(cmdline);
return -1;
}
diff --git a/tools/perf/util/header.h b/tools/perf/util/header.h
index d4d57962c591..9b53b6525ce8 100644
--- a/tools/perf/util/header.h
+++ b/tools/perf/util/header.h
@@ -84,6 +84,7 @@ struct perf_session_env {
int nr_pmu_mappings;
int nr_groups;
char*cmdline;
+ const char **cmdline_argv;
char*sibling_cores;
char*sibling_threads;
char*numa_nodes;
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index ed9dc2555ec7..fb1d525ca3d0 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -180,6 +180,7 @@ static void perf_session_env__delete(struct
perf_session_env *env)
zfree(>cpuid);
zfree(>cmdline);
+ zfree(>cmdline_argv);
zfree(>sibling_cores);
zfree(>sibling_threads);
zfree(>numa_nodes);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/18] perf tools: Add new PERF_RECORD_SWITCH event
From: Adrian Hunter
Support processing of PERF_RECORD_SWITCH events and
PERF_RECORD_SWITCH_CPU_WIDE events. There is a single
tools callback for them both so that the tool must
check the event type before using the extra members
in PERF_RECORD_SWITCH_CPU_WIDE.
There is still no way to select the events, though.
That is added in a subsequest patch.
Signed-off-by: Adrian Hunter
Acked-by: Peter Zijlstra (Intel)
Tested-by: Jiri Olsa
Cc: Andi Kleen
Cc: Mathieu Poirier
Cc: Pawel Moll
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1437471846-26995-3-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-inject.c | 1 +
tools/perf/util/event.c | 28
tools/perf/util/event.h | 12
tools/perf/util/evsel.c | 1 +
tools/perf/util/machine.c | 11 +++
tools/perf/util/machine.h | 2 ++
tools/perf/util/session.c | 20
tools/perf/util/tool.h | 1 +
8 files changed, 76 insertions(+)
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 01b06492bd6a..f62c49b35be0 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -561,6 +561,7 @@ int cmd_inject(int argc, const char **argv, const char
*prefix __maybe_unused)
.lost = perf_event__repipe,
.aux= perf_event__repipe,
.itrace_start = perf_event__repipe,
+ .context_switch = perf_event__repipe,
.read = perf_event__repipe_sample,
.throttle = perf_event__repipe,
.unthrottle = perf_event__repipe,
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 67a977e5d0ab..7ff61274ed57 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -26,6 +26,8 @@ static const char *perf_event__names[] = {
[PERF_RECORD_AUX] = "AUX",
[PERF_RECORD_ITRACE_START] = "ITRACE_START",
[PERF_RECORD_LOST_SAMPLES] = "LOST_SAMPLES",
+ [PERF_RECORD_SWITCH]= "SWITCH",
+ [PERF_RECORD_SWITCH_CPU_WIDE] = "SWITCH_CPU_WIDE",
[PERF_RECORD_HEADER_ATTR] = "ATTR",
[PERF_RECORD_HEADER_EVENT_TYPE] = "EVENT_TYPE",
[PERF_RECORD_HEADER_TRACING_DATA] = "TRACING_DATA",
@@ -749,6 +751,14 @@ int perf_event__process_lost_samples(struct perf_tool
*tool __maybe_unused,
return machine__process_lost_samples_event(machine, event, sample);
}
+int perf_event__process_switch(struct perf_tool *tool __maybe_unused,
+ union perf_event *event,
+ struct perf_sample *sample __maybe_unused,
+ struct machine *machine)
+{
+ return machine__process_switch_event(machine, event);
+}
+
size_t perf_event__fprintf_mmap(union perf_event *event, FILE *fp)
{
return fprintf(fp, " %d/%d: [%#" PRIx64 "(%#" PRIx64 ") @ %#" PRIx64
"]: %c %s\n",
@@ -827,6 +837,20 @@ size_t perf_event__fprintf_itrace_start(union perf_event
*event, FILE *fp)
event->itrace_start.pid, event->itrace_start.tid);
}
+size_t perf_event__fprintf_switch(union perf_event *event, FILE *fp)
+{
+ bool out = event->header.misc & PERF_RECORD_MISC_SWITCH_OUT;
+ const char *in_out = out ? "OUT" : "IN ";
+
+ if (event->header.type == PERF_RECORD_SWITCH)
+ return fprintf(fp, " %s\n", in_out);
+
+ return fprintf(fp, " %s %s pid/tid: %5u/%-5u\n",
+ in_out, out ? "next" : "prev",
+ event->context_switch.next_prev_pid,
+ event->context_switch.next_prev_tid);
+}
+
size_t perf_event__fprintf(union perf_event *event, FILE *fp)
{
size_t ret = fprintf(fp, "PERF_RECORD_%s",
@@ -852,6 +876,10 @@ size_t perf_event__fprintf(union perf_event *event, FILE
*fp)
case PERF_RECORD_ITRACE_START:
ret += perf_event__fprintf_itrace_start(event, fp);
break;
+ case PERF_RECORD_SWITCH:
+ case PERF_RECORD_SWITCH_CPU_WIDE:
+ ret += perf_event__fprintf_switch(event, fp);
+ break;
default:
ret += fprintf(fp, "\n");
}
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index c53f36384b64..4bb2ae894c78 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -348,6 +348,12 @@ struct itrace_start_event {
u32 pid, tid;
};
+struct context_switch_event {
+ struct perf_event_header header;
+ u32 next_prev_pid;
+ u32 next_prev_tid;
+};
+
union perf_event {
struct perf_event_headerheader;
struct mmap_event mmap;
@@ -369,6 +375,7 @@ union perf_event {
struct auxtrace_error_event
[PATCH 11/18] perf script: Switch from perf.data's kallsyms to perf's symbol resolver
From: Arnaldo Carvalho de Melo
We were storing a copy of kallsyms inside perf.data file so that we
could resolve kernel addresses to function (start, name, mod) tuples,
but that can be achieved using the symbol resolving routines we have
in symbols.c, and that are used elsewhere in tools/perf.
So, do just like 'perf trace' did and ask libtraceevent to use perf's
symbol resolution routines.
The next step is to just skip whatever kallsyms data is embedded in
older perf.data files and finally to stop storing kallsyms in the perf
data file, as the 20-bytes build-id stored in perf.data's header is
enough to find out the right symtab (be it ELF, kcore, kallsyms, etc) to
use.
Acked-by: David Ahern
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Stephane Eranian
Cc: Steven Rostedt
Link: http://lkml.kernel.org/n/tip-d0rtb8tk9j72pz0ehw5fn...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-script.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 24809787369f..2777c6444bc3 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -1830,6 +1830,13 @@ int cmd_script(int argc, const char **argv, const char
*prefix __maybe_unused)
else
symbol_conf.use_callchain = false;
+ if (pevent_set_function_resolver(session->tevent.pevent,
+machine__resolve_kernel_addr,
+>machines.host) < 0) {
+ pr_err("%s: failed to set libtraceevent function resolver\n",
__func__);
+ return -1;
+ }
+
if (generate_script_lang) {
struct stat perf_stat;
int input;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/18] perf symbols: Introduce map__is_(kernel,kmodule)()
From: Arnaldo Carvalho de Melo
To, with members we already have, check if a kernel level map is for the
kernel proper or for a module.
Acked-by: David Ahern
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-m5ic7h0z2crmtj7vi1a1r...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/map.c | 14 ++
tools/perf/util/map.h | 7 +++
2 files changed, 21 insertions(+)
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index b5a5e9c02437..ce37e95bc513 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -224,6 +224,20 @@ struct map *map__new2(u64 start, struct dso *dso, enum
map_type type)
return map;
}
+/*
+ * Use this and __map__is_kmodule() for map instances that are in
+ * machine->kmaps, and thus have map->groups->machine all properly set, to
+ * disambiguate between the kernel and modules.
+ *
+ * When the need arises, introduce map__is_{kernel,kmodule)() that
+ * checks (map->groups != NULL && map->groups->machine != NULL &&
+ * map->dso->kernel) before calling __map__is_{kernel,kmodule}())
+ */
+bool __map__is_kernel(const struct map *map)
+{
+ return map->groups->machine->vmlinux_maps[map->type] == map;
+}
+
static void map__exit(struct map *map)
{
BUG_ON(!RB_EMPTY_NODE(>rb_node));
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index d73e687b224e..57829e89b78b 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -256,4 +256,11 @@ int map_groups__fixup_overlappings(struct map_groups *mg,
struct map *map,
struct map *map_groups__find_by_name(struct map_groups *mg,
enum map_type type, const char *name);
+bool __map__is_kernel(const struct map *map);
+
+static inline bool __map__is_kmodule(const struct map *map)
+{
+ return !__map__is_kernel(map);
+}
+
#endif /* __PERF_MAP_H */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] ACPI: Update method tracing facility.
Hi, Rafael ACPICA logs contain details (trace logs) that may be useful for development. But the quantity of the trace logs are huge to be put into the kernel log buffer. Originally, we have a "trace log reducer" in /sys/modules/acpi/parameter, it is the method tracing facility. We can specify a method name, for example, "_PS0", and corresponding debug layer/level for the "trace log reducer". When the AML interpreter starts to execute the method, the tracing debug level/layer will be applied. When the AML interpreter stops to execute the method, the original debug level/layer is restored. Thus the ACPICA trace logs can only be enabled during the period the specified method is executed and its output thus can be reduced. The facility invokes acpi_debug_trace() to do the flexible settings. See Documentation/acpi/method-tracing.txt for reference. Actually, the "trace log reducer" facility is buggy and some of the shortcomings put us into the trouble in using it. 1. We cannot specify a full path for the tracing method. For example, though we only want to track \_SB,PCI0.I2C0._PS0, we can only specify "_PS0" and all _PS0 method execution logs will be dumped, the unwanted _PS0 execution trace logs may still blow the kernel log buffer up. 2. We can only specify a method that is passed to acpi_evaluate_object(). For example, if \_SB.LID0._LID invokes \_SB.PCI0.LPCB.H_EC.ECRD, since Linux never passes \_SB.PCI0.LPCB.H_EC.ECRD to acpi_evaluate_object(), specifying "ECRD" cannot match the start of the execution to enable the "trace log reducer". So during this ACPICA release, we re-implement the facility in the ACPICA dispatcher rather than implementing it in acpi_evaluate_object and allows the full path to be specified to precisely lock on a specific control method. It is achieved by doing the following improvements: 1. Re-implements the facility in the ACPICA dispatcher component. 1. Introduce a new AML path -> ASL path decoding facility to zap the trailing underscore. Originally ACPICA decodes AML path into such a format that the user must explicitly specify the trailing. And users are likely to forget to put the underscores and leave us with useless trace logs. 2. Move the exception stack walker from the ACPICA debugger component to the ACPICA dispatcher component. When an exception is encountered, AML interpreter just jumps to the top of the stack. Thus we need a facility to walk the stack so that the method can be matched to implement the "end of the tracing". And with the improvements, we now can do an exciting tracing: 1. When the trace is enabled, we add new log entries for the begin/end of each control method that is executed by the interpreter. 2. When the trace is enabled, we add new log entries for the begin/end of each opcode that is executed by the interpreter. 3. We allow the method virtual address and the opcode virtual address to be dumped along with the begin/end logs. This makes it possible to draw a AML call graph using the dumped log and we can calculate the execution time of a control method/opcode. We can use it either for performance tuning or remote debugging. The new feature is known as "AML execution tracer". All of above improvements are done to the acpi_debug_trace(), new features/parameters are added to this ACPICA interface. Now acpi_debug_trace() can be used not only as the "trace log reducer" but also the "AML execution tracer". As its user, /sys/modules/acpi/parameters/trace_xxx files need to be updated so that we can use the fixed/improved old feature and the new feature in the Linux kernel. There is an user experience example of the new feature (AML execution tracer) on the kernel Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70891 The user reported a delay to the ACPICA developers mailing list and I helped to file a bug there. With the assistance of this debugging facility (see comment 29, 30, 31), I found the delay was caused by the EC driver (so this is really an effective debugging facility). This bug (erroneously reported as an ACPICA issue) motivated me to look at the Linux EC driver and offered the fixes to help to improve the quality of the EC/GPE implementations. Hope this explanation can help. Thanks and best regards -Lv > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Friday, July 24, 2015 4:51 AM > > On Thursday, July 23, 2015 01:06:37 PM Lv Zheng wrote: > > This patch updates method tracing facility according to ACPICA 20150717 > > release changes. > > Can you please explain this in a few more words. > > Why do we need to update the interface? > > Rafael
Re: [RESEND PATCH 2/6] soc: Mediatek: Add SCPSYS CPU power domain driver
On Tue, 2015-06-23 at 07:53 +0200, Sascha Hauer wrote: > Hi Scott, > > On Fri, Jun 19, 2015 at 02:01:17AM +0800, Scott Shu wrote: > > This adds a CPU power domain driver for the Mediatek SCPSYS unit on > > MT6580. > > This seems to be support for the very same hardware as I am posting > here: > > https://lkml.org/lkml/2015/6/22/41 > > We should consolidate this. > > My driver is currently handles all power domains except the CPUs while > yours handles only the CPUs. > I currently haven't looked whether CPUs can just be part of a power > domain aswell, but if that works this would probably be the way to go. > > Sascha > > Hi Sascga, We had posted new patch set in following link, but still keep our original framework. http://lists.infradead.org/pipermail/linux-mediatek/2015-July/001498.html As we mentioned in the new email thread, the SMP operations (smp_boot_secondary) will be executed before registering the scpsys_drv driver, so the CPUs power domain is controlled on arch/arm/mach-$(MACHINE) directory. Please kindly provide your comments and suggestion. Thank you very much. Best Regards, Scott Shu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/18] perf tools: Stop reading the kallsyms data from perf.data
From: Arnaldo Carvalho de Melo
As it is not used anymore, since 'perf script' switched to asking
libtraceevent to use tools/perf's symbol resolution routines.
Acked-by: David Ahern
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Stephane Eranian
Cc: Steven Rostedt
Link: http://lkml.kernel.org/n/tip-4ilhofz4b7o8yokvutjt9...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/trace-event-parse.c | 30 --
tools/perf/util/trace-event-read.c | 28 +---
2 files changed, 13 insertions(+), 45 deletions(-)
diff --git a/tools/perf/util/trace-event-parse.c
b/tools/perf/util/trace-event-parse.c
index d4957418657e..8ff7d620d942 100644
--- a/tools/perf/util/trace-event-parse.c
+++ b/tools/perf/util/trace-event-parse.c
@@ -135,36 +135,6 @@ void event_format__print(struct event_format *event,
return event_format__fprintf(event, cpu, data, size, stdout);
}
-void parse_proc_kallsyms(struct pevent *pevent,
-char *file, unsigned int size __maybe_unused)
-{
- unsigned long long addr;
- char *func;
- char *line;
- char *next = NULL;
- char *addr_str;
- char *mod;
- char *fmt = NULL;
-
- line = strtok_r(file, "\n", );
- while (line) {
- mod = NULL;
- addr_str = strtok_r(line, " ", );
- addr = strtoull(addr_str, NULL, 16);
- /* skip character */
- strtok_r(NULL, " ", );
- func = strtok_r(NULL, "\t", );
- mod = strtok_r(NULL, "]", );
- /* truncate the extra '[' */
- if (mod)
- mod = mod + 1;
-
- pevent_register_function(pevent, func, addr, mod);
-
- line = strtok_r(NULL, "\n", );
- }
-}
-
void parse_ftrace_printk(struct pevent *pevent,
char *file, unsigned int size __maybe_unused)
{
diff --git a/tools/perf/util/trace-event-read.c
b/tools/perf/util/trace-event-read.c
index 54d9e9b548a8..b67a0ccf5ab9 100644
--- a/tools/perf/util/trace-event-read.c
+++ b/tools/perf/util/trace-event-read.c
@@ -162,25 +162,23 @@ out:
static int read_proc_kallsyms(struct pevent *pevent)
{
unsigned int size;
- char *buf;
size = read4(pevent);
if (!size)
return 0;
-
- buf = malloc(size + 1);
- if (buf == NULL)
- return -1;
-
- if (do_read(buf, size) < 0) {
- free(buf);
- return -1;
- }
- buf[size] = '\0';
-
- parse_proc_kallsyms(pevent, buf, size);
-
- free(buf);
+ /*
+* Just skip it, now that we configure libtraceevent to use the
+* tools/perf/ symbol resolver.
+*
+* We need to skip it so that we can continue parsing old perf.data
+* files, that contains this /proc/kallsyms payload.
+*
+* Newer perf.data files will have just the 4-bytes zeros "kallsyms
+* payload", so that older tools can continue reading it and interpret
+* it as "no kallsyms payload is present".
+*/
+ lseek(input_fd, size, SEEK_CUR);
+ trace_data_size += size;
return 0;
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the mmc-uh tree with the imx-mxs tree
Hi Ulf,
Today's linux-next merge of the mmc-uh tree got conflicts in:
arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
between commit:
82a5485b6aef ("ARM: dts: ventana: add UHS-I support for Ventana boards")
from the imx-mxs tree and commit:
849dea0a52d2 ("dts: imx6: fix sd card gpio polarity specified in device tree")
from the mmc-uh tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
index b8e35513aed2,4493f6e99330..
--- a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
@@@ -316,13 -316,10 +316,13 @@@
};
{
- pinctrl-names = "default";
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <_usdhc3>;
+ pinctrl-1 = <_usdhc3_100mhz>;
+ pinctrl-2 = <_usdhc3_200mhz>;
- cd-gpios = < 0 GPIO_ACTIVE_HIGH>;
+ cd-gpios = < 0 GPIO_ACTIVE_LOW>;
vmmc-supply = <_3p3v>;
+ no-1-8-v; /* firmware will remove if board revision supports */
status = "okay";
};
diff --cc arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
index 765c3a758ae0,a857d1294609..
--- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
@@@ -322,13 -322,10 +322,13 @@@
};
{
- pinctrl-names = "default";
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <_usdhc3>;
+ pinctrl-1 = <_usdhc3_100mhz>;
+ pinctrl-2 = <_usdhc3_200mhz>;
- cd-gpios = < 0 GPIO_ACTIVE_HIGH>;
+ cd-gpios = < 0 GPIO_ACTIVE_LOW>;
vmmc-supply = <_3p3v>;
+ no-1-8-v; /* firmware will remove if board revision supports */
status = "okay";
};
diff --cc arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
index 1100aab4be54,1afe3385e2d2..
--- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
@@@ -415,13 -415,10 +415,13 @@@
};
{
- pinctrl-names = "default";
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <_usdhc3>;
+ pinctrl-1 = <_usdhc3_100mhz>;
+ pinctrl-2 = <_usdhc3_200mhz>;
- cd-gpios = < 0 GPIO_ACTIVE_HIGH>;
+ cd-gpios = < 0 GPIO_ACTIVE_LOW>;
vmmc-supply = <_3p3v>;
+ no-1-8-v; /* firmware will remove if board revision supports */
status = "okay";
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/18] perf tools: Stop copying kallsyms into the perf.data file header
From: Arnaldo Carvalho de Melo
Since we now ask libtraceevent, the only user of this payload, to use
perf's symbol resolution routines, there is no need to carry about
~4.5MB per perf.data when we can get it from one of the places the perf
symbol resolution looks for that symtab (debuginfo, ~/.debug/,
/proc/kallsyms, --symfs, etc), using the kernel and modules build-ids to
make sure the right table is used.
Acked-by: David Ahern
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Stephane Eranian
Cc: Steven Rostedt
Link: http://lkml.kernel.org/n/tip-h89ituf9rso2rv1v7kjrb...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/trace-event-info.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/tools/perf/util/trace-event-info.c
b/tools/perf/util/trace-event-info.c
index eb72716017ac..22245986e59e 100644
--- a/tools/perf/util/trace-event-info.c
+++ b/tools/perf/util/trace-event-info.c
@@ -341,20 +341,14 @@ out:
static int record_proc_kallsyms(void)
{
- unsigned int size;
- const char *path = "/proc/kallsyms";
- struct stat st;
- int ret, err = 0;
-
- ret = stat(path, );
- if (ret < 0) {
- /* not found */
- size = 0;
- if (write(output_fd, , 4) != 4)
- err = -EIO;
- return err;
- }
- return record_file(path, 4);
+ unsigned long long size = 0;
+ /*
+* Just to keep older perf.data file parsers happy, record a zero
+* sized kallsyms file, i.e. do the same thing that was done when
+* /proc/kallsyms (or something specified via --kallsyms, in a
+* different path) couldn't be read.
+*/
+ return write(output_fd, , 4) != 4 ? -EIO : 0;
}
static int record_ftrace_printk(void)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 17/18] perf script: Don't assume evsel position of tracking events
From: Adrian Hunter
The tracking event does not have to be the first event so replace
perf_evlist__first() with perf_evlist__id2evsel() which uses the event
ID to find the correct evsel.
Signed-off-by: Adrian Hunter
Acked-by: Peter Zijlstra (Intel)
Tested-by: Jiri Olsa
Cc: Andi Kleen
Cc: Mathieu Poirier
Cc: Pawel Moll
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1437471846-26995-5-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-script.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 2777c6444bc3..8a8e2ead6382 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -661,7 +661,7 @@ static int process_comm_event(struct perf_tool *tool,
struct thread *thread;
struct perf_script *script = container_of(tool, struct perf_script,
tool);
struct perf_session *session = script->session;
- struct perf_evsel *evsel = perf_evlist__first(session->evlist);
+ struct perf_evsel *evsel = perf_evlist__id2evsel(session->evlist,
sample->id);
int ret = -1;
thread = machine__findnew_thread(machine, event->comm.pid,
event->comm.tid);
@@ -695,7 +695,7 @@ static int process_fork_event(struct perf_tool *tool,
struct thread *thread;
struct perf_script *script = container_of(tool, struct perf_script,
tool);
struct perf_session *session = script->session;
- struct perf_evsel *evsel = perf_evlist__first(session->evlist);
+ struct perf_evsel *evsel = perf_evlist__id2evsel(session->evlist,
sample->id);
if (perf_event__process_fork(tool, event, sample, machine) < 0)
return -1;
@@ -727,7 +727,7 @@ static int process_exit_event(struct perf_tool *tool,
struct thread *thread;
struct perf_script *script = container_of(tool, struct perf_script,
tool);
struct perf_session *session = script->session;
- struct perf_evsel *evsel = perf_evlist__first(session->evlist);
+ struct perf_evsel *evsel = perf_evlist__id2evsel(session->evlist,
sample->id);
thread = machine__findnew_thread(machine, event->fork.pid,
event->fork.tid);
if (thread == NULL) {
@@ -759,7 +759,7 @@ static int process_mmap_event(struct perf_tool *tool,
struct thread *thread;
struct perf_script *script = container_of(tool, struct perf_script,
tool);
struct perf_session *session = script->session;
- struct perf_evsel *evsel = perf_evlist__first(session->evlist);
+ struct perf_evsel *evsel = perf_evlist__id2evsel(session->evlist,
sample->id);
if (perf_event__process_mmap(tool, event, sample, machine) < 0)
return -1;
@@ -790,7 +790,7 @@ static int process_mmap2_event(struct perf_tool *tool,
struct thread *thread;
struct perf_script *script = container_of(tool, struct perf_script,
tool);
struct perf_session *session = script->session;
- struct perf_evsel *evsel = perf_evlist__first(session->evlist);
+ struct perf_evsel *evsel = perf_evlist__id2evsel(session->evlist,
sample->id);
if (perf_event__process_mmap2(tool, event, sample, machine) < 0)
return -1;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/18] perf symbols: Add front end cache for DSO symbol lookup
From: Arnaldo Carvalho de Melo
Acked-by: David Ahern
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-voo94tow8wpkcc76mlkny...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/dso.h| 4
tools/perf/util/symbol.c | 7 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
index 2fe98bb0e95b..c73276db6d6f 100644
--- a/tools/perf/util/dso.h
+++ b/tools/perf/util/dso.h
@@ -137,6 +137,10 @@ struct dso {
struct rb_node rb_node; /* rbtree node sorted by long name */
struct rb_root symbols[MAP__NR_TYPES];
struct rb_root symbol_names[MAP__NR_TYPES];
+ struct {
+ u64 addr;
+ struct symbol *symbol;
+ } last_find_result[MAP__NR_TYPES];
void *a2l;
char *symsrc_filename;
unsigned int a2l_fails;
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 45c2e3a8316b..725640fd7cd8 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -444,7 +444,12 @@ static struct symbol *symbols__find_by_name(struct rb_root
*symbols,
struct symbol *dso__find_symbol(struct dso *dso,
enum map_type type, u64 addr)
{
- return symbols__find(>symbols[type], addr);
+ if (dso->last_find_result[type].addr != addr) {
+ dso->last_find_result[type].addr = addr;
+ dso->last_find_result[type].symbol =
symbols__find(>symbols[type], addr);
+ }
+
+ return dso->last_find_result[type].symbol;
}
struct symbol *dso__first_symbol(struct dso *dso, enum map_type type)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 18/18] perf script: Add option --show-switch-events
From: Adrian Hunter
Add option --show-switch-events to show switch events in a similar
fashion to --show-task-events and --show-mmap-events.
Signed-off-by: Adrian Hunter
Acked-by: Peter Zijlstra (Intel)
Tested-by: Jiri Olsa
Tested-by: Arnaldo Carvalho de Melo
Cc: Andi Kleen
Cc: Mathieu Poirier
Cc: Pawel Moll
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1437471846-26995-6-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/perf-script.txt | 4
tools/perf/builtin-script.c | 31 +++
2 files changed, 35 insertions(+)
diff --git a/tools/perf/Documentation/perf-script.txt
b/tools/perf/Documentation/perf-script.txt
index c82df572fac2..e2fec5fc21e7 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -222,6 +222,10 @@ OPTIONS
--show-mmap-events
Display mmap related events (e.g. MMAP, MMAP2).
+--show-switch-events
+ Display context switch events i.e. events of type PERF_RECORD_SWITCH or
+ PERF_RECORD_SWITCH_CPU_WIDE.
+
--header
Show perf.data header.
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 8a8e2ead6382..bd31380122f9 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -623,6 +623,7 @@ struct perf_script {
struct perf_session *session;
boolshow_task_events;
boolshow_mmap_events;
+ boolshow_switch_events;
};
static int process_attr(struct perf_tool *tool, union perf_event *event,
@@ -813,6 +814,32 @@ static int process_mmap2_event(struct perf_tool *tool,
return 0;
}
+static int process_switch_event(struct perf_tool *tool,
+ union perf_event *event,
+ struct perf_sample *sample,
+ struct machine *machine)
+{
+ struct thread *thread;
+ struct perf_script *script = container_of(tool, struct perf_script,
tool);
+ struct perf_session *session = script->session;
+ struct perf_evsel *evsel = perf_evlist__id2evsel(session->evlist,
sample->id);
+
+ if (perf_event__process_switch(tool, event, sample, machine) < 0)
+ return -1;
+
+ thread = machine__findnew_thread(machine, sample->pid,
+sample->tid);
+ if (thread == NULL) {
+ pr_debug("problem processing SWITCH event, skipping it.\n");
+ return -1;
+ }
+
+ print_sample_start(sample, thread, evsel);
+ perf_event__fprintf(event, stdout);
+ thread__put(thread);
+ return 0;
+}
+
static void sig_handler(int sig __maybe_unused)
{
session_done = 1;
@@ -834,6 +861,8 @@ static int __cmd_script(struct perf_script *script)
script->tool.mmap = process_mmap_event;
script->tool.mmap2 = process_mmap2_event;
}
+ if (script->show_switch_events)
+ script->tool.context_switch = process_switch_event;
ret = perf_session__process_events(script->session);
@@ -1618,6 +1647,8 @@ int cmd_script(int argc, const char **argv, const char
*prefix __maybe_unused)
"Show the fork/comm/exit events"),
OPT_BOOLEAN('\0', "show-mmap-events", _mmap_events,
"Show the mmap events"),
+ OPT_BOOLEAN('\0', "show-switch-events", _switch_events,
+ "Show context switch events (if recorded)"),
OPT_BOOLEAN('f', "force", , "don't complain, do it"),
OPT_CALLBACK_OPTARG(0, "itrace", _synth_opts, NULL, "opts",
"Instruction Tracing options",
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/18] perf evlist: Use bool instead of target argument in propagate_maps()
From: Jiri Olsa
We need only bool info wether user defined her own set of cpus.
Switching target argument to bool so it could be used from places
without target object defined in following patches.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1437481927-29538-9-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evlist.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 6bfcab9b7108..80ab942afa8a 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1102,7 +1102,7 @@ int perf_evlist__mmap(struct perf_evlist *evlist,
unsigned int pages,
}
static int perf_evlist__propagate_maps(struct perf_evlist *evlist,
- struct target *target)
+ bool has_user_cpus)
{
struct perf_evsel *evsel;
@@ -,10 +,10 @@ static int perf_evlist__propagate_maps(struct
perf_evlist *evlist,
* We already have cpus for evsel (via PMU sysfs) so
* keep it, if there's no target cpu list defined.
*/
- if (evsel->cpus && target->cpu_list)
+ if (evsel->cpus && has_user_cpus)
cpu_map__put(evsel->cpus);
- if (!evsel->cpus || target->cpu_list)
+ if (!evsel->cpus || has_user_cpus)
evsel->cpus = cpu_map__get(evlist->cpus);
evsel->threads = thread_map__get(evlist->threads);
@@ -1142,7 +1142,7 @@ int perf_evlist__create_maps(struct perf_evlist *evlist,
struct target *target)
if (evlist->cpus == NULL)
goto out_delete_threads;
- return perf_evlist__propagate_maps(evlist, target);
+ return perf_evlist__propagate_maps(evlist, !!target->cpu_list);
out_delete_threads:
thread_map__put(evlist->threads);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
