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.
>
river works fine on my UP1500 machine, unless something
broke recently. I'll build the latest kernel and report back.
--
Måns Rullgård
roduces some kind of
error. How is it breaking anything to not create device nodes for
hardware that doesn't exist?
--
Måns Rullgård
Greg Kroah-Hartman writes:
> On Sun, Jan 31, 2021 at 01:18:47PM +0000, Måns Rullgård wrote:
>> Greg Kroah-Hartman writes:
>>
>> > On Thu, Jan 28, 2021 at 05:22:44PM +, Mans Rullgard wrote:
>> >> On systems that do not have the traditional PC ISA seria
used by this?
There won't be /dev/ttyS devices for ports that don't exist.
> Will ports get renumbered?
Not if they had predictable numbers to begin with.
> What harm is this causing systems today without this change?
It means I have to somehow maintain a separate list of which ports are
real and which should be ignored, or else try to distinguish real errors
from those caused by trying to access the bogus ports.
--
Måns Rullgård
> - .compatible = "sigma,smp8759-pcie",
> - .data = &smp8759_ecam_ops,
> - },
> - { },
> -};
> -
> -static struct platform_driver tango_pcie_driver = {
> - .probe = tango_pcie_probe,
> - .driver = {
> - .name = KBUILD_MODNAME,
> - .of_match_table = tango_pcie_ids,
> - .suppress_bind_attrs = true,
> - },
> -};
> -builtin_platform_driver(tango_pcie_driver);
> -
> -/*
> - * The root complex advertises the wrong device class.
> - * Header Type 1 is for PCI-to-PCI bridges.
> - */
> -static void tango_fixup_class(struct pci_dev *dev)
> -{
> - dev->class = PCI_CLASS_BRIDGE_PCI << 8;
> -}
> -DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SIGMA, 0x0024, tango_fixup_class);
> -DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SIGMA, 0x0028, tango_fixup_class);
> -
> -/*
> - * The root complex exposes a "fake" BAR, which is used to filter
> - * bus-to-system accesses. Only accesses within the range defined by this
> - * BAR are forwarded to the host, others are ignored.
> - *
> - * By default, the DMA framework expects an identity mapping, and DRAM0 is
> - * mapped at 0x8000.
> - */
> -static void tango_fixup_bar(struct pci_dev *dev)
> -{
> - dev->non_compliant_bars = true;
> - pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, 0x8000);
> -}
> -DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SIGMA, 0x0024, tango_fixup_bar);
> -DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SIGMA, 0x0028, tango_fixup_bar);
> --
>
> 2.29.2
>
--
Måns Rullgård
c int __maybe_unused tango_thermal_resume(struct device *dev)
> -{
> - tango_thermal_init(dev_get_drvdata(dev));
> - return 0;
> -}
> -
> -static SIMPLE_DEV_PM_OPS(tango_thermal_pm, NULL, tango_thermal_resume);
> -
> -static const struct of_device_id tango_sensor_ids[] = {
> - {
> - .compatible = "sigma,smp8758-thermal",
> - },
> - { /* sentinel */ }
> -};
> -MODULE_DEVICE_TABLE(of, tango_sensor_ids);
> -
> -static struct platform_driver tango_thermal_driver = {
> - .probe = tango_thermal_probe,
> - .driver = {
> - .name = "tango-thermal",
> - .of_match_table = tango_sensor_ids,
> - .pm = &tango_thermal_pm,
> - },
> -};
> -
> -module_platform_driver(tango_thermal_driver);
> -
> -MODULE_LICENSE("GPL");
> -MODULE_AUTHOR("Sigma Designs");
> -MODULE_DESCRIPTION("Tango temperature sensor");
> --
>
> 2.29.2
>
--
Måns Rullgård
; - if (readl(dev->base + WD_COUNTER)) {
> - set_bit(WDOG_HW_RUNNING, &dev->wdt.status);
> - tangox_wdt_start(&dev->wdt);
> - }
> -
> - watchdog_set_restart_priority(&dev->wdt, 128);
> -
> - watchdog_stop_on_unregi
Arnd Bergmann writes:
> From: Arnd Bergmann
>
> The tango4 platform is getting removed, and this driver has no
> other known users, so it can be removed.
>
> Cc: Marc Gonzalez
> Cc: Mans Rullgard
> Signed-off-by: Arnd Bergmann
Acked-by: Mans Rullgard
> ---
> drivers/net/ethernet/Kconfig
v, RC6_CARRIER);
> -
> - writel_relaxed(ACK_RC6_INT, ir->rc6_base + RC6_CTRL);
> - writel_relaxed((clkdiv >> 2) << 18 | clkdiv, ir->rc6_base + RC6_CLKDIV);
> -
> - err = devm_request_irq(dev, irq, tango_ir_irq, IRQF_SHARED,
> -dev_name(dev), ir);
> - if (err)
> - goto err_clk;
> -
> - err = devm_rc_register_device(dev, rc);
> - if (err)
> - goto err_clk;
> -
> - platform_set_drvdata(pdev, ir);
> - return 0;
> -
> -err_clk:
> - clk_disable_unprepare(ir->clk);
> - return err;
> -}
> -
> -static int tango_ir_remove(struct platform_device *pdev)
> -{
> - struct tango_ir *ir = platform_get_drvdata(pdev);
> -
> - clk_disable_unprepare(ir->clk);
> - return 0;
> -}
> -
> -static const struct of_device_id tango_ir_dt_ids[] = {
> - { .compatible = "sigma,smp8642-ir" },
> - { }
> -};
> -MODULE_DEVICE_TABLE(of, tango_ir_dt_ids);
> -
> -static struct platform_driver tango_ir_driver = {
> - .probe = tango_ir_probe,
> - .remove = tango_ir_remove,
> - .driver = {
> - .name = DRIVER_NAME,
> - .of_match_table = tango_ir_dt_ids,
> - },
> -};
> -module_platform_driver(tango_ir_driver);
> -
> -MODULE_DESCRIPTION("SMP86xx IR decoder driver");
> -MODULE_AUTHOR("Mans Rullgard ");
> -MODULE_LICENSE("GPL");
> --
>
> 2.29.2
>
--
Måns Rullgård
failed to get IRQ", node);
> -
> - err = of_address_to_resource(node, 0, &res);
> - if (err)
> - panic("%pOFn: failed to get address", node);
> -
> - chip = kzalloc(sizeof(*chip), GFP_KERNEL);
> - chip->ctl = res.start - baseres->start;
> - chip->base = base;
> -
> - dom = irq_domain_add_linear(node, 64, &irq_generic_chip_ops, chip);
> - if (!dom)
> - panic("%pOFn: failed to create irqdomain", node);
> -
> - err = irq_alloc_domain_generic_chips(dom, 32, 2, node->name,
> - handle_level_irq, 0, 0, 0);
> - if (err)
> - panic("%pOFn: failed to allocate irqchip", node);
> -
> - tangox_irq_domain_init(dom);
> -
> - irq_set_chained_handler_and_data(irq, tangox_irq_handler, dom);
> -
> - return 0;
> -}
> -
> -static int __init tangox_of_irq_init(struct device_node *node,
> - struct device_node *parent)
> -{
> - struct device_node *c;
> - struct resource res;
> - void __iomem *base;
> -
> - base = of_iomap(node, 0);
> - if (!base)
> - panic("%pOFn: of_iomap failed", node);
> -
> - of_address_to_resource(node, 0, &res);
> -
> - for_each_child_of_node(node, c)
> - tangox_irq_init(base, &res, c);
> -
> - return 0;
> -}
> -IRQCHIP_DECLARE(tangox_intc, "sigma,smp8642-intc", tangox_of_irq_init);
> --
>
> 2.29.2
>
--
Måns Rullgård
ot;, xtal_freq, 350,
> - 32, clocksource_mmio_readl_up);
> - if (ret) {
> - pr_err("%pOF: registration failed\n", np);
> - return ret;
> - }
> -
> - sched_clock_register(read_sched_clock, 32, xtal_freq);
> - register_current_timer_delay(&delay_timer);
> -
> - return 0;
> -}
> -
> -TIMER_OF_DECLARE(tango, "sigma,tick-counter", tango_clocksource_init);
> --
>
> 2.29.2
>
--
Måns Rullgård
e tango3 and tango4 boards.
>
> Waiting for his take on the matter.
>
> I can point out some device-specific drivers that would become
> useless if tango support were dropped.
I have tango3 and tango4 boards. Can't say I'm using them for anything,
though. With the entire platform dead at the vendor level, removal
seems like a reasonable choice.
--
Måns Rullgård
t;;
> reg = <0x2010 0x1000>;
> cache-level = <2>;
> --
> 2.17.1
>
--
Måns Rullgård
ned long reg;
>
> reg = readl(hdmi->base + SUN4I_HDMI_HPD_REG);
> - if (reg & SUN4I_HDMI_HPD_HIGH) {
> + if (!(reg & SUN4I_HDMI_HPD_HIGH)) {
> cec_phys_addr_invalidate(hdmi->cec_adap);
> return connector_status_disconnected;
> }
> --
> 2.27.0
>
--
Måns Rullgård
"Invalid block size returned: %d\n",
>> +msg[1].buf[0]);
>> +status = -EINVAL;
>
> I changed this to -EPROTO as described in
> Documentation/i2c/fault-codes.rst.
>
> Applied to for-current, thanks!
>
--
Måns Rullgård
t;;
> reg = <0x2010 0x1000>;
> cache-level = <2>;
> --
> 2.17.1
>
--
Måns Rullgård
_resource(dev, rc6_res);
> + ir->rc6_base = devm_platform_ioremap_resource(pdev, 1);
> if (IS_ERR(ir->rc6_base))
> return PTR_ERR(ir->rc6_base);
>
> --
> 2.23.0
>
--
Måns Rullgård
ruct platform_device *pdev)
> if (!priv)
> return -ENOMEM;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - priv->base = devm_ioremap_resource(&pdev->dev, res);
> + priv->base = devm_platform_ioremap_resource(pdev, 0);
>
ls,
the system will not work anyway.
- Replace the panic() calls with error returns and check the return
value in tangox_of_irq_init(). The system will still end up unusable.
--
Måns Rullgård
= "musb-hdrc";
> pinfo.id= PLATFORM_DEVID_AUTO;
> pinfo.parent= &pdev->dev;
> + pinfo.fwnode= of_fwnode_handle(pdev->dev.of_node);
> + pinfo.of_node_reused = true;
> pinfo.res = pdev->resource;
> pinfo.num_res = pdev->num_resources;
> pinfo.data = &pdata;
> --
> 2.20.1
>
--
Måns Rullgård
Marek Szyprowski writes:
> Hi Måns
>
> On 2019-05-21 15:30, Måns Rullgård wrote:
>> Marek Szyprowski writes:
>>> Dear All,
>>>
>>> Commit 69bec7259853 ("USB: core: let USB device know device node") added
>>> support for attaching dev
; conflict"), but it disabled support for USB device binding for Exynos
> EHCI/OHCI controllers.
>
> This patchset tries to resolve this binding conflict by changing Exynos
> EHCI/OHCI bindings: PHYs are moved from the sub-nodes to a standard array
> under the 'phys' pro
Marek Szyprowski writes:
> Hi
>
> On 2019-05-08 13:46, Måns Rullgård wrote:
>> Marek Szyprowski writes:
>>> Commit 01fdf179f4b0 ("usb: core: skip interfaces disabled in devicetree")
>>> add support for disabling given USB device interface by adding
ta(pdev);
> -
> - tangox_wdt_stop(&dev->wdt);
> - clk_disable_unprepare(dev->clk);
> -
> - watchdog_unregister_device(&dev->wdt);
> -
> - return 0;
> }
>
> static const struct of_device_id tangox_wdt_dt_ids[] = {
> @@ -204,7 +196,6 @@ MODULE_DEVICE_TABLE(of, tangox_wdt_dt_ids);
>
> static struct platform_driver tangox_wdt_driver = {
> .probe = tangox_wdt_probe,
> - .remove = tangox_wdt_remove,
> .driver = {
> .name = "tangox-wdt",
> .of_match_table = tangox_wdt_dt_ids,
> --
> 2.7.4
>
--
Måns Rullgård
gt; stmfd sp!, {r4-r11, lr}
> smc #0
[...]
> diff --git a/arch/arm/mach-tango/smc.S b/arch/arm/mach-tango/smc.S
> index 361a8dc89804..cf2d21e5226c 100644
> --- a/arch/arm/mach-tango/smc.S
> +++ b/arch/arm/mach-tango/smc.S
> @@ -1,6 +1,7 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> #include
>
> + .arch_extension sec
> ENTRY(tango_smc)
> push{lr}
> mov ip, r1
Is there some reason these three don't need the .arch directive?
--
Måns Rullgård
b/arch/arm/mach-tango/smc.S
> @@ -1,6 +1,7 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> #include
>
> + .arch_extension sec
> ENTRY(tango_smc)
> push{lr}
> mov ip, r1
For Tango:
Acked-by: Mans Rullgard
--
Måns Rullgård
Maxime Ripard writes:
> On Thu, Mar 14, 2019 at 04:09:13PM +0000, Måns Rullgård wrote:
>> Maxime Ripard writes:
>>
>> > On Mon, Mar 11, 2019 at 04:11:06PM +, Måns Rullgård wrote:
>> >> Maxime Ripard writes:
>> >>
>> >> > Hi!
Miguel Ojeda writes:
> On Tue, Mar 12, 2019 at 4:48 PM Måns Rullgård wrote:
>>
>> The current code unconditionally flashes the light once. I though it
>> best to keep that behaviour as default, even if it's not seen as ideal.
>
> Sent into -next. If no one els
t boards
> with different SoC's. I have a couple of SD cards with various rootfs
> and use internal eMMC boot quite often as well. Remembering which board
> uses which numbering is a pain. Maintaining a patch is just easier...
> Furthermore, U-Boot allows reordering and all boards I deal with use mmc
> 0 for the internal eMMC. The aliases allow consistency.
Since pretty much every other device type supports renumbering with DT
aliases, it would make sense to do this for mmc as well.
--
Måns Rullgård
r
> off, not flashing for sure.
> Though it seems the case before the patch...
The current code unconditionally flashes the light once. I though it
best to keep that behaviour as default, even if it's not seen as ideal.
--
Måns Rullgård
g this marking).
The option is there so 'make oldconfig' on existing configurations
doesn't silently drop that driver since it now depends on AUXDISPLAY.
There have been similar cases when shuffling options. Maybe they used a
different tag. We could of course let the three people using that
driver deal with it themselves.
>> + depends on PARPORT
>> + select AUXDISPLAY
>> + select PARPORT_PANEL
>
> I agree the menu was a bit convoluted and we didn't get to clean it.
>
> Since you are touching the panel.c options, CC'ing the maintainers
> (please do run get_maintainer.pl in that case!)
I always run get_maintainer.pl on patches. Sometimes it isn't clever
enough to figure out all the people who might be interested.
--
Måns Rullgård
you mind if I change
> it before sending it to linux-next? Otherwise, looks fine to me.
> Thanks!
Of course I don't mind.
--
Måns Rullgård
an option for multiple reasons:
- We have two rootfs partitions for ping-pong updates, so simply
referring to "the thing with ID foo" doesn't work.
- Installing said updates needs direct access the device/partition,
which may not even have a filesystem.
- The u-boot environment is stored in an eMMC "boot" partition, and
userspace needs to know where to find it.
I'm sure I'm not the only one in a similar situation.
Russel, feel free to shout abuse at me. I don't care, but it makes you
look stupid.
--
Måns Rullgård
> num_pkts < quota) {
> mbx_mask = BIT(priv->rx_next); /* next rx mailbox to process */
> --
> 2.7.4
This seems to have been lost or forgotten.
--
Måns Rullgård
RCE_MEM, 1);
>> ...
>> rc = davinci_emac_try_get_mac(pdev, res_ctrl ? 0 : 1,
>> priv->mac_addr);
>>
>> So it there are two ranges, the slave param becomes 0. It there is only one,
>> it
>> will be 1. Since the am3517 only has a single regs entry it ends up with
>> slave 1,
>> while there is only a single davinci_emac.
>
> OK thanks for clarifying it:
>
> Acked-by: Tony Lindgren
What happened to this patch?
--
Måns Rullgård
Greg Kroah-Hartman writes:
> On Thu, Feb 28, 2019 at 03:22:24PM +0000, Måns Rullgård wrote:
>> Greg Kroah-Hartman writes:
>>
>> > On Thu, Feb 28, 2019 at 02:33:44PM +, Mans Rullgard wrote:
>> >> Add a boolean property indicating that a device is
* Otherwise, check whether DT indicates this device is non-removable.
+*/
+ if (of_property_read_bool(udev->dev.of_node, "non-removable")) {
+ udev->removable = USB_DEVICE_FIXED;
+ return;
+ }
+
/*
* Otherwise, check whether the hub knows whether a port is removable
* or not
--
Måns Rullgård
Johan Hovold writes:
> Adding Bjørn.
>
> On Wed, Feb 27, 2019 at 11:57:16AM +0000, Måns Rullgård wrote:
>> Johan Hovold writes:
>>
>> > On Tue, Feb 26, 2019 at 05:07:10PM +, Mans Rullgard wrote:
>> >> The SIMCom SIM5218 and compatible devices ha
device speed):
bLength10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
bNumConfigurations 1
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x
(Bus Powered)
--
Måns Rullgård
ice_put(), should it ever be called. Moreover, these
devices are not removed if the module is unloaded or if there is an
error partway through the loop.
That said, it doesn't seem like setting of_node in
platform_device_register_full() should cause any (new) problems here.
--
Måns Rullgård
"Rafael J. Wysocki" writes:
> On Wed, Feb 20, 2019 at 1:12 PM Måns Rullgård wrote:
>>
>> Johan Hovold writes:
>>
>> > On Wed, Feb 20, 2019 at 11:35:06AM +, Mans Rullgard wrote:
>> >> If the provided fwnode is an OF node, set dev.of_node a
.c
>> +++ b/drivers/base/platform.c
>> @@ -512,6 +512,7 @@ struct platform_device *platform_device_register_full(
>>
>> pdev->dev.parent = pdevinfo->parent;
>> pdev->dev.fwnode = pdevinfo->fwnode;
>> +pdev->dev.of_node = of_node_get(to_of_node(pdev->dev.fwnode));
>>
>> if (pdevinfo->dma_mask) {
>> /*
>
> Johan
--
Måns Rullgård
>
> pdev->dev.parent = pdevinfo->parent;
> pdev->dev.fwnode = pdevinfo->fwnode;
> + pdev->dev.of_node = of_node_get(to_of_node(pdev->dev.fwnode));
>
> if (pdevinfo->dma_mask) {
> /*
> --
Sorry, I forgot to add a v2 to this. Anyway, the only change is the
commit message.
--
Måns Rullgård
"Rafael J. Wysocki" writes:
> On Wed, Feb 20, 2019 at 11:41 AM Måns Rullgård wrote:
>>
>> "Rafael J. Wysocki" writes:
>>
>> > On Mon, Feb 18, 2019 at 12:10 PM Måns Rullgård wrote:
>> >>
>> >> "Rafael J. Wysoc
t;
>> So please add this to all the new nodes. It seems to work regardless whether
>> you add it before or after the label, though having it after the label seems
>> to make vim syntax highlighting happier.
Should we also add this to existing nodes?
BTW, I really do need all those uart pin options.
--
Måns Rullgård
"Rafael J. Wysocki" writes:
> On Mon, Feb 18, 2019 at 12:10 PM Måns Rullgård wrote:
>>
>> "Rafael J. Wysocki" writes:
>>
>> > On Sat, Feb 16, 2019 at 5:50 PM Mans Rullgard wrote:
>> >>
>> >> If the provided fwno
s
> line, so something like:
>
> /omit-if-no-ref/
> uart0_pf_pins: uart0-pf-pins {
> };
>
> And it does have the advantage of keeping the same line width, which
> could get pretty long on some nodes.
Thanks, I'd missed that directive. It always seems needlessly annoying
to make everybody working on a new board to add those nodes separately.
--
Måns Rullgård
and_ it has and explicit status = "disabled" property.
The default is still to create devices for all interfaces.
That said, printing a message is probably a good idea anyway. Would
"info" level be appropriate for this?
--
Måns Rullgård
27;s kobject, so
> when is that reference dropped? Or if it doesn't need to be dropped
> at all, why is this the case?
platform_device_release() calls of_device_node_put().
--
Måns Rullgård
m still panic on errors during init. There's
really not much else that can sanely be done since nothing will work
without irq handling.
As for the error return added by this patch, nothing checks it, so a
failure would merely result in the irqchip being silently skipped and
nothing working.
Miguel Ojeda writes:
> Hi Måns,
>
> On Thu, Dec 6, 2018 at 1:06 PM Måns Rullgård wrote:
>>
>> >> BTW, the parsing of this command has been broken since 3.2-rc1 due to
>> >> commit 129957069e6a.
>> >
>> > Thanks for checking! Are you
Miguel Ojeda writes:
> On Wed, Dec 5, 2018 at 6:58 PM Måns Rullgård wrote:
>>
>> Suppose the command "\e[Lx0y0;" is written to the device. The
>> charlcd_write_char() function adds one character at a time to the escape
>> sequence buffer.
>
> Ah, yes
ntil we have seen one. With the
characters being added to the buffer one by one, it is enough to check
for semicolon at the end.
BTW, the parsing of this command has been broken since 3.2-rc1 due to
commit 129957069e6a.
--
Måns Rullgård
patch author when you claim to
> be fixing a bug in their patch.
Sorry about that. Blame the get-maintainers script.
--
Måns Rullgård
pends on SOC_IMX23 || SOC_IMX28 || SOC_IMX6Q || SOC_IMX6SX ||
>> SOC_IMX6UL
>> select STMP_DEVICE
>> select DMA_ENGINE
>> help
>> --
>> 2.14.1
>>
>
> --
> ~Vinod
--
Måns Rullgård
Florian Fainelli writes:
> What do we do with this patch series to move forward? Can we get Doug's
> changes queued up for 4.14?
My opinion is that the correct combined function should be added and the
tango driver updated to use it. Patches already exist, so what are we
waiting for
Florian Fainelli writes:
> On 07/25/2017 06:29 AM, Måns Rullgård wrote:
>> Marc Gonzalez writes:
>>
>>> On 25/07/2017 15:16, Måns Rullgård wrote:
>>>
>>>> What happened to the patch adding the proper combined function?
>>&g
Marc Gonzalez writes:
> On 25/07/2017 15:16, Måns Rullgård wrote:
>
>> What happened to the patch adding the proper combined function?
>
> It appears you're not CCed on v2.
>
> https://patchwork.kernel.org/patch/9859799/
>
> Doug wrote:
>> Yes, you under
ct[i].chip.irq_mask_ack = irq_gc_mask_disable_reg_and_ack;
> ct[i].chip.irq_unmask = irq_gc_unmask_enable_reg;
> ct[i].chip.irq_set_type = tangox_irq_set_type;
> ct[i].chip.name = gc->domain->name;
> --
What happened to the patch adding the proper combined function?
--
Måns Rullgård
reg;
>> -ct[i].chip.irq_mask_ack = irq_gc_mask_disable_reg_and_ack;
>> +ct[i].chip.irq_mask_ack = irq_gc_mask_disable_and_ack_set;
>> ct[i].chip.irq_unmask = irq_gc_unmask_enable_reg;
>> ct[i].chip.irq_set_type = tangox_irq_set_type;
>> ct[i].chip.name = gc->domain->name;
>>
>
--
Måns Rullgård
p_data(d);
>> +struct irq_chip_type *ct = irq_data_get_chip_type(d);
>> +u32 mask = d->mask;
>> +
>> +irq_gc_lock(gc);
>> +irq_reg_writel(gc, mask, ct->regs.disable);
>> +*ct->mask_cache &= ~mask;
>> +irq_reg_writel(gc, mask, ct->regs.ack);
>> +irq_gc_unlock(gc);
>> +}
This function looks like it should probably be used instead. I'll try
to remember to test it when I have time to fire up that hardware.
--
Måns Rullgård
Tomas Winkler writes:
> On Thu, Mar 9, 2017 at 4:26 PM, Måns Rullgård wrote:
>> Tomas Winkler writes:
>>
>>> On Thu, Mar 9, 2017 at 4:16 PM, Måns Rullgård wrote:
>>>> Tomas Winkler writes:
>>>>
>>>>> On Thu, Mar 9, 2017
Tomas Winkler writes:
> On Thu, Mar 9, 2017 at 4:16 PM, Måns Rullgård wrote:
>> Tomas Winkler writes:
>>
>>> On Thu, Mar 9, 2017 at 3:02 PM, Måns Rullgård wrote:
>>>> Tomas Winkler writes:
>>>>
>>>>> On Mon, Mar 6, 2017 at 2:
Tomas Winkler writes:
> On Thu, Mar 9, 2017 at 3:02 PM, Måns Rullgård wrote:
>> Tomas Winkler writes:
>>
>>> On Mon, Mar 6, 2017 at 2:31 AM, Måns Rullgård wrote:
>>>> Henrique de Moraes Holschuh writes:
>>>>
>>>>> On Sun,
Tomas Winkler writes:
> On Mon, Mar 6, 2017 at 2:31 AM, Måns Rullgård wrote:
>> Henrique de Moraes Holschuh writes:
>>
>>> On Sun, 05 Mar 2017, Måns Rullgård wrote:
>>>> Tomas Winkler writes:
>>>> > Sparse complains for arrays declared wi
Henrique de Moraes Holschuh writes:
> On Sun, 05 Mar 2017, Måns Rullgård wrote:
>> Tomas Winkler writes:
>> > Sparse complains for arrays declared with variable length
>> >
>> > 'warning: Variable length array is used'
>> >
>> &g
ster for the frame pointer, and
it often prevents inlining.
--
Måns Rullgård
ard stops just short of declaring pointer
to void compatible with other pointer types.
> However, I agree that it will work as expected on typical platforms
> (where all pointers are the same size, and the calling convention
> treats all pointers the same).
Yes, I don't see how it could possibly go wrong.
--
Måns Rullgård
k C permits for "undefined behavior, strictly speaking".
> Besides, that same mechanism is already used elsewhere, which is how I
> got the idea. Are you claiming that there are situations where it won't
> work ?
A pointer to void is interchangeable with any other pointer type. That
doesn't necessarily imply that pointers to functions taking arguments of
different pointer types (as we have here) are always compatible. I'd
have to read the C standard carefully to see if there's any such
promise, and I have other things to do right now. I am, however, not
aware of any ABI (certainly none used by Linux) where it would pose a
problem.
--
Måns Rullgård
restart.notifier_call = tangox_wdt_restart;
>> -dev->restart.priority = 128;
>> -err = register_restart_handler(&dev->restart);
>> -if (err)
>> -dev_warn(&pdev->dev, "failed to register restart handler\n");
>> -
>> dev_info(&pdev->dev, "SMP86xx/SMP87xx watchdog registered\n");
>>
>> return 0;
>> @@ -202,7 +193,6 @@ static int tangox_wdt_remove(struct platform_device
>> *pdev)
>> tangox_wdt_stop(&dev->wdt);
>> clk_disable_unprepare(dev->clk);
>>
>> -unregister_restart_handler(&dev->restart);
>> watchdog_unregister_device(&dev->wdt);
>>
>> return 0;
>>
--
Måns Rullgård
Joe Perches writes:
> On Wed, 2016-12-14 at 18:13 +0000, Måns Rullgård wrote:
>> Alexey Dobriyan writes:
>> > I call for a tree wide moratorium on pure coding style changes.
> []
>> I'd relax this slightly and say don't do style
>> patches unless as a
k at the code I'm trying
to debug without wanting to claw my eyes out. In such cases, an initial
cleanup patch often makes the actual fix much easier to comprehend.
There's not a lot such code in the kernel, thankfully, but it does
exist.
> Said that, I call for a tree wide morat
David Laight writes:
> From: Måns Rullgård
>> Sent: 10 December 2016 13:25
> ...
>> I solved this problem in an Ethernet driver by copying the initial part
>> of the packet to an aligned skb and appending the remainder using
>> skb_add_rx_frag(). The kernel netw
ur protocol.
Always include some way of extending the protocol in the future. A
single bit is often enough. Require a value of zero initially, then if
you ever want to change anything, setting it to one can indicate
whatever you want, including a complete redesign of the header.
Alternatively, a o
Felix Fietkau writes:
> On 2016-12-10 14:25, Måns Rullgård wrote:
>> Felix Fietkau writes:
>>
>>> On 2016-12-07 19:54, Jason A. Donenfeld wrote:
>>>> On Wed, Dec 7, 2016 at 7:51 PM, David Miller wrote:
>>>>> It's so much better to anal
e remainder using
skb_add_rx_frag(). The kernel network stack only cares about the
headers, so the alignment of the packet payload doesn't matter.
--
Måns Rullgård
A) solves this.
Driver-specific interfaces are not the solution. That way lies chaos
and madness.
This would all be so much easier if you all would just shut up for a
moment and let me fix it properly.
--
Måns Rullgård
Sebastian Frias writes:
> On 09/12/16 07:59, Vinod Koul wrote:
>> On Thu, Dec 08, 2016 at 04:48:18PM +0000, Måns Rullgård wrote:
>>> Vinod Koul writes:
>>>
>>>> To make it efficient, disregarding your Sbox HW issue, the solution is
>>>> vir
ired so they cant use any channel. But
> if you dont have this restriction then driver can queue up many transactions
> from different controllers.
Have you been paying attention at all? This exactly what the driver
ALREADY DOES.
--
Måns Rullgård
Vinod Koul writes:
> On Thu, Dec 08, 2016 at 11:44:53AM +0000, Måns Rullgård wrote:
>> Vinod Koul writes:
>>
>> > On Wed, Dec 07, 2016 at 04:45:58PM +, Måns Rullgård wrote:
>> >> Vinod Koul writes:
>> >>
>> >> >
Vinod Koul writes:
> On Thu, Dec 08, 2016 at 12:20:30PM +0000, Måns Rullgård wrote:
>> >
>> > I'm far from claiming that drivers/tty/serial/sh-sci.c is perfect, but
>> > it does request DMA channels at open time, not at probe time.
>>
>> In the par
Mason writes:
> On 08/12/2016 13:44, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> On 08/12/2016 13:20, Måns Rullgård wrote:
>>>
>>>> The only problem we have is that nobody envisioned hardware where the
>>>> dma engine indicates com
Mason writes:
> On 08/12/2016 13:20, Måns Rullgård wrote:
>
>> The only problem we have is that nobody envisioned hardware where the
>> dma engine indicates completion slightly too soon. I suspect there's a
>> fifo or such somewhere, and the interrupt is triggered w
Geert Uytterhoeven writes:
> Hi Måns,
>
> On Thu, Dec 8, 2016 at 12:47 PM, Måns Rullgård wrote:
>> Geert Uytterhoeven writes:
>>> On Thu, Dec 8, 2016 at 11:54 AM, Mason wrote:
>>>> On 08/12/2016 11:39, Vinod Koul wrote:
>>>>> On Wed, De
Geert Uytterhoeven writes:
> On Thu, Dec 8, 2016 at 12:44 PM, Måns Rullgård wrote:
>> Vinod Koul writes:
>>> On Wed, Dec 07, 2016 at 04:45:58PM +0000, Måns Rullgård wrote:
>>>> Vinod Koul writes:
>>>> > On Tue, Dec 06, 2016 at 01:14:20PM +, Mån
Geert Uytterhoeven writes:
> On Thu, Dec 8, 2016 at 11:54 AM, Mason wrote:
>> On 08/12/2016 11:39, Vinod Koul wrote:
>>> On Wed, Dec 07, 2016 at 04:45:58PM +0000, Måns Rullgård wrote:
>>>> Vinod Koul writes:
>>>>> On Tue, Dec 06, 2016 at 01:14:20PM
Vinod Koul writes:
> On Wed, Dec 07, 2016 at 04:45:58PM +0000, Måns Rullgård wrote:
>> Vinod Koul writes:
>>
>> > On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote:
>> >>
>> >> That's not going to work very well. Device driver
Vinod Koul writes:
> On Wed, Dec 07, 2016 at 04:44:55PM +0000, Måns Rullgård wrote:
>> Vinod Koul writes:
>> >>
>> >> What you're proposing, Vinod, is to make a channel exclusive
>> >> to a driver, as long as the driver has not explicitly r
Vinod Koul writes:
> On Tue, Dec 06, 2016 at 01:14:20PM +0000, Måns Rullgård wrote:
>>
>> That's not going to work very well. Device drivers typically request
>> dma channels in their probe functions or when the device is opened.
>> This means that reserving on
l(), right?
>
> Precisely, but yes the downside of that is concurrent access are
> limited, but am not sure if driver implements virtual channels and
> allows that..
My driver implements virtual channels. The problem is that the physical
dma channels signal completion slightly too soon, at least with
mem-to-device transfers. Apparently we need to keep the sbox routing
until the peripheral indicates that it has actually received all the
data.
--
Måns Rullgård
Mason writes:
> On 06/12/2016 14:14, Måns Rullgård wrote:
>
>> Mason wrote:
>>
>>> On 06/12/2016 06:12, Vinod Koul wrote:
>>>
>>>> On Tue, Nov 29, 2016 at 07:25:02PM +0100, Mason wrote:
>>>>
>>>>> Is there a way to write
to deliberately cripple the software
support in order to shoehorn it into an incomplete model of how hardware
ought to work. While I agree it would be nicer if all hardware actually
did work that way, this isn't the reality we're living in.
--
Måns Rullgård
Mason writes:
> On 25/11/2016 16:12, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> I've had several talks with the HW dev, and I don't think they
>>> anticipated the need to mux the 3 channels. In their minds,
>>> customers would choose a
Russell King - ARM Linux writes:
> On Fri, Nov 25, 2016 at 02:40:21PM +0000, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Fri, Nov 25, 2016 at 02:03:20PM +, Måns Rullgård wrote:
>> >> Russell King - ARM Linux writes:
>> >
Mason writes:
> On 25/11/2016 15:17, Russell King - ARM Linux wrote:
>> On Fri, Nov 25, 2016 at 02:03:20PM +0000, Måns Rullgård wrote:
>>> Russell King - ARM Linux writes:
>>>
>>>> On Fri, Nov 25, 2016 at 01:50:35PM +, Måns Rullgård wrote:
>>&g
Mason writes:
> On 25/11/2016 15:12, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> On 25/11/2016 12:57, Måns Rullgård wrote:
>>>
>>>> The same DMA unit is also used for SATA, which is an off the shelf
>>>> Designware controller with
Russell King - ARM Linux writes:
> On Fri, Nov 25, 2016 at 02:03:20PM +0000, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Fri, Nov 25, 2016 at 01:50:35PM +, Måns Rullgård wrote:
>> >> Russell King - ARM Linux writes:
>> >
Mason writes:
> On 25/11/2016 14:11, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> It seems there is a disconnect between what Linux expects - an IRQ
>>> when the transfer is complete - and the quirks of this HW :-(
>>>
>>> On this syste
Mason writes:
> On 25/11/2016 12:57, Måns Rullgård wrote:
>
>> The same DMA unit is also used for SATA, which is an off the shelf
>> Designware controller with an in-kernel driver. This interrupt timing
>> glitch can actually explain some intermittent errors I've
1 - 100 of 433 matches
Mail list logo
