USB: make usb_kbd obey USB DMA alignment requirements

Move environment settings for stdin/stdout/stderr to tegra-common-post.h and generate them automaticaly based on input device selection.

Signed-off-by Allen Martin <[email protected]>

---
 include/configs/seaboard.h          |    5 -----
 include/configs/tegra-common-post.h |   19 +++++++++++++++++++
 include/configs/tegra20-common.h    |    4 ----
 3 files changed, 19 insertions(+), 9 deletions(-)

include/configs/seaboard.h +0 -5

index 0727a4c..2cb3ac9 100644
@@ -98,11 +98,6 @@
 #define CONFIG_TEGRA_KEYBOARD
 #define CONFIG_KEYBOARD
 
-#undef TEGRA_DEVICE_SETTINGS
-#define TEGRA_DEVICE_SETTINGS	"stdin=serial,tegra-kbc\0" \
-				"stdout=serial\0" \
-				"stderr=serial\0"
-
 #include "tegra-common-post.h"
 
 /* NAND support */

(quoted diff) +0 -0

b/include/configs/tegra-common-post.h index 9698c23..8d21d9c 100644

include/configs/tegra-common-post.h +19 -0

@@ -140,6 +140,25 @@
 
 #endif
 
+#ifdef CONFIG_TEGRA_KEYBOARD
+#define STDIN_KBD_KBC ",tegra-kbc"
+#else
+#define STDIN_KBD_KBC ""
+#endif
+
+#ifdef CONFIG_USB_KEYBOARD
+#define STDIN_KBD_USB ",usbkbd"
+#define CONFIG_SYS_USB_EVENT_POLL
+#define CONFIG_PREBOOT			"usb start"
+#else
+#define STDIN_KBD_USB ""
+#endif
+
+#define TEGRA_DEVICE_SETTINGS \
+	"stdin=serial" STDIN_KBD_KBC STDIN_KBD_USB "\0" \
+	"stdout=serial\0" \
+	"stderr=serial\0" \
+
 #define CONFIG_EXTRA_ENV_SETTINGS \
 	TEGRA_DEVICE_SETTINGS \
 	"fdt_load=0x01000000\0" \

(quoted diff) +0 -0

b/include/configs/tegra20-common.h index dc7444d..ea89d76 100644

include/configs/tegra20-common.h +0 -0

@@ -125,12 +125,8 @@
 

Dear Allen Martin,

Quoted 5 lines

Move environment settings for stdin/stdout/stderr to tegra-common-post.h and generate them automaticaly based on input device selection.

Signed-off-by Allen Martin <[email protected]>

2/3 and 3/3 should go through tegra, thanks

Quoted 9 lines

Dear Allen Martin,

Quoted 5 lines

Move environment settings for stdin/stdout/stderr to tegra-common-post.h and generate them automaticaly based on input device selection.

Signed-off-by Allen Martin <[email protected]>

2/3 and 3/3 should go through tegra, thanks

Although of course patches 2 & 3 depend on patch 1. So, the process would have to be:

1) Apply patch 1 to USB tree.
2) Send pull request for USB to main U-Boot repo.
3) Pull request actioned.
4) Wait until latest u-boot/master is picked in u-boot/arm and hence u-boot/tegra.
5) Apply patches 2 & 3 to the Tegra tree.

That's quite a long round-trip. What's the typical delay between (1) and
(2) or (3) and (4)?

In the Linux kernel, this would be handled by putting patch (1) into a topic branch on its own, which can then be merged into both the USB branch and immediately into Tegra's branch. Of course, that all relies on never rebasing during pull requests (otherwise, the branch with patch 1 might end up being applied as two different commits when merging into u-boot/master); something which apparently isn't acceptable for U-Boot:-(

Dear Stephen Warren,

Quoted 24 lines · Marek Vasut

Quoted 9 lines

Dear Allen Martin,

Quoted 5 lines

Move environment settings for stdin/stdout/stderr to tegra-common-post.h and generate them automaticaly based on input device selection.

Signed-off-by Allen Martin <[email protected]>

2/3 and 3/3 should go through tegra, thanks

Although of course patches 2 & 3 depend on patch 1. So, the process would have to be:

1) Apply patch 1 to USB tree.
2) Send pull request for USB to main U-Boot repo.
3) Pull request actioned.
4) Wait until latest u-boot/master is picked in u-boot/arm and hence u-boot/tegra.
5) Apply patches 2 & 3 to the Tegra tree.

