linux-kernel - RE: [PATCH net-next 0/4] r8152: firmware support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0835B3720019904CB8F7AA43166CEEB25161DF@RTITMBSV03.realtek.com.tw>
Date:	Mon, 25 Aug 2014 06:43:02 +0000
From:	Hayes Wang <hayeswang@...ltek.com>
To:	David Miller <davem@...emloft.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	nic_swsd <nic_swsd@...ltek.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
Subject: RE: [PATCH net-next 0/4] r8152: firmware support

 From: David Miller [mailto:davem@...emloft.net] 
[...]
> That still doesn't convince me.
> 
> The functions I see you removing are just programming a set of
> registers in some way.

That is to clear the break point of the firmware. If a firmware exists,
you should clear it before updating a new one.

> And the firmware that is replacing those functions is just going to be
> causing the same register writes, just even more obfuscated than it is
> now.
> 
> You should keep the C functions which document and show clearly what
> is being programmed in each chip.
> 
> Don't hide register programming behind firmware files, please.

Excuse me. Some settings are relative the content of the firmware.
How should I deal with that parts. Take 8153 (RTL_VER_03) for
example.

	1. wait PLA 0xb800 bit 6 = 1.
	2. set patch key = 0x7000.
	3. update the PHY firmware.
	4. enable the firmware.
	5. set USB 0xcfca bit 14 = 0.
	6. clear break point (That is r8153_clear_bp()).
	7. load the firmware about PLA and USB parts.
	8. set the break point of the firmware.
	9. set USB 0xcfca bit 14 = 1.

Except the step 3, 4, 6 and 7, the other steps depend on the
context of the firmware. That is, for different firmware, some
actions would be removed or added, and some settings would be
different. Especially the step 8, it often different for
different firmwares. Should I add some firmware version check
in the source code? Such as

	if (fw_version == v1) {
		...
		load firmware
		set break point of the firmware
		...
	} else if (fw_version == v2) {
	...--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/