[PATCH 4/4] Staging: rts5208: sd: Fixed multiple coding style issues Fixed multiple braces issues
---
drivers/staging/rts5208/sd.c | 704 +--
1 file changed, 268 insertions(+), 436 deletions(-)
diff --git a/drivers/staging/rts5208/sd.c b/drivers/staging/rts5208/sd.c
index e7efa34195c7..930c61ccb047 100644
--- a/drivers/staging/rts5208/sd.c
+++ b/drivers/staging/rts5208/sd.c
@@ -109,9 +109,8 @@ static int sd_check_data0_status(struct rtsx_chip *chip)
u8 stat;
retval = rtsx_read_register(chip, REG_SD_STAT1, );
- if (retval) {
+ if (retval)
return retval;
- }
if (!(stat & SD_DAT0_STATUS)) {
sd_set_err_code(chip, SD_BUSY);
@@ -234,9 +233,8 @@ static int sd_send_cmd_get_rsp(struct rtsx_chip *chip, u8
cmd_idx,
if ((cmd_idx != SEND_RELATIVE_ADDR) &&
(cmd_idx != SEND_IF_COND)) {
if (cmd_idx != STOP_TRANSMISSION) {
- if (ptr[1] & 0x80) {
+ if (ptr[1] & 0x80)
return STATUS_FAIL;
- }
}
#ifdef SUPPORT_SD_LOCK
if (ptr[1] & 0x7D) {
@@ -284,9 +282,8 @@ static int sd_read_data(struct rtsx_chip *chip,
if (!buf)
buf_len = 0;
- if (buf_len > 512) {
+ if (buf_len > 512)
return STATUS_FAIL;
- }
rtsx_init_cmd(chip);
@@ -331,9 +328,8 @@ static int sd_read_data(struct rtsx_chip *chip,
if (buf && buf_len) {
retval = rtsx_read_ppbuf(chip, buf, buf_len);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
}
return STATUS_SUCCESS;
@@ -359,9 +355,8 @@ static int sd_write_data(struct rtsx_chip *chip, u8
trans_mode,
if (buf && buf_len) {
retval = rtsx_write_ppbuf(chip, buf, buf_len);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
}
rtsx_init_cmd(chip);
@@ -426,9 +421,8 @@ static int sd_check_csd(struct rtsx_chip *chip, char
check_wp)
break;
}
- if (i == 6) {
+ if (i == 6)
return STATUS_FAIL;
- }
memcpy(sd_card->raw_csd, rsp + 1, 15);
@@ -543,9 +537,8 @@ static int sd_set_sample_push_timing(struct rtsx_chip *chip)
}
retval = rtsx_write_register(chip, REG_SD_CFG1, 0x1C, val);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -606,9 +599,8 @@ static int sd_set_clock_divider(struct rtsx_chip *chip, u8
clk_div)
val = 0x20;
retval = rtsx_write_register(chip, REG_SD_CFG1, mask, val);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -619,16 +611,14 @@ static int sd_set_init_para(struct rtsx_chip *chip)
int retval;
retval = sd_set_sample_push_timing(chip);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
sd_choose_proper_clock(chip);
retval = switch_clock(chip, sd_card->sd_clock);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -651,9 +641,8 @@ int sd_select_card(struct rtsx_chip *chip, int select)
}
retval = sd_send_cmd_get_rsp(chip, cmd_idx, addr, cmd_type, NULL, 0);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -667,9 +656,8 @@ static int sd_update_lock_status(struct rtsx_chip *chip)
retval = sd_send_cmd_get_rsp(chip, SEND_STATUS, sd_card->sd_addr,
SD_RSP_TYPE_R1, rsp, 5);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
if (rsp[1] & 0x02)
sd_card->sd_lock_status |= SD_LOCKED;
@@ -679,9 +667,8 @@ static int sd_update_lock_status(struct rtsx_chip *chip)
dev_dbg(rtsx_dev(chip), "sd_card->sd_lock_status = 0x%x\n",
sd_card->sd_lock_status);
- if (rsp[1] & 0x01) {
+ if (rsp[1] & 0x01)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -698,9 +685,8 @@ static int sd_wait_state_data_ready(struct rtsx_chip *chip,
u8 state,
retval = sd_send_cmd_get_rsp(chip, SEND_STATUS,
sd_card->sd_addr, SD_RSP_TYPE_R1,
rsp, 5);
- if (retval != STATUS_SUCCESS) {
+ if (retval !=
[PATCH 4/4] Staging: rts5208: sd: Fixed multiple coding style issues Fixed multiple braces issues
---
drivers/staging/rts5208/sd.c | 704 +--
1 file changed, 268 insertions(+), 436 deletions(-)
diff --git a/drivers/staging/rts5208/sd.c b/drivers/staging/rts5208/sd.c
index e7efa34195c7..930c61ccb047 100644
--- a/drivers/staging/rts5208/sd.c
+++ b/drivers/staging/rts5208/sd.c
@@ -109,9 +109,8 @@ static int sd_check_data0_status(struct rtsx_chip *chip)
u8 stat;
retval = rtsx_read_register(chip, REG_SD_STAT1, );
- if (retval) {
+ if (retval)
return retval;
- }
if (!(stat & SD_DAT0_STATUS)) {
sd_set_err_code(chip, SD_BUSY);
@@ -234,9 +233,8 @@ static int sd_send_cmd_get_rsp(struct rtsx_chip *chip, u8
cmd_idx,
if ((cmd_idx != SEND_RELATIVE_ADDR) &&
(cmd_idx != SEND_IF_COND)) {
if (cmd_idx != STOP_TRANSMISSION) {
- if (ptr[1] & 0x80) {
+ if (ptr[1] & 0x80)
return STATUS_FAIL;
- }
}
#ifdef SUPPORT_SD_LOCK
if (ptr[1] & 0x7D) {
@@ -284,9 +282,8 @@ static int sd_read_data(struct rtsx_chip *chip,
if (!buf)
buf_len = 0;
- if (buf_len > 512) {
+ if (buf_len > 512)
return STATUS_FAIL;
- }
rtsx_init_cmd(chip);
@@ -331,9 +328,8 @@ static int sd_read_data(struct rtsx_chip *chip,
if (buf && buf_len) {
retval = rtsx_read_ppbuf(chip, buf, buf_len);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
}
return STATUS_SUCCESS;
@@ -359,9 +355,8 @@ static int sd_write_data(struct rtsx_chip *chip, u8
trans_mode,
if (buf && buf_len) {
retval = rtsx_write_ppbuf(chip, buf, buf_len);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
}
rtsx_init_cmd(chip);
@@ -426,9 +421,8 @@ static int sd_check_csd(struct rtsx_chip *chip, char
check_wp)
break;
}
- if (i == 6) {
+ if (i == 6)
return STATUS_FAIL;
- }
memcpy(sd_card->raw_csd, rsp + 1, 15);
@@ -543,9 +537,8 @@ static int sd_set_sample_push_timing(struct rtsx_chip *chip)
}
retval = rtsx_write_register(chip, REG_SD_CFG1, 0x1C, val);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -606,9 +599,8 @@ static int sd_set_clock_divider(struct rtsx_chip *chip, u8
clk_div)
val = 0x20;
retval = rtsx_write_register(chip, REG_SD_CFG1, mask, val);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -619,16 +611,14 @@ static int sd_set_init_para(struct rtsx_chip *chip)
int retval;
retval = sd_set_sample_push_timing(chip);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
sd_choose_proper_clock(chip);
retval = switch_clock(chip, sd_card->sd_clock);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -651,9 +641,8 @@ int sd_select_card(struct rtsx_chip *chip, int select)
}
retval = sd_send_cmd_get_rsp(chip, cmd_idx, addr, cmd_type, NULL, 0);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -667,9 +656,8 @@ static int sd_update_lock_status(struct rtsx_chip *chip)
retval = sd_send_cmd_get_rsp(chip, SEND_STATUS, sd_card->sd_addr,
SD_RSP_TYPE_R1, rsp, 5);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
if (rsp[1] & 0x02)
sd_card->sd_lock_status |= SD_LOCKED;
@@ -679,9 +667,8 @@ static int sd_update_lock_status(struct rtsx_chip *chip)
dev_dbg(rtsx_dev(chip), "sd_card->sd_lock_status = 0x%x\n",
sd_card->sd_lock_status);
- if (rsp[1] & 0x01) {
+ if (rsp[1] & 0x01)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -698,9 +685,8 @@ static int sd_wait_state_data_ready(struct rtsx_chip *chip,
u8 state,
retval = sd_send_cmd_get_rsp(chip, SEND_STATUS,
sd_card->sd_addr, SD_RSP_TYPE_R1,
rsp, 5);
- if (retval != STATUS_SUCCESS) {
+ if (retval !=
Re: [PATCH v5 0/9] PCI: mediatek: fixup find_port, enable_msi and add pm, module support
On Fri, 2018-09-28 at 18:04 +0800, honghui.zh...@mediatek.com wrote: > From: Honghui Zhang > > This patchset includes misc patchs: > > The patch 1 fixup the mtk_pcie_find_port logic which will cause system > could not touch the EP's configuration space that connected to PCIe slot 1. > > The patch 2 fixup the class type for MT7622. > The patch 6 fixup the enable msi logic, the operation to enable msi > should be after system clock is enabled. Call mtk_pcie_enable_msi in > mtk_pcie_startup_port_v2 since the clock was all enabled at that time. > > The patch 7 was rebased and refactor of the v4 patch[1], changes are: > -Add PM support for MT7622. > -Using mtk_pcie_enable_port to re-establish the link when resumed. > -Rebased on this patchset. > > The patch 9 add loadable kernel module support. > > [1] https://patchwork.kernel.org/patch/10479079 > > Change since v4: > - Add patch 2 to fixup class type for MT7622. > - Add patch 3 to remove the redundant dev->pm_domain check > - Add patch 4 to covert to use pci_host_probe > - Add patch 5 to re-arrange the function define, this is a prepare patch for >fixup the enable_msi logic, no functional changed have been made by this > one. > - Add patch 8 to save the GIC IRQ in mtk_pcie_port as a prepare patch for > tear >down the irq when remove the kernel module. > - Re-arrange the find_port flow suggest by Lorenzo to make the code parse > easier >for the patch 1. > - Remove the .pm_support in mtk_pcie_soc in patch 7 since if system pm was > not >supported, then those pm callbacks will never be executed for MT7622. So > the >.pm_support is not needed. > > Change since v3: > - Remove pm_runtime_XXX ops in suspend and resume callbacks in the third > patch. > - Rebase to 4.19-rc1. > > Change since v2: > - Fix the list_for_each_entry_safe parameter error. > - Add Ryder's Acked-by flag. > > Change since v1: > - A bit of code refact of the first patch suggested by Andy Shevchenko, and >commit message updated. > - Using __maybe_unused. > - Remove the redundant list_empty check of the fourth patch. > > Honghui Zhang (9): > PCI: mediatek: Using slot's devfn for compare to fix > mtk_pcie_find_port logic > PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI > PCI: mediatek: Remove the redundant dev->pm_domain check > PCI: mediatek: Convert to use pci_host_probe() > PCI: mediatek: Move the mtk_pcie_startup_port_v2 function's define > after mtk_pcie_setup_irq > PCI: mediatek: Enable msi after clock enabled > PCI: mediatek: Add system pm support for MT2712 and MT7622 > PCI: mediatek: Save the GIC IRQ in mtk_pcie_port > PCI: mediatek: Add loadable kernel module support > > drivers/pci/controller/Kconfig | 2 +- > drivers/pci/controller/pcie-mediatek.c | 326 > + > 2 files changed, 210 insertions(+), 118 deletions(-) > Acked-by: Ryder Lee for the whole series.
Re: [PATCH v5 0/9] PCI: mediatek: fixup find_port, enable_msi and add pm, module support
On Fri, 2018-09-28 at 18:04 +0800, honghui.zh...@mediatek.com wrote: > From: Honghui Zhang > > This patchset includes misc patchs: > > The patch 1 fixup the mtk_pcie_find_port logic which will cause system > could not touch the EP's configuration space that connected to PCIe slot 1. > > The patch 2 fixup the class type for MT7622. > The patch 6 fixup the enable msi logic, the operation to enable msi > should be after system clock is enabled. Call mtk_pcie_enable_msi in > mtk_pcie_startup_port_v2 since the clock was all enabled at that time. > > The patch 7 was rebased and refactor of the v4 patch[1], changes are: > -Add PM support for MT7622. > -Using mtk_pcie_enable_port to re-establish the link when resumed. > -Rebased on this patchset. > > The patch 9 add loadable kernel module support. > > [1] https://patchwork.kernel.org/patch/10479079 > > Change since v4: > - Add patch 2 to fixup class type for MT7622. > - Add patch 3 to remove the redundant dev->pm_domain check > - Add patch 4 to covert to use pci_host_probe > - Add patch 5 to re-arrange the function define, this is a prepare patch for >fixup the enable_msi logic, no functional changed have been made by this > one. > - Add patch 8 to save the GIC IRQ in mtk_pcie_port as a prepare patch for > tear >down the irq when remove the kernel module. > - Re-arrange the find_port flow suggest by Lorenzo to make the code parse > easier >for the patch 1. > - Remove the .pm_support in mtk_pcie_soc in patch 7 since if system pm was > not >supported, then those pm callbacks will never be executed for MT7622. So > the >.pm_support is not needed. > > Change since v3: > - Remove pm_runtime_XXX ops in suspend and resume callbacks in the third > patch. > - Rebase to 4.19-rc1. > > Change since v2: > - Fix the list_for_each_entry_safe parameter error. > - Add Ryder's Acked-by flag. > > Change since v1: > - A bit of code refact of the first patch suggested by Andy Shevchenko, and >commit message updated. > - Using __maybe_unused. > - Remove the redundant list_empty check of the fourth patch. > > Honghui Zhang (9): > PCI: mediatek: Using slot's devfn for compare to fix > mtk_pcie_find_port logic > PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI > PCI: mediatek: Remove the redundant dev->pm_domain check > PCI: mediatek: Convert to use pci_host_probe() > PCI: mediatek: Move the mtk_pcie_startup_port_v2 function's define > after mtk_pcie_setup_irq > PCI: mediatek: Enable msi after clock enabled > PCI: mediatek: Add system pm support for MT2712 and MT7622 > PCI: mediatek: Save the GIC IRQ in mtk_pcie_port > PCI: mediatek: Add loadable kernel module support > > drivers/pci/controller/Kconfig | 2 +- > drivers/pci/controller/pcie-mediatek.c | 326 > + > 2 files changed, 210 insertions(+), 118 deletions(-) > Acked-by: Ryder Lee for the whole series.
Re: [PATCH v5 4/9] PCI: mediatek: Convert to use pci_host_probe()
On Sat, 2018-09-29 at 08:16 +0800, Honghui Zhang wrote:
> On Fri, 2018-09-28 at 23:41 +0800, Ryder Lee wrote:
> > On Fri, 2018-09-28 at 18:04 +0800, honghui.zh...@mediatek.com wrote:
> > > From: Honghui Zhang
> > >
> > > Part of mtk_pcie_register_host is an open-coded version of
> > > pci_host_probe(). So instead of duplicating this code, use
> > > pci_host_probe() directly and remove mtk_pcie_register_host.
> > >
> > > Signed-off-by: Honghui Zhang
> > > ---
> > > drivers/pci/controller/pcie-mediatek.c | 37
> > > --
> > > 1 file changed, 8 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/pcie-mediatek.c
> > > b/drivers/pci/controller/pcie-mediatek.c
> > > index e2c4127..cbf4543 100644
> > > --- a/drivers/pci/controller/pcie-mediatek.c
> > > +++ b/drivers/pci/controller/pcie-mediatek.c
> > > @@ -1125,34 +1125,6 @@ static int mtk_pcie_request_resources(struct
> > > mtk_pcie *pcie)
> > > return 0;
> > > }
> > >
> > > -static int mtk_pcie_register_host(struct pci_host_bridge *host)
> > > -{
> > > - struct mtk_pcie *pcie = pci_host_bridge_priv(host);
> > > - struct pci_bus *child;
> > > - int err;
> >
> > To make the patch simple, could we keep these host->*. and return
> > pci_host_probe() directly?
>
> Well, I guess it's not necessary to keep the mtk_pcie_register_host just
> wrap pci_host_probe(). Put those host->* directly in probe function is
> no harm, it will reduce one function call and related parameter passing.
>
> I may update this patch to keep the mtk_pcie_register_host if you insist
> though I prefer the current way.
>
> Thanks.
Okay. I'm fine with this.
> > > - host->busnr = pcie->busn.start;
> > > - host->dev.parent = pcie->dev;
> > > - host->ops = pcie->soc->ops;
> > > - host->map_irq = of_irq_parse_and_map_pci;
> > > - host->swizzle_irq = pci_common_swizzle;
> > > - host->sysdata = pcie;
> > > -
> > > - err = pci_scan_root_bus_bridge(host);
> > > - if (err < 0)
> > > - return err;
> > > -
> > > - pci_bus_size_bridges(host->bus);
> > > - pci_bus_assign_resources(host->bus);
> > > -
> > > - list_for_each_entry(child, >bus->children, node)
> > > - pcie_bus_configure_settings(child);
> > > -
> > > - pci_bus_add_devices(host->bus);
> > > -
> > > - return 0;
> > > -}
> > > -
> > > static int mtk_pcie_probe(struct platform_device *pdev)
> > > {
> > > struct device *dev = >dev;
> > > @@ -1179,7 +1151,14 @@ static int mtk_pcie_probe(struct platform_device
> > > *pdev)
> > > if (err)
> > > goto put_resources;
> > >
> > > - err = mtk_pcie_register_host(host);
> > > + host->busnr = pcie->busn.start;
> > > + host->dev.parent = pcie->dev;
> > > + host->ops = pcie->soc->ops;
> > > + host->map_irq = of_irq_parse_and_map_pci;
> > > + host->swizzle_irq = pci_common_swizzle;
> > > + host->sysdata = pcie;
> > > +
> > > + err = pci_host_probe(host);
> > > if (err)
> > > goto put_resources;
> > >
> >
> >
>
>
Re: [PATCH v5 4/9] PCI: mediatek: Convert to use pci_host_probe()
On Sat, 2018-09-29 at 08:16 +0800, Honghui Zhang wrote:
> On Fri, 2018-09-28 at 23:41 +0800, Ryder Lee wrote:
> > On Fri, 2018-09-28 at 18:04 +0800, honghui.zh...@mediatek.com wrote:
> > > From: Honghui Zhang
> > >
> > > Part of mtk_pcie_register_host is an open-coded version of
> > > pci_host_probe(). So instead of duplicating this code, use
> > > pci_host_probe() directly and remove mtk_pcie_register_host.
> > >
> > > Signed-off-by: Honghui Zhang
> > > ---
> > > drivers/pci/controller/pcie-mediatek.c | 37
> > > --
> > > 1 file changed, 8 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/pcie-mediatek.c
> > > b/drivers/pci/controller/pcie-mediatek.c
> > > index e2c4127..cbf4543 100644
> > > --- a/drivers/pci/controller/pcie-mediatek.c
> > > +++ b/drivers/pci/controller/pcie-mediatek.c
> > > @@ -1125,34 +1125,6 @@ static int mtk_pcie_request_resources(struct
> > > mtk_pcie *pcie)
> > > return 0;
> > > }
> > >
> > > -static int mtk_pcie_register_host(struct pci_host_bridge *host)
> > > -{
> > > - struct mtk_pcie *pcie = pci_host_bridge_priv(host);
> > > - struct pci_bus *child;
> > > - int err;
> >
> > To make the patch simple, could we keep these host->*. and return
> > pci_host_probe() directly?
>
> Well, I guess it's not necessary to keep the mtk_pcie_register_host just
> wrap pci_host_probe(). Put those host->* directly in probe function is
> no harm, it will reduce one function call and related parameter passing.
>
> I may update this patch to keep the mtk_pcie_register_host if you insist
> though I prefer the current way.
>
> Thanks.
Okay. I'm fine with this.
> > > - host->busnr = pcie->busn.start;
> > > - host->dev.parent = pcie->dev;
> > > - host->ops = pcie->soc->ops;
> > > - host->map_irq = of_irq_parse_and_map_pci;
> > > - host->swizzle_irq = pci_common_swizzle;
> > > - host->sysdata = pcie;
> > > -
> > > - err = pci_scan_root_bus_bridge(host);
> > > - if (err < 0)
> > > - return err;
> > > -
> > > - pci_bus_size_bridges(host->bus);
> > > - pci_bus_assign_resources(host->bus);
> > > -
> > > - list_for_each_entry(child, >bus->children, node)
> > > - pcie_bus_configure_settings(child);
> > > -
> > > - pci_bus_add_devices(host->bus);
> > > -
> > > - return 0;
> > > -}
> > > -
> > > static int mtk_pcie_probe(struct platform_device *pdev)
> > > {
> > > struct device *dev = >dev;
> > > @@ -1179,7 +1151,14 @@ static int mtk_pcie_probe(struct platform_device
> > > *pdev)
> > > if (err)
> > > goto put_resources;
> > >
> > > - err = mtk_pcie_register_host(host);
> > > + host->busnr = pcie->busn.start;
> > > + host->dev.parent = pcie->dev;
> > > + host->ops = pcie->soc->ops;
> > > + host->map_irq = of_irq_parse_and_map_pci;
> > > + host->swizzle_irq = pci_common_swizzle;
> > > + host->sysdata = pcie;
> > > +
> > > + err = pci_host_probe(host);
> > > if (err)
> > > goto put_resources;
> > >
> >
> >
>
>
[PATCH 6/7] dmaengine: sprd: Support DMA 2-stage transfer mode
From: Eric Long
The Spreadtrum DMA controller supports channel 2-stage tansfer mode,
that means we can request 2 dma channels, one for source channel, and
another one for destination channel. Once the source channel's transaction
is done, it will trigger the destination channel's transaction automatically
by hardware signal.
Signed-off-by: Eric Long
Signed-off-by: Baolin Wang
---
drivers/dma/sprd-dma.c | 98 +-
include/linux/dma/sprd-dma.h | 62 --
2 files changed, 156 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index cefe42f..50d6569 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -36,6 +36,8 @@
#define SPRD_DMA_GLB_CHN_EN_STS0x1c
#define SPRD_DMA_GLB_DEBUG_STS 0x20
#define SPRD_DMA_GLB_ARB_SEL_STS 0x24
+#define SPRD_DMA_GLB_2STAGE_GRP1 0x28
+#define SPRD_DMA_GLB_2STAGE_GRP2 0x2c
#define SPRD_DMA_GLB_REQ_UID(uid) (0x4 * ((uid) - 1))
#define SPRD_DMA_GLB_REQ_UID_OFFSET0x2000
@@ -57,6 +59,18 @@
#define SPRD_DMA_CHN_SRC_BLK_STEP 0x38
#define SPRD_DMA_CHN_DES_BLK_STEP 0x3c
+/* SPRD_DMA_GLB_2STAGE_GRP register definition */
+#define SPRD_DMA_GLB_2STAGE_EN BIT(24)
+#define SPRD_DMA_GLB_CHN_INT_MASK GENMASK(23, 20)
+#define SPRD_DMA_GLB_LIST_DONE_TRG BIT(19)
+#define SPRD_DMA_GLB_TRANS_DONE_TRGBIT(18)
+#define SPRD_DMA_GLB_BLOCK_DONE_TRGBIT(17)
+#define SPRD_DMA_GLB_FRAG_DONE_TRG BIT(16)
+#define SPRD_DMA_GLB_TRG_OFFSET16
+#define SPRD_DMA_GLB_DEST_CHN_MASK GENMASK(13, 8)
+#define SPRD_DMA_GLB_DEST_CHN_OFFSET 8
+#define SPRD_DMA_GLB_SRC_CHN_MASK GENMASK(5, 0)
+
/* SPRD_DMA_CHN_INTC register definition */
#define SPRD_DMA_INT_MASK GENMASK(4, 0)
#define SPRD_DMA_INT_CLR_OFFSET24
@@ -118,6 +132,10 @@
#define SPRD_DMA_SRC_TRSF_STEP_OFFSET 0
#define SPRD_DMA_TRSF_STEP_MASKGENMASK(15, 0)
+/* define DMA channel mode & trigger mode mask */
+#define SPRD_DMA_CHN_MODE_MASK GENMASK(7, 0)
+#define SPRD_DMA_TRG_MODE_MASK GENMASK(7, 0)
+
/* define the DMA transfer step type */
#define SPRD_DMA_NONE_STEP 0
#define SPRD_DMA_BYTE_STEP 1
@@ -170,6 +188,8 @@ struct sprd_dma_chn {
struct dma_slave_config slave_cfg;
u32 chn_num;
u32 dev_id;
+ enum sprd_dma_chn_mode chn_mode;
+ enum sprd_dma_trg_mode trg_mode;
struct sprd_dma_desc*cur_desc;
};
@@ -206,6 +226,16 @@ static inline struct sprd_dma_desc
*to_sprd_dma_desc(struct virt_dma_desc *vd)
return container_of(vd, struct sprd_dma_desc, vd);
}
+static void sprd_dma_glb_update(struct sprd_dma_dev *sdev, u32 reg,
+ u32 mask, u32 val)
+{
+ u32 orig = readl(sdev->glb_base + reg);
+ u32 tmp;
+
+ tmp = (orig & ~mask) | val;
+ writel(tmp, sdev->glb_base + reg);
+}
+
static void sprd_dma_chn_update(struct sprd_dma_chn *schan, u32 reg,
u32 mask, u32 val)
{
@@ -389,6 +419,49 @@ static enum sprd_dma_req_mode sprd_dma_get_req_type(struct
sprd_dma_chn *schan)
return (frag_reg >> SPRD_DMA_REQ_MODE_OFFSET) & SPRD_DMA_REQ_MODE_MASK;
}
+static int sprd_dma_set_2stage_config(struct sprd_dma_chn *schan)
+{
+ struct sprd_dma_dev *sdev = to_sprd_dma_dev(>vc.chan);
+ u32 val, chn = schan->chn_num + 1;
+
+ switch (schan->chn_mode) {
+ case SPRD_DMA_SRC_CHN0:
+ val = chn & SPRD_DMA_GLB_SRC_CHN_MASK;
+ val |= BIT(schan->trg_mode - 1) << SPRD_DMA_GLB_TRG_OFFSET;
+ val |= SPRD_DMA_GLB_2STAGE_EN;
+ sprd_dma_glb_update(sdev, SPRD_DMA_GLB_2STAGE_GRP1, val, val);
+ break;
+
+ case SPRD_DMA_SRC_CHN1:
+ val = chn & SPRD_DMA_GLB_SRC_CHN_MASK;
+ val |= BIT(schan->trg_mode - 1) << SPRD_DMA_GLB_TRG_OFFSET;
+ val |= SPRD_DMA_GLB_2STAGE_EN;
+ sprd_dma_glb_update(sdev, SPRD_DMA_GLB_2STAGE_GRP2, val, val);
+ break;
+
+ case SPRD_DMA_DST_CHN0:
+ val = (chn << SPRD_DMA_GLB_DEST_CHN_OFFSET) &
+ SPRD_DMA_GLB_DEST_CHN_MASK;
+ val |= SPRD_DMA_GLB_2STAGE_EN;
+ sprd_dma_glb_update(sdev, SPRD_DMA_GLB_2STAGE_GRP1, val, val);
+ break;
+
+ case SPRD_DMA_DST_CHN1:
+ val = (chn << SPRD_DMA_GLB_DEST_CHN_OFFSET) &
+ SPRD_DMA_GLB_DEST_CHN_MASK;
+ val |= SPRD_DMA_GLB_2STAGE_EN;
+ sprd_dma_glb_update(sdev, SPRD_DMA_GLB_2STAGE_GRP2, val, val);
+ break;
+
+ default:
+ dev_err(sdev->dma_dev.dev, "invalid channel mode setting %d\n",
+ schan->chn_mode);
+ return -EINVAL;
+ }
+
+
[PATCH 6/7] dmaengine: sprd: Support DMA 2-stage transfer mode
From: Eric Long
The Spreadtrum DMA controller supports channel 2-stage tansfer mode,
that means we can request 2 dma channels, one for source channel, and
another one for destination channel. Once the source channel's transaction
is done, it will trigger the destination channel's transaction automatically
by hardware signal.
Signed-off-by: Eric Long
Signed-off-by: Baolin Wang
---
drivers/dma/sprd-dma.c | 98 +-
include/linux/dma/sprd-dma.h | 62 --
2 files changed, 156 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index cefe42f..50d6569 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -36,6 +36,8 @@
#define SPRD_DMA_GLB_CHN_EN_STS0x1c
#define SPRD_DMA_GLB_DEBUG_STS 0x20
#define SPRD_DMA_GLB_ARB_SEL_STS 0x24
+#define SPRD_DMA_GLB_2STAGE_GRP1 0x28
+#define SPRD_DMA_GLB_2STAGE_GRP2 0x2c
#define SPRD_DMA_GLB_REQ_UID(uid) (0x4 * ((uid) - 1))
#define SPRD_DMA_GLB_REQ_UID_OFFSET0x2000
@@ -57,6 +59,18 @@
#define SPRD_DMA_CHN_SRC_BLK_STEP 0x38
#define SPRD_DMA_CHN_DES_BLK_STEP 0x3c
+/* SPRD_DMA_GLB_2STAGE_GRP register definition */
+#define SPRD_DMA_GLB_2STAGE_EN BIT(24)
+#define SPRD_DMA_GLB_CHN_INT_MASK GENMASK(23, 20)
+#define SPRD_DMA_GLB_LIST_DONE_TRG BIT(19)
+#define SPRD_DMA_GLB_TRANS_DONE_TRGBIT(18)
+#define SPRD_DMA_GLB_BLOCK_DONE_TRGBIT(17)
+#define SPRD_DMA_GLB_FRAG_DONE_TRG BIT(16)
+#define SPRD_DMA_GLB_TRG_OFFSET16
+#define SPRD_DMA_GLB_DEST_CHN_MASK GENMASK(13, 8)
+#define SPRD_DMA_GLB_DEST_CHN_OFFSET 8
+#define SPRD_DMA_GLB_SRC_CHN_MASK GENMASK(5, 0)
+
/* SPRD_DMA_CHN_INTC register definition */
#define SPRD_DMA_INT_MASK GENMASK(4, 0)
#define SPRD_DMA_INT_CLR_OFFSET24
@@ -118,6 +132,10 @@
#define SPRD_DMA_SRC_TRSF_STEP_OFFSET 0
#define SPRD_DMA_TRSF_STEP_MASKGENMASK(15, 0)
+/* define DMA channel mode & trigger mode mask */
+#define SPRD_DMA_CHN_MODE_MASK GENMASK(7, 0)
+#define SPRD_DMA_TRG_MODE_MASK GENMASK(7, 0)
+
/* define the DMA transfer step type */
#define SPRD_DMA_NONE_STEP 0
#define SPRD_DMA_BYTE_STEP 1
@@ -170,6 +188,8 @@ struct sprd_dma_chn {
struct dma_slave_config slave_cfg;
u32 chn_num;
u32 dev_id;
+ enum sprd_dma_chn_mode chn_mode;
+ enum sprd_dma_trg_mode trg_mode;
struct sprd_dma_desc*cur_desc;
};
@@ -206,6 +226,16 @@ static inline struct sprd_dma_desc
*to_sprd_dma_desc(struct virt_dma_desc *vd)
return container_of(vd, struct sprd_dma_desc, vd);
}
+static void sprd_dma_glb_update(struct sprd_dma_dev *sdev, u32 reg,
+ u32 mask, u32 val)
+{
+ u32 orig = readl(sdev->glb_base + reg);
+ u32 tmp;
+
+ tmp = (orig & ~mask) | val;
+ writel(tmp, sdev->glb_base + reg);
+}
+
static void sprd_dma_chn_update(struct sprd_dma_chn *schan, u32 reg,
u32 mask, u32 val)
{
@@ -389,6 +419,49 @@ static enum sprd_dma_req_mode sprd_dma_get_req_type(struct
sprd_dma_chn *schan)
return (frag_reg >> SPRD_DMA_REQ_MODE_OFFSET) & SPRD_DMA_REQ_MODE_MASK;
}
+static int sprd_dma_set_2stage_config(struct sprd_dma_chn *schan)
+{
+ struct sprd_dma_dev *sdev = to_sprd_dma_dev(>vc.chan);
+ u32 val, chn = schan->chn_num + 1;
+
+ switch (schan->chn_mode) {
+ case SPRD_DMA_SRC_CHN0:
+ val = chn & SPRD_DMA_GLB_SRC_CHN_MASK;
+ val |= BIT(schan->trg_mode - 1) << SPRD_DMA_GLB_TRG_OFFSET;
+ val |= SPRD_DMA_GLB_2STAGE_EN;
+ sprd_dma_glb_update(sdev, SPRD_DMA_GLB_2STAGE_GRP1, val, val);
+ break;
+
+ case SPRD_DMA_SRC_CHN1:
+ val = chn & SPRD_DMA_GLB_SRC_CHN_MASK;
+ val |= BIT(schan->trg_mode - 1) << SPRD_DMA_GLB_TRG_OFFSET;
+ val |= SPRD_DMA_GLB_2STAGE_EN;
+ sprd_dma_glb_update(sdev, SPRD_DMA_GLB_2STAGE_GRP2, val, val);
+ break;
+
+ case SPRD_DMA_DST_CHN0:
+ val = (chn << SPRD_DMA_GLB_DEST_CHN_OFFSET) &
+ SPRD_DMA_GLB_DEST_CHN_MASK;
+ val |= SPRD_DMA_GLB_2STAGE_EN;
+ sprd_dma_glb_update(sdev, SPRD_DMA_GLB_2STAGE_GRP1, val, val);
+ break;
+
+ case SPRD_DMA_DST_CHN1:
+ val = (chn << SPRD_DMA_GLB_DEST_CHN_OFFSET) &
+ SPRD_DMA_GLB_DEST_CHN_MASK;
+ val |= SPRD_DMA_GLB_2STAGE_EN;
+ sprd_dma_glb_update(sdev, SPRD_DMA_GLB_2STAGE_GRP2, val, val);
+ break;
+
+ default:
+ dev_err(sdev->dma_dev.dev, "invalid channel mode setting %d\n",
+ schan->chn_mode);
+ return -EINVAL;
+ }
+
+
[PATCH 4/7] dmaengine: sprd: Set cur_desc as NULL when free or terminate one dma channel
From: Eric Long It will be failed to start one new transfer if the channel started one none interrupt transfer before, since we will only set the schan->cur_desc as NULL depending on the transfer interrupt now. Thus we should set schan->cur_desc as NULL when free or terminate one dma channel to avoid this issue. Signed-off-by: Eric Long Signed-off-by: Baolin Wang --- drivers/dma/sprd-dma.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c index e6a74dc..1b39661 100644 --- a/drivers/dma/sprd-dma.c +++ b/drivers/dma/sprd-dma.c @@ -439,6 +439,7 @@ static void sprd_dma_stop(struct sprd_dma_chn *schan) sprd_dma_stop_and_disable(schan); sprd_dma_unset_uid(schan); sprd_dma_clear_int(schan); + schan->cur_desc = NULL; } static bool sprd_dma_check_trans_done(struct sprd_dma_desc *sdesc, -- 1.7.9.5
[PATCH 0/7] Add some fixes and new feature for SPRD DMA
This patchset removes the direction usage from struct dma_slave_config, and add one new field to save the direction. It also fixes some issues for link-list transfer. Moreover this patchset adds new 2-stage transfer support for our DMA. Baolin Wang (1): dmaengine: sprd: Remove direction usage from struct dma_slave_config Eric Long (6): dmaengine: sprd: Get transfer residue depending on the transfer direction dmaengine: sprd: Fix the last link-list configuration dmaengine: sprd: Set cur_desc as NULL when free or terminate one dma channel dmaengine: sprd: Support DMA link-list cyclic callback dmaengine: sprd: Support DMA 2-stage transfer mode dmaengine: sprd: Add me as one of the module authors drivers/dma/sprd-dma.c | 152 +- include/linux/dma/sprd-dma.h | 62 - 2 files changed, 194 insertions(+), 20 deletions(-) -- 1.7.9.5
[PATCH 1/7] dmaengine: sprd: Remove direction usage from struct dma_slave_config
The direction field of struct dma_slave_config was marked deprecated, thus remove the usage. Signed-off-by: Baolin Wang --- drivers/dma/sprd-dma.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c index 38d4e4f..c226dc93 100644 --- a/drivers/dma/sprd-dma.c +++ b/drivers/dma/sprd-dma.c @@ -847,9 +847,6 @@ static int sprd_dma_slave_config(struct dma_chan *chan, struct sprd_dma_chn *schan = to_sprd_dma_chan(chan); struct dma_slave_config *slave_cfg = >slave_cfg; - if (!is_slave_direction(config->direction)) - return -EINVAL; - memcpy(slave_cfg, config, sizeof(*config)); return 0; } -- 1.7.9.5
[PATCH 7/7] dmaengine: sprd: Add me as one of the module authors
From: Eric Long
Add me as one of the module authors.
Signed-off-by: Eric Long
Signed-off-by: Baolin Wang
---
drivers/dma/sprd-dma.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index 50d6569..e2f0167 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -1226,4 +1226,5 @@ static int __maybe_unused sprd_dma_runtime_resume(struct
device *dev)
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("DMA driver for Spreadtrum");
MODULE_AUTHOR("Baolin Wang ");
+MODULE_AUTHOR("Eric Long ");
MODULE_ALIAS("platform:sprd-dma");
--
1.7.9.5
[PATCH 4/7] dmaengine: sprd: Set cur_desc as NULL when free or terminate one dma channel
From: Eric Long It will be failed to start one new transfer if the channel started one none interrupt transfer before, since we will only set the schan->cur_desc as NULL depending on the transfer interrupt now. Thus we should set schan->cur_desc as NULL when free or terminate one dma channel to avoid this issue. Signed-off-by: Eric Long Signed-off-by: Baolin Wang --- drivers/dma/sprd-dma.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c index e6a74dc..1b39661 100644 --- a/drivers/dma/sprd-dma.c +++ b/drivers/dma/sprd-dma.c @@ -439,6 +439,7 @@ static void sprd_dma_stop(struct sprd_dma_chn *schan) sprd_dma_stop_and_disable(schan); sprd_dma_unset_uid(schan); sprd_dma_clear_int(schan); + schan->cur_desc = NULL; } static bool sprd_dma_check_trans_done(struct sprd_dma_desc *sdesc, -- 1.7.9.5
[PATCH 0/7] Add some fixes and new feature for SPRD DMA
This patchset removes the direction usage from struct dma_slave_config, and add one new field to save the direction. It also fixes some issues for link-list transfer. Moreover this patchset adds new 2-stage transfer support for our DMA. Baolin Wang (1): dmaengine: sprd: Remove direction usage from struct dma_slave_config Eric Long (6): dmaengine: sprd: Get transfer residue depending on the transfer direction dmaengine: sprd: Fix the last link-list configuration dmaengine: sprd: Set cur_desc as NULL when free or terminate one dma channel dmaengine: sprd: Support DMA link-list cyclic callback dmaengine: sprd: Support DMA 2-stage transfer mode dmaengine: sprd: Add me as one of the module authors drivers/dma/sprd-dma.c | 152 +- include/linux/dma/sprd-dma.h | 62 - 2 files changed, 194 insertions(+), 20 deletions(-) -- 1.7.9.5
[PATCH 1/7] dmaengine: sprd: Remove direction usage from struct dma_slave_config
The direction field of struct dma_slave_config was marked deprecated, thus remove the usage. Signed-off-by: Baolin Wang --- drivers/dma/sprd-dma.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c index 38d4e4f..c226dc93 100644 --- a/drivers/dma/sprd-dma.c +++ b/drivers/dma/sprd-dma.c @@ -847,9 +847,6 @@ static int sprd_dma_slave_config(struct dma_chan *chan, struct sprd_dma_chn *schan = to_sprd_dma_chan(chan); struct dma_slave_config *slave_cfg = >slave_cfg; - if (!is_slave_direction(config->direction)) - return -EINVAL; - memcpy(slave_cfg, config, sizeof(*config)); return 0; } -- 1.7.9.5
[PATCH 7/7] dmaengine: sprd: Add me as one of the module authors
From: Eric Long
Add me as one of the module authors.
Signed-off-by: Eric Long
Signed-off-by: Baolin Wang
---
drivers/dma/sprd-dma.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index 50d6569..e2f0167 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -1226,4 +1226,5 @@ static int __maybe_unused sprd_dma_runtime_resume(struct
device *dev)
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("DMA driver for Spreadtrum");
MODULE_AUTHOR("Baolin Wang ");
+MODULE_AUTHOR("Eric Long ");
MODULE_ALIAS("platform:sprd-dma");
--
1.7.9.5
[PATCH 5/7] dmaengine: sprd: Support DMA link-list cyclic callback
From: Eric Long
The Spreadtrum DMA link-list mode is always one cyclic transfer,
so we should clear the SPRD_DMA_LLIST_END flag for the link-list
configuration. Moreover add cyclic callback support for the cyclic
transfer.
Signed-off-by: Eric Long
Signed-off-by: Baolin Wang
---
drivers/dma/sprd-dma.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index 1b39661..cefe42f 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -463,7 +463,7 @@ static irqreturn_t dma_irq_handle(int irq, void *dev_id)
struct sprd_dma_desc *sdesc;
enum sprd_dma_req_mode req_type;
enum sprd_dma_int_type int_type;
- bool trans_done = false;
+ bool trans_done = false, cyclic = false;
u32 i;
while (irq_status) {
@@ -478,13 +478,19 @@ static irqreturn_t dma_irq_handle(int irq, void *dev_id)
sdesc = schan->cur_desc;
- /* Check if the dma request descriptor is done. */
- trans_done = sprd_dma_check_trans_done(sdesc, int_type,
- req_type);
- if (trans_done == true) {
- vchan_cookie_complete(>vd);
- schan->cur_desc = NULL;
- sprd_dma_start(schan);
+ /* cyclic mode schedule callback */
+ cyclic = schan->linklist.phy_addr ? true : false;
+ if (cyclic == true) {
+ vchan_cyclic_callback(>vd);
+ } else {
+ /* Check if the dma request descriptor is done. */
+ trans_done = sprd_dma_check_trans_done(sdesc, int_type,
+ req_type);
+ if (trans_done == true) {
+ vchan_cookie_complete(>vd);
+ schan->cur_desc = NULL;
+ sprd_dma_start(schan);
+ }
}
spin_unlock(>vc.lock);
}
@@ -692,9 +698,6 @@ static int sprd_dma_fill_desc(struct dma_chan *chan,
/* link-list configuration */
if (schan->linklist.phy_addr) {
- if (sg_index == sglen - 1)
- hw->frg_len |= SPRD_DMA_LLIST_END;
-
hw->cfg |= SPRD_DMA_LINKLIST_EN;
/* link-list index */
--
1.7.9.5
[PATCH 5/7] dmaengine: sprd: Support DMA link-list cyclic callback
From: Eric Long
The Spreadtrum DMA link-list mode is always one cyclic transfer,
so we should clear the SPRD_DMA_LLIST_END flag for the link-list
configuration. Moreover add cyclic callback support for the cyclic
transfer.
Signed-off-by: Eric Long
Signed-off-by: Baolin Wang
---
drivers/dma/sprd-dma.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index 1b39661..cefe42f 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -463,7 +463,7 @@ static irqreturn_t dma_irq_handle(int irq, void *dev_id)
struct sprd_dma_desc *sdesc;
enum sprd_dma_req_mode req_type;
enum sprd_dma_int_type int_type;
- bool trans_done = false;
+ bool trans_done = false, cyclic = false;
u32 i;
while (irq_status) {
@@ -478,13 +478,19 @@ static irqreturn_t dma_irq_handle(int irq, void *dev_id)
sdesc = schan->cur_desc;
- /* Check if the dma request descriptor is done. */
- trans_done = sprd_dma_check_trans_done(sdesc, int_type,
- req_type);
- if (trans_done == true) {
- vchan_cookie_complete(>vd);
- schan->cur_desc = NULL;
- sprd_dma_start(schan);
+ /* cyclic mode schedule callback */
+ cyclic = schan->linklist.phy_addr ? true : false;
+ if (cyclic == true) {
+ vchan_cyclic_callback(>vd);
+ } else {
+ /* Check if the dma request descriptor is done. */
+ trans_done = sprd_dma_check_trans_done(sdesc, int_type,
+ req_type);
+ if (trans_done == true) {
+ vchan_cookie_complete(>vd);
+ schan->cur_desc = NULL;
+ sprd_dma_start(schan);
+ }
}
spin_unlock(>vc.lock);
}
@@ -692,9 +698,6 @@ static int sprd_dma_fill_desc(struct dma_chan *chan,
/* link-list configuration */
if (schan->linklist.phy_addr) {
- if (sg_index == sglen - 1)
- hw->frg_len |= SPRD_DMA_LLIST_END;
-
hw->cfg |= SPRD_DMA_LINKLIST_EN;
/* link-list index */
--
1.7.9.5
[PATCH 2/7] dmaengine: sprd: Get transfer residue depending on the transfer direction
From: Eric Long
Add one field to save the transfer direction for struct sprd_dma_desc,
which is used to get correct transfer residue depending on the transfer
direction.
[Baolin Wang adds one field to present the transfer direction]
Signed-off-by: Eric Long
Signed-off-by: Baolin Wang
---
drivers/dma/sprd-dma.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index c226dc93..4f3587b 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -159,6 +159,7 @@ struct sprd_dma_chn_hw {
struct sprd_dma_desc {
struct virt_dma_descvd;
struct sprd_dma_chn_hw chn_hw;
+ enum dma_transfer_direction dir;
};
/* dma channel description */
@@ -331,6 +332,17 @@ static void sprd_dma_stop_and_disable(struct sprd_dma_chn
*schan)
sprd_dma_disable_chn(schan);
}
+static unsigned long sprd_dma_get_src_addr(struct sprd_dma_chn *schan)
+{
+ unsigned long addr, addr_high;
+
+ addr = readl(schan->chn_base + SPRD_DMA_CHN_SRC_ADDR);
+ addr_high = readl(schan->chn_base + SPRD_DMA_CHN_WARP_PTR) &
+ SPRD_DMA_HIGH_ADDR_MASK;
+
+ return addr | (addr_high << SPRD_DMA_HIGH_ADDR_OFFSET);
+}
+
static unsigned long sprd_dma_get_dst_addr(struct sprd_dma_chn *schan)
{
unsigned long addr, addr_high;
@@ -534,7 +546,12 @@ static enum dma_status sprd_dma_tx_status(struct dma_chan
*chan,
else
pos = 0;
} else if (schan->cur_desc && schan->cur_desc->vd.tx.cookie == cookie) {
- pos = sprd_dma_get_dst_addr(schan);
+ struct sprd_dma_desc *sdesc = to_sprd_dma_desc(vd);
+
+ if (sdesc->dir == DMA_DEV_TO_MEM)
+ pos = sprd_dma_get_dst_addr(schan);
+ else
+ pos = sprd_dma_get_src_addr(schan);
} else {
pos = 0;
}
@@ -804,6 +821,8 @@ static int sprd_dma_fill_linklist_desc(struct dma_chan
*chan,
if (!sdesc)
return NULL;
+ sdesc->dir = dir;
+
for_each_sg(sgl, sg, sglen, i) {
len = sg_dma_len(sg);
--
1.7.9.5
[PATCH 3/7] dmaengine: sprd: Fix the last link-list configuration
From: Eric Long We will pass sglen as 0 configure the last link-list configuration when filling the descriptor, which will cause the incorrect link-list configuration. Thus we should check if the sglen is 0 to configure the correct link-list configuration. Signed-off-by: Eric Long Signed-off-by: Baolin Wang --- drivers/dma/sprd-dma.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c index 4f3587b..e6a74dc 100644 --- a/drivers/dma/sprd-dma.c +++ b/drivers/dma/sprd-dma.c @@ -697,7 +697,8 @@ static int sprd_dma_fill_desc(struct dma_chan *chan, hw->cfg |= SPRD_DMA_LINKLIST_EN; /* link-list index */ - temp = (sg_index + 1) % sglen; + temp = sglen ? (sg_index + 1) % sglen : 0; + /* Next link-list configuration's physical address offset */ temp = temp * sizeof(*hw) + SPRD_DMA_CHN_SRC_ADDR; /* -- 1.7.9.5
[PATCH 2/7] dmaengine: sprd: Get transfer residue depending on the transfer direction
From: Eric Long
Add one field to save the transfer direction for struct sprd_dma_desc,
which is used to get correct transfer residue depending on the transfer
direction.
[Baolin Wang adds one field to present the transfer direction]
Signed-off-by: Eric Long
Signed-off-by: Baolin Wang
---
drivers/dma/sprd-dma.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index c226dc93..4f3587b 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -159,6 +159,7 @@ struct sprd_dma_chn_hw {
struct sprd_dma_desc {
struct virt_dma_descvd;
struct sprd_dma_chn_hw chn_hw;
+ enum dma_transfer_direction dir;
};
/* dma channel description */
@@ -331,6 +332,17 @@ static void sprd_dma_stop_and_disable(struct sprd_dma_chn
*schan)
sprd_dma_disable_chn(schan);
}
+static unsigned long sprd_dma_get_src_addr(struct sprd_dma_chn *schan)
+{
+ unsigned long addr, addr_high;
+
+ addr = readl(schan->chn_base + SPRD_DMA_CHN_SRC_ADDR);
+ addr_high = readl(schan->chn_base + SPRD_DMA_CHN_WARP_PTR) &
+ SPRD_DMA_HIGH_ADDR_MASK;
+
+ return addr | (addr_high << SPRD_DMA_HIGH_ADDR_OFFSET);
+}
+
static unsigned long sprd_dma_get_dst_addr(struct sprd_dma_chn *schan)
{
unsigned long addr, addr_high;
@@ -534,7 +546,12 @@ static enum dma_status sprd_dma_tx_status(struct dma_chan
*chan,
else
pos = 0;
} else if (schan->cur_desc && schan->cur_desc->vd.tx.cookie == cookie) {
- pos = sprd_dma_get_dst_addr(schan);
+ struct sprd_dma_desc *sdesc = to_sprd_dma_desc(vd);
+
+ if (sdesc->dir == DMA_DEV_TO_MEM)
+ pos = sprd_dma_get_dst_addr(schan);
+ else
+ pos = sprd_dma_get_src_addr(schan);
} else {
pos = 0;
}
@@ -804,6 +821,8 @@ static int sprd_dma_fill_linklist_desc(struct dma_chan
*chan,
if (!sdesc)
return NULL;
+ sdesc->dir = dir;
+
for_each_sg(sgl, sg, sglen, i) {
len = sg_dma_len(sg);
--
1.7.9.5
[PATCH 3/7] dmaengine: sprd: Fix the last link-list configuration
From: Eric Long We will pass sglen as 0 configure the last link-list configuration when filling the descriptor, which will cause the incorrect link-list configuration. Thus we should check if the sglen is 0 to configure the correct link-list configuration. Signed-off-by: Eric Long Signed-off-by: Baolin Wang --- drivers/dma/sprd-dma.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c index 4f3587b..e6a74dc 100644 --- a/drivers/dma/sprd-dma.c +++ b/drivers/dma/sprd-dma.c @@ -697,7 +697,8 @@ static int sprd_dma_fill_desc(struct dma_chan *chan, hw->cfg |= SPRD_DMA_LINKLIST_EN; /* link-list index */ - temp = (sg_index + 1) % sglen; + temp = sglen ? (sg_index + 1) % sglen : 0; + /* Next link-list configuration's physical address offset */ temp = temp * sizeof(*hw) + SPRD_DMA_CHN_SRC_ADDR; /* -- 1.7.9.5
[PATCH] fs/dax.c: Use vmf_error() helper
These codes can be replaced with new inline vmf_error().
Signed-off-by: zhong jiang
---
fs/dax.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index b68ce48..e732f70 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1311,9 +1311,8 @@ static vm_fault_t dax_fault_return(int error)
{
if (error == 0)
return VM_FAULT_NOPAGE;
- if (error == -ENOMEM)
- return VM_FAULT_OOM;
- return VM_FAULT_SIGBUS;
+
+ return vmf_error(error);
}
/*
--
1.7.12.4
[PATCH] fs/dax.c: Use vmf_error() helper
These codes can be replaced with new inline vmf_error().
Signed-off-by: zhong jiang
---
fs/dax.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index b68ce48..e732f70 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1311,9 +1311,8 @@ static vm_fault_t dax_fault_return(int error)
{
if (error == 0)
return VM_FAULT_NOPAGE;
- if (error == -ENOMEM)
- return VM_FAULT_OOM;
- return VM_FAULT_SIGBUS;
+
+ return vmf_error(error);
}
/*
--
1.7.12.4
[BUG] sleep in atomic in 8250 runtime PM code path
Hi,
Recently I found I could trigger sleep in atomic bug on berlin after commit
d76c74387e1c ("serial: 8250_dw: Fix runtime PM handling"). The path looks like:
dw8250_probe => serial850_register_8250_port => uart_add_one_port=>
register_console => console_unlock => univ8250_console_write =>
serial8250_console_write => serial8250_rpm_get => pm_runtime_get_sync
The irq is disabled by printk_safe_enter_irqsave() in console_unlock, but
pm_runtime_get_sync can't be called in atomic context...
I guess the reason why we didn't notice it is due to the fact that
only OMAP and DW sets UART_CAP_RPM currently, and DW set the flag in
May 2018.
Per my understanding, the bug sits in the 8250 core driver rather than
8250_dw.c.
Thanks
[BUG] sleep in atomic in 8250 runtime PM code path
Hi,
Recently I found I could trigger sleep in atomic bug on berlin after commit
d76c74387e1c ("serial: 8250_dw: Fix runtime PM handling"). The path looks like:
dw8250_probe => serial850_register_8250_port => uart_add_one_port=>
register_console => console_unlock => univ8250_console_write =>
serial8250_console_write => serial8250_rpm_get => pm_runtime_get_sync
The irq is disabled by printk_safe_enter_irqsave() in console_unlock, but
pm_runtime_get_sync can't be called in atomic context...
I guess the reason why we didn't notice it is due to the fact that
only OMAP and DW sets UART_CAP_RPM currently, and DW set the flag in
May 2018.
Per my understanding, the bug sits in the 8250 core driver rather than
8250_dw.c.
Thanks
Response to SFConservancy: The copyright holder can rescind.
The software freedom conservancy has tendered its response: http://sfconservancy.org/news/2018/sep/26/GPLv2-irrevocability/ http://copyleft.org/guide/comprehensive-gpl-guidech8.html#x11-540007.4 "" "The GPLv2 have several provisions that, when taken together, can be construed as an irrevocable license from each contributor. " "" It cites: " That license granted to downstream is irrevocable, again provided that the downstream user complies with the license terms: "[P]arties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance" (GPLv2§4). " However this is disingenuous The full text of section 4 is as follows: "" 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. "" The "You" in section 4 is speaking of the licensee regarding sub-licensees, it is not speaking to the licensor/copyright-holder. IE: if the licensee loses his license, through operation of the automatic-revocation provisions, the sub-licensees do not also lose their licenses. IE: The language is disclaiming a chain topography for license distribution, and instead substituting a hub-and-spoke topography (all licenses originating from the copyright holder, not the previous-in-line) GPLv3 added a no-rescission clause for a reason: the reason being to attempt to create an estoppel defense for the licensees against the licensor. You will notice that Eben Moglen never speaks on these issues. (He preumably is aware of the weaknesses vis a vis the US copyright regime.) Section 6 further clarifies the hub-and-spoke model: "" 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. "" The memorandum posted then goes on to a discussion of estoppel, detrimental reliance, etc; noting that users may have relied on the software and their licenses may be estopped from being revoked from said users since doing so might cause them unanticipated loss. This is speaking of already published, existent, versions of the program used by end users. The memorandum seems to ignore what happens to "upstream" once said project receives a revocation notice. Thought it may be possible that users of a published piece of software may have defenses to license revocation, the same is not true regarding the rescinded property vis-a-vis future prospective versions of the software nor of future prospective licensees of said software. That is: once the grant to use the code in question is rescinded, future versions of the software may not use that code. Current users of the software may be-able to raise an estoppel / detrimental reliance defense regarding the current published software, however the programmers working on the next version of said software cannot continue to use the property in future versions of the software (such would be a copyright violation once the gratuitous license is rescinded by the grantor). Additionally, prospective-licensees, once the grant was rescinded and such was published, would have no same-such estoppel defense (not being user-licensees at the time of revocation). (Ignoring this eventuality in the published memorandum, is, of-course, by design.) (Now, to note: the free-software movement is focused on the freedom of the user, not the progenitors of the software, so one could certainly say that ignoring some developer-focused analysis is consistent with their prerogative...)
Response to SFConservancy: The copyright holder can rescind.
The software freedom conservancy has tendered its response: http://sfconservancy.org/news/2018/sep/26/GPLv2-irrevocability/ http://copyleft.org/guide/comprehensive-gpl-guidech8.html#x11-540007.4 "" "The GPLv2 have several provisions that, when taken together, can be construed as an irrevocable license from each contributor. " "" It cites: " That license granted to downstream is irrevocable, again provided that the downstream user complies with the license terms: "[P]arties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance" (GPLv2§4). " However this is disingenuous The full text of section 4 is as follows: "" 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. "" The "You" in section 4 is speaking of the licensee regarding sub-licensees, it is not speaking to the licensor/copyright-holder. IE: if the licensee loses his license, through operation of the automatic-revocation provisions, the sub-licensees do not also lose their licenses. IE: The language is disclaiming a chain topography for license distribution, and instead substituting a hub-and-spoke topography (all licenses originating from the copyright holder, not the previous-in-line) GPLv3 added a no-rescission clause for a reason: the reason being to attempt to create an estoppel defense for the licensees against the licensor. You will notice that Eben Moglen never speaks on these issues. (He preumably is aware of the weaknesses vis a vis the US copyright regime.) Section 6 further clarifies the hub-and-spoke model: "" 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. "" The memorandum posted then goes on to a discussion of estoppel, detrimental reliance, etc; noting that users may have relied on the software and their licenses may be estopped from being revoked from said users since doing so might cause them unanticipated loss. This is speaking of already published, existent, versions of the program used by end users. The memorandum seems to ignore what happens to "upstream" once said project receives a revocation notice. Thought it may be possible that users of a published piece of software may have defenses to license revocation, the same is not true regarding the rescinded property vis-a-vis future prospective versions of the software nor of future prospective licensees of said software. That is: once the grant to use the code in question is rescinded, future versions of the software may not use that code. Current users of the software may be-able to raise an estoppel / detrimental reliance defense regarding the current published software, however the programmers working on the next version of said software cannot continue to use the property in future versions of the software (such would be a copyright violation once the gratuitous license is rescinded by the grantor). Additionally, prospective-licensees, once the grant was rescinded and such was published, would have no same-such estoppel defense (not being user-licensees at the time of revocation). (Ignoring this eventuality in the published memorandum, is, of-course, by design.) (Now, to note: the free-software movement is focused on the freedom of the user, not the progenitors of the software, so one could certainly say that ignoring some developer-focused analysis is consistent with their prerogative...)
[PATCH 3/3] Staging: rts5208: rtsx_scsi: Fixed multiple coding style issues Fized multiple braces issues
---
drivers/staging/rts5208/rtsx_scsi.c | 108 ++--
1 file changed, 36 insertions(+), 72 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_scsi.c
b/drivers/staging/rts5208/rtsx_scsi.c
index c9a6d97938f6..9c594a778425 100644
--- a/drivers/staging/rts5208/rtsx_scsi.c
+++ b/drivers/staging/rts5208/rtsx_scsi.c
@@ -507,9 +507,8 @@ static int inquiry(struct scsi_cmnd *srb, struct rtsx_chip
*chip)
}
buf = vmalloc(scsi_bufflen(srb));
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
#ifdef SUPPORT_MAGIC_GATE
if ((chip->mspro_formatter_enable) &&
@@ -637,9 +636,8 @@ static int request_sense(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
}
buf = vmalloc(scsi_bufflen(srb));
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
tmp = (unsigned char *)sense;
memcpy(buf, tmp, scsi_bufflen(srb));
@@ -783,9 +781,8 @@ static int mode_sense(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
#endif
buf = kmalloc(data_size, GFP_KERNEL);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
page_code = srb->cmnd[2] & 0x3f;
@@ -999,9 +996,8 @@ static int read_format_capacity(struct scsi_cmnd *srb,
struct rtsx_chip *chip)
buf_len = (scsi_bufflen(srb) > 12) ? 0x14 : 12;
buf = kmalloc(buf_len, GFP_KERNEL);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
buf[i++] = 0;
buf[i++] = 0;
@@ -1076,9 +1072,8 @@ static int read_capacity(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
}
buf = kmalloc(8, GFP_KERNEL);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
card_size = get_card_size(chip, lun);
buf[0] = (unsigned char)((card_size - 1) >> 24);
@@ -1116,9 +,8 @@ static int read_eeprom(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
len = ((u16)srb->cmnd[4] << 8) | srb->cmnd[5];
buf = vmalloc(len);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
retval = rtsx_force_power_on(chip, SSC_PDCTL);
if (retval != STATUS_SUCCESS) {
@@ -1180,9 +1174,8 @@ static int write_eeprom(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
len = (unsigned short)min_t(unsigned int, scsi_bufflen(srb),
len);
buf = vmalloc(len);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
rtsx_stor_get_xfer_buf(buf, len, srb);
scsi_set_resid(srb, scsi_bufflen(srb) - len);
@@ -1227,9 +1220,8 @@ static int read_mem(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
}
buf = vmalloc(len);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
retval = rtsx_force_power_on(chip, SSC_PDCTL);
if (retval != STATUS_SUCCESS) {
@@ -1282,9 +1274,8 @@ static int write_mem(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
len = (unsigned short)min_t(unsigned int, scsi_bufflen(srb), len);
buf = vmalloc(len);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
rtsx_stor_get_xfer_buf(buf, len, srb);
scsi_set_resid(srb, scsi_bufflen(srb) - len);
@@ -1702,41 +1693,35 @@ static int set_chip_mode(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
if (phy_debug_mode) {
chip->phy_debug_mode = 1;
retval = rtsx_write_register(chip, CDRESUMECTL, 0x77, 0);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
- }
rtsx_disable_bus_int(chip);
retval = rtsx_read_phy_register(chip, 0x1C, );
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
- }
reg |= 0x0001;
retval = rtsx_write_phy_register(chip, 0x1C, reg);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
- }
} else {
chip->phy_debug_mode = 0;
retval = rtsx_write_register(chip, CDRESUMECTL, 0x77, 0x77);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
- }
rtsx_enable_bus_int(chip);
retval = rtsx_read_phy_register(chip, 0x1C, );
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
- }
Reminder: Licenses and revocability, in a paragraph or less. GPL 2 is revocable at the will of the grantor.
As has been stated in easily accessible terms elsewhere: "Most courts hold that simple, non-exclusive licenses with unspecified durations that are silent on revocability are revocable at will. This means that the licensor may terminate the license at any time, with or without cause." + Version 2 of the GPL specifies no duration, nor does it declare that it is non-revocable by the grantor. (Also note: A perpetual license may violate the rule against perpetuities in various jurisdictions where it is applied not only to real property but additionally to personal property (and the like), which is why the GPL-3's term of duration is set as the duration of copyright on the program (and not "forever")) +[https://www.sidley.com/en/insights/newsupdates/2013/02/the-terms-revocable-and-irrevocable-in-license-agreements-tips-and-pitfalls]
[PATCH 3/3] Staging: rts5208: rtsx_scsi: Fixed multiple coding style issues Fized multiple braces issues
---
drivers/staging/rts5208/rtsx_scsi.c | 108 ++--
1 file changed, 36 insertions(+), 72 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_scsi.c
b/drivers/staging/rts5208/rtsx_scsi.c
index c9a6d97938f6..9c594a778425 100644
--- a/drivers/staging/rts5208/rtsx_scsi.c
+++ b/drivers/staging/rts5208/rtsx_scsi.c
@@ -507,9 +507,8 @@ static int inquiry(struct scsi_cmnd *srb, struct rtsx_chip
*chip)
}
buf = vmalloc(scsi_bufflen(srb));
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
#ifdef SUPPORT_MAGIC_GATE
if ((chip->mspro_formatter_enable) &&
@@ -637,9 +636,8 @@ static int request_sense(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
}
buf = vmalloc(scsi_bufflen(srb));
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
tmp = (unsigned char *)sense;
memcpy(buf, tmp, scsi_bufflen(srb));
@@ -783,9 +781,8 @@ static int mode_sense(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
#endif
buf = kmalloc(data_size, GFP_KERNEL);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
page_code = srb->cmnd[2] & 0x3f;
@@ -999,9 +996,8 @@ static int read_format_capacity(struct scsi_cmnd *srb,
struct rtsx_chip *chip)
buf_len = (scsi_bufflen(srb) > 12) ? 0x14 : 12;
buf = kmalloc(buf_len, GFP_KERNEL);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
buf[i++] = 0;
buf[i++] = 0;
@@ -1076,9 +1072,8 @@ static int read_capacity(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
}
buf = kmalloc(8, GFP_KERNEL);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
card_size = get_card_size(chip, lun);
buf[0] = (unsigned char)((card_size - 1) >> 24);
@@ -1116,9 +,8 @@ static int read_eeprom(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
len = ((u16)srb->cmnd[4] << 8) | srb->cmnd[5];
buf = vmalloc(len);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
retval = rtsx_force_power_on(chip, SSC_PDCTL);
if (retval != STATUS_SUCCESS) {
@@ -1180,9 +1174,8 @@ static int write_eeprom(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
len = (unsigned short)min_t(unsigned int, scsi_bufflen(srb),
len);
buf = vmalloc(len);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
rtsx_stor_get_xfer_buf(buf, len, srb);
scsi_set_resid(srb, scsi_bufflen(srb) - len);
@@ -1227,9 +1220,8 @@ static int read_mem(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
}
buf = vmalloc(len);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
retval = rtsx_force_power_on(chip, SSC_PDCTL);
if (retval != STATUS_SUCCESS) {
@@ -1282,9 +1274,8 @@ static int write_mem(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
len = (unsigned short)min_t(unsigned int, scsi_bufflen(srb), len);
buf = vmalloc(len);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
rtsx_stor_get_xfer_buf(buf, len, srb);
scsi_set_resid(srb, scsi_bufflen(srb) - len);
@@ -1702,41 +1693,35 @@ static int set_chip_mode(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
if (phy_debug_mode) {
chip->phy_debug_mode = 1;
retval = rtsx_write_register(chip, CDRESUMECTL, 0x77, 0);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
- }
rtsx_disable_bus_int(chip);
retval = rtsx_read_phy_register(chip, 0x1C, );
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
- }
reg |= 0x0001;
retval = rtsx_write_phy_register(chip, 0x1C, reg);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
- }
} else {
chip->phy_debug_mode = 0;
retval = rtsx_write_register(chip, CDRESUMECTL, 0x77, 0x77);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
- }
rtsx_enable_bus_int(chip);
retval = rtsx_read_phy_register(chip, 0x1C, );
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
- }
Reminder: Licenses and revocability, in a paragraph or less. GPL 2 is revocable at the will of the grantor.
As has been stated in easily accessible terms elsewhere: "Most courts hold that simple, non-exclusive licenses with unspecified durations that are silent on revocability are revocable at will. This means that the licensor may terminate the license at any time, with or without cause." + Version 2 of the GPL specifies no duration, nor does it declare that it is non-revocable by the grantor. (Also note: A perpetual license may violate the rule against perpetuities in various jurisdictions where it is applied not only to real property but additionally to personal property (and the like), which is why the GPL-3's term of duration is set as the duration of copyright on the program (and not "forever")) +[https://www.sidley.com/en/insights/newsupdates/2013/02/the-terms-revocable-and-irrevocable-in-license-agreements-tips-and-pitfalls]
[PATCH] MAINTAINERS: fix pattern in ARM/Synaptics berlin SoC section
Berlin SoC files has been moved from marvell dir to synaptics dir, but
commit bc52497a595d ("MAINTAINERS: update entry for ARM/berlin") didn't
update the dir accordingly. This patch fixes it.
From another side, new derivative SoCs from Synaptics may not be named
as berlin*, so let's update the entries accordingly.
Fixes: bc52497a595d ("MAINTAINERS: update entry for ARM/berlin")
Signed-off-by: Jisheng Zhang
Reported-by: Joe Perches
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a255240d1452..2be912b67905 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2093,14 +2093,14 @@ F: arch/arm/boot/dts/stm32*
F: arch/arm/mach-stm32/
F: drivers/clocksource/armv7m_systick.c
-ARM/Synaptics Berlin SoC support
+ARM/Synaptics SoC support
M: Jisheng Zhang
M: Sebastian Hesselbarth
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-berlin/
F: arch/arm/boot/dts/berlin*
-F: arch/arm64/boot/dts/marvell/berlin*
+F: arch/arm64/boot/dts/synaptics/
ARM/TANGO ARCHITECTURE
M: Marc Gonzalez
--
2.19.0
[PATCH] MAINTAINERS: fix pattern in ARM/Synaptics berlin SoC section
Berlin SoC files has been moved from marvell dir to synaptics dir, but
commit bc52497a595d ("MAINTAINERS: update entry for ARM/berlin") didn't
update the dir accordingly. This patch fixes it.
From another side, new derivative SoCs from Synaptics may not be named
as berlin*, so let's update the entries accordingly.
Fixes: bc52497a595d ("MAINTAINERS: update entry for ARM/berlin")
Signed-off-by: Jisheng Zhang
Reported-by: Joe Perches
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a255240d1452..2be912b67905 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2093,14 +2093,14 @@ F: arch/arm/boot/dts/stm32*
F: arch/arm/mach-stm32/
F: drivers/clocksource/armv7m_systick.c
-ARM/Synaptics Berlin SoC support
+ARM/Synaptics SoC support
M: Jisheng Zhang
M: Sebastian Hesselbarth
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-berlin/
F: arch/arm/boot/dts/berlin*
-F: arch/arm64/boot/dts/marvell/berlin*
+F: arch/arm64/boot/dts/synaptics/
ARM/TANGO ARCHITECTURE
M: Marc Gonzalez
--
2.19.0
[PATCH 1/2] Staging: rts5208: rtsx_card: Fixed multiple coding style issues
Fixed multiple coding style issues
Signed-off-by: Maxime Desroches
---
drivers/staging/rts5208/rtsx_card.c | 96 +++--
1 file changed, 37 insertions(+), 59 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_card.c
b/drivers/staging/rts5208/rtsx_card.c
index d26a8e372fce..b45abbe29bc2 100644
--- a/drivers/staging/rts5208/rtsx_card.c
+++ b/drivers/staging/rts5208/rtsx_card.c
@@ -647,9 +647,8 @@ int switch_ssc_clock(struct rtsx_chip *chip, int clk)
dev_dbg(rtsx_dev(chip), "Switch SSC clock to %dMHz (cur_clk = %d)\n",
clk, chip->cur_clk);
- if ((clk <= 2) || (n > max_n)) {
+ if ((clk <= 2) || (n > max_n))
return STATUS_FAIL;
- }
mcu_cnt = (u8)(125 / clk + 3);
if (mcu_cnt > 7)
@@ -688,15 +687,13 @@ int switch_ssc_clock(struct rtsx_chip *chip, int clk)
}
retval = rtsx_send_cmd(chip, 0, WAIT_TIME);
- if (retval < 0) {
+ if (retval < 0)
return STATUS_ERROR;
- }
udelay(10);
retval = rtsx_write_register(chip, CLK_CTL, CLK_LOW_FREQ, 0);
- if (retval) {
+ if (retval)
return retval;
- }
chip->cur_clk = clk;
@@ -790,49 +787,44 @@ int switch_normal_clock(struct rtsx_chip *chip, int clk)
}
retval = rtsx_write_register(chip, CLK_CTL, 0xFF, CLK_LOW_FREQ);
- if (retval) {
+ if (retval)
return retval;
- }
if (sd_vpclk_phase_reset) {
retval = rtsx_write_register(chip, SD_VPCLK0_CTL,
PHASE_NOT_RESET, 0);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SD_VPCLK1_CTL,
PHASE_NOT_RESET, 0);
- if (retval) {
+ if (retval)
return retval;
- }
}
retval = rtsx_write_register(chip, CLK_DIV, 0xFF,
(div << 4) | mcu_cnt);
- if (retval) {
+ if (retval)
return retval;
- }
retval = rtsx_write_register(chip, CLK_SEL, 0xFF, sel);
- if (retval) {
+ if (retval)
return retval;
- }
if (sd_vpclk_phase_reset) {
udelay(200);
retval = rtsx_write_register(chip, SD_VPCLK0_CTL,
PHASE_NOT_RESET, PHASE_NOT_RESET);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SD_VPCLK1_CTL,
PHASE_NOT_RESET, PHASE_NOT_RESET);
- if (retval) {
+ if (retval)
return retval;
- }
+
udelay(200);
}
retval = rtsx_write_register(chip, CLK_CTL, 0xFF, 0);
- if (retval) {
+ if (retval)
return retval;
- }
chip->cur_clk = clk;
@@ -878,9 +870,8 @@ int enable_card_clock(struct rtsx_chip *chip, u8 card)
clk_en |= MS_CLK_EN;
retval = rtsx_write_register(chip, CARD_CLK_EN, clk_en, clk_en);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -898,9 +889,8 @@ int disable_card_clock(struct rtsx_chip *chip, u8 card)
clk_en |= MS_CLK_EN;
retval = rtsx_write_register(chip, CARD_CLK_EN, clk_en, 0);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -924,9 +914,8 @@ int card_power_on(struct rtsx_chip *chip, u8 card)
rtsx_add_cmd(chip, WRITE_REG_CMD, CARD_PWR_CTL, mask, val1);
retval = rtsx_send_cmd(chip, 0, 100);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
udelay(chip->pmos_pwr_on_interval);
@@ -934,9 +923,8 @@ int card_power_on(struct rtsx_chip *chip, u8 card)
rtsx_add_cmd(chip, WRITE_REG_CMD, CARD_PWR_CTL, mask, val2);
retval = rtsx_send_cmd(chip, 0, 100);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -955,9 +943,8 @@ int card_power_off(struct rtsx_chip *chip, u8 card)
}
retval = rtsx_write_register(chip, CARD_PWR_CTL, mask, val);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -969,9 +956,8 @@ int card_rw(struct scsi_cmnd *srb, struct rtsx_chip *chip,
unsigned int lun = SCSI_LUN(srb);
int i;
- if (!chip->rw_card[lun]) {
+ if (!chip->rw_card[lun])
[PATCH 1/2] Staging: rts5208: rtsx_card: Fixed multiple coding style issues
Fixed multiple coding style issues
Signed-off-by: Maxime Desroches
---
drivers/staging/rts5208/rtsx_card.c | 96 +++--
1 file changed, 37 insertions(+), 59 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_card.c
b/drivers/staging/rts5208/rtsx_card.c
index d26a8e372fce..b45abbe29bc2 100644
--- a/drivers/staging/rts5208/rtsx_card.c
+++ b/drivers/staging/rts5208/rtsx_card.c
@@ -647,9 +647,8 @@ int switch_ssc_clock(struct rtsx_chip *chip, int clk)
dev_dbg(rtsx_dev(chip), "Switch SSC clock to %dMHz (cur_clk = %d)\n",
clk, chip->cur_clk);
- if ((clk <= 2) || (n > max_n)) {
+ if ((clk <= 2) || (n > max_n))
return STATUS_FAIL;
- }
mcu_cnt = (u8)(125 / clk + 3);
if (mcu_cnt > 7)
@@ -688,15 +687,13 @@ int switch_ssc_clock(struct rtsx_chip *chip, int clk)
}
retval = rtsx_send_cmd(chip, 0, WAIT_TIME);
- if (retval < 0) {
+ if (retval < 0)
return STATUS_ERROR;
- }
udelay(10);
retval = rtsx_write_register(chip, CLK_CTL, CLK_LOW_FREQ, 0);
- if (retval) {
+ if (retval)
return retval;
- }
chip->cur_clk = clk;
@@ -790,49 +787,44 @@ int switch_normal_clock(struct rtsx_chip *chip, int clk)
}
retval = rtsx_write_register(chip, CLK_CTL, 0xFF, CLK_LOW_FREQ);
- if (retval) {
+ if (retval)
return retval;
- }
if (sd_vpclk_phase_reset) {
retval = rtsx_write_register(chip, SD_VPCLK0_CTL,
PHASE_NOT_RESET, 0);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SD_VPCLK1_CTL,
PHASE_NOT_RESET, 0);
- if (retval) {
+ if (retval)
return retval;
- }
}
retval = rtsx_write_register(chip, CLK_DIV, 0xFF,
(div << 4) | mcu_cnt);
- if (retval) {
+ if (retval)
return retval;
- }
retval = rtsx_write_register(chip, CLK_SEL, 0xFF, sel);
- if (retval) {
+ if (retval)
return retval;
- }
if (sd_vpclk_phase_reset) {
udelay(200);
retval = rtsx_write_register(chip, SD_VPCLK0_CTL,
PHASE_NOT_RESET, PHASE_NOT_RESET);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SD_VPCLK1_CTL,
PHASE_NOT_RESET, PHASE_NOT_RESET);
- if (retval) {
+ if (retval)
return retval;
- }
+
udelay(200);
}
retval = rtsx_write_register(chip, CLK_CTL, 0xFF, 0);
- if (retval) {
+ if (retval)
return retval;
- }
chip->cur_clk = clk;
@@ -878,9 +870,8 @@ int enable_card_clock(struct rtsx_chip *chip, u8 card)
clk_en |= MS_CLK_EN;
retval = rtsx_write_register(chip, CARD_CLK_EN, clk_en, clk_en);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -898,9 +889,8 @@ int disable_card_clock(struct rtsx_chip *chip, u8 card)
clk_en |= MS_CLK_EN;
retval = rtsx_write_register(chip, CARD_CLK_EN, clk_en, 0);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -924,9 +914,8 @@ int card_power_on(struct rtsx_chip *chip, u8 card)
rtsx_add_cmd(chip, WRITE_REG_CMD, CARD_PWR_CTL, mask, val1);
retval = rtsx_send_cmd(chip, 0, 100);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
udelay(chip->pmos_pwr_on_interval);
@@ -934,9 +923,8 @@ int card_power_on(struct rtsx_chip *chip, u8 card)
rtsx_add_cmd(chip, WRITE_REG_CMD, CARD_PWR_CTL, mask, val2);
retval = rtsx_send_cmd(chip, 0, 100);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -955,9 +943,8 @@ int card_power_off(struct rtsx_chip *chip, u8 card)
}
retval = rtsx_write_register(chip, CARD_PWR_CTL, mask, val);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -969,9 +956,8 @@ int card_rw(struct scsi_cmnd *srb, struct rtsx_chip *chip,
unsigned int lun = SCSI_LUN(srb);
int i;
- if (!chip->rw_card[lun]) {
+ if (!chip->rw_card[lun])
[PATCH 2/2] Staging: rts5208: rtsx_chip: Fixed multiple coding style issues
Fixed multiple braces issues
Signed-off-by: Maxime Desroches
---
drivers/staging/rts5208/rtsx_chip.c | 463
1 file changed, 199 insertions(+), 264 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_chip.c
b/drivers/staging/rts5208/rtsx_chip.c
index 6b1234bff09c..6bec2ddc75f2 100644
--- a/drivers/staging/rts5208/rtsx_chip.c
+++ b/drivers/staging/rts5208/rtsx_chip.c
@@ -116,34 +116,31 @@ static int rtsx_pre_handle_sdio_old(struct rtsx_chip
*chip)
0xFF,
MS_INS_PU | SD_WP_PU |
SD_CD_PU | SD_CMD_PU);
- if (retval) {
+ if (retval)
return retval;
- }
+
} else {
retval = rtsx_write_register(chip, FPGA_PULL_CTL,
0xFF,
FPGA_SD_PULL_CTL_EN);
- if (retval) {
+ if (retval)
return retval;
- }
+
}
retval = rtsx_write_register(chip, CARD_SHARE_MODE, 0xFF,
CARD_SHARE_48_SD);
- if (retval) {
+ if (retval)
return retval;
- }
/* Enable SDIO internal clock */
retval = rtsx_write_register(chip, 0xFF2C, 0x01, 0x01);
- if (retval) {
+ if (retval)
return retval;
- }
retval = rtsx_write_register(chip, SDIO_CTRL, 0xFF,
SDIO_BUS_CTRL | SDIO_CD_CTRL);
- if (retval) {
+ if (retval)
return retval;
- }
chip->sd_int = 1;
chip->sd_io = 1;
@@ -164,16 +161,16 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip
*chip)
if (chip->driver_first_load) {
if (CHECK_PID(chip, 0x5288)) {
retval = rtsx_read_register(chip, 0xFE5A, );
- if (retval) {
+ if (retval)
return retval;
- }
+
if (tmp & 0x08)
sw_bypass_sd = true;
} else if (CHECK_PID(chip, 0x5208)) {
retval = rtsx_read_register(chip, 0xFE70, );
- if (retval) {
+ if (retval)
return retval;
- }
+
if (tmp & 0x80)
sw_bypass_sd = true;
}
@@ -192,9 +189,9 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip *chip)
u8 cd_toggle_mask = 0;
retval = rtsx_read_register(chip, TLPTISTAT, );
- if (retval) {
+ if (retval)
return retval;
- }
+
cd_toggle_mask = 0x08;
if (tmp & cd_toggle_mask) {
@@ -202,22 +199,20 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip
*chip)
if (CHECK_PID(chip, 0x5288)) {
retval = rtsx_write_register(chip, 0xFE5A,
0x08, 0x00);
- if (retval) {
+ if (retval)
return retval;
- }
+
} else if (CHECK_PID(chip, 0x5208)) {
retval = rtsx_write_register(chip, 0xFE70,
0x80, 0x00);
- if (retval) {
+ if (retval)
return retval;
- }
}
retval = rtsx_write_register(chip, TLPTISTAT, 0xFF,
tmp);
- if (retval) {
+ if (retval)
return retval;
- }
chip->need_reset |= SD_CARD;
} else {
@@ -225,36 +220,35 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip
*chip)
if (chip->asic_code) {
retval = sd_pull_ctl_enable(chip);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
+
[PATCH 2/2] Staging: rts5208: rtsx_chip: Fixed multiple coding style issues
Fixed multiple braces issues
Signed-off-by: Maxime Desroches
---
drivers/staging/rts5208/rtsx_chip.c | 463
1 file changed, 199 insertions(+), 264 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_chip.c
b/drivers/staging/rts5208/rtsx_chip.c
index 6b1234bff09c..6bec2ddc75f2 100644
--- a/drivers/staging/rts5208/rtsx_chip.c
+++ b/drivers/staging/rts5208/rtsx_chip.c
@@ -116,34 +116,31 @@ static int rtsx_pre_handle_sdio_old(struct rtsx_chip
*chip)
0xFF,
MS_INS_PU | SD_WP_PU |
SD_CD_PU | SD_CMD_PU);
- if (retval) {
+ if (retval)
return retval;
- }
+
} else {
retval = rtsx_write_register(chip, FPGA_PULL_CTL,
0xFF,
FPGA_SD_PULL_CTL_EN);
- if (retval) {
+ if (retval)
return retval;
- }
+
}
retval = rtsx_write_register(chip, CARD_SHARE_MODE, 0xFF,
CARD_SHARE_48_SD);
- if (retval) {
+ if (retval)
return retval;
- }
/* Enable SDIO internal clock */
retval = rtsx_write_register(chip, 0xFF2C, 0x01, 0x01);
- if (retval) {
+ if (retval)
return retval;
- }
retval = rtsx_write_register(chip, SDIO_CTRL, 0xFF,
SDIO_BUS_CTRL | SDIO_CD_CTRL);
- if (retval) {
+ if (retval)
return retval;
- }
chip->sd_int = 1;
chip->sd_io = 1;
@@ -164,16 +161,16 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip
*chip)
if (chip->driver_first_load) {
if (CHECK_PID(chip, 0x5288)) {
retval = rtsx_read_register(chip, 0xFE5A, );
- if (retval) {
+ if (retval)
return retval;
- }
+
if (tmp & 0x08)
sw_bypass_sd = true;
} else if (CHECK_PID(chip, 0x5208)) {
retval = rtsx_read_register(chip, 0xFE70, );
- if (retval) {
+ if (retval)
return retval;
- }
+
if (tmp & 0x80)
sw_bypass_sd = true;
}
@@ -192,9 +189,9 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip *chip)
u8 cd_toggle_mask = 0;
retval = rtsx_read_register(chip, TLPTISTAT, );
- if (retval) {
+ if (retval)
return retval;
- }
+
cd_toggle_mask = 0x08;
if (tmp & cd_toggle_mask) {
@@ -202,22 +199,20 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip
*chip)
if (CHECK_PID(chip, 0x5288)) {
retval = rtsx_write_register(chip, 0xFE5A,
0x08, 0x00);
- if (retval) {
+ if (retval)
return retval;
- }
+
} else if (CHECK_PID(chip, 0x5208)) {
retval = rtsx_write_register(chip, 0xFE70,
0x80, 0x00);
- if (retval) {
+ if (retval)
return retval;
- }
}
retval = rtsx_write_register(chip, TLPTISTAT, 0xFF,
tmp);
- if (retval) {
+ if (retval)
return retval;
- }
chip->need_reset |= SD_CARD;
} else {
@@ -225,36 +220,35 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip
*chip)
if (chip->asic_code) {
retval = sd_pull_ctl_enable(chip);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
+
Re: [PATCH v2 0/5] Fix some bugs on RV32 build fail and issue
Palmer Dabbelt 於 2018年9月29日 週六 上午7:52寫道： > > On Wed, 26 Sep 2018 01:31:09 PDT (-0700), zong...@gmail.com wrote: > > This patches contain the modificaion as follows: > > 1. Fix up the building fail on RV32. > > 2. Add umoddi3 and udivmoddi4 functions for RV32. > > 3. Fix ioremap problem on RV32. > > > > Changes in v2: > > - Retain the copyright notices from libgcc in umoddi3.c and udivmoddi4.c. > > > > Vincent Chen (1): > > RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap > > > > Zong Li (4): > > RISC-V: Build tishift only on 64-bit > > RISC-V: Use swiotlb on RV64 only > > lib: Add umoddi3 and udivmoddi4 of GCC library routines > > RISC-V: Select GENERIC_LIB_UMODDI3 on RV32 > > > > arch/riscv/Kconfig| 1 + > > arch/riscv/kernel/setup.c | 3 + > > arch/riscv/lib/Makefile | 3 +- > > arch/riscv/mm/ioremap.c | 2 +- > > lib/Kconfig | 3 + > > lib/Makefile | 1 + > > lib/udivmoddi4.c | 309 > > ++ > > lib/umoddi3.c | 34 + > > 8 files changed, 354 insertions(+), 2 deletions(-) > > create mode 100644 lib/udivmoddi4.c > > create mode 100644 lib/umoddi3.c > > I like what this does, but there's a license issue here that Christoph pointed > out. It'd be great to have RV32I systems booting 4.19, do you think there's a > chance you can sort this out next week so we can get it into the last RC? > That > would help with the rv32i glibc process, as we'll actually be able to boot an > upstream kernel. > > It looks like the functions we have an issue with come from libgcc2.c, which > doesn't change very much. As far as I can tell we might be able to get away > with these functions from 4.2.1, which was licensed under the GPLv2. Here's > the relevant functions on GCC's github mirror > > > https://github.com/gcc-mirror/gcc/blob/gcc-4_2_1-release/gcc/libgcc2.c#L559 > > https://github.com/gcc-mirror/gcc/blob/gcc-4_2_1-release/gcc/libgcc2.c#L844 > > These look very similar to what you send out. As far as I can tell, if you > base your code on the GPLv2 version then this should be fine to include. > > Thanks! Thanks for the help and useful information. I will modify the implementation and submit the next version.
Re: [PATCH v2 0/5] Fix some bugs on RV32 build fail and issue
Palmer Dabbelt 於 2018年9月29日 週六 上午7:52寫道： > > On Wed, 26 Sep 2018 01:31:09 PDT (-0700), zong...@gmail.com wrote: > > This patches contain the modificaion as follows: > > 1. Fix up the building fail on RV32. > > 2. Add umoddi3 and udivmoddi4 functions for RV32. > > 3. Fix ioremap problem on RV32. > > > > Changes in v2: > > - Retain the copyright notices from libgcc in umoddi3.c and udivmoddi4.c. > > > > Vincent Chen (1): > > RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap > > > > Zong Li (4): > > RISC-V: Build tishift only on 64-bit > > RISC-V: Use swiotlb on RV64 only > > lib: Add umoddi3 and udivmoddi4 of GCC library routines > > RISC-V: Select GENERIC_LIB_UMODDI3 on RV32 > > > > arch/riscv/Kconfig| 1 + > > arch/riscv/kernel/setup.c | 3 + > > arch/riscv/lib/Makefile | 3 +- > > arch/riscv/mm/ioremap.c | 2 +- > > lib/Kconfig | 3 + > > lib/Makefile | 1 + > > lib/udivmoddi4.c | 309 > > ++ > > lib/umoddi3.c | 34 + > > 8 files changed, 354 insertions(+), 2 deletions(-) > > create mode 100644 lib/udivmoddi4.c > > create mode 100644 lib/umoddi3.c > > I like what this does, but there's a license issue here that Christoph pointed > out. It'd be great to have RV32I systems booting 4.19, do you think there's a > chance you can sort this out next week so we can get it into the last RC? > That > would help with the rv32i glibc process, as we'll actually be able to boot an > upstream kernel. > > It looks like the functions we have an issue with come from libgcc2.c, which > doesn't change very much. As far as I can tell we might be able to get away > with these functions from 4.2.1, which was licensed under the GPLv2. Here's > the relevant functions on GCC's github mirror > > > https://github.com/gcc-mirror/gcc/blob/gcc-4_2_1-release/gcc/libgcc2.c#L559 > > https://github.com/gcc-mirror/gcc/blob/gcc-4_2_1-release/gcc/libgcc2.c#L844 > > These look very similar to what you send out. As far as I can tell, if you > base your code on the GPLv2 version then this should be fine to include. > > Thanks! Thanks for the help and useful information. I will modify the implementation and submit the next version.
Re: [PATCH 3/4] infiniband/mm: convert to the new put_user_page() call
On 9/28/18 8:39 AM, Jason Gunthorpe wrote:
> On Thu, Sep 27, 2018 at 10:39:47PM -0700, john.hubb...@gmail.com wrote:
>> From: John Hubbard
[...]
>>
>> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
>> index a41792dbae1f..9430d697cb9f 100644
>> +++ b/drivers/infiniband/core/umem.c
>> @@ -60,7 +60,7 @@ static void __ib_umem_release(struct ib_device *dev,
>> struct ib_umem *umem, int d
>> page = sg_page(sg);
>> if (!PageDirty(page) && umem->writable && dirty)
>> set_page_dirty_lock(page);
>> -put_page(page);
>> +put_user_page(page);
>
> Would it make sense to have a release/put_user_pages_dirtied to absorb
> the set_page_dity pattern too? I notice in this patch there is some
> variety here, I wonder what is the right way?
>
> Also, I'm told this code here is a big performance bottleneck when the
> number of pages becomes very long (think >> GB of memory), so having a
> future path to use some kind of batching/threading sound great.
>
Yes. And you asked for this the first time, too. Consistent! :) Sorry for
being slow to pick it up. It looks like there are several patterns, and
we have to support both set_page_dirty() and set_page_dirty_lock(). So
the best combination looks to be adding a few variations of
release_user_pages*(), but leaving put_user_page() alone, because it's
the "do it yourself" basic one. Scatter-gather will be stuck with that.
Here's a differential patch with that, that shows a nice little cleanup in
a couple of IB places, and as you point out, it also provides the hooks for
performance upgrades (via batching) in the future.
Does this API look about right?
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c
b/drivers/infiniband/hw/hfi1/user_pages.c
index c7516029af33..48afec362c31 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -123,11 +123,7 @@ void hfi1_release_user_pages(struct mm_struct *mm, struct
page **p,
{
size_t i;
- for (i = 0; i < npages; i++) {
- if (dirty)
- set_page_dirty_lock(p[i]);
- put_user_page(p[i]);
- }
+ release_user_pages_lock(p, npages, dirty);
if (mm) { /* during close after signal, mm can be NULL */
down_write(>mmap_sem);
diff --git a/drivers/infiniband/hw/qib/qib_user_pages.c
b/drivers/infiniband/hw/qib/qib_user_pages.c
index 3f8fd42dd7fc..c57a3a6730b6 100644
--- a/drivers/infiniband/hw/qib/qib_user_pages.c
+++ b/drivers/infiniband/hw/qib/qib_user_pages.c
@@ -40,13 +40,7 @@
static void __qib_release_user_pages(struct page **p, size_t num_pages,
int dirty)
{
- size_t i;
-
- for (i = 0; i < num_pages; i++) {
- if (dirty)
- set_page_dirty_lock(p[i]);
- put_user_page(p[i]);
- }
+ release_user_pages_lock(p, num_pages, dirty);
}
/*
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 72caf803115f..b280d0181e06 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -138,6 +138,9 @@ extern int overcommit_ratio_handler(struct ctl_table *,
int, void __user *,
extern int overcommit_kbytes_handler(struct ctl_table *, int, void __user *,
size_t *, loff_t *);
+int set_page_dirty(struct page *page);
+int set_page_dirty_lock(struct page *page);
+
#define nth_page(page,n) pfn_to_page(page_to_pfn((page)) + (n))
/* to align the pointer to the (next) page boundary */
@@ -949,12 +952,56 @@ static inline void put_user_page(struct page *page)
put_page(page);
}
-/* A drop-in replacement for release_pages(): */
+/* For get_user_pages*()-pinned pages, use these variants instead of
+ * release_pages():
+ */
+static inline void release_user_pages_dirty(struct page **pages,
+ unsigned long npages)
+{
+ while (npages) {
+ set_page_dirty(pages[npages]);
+ put_user_page(pages[npages]);
+ --npages;
+ }
+}
+
+static inline void release_user_pages_dirty_lock(struct page **pages,
+unsigned long npages)
+{
+ while (npages) {
+ set_page_dirty_lock(pages[npages]);
+ put_user_page(pages[npages]);
+ --npages;
+ }
+}
+
+static inline void release_user_pages_basic(struct page **pages,
+ unsigned long npages)
+{
+ while (npages) {
+ put_user_page(pages[npages]);
+ --npages;
+ }
+}
+
static inline void release_user_pages(struct page **pages,
- unsigned long npages)
+ unsigned long npages,
+ bool set_dirty)
{
- while (npages)
-
Re: [PATCH 3/4] infiniband/mm: convert to the new put_user_page() call
On 9/28/18 8:39 AM, Jason Gunthorpe wrote:
> On Thu, Sep 27, 2018 at 10:39:47PM -0700, john.hubb...@gmail.com wrote:
>> From: John Hubbard
[...]
>>
>> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
>> index a41792dbae1f..9430d697cb9f 100644
>> +++ b/drivers/infiniband/core/umem.c
>> @@ -60,7 +60,7 @@ static void __ib_umem_release(struct ib_device *dev,
>> struct ib_umem *umem, int d
>> page = sg_page(sg);
>> if (!PageDirty(page) && umem->writable && dirty)
>> set_page_dirty_lock(page);
>> -put_page(page);
>> +put_user_page(page);
>
> Would it make sense to have a release/put_user_pages_dirtied to absorb
> the set_page_dity pattern too? I notice in this patch there is some
> variety here, I wonder what is the right way?
>
> Also, I'm told this code here is a big performance bottleneck when the
> number of pages becomes very long (think >> GB of memory), so having a
> future path to use some kind of batching/threading sound great.
>
Yes. And you asked for this the first time, too. Consistent! :) Sorry for
being slow to pick it up. It looks like there are several patterns, and
we have to support both set_page_dirty() and set_page_dirty_lock(). So
the best combination looks to be adding a few variations of
release_user_pages*(), but leaving put_user_page() alone, because it's
the "do it yourself" basic one. Scatter-gather will be stuck with that.
Here's a differential patch with that, that shows a nice little cleanup in
a couple of IB places, and as you point out, it also provides the hooks for
performance upgrades (via batching) in the future.
Does this API look about right?
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c
b/drivers/infiniband/hw/hfi1/user_pages.c
index c7516029af33..48afec362c31 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -123,11 +123,7 @@ void hfi1_release_user_pages(struct mm_struct *mm, struct
page **p,
{
size_t i;
- for (i = 0; i < npages; i++) {
- if (dirty)
- set_page_dirty_lock(p[i]);
- put_user_page(p[i]);
- }
+ release_user_pages_lock(p, npages, dirty);
if (mm) { /* during close after signal, mm can be NULL */
down_write(>mmap_sem);
diff --git a/drivers/infiniband/hw/qib/qib_user_pages.c
b/drivers/infiniband/hw/qib/qib_user_pages.c
index 3f8fd42dd7fc..c57a3a6730b6 100644
--- a/drivers/infiniband/hw/qib/qib_user_pages.c
+++ b/drivers/infiniband/hw/qib/qib_user_pages.c
@@ -40,13 +40,7 @@
static void __qib_release_user_pages(struct page **p, size_t num_pages,
int dirty)
{
- size_t i;
-
- for (i = 0; i < num_pages; i++) {
- if (dirty)
- set_page_dirty_lock(p[i]);
- put_user_page(p[i]);
- }
+ release_user_pages_lock(p, num_pages, dirty);
}
/*
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 72caf803115f..b280d0181e06 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -138,6 +138,9 @@ extern int overcommit_ratio_handler(struct ctl_table *,
int, void __user *,
extern int overcommit_kbytes_handler(struct ctl_table *, int, void __user *,
size_t *, loff_t *);
+int set_page_dirty(struct page *page);
+int set_page_dirty_lock(struct page *page);
+
#define nth_page(page,n) pfn_to_page(page_to_pfn((page)) + (n))
/* to align the pointer to the (next) page boundary */
@@ -949,12 +952,56 @@ static inline void put_user_page(struct page *page)
put_page(page);
}
-/* A drop-in replacement for release_pages(): */
+/* For get_user_pages*()-pinned pages, use these variants instead of
+ * release_pages():
+ */
+static inline void release_user_pages_dirty(struct page **pages,
+ unsigned long npages)
+{
+ while (npages) {
+ set_page_dirty(pages[npages]);
+ put_user_page(pages[npages]);
+ --npages;
+ }
+}
+
+static inline void release_user_pages_dirty_lock(struct page **pages,
+unsigned long npages)
+{
+ while (npages) {
+ set_page_dirty_lock(pages[npages]);
+ put_user_page(pages[npages]);
+ --npages;
+ }
+}
+
+static inline void release_user_pages_basic(struct page **pages,
+ unsigned long npages)
+{
+ while (npages) {
+ put_user_page(pages[npages]);
+ --npages;
+ }
+}
+
static inline void release_user_pages(struct page **pages,
- unsigned long npages)
+ unsigned long npages,
+ bool set_dirty)
{
- while (npages)
-
RE: linux-next: manual merge of the rdma tree with Linus' tree
Hi Stephen,
> -Original Message-
> From: Stephen Rothwell
> Sent: Thursday, September 27, 2018 7:01 PM
> To: Doug Ledford ; Jason Gunthorpe
>
> Cc: Linux-Next Mailing List ; Linux Kernel
> Mailing List ; Parav Pandit
>
> Subject: linux-next: manual merge of the rdma tree with Linus' tree
>
> Hi all,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
> drivers/infiniband/core/cache.c
>
> between commit:
>
> 5c5702e259dc ("RDMA/core: Set right entry state before releasing
> reference")
>
> from Linus' tree and commit:
>
> 43c7c851b9bc ("RDMA/core: Use dev_err/dbg/etc instead of pr_* + ibdev-
> >name")
>
> from the rdma tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This is now
> fixed
> as far as linux-next is concerned, but any non trivial conflicts should be
> mentioned to your upstream maintainer when your tree is submitted for
> merging. You may also want to consider cooperating with the maintainer of
> the conflicting tree to minimise any particularly complex conflicts.
>
Sorry for the late reply. For some reason mail ended up in spam folder which I
noticed now.
I should have watched the device naming series.
My fix went to for-rc and I guess it wasn't applied to for-next which resulted
into this merge conflict.
My understanding is, maintainers usually try to avoid merge conflict between
for-next and for-rc branches before sending pull request from rdma tree.
I will try to be more careful in future to notify maintainer about it.
Your changes below looks good. Thanks.
Reviewed-by: Parav Pandit
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/infiniband/core/cache.c index
> 3208ad6ad540,ebc64418d809..
> --- a/drivers/infiniband/core/cache.c
> +++ b/drivers/infiniband/core/cache.c
> @@@ -337,39 -335,6 +335,38 @@@ static int add_roce_gid(struct ib_gid_t
> return 0;
> }
>
> +/**
> + * del_gid - Delete GID table entry
> + *
> + * @ib_dev: IB device whose GID entry to be deleted
> + * @port: Port number of the IB device
> + * @table: GID table of the IB device for a port
> + * @ix: GID entry index to delete
> + *
> + */
> +static void del_gid(struct ib_device *ib_dev, u8 port,
> +struct ib_gid_table *table, int ix)
> +{
> +struct ib_gid_table_entry *entry;
> +
> +lockdep_assert_held(>lock);
> +
> - pr_debug("%s device=%s port=%d index=%d gid %pI6\n", __func__,
> - ib_dev->name, port, ix,
> - table->data_vec[ix]->attr.gid.raw);
> ++dev_dbg(_dev->dev, "%s port=%d index=%d gid %pI6\n",
>__func__, port,
> ++ix, table->data_vec[ix]->attr.gid.raw);
> +
> +write_lock_irq(>rwlock);
> +entry = table->data_vec[ix];
> +entry->state = GID_TABLE_ENTRY_PENDING_DEL;
> +/*
> + * For non RoCE protocol, GID entry slot is ready to use.
> + */
> +if (!rdma_protocol_roce(ib_dev, port))
> +table->data_vec[ix] = NULL;
> +write_unlock_irq(>rwlock);
> +
> +put_gid_entry_locked(entry);
> +}
> +
> /**
>* add_modify_gid - Add or modify GID table entry
>*
RE: linux-next: manual merge of the rdma tree with Linus' tree
Hi Stephen,
> -Original Message-
> From: Stephen Rothwell
> Sent: Thursday, September 27, 2018 7:01 PM
> To: Doug Ledford ; Jason Gunthorpe
>
> Cc: Linux-Next Mailing List ; Linux Kernel
> Mailing List ; Parav Pandit
>
> Subject: linux-next: manual merge of the rdma tree with Linus' tree
>
> Hi all,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
> drivers/infiniband/core/cache.c
>
> between commit:
>
> 5c5702e259dc ("RDMA/core: Set right entry state before releasing
> reference")
>
> from Linus' tree and commit:
>
> 43c7c851b9bc ("RDMA/core: Use dev_err/dbg/etc instead of pr_* + ibdev-
> >name")
>
> from the rdma tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This is now
> fixed
> as far as linux-next is concerned, but any non trivial conflicts should be
> mentioned to your upstream maintainer when your tree is submitted for
> merging. You may also want to consider cooperating with the maintainer of
> the conflicting tree to minimise any particularly complex conflicts.
>
Sorry for the late reply. For some reason mail ended up in spam folder which I
noticed now.
I should have watched the device naming series.
My fix went to for-rc and I guess it wasn't applied to for-next which resulted
into this merge conflict.
My understanding is, maintainers usually try to avoid merge conflict between
for-next and for-rc branches before sending pull request from rdma tree.
I will try to be more careful in future to notify maintainer about it.
Your changes below looks good. Thanks.
Reviewed-by: Parav Pandit
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/infiniband/core/cache.c index
> 3208ad6ad540,ebc64418d809..
> --- a/drivers/infiniband/core/cache.c
> +++ b/drivers/infiniband/core/cache.c
> @@@ -337,39 -335,6 +335,38 @@@ static int add_roce_gid(struct ib_gid_t
> return 0;
> }
>
> +/**
> + * del_gid - Delete GID table entry
> + *
> + * @ib_dev: IB device whose GID entry to be deleted
> + * @port: Port number of the IB device
> + * @table: GID table of the IB device for a port
> + * @ix: GID entry index to delete
> + *
> + */
> +static void del_gid(struct ib_device *ib_dev, u8 port,
> +struct ib_gid_table *table, int ix)
> +{
> +struct ib_gid_table_entry *entry;
> +
> +lockdep_assert_held(>lock);
> +
> - pr_debug("%s device=%s port=%d index=%d gid %pI6\n", __func__,
> - ib_dev->name, port, ix,
> - table->data_vec[ix]->attr.gid.raw);
> ++dev_dbg(_dev->dev, "%s port=%d index=%d gid %pI6\n",
>__func__, port,
> ++ix, table->data_vec[ix]->attr.gid.raw);
> +
> +write_lock_irq(>rwlock);
> +entry = table->data_vec[ix];
> +entry->state = GID_TABLE_ENTRY_PENDING_DEL;
> +/*
> + * For non RoCE protocol, GID entry slot is ready to use.
> + */
> +if (!rdma_protocol_roce(ib_dev, port))
> +table->data_vec[ix] = NULL;
> +write_unlock_irq(>rwlock);
> +
> +put_gid_entry_locked(entry);
> +}
> +
> /**
>* add_modify_gid - Add or modify GID table entry
>*
Re: [PATCH] arm: support big-endian for the virt architecture
Hey Arnd, On Fri, Sep 28, 2018 at 9:19 PM Arnd Bergmann wrote: > You can probably work around it by enabling ARCH_HIGHBANK, > which is a minimal platform with no other requirements, so it > should only add a few milliseconds to the build. Nice hack, thanks for the suggestion. Committed here: https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/WireGuard.git/commit/?id=56ff2eb9480e6c691a5b8d8ff1fa01090df61e1d > Another option would be to do the testing on top of linux-next, > which should have your fix starting on Monday. Testing on > linux-next carries a higher risk of running into unrelated > regressions, but also lets you find out about conflicts with > other patches early on. I do actually test on linux-next (and tons of other kernels too), but I like to have things working for at least the latest mainline. Jason
Re: [PATCH] arm: support big-endian for the virt architecture
Hey Arnd, On Fri, Sep 28, 2018 at 9:19 PM Arnd Bergmann wrote: > You can probably work around it by enabling ARCH_HIGHBANK, > which is a minimal platform with no other requirements, so it > should only add a few milliseconds to the build. Nice hack, thanks for the suggestion. Committed here: https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/WireGuard.git/commit/?id=56ff2eb9480e6c691a5b8d8ff1fa01090df61e1d > Another option would be to do the testing on top of linux-next, > which should have your fix starting on Monday. Testing on > linux-next carries a higher risk of running into unrelated > regressions, but also lets you find out about conflicts with > other patches early on. I do actually test on linux-next (and tons of other kernels too), but I like to have things working for at least the latest mainline. Jason
Re: [PATCH 2/2] mmc: mediatek: add bus_clk control
On Sat, 2018-09-29 at 01:28 +0800, Sean Wang wrote:
> Hi,
>
> On Fri, 2018-09-28 at 19:40 +0800, Chaotian Jing wrote:
> > when gate MSDC0_HCLK, access register will hang, even the MSDC driver
> > will never accessing register after HCLK was gated, but for safety, need
> > gate the bus_clk(which used to access register) too.
> >
> > Signed-off-by: Chaotian Jing
> > ---
> > drivers/mmc/host/mtk-sd.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> > index 0484138..1c1c967 100644
> > --- a/drivers/mmc/host/mtk-sd.c
> > +++ b/drivers/mmc/host/mtk-sd.c
> > @@ -387,6 +387,7 @@ struct msdc_host {
> >
> > struct clk *src_clk;/* msdc source clock */
> > struct clk *h_clk; /* msdc h_clk */
> > + struct clk *bus_clk;/* bus clock which used to access register */
> > struct clk *src_clk_cg; /* msdc source clock control gate */
> > u32 mclk; /* mmc subsystem clock frequency */
> > u32 src_clk_freq; /* source clock frequency */
> > @@ -660,12 +661,14 @@ static void msdc_gate_clock(struct msdc_host *host)
> > {
> > clk_disable_unprepare(host->src_clk_cg);
> > clk_disable_unprepare(host->src_clk);
> > + clk_disable_unprepare(host->bus_clk);
> > clk_disable_unprepare(host->h_clk);
> > }
> >
> > static void msdc_ungate_clock(struct msdc_host *host)
> > {
> > clk_prepare_enable(host->h_clk);
> > + clk_prepare_enable(host->bus_clk);
> > clk_prepare_enable(host->src_clk);
> > clk_prepare_enable(host->src_clk_cg);
> > while (!(readl(host->base + MSDC_CFG) & MSDC_CFG_CKSTB))
> > @@ -1900,6 +1903,9 @@ static int msdc_drv_probe(struct platform_device
> > *pdev)
> > goto host_free;
> > }
> >
> > + host->bus_clk = devm_clk_get(>dev, "bus_clk");
> > + if (IS_ERR(host->bus_clk))
> > + host->bus_clk = NULL;
>
> The implementation would cause all SoCs to treat the bus_clk as the optional.
> It seems you should add a flag to see what SoC requires the bus_clk to
> successfully access the related registers.
> Yes, but is no harm to other SoCs, just like the handle of "source_cg"
> > /*source clock control gate is optional clock*/
> > host->src_clk_cg = devm_clk_get(>dev, "source_cg");
> > if (IS_ERR(host->src_clk_cg))
>
>
Re: [PATCH 2/2] mmc: mediatek: add bus_clk control
On Sat, 2018-09-29 at 01:28 +0800, Sean Wang wrote:
> Hi,
>
> On Fri, 2018-09-28 at 19:40 +0800, Chaotian Jing wrote:
> > when gate MSDC0_HCLK, access register will hang, even the MSDC driver
> > will never accessing register after HCLK was gated, but for safety, need
> > gate the bus_clk(which used to access register) too.
> >
> > Signed-off-by: Chaotian Jing
> > ---
> > drivers/mmc/host/mtk-sd.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> > index 0484138..1c1c967 100644
> > --- a/drivers/mmc/host/mtk-sd.c
> > +++ b/drivers/mmc/host/mtk-sd.c
> > @@ -387,6 +387,7 @@ struct msdc_host {
> >
> > struct clk *src_clk;/* msdc source clock */
> > struct clk *h_clk; /* msdc h_clk */
> > + struct clk *bus_clk;/* bus clock which used to access register */
> > struct clk *src_clk_cg; /* msdc source clock control gate */
> > u32 mclk; /* mmc subsystem clock frequency */
> > u32 src_clk_freq; /* source clock frequency */
> > @@ -660,12 +661,14 @@ static void msdc_gate_clock(struct msdc_host *host)
> > {
> > clk_disable_unprepare(host->src_clk_cg);
> > clk_disable_unprepare(host->src_clk);
> > + clk_disable_unprepare(host->bus_clk);
> > clk_disable_unprepare(host->h_clk);
> > }
> >
> > static void msdc_ungate_clock(struct msdc_host *host)
> > {
> > clk_prepare_enable(host->h_clk);
> > + clk_prepare_enable(host->bus_clk);
> > clk_prepare_enable(host->src_clk);
> > clk_prepare_enable(host->src_clk_cg);
> > while (!(readl(host->base + MSDC_CFG) & MSDC_CFG_CKSTB))
> > @@ -1900,6 +1903,9 @@ static int msdc_drv_probe(struct platform_device
> > *pdev)
> > goto host_free;
> > }
> >
> > + host->bus_clk = devm_clk_get(>dev, "bus_clk");
> > + if (IS_ERR(host->bus_clk))
> > + host->bus_clk = NULL;
>
> The implementation would cause all SoCs to treat the bus_clk as the optional.
> It seems you should add a flag to see what SoC requires the bus_clk to
> successfully access the related registers.
> Yes, but is no harm to other SoCs, just like the handle of "source_cg"
> > /*source clock control gate is optional clock*/
> > host->src_clk_cg = devm_clk_get(>dev, "source_cg");
> > if (IS_ERR(host->src_clk_cg))
>
>
Re: [PATCH 1/2] mmc: dt-bindings: add "bus-clk" for MT2712
On Sat, 2018-09-29 at 01:34 +0800, Sean Wang wrote: > On Fri, 2018-09-28 at 19:40 +0800, Chaotian Jing wrote: > > On MT2712 MSDC0/3, HCLK/bus-clk need gate/ungate together, > > or will hang when access MSDC register. > > > > Signed-off-by: Chaotian Jing > > --- > > Documentation/devicetree/bindings/mmc/mtk-sd.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt > > b/Documentation/devicetree/bindings/mmc/mtk-sd.txt > > index f33467a..182299b 100644 > > --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt > > +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt > > @@ -22,6 +22,7 @@ Required properties: > > "source" - source clock (required) > > "hclk" - HCLK which used for host (required) > > "source_cg" - independent source clock gate (required for MT2712) > > + "bus_clk" - bus clk used for internal register access(required for > > MT2712 MSDC0/3) > > use a full name in the description such as changing "clk" to "clock" and > > add an extra blank char prior to left parenthesis > OK, fixed at v1 version. > > - pinctrl-names: should be "default", "state_uhs" > > - pinctrl-0: should contain default/high speed pin ctrl > > - pinctrl-1: should contain uhs mode pin ctrl > >
Re: [PATCH 1/2] mmc: dt-bindings: add "bus-clk" for MT2712
On Sat, 2018-09-29 at 01:34 +0800, Sean Wang wrote: > On Fri, 2018-09-28 at 19:40 +0800, Chaotian Jing wrote: > > On MT2712 MSDC0/3, HCLK/bus-clk need gate/ungate together, > > or will hang when access MSDC register. > > > > Signed-off-by: Chaotian Jing > > --- > > Documentation/devicetree/bindings/mmc/mtk-sd.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt > > b/Documentation/devicetree/bindings/mmc/mtk-sd.txt > > index f33467a..182299b 100644 > > --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt > > +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt > > @@ -22,6 +22,7 @@ Required properties: > > "source" - source clock (required) > > "hclk" - HCLK which used for host (required) > > "source_cg" - independent source clock gate (required for MT2712) > > + "bus_clk" - bus clk used for internal register access(required for > > MT2712 MSDC0/3) > > use a full name in the description such as changing "clk" to "clock" and > > add an extra blank char prior to left parenthesis > OK, fixed at v1 version. > > - pinctrl-names: should be "default", "state_uhs" > > - pinctrl-0: should contain default/high speed pin ctrl > > - pinctrl-1: should contain uhs mode pin ctrl > >
[PATCH v1 2/2] mmc: mediatek: add bus_clk control
when gate MSDC0_HCLK, access register will hang, even the MSDC driver
will never accessing register after HCLK was gated, but for safety, need
gate the bus_clk(which used to access register) too.
Signed-off-by: Chaotian Jing
---
drivers/mmc/host/mtk-sd.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 0484138..1c1c967 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -387,6 +387,7 @@ struct msdc_host {
struct clk *src_clk;/* msdc source clock */
struct clk *h_clk; /* msdc h_clk */
+ struct clk *bus_clk;/* bus clock which used to access register */
struct clk *src_clk_cg; /* msdc source clock control gate */
u32 mclk; /* mmc subsystem clock frequency */
u32 src_clk_freq; /* source clock frequency */
@@ -660,12 +661,14 @@ static void msdc_gate_clock(struct msdc_host *host)
{
clk_disable_unprepare(host->src_clk_cg);
clk_disable_unprepare(host->src_clk);
+ clk_disable_unprepare(host->bus_clk);
clk_disable_unprepare(host->h_clk);
}
static void msdc_ungate_clock(struct msdc_host *host)
{
clk_prepare_enable(host->h_clk);
+ clk_prepare_enable(host->bus_clk);
clk_prepare_enable(host->src_clk);
clk_prepare_enable(host->src_clk_cg);
while (!(readl(host->base + MSDC_CFG) & MSDC_CFG_CKSTB))
@@ -1900,6 +1903,9 @@ static int msdc_drv_probe(struct platform_device *pdev)
goto host_free;
}
+ host->bus_clk = devm_clk_get(>dev, "bus_clk");
+ if (IS_ERR(host->bus_clk))
+ host->bus_clk = NULL;
/*source clock control gate is optional clock*/
host->src_clk_cg = devm_clk_get(>dev, "source_cg");
if (IS_ERR(host->src_clk_cg))
--
1.8.1.1.dirty
[PATCH v1 2/2] mmc: mediatek: add bus_clk control
when gate MSDC0_HCLK, access register will hang, even the MSDC driver
will never accessing register after HCLK was gated, but for safety, need
gate the bus_clk(which used to access register) too.
Signed-off-by: Chaotian Jing
---
drivers/mmc/host/mtk-sd.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 0484138..1c1c967 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -387,6 +387,7 @@ struct msdc_host {
struct clk *src_clk;/* msdc source clock */
struct clk *h_clk; /* msdc h_clk */
+ struct clk *bus_clk;/* bus clock which used to access register */
struct clk *src_clk_cg; /* msdc source clock control gate */
u32 mclk; /* mmc subsystem clock frequency */
u32 src_clk_freq; /* source clock frequency */
@@ -660,12 +661,14 @@ static void msdc_gate_clock(struct msdc_host *host)
{
clk_disable_unprepare(host->src_clk_cg);
clk_disable_unprepare(host->src_clk);
+ clk_disable_unprepare(host->bus_clk);
clk_disable_unprepare(host->h_clk);
}
static void msdc_ungate_clock(struct msdc_host *host)
{
clk_prepare_enable(host->h_clk);
+ clk_prepare_enable(host->bus_clk);
clk_prepare_enable(host->src_clk);
clk_prepare_enable(host->src_clk_cg);
while (!(readl(host->base + MSDC_CFG) & MSDC_CFG_CKSTB))
@@ -1900,6 +1903,9 @@ static int msdc_drv_probe(struct platform_device *pdev)
goto host_free;
}
+ host->bus_clk = devm_clk_get(>dev, "bus_clk");
+ if (IS_ERR(host->bus_clk))
+ host->bus_clk = NULL;
/*source clock control gate is optional clock*/
host->src_clk_cg = devm_clk_get(>dev, "source_cg");
if (IS_ERR(host->src_clk_cg))
--
1.8.1.1.dirty
[PATCH v1 1/2] mmc: dt-bindings: add "bus-clk" for MT2712
On MT2712 MSDC0/3, HCLK/bus-clk need gate/ungate together, or will hang when access MSDC register. Signed-off-by: Chaotian Jing --- Documentation/devicetree/bindings/mmc/mtk-sd.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt index f33467a..f2208f4 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt @@ -22,6 +22,7 @@ Required properties: "source" - source clock (required) "hclk" - HCLK which used for host (required) "source_cg" - independent source clock gate (required for MT2712) + "bus_clk" - bus clock used for internal register access (required for MT2712 MSDC0/3) - pinctrl-names: should be "default", "state_uhs" - pinctrl-0: should contain default/high speed pin ctrl - pinctrl-1: should contain uhs mode pin ctrl -- 1.8.1.1.dirty
[PATCH v1 1/2] mmc: dt-bindings: add "bus-clk" for MT2712
On MT2712 MSDC0/3, HCLK/bus-clk need gate/ungate together, or will hang when access MSDC register. Signed-off-by: Chaotian Jing --- Documentation/devicetree/bindings/mmc/mtk-sd.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt index f33467a..f2208f4 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt @@ -22,6 +22,7 @@ Required properties: "source" - source clock (required) "hclk" - HCLK which used for host (required) "source_cg" - independent source clock gate (required for MT2712) + "bus_clk" - bus clock used for internal register access (required for MT2712 MSDC0/3) - pinctrl-names: should be "default", "state_uhs" - pinctrl-0: should contain default/high speed pin ctrl - pinctrl-1: should contain uhs mode pin ctrl -- 1.8.1.1.dirty
Re: [PATCH 0/4] get_user_pages*() and RDMA: first steps
On 9/28/18 2:49 PM, Jerome Glisse wrote: > On Fri, Sep 28, 2018 at 12:06:12PM -0700, John Hubbard wrote: >> On 9/28/18 8:29 AM, Jerome Glisse wrote: >>> On Thu, Sep 27, 2018 at 10:39:45PM -0700, john.hubb...@gmail.com wrote: From: John Hubbard [...] >>> So the solution is to wait (possibly for days, months, years) that the >>> RDMA or GPU which did GUP and do not have mmu notifier, release the page >>> (or put_user_page()) ? >>> >>> This sounds bads. Like i said during LSF/MM there is no way to properly >>> fix hardware that can not be preempted/invalidated ... most GPU are fine. >>> Few RDMA are fine, most can not ... >>> >> >> Hi Jerome, >> >> Personally, I'm think that this particular design is the best one I've seen >> so far, but if other, better designs show up, than let's do those instead, >> sure. >> >> I guess your main concern is that this might take longer than other >> approaches. >> >> As for time frame, perhaps I made it sound worse than it really is. I have >> patches >> staged already for all of the simpler call sites, and for about half of the >> more >> complicated ones. The core solution in mm is not large, and we've gone >> through a >> few discussion threads about it back in July or so, so it shouldn't take too >> long >> to perfect it. >> >> So it may be a few months to get it all reviewed and submitted, but I don't >> see "years" by any stretch. > > Bit of miss-comprehention there :) By month, years, i am talking about > the time it will take for some user to release the pin they have on the > page. Not the time to push something upstream. > > AFAICT RDMA driver do not have any upper bound on how long they can hold > a page reference and thus your solution can leave one CPU core stuck for > as long as the pin is active. Worst case might lead to all CPU core waiting > for something that might never happen. > Actually, the latest direction on that discussion was toward periodically writing back, even while under RDMA, via bounce buffers: https://lkml.kernel.org/r/20180710082100.mkdwngdv5kkrc...@quack2.suse.cz I still think that's viable. Of course, there are other things besides writeback (see below) that might also lead to waiting. >>> If it is just about fixing the set_page_dirty() bug then just looking at >>> refcount versus mapcount should already tell you if you can remove the >>> buffer head from the page or not. Which would fix the bug without complex >>> changes (i still like the put_user_page just for symetry with GUP). >>> >> >> It's about more than that. The goal is to make it safe and correct to >> use a non-CPU device to read and write to "pinned" memory, especially when >> that memory is backed by a file system. >> >> I recall there were objections to just narrowly fixing the set_page_dirty() >> bug, because the underlying problem is large and serious. So here we are. > > Except that you can not solve that issue without proper hardware. GPU are > fine. RDMA are broken except the mellanox5 hardware which can invalidate > at anytime its page table thus allowing to write protect the page at any > time. Today, people are out there using RDMA without page-fault-capable hardware. And they are hitting problems, as we've seen. From the discussions so far, I don't think it's impossible to solve the problems, even for "lesser", non-fault-capable hardware. Especially once we decide on what is reasonable and supported. Certainly the existing situation needs *something* to change, even if it's (I don't recommend this) "go forth and tell the world to stop using RDMA with their current hardware". > > With the solution put forward here you can potentialy wait _forever_ for > the driver that holds a pin to drop it. This was the point i was trying to > get accross during LSF/MM. I agree that just blocking indefinitely is generally unacceptable for kernel code, but we can probably avoid it for many cases (bounce buffers), and if we think it is really appropriate (file system unmounting, maybe?) then maybe tolerate it in some rare cases. >You can not fix broken hardware that decided to > use GUP to do a feature they can't reliably do because their hardware is > not capable to behave. > > Because code is easier here is what i was meaning: > > https://cgit.freedesktop.org/~glisse/linux/commit/?h=gup=a5dbc0fe7e71d347067579f13579df372ec48389 > https://cgit.freedesktop.org/~glisse/linux/commit/?h=gup=01677bc039c791a16d5f82b3ef84917d62fac826 > While that may work sometimes, I don't think it is reliable enough to trust for identifying pages that have been gup-pinned. There's just too much overloading of other mechanisms going on there, and if we pile on top with this constraint of "if you have +3 refcounts, and this particular combination of page counts and mapcounts, then you're definitely a long-term pinned page", I think users will find a lot of corner cases for us that break that assumption. So I think we agree that the put_user_page() approach, to
Re: [PATCH 0/4] get_user_pages*() and RDMA: first steps
On 9/28/18 2:49 PM, Jerome Glisse wrote: > On Fri, Sep 28, 2018 at 12:06:12PM -0700, John Hubbard wrote: >> On 9/28/18 8:29 AM, Jerome Glisse wrote: >>> On Thu, Sep 27, 2018 at 10:39:45PM -0700, john.hubb...@gmail.com wrote: From: John Hubbard [...] >>> So the solution is to wait (possibly for days, months, years) that the >>> RDMA or GPU which did GUP and do not have mmu notifier, release the page >>> (or put_user_page()) ? >>> >>> This sounds bads. Like i said during LSF/MM there is no way to properly >>> fix hardware that can not be preempted/invalidated ... most GPU are fine. >>> Few RDMA are fine, most can not ... >>> >> >> Hi Jerome, >> >> Personally, I'm think that this particular design is the best one I've seen >> so far, but if other, better designs show up, than let's do those instead, >> sure. >> >> I guess your main concern is that this might take longer than other >> approaches. >> >> As for time frame, perhaps I made it sound worse than it really is. I have >> patches >> staged already for all of the simpler call sites, and for about half of the >> more >> complicated ones. The core solution in mm is not large, and we've gone >> through a >> few discussion threads about it back in July or so, so it shouldn't take too >> long >> to perfect it. >> >> So it may be a few months to get it all reviewed and submitted, but I don't >> see "years" by any stretch. > > Bit of miss-comprehention there :) By month, years, i am talking about > the time it will take for some user to release the pin they have on the > page. Not the time to push something upstream. > > AFAICT RDMA driver do not have any upper bound on how long they can hold > a page reference and thus your solution can leave one CPU core stuck for > as long as the pin is active. Worst case might lead to all CPU core waiting > for something that might never happen. > Actually, the latest direction on that discussion was toward periodically writing back, even while under RDMA, via bounce buffers: https://lkml.kernel.org/r/20180710082100.mkdwngdv5kkrc...@quack2.suse.cz I still think that's viable. Of course, there are other things besides writeback (see below) that might also lead to waiting. >>> If it is just about fixing the set_page_dirty() bug then just looking at >>> refcount versus mapcount should already tell you if you can remove the >>> buffer head from the page or not. Which would fix the bug without complex >>> changes (i still like the put_user_page just for symetry with GUP). >>> >> >> It's about more than that. The goal is to make it safe and correct to >> use a non-CPU device to read and write to "pinned" memory, especially when >> that memory is backed by a file system. >> >> I recall there were objections to just narrowly fixing the set_page_dirty() >> bug, because the underlying problem is large and serious. So here we are. > > Except that you can not solve that issue without proper hardware. GPU are > fine. RDMA are broken except the mellanox5 hardware which can invalidate > at anytime its page table thus allowing to write protect the page at any > time. Today, people are out there using RDMA without page-fault-capable hardware. And they are hitting problems, as we've seen. From the discussions so far, I don't think it's impossible to solve the problems, even for "lesser", non-fault-capable hardware. Especially once we decide on what is reasonable and supported. Certainly the existing situation needs *something* to change, even if it's (I don't recommend this) "go forth and tell the world to stop using RDMA with their current hardware". > > With the solution put forward here you can potentialy wait _forever_ for > the driver that holds a pin to drop it. This was the point i was trying to > get accross during LSF/MM. I agree that just blocking indefinitely is generally unacceptable for kernel code, but we can probably avoid it for many cases (bounce buffers), and if we think it is really appropriate (file system unmounting, maybe?) then maybe tolerate it in some rare cases. >You can not fix broken hardware that decided to > use GUP to do a feature they can't reliably do because their hardware is > not capable to behave. > > Because code is easier here is what i was meaning: > > https://cgit.freedesktop.org/~glisse/linux/commit/?h=gup=a5dbc0fe7e71d347067579f13579df372ec48389 > https://cgit.freedesktop.org/~glisse/linux/commit/?h=gup=01677bc039c791a16d5f82b3ef84917d62fac826 > While that may work sometimes, I don't think it is reliable enough to trust for identifying pages that have been gup-pinned. There's just too much overloading of other mechanisms going on there, and if we pile on top with this constraint of "if you have +3 refcounts, and this particular combination of page counts and mapcounts, then you're definitely a long-term pinned page", I think users will find a lot of corner cases for us that break that assumption. So I think we agree that the put_user_page() approach, to
Re: Bad MAINTAINERS pattern in section 'ARM/Synaptics Berlin SoC support'
On Fri, 28 Sep 2018 14:51:32 -0700 Joe Perches wrote:
> Please fix this defect appropriately.
>
> linux-next MAINTAINERS section:
>
> 2111ARM/Synaptics Berlin SoC support
> 2112M: Jisheng Zhang
> 2113M: Sebastian Hesselbarth
> 2114L: linux-arm-ker...@lists.infradead.org (moderated for
> non-subscribers)
> 2115S: Maintained
> 2116F: arch/arm/mach-berlin/
> 2117F: arch/arm/boot/dts/berlin*
> --> 2118F: arch/arm64/boot/dts/marvell/berlin*
Thanks so much. I will fix it soon.
>
> Commit that introduced this:
>
> commit bc52497a595d2246923749177d99e4216703b0f4
> Author: Jisheng Zhang
> Date: Fri Mar 30 11:02:11 2018 +0800
>
> MAINTAINERS: update entry for ARM/berlin
>
> Synaptics has acquired the Multimedia Solutions Business of Marvell[1].
> So change the berlin entry name and move it to its alphabetical
> location. We move to ARM/Synaptics instead of ARM/Marvell.
>
> This patch also updates my email address from marvell to synaptics.
>
> [1] https://www.synaptics.com/company/news/conexant-marvell
>
> Signed-off-by: Jisheng Zhang
> Reviewed-by: Andrew Lunn
> Signed-off-by: Arnd Bergmann
>
> MAINTAINERS | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> Last commit with arch/arm64/boot/dts/marvell/berlin*
>
> commit 031106ce95a201f6dd4c5ebf35abb900cf34e2ba
> Author: Jisheng Zhang
> Date: Wed May 16 17:43:28 2018 +0800
>
> arm64: dts: move berlin SoC files from marvell dir to synaptics dir
>
> Move device tree files as part of transition from Marvell berlin to
> Synaptics berlin.
>
> Signed-off-by: Jisheng Zhang
>
> arch/arm64/boot/dts/Makefile | 1 +
> arch/arm64/boot/dts/marvell/Makefile | 4
> arch/arm64/boot/dts/synaptics/Makefile | 4
> arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct-dmp.dts | 0
> arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct-stb.dts | 0
> arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct.dtsi| 0
> 6 files changed, 5 insertions(+), 4 deletions(-)
Re: Bad MAINTAINERS pattern in section 'ARM/Synaptics Berlin SoC support'
On Fri, 28 Sep 2018 14:51:32 -0700 Joe Perches wrote:
> Please fix this defect appropriately.
>
> linux-next MAINTAINERS section:
>
> 2111ARM/Synaptics Berlin SoC support
> 2112M: Jisheng Zhang
> 2113M: Sebastian Hesselbarth
> 2114L: linux-arm-ker...@lists.infradead.org (moderated for
> non-subscribers)
> 2115S: Maintained
> 2116F: arch/arm/mach-berlin/
> 2117F: arch/arm/boot/dts/berlin*
> --> 2118F: arch/arm64/boot/dts/marvell/berlin*
Thanks so much. I will fix it soon.
>
> Commit that introduced this:
>
> commit bc52497a595d2246923749177d99e4216703b0f4
> Author: Jisheng Zhang
> Date: Fri Mar 30 11:02:11 2018 +0800
>
> MAINTAINERS: update entry for ARM/berlin
>
> Synaptics has acquired the Multimedia Solutions Business of Marvell[1].
> So change the berlin entry name and move it to its alphabetical
> location. We move to ARM/Synaptics instead of ARM/Marvell.
>
> This patch also updates my email address from marvell to synaptics.
>
> [1] https://www.synaptics.com/company/news/conexant-marvell
>
> Signed-off-by: Jisheng Zhang
> Reviewed-by: Andrew Lunn
> Signed-off-by: Arnd Bergmann
>
> MAINTAINERS | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> Last commit with arch/arm64/boot/dts/marvell/berlin*
>
> commit 031106ce95a201f6dd4c5ebf35abb900cf34e2ba
> Author: Jisheng Zhang
> Date: Wed May 16 17:43:28 2018 +0800
>
> arm64: dts: move berlin SoC files from marvell dir to synaptics dir
>
> Move device tree files as part of transition from Marvell berlin to
> Synaptics berlin.
>
> Signed-off-by: Jisheng Zhang
>
> arch/arm64/boot/dts/Makefile | 1 +
> arch/arm64/boot/dts/marvell/Makefile | 4
> arch/arm64/boot/dts/synaptics/Makefile | 4
> arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct-dmp.dts | 0
> arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct-stb.dts | 0
> arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct.dtsi| 0
> 6 files changed, 5 insertions(+), 4 deletions(-)
[PATCH] Staging: rts5208: rtsx_card: Fixed multiple coding style issues
Fixed multiple coding style issues
Signed-off-by: Maxime Desroches
---
drivers/staging/rts5208/rtsx_card.c | 96 +++--
1 file changed, 37 insertions(+), 59 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_card.c
b/drivers/staging/rts5208/rtsx_card.c
index d26a8e372fce..b45abbe29bc2 100644
--- a/drivers/staging/rts5208/rtsx_card.c
+++ b/drivers/staging/rts5208/rtsx_card.c
@@ -647,9 +647,8 @@ int switch_ssc_clock(struct rtsx_chip *chip, int clk)
dev_dbg(rtsx_dev(chip), "Switch SSC clock to %dMHz (cur_clk = %d)\n",
clk, chip->cur_clk);
- if ((clk <= 2) || (n > max_n)) {
+ if ((clk <= 2) || (n > max_n))
return STATUS_FAIL;
- }
mcu_cnt = (u8)(125 / clk + 3);
if (mcu_cnt > 7)
@@ -688,15 +687,13 @@ int switch_ssc_clock(struct rtsx_chip *chip, int clk)
}
retval = rtsx_send_cmd(chip, 0, WAIT_TIME);
- if (retval < 0) {
+ if (retval < 0)
return STATUS_ERROR;
- }
udelay(10);
retval = rtsx_write_register(chip, CLK_CTL, CLK_LOW_FREQ, 0);
- if (retval) {
+ if (retval)
return retval;
- }
chip->cur_clk = clk;
@@ -790,49 +787,44 @@ int switch_normal_clock(struct rtsx_chip *chip, int clk)
}
retval = rtsx_write_register(chip, CLK_CTL, 0xFF, CLK_LOW_FREQ);
- if (retval) {
+ if (retval)
return retval;
- }
if (sd_vpclk_phase_reset) {
retval = rtsx_write_register(chip, SD_VPCLK0_CTL,
PHASE_NOT_RESET, 0);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SD_VPCLK1_CTL,
PHASE_NOT_RESET, 0);
- if (retval) {
+ if (retval)
return retval;
- }
}
retval = rtsx_write_register(chip, CLK_DIV, 0xFF,
(div << 4) | mcu_cnt);
- if (retval) {
+ if (retval)
return retval;
- }
retval = rtsx_write_register(chip, CLK_SEL, 0xFF, sel);
- if (retval) {
+ if (retval)
return retval;
- }
if (sd_vpclk_phase_reset) {
udelay(200);
retval = rtsx_write_register(chip, SD_VPCLK0_CTL,
PHASE_NOT_RESET, PHASE_NOT_RESET);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SD_VPCLK1_CTL,
PHASE_NOT_RESET, PHASE_NOT_RESET);
- if (retval) {
+ if (retval)
return retval;
- }
+
udelay(200);
}
retval = rtsx_write_register(chip, CLK_CTL, 0xFF, 0);
- if (retval) {
+ if (retval)
return retval;
- }
chip->cur_clk = clk;
@@ -878,9 +870,8 @@ int enable_card_clock(struct rtsx_chip *chip, u8 card)
clk_en |= MS_CLK_EN;
retval = rtsx_write_register(chip, CARD_CLK_EN, clk_en, clk_en);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -898,9 +889,8 @@ int disable_card_clock(struct rtsx_chip *chip, u8 card)
clk_en |= MS_CLK_EN;
retval = rtsx_write_register(chip, CARD_CLK_EN, clk_en, 0);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -924,9 +914,8 @@ int card_power_on(struct rtsx_chip *chip, u8 card)
rtsx_add_cmd(chip, WRITE_REG_CMD, CARD_PWR_CTL, mask, val1);
retval = rtsx_send_cmd(chip, 0, 100);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
udelay(chip->pmos_pwr_on_interval);
@@ -934,9 +923,8 @@ int card_power_on(struct rtsx_chip *chip, u8 card)
rtsx_add_cmd(chip, WRITE_REG_CMD, CARD_PWR_CTL, mask, val2);
retval = rtsx_send_cmd(chip, 0, 100);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -955,9 +943,8 @@ int card_power_off(struct rtsx_chip *chip, u8 card)
}
retval = rtsx_write_register(chip, CARD_PWR_CTL, mask, val);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -969,9 +956,8 @@ int card_rw(struct scsi_cmnd *srb, struct rtsx_chip *chip,
unsigned int lun = SCSI_LUN(srb);
int i;
- if (!chip->rw_card[lun]) {
+ if (!chip->rw_card[lun])
[PATCH] Staging: rts5208: rtsx_card: Fixed multiple coding style issues
Fixed multiple coding style issues
Signed-off-by: Maxime Desroches
---
drivers/staging/rts5208/rtsx_card.c | 96 +++--
1 file changed, 37 insertions(+), 59 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_card.c
b/drivers/staging/rts5208/rtsx_card.c
index d26a8e372fce..b45abbe29bc2 100644
--- a/drivers/staging/rts5208/rtsx_card.c
+++ b/drivers/staging/rts5208/rtsx_card.c
@@ -647,9 +647,8 @@ int switch_ssc_clock(struct rtsx_chip *chip, int clk)
dev_dbg(rtsx_dev(chip), "Switch SSC clock to %dMHz (cur_clk = %d)\n",
clk, chip->cur_clk);
- if ((clk <= 2) || (n > max_n)) {
+ if ((clk <= 2) || (n > max_n))
return STATUS_FAIL;
- }
mcu_cnt = (u8)(125 / clk + 3);
if (mcu_cnt > 7)
@@ -688,15 +687,13 @@ int switch_ssc_clock(struct rtsx_chip *chip, int clk)
}
retval = rtsx_send_cmd(chip, 0, WAIT_TIME);
- if (retval < 0) {
+ if (retval < 0)
return STATUS_ERROR;
- }
udelay(10);
retval = rtsx_write_register(chip, CLK_CTL, CLK_LOW_FREQ, 0);
- if (retval) {
+ if (retval)
return retval;
- }
chip->cur_clk = clk;
@@ -790,49 +787,44 @@ int switch_normal_clock(struct rtsx_chip *chip, int clk)
}
retval = rtsx_write_register(chip, CLK_CTL, 0xFF, CLK_LOW_FREQ);
- if (retval) {
+ if (retval)
return retval;
- }
if (sd_vpclk_phase_reset) {
retval = rtsx_write_register(chip, SD_VPCLK0_CTL,
PHASE_NOT_RESET, 0);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SD_VPCLK1_CTL,
PHASE_NOT_RESET, 0);
- if (retval) {
+ if (retval)
return retval;
- }
}
retval = rtsx_write_register(chip, CLK_DIV, 0xFF,
(div << 4) | mcu_cnt);
- if (retval) {
+ if (retval)
return retval;
- }
retval = rtsx_write_register(chip, CLK_SEL, 0xFF, sel);
- if (retval) {
+ if (retval)
return retval;
- }
if (sd_vpclk_phase_reset) {
udelay(200);
retval = rtsx_write_register(chip, SD_VPCLK0_CTL,
PHASE_NOT_RESET, PHASE_NOT_RESET);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SD_VPCLK1_CTL,
PHASE_NOT_RESET, PHASE_NOT_RESET);
- if (retval) {
+ if (retval)
return retval;
- }
+
udelay(200);
}
retval = rtsx_write_register(chip, CLK_CTL, 0xFF, 0);
- if (retval) {
+ if (retval)
return retval;
- }
chip->cur_clk = clk;
@@ -878,9 +870,8 @@ int enable_card_clock(struct rtsx_chip *chip, u8 card)
clk_en |= MS_CLK_EN;
retval = rtsx_write_register(chip, CARD_CLK_EN, clk_en, clk_en);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -898,9 +889,8 @@ int disable_card_clock(struct rtsx_chip *chip, u8 card)
clk_en |= MS_CLK_EN;
retval = rtsx_write_register(chip, CARD_CLK_EN, clk_en, 0);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -924,9 +914,8 @@ int card_power_on(struct rtsx_chip *chip, u8 card)
rtsx_add_cmd(chip, WRITE_REG_CMD, CARD_PWR_CTL, mask, val1);
retval = rtsx_send_cmd(chip, 0, 100);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
udelay(chip->pmos_pwr_on_interval);
@@ -934,9 +923,8 @@ int card_power_on(struct rtsx_chip *chip, u8 card)
rtsx_add_cmd(chip, WRITE_REG_CMD, CARD_PWR_CTL, mask, val2);
retval = rtsx_send_cmd(chip, 0, 100);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -955,9 +943,8 @@ int card_power_off(struct rtsx_chip *chip, u8 card)
}
retval = rtsx_write_register(chip, CARD_PWR_CTL, mask, val);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -969,9 +956,8 @@ int card_rw(struct scsi_cmnd *srb, struct rtsx_chip *chip,
unsigned int lun = SCSI_LUN(srb);
int i;
- if (!chip->rw_card[lun]) {
+ if (!chip->rw_card[lun])
Re: [PATCH] RISC-V: Show CPU ID and Hart ID separately in /proc/cpuinfo
On Wed, 12 Sep 2018 07:38:22 PDT (-0700), a...@brainfault.org wrote: Currently, /proc/cpuinfo show logical CPU ID as Hart ID which is in-correct. This patch shows CPU ID and Hart ID separately in /proc/cpuinfo using cpuid_to_hardid_map(). With this patch, contents of /proc/cpuinfo looks as follows: cpu : 0 hart: 1 isa : rv64imafdcsu mmu : sv48 cpu : 1 hart: 0 isa : rv64imafdcsu mmu : sv48 cpu : 2 hart: 3 isa : rv64imafdcsu mmu : sv48 cpu : 3 hart: 2 isa : rv64imafdcsu mmu : sv48 Signed-off-by: Anup Patel --- arch/riscv/kernel/cpu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c index f0f0ec2737b7..7c1342e242e6 100644 --- a/arch/riscv/kernel/cpu.c +++ b/arch/riscv/kernel/cpu.c @@ -87,7 +87,8 @@ static int c_show(struct seq_file *m, void *v) NULL); const char *compat, *isa, *mmu; - seq_printf(m, "hart\t: %lu\n", cpu_id); + seq_printf(m, "cpu\t: %lu\n", cpu_id); + seq_printf(m, "hart\t: %lu\n", cpuid_to_hardid_map(cpu_id)); if (!of_property_read_string(node, "riscv,isa", ) && isa[0] == 'r' && isa[1] == 'v') I like this, but it doesn't appear to apply. Do you mind sending something against Linus' master? Then I should be able to sort it out. Thanks!
Re: [PATCH] RISC-V: Show CPU ID and Hart ID separately in /proc/cpuinfo
On Wed, 12 Sep 2018 07:38:22 PDT (-0700), a...@brainfault.org wrote: Currently, /proc/cpuinfo show logical CPU ID as Hart ID which is in-correct. This patch shows CPU ID and Hart ID separately in /proc/cpuinfo using cpuid_to_hardid_map(). With this patch, contents of /proc/cpuinfo looks as follows: cpu : 0 hart: 1 isa : rv64imafdcsu mmu : sv48 cpu : 1 hart: 0 isa : rv64imafdcsu mmu : sv48 cpu : 2 hart: 3 isa : rv64imafdcsu mmu : sv48 cpu : 3 hart: 2 isa : rv64imafdcsu mmu : sv48 Signed-off-by: Anup Patel --- arch/riscv/kernel/cpu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c index f0f0ec2737b7..7c1342e242e6 100644 --- a/arch/riscv/kernel/cpu.c +++ b/arch/riscv/kernel/cpu.c @@ -87,7 +87,8 @@ static int c_show(struct seq_file *m, void *v) NULL); const char *compat, *isa, *mmu; - seq_printf(m, "hart\t: %lu\n", cpu_id); + seq_printf(m, "cpu\t: %lu\n", cpu_id); + seq_printf(m, "hart\t: %lu\n", cpuid_to_hardid_map(cpu_id)); if (!of_property_read_string(node, "riscv,isa", ) && isa[0] == 'r' && isa[1] == 'v') I like this, but it doesn't appear to apply. Do you mind sending something against Linus' master? Then I should be able to sort it out. Thanks!
Re: [RFC PATCH 1/5] RISC-V: Make IPI triggering flexible
On Mon, 10 Sep 2018 06:34:18 PDT (-0700), Christoph Hellwig wrote: On Thu, Sep 06, 2018 at 04:15:14PM +0530, Anup Patel wrote: This patch is doing two things: 1. Allow IRQCHIP driver to provide IPI trigger mechanism And the big questions is why do we want that? The last thing we want is for people to "innovate" on how they deliver IPIs. RISC-V has defined an SBI interface for it to hide all the details, and we should not try to handle systems that are not SBI compliant. Eventuall we might want to revisit the SBI to improve on shortcomings if there are any, but we should not allow random irqchip drivers to override this. I agree. The whole point of the SBI is to provide an interface that everyone uses so we can the go figure out how to make this fast later. If each platform has their own magic IPI hooks then this will end up being a mess. We've got some schemes floating around to make the SBI fast (essentially an SBI VDSO), I'd prefer to push on that rather than adding a bunch of complexity here. 2. Have more generic IPI handler in arch/riscv so that IRQCHIP driver can call it And that is rather irrelevant without 1) above.
Re: [RFC PATCH 1/5] RISC-V: Make IPI triggering flexible
On Mon, 10 Sep 2018 06:34:18 PDT (-0700), Christoph Hellwig wrote: On Thu, Sep 06, 2018 at 04:15:14PM +0530, Anup Patel wrote: This patch is doing two things: 1. Allow IRQCHIP driver to provide IPI trigger mechanism And the big questions is why do we want that? The last thing we want is for people to "innovate" on how they deliver IPIs. RISC-V has defined an SBI interface for it to hide all the details, and we should not try to handle systems that are not SBI compliant. Eventuall we might want to revisit the SBI to improve on shortcomings if there are any, but we should not allow random irqchip drivers to override this. I agree. The whole point of the SBI is to provide an interface that everyone uses so we can the go figure out how to make this fast later. If each platform has their own magic IPI hooks then this will end up being a mess. We've got some schemes floating around to make the SBI fast (essentially an SBI VDSO), I'd prefer to push on that rather than adding a bunch of complexity here. 2. Have more generic IPI handler in arch/riscv so that IRQCHIP driver can call it And that is rather irrelevant without 1) above.
Re: [PATCH 1/2] of/fdt: Allow architectures to override CONFIG_CMDLINE logic
On Fri, 07 Sep 2018 13:29:03 PDT (-0700), robh...@kernel.org wrote: On Fri, Sep 7, 2018 at 1:55 PM Paul Burton wrote: The CONFIG_CMDLINE-related logic in early_init_dt_scan_chosen() falls back to copying CONFIG_CMDLINE into boot_command_line/data if the DT has a /chosen node but that node has no bootargs property or a bootargs property of length zero. The Risc-V guys found a similar issue if chosen is missing[1]. I started a patch[2] to address that, but then looking at the different arches wasn't sure if I'd break something. I don't recall for sure, but it may have been MIPS that worried me. IIRC we actually determined it didn't even work correctly on RISC-V, but I never actually got the time to figure out why and then forgot about it. Sorry! This is problematic for the MIPS architecture because we support concatenating arguments from either the DT or the bootloader with those from CONFIG_CMDLINE, but the behaviour of early_init_dt_scan_chosen() gives us no way of knowing whether boot_command_line contains arguments from DT or already contains CONFIG_CMDLINE. This can lead to us concatenating CONFIG_CMDLINE with itself, duplicating command line arguments which can be problematic (eg. for earlycon which will attempt to register the same console twice & warn about it). If CONFIG_CMDLINE_EXTEND is set, you know it contains CONFIG_CMDLINE. But I guess part of the problem is MIPS using its own kconfig options. Move the CONFIG_CMDLINE-related logic to a weak function that architectures can provide their own version of, such that we continue to use the existing logic for architectures where it's suitable but also allow MIPS to override this behaviour such that the architecture code knows when CONFIG_CMDLINE is used. More arch specific functions is not what I want. Really, all the cmdline manipulating logic doesn't belong in DT code, but it shouldn't be in the arch specific code either IMO. Really it should be some common kernel function which calls into the DT code to retrieve the DT bootargs and that's it. Then you can skip calling that kernel function if you really need non-standard handling. Perhaps you should consider filling DT bootargs with the cmdline from bootloader. IOW, make the legacy case look like the non-legacy case early, and then the kernel doesn't have to deal with both cases later on. Rob [1] https://lkml.org/lkml/2018/3/14/701 [2] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git dt/cmdline
Re: [PATCH] RISC-V: Show IPI stats
On Mon, 10 Sep 2018 06:46:59 PDT (-0700), Christoph Hellwig wrote:
On Fri, Sep 07, 2018 at 06:14:29PM +0530, Anup Patel wrote:
This patch provides arch_show_interrupts() implementation to
show IPI stats via /proc/interrupts.
Now the contents of /proc/interrupts" will look like below:
CPU0 CPU1 CPU2 CPU3
8: 17 7 6 14 SiFive PLIC 8 virtio0
10: 10 10 9 11 SiFive PLIC 10 ttyS0
IPI0: 170673251 79 Rescheduling interrupts
IPI1: 1 12 27 1 Function call interrupts
IPI2: 0 0 0 0 CPU wake-up interrupts
Signed-off-by: Anup Patel
Thanks, this looks pretty sensible to me. Maybe we want to also show
timer interrupts if we do this?
IIRC we used to have some issue where the timer interrupt ID in
/proc/interrupts aliased with a possible PLIC interrupt ID, but that was back
when we had a big mess of chained interrupt drivers that didn't really talk to
each other. I think at some point I might have just removed the timer
interrupt from /proc/interrupts as a hack, but now that our interrupt
controller mess is sorted out it'd be better to have it.
I'm fine taking this without the timer interrupts, as something is better than
nothing.
--- a/arch/riscv/kernel/irq.c
+++ b/arch/riscv/kernel/irq.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
/*
* Possible interrupt causes:
@@ -24,6 +25,14 @@
*/
#define INTERRUPT_CAUSE_FLAG (1UL << (__riscv_xlen - 1))
+int arch_show_interrupts(struct seq_file *p, int prec)
+{
+#ifdef CONFIG_SMP
+ show_ipi_stats(p, prec);
+#endif
+ return 0;
+}
If we don't also add timer stats I'd just move arch_show_interrupts
to smp.c and make it conditional. If we don't this split might make
more sense.
Makes sense, but I think timer interrupts are more interesting to see than IPIs
so we'll eventually pipe them through. Might just be my workloads, though :)
+static const char *ipi_names[IPI_MAX] = {
+ [IPI_RESCHEDULE] = "Rescheduling interrupts",
+ [IPI_CALL_FUNC] = "Function call interrupts",
+ [IPI_CALL_WAKEUP] = "CPU wake-up interrupts",
+};
No need for the explicit array size. Also please use a few tabs to
align this nicely:
static const char *ipi_names[] = {
[IPI_RESCHEDULE]= "Rescheduling interrupts",
[IPI_CALL_FUNC] = "Function call interrupts",
[IPI_CALL_WAKEUP] = "CPU wake-up interrupts",
};
I don't see a v2 of this, was there one? If not then I'll just clean up
ipi_names and drop this on for-next.
Thanks for the patch!
Re: [PATCH 1/2] of/fdt: Allow architectures to override CONFIG_CMDLINE logic
On Fri, 07 Sep 2018 13:29:03 PDT (-0700), robh...@kernel.org wrote: On Fri, Sep 7, 2018 at 1:55 PM Paul Burton wrote: The CONFIG_CMDLINE-related logic in early_init_dt_scan_chosen() falls back to copying CONFIG_CMDLINE into boot_command_line/data if the DT has a /chosen node but that node has no bootargs property or a bootargs property of length zero. The Risc-V guys found a similar issue if chosen is missing[1]. I started a patch[2] to address that, but then looking at the different arches wasn't sure if I'd break something. I don't recall for sure, but it may have been MIPS that worried me. IIRC we actually determined it didn't even work correctly on RISC-V, but I never actually got the time to figure out why and then forgot about it. Sorry! This is problematic for the MIPS architecture because we support concatenating arguments from either the DT or the bootloader with those from CONFIG_CMDLINE, but the behaviour of early_init_dt_scan_chosen() gives us no way of knowing whether boot_command_line contains arguments from DT or already contains CONFIG_CMDLINE. This can lead to us concatenating CONFIG_CMDLINE with itself, duplicating command line arguments which can be problematic (eg. for earlycon which will attempt to register the same console twice & warn about it). If CONFIG_CMDLINE_EXTEND is set, you know it contains CONFIG_CMDLINE. But I guess part of the problem is MIPS using its own kconfig options. Move the CONFIG_CMDLINE-related logic to a weak function that architectures can provide their own version of, such that we continue to use the existing logic for architectures where it's suitable but also allow MIPS to override this behaviour such that the architecture code knows when CONFIG_CMDLINE is used. More arch specific functions is not what I want. Really, all the cmdline manipulating logic doesn't belong in DT code, but it shouldn't be in the arch specific code either IMO. Really it should be some common kernel function which calls into the DT code to retrieve the DT bootargs and that's it. Then you can skip calling that kernel function if you really need non-standard handling. Perhaps you should consider filling DT bootargs with the cmdline from bootloader. IOW, make the legacy case look like the non-legacy case early, and then the kernel doesn't have to deal with both cases later on. Rob [1] https://lkml.org/lkml/2018/3/14/701 [2] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git dt/cmdline
Re: [PATCH] RISC-V: Show IPI stats
On Mon, 10 Sep 2018 06:46:59 PDT (-0700), Christoph Hellwig wrote:
On Fri, Sep 07, 2018 at 06:14:29PM +0530, Anup Patel wrote:
This patch provides arch_show_interrupts() implementation to
show IPI stats via /proc/interrupts.
Now the contents of /proc/interrupts" will look like below:
CPU0 CPU1 CPU2 CPU3
8: 17 7 6 14 SiFive PLIC 8 virtio0
10: 10 10 9 11 SiFive PLIC 10 ttyS0
IPI0: 170673251 79 Rescheduling interrupts
IPI1: 1 12 27 1 Function call interrupts
IPI2: 0 0 0 0 CPU wake-up interrupts
Signed-off-by: Anup Patel
Thanks, this looks pretty sensible to me. Maybe we want to also show
timer interrupts if we do this?
IIRC we used to have some issue where the timer interrupt ID in
/proc/interrupts aliased with a possible PLIC interrupt ID, but that was back
when we had a big mess of chained interrupt drivers that didn't really talk to
each other. I think at some point I might have just removed the timer
interrupt from /proc/interrupts as a hack, but now that our interrupt
controller mess is sorted out it'd be better to have it.
I'm fine taking this without the timer interrupts, as something is better than
nothing.
--- a/arch/riscv/kernel/irq.c
+++ b/arch/riscv/kernel/irq.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
/*
* Possible interrupt causes:
@@ -24,6 +25,14 @@
*/
#define INTERRUPT_CAUSE_FLAG (1UL << (__riscv_xlen - 1))
+int arch_show_interrupts(struct seq_file *p, int prec)
+{
+#ifdef CONFIG_SMP
+ show_ipi_stats(p, prec);
+#endif
+ return 0;
+}
If we don't also add timer stats I'd just move arch_show_interrupts
to smp.c and make it conditional. If we don't this split might make
more sense.
Makes sense, but I think timer interrupts are more interesting to see than IPIs
so we'll eventually pipe them through. Might just be my workloads, though :)
+static const char *ipi_names[IPI_MAX] = {
+ [IPI_RESCHEDULE] = "Rescheduling interrupts",
+ [IPI_CALL_FUNC] = "Function call interrupts",
+ [IPI_CALL_WAKEUP] = "CPU wake-up interrupts",
+};
No need for the explicit array size. Also please use a few tabs to
align this nicely:
static const char *ipi_names[] = {
[IPI_RESCHEDULE]= "Rescheduling interrupts",
[IPI_CALL_FUNC] = "Function call interrupts",
[IPI_CALL_WAKEUP] = "CPU wake-up interrupts",
};
I don't see a v2 of this, was there one? If not then I'll just clean up
ipi_names and drop this on for-next.
Thanks for the patch!
[PATCH] MAINTAINERS: removed staging/ft1000 driver
Delete the ft1000 MAINTAINERS entry, concluding the
earlier removal of the driver in commit 6512edec48b2
("staging: ft1000: remove obsolete driver").
Reported-by: Joe Perches
Signed-off-by: Deepa Dinamani
---
MAINTAINERS | 5 -
1 file changed, 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1c62b724bb60..6b29bc4da920 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13908,11 +13908,6 @@ L: linux-er...@lists.ozlabs.org
S: Maintained
F: drivers/staging/erofs/
-STAGING - FLARION FT1000 DRIVERS
-M: Marek Belisko
-S: Odd Fixes
-F: drivers/staging/ft1000/
-
STAGING - INDUSTRIAL IO
M: Jonathan Cameron
L: linux-...@vger.kernel.org
--
2.17.1
[PATCH] MAINTAINERS: removed staging/ft1000 driver
Delete the ft1000 MAINTAINERS entry, concluding the
earlier removal of the driver in commit 6512edec48b2
("staging: ft1000: remove obsolete driver").
Reported-by: Joe Perches
Signed-off-by: Deepa Dinamani
---
MAINTAINERS | 5 -
1 file changed, 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1c62b724bb60..6b29bc4da920 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13908,11 +13908,6 @@ L: linux-er...@lists.ozlabs.org
S: Maintained
F: drivers/staging/erofs/
-STAGING - FLARION FT1000 DRIVERS
-M: Marek Belisko
-S: Odd Fixes
-F: drivers/staging/ft1000/
-
STAGING - INDUSTRIAL IO
M: Jonathan Cameron
L: linux-...@vger.kernel.org
--
2.17.1
Re: [git pull] Input updates for v4.19-rc5
On Fri, Sep 28, 2018 at 04:57:51PM -0700, Dmitry Torokhov wrote: > Hi Greg, > > Please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus > > to receive updates for the input subsystem. Just a few driver fixes. Now pulled, thanks. greg k-h
Re: [git pull] Input updates for v4.19-rc5
On Fri, Sep 28, 2018 at 04:57:51PM -0700, Dmitry Torokhov wrote: > Hi Greg, > > Please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus > > to receive updates for the input subsystem. Just a few driver fixes. Now pulled, thanks. greg k-h
Re: [GIT PULL] spi fixes for v4.19
On Fri, Sep 28, 2018 at 03:30:41PM +0100, Mark Brown wrote: > The following changes since commit 5223c9c1cbfc0cd4d0a1b50758e0949af3290fa1: > > spi: spi-fsl-dspi: fix broken DSPI_EOQ_MODE (2018-08-28 20:55:23 +0100) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git > tags/spi-fix-v4.19-rc5 Now pulled, thanks. greg k-h
Re: [GIT PULL] spi fixes for v4.19
On Fri, Sep 28, 2018 at 03:30:41PM +0100, Mark Brown wrote: > The following changes since commit 5223c9c1cbfc0cd4d0a1b50758e0949af3290fa1: > > spi: spi-fsl-dspi: fix broken DSPI_EOQ_MODE (2018-08-28 20:55:23 +0100) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git > tags/spi-fix-v4.19-rc5 Now pulled, thanks. greg k-h
Re: [GIT PULL] regulator fixes for v4.19
On Fri, Sep 28, 2018 at 02:42:53PM +0100, Mark Brown wrote: > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git > tags/regulator-v4.19-rc5 Now pulled, thanks. greg k-h
Re: [GIT PULL] regulator fixes for v4.19
On Fri, Sep 28, 2018 at 02:42:53PM +0100, Mark Brown wrote: > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git > tags/regulator-v4.19-rc5 Now pulled, thanks. greg k-h
Re: Bad MAINTAINERS pattern in section 'STAGING - FLARION FT1000 DRIVERS'
On Fri, 2018-09-28 at 17:46 -0700, Greg Kroah-Hartman wrote: > On Fri, Sep 28, 2018 at 03:04:23PM -0700, Joe Perches wrote: > > Please fix this defect appropriately. > > > > linux-next MAINTAINERS section: > > > > 13899 STAGING - FLARION FT1000 DRIVERS > > 13900 M: Marek Belisko > > 13901 S: Odd Fixes > > --> 13902 F: drivers/staging/ft1000/ > > > > Commit that introduced this: > > > > commit a0138163cfbfdfbdc20e4477c77bd7046bd66bb4 > > Author: Joe Perches > > Date: Tue Jul 5 15:21:34 2011 -0700 > > > > MAINTAINERS: Add remaining staging entries > > > > Add the staging entries from various TODO files > > to MAINTAINERS. Add a few web links as well. > > > > Miscellaneous staging typo section header fix. > > > > Signed-off-by: Joe Perches > > Signed-off-by: Greg Kroah-Hartman > > > > MAINTAINERS | 69 > > - > > 1 file changed, 68 insertions(+), 1 deletion(-) > > So you are going to fix this, considering you created the problem? _I_ did not create this problem. You neglected to read the commit information below this in the parent email. When I wrote the MAINTAINERS patch in 2011, the files existed. The files were removed in 2015 and you signed-off on their removal. -- Last commit with drivers/staging/ft1000/ commit 6512edec48b2ccfe9bb969ce26ebbbcd49de6c4b Author: Deepa Dinamani Date: Wed Oct 21 18:42:37 2015 -0700 staging: ft1000: remove obsolete driver Remove support for Qleadtek Flash-OFDM modems. Telecom carrier is discontinuing service for the radio technology. See http://www.gtigroup.org/news/ind/2015-08-18/6996.html. Suggested-by: Arnd Bergmann Signed-off-by: Deepa Dinamani Acked-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman -- > This is an odd request to make of yourself in public, or was this a > script gone wrong? It was not a script gone wrong, though the output and emails were scripted. > confused, No worries, it's easy to miss stuff. fyi: the silly script I wrote is attached Done using the latest -next with an empty patterns directory $ perl ./scripts/get_maintainer.pl --self-test=patterns | \ cut -f2 -d: | \ while read line ; do \ perl ./dump_section.perl $line \ done dump_section.perl Description: Perl program
Re: Bad MAINTAINERS pattern in section 'STAGING - FLARION FT1000 DRIVERS'
On Fri, 2018-09-28 at 17:46 -0700, Greg Kroah-Hartman wrote: > On Fri, Sep 28, 2018 at 03:04:23PM -0700, Joe Perches wrote: > > Please fix this defect appropriately. > > > > linux-next MAINTAINERS section: > > > > 13899 STAGING - FLARION FT1000 DRIVERS > > 13900 M: Marek Belisko > > 13901 S: Odd Fixes > > --> 13902 F: drivers/staging/ft1000/ > > > > Commit that introduced this: > > > > commit a0138163cfbfdfbdc20e4477c77bd7046bd66bb4 > > Author: Joe Perches > > Date: Tue Jul 5 15:21:34 2011 -0700 > > > > MAINTAINERS: Add remaining staging entries > > > > Add the staging entries from various TODO files > > to MAINTAINERS. Add a few web links as well. > > > > Miscellaneous staging typo section header fix. > > > > Signed-off-by: Joe Perches > > Signed-off-by: Greg Kroah-Hartman > > > > MAINTAINERS | 69 > > - > > 1 file changed, 68 insertions(+), 1 deletion(-) > > So you are going to fix this, considering you created the problem? _I_ did not create this problem. You neglected to read the commit information below this in the parent email. When I wrote the MAINTAINERS patch in 2011, the files existed. The files were removed in 2015 and you signed-off on their removal. -- Last commit with drivers/staging/ft1000/ commit 6512edec48b2ccfe9bb969ce26ebbbcd49de6c4b Author: Deepa Dinamani Date: Wed Oct 21 18:42:37 2015 -0700 staging: ft1000: remove obsolete driver Remove support for Qleadtek Flash-OFDM modems. Telecom carrier is discontinuing service for the radio technology. See http://www.gtigroup.org/news/ind/2015-08-18/6996.html. Suggested-by: Arnd Bergmann Signed-off-by: Deepa Dinamani Acked-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman -- > This is an odd request to make of yourself in public, or was this a > script gone wrong? It was not a script gone wrong, though the output and emails were scripted. > confused, No worries, it's easy to miss stuff. fyi: the silly script I wrote is attached Done using the latest -next with an empty patterns directory $ perl ./scripts/get_maintainer.pl --self-test=patterns | \ cut -f2 -d: | \ while read line ; do \ perl ./dump_section.perl $line \ done dump_section.perl Description: Perl program
Step-by-Step Tutorial: How to Setup Your Own e-Commerce Online Store using WooCommerce 3.4.5, Wordpress 4.9.8, and CentOS 1805 (LAMP) in Amazon AWS Cloud
Step-by-Step Tutorial: How to Setup Your Own e-Commerce Online Store using WooCommerce 3.4.5, Wordpress 4.9.8, and CentOS 1805 (LAMP) in Amazon AWS Cloud Author: Mr. Turritopsis Dohrnii Teo En Ming Country: Singapore Date: 28th September 2018 Friday Document Version: 1809.01 Abbreviations = LAMP: Linux + Apache Web Server + MySQL/MariaDB + PHP WAMP: Windows + Apache Web Server + MySQL/MariaDB + PHP SECTION 1 CREATING YOUR CENTOS 7.5 (1805) LINUX INSTANCE 001. Login to Amazon Web Services. 002. Click Services > Compute > EC2. 003. Click Network & Security > Key Pairs 004. Click Create Key Pair. 005. Enter your key pair name. Then click Create. 006. Be sure to download your private key in the form of a .PEM file. You will need to convert it to a .PPK file later. 007. Click Instances > Instances. 008. Click Launch Instance. 009. Click AWS Marketplace. 010. Search for CentOS. 011. Select CentOS 7 (x86_64) - with Updates HVM Amazon Machine Image (AMI). 012. Click Continue. 013. Select General Purpose, t2.micro, 1 vCPU, 1 GB RAM (FREE TIER ELIGIBLE). 014. Click Next: Configure Instance Details. 015. Select Network: 016. Select Subnet: 017. Click Protect against accidental termination. 018. Click Next: Add Storage. 019. Click Next: Add Tags. Click Add tag. 020. Enter Key = Name and Value = Online Store. 021. Click Next: Configure Security Group 022. Click Select an existing security group. 023. Select VS_SG (Virtual Server Security Group). 024. Click Review and Launch. Click Launch. 025. Select a key pair. Click Launch Instances. 026. Click View Instances. 027. Click Network & Security > Elastic IPs. 028. Select an unused IPv4 address. 029. Click Actions > Associate address. 030. Select the Online Store instance. 031. Click Allow Elastic IP to be reassociated if already attached. 032. Click Associate. Click Close. 033. Login to CentOS 7.5 Linux using Putty. SECTION 2 INSTALLING WORDPRESS 4.9.8 034. sudo yum install php php-mysql php-devel php-gd php-pecl-memcache php-pspell php-snmp php-xmlrpc php-xml Guide: How To Install MySQL / MariaDB on CentOS 7 Link: https://www.liquidweb.com/kb/how-to-install-mysql-mariadb-on-centos-7/ 035. sudo yum -y install mariadb-server mariadb 036. sudo yum install wget Guide: Installing WordPress: Detailed Instructions Link: https://codex.wordpress.org/Installing_WordPress#Detailed_Instructions 037. wget https://wordpress.org/latest.tar.gz 038. tar xfvz latest.tar.gz 039. sudo passwd root 040. su - 041. systemctl start mariadb 042. systemctl enable mariadb 043. mysql 044. MariaDB [(none)]> CREATE DATABASE wordpress; 045. MariaDB [(none)]> GRANT ALL PRIVILEGES ON wordpress.* TO "wordpress"@"localhost" IDENTIFIED BY "password"; 046. MariaDB [(none)]> FLUSH PRIVILEGES; 047. MariaDB [(none)]> EXIT 048. cd /home/centos/wordpress AFAIK Wordpress 4.9.8 cannot be installed in a subdirectory. If you encounter a HTTP error code 500 doing so, be sure to check the Apache Web Server error logs, that is, tail -f /var/log/httpd/error_log. 049. cp -R * /var/www/html 050. systemctl start httpd 051. systemctl enable httpd 052. sudo yum install nano 053. nano /etc/httpd/conf/httpd.conf 054. Append the following line AddType application/x-httpd-php .php 055. systemctl restart httpd Wordpress 4.9.8's PHP code won't execute on php-5.4.16, which is installed by default on CentOS 7.5. It will return a HTTP error code of 500. Install PHP-7.2.10 instead. Guide: How to Install PHP 7 in CentOS 7 Link: https://www.tecmint.com/install-php-7-in-centos-7/ 056. yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm 057. yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm 058. yum install yum-utils You will need minimum PHP 7.2. 059. yum-config-manager --enable remi-php72 060. yum install php php-mcrypt php-cli php-gd php-curl php-mysql php-ldap php-zip php-fileinfo 061. php -v PHP 7.2.10 is now installed. 062. systemctl stop httpd && systemctl start httpd 063. Go to http:// 064. Click Let's go! 065. Fill in the following MySQL/MariaDB database connection information. Database Name: wordpress Username: wordpress Password: password Database Host: localhost Table Prefix: wp_ 066. Click Submit. 067. cd /var/www/html 068. nano wp-config.php 069. Copy and paste the contents of wp-config.php shown on the Wordpress installation screen on your browser. 070. Click Run the installation. 071. Fill in the following information. Site Title: Teo En Ming Corporation Online Store Username: admin Password: password Your email: u...@example.com Uncheck Discourage search engines from indexing this site 072. Click Install wordpress. 073. Click Login. SECTION 3 INSTALLING WOOCOMMERCE 3.4.5 == Follow the WooCommerce installation guide here:
Step-by-Step Tutorial: How to Setup Your Own e-Commerce Online Store using WooCommerce 3.4.5, Wordpress 4.9.8, and CentOS 1805 (LAMP) in Amazon AWS Cloud
Step-by-Step Tutorial: How to Setup Your Own e-Commerce Online Store using WooCommerce 3.4.5, Wordpress 4.9.8, and CentOS 1805 (LAMP) in Amazon AWS Cloud Author: Mr. Turritopsis Dohrnii Teo En Ming Country: Singapore Date: 28th September 2018 Friday Document Version: 1809.01 Abbreviations = LAMP: Linux + Apache Web Server + MySQL/MariaDB + PHP WAMP: Windows + Apache Web Server + MySQL/MariaDB + PHP SECTION 1 CREATING YOUR CENTOS 7.5 (1805) LINUX INSTANCE 001. Login to Amazon Web Services. 002. Click Services > Compute > EC2. 003. Click Network & Security > Key Pairs 004. Click Create Key Pair. 005. Enter your key pair name. Then click Create. 006. Be sure to download your private key in the form of a .PEM file. You will need to convert it to a .PPK file later. 007. Click Instances > Instances. 008. Click Launch Instance. 009. Click AWS Marketplace. 010. Search for CentOS. 011. Select CentOS 7 (x86_64) - with Updates HVM Amazon Machine Image (AMI). 012. Click Continue. 013. Select General Purpose, t2.micro, 1 vCPU, 1 GB RAM (FREE TIER ELIGIBLE). 014. Click Next: Configure Instance Details. 015. Select Network: 016. Select Subnet: 017. Click Protect against accidental termination. 018. Click Next: Add Storage. 019. Click Next: Add Tags. Click Add tag. 020. Enter Key = Name and Value = Online Store. 021. Click Next: Configure Security Group 022. Click Select an existing security group. 023. Select VS_SG (Virtual Server Security Group). 024. Click Review and Launch. Click Launch. 025. Select a key pair. Click Launch Instances. 026. Click View Instances. 027. Click Network & Security > Elastic IPs. 028. Select an unused IPv4 address. 029. Click Actions > Associate address. 030. Select the Online Store instance. 031. Click Allow Elastic IP to be reassociated if already attached. 032. Click Associate. Click Close. 033. Login to CentOS 7.5 Linux using Putty. SECTION 2 INSTALLING WORDPRESS 4.9.8 034. sudo yum install php php-mysql php-devel php-gd php-pecl-memcache php-pspell php-snmp php-xmlrpc php-xml Guide: How To Install MySQL / MariaDB on CentOS 7 Link: https://www.liquidweb.com/kb/how-to-install-mysql-mariadb-on-centos-7/ 035. sudo yum -y install mariadb-server mariadb 036. sudo yum install wget Guide: Installing WordPress: Detailed Instructions Link: https://codex.wordpress.org/Installing_WordPress#Detailed_Instructions 037. wget https://wordpress.org/latest.tar.gz 038. tar xfvz latest.tar.gz 039. sudo passwd root 040. su - 041. systemctl start mariadb 042. systemctl enable mariadb 043. mysql 044. MariaDB [(none)]> CREATE DATABASE wordpress; 045. MariaDB [(none)]> GRANT ALL PRIVILEGES ON wordpress.* TO "wordpress"@"localhost" IDENTIFIED BY "password"; 046. MariaDB [(none)]> FLUSH PRIVILEGES; 047. MariaDB [(none)]> EXIT 048. cd /home/centos/wordpress AFAIK Wordpress 4.9.8 cannot be installed in a subdirectory. If you encounter a HTTP error code 500 doing so, be sure to check the Apache Web Server error logs, that is, tail -f /var/log/httpd/error_log. 049. cp -R * /var/www/html 050. systemctl start httpd 051. systemctl enable httpd 052. sudo yum install nano 053. nano /etc/httpd/conf/httpd.conf 054. Append the following line AddType application/x-httpd-php .php 055. systemctl restart httpd Wordpress 4.9.8's PHP code won't execute on php-5.4.16, which is installed by default on CentOS 7.5. It will return a HTTP error code of 500. Install PHP-7.2.10 instead. Guide: How to Install PHP 7 in CentOS 7 Link: https://www.tecmint.com/install-php-7-in-centos-7/ 056. yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm 057. yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm 058. yum install yum-utils You will need minimum PHP 7.2. 059. yum-config-manager --enable remi-php72 060. yum install php php-mcrypt php-cli php-gd php-curl php-mysql php-ldap php-zip php-fileinfo 061. php -v PHP 7.2.10 is now installed. 062. systemctl stop httpd && systemctl start httpd 063. Go to http:// 064. Click Let's go! 065. Fill in the following MySQL/MariaDB database connection information. Database Name: wordpress Username: wordpress Password: password Database Host: localhost Table Prefix: wp_ 066. Click Submit. 067. cd /var/www/html 068. nano wp-config.php 069. Copy and paste the contents of wp-config.php shown on the Wordpress installation screen on your browser. 070. Click Run the installation. 071. Fill in the following information. Site Title: Teo En Ming Corporation Online Store Username: admin Password: password Your email: u...@example.com Uncheck Discourage search engines from indexing this site 072. Click Install wordpress. 073. Click Login. SECTION 3 INSTALLING WOOCOMMERCE 3.4.5 == Follow the WooCommerce installation guide here:
Re: [PATCH] sched/fair: vruntime should normalize when switching from fair
On Sat, 29 Sep 2018 at 01:36, Dietmar Eggemann wrote: > > On 09/28/2018 06:10 PM, Steve Muckle wrote: > > On 09/27/2018 05:43 PM, Wanpeng Li wrote: > On your CPU4: > scheduler_ipi() > -> sched_ttwu_pending() > -> ttwu_do_activate()=> p->sched_remote_wakeup should be > false, so ENQUEUE_WAKEUP is set, ENQUEUE_MIGRATED is not > -> ttwu_activate() > -> activate_task() > -> enqueue_task() > -> enqueue_task_fair() > -> enqueue_entity() > bool renorm = !(flags & > ENQUEUE_WAKEUP) || (flags & ENQUEUE_MIGRATE) > so renorm is false in enqueue_entity(), why you mentioned that the > cfs_rq->min_vruntime is still added to the se->vruntime in > enqueue_task_fair()? > >>> > >>> Maybe this is a misunderstanding on my side but didn't you asked me to > >>> '... Could you point out when the fair rq's min_vruntime is added to the > >>> task's vruntime in your *later* scenario? ...' > >> > >> Yeah, if the calltrace above and my analysis is correct, then the fair > >> rq's min_vruntime will not be added to the task's vruntime in your > >> *later* scenario, which means that your patch is not necessary. > > > > In the scenario I observed, the task is not waking - it is running and > > being deboosted from priority inheritance, transitioning from RT to CFS. > > > > Dietmar and I both were able to reproduce the issue with the testcase I > > posted earlier in this thread. > > Correct, and with the same testcase I got this call stack in this scenario: > > [ 35.588509] CPU: 1 PID: 2926 Comm: fair_task Not tainted > 4.18.0-rc6-00052-g11b7dafa2edb-dirty #5 > [ 35.597217] Hardware name: ARM Juno development board (r0) (DT) > [ 35.603080] Call trace: > [ 35.605509] dump_backtrace+0x0/0x168 > [ 35.609138] show_stack+0x24/0x30 > [ 35.612424] dump_stack+0xac/0xe4 > [ 35.615710] enqueue_task_fair+0xae0/0x11c0 > [ 35.619854] rt_mutex_setprio+0x5a0/0x628 > [ 35.623827] mark_wakeup_next_waiter+0x7c/0xc8 > [ 35.628228] __rt_mutex_futex_unlock+0x30/0x50 > [ 35.632630] do_futex+0x74c/0xb28 > [ 35.635912] sys_futex+0x118/0x198 > [ 35.639280] el0_svc_naked+0x30/0x34 Thanks for pointing out. :) Regards, Wanpeng Li
Re: [PATCH] sched/fair: vruntime should normalize when switching from fair
On Sat, 29 Sep 2018 at 01:36, Dietmar Eggemann wrote: > > On 09/28/2018 06:10 PM, Steve Muckle wrote: > > On 09/27/2018 05:43 PM, Wanpeng Li wrote: > On your CPU4: > scheduler_ipi() > -> sched_ttwu_pending() > -> ttwu_do_activate()=> p->sched_remote_wakeup should be > false, so ENQUEUE_WAKEUP is set, ENQUEUE_MIGRATED is not > -> ttwu_activate() > -> activate_task() > -> enqueue_task() > -> enqueue_task_fair() > -> enqueue_entity() > bool renorm = !(flags & > ENQUEUE_WAKEUP) || (flags & ENQUEUE_MIGRATE) > so renorm is false in enqueue_entity(), why you mentioned that the > cfs_rq->min_vruntime is still added to the se->vruntime in > enqueue_task_fair()? > >>> > >>> Maybe this is a misunderstanding on my side but didn't you asked me to > >>> '... Could you point out when the fair rq's min_vruntime is added to the > >>> task's vruntime in your *later* scenario? ...' > >> > >> Yeah, if the calltrace above and my analysis is correct, then the fair > >> rq's min_vruntime will not be added to the task's vruntime in your > >> *later* scenario, which means that your patch is not necessary. > > > > In the scenario I observed, the task is not waking - it is running and > > being deboosted from priority inheritance, transitioning from RT to CFS. > > > > Dietmar and I both were able to reproduce the issue with the testcase I > > posted earlier in this thread. > > Correct, and with the same testcase I got this call stack in this scenario: > > [ 35.588509] CPU: 1 PID: 2926 Comm: fair_task Not tainted > 4.18.0-rc6-00052-g11b7dafa2edb-dirty #5 > [ 35.597217] Hardware name: ARM Juno development board (r0) (DT) > [ 35.603080] Call trace: > [ 35.605509] dump_backtrace+0x0/0x168 > [ 35.609138] show_stack+0x24/0x30 > [ 35.612424] dump_stack+0xac/0xe4 > [ 35.615710] enqueue_task_fair+0xae0/0x11c0 > [ 35.619854] rt_mutex_setprio+0x5a0/0x628 > [ 35.623827] mark_wakeup_next_waiter+0x7c/0xc8 > [ 35.628228] __rt_mutex_futex_unlock+0x30/0x50 > [ 35.632630] do_futex+0x74c/0xb28 > [ 35.635912] sys_futex+0x118/0x198 > [ 35.639280] el0_svc_naked+0x30/0x34 Thanks for pointing out. :) Regards, Wanpeng Li
Re: [GIT PULL] pin control fixes for v4.19 take 4
On Fri, Sep 28, 2018 at 08:59:32AM +0200, Linus Walleij wrote: > Hi Greg, > > here are some three pin control fixes for v4.19. > All are x86 related. > > Please pull them in! Now pulled, thanks. greg k-h
Re: [GIT PULL] pin control fixes for v4.19 take 4
On Fri, Sep 28, 2018 at 08:59:32AM +0200, Linus Walleij wrote: > Hi Greg, > > here are some three pin control fixes for v4.19. > All are x86 related. > > Please pull them in! Now pulled, thanks. greg k-h
Re: Licenses and revocability, in a paragraph or less.
It is imperative that the people know their rights so that they are not taken advantage of by moneyed interests. For those who are dispossessed there are remedies at law and in equity. Here we have a situation where moneyed interests have found a social exploit to leverage into ascendancy, while those who created the edifice which they have willed to conquer are shut out. On 2018-09-28 03:56, Eric S. Raymond wrote: freedomfromr...@aaathats3as.com : As has been stated in easily accessible terms elsewhere: "Most courts hold that simple, non-exclusive licenses with unspecified durations that are silent on revocability are revocable at will. This means that the licensor may terminate the license at any time, with or without cause." + Furthermore, license revocation is not the only option. In Jacobsen vs. Katzer (535 F.3d 1373 (Fed. Cir. 2008) it was found that open-source developers have an actionable right not to have their software misappropriated even though the resulting damages are only reputational rather than monetary. Under that theory, developers can seek an injunction against a misappropriating party without globally revoking their license. The application of that case law to this situation is left as an easy exercise for the reader. Any competent paralegal could write the brief in an evening. Hell, I could almost do it myself. I do not personally want to see this happen. But that it is possible is a fact all parties must deal with.
Re: Licenses and revocability, in a paragraph or less.
It is imperative that the people know their rights so that they are not taken advantage of by moneyed interests. For those who are dispossessed there are remedies at law and in equity. Here we have a situation where moneyed interests have found a social exploit to leverage into ascendancy, while those who created the edifice which they have willed to conquer are shut out. On 2018-09-28 03:56, Eric S. Raymond wrote: freedomfromr...@aaathats3as.com : As has been stated in easily accessible terms elsewhere: "Most courts hold that simple, non-exclusive licenses with unspecified durations that are silent on revocability are revocable at will. This means that the licensor may terminate the license at any time, with or without cause." + Furthermore, license revocation is not the only option. In Jacobsen vs. Katzer (535 F.3d 1373 (Fed. Cir. 2008) it was found that open-source developers have an actionable right not to have their software misappropriated even though the resulting damages are only reputational rather than monetary. Under that theory, developers can seek an injunction against a misappropriating party without globally revoking their license. The application of that case law to this situation is left as an easy exercise for the reader. Any competent paralegal could write the brief in an evening. Hell, I could almost do it myself. I do not personally want to see this happen. But that it is possible is a fact all parties must deal with.
Again: Licenses and revocability, in a paragraph or less. GPL 2 is revocable at the will of the grantor.
As has been stated in easily accessible terms elsewhere: "Most courts hold that simple, non-exclusive licenses with unspecified durations that are silent on revocability are revocable at will. This means that the licensor may terminate the license at any time, with or without cause." + Version 2 of the GPL specifies no duration, nor does it declare that it is non-revocable by the grantor. (Also note: A perpetual license may violate the rule against perpetuities in various jurisdictions where it is applied not only to real property but additionally to personal property (and the like), which is why the GPL-3's term of duration is set as the duration of copyright on the program (and not "forever")) +[https://www.sidley.com/en/insights/newsupdates/2013/02/the-terms-revocable-and-irrevocable-in-license-agreements-tips-and-pitfalls]
Again: Licenses and revocability, in a paragraph or less. GPL 2 is revocable at the will of the grantor.
As has been stated in easily accessible terms elsewhere: "Most courts hold that simple, non-exclusive licenses with unspecified durations that are silent on revocability are revocable at will. This means that the licensor may terminate the license at any time, with or without cause." + Version 2 of the GPL specifies no duration, nor does it declare that it is non-revocable by the grantor. (Also note: A perpetual license may violate the rule against perpetuities in various jurisdictions where it is applied not only to real property but additionally to personal property (and the like), which is why the GPL-3's term of duration is set as the duration of copyright on the program (and not "forever")) +[https://www.sidley.com/en/insights/newsupdates/2013/02/the-terms-revocable-and-irrevocable-in-license-agreements-tips-and-pitfalls]
Re: [PATCH -V5 RESEND 03/21] swap: Support PMD swap mapping in swap_duplicate()
Daniel Jordan writes: > On Fri, Sep 28, 2018 at 04:19:03PM +0800, Huang, Ying wrote: >> Daniel Jordan writes: >> > One way is to change >> > copy_one_pte's return to int so we can just pass the error code back to >> > copy_pte_range so it knows whether to try adding the continuation. >> >> There may be even more problems. After add_swap_count_continuation(), >> copy_one_pte() will be retried, and the CPU may hang with dead loop. > > That's true, it would do that. > >> But before the changes in this patchset, the behavior is, >> __swap_duplicate() return an error that isn't -ENOMEM, such as -EEXIST. >> Then copy_one_pte() would thought the operation has been done >> successfully, and go to call set_pte_at(). This will cause the system >> state become inconsistent, and the system may panic or hang somewhere >> later. >> >> So per my understanding, if we thought page table corruption isn't a >> real problem (that is, __swap_duplicate() will never return e.g. -EEXIST >> if copied by copy_one_pte() indirectly), both the original and the new >> code should be OK. >> >> If we thought it is a real problem, we need to fix the original code and >> keep it fixed in the new code. Do you agree? > > Yes, if it was a real problem, which seems less and less the case the more I > stare at this. > >> There's several ways to fix the problem. But the page table shouldn't >> be corrupted in practice, unless there's some programming error. So I >> suggest to make it as simple as possible via adding, >> >> VM_BUG_ON(error != -ENOMEM); >> >> in swap_duplicate(). >> >> Do you agree? > > Yes, I'm ok with that, adding in -ENOTDIR along with it. Sure. I will do this. > The error handling in __swap_duplicate (before this series) still leaves > something to be desired IMHO. Why all the different returns when callers > ignore them or only specifically check for -ENOMEM or -EEXIST? Could maybe > stand a cleanup, but outside this series. Yes. Maybe. I guess you will work on this? Best Regards, Huang, Ying
Re: [PATCH -V5 RESEND 03/21] swap: Support PMD swap mapping in swap_duplicate()
Daniel Jordan writes: > On Fri, Sep 28, 2018 at 04:19:03PM +0800, Huang, Ying wrote: >> Daniel Jordan writes: >> > One way is to change >> > copy_one_pte's return to int so we can just pass the error code back to >> > copy_pte_range so it knows whether to try adding the continuation. >> >> There may be even more problems. After add_swap_count_continuation(), >> copy_one_pte() will be retried, and the CPU may hang with dead loop. > > That's true, it would do that. > >> But before the changes in this patchset, the behavior is, >> __swap_duplicate() return an error that isn't -ENOMEM, such as -EEXIST. >> Then copy_one_pte() would thought the operation has been done >> successfully, and go to call set_pte_at(). This will cause the system >> state become inconsistent, and the system may panic or hang somewhere >> later. >> >> So per my understanding, if we thought page table corruption isn't a >> real problem (that is, __swap_duplicate() will never return e.g. -EEXIST >> if copied by copy_one_pte() indirectly), both the original and the new >> code should be OK. >> >> If we thought it is a real problem, we need to fix the original code and >> keep it fixed in the new code. Do you agree? > > Yes, if it was a real problem, which seems less and less the case the more I > stare at this. > >> There's several ways to fix the problem. But the page table shouldn't >> be corrupted in practice, unless there's some programming error. So I >> suggest to make it as simple as possible via adding, >> >> VM_BUG_ON(error != -ENOMEM); >> >> in swap_duplicate(). >> >> Do you agree? > > Yes, I'm ok with that, adding in -ENOTDIR along with it. Sure. I will do this. > The error handling in __swap_duplicate (before this series) still leaves > something to be desired IMHO. Why all the different returns when callers > ignore them or only specifically check for -ENOMEM or -EEXIST? Could maybe > stand a cleanup, but outside this series. Yes. Maybe. I guess you will work on this? Best Regards, Huang, Ying
Re: Bad MAINTAINERS pattern in section 'STAGING - FLARION FT1000 DRIVERS'
On Fri, Sep 28, 2018 at 03:04:23PM -0700, Joe Perches wrote: > Please fix this defect appropriately. > > linux-next MAINTAINERS section: > > 13899 STAGING - FLARION FT1000 DRIVERS > 13900 M: Marek Belisko > 13901 S: Odd Fixes > --> 13902 F: drivers/staging/ft1000/ > > Commit that introduced this: > > commit a0138163cfbfdfbdc20e4477c77bd7046bd66bb4 > Author: Joe Perches > Date: Tue Jul 5 15:21:34 2011 -0700 > > MAINTAINERS: Add remaining staging entries > > Add the staging entries from various TODO files > to MAINTAINERS. Add a few web links as well. > > Miscellaneous staging typo section header fix. > > Signed-off-by: Joe Perches > Signed-off-by: Greg Kroah-Hartman > > MAINTAINERS | 69 > - > 1 file changed, 68 insertions(+), 1 deletion(-) So you are going to fix this, considering you created the problem? This is an odd request to make of yourself in public, or was this a script gone wrong? confused, greg k-h
Re: Bad MAINTAINERS pattern in section 'STAGING - FLARION FT1000 DRIVERS'
On Fri, Sep 28, 2018 at 03:04:23PM -0700, Joe Perches wrote: > Please fix this defect appropriately. > > linux-next MAINTAINERS section: > > 13899 STAGING - FLARION FT1000 DRIVERS > 13900 M: Marek Belisko > 13901 S: Odd Fixes > --> 13902 F: drivers/staging/ft1000/ > > Commit that introduced this: > > commit a0138163cfbfdfbdc20e4477c77bd7046bd66bb4 > Author: Joe Perches > Date: Tue Jul 5 15:21:34 2011 -0700 > > MAINTAINERS: Add remaining staging entries > > Add the staging entries from various TODO files > to MAINTAINERS. Add a few web links as well. > > Miscellaneous staging typo section header fix. > > Signed-off-by: Joe Perches > Signed-off-by: Greg Kroah-Hartman > > MAINTAINERS | 69 > - > 1 file changed, 68 insertions(+), 1 deletion(-) So you are going to fix this, considering you created the problem? This is an odd request to make of yourself in public, or was this a script gone wrong? confused, greg k-h
Re: [PATCH v3 2/2] spi: Introduce new driver for Qualcomm QuadSPI controller
Quoting Ryan Case (2018-09-28 11:19:51)
> On Wed, Sep 26, 2018 at 11:43 PM Stephen Boyd wrote:
> > Quoting Ryan Case (2018-09-26 13:52:04)
> > > From: Girish Mahadevan
> > > +#include
> > > +
> > > +#define AHB_MIN_HZ 960UL
> >
> > Is this used?
>
> Nope. Do you want all currently unused defines removed or specifically this
> one? I saw precedent in other drivers for defining registers/flags/values of
> supported but unused functionality so I left these (big endian, DDR, ...).
I guess it's fine but I don't know if it will ever be used so remove it?
I'd leave the others if they help someone know what register bits exist.
That's usually how I handle it.
>
>
> > > + speed_hz = slv->max_speed_hz;
> > > + if (xfer->speed_hz)
> > > + speed_hz = xfer->speed_hz;
> > > +
> > > + ret = clk_set_rate(ctrl->clks[QSPI_CLK_CORE].clk, speed_hz * 4);
> >
> > Why 4? Is that related to the number of wires?
>
> In normal operation the core clock should be running at 4x the rate of the
> transfer clock regardless of number of wires used.
Ok. Maybe add a comment so we understand that.
>
> > > + put_unaligned(rd_fifo, word_buf++);
> > > + }
> > > + ctrl->xfer.rx_buf = word_buf;
> > > + }
> > > +
> > > + if (bytes_to_read) {
> > > + byte_buf = ctrl->xfer.rx_buf;
> >
> > Does this need to move forward by words_to_read bytes so that the left
> > over bytes are tacked onto the end? Or this should be an else if
> > statement?
>
> When the words block completes it updates the rx_buf location so it is already
> at the correct offset for bytes.
>
Ok I see. Subtle!
Re: [PATCH v3 2/2] spi: Introduce new driver for Qualcomm QuadSPI controller
Quoting Ryan Case (2018-09-28 11:19:51)
> On Wed, Sep 26, 2018 at 11:43 PM Stephen Boyd wrote:
> > Quoting Ryan Case (2018-09-26 13:52:04)
> > > From: Girish Mahadevan
> > > +#include
> > > +
> > > +#define AHB_MIN_HZ 960UL
> >
> > Is this used?
>
> Nope. Do you want all currently unused defines removed or specifically this
> one? I saw precedent in other drivers for defining registers/flags/values of
> supported but unused functionality so I left these (big endian, DDR, ...).
I guess it's fine but I don't know if it will ever be used so remove it?
I'd leave the others if they help someone know what register bits exist.
That's usually how I handle it.
>
>
> > > + speed_hz = slv->max_speed_hz;
> > > + if (xfer->speed_hz)
> > > + speed_hz = xfer->speed_hz;
> > > +
> > > + ret = clk_set_rate(ctrl->clks[QSPI_CLK_CORE].clk, speed_hz * 4);
> >
> > Why 4? Is that related to the number of wires?
>
> In normal operation the core clock should be running at 4x the rate of the
> transfer clock regardless of number of wires used.
Ok. Maybe add a comment so we understand that.
>
> > > + put_unaligned(rd_fifo, word_buf++);
> > > + }
> > > + ctrl->xfer.rx_buf = word_buf;
> > > + }
> > > +
> > > + if (bytes_to_read) {
> > > + byte_buf = ctrl->xfer.rx_buf;
> >
> > Does this need to move forward by words_to_read bytes so that the left
> > over bytes are tacked onto the end? Or this should be an else if
> > statement?
>
> When the words block completes it updates the rx_buf location so it is already
> at the correct offset for bytes.
>
Ok I see. Subtle!
Re: [PATCH] regulator: core: Pass max_uV value to regulator_set_voltage_rdev
On 9/29/18 3:27 AM, Tony Lindgren wrote: > * Dmitry Osipenko [180928 23:55]: >> On 9/29/18 2:17 AM, Dmitry Osipenko wrote: >>> On 9/29/18 1:41 AM, Tony Lindgren wrote: I'm still getting these errors after init: >>> >>> Thank you very much again, seems I got what's wrong with your case. The >>> ti-abb-regulator driver sets the "abb->current_info_idx = -EINVAL" on probe >>> and that value is getting updated only after the first voltage change, >>> hence _regulator_get_voltage() returns -22. > > OK that's starting to make some sense now thanks. > >>> Please try this patch: >> >> I've revised the patch and here is the current final version. > > Hey cool this one works now :) I suggest you rework the whole series > with these fixes. I recall the series had a problem with git bisect > too between the patches. It will make life easier for other people > who may need to git bisect these patches. Awesome! There are few other things in this patchset that also need fixing. I've asked Maciej if he's going to continue working on the patches, waiting for the answer. I can pick up the patches and try to finish the work if necessary.
Re: [PATCH] regulator: core: Pass max_uV value to regulator_set_voltage_rdev
On 9/29/18 3:27 AM, Tony Lindgren wrote: > * Dmitry Osipenko [180928 23:55]: >> On 9/29/18 2:17 AM, Dmitry Osipenko wrote: >>> On 9/29/18 1:41 AM, Tony Lindgren wrote: I'm still getting these errors after init: >>> >>> Thank you very much again, seems I got what's wrong with your case. The >>> ti-abb-regulator driver sets the "abb->current_info_idx = -EINVAL" on probe >>> and that value is getting updated only after the first voltage change, >>> hence _regulator_get_voltage() returns -22. > > OK that's starting to make some sense now thanks. > >>> Please try this patch: >> >> I've revised the patch and here is the current final version. > > Hey cool this one works now :) I suggest you rework the whole series > with these fixes. I recall the series had a problem with git bisect > too between the patches. It will make life easier for other people > who may need to git bisect these patches. Awesome! There are few other things in this patchset that also need fixing. I've asked Maciej if he's going to continue working on the patches, waiting for the answer. I can pick up the patches and try to finish the work if necessary.
Hello
I have a legal business proposal worth $30.5M for you if interested reply me for more details. Regards, Ms Margaret Kwan Wing Han
Hello
I have a legal business proposal worth $30.5M for you if interested reply me for more details. Regards, Ms Margaret Kwan Wing Han
Re: [PATCH] regulator: core: Pass max_uV value to regulator_set_voltage_rdev
* Dmitry Osipenko [180928 23:55]: > On 9/29/18 2:17 AM, Dmitry Osipenko wrote: > > On 9/29/18 1:41 AM, Tony Lindgren wrote: > >> I'm still getting these errors after init: > > > > Thank you very much again, seems I got what's wrong with your case. The > > ti-abb-regulator driver sets the "abb->current_info_idx = -EINVAL" on probe > > and that value is getting updated only after the first voltage change, > > hence _regulator_get_voltage() returns -22. OK that's starting to make some sense now thanks. > > Please try this patch: > > I've revised the patch and here is the current final version. Hey cool this one works now :) I suggest you rework the whole series with these fixes. I recall the series had a problem with git bisect too between the patches. It will make life easier for other people who may need to git bisect these patches. Thanks, Tony
Re: [PATCH] regulator: core: Pass max_uV value to regulator_set_voltage_rdev
* Dmitry Osipenko [180928 23:55]: > On 9/29/18 2:17 AM, Dmitry Osipenko wrote: > > On 9/29/18 1:41 AM, Tony Lindgren wrote: > >> I'm still getting these errors after init: > > > > Thank you very much again, seems I got what's wrong with your case. The > > ti-abb-regulator driver sets the "abb->current_info_idx = -EINVAL" on probe > > and that value is getting updated only after the first voltage change, > > hence _regulator_get_voltage() returns -22. OK that's starting to make some sense now thanks. > > Please try this patch: > > I've revised the patch and here is the current final version. Hey cool this one works now :) I suggest you rework the whole series with these fixes. I recall the series had a problem with git bisect too between the patches. It will make life easier for other people who may need to git bisect these patches. Thanks, Tony
