On Mon, Oct 09, 2023 at 04:19:03PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The .ndo_do_ioctl functions are never called, and can just be removed,
> especially since this is a staging driver.
>
> Signed-off-by: Arnd Bergmann
> ---
> drivers/staging/rtl8192u/ieee80211/dot11d.c |
On Mon, Oct 09, 2023 at 04:19:04PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The .ndo_do_ioctl functions are never called, and can just be removed,
> especially since this is a staging driver.
>
> Signed-off-by: Arnd Bergmann
> ---
> drivers/staging/rtl8712/os_intfs.c|
From: Arnd Bergmann
The .ndo_do_ioctl functions are never called, and can just be removed,
especially since this is a staging driver.
Signed-off-by: Arnd Bergmann
---
drivers/staging/rtl8712/os_intfs.c| 1 -
drivers/staging/rtl8712/osdep_intf.h | 2 -
drivers/staging/r
From: Arnd Bergmann
The .ndo_do_ioctl functions are never called, and can just be removed,
especially since this is a staging driver.
Signed-off-by: Arnd Bergmann
---
drivers/staging/rtl8192u/ieee80211/dot11d.c | 41 --
drivers/staging/rtl8192u/ieee80211/dot11d.h | 2 -
.../staging/rtl8
As the legacy lru provides, the mglru needs some trace events for
debugging. Let's reuse following legacy events for the mglru.
trace_mm_vmscan_lru_isolate
trace_mm_vmscan_lru_shrink_inactive
Here's an example
mm_vmscan_lru_isolate: classzone=2 order=0 nr_requested=4096 nr_
On 9/13/23 2:10 PM, Christoph Hellwig wrote:
> Creating new a new super_block vs freeing the old one for single instance
^
I can't parse that. :-)
> file systems is serialized by the wait for SB_DEAD.
>
> Remove the superfluous sb_mutex.
>
> Signed-off-by: Christoph Hellwi
--
You might mention that this is essentially a reversion of commit
d18dcfe9860e ("USB: gadgetfs: Fix race between mounting and
unmounting").
Alan Stern
> drivers/usb/gadget/legacy/inode.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/usb/ga
Creating new a new super_block vs freeing the old one for single instance
file systems is serialized by the wait for SB_DEAD.
Remove the superfluous sb_mutex.
Signed-off-by: Christoph Hellwig
---
drivers/usb/gadget/legacy/inode.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers
On Mon, Apr 19, 2021 at 11:39:43PM -0700, Ilya Lipnitskiy wrote:
> This mostly reverts commit 99bca615d895 ("MIPS: pci-legacy: use generic
> pci_enable_resources"). Fixes regressions such as:
> ata_piix :00:0a.1: can't enable device: BAR 0 [io 0x01f0-0x01f7] not
>
This mostly reverts commit 99bca615d895 ("MIPS: pci-legacy: use generic
pci_enable_resources"). Fixes regressions such as:
ata_piix :00:0a.1: can't enable device: BAR 0 [io 0x01f0-0x01f7] not
claimed
ata_piix: probe of :00:0a.1 failed with error -22
The only c
quot; to check for resource collisions
> instead of "!r->start && r->end".
>
> That should have no effect on any pci-legacy driver.
>
Unfortunately it does. With this patch in place, all my mips qemu emulations
fail to boot from ide/ata drive; the drive
From: Linus Torvalds
[ Upstream commit 0c93ac69407d63a85be0129aa55ffaec27ffebd3 ]
This does the directory entry name verification for the legacy
"fillonedir" (and compat) interface that goes all the way back to the
dark ages before we had a proper dirent, and the readdir() system cal
From: Linus Torvalds
[ Upstream commit 0c93ac69407d63a85be0129aa55ffaec27ffebd3 ]
This does the directory entry name verification for the legacy
"fillonedir" (and compat) interface that goes all the way back to the
dark ages before we had a proper dirent, and the readdir() system cal
From: Linus Torvalds
[ Upstream commit 0c93ac69407d63a85be0129aa55ffaec27ffebd3 ]
This does the directory entry name verification for the legacy
"fillonedir" (and compat) interface that goes all the way back to the
dark ages before we had a proper dirent, and the readdir() system cal
From: Linus Torvalds
[ Upstream commit 0c93ac69407d63a85be0129aa55ffaec27ffebd3 ]
This does the directory entry name verification for the legacy
"fillonedir" (and compat) interface that goes all the way back to the
dark ages before we had a proper dirent, and the readdir() system cal
From: Linus Torvalds
[ Upstream commit 0c93ac69407d63a85be0129aa55ffaec27ffebd3 ]
This does the directory entry name verification for the legacy
"fillonedir" (and compat) interface that goes all the way back to the
dark ages before we had a proper dirent, and the readdir() system cal
From: Linus Torvalds
commit 0c93ac69407d63a85be0129aa55ffaec27ffebd3 upstream.
This does the directory entry name verification for the legacy
"fillonedir" (and compat) interface that goes all the way back to the
dark ages before we had a proper dirent, and the readdir() system cal
From: Linus Torvalds
commit 0c93ac69407d63a85be0129aa55ffaec27ffebd3 upstream.
This does the directory entry name verification for the legacy
"fillonedir" (and compat) interface that goes all the way back to the
dark ages before we had a proper dirent, and the readdir() system cal
From: Linus Torvalds
commit 0c93ac69407d63a85be0129aa55ffaec27ffebd3 upstream.
This does the directory entry name verification for the legacy
"fillonedir" (and compat) interface that goes all the way back to the
dark ages before we had a proper dirent, and the readdir() system cal
> + bool dynamic_pll;
> > +
> > + if (input_pll_index >= PLL_MAX) {
> > + dev_err(hdev->dev, "PLL index %d is out of range\n",
> > + input_pll_index);
> > + return -EINVAL;
> > +
ddress_to_pio(). Moreover, IO_SPACE_LIMIT is 0x for most MIPS
> platforms. of_pci_range_to_resource passes the _start address_ of the IO
> range into pci_address_to_pio, which then checks it against
> IO_SPACE_LIMIT and fails, because for MIPS platforms that use
> pci-legacy (pci-lantiq, pci-rt38
8):
> MIPS: pci-rt2880: fix slot 0 configuration
> MIPS: pci-rt2880: remove unneeded locks
> MIPS: pci-rt3883: trivial: remove unused variable
> MIPS: pci-rt3883: more accurate DT error messages
> MIPS: pci-legacy: stop using of_pci_range_to_resource
> MIPS: pci-legacy: remov
gt; + dev_err(hdev->dev, "PLL index %d is out of range\n",
> + input_pll_index);
> + return -EINVAL;
> + }
> +
> + dynamic_pll = prop->fw_security_status_valid &&
> +
On Wed, Apr 14, 2021 at 7:13 PM Al Cooper wrote:
>
> From: Florian Fainelli
>
> Older 32-bit only Broadcom STB chips used a NS16550A compatible UART,
> the 8250_bcm7271.c driver can drive those UARTs just fine provided that
> we let it match the appropriate compatible string.
This sounds not cor
On Wed, Apr 14, 2021 at 09:45:39AM -0400, Al Cooper wrote:
> From: Florian Fainelli
>
> Older 32-bit only Broadcom STB chips used a NS16550A compatible UART,
> the 8250_bcm7271.c driver can drive those UARTs just fine provided that
> we let it match the appropriate compatible string.
>
> Signed-
From: Florian Fainelli
Older 32-bit only Broadcom STB chips used a NS16550A compatible UART,
the 8250_bcm7271.c driver can drive those UARTs just fine provided that
we let it match the appropriate compatible string.
Signed-off-by: Florian Fainelli
Reviewed-by: Al Cooper
---
drivers/tty/serial
On Wed, 31 Mar 2021, Andy Shevchenko wrote:
> Platform data is a legacy interface to supply device properties
> to the driver. In this case we don't have anymore in-kernel users
> for it. Just remove it for good.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers
> > > Platform data is a legacy interface to supply device properties
> > > to the driver. In this case we don't have anymore in-kernel users
> > > for it. Just remove it for good.
> > >
> > > Signed-off-by: Andy Shevchenko
> >
>
On Tue, 06 Apr 2021, Wolfram Sang wrote:
> On Wed, Mar 31, 2021 at 06:48:51PM +0300, Andy Shevchenko wrote:
> > Platform data is a legacy interface to supply device properties
> > to the driver. In this case we don't have anymore in-kernel users
> > for i
Remove the following pci-legacy message:
PCI host bridge /pci@44/host-bridge ranges:
MEM 0x2000..0x2fff
IO 0x0046..0x0046
It is followed shortly by the same data from pci_register_host_bridge:
PCI host bridge to bus :00
pci_bus
d".
That should have no effect on any pci-legacy driver.
Suggested-by: Bjorn Helgaas
Signed-off-by: Ilya Lipnitskiy
---
arch/mips/pci/pci-legacy.c | 40 ++
1 file changed, 2 insertions(+), 38 deletions(-)
diff --git a/arch/mips/pci/pci-legacy.c
No drivers set the busn_resource field in the pci_controller struct.
Commit 7ee214b540d9 ("MIPS: PCI: Remove unused busn_offset") almost
removed it over 3 years ago. Remove it for good to free up memory and
eliminate messages like:
pci_bus :00: root bus resource [??? 0x flags 0x0]
Si
the _start address_ of the IO
range into pci_address_to_pio, which then checks it against
IO_SPACE_LIMIT and fails, because for MIPS platforms that use
pci-legacy (pci-lantiq, pci-rt3883, pci-mt7620), IO ranges start much
higher than 0x.
In fact, pci-mt7621 in staging already works around this pr
variable
MIPS: pci-rt3883: more accurate DT error messages
MIPS: pci-legacy: stop using of_pci_range_to_resource
MIPS: pci-legacy: remove redundant info messages
MIPS: pci-legacy: remove busn_resource field
MIPS: pci-legacy: use generic pci_enable_resources
arch/mips/include/asm/pci.h
the _start address_ of the IO
range into pci_address_to_pio, which then checks it against
IO_SPACE_LIMIT and fails, because for MIPS platforms that use
pci-legacy (pci-lantiq, pci-rt3883, pci-mt7620), IO ranges start much
higher than 0x.
In fact, pci-mt7621 in staging already works around this pr
d".
That should have no effect on any pci-legacy driver.
Suggested-by: Bjorn Helgaas
Signed-off-by: Ilya Lipnitskiy
---
arch/mips/pci/pci-legacy.c | 40 ++
1 file changed, 2 insertions(+), 38 deletions(-)
diff --git a/arch/mips/pci/pci-legacy.c
No drivers set the busn_resource field in the pci_controller struct.
Commit 7ee214b540d9 ("MIPS: PCI: Remove unused busn_offset") almost
removed it over 3 years ago. Remove it for good to free up memory and
eliminate messages like:
pci_bus :00: root bus resource [??? 0x flags 0x0]
Si
Remove the following pci-legacy message:
PCI host bridge /pci@44/host-bridge ranges:
MEM 0x2000..0x2fff
IO 0x0046..0x0046
It is followed shortly by the same data from pci_register_host_bridge:
PCI host bridge to bus :00
pci_bus
configuration
MIPS: pci-rt2880: remove unneeded locks
MIPS: pci-rt3883: trivial: remove unused variable
MIPS: pci-rt3883: more accurate DT error messages
MIPS: pci-legacy: stop using of_pci_range_to_resource
MIPS: pci-legacy: remove redundant info messages
MIPS: pci-legacy: remove busn_resource
gt; > >
> > > On Wed, Jan 06, 2021 at 02:55:40PM +0100, Martin Blumenstingl wrote:
> > > > The legacy PCI interrupt lines need to be enabled using PCIE_APP_IRNEN
> > > > bits 13 (INTA), 14 (INTB), 15 (INTC) and 16 (INTD). The old code
> &g
On 9/4/2021 4:40 am, Martin Blumenstingl wrote:
> This email was sent from outside of MaxLinear.
>
> Hi Lorenzo,
>
> On Tue, Mar 23, 2021 at 12:36 PM Lorenzo Pieralisi
> wrote:
> >
> > On Wed, Jan 06, 2021 at 02:55:40PM +0100, Martin Blumenstingl wrote:
> &
Quoting Stephan Gerhold (2021-04-08 00:19:44)
> Personally, I think it would be best to introduce a new, SMC64 only
> compatible (e.g. "qcom,scm-64" like I mentioned). Then you can skip the
> detection check for the boards that opt-in by adding the compatible.
> You can then use it on all newer boa
Hi Lorenzo,
On Tue, Mar 23, 2021 at 12:36 PM Lorenzo Pieralisi
wrote:
>
> On Wed, Jan 06, 2021 at 02:55:40PM +0100, Martin Blumenstingl wrote:
> > The legacy PCI interrupt lines need to be enabled using PCIE_APP_IRNEN
> > bits 13 (INTA), 14 (INTB), 15 (INTC) and 16 (INTD). Th
etection so far. I suppose you could do the opposite,
> > add an optional qcom,scm-64 to skip the detection step and force SMC64.
>
> Isn't SMC64 going to be the overall majority going forward? Legacy
> convention is for sure limited to CONFIG_ARM so I'll send another
&
94 also uses SMC32 from what I heard. Overall it's
> probably quite hard to get that right now since all boards were tested
> with the dynamic detection so far. I suppose you could do the opposite,
> add an optional qcom,scm-64 to skip the detection step and force SMC64.
Isn't SMC6
The TIOCGSERIAL ioctl can be used to set and retrieve the UART type for
legacy UARTs, but some USB serial drivers have been reporting back
random types in order to "make user-space happy".
Some applications have historically expected TIOCGSERIAL to be
implemented, but judging from
On 4/6/21 1:49 PM, Wolfram Sang wrote:
On Wed, Mar 31, 2021 at 06:48:51PM +0300, Andy Shevchenko wrote:
Platform data is a legacy interface to supply device properties
to the driver. In this case we don't have anymore in-kernel users
for it. Just remove it for good.
Signed-off-by:
On Wed, Mar 31, 2021 at 06:48:51PM +0300, Andy Shevchenko wrote:
> Platform data is a legacy interface to supply device properties
> to the driver. In this case we don't have anymore in-kernel users
> for it. Just remove it for good.
>
> Signed-off-by: Andy Shevchenko
Ac
source and force
> > > arm64 calling convention to be safe? I'm thinking of this patch, but it
> > > could be even more fine tuned and probably the sc7180 check could be
> > > removed in the process if the rest of this email makes sense.
> > >
> > > If I u
D(CONFIG_ARM), and the corresponding ones in
> > > qcom_scm_call_atomic:
> > >
> > >case SMC_CONVENTION_LEGACY:
> > >return scm_legacy_call(dev, desc, res);
> > >
> > > If something is wrong with loaded firmware and LEGAC
On Thu, 25 Mar 2021 09:00:25 +,
Kishon Vijay Abraham I wrote:
>
> Add PCI legacy interrupt support for AM654. AM654 has a single HW
> interrupt line for all the four legacy interrupts INTA/INTB/INTC/INTD.
> The HW interrupt line connected to GIC is a pulse interrupt whereas
mic:
> >
> >case SMC_CONVENTION_LEGACY:
> >return scm_legacy_call(dev, desc, res);
> >
> > If something is wrong with loaded firmware and LEGACY convention is
> > incorrectly selected, you would get a better hint about the problem:
> > "U
esc, res);
>
> If something is wrong with loaded firmware and LEGACY convention is
> incorrectly selected, you would get a better hint about the problem:
> "Unknown current SCM calling convention." You would still get the hint
> earlier from __get_convention, but that may n
On 3/23/2021 3:43 PM, Stephen Boyd wrote:
These scm calls are never used outside of legacy ARMv7 based platforms.
That's because PSCI, mandated on arm64, implements them for modern SoCs
via the PSCI spec. Let's move them to the legacy file and only compile
the legacy file into the k
On Tue 23 Mar 17:43 CDT 2021, Stephen Boyd wrote:
> These scm calls are never used outside of legacy ARMv7 based platforms.
> That's because PSCI, mandated on arm64, implements them for modern SoCs
> via the PSCI spec. Let's move them to the legacy file and only compile
> th
Quoting Stephen Boyd (2021-03-23 15:43:36)
> These scm calls are never used outside of legacy ARMv7 based platforms.
> That's because PSCI, mandated on arm64, implements them for modern SoCs
> via the PSCI spec. Let's move them to the legacy file and only compile
> the legac
Platform data is a legacy interface to supply device properties
to the driver. In this case we don't have anymore in-kernel users
for it. Just remove it for good.
Signed-off-by: Andy Shevchenko
---
drivers/i2c/busses/i2c-designware-platdrv.c | 7 +--
include/linux/platform_dat
From: Tony Lindgren
[ Upstream commit fbfa463be8dc7957ee4f81556e9e1ea2a951807d ]
When I dropped legacy data for omap4 and dra7 smartreflex in favor of
device tree based data, it seems I only testd for the "SmartReflex Class3
initialized" line in dmesg. I missed the fact that the
From: Tony Lindgren
[ Upstream commit fbfa463be8dc7957ee4f81556e9e1ea2a951807d ]
When I dropped legacy data for omap4 and dra7 smartreflex in favor of
device tree based data, it seems I only testd for the "SmartReflex Class3
initialized" line in dmesg. I missed the fact that the
Hi Kishon,
[...]
> + if (!legacy_irq_domain) {
> + dev_err(dev, "Failed to add irq domain for legacy irqs\n");
> + return -EINVAL;
> + }
[...]
It would be "IRQ" and "IRQs" in the message above.
[...]
> - ret = k
Hi Kishon,
Thank you for sending the series over!
A few small nitpick, so feel free to ignore it.
[...]
> + ret = irq_domain_alloc_irqs_parent(domain, virq, 1, &parent_fwspec);
> + if (ret < 0) {
> + pr_err("Failed to allocate parent irq %u: %d\n",
> +pare
Place the onus on the caller of slot_handle_*() to flush the TLB, rather
than handling the flush in the helper, and rename parameters accordingly.
This will allow future patches to coalesce flushes between address spaces
and between the legacy and TDP MMUs.
No functional change intended.
Signed
I'd promote J721E earlier in subject so it doesn't get truncated, e.g.,
PCI: j721e: Add J721E PCI legacy interrupt support
On Thu, Mar 25, 2021 at 02:39:34PM +0530, Kishon Vijay Abraham I wrote:
> +static void j721e_pcie_legacy_irq_handler(struct irq_desc *desc)
>
On Thu, 25 Mar 2021 14:39:33 +0530, Kishon Vijay Abraham I wrote:
> Add bindings to specify interrupt controller for legacy interrupts.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> .../devicetree/bindings/pci/ti,j721e-pci-host.yaml | 13 +
> 1 file chan
Add PCI legacy interrupt support for J721E. J721E has a single HW
interrupt line for all the four legacy interrupts INTA/INTB/INTC/INTD.
The HW interrupt line connected to GIC is a pulse interrupt whereas
the legacy interrupts by definition is level interrupt. In order to
provide level interrupt
Patch series adds support for legacy interrupt in pci-j721e. There are
two HW implementations of legacy interrupt controller, one specific to
J721E and the other for J7200/AM64.
In both these implementations, the legacy interrupt is connect to pulse
interrupt of GIC and level to pulse is handled
Add bindings to specify interrupt controller for legacy interrupts.
Signed-off-by: Kishon Vijay Abraham I
---
.../devicetree/bindings/pci/ti,j721e-pci-host.yaml | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
b
K2G provides separate IRQ lines for each of the four legacy interrupts.
Model this using hierarchy domain instead of linear domain with chained
IRQ handler.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/pci/controller/dwc/pci-keystone.c | 214 --
1 file changed, 120
Add PCI legacy interrupt support for AM654. AM654 has a single HW
interrupt line for all the four legacy interrupts INTA/INTB/INTC/INTD.
The HW interrupt line connected to GIC is a pulse interrupt whereas
the legacy interrupts by definition is level interrupt. In order to
provide level interrupt
Keystone driver is used by K2G and AM65 and the interrupt handling of
both of them is different. Add support to handle legacy interrupt for
both K2G and AM65 here.
Some discussions regarding this was already done here [1] and it was
around having pulse interrupt for legacy interrupt.
The HW
The behavior of the SEV-legacy commands is altered when the SNP firmware
is in the INIT state. When SNP is in INIT state, all the SEV-legacy
commands that cause the firmware to write to memory must be in the
firmware state before issuing the command..
See SEV-SNP spec section 5.3.7 for more
On Thu, Mar 18, 2021 at 05:57:01AM +0100, Christoph Hellwig wrote:
> Use libata instead of the deprecated legacy ide driver in
> workpad_defconfig.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/mips/configs/workpad_defconfig | 9 ++---
> 1 file changed, 6 inser
These scm calls are never used outside of legacy ARMv7 based platforms.
That's because PSCI, mandated on arm64, implements them for modern SoCs
via the PSCI spec. Let's move them to the legacy file and only compile
the legacy file into the kernel when CONFIG_ARM=y. Otherwise provide
stub
On Tue 23 Mar 13:27 CDT 2021, Elliot Berman wrote:
> On 3/22/2021 8:36 PM, Stephen Boyd wrote:
> > Quoting Bjorn Andersson (2021-03-07 09:42:45)
> > > On Sat 06 Mar 00:18 CST 2021, Stephen Boyd wrote:
> > >
> > > > Quoting Elliot Berman (2021-03-05 10:18:09)
> > > > > On 3/3/2021 10:14 PM, Stephe
On 3/22/2021 8:36 PM, Stephen Boyd wrote:
Quoting Bjorn Andersson (2021-03-07 09:42:45)
On Sat 06 Mar 00:18 CST 2021, Stephen Boyd wrote:
Quoting Elliot Berman (2021-03-05 10:18:09)
On 3/3/2021 10:14 PM, Stephen Boyd wrote:
Quoting Elliot Berman (2021-03-03 19:35:08)
> +desc.args[0]
.
---
drivers/usb/gadget/legacy/mass_storage.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/legacy/mass_storage.c
b/drivers/usb/gadget/legacy/mass_storage.c
index 9ed22c5fb7fe..ac1741126619 100644
--- a/drivers/usb/gadget/legacy/mass_storage.c
+++ b/drivers/usb
On 2021/3/23 19:35, Greg KH wrote:
On Sun, Mar 07, 2021 at 12:49:15AM -0800, Jia-Ju Bai wrote:
When usb_otg_descriptor_alloc() returns NULL to usb_desc, no error
return code of msg_bind() is assigned.
To fix this bug, status is assigned with -ENOMEM in this case.
Reported-by: TOTE Robot >
T
On Wed, Jan 06, 2021 at 02:55:40PM +0100, Martin Blumenstingl wrote:
> The legacy PCI interrupt lines need to be enabled using PCIE_APP_IRNEN
> bits 13 (INTA), 14 (INTB), 15 (INTC) and 16 (INTD). The old code however
> was taking (for example) "13" as raw value instead of takin
On Sun, Mar 07, 2021 at 12:52:19AM -0800, Jia-Ju Bai wrote:
> When usb_otg_descriptor_alloc() returns NULL to usb_desc, no error
> return code of msg_bind() is assigned.
> To fix this bug, status is assigned with -ENOMEM in this case.
>
> Reported-by: TOTE Robot >
You have 2 '>' on the end of thi
On Sun, Mar 07, 2021 at 12:49:15AM -0800, Jia-Ju Bai wrote:
> When usb_otg_descriptor_alloc() returns NULL to usb_desc, no error
> return code of msg_bind() is assigned.
> To fix this bug, status is assigned with -ENOMEM in this case.
>
> Reported-by: TOTE Robot Reported-by: TOTE Robot >
These l
it is safe.
Signed-off-by: Rasmus Villemoes
---
drivers/usb/gadget/legacy/multi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/legacy/multi.c
b/drivers/usb/gadget/legacy/multi.c
index ec9749845660..f6d0782e6fc3 100644
--- a/drivers/usb/gadg
Quoting Bjorn Andersson (2021-03-07 09:42:45)
> On Sat 06 Mar 00:18 CST 2021, Stephen Boyd wrote:
>
> > Quoting Elliot Berman (2021-03-05 10:18:09)
> > > On 3/3/2021 10:14 PM, Stephen Boyd wrote:
> > > > Quoting Elliot Berman (2021-03-03 19:35:08)
> > >
> > > > +desc.args[0] = flags;
> > >
d &&
+ (prop->fw_app_security_map & CPU_BOOT_DEV_STS0_DYN_PLL_EN);
+
+ if (!dynamic_pll) {
+ /*
+ * in case we are working with legacy FW (each asic has unique
+ * PLL numbering) extract the legacy numbering
+*/
+
Hello Christoph!
On 3/18/21 5:56 AM, Christoph Hellwig wrote:
> libata mostly covers all hardware supported by the legacy ide driver.
> There are three mips drivers that are not supported, but the linux-mips
> list could not identify any users of those. There also are two m68k
> dri
On Sat, 20 Mar 2021, Maciej W. Rozycki wrote:
> > been scheduled for removal for a while. Finally kill it off so that we
> > can start cleaning up various bits of cruft it forced on the block layer.
>
> You need to adjust Documentation/admin-guide/kernel-parameters.txt too,
> i.e. remove all t
On Thu, 18 Mar 2021, Christoph Hellwig wrote:
> The legay ide driver has been replace with libata startin in 2003 and has
s/legay/legacy/;s/replace/replaced/;s/startin/startin/ (though I'd say
"back in" instead in the latter case).
> been scheduled for removal for a wh
provides an easy way out in future where we can remove the
legacy driver.
Signed-off-by: Atish Patra
---
drivers/perf/Kconfig| 9
drivers/perf/Makefile | 3 ++
drivers/perf/riscv_pmu.c| 2 +
drivers/perf/riscv_pmu_legacy.c | 88
On Thu, 18 Mar 2021, Christoph Hellwig wrote:
> we've been trying to get rid of the legacy ide driver for a while now,
> and finally scheduled a removal for 2021, which is three month old now.
Hmm, there's still a regression in that pata_legacy unconditionally pokes
at
Al Viro writes:
> ...
>
> Do you have reports of libata variants of drivers actually tested on
> those?
PATA_CMD64X works fine on my 164LX for many years, last tested with 5.12-rc3.
(with a caveat: in my setup with CF card DMA is broken, but it is broken
with BLK_DEV_CMD64X as well).
On Fri, Mar 19, 2021 at 12:43:48PM +1100, Finn Thain wrote:
> A few months ago I wrote another patch to move some more platforms away
> from macide but it has not been tested yet. That is not to say you should
> wait. However, my patch does have some changes that are missing from your
> patch se
On Thu, 18 Mar 2021, Christoph Hellwig wrote:
> Hi all,
>
> we've been trying to get rid of the legacy ide driver for a while now,
> and finally scheduled a removal for 2021, which is three month old now.
>
> In general distros and most defconfigs have switched to libat
Måns Rullgård writes:
> Christoph Hellwig writes:
>
>> On Thu, Mar 18, 2021 at 05:54:55AM +, Al Viro wrote:
>>> On Thu, Mar 18, 2021 at 05:56:57AM +0100, Christoph Hellwig wrote:
>>> > Switch the alpha defconfig from the legacy ide driver to libata.
>
Christoph Hellwig writes:
> On Thu, Mar 18, 2021 at 05:54:55AM +, Al Viro wrote:
>> On Thu, Mar 18, 2021 at 05:56:57AM +0100, Christoph Hellwig wrote:
>> > Switch the alpha defconfig from the legacy ide driver to libata.
>>
>> Umm... I don't have an IDE a
Platform data is a legacy interface to supply device properties
to the driver. In this case we even don't have in-kernel users
for it. Just remove it for good.
Signed-off-by: Andy Shevchenko
Acked-by: Rodolfo Giometti
---
drivers/pps/clients/pps-gpio.c | 17 +++--
include/linu
On Thu, Mar 18 2021 at 09:29, Vitaly Kuznetsov wrote:
> Thomas Gleixner writes:
>> Out of paranoia I'd rather ignore that IO/APIC pin completely if it
>> claims to be IRQ2. I assume there is no device connected to it at all,
>> right?
>
> The original issue was observed on Amazon's r5d.xlarge inst
Thomas Gleixner writes:
> On Wed, Mar 17 2021 at 22:40, Thomas Gleixner wrote:
>> af174783b925 ("x86: I/O APIC: Never configure IRQ2")
>>
>> has a very nice explanation why.
>>
>> Back then the logic was quite different. All legacy PIC interrupts
&g
located in irq_matrix and think that
>> there are too many vectors require re-assigning.
>>
>> The problem turns to be: lapic_assign_system_vectors() called from
>> native_init_IRQ() makes an exception for PIC_CASCADE_IR and doesn't
>> mark it in irq_matrix. Later,
Hi Al!
On 3/18/21 6:54 AM, Al Viro wrote:
> On Thu, Mar 18, 2021 at 05:56:57AM +0100, Christoph Hellwig wrote:
>> Switch the alpha defconfig from the legacy ide driver to libata.
>
> Umm... I don't have an IDE alpha box in a usable shape (fans on
> CPU module shat themsel
On Thu, Mar 18, 2021 at 05:54:55AM +, Al Viro wrote:
> On Thu, Mar 18, 2021 at 05:56:57AM +0100, Christoph Hellwig wrote:
> > Switch the alpha defconfig from the legacy ide driver to libata.
>
> Umm... I don't have an IDE alpha box in a usable shape (fans on
> CPU
On Thu, Mar 18, 2021 at 05:56:57AM +0100, Christoph Hellwig wrote:
> Switch the alpha defconfig from the legacy ide driver to libata.
Umm... I don't have an IDE alpha box in a usable shape (fans on
CPU module shat themselves), and it would take a while to resurrect
it, but I remember th
1 - 100 of 1935 matches
Mail list logo