That's quite a long round-trip. What's the typical delay between (1) and
(2) or (3) and (4)?

Quoted 6 lines

In the Linux kernel, this would be handled by putting patch (1) into a topic branch on its own, which can then be merged into both the USB branch and immediately into Tegra's branch. Of course, that all relies on never rebasing during pull requests (otherwise, the branch with patch 1 might end up being applied as two different commits when merging into u-boot/master); something which apparently isn't acceptable for U-Boot:-(

Fine, then if you agree, I'll pull them all through usb tree ?

Dear Stephen Warren,

Quoted 24 lines · Marek Vasut

Quoted 9 lines

Dear Allen Martin,

Quoted 5 lines

Move environment settings for stdin/stdout/stderr to tegra-common-post.h and generate them automaticaly based on input device selection.

Signed-off-by Allen Martin <[email protected]>

2/3 and 3/3 should go through tegra, thanks

Although of course patches 2 & 3 depend on patch 1. So, the process would have to be:

1) Apply patch 1 to USB tree.
2) Send pull request for USB to main U-Boot repo.
3) Pull request actioned.
4) Wait until latest u-boot/master is picked in u-boot/arm and hence u-boot/tegra.
5) Apply patches 2 & 3 to the Tegra tree.

That's quite a long round-trip. What's the typical delay between (1) and
(2) or (3) and (4)?

Quoted 6 lines

In the Linux kernel, this would be handled by putting patch (1) into a topic branch on its own, which can then be merged into both the USB branch and immediately into Tegra's branch. Of course, that all relies on never rebasing during pull requests (otherwise, the branch with patch 1 might end up being applied as two different commits when merging into u-boot/master); something which apparently isn't acceptable for U-Boot:-(

Fine, then if you agree, I'll pull them all through usb tree ?

Best regards,
Marek Vasut

Dear Stephen Warren,

Quoted 24 lines · Marek Vasut

Quoted 9 lines

Dear Allen Martin,

Quoted 5 lines

Move environment settings for stdin/stdout/stderr to tegra-common-post.h and generate them automaticaly based on input device selection.

Signed-off-by Allen Martin <[email protected]>

2/3 and 3/3 should go through tegra, thanks

Although of course patches 2 & 3 depend on patch 1. So, the process would have to be:

1) Apply patch 1 to USB tree.
2) Send pull request for USB to main U-Boot repo.
3) Pull request actioned.
4) Wait until latest u-boot/master is picked in u-boot/arm and hence u-boot/tegra.
5) Apply patches 2 & 3 to the Tegra tree.

That's quite a long round-trip. What's the typical delay between (1) and
(2) or (3) and (4)?

Quoted 6 lines

In the Linux kernel, this would be handled by putting patch (1) into a topic branch on its own, which can then be merged into both the USB branch and immediately into Tegra's branch. Of course, that all relies on never rebasing during pull requests (otherwise, the branch with patch 1 might end up being applied as two different commits when merging into u-boot/master); something which apparently isn't acceptable for U-Boot:-(

Fine, then if you agree, I'll pull them all through usb tree ?

Quoted 34 lines

Dear Stephen Warren,

Quoted 31 lines · Marek Vasut

Quoted 9 lines

Dear Allen Martin,

Quoted 5 lines

Move environment settings for stdin/stdout/stderr to tegra-common-post.h and generate them automaticaly based on input device selection.

Signed-off-by Allen Martin <[email protected]>

2/3 and 3/3 should go through tegra, thanks

Although of course patches 2 & 3 depend on patch 1. So, the process would have to be:

1) Apply patch 1 to USB tree.
2) Send pull request for USB to main U-Boot repo.
3) Pull request actioned.
4) Wait until latest u-boot/master is picked in u-boot/arm and hence u-boot/tegra.
5) Apply patches 2 & 3 to the Tegra tree.

That's quite a long round-trip. What's the typical delay between (1) and (2) or (3) and (4)?

In the Linux kernel, this would be handled by putting patch (1) into a topic branch on its own, which can then be merged into both the USB branch and immediately into Tegra's branch. Of course, that all relies on never rebasing during pull requests (otherwise, the branch with patch 1 might end up being applied as two different commits when merging into u-boot/master); something which apparently isn't acceptable for U-Boot:-(

Quoted 1 line

Fine, then if you agree, I'll pull them all through usb tree ?

Hi Marek, I just wanted to check on that status of this series. Were you going to apply them to u-boot-usb ?

Move environment settings for stdin/stdout/stderr to tegra-common-post.h and generate them automaticaly based on input device selection.

Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.

Signed-off-by Allen Martin <[email protected]>

---
 common/usb_kbd.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

common/usb_kbd.c +0 -0

index 19f01db..57928d9 100644

common/usb_kbd.c +0 -3

 	uint32_t	repeat_delay;
 
 	uint32_t	usb_in_pointer;
 	uint32_t	usb_out_pointer;
 	uint8_t		usb_kbd_buffer[USB_KBD_BUFFER_LEN];
 
-	uint8_t		new[8];
-	uint8_t		old[8];
-
 	uint8_t		flags;
 };
 

common/usb_kbd.c +0 -0

 	if (!data) {
 		printf("USB KBD: Error allocating private data\n");

return 0;

Dear Allen Martin,

Quoted 7 lines

Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.

(quoted diff) +0 -0

@@ -426,7 +426,7 @@ static int usb_kbd_probe(struct usb_device *dev,
 unsigned int ifnum)
 

common/usb_kbd.c static int usb_kbd_probe(struct usb_device *dev, unsigned int ifnum) · line 429

Quoted 4 lines

common/usb_kbd.c +1 -1

 	USB_KBD_PRINTF("USB KBD: found set protocol...\n");
 
-	data = malloc(sizeof(struct usb_kbd_pdata));
+	data = memalign(USB_DMA_MINALIGN, sizeof(struct usb_kbd_pdata));

Don't we have ALLOC_CACHE_ALIGN_BUFFER and such stuff in include/common.h for this purpose ?

Dear Allen Martin,

Quoted 16 lines

Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.

Signed-off-by Allen Martin <[email protected]>

---
 common/usb_kbd.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

common/usb_kbd.c +0 -0

index 19f01db..57928d9 100644
@@ -106,15 +106,15 @@ static const unsigned char usb_kbd_num_keypad[] = {
 	(USB_KBD_NUMLOCK | USB_KBD_CAPSLOCK | USB_KBD_SCROLLLOCK)
 

common/usb_kbd.c static const unsigned char usb_kbd_num_keypad[] = { · line 111

Quoted 4 lines

common/usb_kbd.c +3 -0

 struct usb_kbd_pdata {
+	uint8_t		new[8];
+	uint8_t		old[8];
+

Some comment about the alignment won't hurt.

Quoted 16 lines

common/usb_kbd.c +0 -3

 	uint32_t	repeat_delay;
 
 	uint32_t	usb_in_pointer;
 	uint32_t	usb_out_pointer;
 	uint8_t		usb_kbd_buffer[USB_KBD_BUFFER_LEN];
 
-	uint8_t		new[8];
-	uint8_t		old[8];
-
 	uint8_t		flags;
 };
 

@@ -426,7 +426,7 @@ static int usb_kbd_probe(struct usb_device *dev,
 unsigned int ifnum)
 

common/usb_kbd.c static int usb_kbd_probe(struct usb_device *dev, unsigned int ifnum) · line 429

Quoted 4 lines

common/usb_kbd.c +1 -1

 	USB_KBD_PRINTF("USB KBD: found set protocol...\n");
 
-	data = malloc(sizeof(struct usb_kbd_pdata));
+	data = memalign(USB_DMA_MINALIGN, sizeof(struct usb_kbd_pdata));

Don't we have ALLOC_CACHE_ALIGN_BUFFER and such stuff in include/common.h for this purpose ?

Quoted 4 lines

common/usb_kbd.c +0 -0

 	if (!data) {
 		printf("USB KBD: Error allocating private data\n");

return 0;

Best regards,
Marek Vasut

Quoted 21 lines

Dear Allen Martin,

Quoted 19 lines

Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.

Signed-off-by Allen Martin <[email protected]>

---

 common/usb_kbd.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

common/usb_kbd.c +0 -0

index 19f01db..57928d9 100644
@@ -106,15 +106,15 @@ static const unsigned char usb_kbd_num_keypad[] =
 {
 
 	(USB_KBD_NUMLOCK | USB_KBD_CAPSLOCK | USB_KBD_SCROLLLOCK)
 

Quoted 7 lines

common/usb_kbd.c static const unsigned char usb_kbd_num_keypad[] = { · line 111

Quoted 5 lines

common/usb_kbd.c +3 -0

 struct usb_kbd_pdata {
 
+	uint8_t		new[8];
+	uint8_t		old[8];
+

Some comment about the alignment won't hurt.

Good idea.

Quoted 17 lines

Quoted 17 lines

common/usb_kbd.c +0 -3

 	uint32_t	repeat_delay;
 
 	uint32_t	usb_in_pointer;
 	uint32_t	usb_out_pointer;
 	uint8_t		usb_kbd_buffer[USB_KBD_BUFFER_LEN];
 
-	uint8_t		new[8];
-	uint8_t		old[8];
-

common/usb_kbd.c +0 -0

 	uint8_t		flags;
 
 };

@@ -426,7 +426,7 @@ static int usb_kbd_probe(struct usb_device *dev,
 unsigned int ifnum)
 

Quoted 7 lines

common/usb_kbd.c static int usb_kbd_probe(struct usb_device *dev, unsigned int ifnum) · line 429

Quoted 4 lines

common/usb_kbd.c +1 -1

 	USB_KBD_PRINTF("USB KBD: found set protocol...\n");
 
-	data = malloc(sizeof(struct usb_kbd_pdata));
+	data = memalign(USB_DMA_MINALIGN, sizeof(struct usb_kbd_pdata));

Don't we have ALLOC_CACHE_ALIGN_BUFFER and such stuff in include/common.h for this purpose ?

There seems to be some discrepency here, because ehci-hcd.c uses USB_DMA_MINALIGN for all cache operations, which may or may not be the same as ARCH_DMA_MINALIGN, see usb.h:

/*
* The EHCI spec says that we must align to at least 32 bytes. However,
* some platforms require larger alignment.
*/
#if ARCH_DMA_MINALIGN > 32
#define USB_DMA_MINALIGN ARCH_DMA_MINALIGN
#else
#define USB_DMA_MINALIGN 32
#endif

For tegra this is fine, because ARCH_DMA_MINALIGN > 32, but grepping through header files, I see a few:

#define ARCH_DMA_MINALIGN 16

which will definately break. It looks like all other usb class drivers use ALLOC_CACHE_ALIGN_BUFFER() though, so for consistency the usb keyboard driver probably should too, but it seems like a potential problem.

Quoted 7 lines

common/usb_kbd.c static int usb_kbd_probe(struct usb_device *dev, unsigned int ifnum) · line 432

Quoted 4 lines

common/usb_kbd.c +0 -0

 	if (!data) {
 

common/usb_kbd.c +0 -0

 		printf("USB KBD: Error allocating private data\n");
 		return 0;

Best regards,
Marek Vasut

-Allen

Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.

Quoted 3 lines · Allen Martin

Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.

The series,

Tested-by Stephen Warren <[email protected]>

BTW, I tested tegra-kbc too, and that does indeed currently work (at least in my local dev branch based on u-boot/master).

Note that patch 2 has a merge conflict with the following patch in u-boot-tegra/next, since I assume your series is based on u-boot/master not u-boot-tegra/next:

799f182 ARM: tegra: use standard variables to define load addresses

It's pretty simple to resolve though.

Quoted 8 lines · Allen Martin

Quoted 3 lines

Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.

The series,

Tested-by Stephen Warren <[email protected]>

Quoted 2 lines

BTW, I tested tegra-kbc too, and that does indeed currently work (at least in my local dev branch based on u-boot/master).

Yes, I also tried on a seaboard with internal keyboard and it works, although once the USB keyboard driver loads the internal keyboard stops working. I haven't tracked down why, but it seems like a bug I can live with for now as seaboards with internal keyboards are pretty rare these days, and how many keyboards do you need in u-boot anyway?

:^)
:

Quoted 4 lines

Note that patch 2 has a merge conflict with the following patch in u-boot-tegra/next, since I assume your series is based on u-boot/master not u-boot-tegra/next:

Quoted 3 lines

799f182 ARM: tegra: use standard variables to define load addresses

It's pretty simple to resolve though.

Yes, I based it on u-boot/master, once we figure out what trees each patch is destined for I'll rebase appropriately.

Dear Allen Martin,

Quoted 12 lines · Stephen Warren

Quoted 10 lines · Allen Martin

Quoted 3 lines

Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.

The series,

Tested-by Stephen Warren <[email protected]>

BTW, I tested tegra-kbc too, and that does indeed currently work (at least in my local dev branch based on u-boot/master).

Quoted 5 lines

Yes, I also tried on a seaboard with internal keyboard and it works, although once the USB keyboard driver loads the internal keyboard stops working. I haven't tracked down why, but it seems like a bug I can live with for now as seaboards with internal keyboards are pretty rare these days, and how many keyboards do you need in u-boot anyway?

Good thing you pointed it out. Please let's not ignore a bug. How come it happens? What happens if you have two usb keyboards connected?

Quoted 6 lines

:^)
:

Quoted 4 lines

Note that patch 2 has a merge conflict with the following patch in u-boot-tegra/next, since I assume your series is based on u-boot/master not u-boot-tegra/next:

Quoted 6 lines

Quoted 3 lines

799f182 ARM: tegra: use standard variables to define load addresses

It's pretty simple to resolve though.

Yes, I based it on u-boot/master, once we figure out what trees each patch is destined for I'll rebase appropriately.

I pushed u-boot-usb/master today, can you check if it still applies ?

Best regards,
Marek Vasut

Quoted 14 lines · Marek Vasut

Dear Allen Martin,

Quoted 12 lines · Stephen Warren

Quoted 10 lines · Allen Martin

Quoted 3 lines

Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.

The series,

Tested-by Stephen Warren <[email protected]>

BTW, I tested tegra-kbc too, and that does indeed currently work (at least in my local dev branch based on u-boot/master).

Quoted 9 lines

Quoted 5 lines

Yes, I also tried on a seaboard with internal keyboard and it works, although once the USB keyboard driver loads the internal keyboard stops working. I haven't tracked down why, but it seems like a bug I can live with for now as seaboards with internal keyboards are pretty rare these days, and how many keyboards do you need in u-boot anyway?

Good thing you pointed it out. Please let's not ignore a bug. How come it happens? What happens if you have two usb keyboards connected?

I'm pretty sure the USB keyboard driver doesn't support multiple devices, I see this in drv_usb_kbd_init():

                /* We found a keyboard, check if it is already
                registered. */
                USB_KBD_PRINTF("USB KBD: found set up device.\n");
                old_dev = stdio_get_by_name(DEVNAME);
                if (old_dev) {
                        /* Already registered, just return ok. */
                        USB_KBD_PRINTF("USB KBD: is already
                registered.\n");
                        return 1;
                }

The bug is almost certainly inside the tegra kbd driver, which is why I'm not terribly concerned about it. The only boards that use that driver are inside NVIDIA, and even those are rare.

Quoted 14 lines

Dear Allen Martin,

Quoted 12 lines · Stephen Warren

Quoted 10 lines · Allen Martin

Quoted 3 lines

Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.

The series,

Tested-by Stephen Warren <[email protected]>

BTW, I tested tegra-kbc too, and that does indeed currently work (at least in my local dev branch based on u-boot/master).

Quoted 8 lines

Quoted 5 lines

Yes, I also tried on a seaboard with internal keyboard and it works, although once the USB keyboard driver loads the internal keyboard stops working. I haven't tracked down why, but it seems like a bug I can live with for now as seaboards with internal keyboards are pretty rare these days, and how many keyboards do you need in u-boot anyway?

Good thing you pointed it out. Please let's not ignore a bug. How come it happens? What happens if you have two usb keyboards connected?

I'm pretty sure the USB keyboard driver doesn't support multiple devices, I see this in drv_usb_kbd_init():

                /* We found a keyboard, check if it is already
                registered. */
                USB_KBD_PRINTF("USB KBD: found set up device.\n");
                old_dev = stdio_get_by_name(DEVNAME);
                if (old_dev) {
                        /* Already registered, just return ok. */
                        USB_KBD_PRINTF("USB KBD: is already
                registered.\n");
                        return 1;
                }

The bug is almost certainly inside the tegra kbd driver, which is why I'm not terribly concerned about it. The only boards that use that driver are inside NVIDIA, and even those are rare.

Dear Allen Martin,

Quoted 38 lines · Marek Vasut

Quoted 14 lines

Dear Allen Martin,

Quoted 12 lines · Stephen Warren

Quoted 10 lines · Allen Martin

Quoted 3 lines

Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA.

The series,

Tested-by Stephen Warren <[email protected]>

BTW, I tested tegra-kbc too, and that does indeed currently work (at least in my local dev branch based on u-boot/master).

Quoted 8 lines

Quoted 5 lines

Yes, I also tried on a seaboard with internal keyboard and it works, although once the USB keyboard driver loads the internal keyboard stops working. I haven't tracked down why, but it seems like a bug I can live with for now as seaboards with internal keyboards are pretty rare these days, and how many keyboards do you need in u-boot anyway?

Good thing you pointed it out. Please let's not ignore a bug. How come it happens? What happens if you have two usb keyboards connected?

I'm pretty sure the USB keyboard driver doesn't support multiple devices, I see this in drv_usb_kbd_init():

                /* We found a keyboard, check if it is already
                registered. */
                USB_KBD_PRINTF("USB KBD: found set up device.\n");
                old_dev = stdio_get_by_name(DEVNAME);
                if (old_dev) {
                        /* Already registered, just return ok. */
                        USB_KBD_PRINTF("USB KBD: is already
                registered.\n");
                        return 1;
                }

Quoted 3 lines

The bug is almost certainly inside the tegra kbd driver, which is why I'm not terribly concerned about it. The only boards that use that driver are inside NVIDIA, and even those are rare.

[...]

Good, now please fix the bug. I'm terribly unhappy seeing there is a bug that is about to go unfixed.

Quoted 4 lines

[...]

Good, now please fix the bug. I'm terribly unhappy seeing there is a bug that is about to go unfixed.

I didn't say the bug will go unfixed, I've opened an issue in our internal bug tracker so it doesn't go forgotten. It's just a matter of prioritization.

It's just not important to fix a corner case bug

in a driver that noone outside of NVIDIA can actually use when there are major functionality holes and regressions (like your change to serial_assign() that broke serial output on tegra).

I only work on
u-boot on the side, so I have to pick my battles carefully.

-Allen

Dear Allen Martin,

[...]

Quoted 5 lines

Quoted 4 lines

[...]

Good, now please fix the bug. I'm terribly unhappy seeing there is a bug that is about to go unfixed.

Quoted 3 lines

I didn't say the bug will go unfixed, I've opened an issue in our internal bug tracker so it doesn't go forgotten. It's just a matter of prioritization.

Yes, the bug is really simple to fix, so instead of arguing, please get to work. It could have been fixed already!